Kun joudut määrittämään olemassa olevan Cognos -ympäristön uudelleen käyttämään eri ulkoista suojauslähdettä (esim. Active Directory, LDAP jne.), Voit käyttää muutamia vaihtoehtoja. Haluan kutsua heitä: "Hyvä, paha ja ruma". Ennen kuin tutkimme näitä hyviä, huonoja ja rumia lähestymistapoja, katsotaanpa joitain yleisiä skenaarioita, jotka pyrkivät saamaan aikaan todennuksen nimitilan muutoksia Cognos -ympäristössä.
Yhteiset liiketoiminta -ajurit:
Laitteiston tai käyttöjärjestelmän päivittäminen - BI -laitteiston/infrastruktuurin nykyaikaistaminen voi olla usein kuljettaja. Vaikka muu Cognos voi toimia kuin mestari tyylikkäässä uudessa laitteistossasi ja modernissa 64-bittisessä käyttöjärjestelmässäsi, onnea siirtymässä noin vuoden 2005 Access Manager -versiosi uudelle alustalle. Access Manager (julkaistu ensimmäisen kerran sarjan 7 kanssa) on monien Cognos -asiakkaiden kunnioitettava menneisyyden päivä. Se on ainoa syy siihen, että monet asiakkaat pitävät sitä Windows Server 2003: n julmaa vanhaa versiota. Kirjoitus on ollut Access Managerin seinällä jo jonkin aikaa. Se on vanha ohjelmisto. Mitä nopeammin voit siirtyä pois siitä, sitä parempi.
Sovellusten standardointi- Organisaatiot, jotka haluavat yhdistää kaikkien sovellustensa todennuksen yhteen keskitetysti hallinnoitavaan yrityshakemistopalvelimeen (esim. LDAP, AD).
Sulautumiset ja yritysostot- Yritys A ostaa yrityksen B ja tarvitsee yrityksen B Cognos -ympäristön osoittamaan yrityksen A hakemistopalvelimelle aiheuttamatta ongelmia yrityksen nykyiseen BI -sisältöön tai kokoonpanoon.
Yritysmyynnit- Tämä on päinvastoin kuin sulautumisskenaario, osa yrityksestä erotetaan omaksi kokonaisuudekseen ja sen on nyt osoitettava nykyinen BI -ympäristönsä uudelle suojauslähteelle.
Miksi nimitilan siirrot voivat olla sotkuisia
Cognos-ympäristön osoittaminen uuteen suojauslähteeseen ei ole niin yksinkertaista kuin uuden nimisovelluksen lisääminen samoilla käyttäjillä, ryhmillä ja rooleilla, vanhan nimitilan irrottaminen ja VOILA!- kaikki uuden nimitilan Cognos-käyttäjät yhdistetään niiden sisältö. Itse asiassa voit usein päätyä veriseen sotkuun käsissäsi, ja tästä syystä…
Kaikkiin Cognosin tietoturvaperiaatteisiin (käyttäjät, ryhmät, roolit) viitataan CAMID -nimisellä yksilöllisellä tunnisteella. Vaikka kaikki muut määritteet olisivat samat, CAMID käyttäjälle olemassa todennuksen nimitila ei ole sama kuin CAMID kyseiselle käyttäjälle uusi nimiavaruus. Tämä voi tuhota olemassa olevan Cognos -ympäristön. Vaikka sinulla olisi vain muutamia Cognos -käyttäjiä, sinun on ymmärrettävä, että CAMID -viittauksia on olemassa monissa eri paikoissa sisältökaupassasi (ja niitä voi esiintyä jopa sisältökaupan ulkopuolella kehysmalleissa, muuntajamalleissa, TM1 -sovelluksissa, kuutioissa, suunnittelusovelluksissa jne.) ).
Monet Cognosin asiakkaat uskovat virheellisesti, että CAMIDilla on oikeastaan merkitystä vain oman kansion sisällölle, käyttäjäasetuksille jne. Tämä ei voi olla kauempana totuudesta. Kyse ei ole vain käyttäjien määrästä, vaan Cognos -objektien määrästä, joista sinun on huolehdittava. Sisältökaupassa on yli 140 erityyppistä Cognos -objektia, joista monilla voi olla useita CAMID -viittauksia.
Esimerkiksi:
- Ei ole harvinaista, että yhdellä sisältökaupan aikataululla on useita CAMID -viittauksia (aikataulun omistajan CAMID, käyttäjän CAMID, jonka aikataulun pitäisi toimia, jokaisen käyttäjän tai jakelulistan CAMID, jonka pitäisi lähettää sähköpostitse luotu raportin lähtö , jne.).
- Jokaisella Cognosin objektilla on tietoturvakäytäntö, joka määrää, ketkä käyttäjät voivat käyttää objektia (ajattele "Käyttöoikeudet" -välilehteä). Yhdellä tietoturvakäytännöllä, joka on riippuvainen kyseisestä kansiosta Cognos Connectionissa, on CAMID -viite jokaiselle käyttäjälle, ryhmälle ja roolille, joka on määritetty kyseisessä käytännössä.
- Toivottavasti ymmärrät pointin - tämä lista jatkuu ja jatkuu!
Ei ole harvinaista, että suuri sisältökauppa sisältää kymmeniä tuhansia CAMID -viitteitä (ja olemme nähneet joitain suuria satoja tuhansia).
Tee nyt laskutoimitukset sen sisällöstä omaa Cognos -ympäristö ja näet, että olet mahdollisesti tekemisissä CAMID -viitteiden laumojen kanssa. Se voi olla painajainen! Todennuksen nimitilan vaihtaminen (tai uudelleen määrittäminen) voi jättää kaikki nämä CAMID-viitteet ratkaisemattomaan tilaan. Tämä johtaa väistämättä Cognosin sisältö- ja kokoonpano -ongelmiin (esim. Aikataulut, jotka eivät enää ole käynnissä, sisältö, joka ei ole enää suojattu sellaisena kuin luulet sen olevan, paketit tai kuutiot, jotka eivät enää täytä tietoturvaa, Oman kansion sisällön ja käyttäjän menetys mieltymykset jne.).
Cognosin nimitilan siirtymämenetelmät
Nyt kun tiedämme, että Cognos -ympäristössä voi olla kymmeniä tuhansia CAMID -viittauksia, jotka edellyttävät uuden CAMID -arvon löytämistä, kartoittamista ja päivittämistä uudessa todennuksen nimitilassa, keskustelemme hyvistä, huonoista ja rumaista lähestymistavoista tämän ongelman ratkaisemiseksi.
Hyvä: Nimitilan korvaaminen Personalla
Ensimmäinen menetelmä (nimitilan korvaaminen) hyödyntää Motio'S, Persona IQ tuote. Tätä lähestymistapaa noudattaen olemassa oleva nimitilasi "korvataan" erityisellä Persona -nimiavaruudella, jonka avulla voit virtualisoida kaikki Cognosille altistuvat tietoturvaperiaatteet. Aiemmat tietoturvapäälliköt altistuvat Cognosille täsmälleen samalla CAMID-tekniikalla kuin ennenkin, vaikka niitä voidaan tukea minkä tahansa määrän ulkoisia suojauslähteitä (esim. Active Directory, LDAP tai jopa Persona-tietokanta).
Kaunis osa tätä lähestymistapaa on, että se vaatii NOLLA muutoksia Cognos -sisältöön. Tämä johtuu siitä, että Persona voi ylläpitää olemassa olevien päämiesten CAMID-tunnuksia, vaikka niitä tukisi uusi lähde. Joten ... kaikki ne kymmenet tuhannet CAMID -viitteet sisältökaupassasi, ulkoiset mallit ja historialliset kuutiot? He voivat pysyä juuri sellaisina kuin ovat. Työtä ei vaadita.
Tämä on ylivoimaisesti vähiten riskialtista ja pienintä vaikutusta käyttävä lähestymistapa, jota voit käyttää nykyisen Cognos -ympäristön siirtämiseen ulkoisesta suojauslähteestä toiseen. Se voidaan tehdä alle tunnissa noin 5 minuutin Cognos -seisokkeilla (ainoa Cognos -seisokkiaika on Cognosin uudelleenkäynnistys, kun olet määrittänyt Persona -nimitilan).
Huono: Nimitilan siirto Personan avulla
Jos helppo ja vähäriskinen lähestymistapa ei vain ole teekuppi, niin siellä is toinen vaihtoehto.
Personaa voidaan käyttää myös nimitilan siirtoon.
Tähän kuuluu toisen todennuksen nimitilan asentaminen Cognos -ympäristöön, kaikkien (toivottavasti) nykyisten tietoturvaperiaatteiden (vanhasta nimiavaruudesta) kartoittaminen vastaaviin uuden nimitilan päämiehiin ja sitten (tässä on hauska osa), jokaisen etsiminen, kartoittaminen ja päivittäminen yksittäinen CAMID -viite, joka on olemassa Cognos -ympäristössäsi: sisältökauppa, kehysmallit, muuntajamallit, historialliset kuutiot, TM1 -sovellukset, suunnittelusovellukset jne.
Tämä lähestymistapa on yleensä stressaava ja prosessiintensiivinen, mutta jos olet sellainen Cognos -järjestelmänvalvoja, joka tarvitsee hieman adrenaliinia voidakseen tuntea olevansa elossa (eikä haittaa myöhään illalla / varhain aamulla soitettuja puheluita), niin ehkä… tätä onko etsimäsi vaihtoehto?
Personaa voidaan käyttää automatisoimaan osia tästä prosessista. Sen avulla voit luoda kartoituksen vanhojen ja uusien tietoturvaperiaatteiden välille, automatisoida raa'an voiman "löytää, analysoida, päivittää" -logiikan sisältökaupan sisällölle jne. Mitä Persona voi automatisoida joihinkin tehtäviin täällä Tämän lähestymistavan työ sisältää "ihmiset ja prosessit" eikä varsinaista tekniikkaa.
Esimerkiksi tietojen kerääminen jokaisesta Framework Manager -mallista, jokaisesta Transformer -mallista, jokaisesta Planning / TM1 -sovelluksesta, jokaisesta SDK -sovelluksesta, joka omistaa ne, ja niiden päivittämisen ja jakelun suunnittelu voi olla paljon työtä. Kunkin Cognos -ympäristön, johon haluat kokeilla tätä, katkaisujen ja ylläpitoikkunoiden, joiden aikana voit yrittää siirtoa, koordinointi voi sisältää suunnittelua ja Cognosin seisokkiaikaa. Tehokkaan testisuunnitelman laatiminen (ja toteuttaminen) siirtymän jälkeen voi myös olla melkoinen karhu.
On myös aivan normaalia, että haluat tehdä tämän prosessin ensin ei-tuotantoympäristössä ennen kokeile sitä tuotannossa.
Vaikka nimitilan siirto Personan kanssa toimii (ja se on paljon parempi kuin alla oleva "Ruma" lähestymistapa), se on invasiivisempi, riskialttiimpi, sisältää paljon enemmän henkilöstöä ja kestää paljon enemmän tunteja kuin nimitilan korvaaminen. Siirrot on tyypillisesti tehtävä "aukioloaikojen" aikana, kun Cognos -ympäristö on edelleen online -tilassa, mutta loppukäyttäjien rajoitettu lomakkeen käyttö.
Ruma: Manuaaliset nimitilan siirtopalvelut
Ruma menetelmä sisältää kadehdittavan lähestymistavan yrittää käsin siirtyä todennuksen nimitilasta toiseen. Tämä edellyttää toisen todennuksen nimitilan yhdistämistä Cognos -ympäristöön ja yrittämistä siirtää tai luoda uudelleen manuaalisesti suuri osa olemassa olevasta Cognos -sisällöstä ja -määrityksistä.
Esimerkiksi tätä lähestymistapaa käyttämällä Cognos -järjestelmänvalvoja voi yrittää:
- Luo ryhmät ja roolit uudesta nimitilasta
- Luo näiden ryhmien ja roolien jäsenyydet uudelleen uudessa nimitilassa
- Kopioi manuaalisesti kansioiden sisältö, käyttäjäasetukset, portaalin välilehdet jne. Jokaisesta lähdetilistä kullekin kohdetilille
- Etsi sisältökaupasta jokainen käytäntöjoukko ja päivitä se viittaaviksi vastaaviin päämiehiin uudessa nimitilassa täsmälleen samalla tavalla kuin se viittasi vanhan nimiavaruuden päämiehiin
- Luo kaikki aikataulut uudelleen ja täytä ne vastaavilla kirjautumistiedoilla, vastaanottajilla jne.
- Nollaa kaikki sisältökaupan kaikkien objektien "omistaja" ja "yhteys" -ominaisuudet
- [Noin 40 muuta sisältökaupan asiaa, jotka unohdat]
- Kerää kaikki FM -mallit, joilla on objekti- tai tietoturva:
- Päivitä jokainen malli vastaavasti
- Julkaise jokainen malli uudelleen
- Jaa muutettu malli takaisin alkuperäiselle tekijälle
- Samanlainen työ Transformer -malleissa, TM1 -sovelluksissa ja suunnittelusovelluksissa, jotka on suojattu alkuperäistä nimitilaa vastaan
- [ja paljon muuta]
Vaikka jotkut Cognosin masokistit voivat salaa nauraa ilosta ajatuksesta napsauttaa 400,000 XNUMX kertaa Cognos Connectionissa, useimmille järkeville ihmisille tämä lähestymistapa on yleensä erittäin tylsä, aikaa vievä ja altis virheille. Se ei kuitenkaan ole tämän lähestymistavan suurin ongelma.
Suurin ongelma tässä lähestymistavassa on se, että se melkein aina johtaa epätäydelliseen muuttoon.
Tällä lähestymistavalla löydät (tuskallisesti) ja yrität kartoittaa ne CAMID -viittaukset, joista tiedät… mutta yleensä jätät kaikki ne CAMID -viitteet, jotka en tiedä.
Kun olet ajatella olet lopettanut tämän lähestymistavan, et usein ihan oikeesti tehty.
Sisältökaupassasi on esineitä, jotka eivät ole enää turvassa sellaisina kuin luulet niiden olevan… sinulla on aikataulut, jotka eivät toimi niin kuin ennen, sinulla on tietoja, jotka eivät ole enää suojattuja se on, ja sinulla voi olla jopa selittämättömiä virheitä tietyissä toiminnoissa et todellakaan voi laittaa sormeasi.
Syyt, miksi huonot ja rumat lähestymistavat voivat olla kauheita:
- Automaattinen nimitilan siirto rasittaa sisällönhallintaa. Sisältökaupan jokaisen objektin tarkastus ja mahdollinen päivitys voi usein johtaa kymmeniin tuhansiin SDK -puheluihin Cognosiin (käytännössä kaikki kulkevat sisällönhallinnan kautta). Tämä epänormaali kysely lisää tyypillisesti muistin käyttöä / kuormitusta ja vaarantaa sisällönhallinnan kaatumisen siirron aikana. Jos sinulla on jo jonkin verran epävakautta Cognos -ympäristössäsi, sinun pitäisi pelätä tätä lähestymistapaa.
- Nimitilan siirto vaatii suuren huoltoikkunan. Cognosin on oltava päällä, mutta et halua ihmisten tekevän muutoksia siirtoprosessin aikana. Tämä edellyttää tyypillisesti nimitilan siirtymisen aloittamista, kun kukaan muu ei työskentele, esimerkiksi perjantai -iltana kello 10. Kukaan ei halua aloittaa stressaavaa projektia perjantai -iltana kello 10. Puhumattakaan siitä, että henkiset kykysi eivät luultavasti ole parhaimmillaan työskentelemässä iltaisin ja viikonloppuisin projektissa ei vaatii sinua olemaan terävä!
- Olen maininnut, että nimitilamuutokset ovat aikaa ja työvoimaa vaativia. Tässä vähän lisää aiheesta:
- Sisällön kartoitusprosessi tulisi tehdä tarkasti, ja se vaatii tiimin yhteistyötä ja paljon työtunteja.
- Useita kuivia ajoja tarvitaan virheiden tai siirtoon liittyvien ongelmien tarkistamiseksi. Tyypillinen muutto ei mene täydellisesti ensimmäisellä yrityksellä. Tarvitset myös voimassa olevan varmuuskopion sisältökaupastasi, joka voidaan palauttaa tällaisissa tapauksissa. Olemme nähneet monia organisaatioita, joilla ei ole käytettävissä hyvää varmuuskopiota (tai joilla on varmuuskopio, jonka he eivät ymmärrä olevan puutteellinen).
- Sinun on tunnistettava kaikki ulkopuolella sisältökauppaan, johon se saattaa vaikuttaa (kehysmallit, muuntajamallit jne.). Tämä tehtävä voi sisältää koordinointia useiden ryhmien välillä (erityisesti suurissa jaetuissa BI -ympäristöissä).
- Tarvitset hyvän testisuunnitelman, joka sisältää edustavia ihmisiä, joilla on erilaiset käyttöoikeudet Cognos -sisältöösi. Tärkeintä tässä on tarkistaa pian siirron päätyttyä, että kaikki on siirretty ja toimii odotetulla tavalla. On yleensä epäkäytännöllistä tarkistaa kaikki, joten päädyt todentamaan, mitä toivot edustaviksi näytteiksi.
- Sinulla on oltava broad tietoa Cognos -ympäristöstä ja siitä riippuvista asioista. Esimerkiksi historialliset kuutiot, joissa on mukautetut näkymät, on rakennettava uudelleen, jos siirryt NSM -reitille.
- Entä jos sinä tai yritys, jonka ulkoistit nimitilan siirron, unohdat jotain, kuten… SDK -sovellukset? Kun olet kääntänyt kytkimen, nämä asiat lakkaavat toimimasta, jos niitä ei päivitetä oikein. Onko sinulla asianmukaiset tarkastukset havaitaksesi tämän välittömästi, vai kestääkö useita viikkoja / kuukausia ennen kuin oireet alkavat näkyä?
- Jos olet käynyt läpi useita Cognos -päivityksiä, sisältökaupassasi voi mahdollisesti olla epäjohdonmukaisia objekteja. Jos et käytä SDK: ta, et voi nähdä, mitkä objektit ovat tässä tilassa.
Miksi nimitilan korvaaminen on paras vaihtoehto
Äsken esittämäni tärkeimmät riskitekijät ja aikaa vievät vaiheet eliminoidaan, kun käytetään Persona Namespace Replacement -menetelmää. Käyttämällä nimitilan korvaamistapaa sinulla on 5 minuuttia Cognos -seisokkiaikaa, eikä sisältösi tarvitse muuttua. "Hyvä" menetelmä tuntuu minusta leikatulta ja kuivalta "ei-aivoilta". Perjantai -iltana on rentoutumista, ei stressiä siitä, että sisällönhallintasi kaatui juuri keskellä nimitilan siirtoa.
