As jo moatte opnij konfigurearje in besteande Cognos omjouwing foar in gebrûk in oare eksterne feiligens boarne (bgl. Active Directory, LDAP, etc), der binne in hantsjefol oanpakken kinne jo nimme. Ik neam se graach, "De goede, de minne en de lelijke." Foardat wy dizze goede, minne en ûnsjogge oanpak ûndersiikje, litte wy efkes sjen nei guon mienskiplike senario's dy't de neiging hawwe om feroaringen fan ferifikaasjenammeromte yn in Cognos-omjouwing oan te driuwen.
Common Business Drivers:
Hardware of OS bywurkje - Modernisearjen fan BI-hardware / ynfrastruktuer kin in faak bestjoerder wêze. Wylst de rest fan Cognos kin rinne as in kampioen op jo slanke nije hardware en moderne 64-bit OS, gelok migrearje jo circa-2005 ferzje fan Access Manager oer nei dat nije platfoarm. Access Manager (earst útbrocht mei Series 7) is in earbiedweardich holdover út dagen gien ferline foar in protte Cognos klanten. It is de iennichste reden dat in protte klanten om dy knappe âlde ferzje fan Windows Server 2003 hinne hâlde. It skriuwen is al in skoft op 'e muorre foar Access Manager. It is legacy software. Hoe earder jo derfan oergean kinne, hoe better.
Applikaasje Standerdisearring- Organisaasjes dy't de autentikaasje fan al har applikaasjes konsolidearje wolle tsjin ien sintraal bestjoerde bedriuwsmaptsjinner (bgl. LDAP, AD).
Fúzjes en oanwinsten– Bedriuw A keapet Bedriuw B en hat de Cognos-omjouwing fan Bedriuw B nedich om te wizen op de triemtafeltsjinner fan Bedriuw A, sûnder problemen te meitsjen mei har besteande BI-ynhâld of konfiguraasje.
Corporate ôfsettings- Dit is it tsjinoerstelde fan it fúzjescenario, in diel fan in bedriuw wurdt ôfspûn yn in eigen entiteit en moat no de besteande BI-omjouwing wize op de nije befeiligingsboarne.
Wêrom nammeromtemigraasjes rommelich kinne wêze
It wizen fan in Cognos-omjouwing nei in nije befeiligingsboarne is net sa ienfâldich as it tafoegjen fan de nije nammenapce mei deselde brûkers, groepen en rollen, de âlde nammeromte losmeitsje, en VOILA!- al jo Cognos-brûkers yn 'e nije nammeromte binne oerienkomme mei harren ynhâld. Yn feite kinne jo faaks einigje mei in bloedige puinhoop op jo hannen, en hjir is de reden ...
Alle Cognos-befeiligingsprinsipes (brûkers, groepen, rollen) wurde ferwiisd troch in unike identifier neamd in CAMID. Sels as alle oare attributen binne gelyk, de CAMID foar in brûker yn in besteande autentikaasje nammeromte sil net wêze itselde as de CAMID foar dy brûker yn de nij nammeromte. Dit kin ferneatigje op in besteande Cognos-omjouwing. Sels as jo mar in pear Cognos-brûkers hawwe, moatte jo realisearje dat CAMID-ferwizings besteane op MANGE ferskillende plakken yn jo ynhâldwinkel (en kinne sels bûten jo ynhâldwinkel bestean yn frameworkmodellen, transformatormodellen, TM1-applikaasjes, kubes, planningapplikaasjes ensfh. ).
In protte Cognos-klanten leauwe fersin dat CAMID's eins allinich saak meitsje foar My Folder-ynhâld, brûkersfoarkar, ensfh. Dit koe net fierder fan 'e wierheid wêze. It is net allinich in kwestje fan it oantal brûkers dat jo hawwe, it is it oantal Cognos-objekten wêrmei jo moatte dwaande hâlde. D'r binne mear dan 140 ferskillende soarten Cognos-objekten gewoan yn 'e Content Store, wêrfan in protte meardere CAMID-referinsjes kinne hawwe.
Bygelyks:
- It is net ûngewoan dat ien skema yn jo ynhâldwinkel meardere CAMID-referinsjes hat (de CAMID fan 'e eigner fan' e skema, de CAMID fan 'e brûker as it skema moat rinne, de CAMID fan elke brûker of distribúsjelist dy't it generearre rapportútfier moat e-post stjoere nei , ensfh.).
- Elk objekt yn Cognos hat in befeiligingsbelied dat regelet hokker brûkers tagong kinne ta it objekt (tink "Tapassingen Tab"). In inkeld befeiligingsbelied dat fan dy map hinget yn Cognos Connection hat in CAMID-referinsje foar elke brûker, groep en rol dy't yn dat belied oanjûn is.
- Hooplik krije jo it punt - dizze list giet troch en troch!
It is net ûngewoan dat in grutte ynhâldwinkel tsientûzenen CAMID-referinsjes befettet (en wy hawwe guon grutte sjoen mei hûnderttûzenen).
No, meitsje de wiskunde oer wat der yn is dyn Cognos-omjouwing en jo kinne sjen dat jo potensjeel te krijen hawwe mei horden CAMID-referinsjes. It kin in nachtmerje wêze! It wikseljen (of opnij konfigurearje) fan jo autentikaasjenammeromte kin al dizze CAMID-referinsjes yn in ûnoplosbere steat litte. Dit liedt ûnûntkomber ta Cognos-ynhâld- en konfiguraasjeproblemen (bgl foarkarren, ensfh.).
Cognos Namespace Transition Methods
No, wittende dat in Cognos-omjouwing tsientûzenen CAMID-referinsjes kin hawwe dy't it finen, yn kaart bringen en bywurkje nei har korrespondearjende nije CAMID-wearde yn 'e nije autentikaasjenammeromte, litte wy de goede, minne en ûnsjogge oanpak besprekke foar it oplossen fan dit probleem.
The Good: Namespace Ferfanging mei Persona
De earste metoade (Namespace Replacement) brûkt Motio's, Persoan IQ produkt. Troch dizze oanpak te nimmen, wurdt jo besteande nammeromte "ferfongen" mei in spesjale Persona nammeromte wêrmei jo alle feiligensprinsipes virtualisearje kinne dy't bleatsteld binne oan Cognos. Foarôf besteande befeiligingsprinsipes sille wurde bleatsteld oan Cognos mei krekt deselde CAMID as earder, ek al kinne se wurde stipe troch in oantal eksterne feiligens boarnen (bgl. Active Directory, LDAP of sels de Persona databank).
It prachtige diel fan dizze oanpak is dat it NUL feroarings fereasket oan jo Cognos-ynhâld. Dit is om't Persona de CAMID's fan foarôf besteande haadpersoanen kin ûnderhâlde, sels as se wurde stipe troch in nije boarne. Dus ... al dy tsientûzenen CAMID-referinsjes yn jo Content Store, eksterne modellen en histoaryske kubussen? Se kinne krekt bliuwe sa't se binne. Der is gjin wurk nedich.
Dit is fierwei de minst risikofolle oanpak mei leechste ynfloed dy't jo kinne brûke foar it oersetten fan jo besteande Cognos-omjouwing fan de iene eksterne feiligensboarne nei de oare. It kin dien wurde yn minder dan in oere mei sawat 5 minuten Cognos-downtime (de ienige Cognos-downtime is it opnij starte fan Cognos as jo de Persona-nammeromte hawwe ynsteld).
The Bad: Namespace Migraasje mei Persona
As de maklike oanpak mei leech risiko gewoan net jo kopke tee is, dan is der is in oare opsje.
Persona kin ek brûkt wurde om in nammeromte-migraasje út te fieren.
Dit omfettet it ynstallearjen fan in twadde autentikaasjenammeromte yn jo Cognos-omjouwing, it yn kaart bringen (hooplik) al jo besteande befeiligingsprinsipes (fan 'e âlde nammeromte) nei korrespondearjende haadpersoanen yn' e nije nammeromte, dan (hjir is it leuke diel), elk fine, yn kaart bringe en bywurkje. ienige CAMID-referinsje dy't bestiet yn jo Cognos-omjouwing: jo ynhâldwinkel, ramtmodellen, transformatormodellen, histoaryske kubes, TM1-applikaasjes, planningapplikaasjes, ensfh.
Dizze oanpak hat de neiging om stress te wêzen en proses-yntinsyf te wêzen, mar as jo it soarte fan Cognos-behearder binne dy't in bytsje adrenaline-kick nedich hat om libben te fielen (en it net slim makket fan 'e lette nacht / iere moarns tillefoantsjes), dan miskien ... dit is de opsje wêr't jo nei sykje?
Persona kin brûkt wurde om dielen fan dit proses te automatisearjen. It sil jo helpe om in mapping te meitsjen tusken de âlde feiligensprinsipes en de nije feiligensprinsipes, automatisearje de brute krêft "fine, analysearje, update" logika foar ynhâld yn jo ynhâldwinkel, ensfh. Wat Persona kin guon fan 'e taken hjir automatisearje, folle fan it wurk yn dizze oanpak giet it om "minsken en proses" ynstee fan eigentlike technology.
Bygelyks - it kompilearjen fan ynformaasje oer elk Framework Manager-model, elk Transformer-model, elke Planning / TM1-applikaasje, elke SDK-applikaasje, wa't se hat, en plannen hoe't se sille wurde bywurke en ferdield kin in soad wurk wêze. Koördinearjen fan ûnderbrekkingen foar elk fan 'e Cognos-omjouwings wêryn jo dit wolle besykje en ûnderhâldsfinsters wêryn't jo de migraasje kinne besykje kinne plannen en Cognos "down time" belûke. Mei (en útfiere) in effektyf testplan foar nei jo migraasje kin ek in bear wêze.
It is ek hiel normaal dat jo dit proses earst wolle dwaan yn in net-produksje omjouwing foar besykje it yn produksje.
Wylst Namespace-migraasje mei Persona wurket (en it is folle better dan de "Ugly" oanpak hjirûnder), is it mear invasive, riskanter, omfettet folle mear personiel, en duorret folle mear manoeren om út te fieren dan Namespace-ferfanging. Typysk moatte migraasjes dien wurde yn "off oeren", wylst de Cognos-omjouwing noch online is, mar beheind formulier gebrûk troch ein brûkers.
The Ugly: Hânlieding Namespace Migration Services
De Ugly metoade giet it om de unenviable oanpak fan besykjen om hân migrearje fan de iene autentikaasjenammeromte nei de oare. Dit omfettet it ferbinen fan in twadde autentikaasjenammeromte oan jo Cognos-omjouwing, en besykje dan in protte fan 'e besteande Cognos-ynhâld en -konfiguraasje mei de hân te ferpleatsen of opnij oan te meitsjen.
Bygelyks, mei dizze oanpak, kin in Cognos-behearder besykje om:
- Meitsje de groepen en rollen opnij yn 'e nije nammeromte
- Meitsje de lidmaatskippen fan dy groepen en rollen opnij yn 'e nije nammeromte
- Kopiearje de ynhâld fan myn mappen, brûkersfoarkarren, portalljeppers, ensfh. fan elke boarne akkount nei elk doelaccount
- Fyn elke beliedsset yn 'e ynhâldwinkel en fernij it om lykweardige haadpersoanen yn 'e nije nammeromte te ferwizen op krekt deselde manier as it ferwiisde nei haadpersoanen út 'e âlde nammeromte
- Meitsje alle skema's opnij en folje se mei oerienkommende referinsjes, ûntfangers, ensfh.
- Reset alle "eigner" en "kontakt" eigenskippen fan alle objekten yn de ynhâld Store
- [Sawat 40 oare dingen yn 'e Content Store dy't jo sille ferjitte]
- Sammelje alle FM-modellen mei befeiliging fan objekt of gegevensnivo:
- Update elk model neffens
- Republisearje elk model
- Ferwiderje it feroare model werom nei de orizjinele auteur
- Fergelykber wurk foar transformatormodellen, TM1-applikaasjes en planningapplikaasjes dy't befeilige binne tsjin de orizjinele nammeromte
- [en folle mear]
Wylst guon Cognos-masochisten temûk kinne giggelje fan blydskip oer it idee om 400,000 kear te klikken yn Cognos Connection, foar de measte ferstannige minsken, hat dizze oanpak de neiging om ekstreem ferfeelsum, tiidslinend en flatersoan te wêzen. Dat is lykwols net it grutste probleem mei dizze oanpak.
It grutste probleem mei dizze oanpak is dat it hast altyd liedt ta in ûnfolsleine migraasje.
Mei dizze oanpak fine jo (pynlik) dy CAMID-referinsjes wêrfan jo witte, en besykje jo dizze CAMID-referinsjes yn kaart te bringen ... wit net oer.
Once you tinke do bist klear mei dizze oanpak, do bist faaks net werklik dien.
Jo hawwe objekten yn jo ynhâldwinkel dy't net mear befeilige binne lykas jo tinke dat se binne ... jo hawwe skema's dy't net rinne sa't se eartiids rinne, jo hawwe gegevens dy't net mear befeilige binne lykas jo tinke it is, en jo kinne sels hawwe ûnferklearbere flaters foar bepaalde operaasjes dy't jo kinne net echt sette dyn finger op.
Redenen wêrom't de minne en ûnsjogge oanpak ferskriklik kin wêze:
- Automatisearre nammeromtemigraasjes sette in soad stress op 'e Content Manager. De ynspeksje en potinsjele fernijing fan elk inkeld objekt yn jo Content Store, kin faak resultearje yn tsientûzenen SDK-oproppen nei Cognos (dy't praktysk allegear troch de Content Manager streame). Dizze abnormale querying spikes typysk ûnthâldgebrûk / laden en set de Content Manager op it risiko fan crashe tidens de migraasje. As jo al in soad ynstabiliteit hawwe yn jo Cognos-omjouwing, moatte jo tige bang wêze foar dizze oanpak.
- Nammeromtemigraasjes fereaskje in grut ûnderhâldsfinster. Cognos moat op, mar jo wolle net dat minsken wizigingen meitsje tidens it migraasjeproses. Dit sil typysk fereaskje dat de nammeromtemigraasje begjint as gjinien oars wurket, lit ús sizze om 10 oere op in freedtejûn. Nimmen wol om 10 oere op in freedtejûn mei in stressfolle projekt begjinne. Net te ferjitten, jo geastlike fakulteiten binne nei alle gedachten net op harren bêste wurkje nachten en wykeinen op in projekt dat docht fereaskje dat jo skerp binne!
- Ik haw neamd Namespace Migraasjes binne tiid en arbeidsintensyf. Hjir is wat mear oer dat:
- It ynhâldmappingproses moat mei presys dien wurde en dat freget teamgearwurking en in protte manoeren.
- Meardere droege runen binne nedich om te kontrolearjen op flaters of problemen mei in migraasje. In typyske migraasje giet net perfekt by de earste poging. Jo sille ek in jildige reservekopy fan jo Content Store nedich wêze dy't yn sokke gefallen kin wurde hersteld. Wy hawwe in protte organisaasjes sjoen dy't gjin goede reservekopy beskikber hawwe (of in reservekopy hawwe dy't se net realisearje dat it net kompleet is).
- Jo moatte alles identifisearje bûten de ynhâldwinkel dy't mooglik beynfloede wurde kin (ramtmodellen, transformatormodellen, ensfh.). Dizze taak kin koördinaasje omfetsje oer meardere teams (benammen yn grutte dielde BI-omjouwings).
- Jo hawwe in goed testplan nedich dat represintative minsken omfettet mei ferskate graden fan tagong ta jo Cognos-ynhâld. De kaai hjir is om koart nei't de migraasje foltôge te kontrolearjen dat alles folslein migrearre is en funksjonearret lykas jo ferwachtsje. It is typysk ûnpraktysk om alles te ferifiearjen, dus jo ferifiearje úteinlik wat jo hoopje represintative samples binne.
- Jo moatte broad kennis fan 'e Cognos-omjouwing en dingen dy't derfan ôfhingje. Bygelyks, histoaryske kubussen mei oanpaste werjeften MOET wurde ferboud as jo de NSM-rûte gean.
- Wat as jo of it bedriuw dat jo de nammeromtemigraasje hawwe útbestege om wat te ferjitten, lykas ... SDK-applikaasjes? As jo ienris de skeakel omdraaid hawwe, stopje dizze dingen mei wurkjen as se net goed binne bywurke. Hawwe jo de juste kontrôles yn plak om dit fuortendaliks op te merken, of sil it ferskate wiken / moannen duorje foardat de symptomen begjinne te ferskinen?
- As jo in protte Cognos-upgrades hawwe ûndergien, kinne jo mooglik objekten hawwe yn jo Content Store dy't yn in inkonsistente steat binne. As jo net wurkje mei de SDK, do silst net by steat wêze om te sjen hokker objekten binne yn dizze steat.
Wêrom nammeromteferfanging de bêste opsje is
De wichtichste risikofaktoaren en tiidslinend stappen dy't ik krekt sketste wurde elimineare as de metoade foar ferfanging fan Persona Namespace wurdt brûkt. Mei help fan de Namespace Replacement-oanpak, hawwe jo 5 minuten Cognos-downtime, en net ien fan jo ynhâld hoecht te feroarjen. De "Goeie" metoade liket my in snie en droech "no-brainer". Freedtejûnen binne om te ûntspannen, net te stressjen oer it feit dat jo Content Manager krekt yn 'e midden fan in Namespace-migraasje ferûngelokke is.
