As u 'n bestaande Cognos -omgewing moet herkonfigureer na 'n ander eksterne veiligheidsbron (bv. Active Directory, LDAP, ens.), Is daar 'n handjievol benaderings. Ek noem hulle graag "Die goeie, die slegte en die lelike." Voordat ons hierdie goeie, slegte en lelike benaderings ondersoek, kyk ons na 'n paar algemene scenario's wat geneig is om die naamruimteveranderings in 'n Cognos -omgewing te veroorsaak.
Algemene sakebestuurders:
Opdatering van hardeware of bedryfstelsel - Die modernisering van BI -hardeware/infrastruktuur kan 'n gereelde bestuurder wees. Terwyl die res van Cognos soos 'n kampioen kan loop op u slanke nuwe hardeware en moderne 64-bis-bedryfstelsel, moet u u circa 2005-weergawe van Access Manager na die nuwe platform oorplaas. Access Manager (vir die eerste keer vrygestel met Series 7) is 'n eerbiedwaardige oorblyfsel uit die verlede vir baie Cognos -kliënte. Dit is die enigste rede waarom baie kliënte die ou ou weergawe van Windows Server 2003 bybly. Die skrywe is al geruime tyd op die muur vir Access Manager. Dit is 'n ou sagteware. Hoe gouer u daarvan kan weggaan, hoe beter.
Standaardisering van toepassings- Organisasies wat die verifikasie van al hul toepassings wil konsolideer teen een sentraal bestuurde korporatiewe gidsbediener (bv. LDAP, AD).
Samesmeltings en verkrygings- Maatskappy A koop Maatskappy B en benodig die Cognos -omgewing van Maatskappy B om na die gidsbediener van Maatskappy A te verwys, sonder om probleme met hul bestaande BI -inhoud of konfigurasie te veroorsaak.
Korporatiewe afskeidings- Dit is die teenoorgestelde van die samesmeltingscenario; 'n gedeelte van 'n onderneming word in sy eie entiteit verdeel en moet nou die bestaande BI -omgewing op die nuwe veiligheidsbron wys.
Waarom naamruimte -migrasies rommelig kan wees
Dit is nie so eenvoudig om 'n Cognos-omgewing na 'n nuwe veiligheidsbron te verwys nie, soos om die nuwe naamadres by dieselfde gebruikers, groepe en rolle te voeg, die ou naamruimte en VOILA te ontkoppel!- al u Cognos-gebruikers in die nuwe naamruimte pas by hul inhoud. Trouens, u kan dikwels 'n bloedige gemors op u hande beland, en hier is die rede waarom ...
Alle Cognos -sekuriteitshoofde (gebruikers, groepe, rolle) word verwys deur 'n unieke identifiseerder, 'n CAMID genoem. Selfs as al die ander eienskappe gelyk is, is die CAMID vir 'n gebruiker in 'n bestaande verifikasie naamruimte sal nie dieselfde wees as die CAMID vir die gebruiker in die nuwe naamruimte. Dit kan verwoesting in 'n bestaande Cognos -omgewing verwoes. Selfs as u slegs 'n paar Cognos -gebruikers het, moet u besef dat CAMID -verwysings op BAIE verskillende plekke in u Content Store bestaan (en selfs buite u Content Store kan bestaan in raamwerkmodelle, transformatormodelle, TM1 -toepassings, kubusse, beplanningstoepassings, ens. ).
Baie Cognos -kliënte glo verkeerdelik dat CAMID eintlik net vir My Folder -inhoud, gebruikersvoorkeure, ens. Saak maak. Dit kan nie verder van die waarheid wees nie. Dit is nie net 'n kwessie van die aantal gebruikers wat u het nie, dit is die hoeveelheid Cognos -voorwerpe waaroor u u moet bekommer. Daar is meer as 140 verskillende soorte Cognos -voorwerpe in die Content Store, waarvan baie verskeie CAMID -verwysings kan hê.
Byvoorbeeld:
- Dit is nie ongewoon dat 'n enkele skedule in u inhoudwinkel meer CAMID -verwysings bevat nie (die CAMID van die skedule -eienaar, die CAMID van die gebruiker wat die skedule moet uitvoer, die CAMID van elke gebruiker of verspreidingslys waarna dit die gegenereerde verslaguitsending moet e -pos na , ens.).
- Elke voorwerp in Cognos het 'n veiligheidsbeleid wat bepaal watter gebruikers toegang tot die voorwerp kan kry (dink aan die blad "Toestemmings"). 'N Enkele sekuriteitsbeleid wat van daardie vouer in Cognos Connection hang, het 'n CAMID -verwysing vir elke gebruiker, groep en rol wat in daardie beleid gespesifiseer word.
- Hopelik begryp u die punt - hierdie lys gaan aan en aan!
Dit is nie ongewoon dat 'n aansienlike inhoudswinkel tienduisende CAMID -verwysings bevat nie (en ons het 'n paar groot met honderde duisende gesien).
Doen nou die wiskunde oor wat daarin is jou Cognos -omgewing en u kan sien dat u moontlik te doen het met hordes CAMID -verwysings. Dit kan 'n nagmerrie wees! As u van u verifikasie-naamruimte verander (of herkonfigureer), kan al hierdie CAMID-verwysings in 'n onoplosbare toestand bly. Dit lei onvermydelik tot probleme met die inhoud en konfigurasie van Cognos (bv. Skedules wat nie meer loop nie, inhoud wat nie meer beveilig is soos u dink nie, pakkette of kubusse wat nie meer die beveiliging van datavlak korrek implementeer nie, die verlies van My Folder -inhoud en gebruikers voorkeure, ens.).
Metodes vir oorgang van Cognos -naamruimte
Aangesien ons weet dat 'n Cognos -omgewing tienduisende CAMID -verwysings kan hê wat nodig is om die ooreenstemmende nuwe CAMID -waarde in die nuwe verifikasie -naamruimte te vind, in kaart te bring en by te werk, bespreek ons die goeie, slegte en lelike benaderings om hierdie probleem op te los.
Die Goeie: Naamruimte vervang met Persona
Die eerste metode (naamruimtevervanging) word gebruik Motiose, Persoonlike IK produk. As u hierdie benadering volg, word u bestaande naamruimte 'vervang' met 'n spesiale Persona -naamruimte waarmee u alle sekuriteitshoofde wat aan Cognos blootgestel word, kan virtualiseer. Bestaande sekuriteitshoofde sal blootgestel word aan Cognos met presies dieselfde CAMID as voorheen, alhoewel hulle deur 'n aantal eksterne sekuriteitsbronne ondersteun kan word (bv. Active Directory, LDAP of selfs die Persona-databasis).
Die mooi deel van hierdie benadering is dat dit NUL veranderings aan u Cognos -inhoud vereis. Dit is omdat Persona die CAMID's van bestaande skoolhoofde kan onderhou, selfs as hulle deur 'n nuwe bron ondersteun word. Dus ... al die tienduisende CAMID -verwysings in u Content Store, eksterne modelle en historiese kubusse? Hulle kan presies bly soos hulle is. Daar is geen werk nodig nie.
Dit is verreweg die minste riskante benadering met die laagste impak wat u kan gebruik om u bestaande Cognos -omgewing van een eksterne bron na 'n ander oor te skakel. Dit kan binne minder as 'n uur gedoen word met ongeveer 5 minute se stilstand van Cognos (die enigste stilstand van Cognos is om Cognos weer te begin nadat u die Persona -naamruimte opgestel het).
Die Bad: Migrasie in die naamruimte met behulp van Persona
As die maklike, lae-risiko-benadering net nie u koppie tee is nie, dan is daar is 'n ander opsie.
Persona kan ook gebruik word om 'n naamruimte -migrasie uit te voer.
Dit behels die installering van 'n tweede verifikasie -naamruimte in u Cognos -omgewing, al u bestaande sekuriteitshoofde (hopelik) in kaart te bring (ooreenstemmend met die hoofruimte in die nuwe naamruimte), en dan (hier is die prettige deel), om alle bestaande sekuriteitshoofde (van die ou naamruimte) toe te karteer en by te werk. enkele CAMID -verwysing wat in u Cognos -omgewing bestaan: u Content Store, raamwerkmodelle, transformatormodelle, historiese kubusse, TM1 -toepassings, beplanningstoepassings, ens.
Hierdie benadering is geneig om stresvol en prosesintensief te wees, maar as u die soort Cognos -administrateur is wat 'n bietjie adrenalien -haas nodig het om lewendig te voel (en nie omgee vir laatnag / vroeë oggendoproepe nie), dan miskien ... hierdie is die opsie waarna u soek?
Persona kan gebruik word om gedeeltes van hierdie proses te outomatiseer. Dit sal u help om 'n kartering te maak tussen die ou sekuriteitshoofde en die nuwe sekuriteitshoofde, die outomatiese logika "vind, ontleed, opdateer" outomaties vir inhoud in u inhoudswinkel, ens. Wat kan Persona sommige van die take hier outomatiseer? van die werk in hierdie benadering behels "mense en proses" eerder as werklike tegnologie.
Byvoorbeeld, die opstel van inligting oor elke Framework Manager -model, elke Transformer -model, elke Planning / TM1 -toepassing, elke SDK -toepassing, wie dit besit, en die beplanning van hoe dit bygewerk en herverdeel kan word, kan baie werk wees. Koordinering van onderbrekings vir elk van die Cognos -omgewings waarin u dit wil probeer, en instandhoudingsvensters waartydens u kan migreer, kan beplanning en 'stilstand' van Cognos insluit. Om 'n effektiewe toetsplan vir na u migrasie op te stel (en uit te voer) kan ook nogal 'n beer wees.
Dit is ook heel normaal dat u hierdie proses eers in 'n nie-produksie-omgewing wil doen voor probeer dit in produksie.
Alhoewel Namespace Migration with Persona wel werk (en dit is baie beter as die 'lelike' benadering hieronder), is dit meer indringend, riskanter, behels veel meer personeel en neem dit baie meer ure om dit uit te voer as om Namespace Replacement te vervang. Gewoonlik moet migrasies gedurende 'af -ure' gedoen word, terwyl die Cognos -omgewing nog steeds aanlyn is, maar die gebruik van die eindgebruikers beperk word.
Die lelike: Handmatige naamruimte -migrasiedienste
Die lelike metode behels die benydenswaardige benadering om te probeer hand van die een verifikasie -naamruimte na die ander migreer. Dit behels dat u 'n tweede verifikasie -naamruimte aan u Cognos -omgewing koppel, en dan probeer om baie van die bestaande Cognos -inhoud en -konfigurasie handmatig te skuif of te herskep.
Deur hierdie benadering te gebruik, kan 'n Cognos -administrateur byvoorbeeld probeer om:
- Herskep die groepe en rolle in die nuwe naamruimte
- Herskep die lidmaatskap van die groepe en rolle in die nuwe naamruimte
- Kopieer die inhoud van my dopgehou, gebruikersvoorkeure, portaal -oortjies, ens. Van elke bronrekening na elke doelrekening
- Soek elke beleidstel in die inhoudswinkel en werk dit op om na ekwivalente skoolhoofde in die nuwe naamruimte te verwys, presies op dieselfde manier as waarna dit verwys na hoofde uit die ou naamruimte
- Herskep al die skedules en vul dit met ooreenstemmende geloofsbriewe, ontvangers, ens.
- Stel al die 'eienaar' en 'kontak' -eienskappe van alle voorwerpe in die inhoudswinkel terug
- [Ongeveer 40 ander dinge in die Content Store waaroor u gaan vergeet]
- Versamel al die FM -modelle met objek- of data -vlak sekuriteit:
- Werk elke model dienooreenkomstig op
- Publiseer elke model weer
- Herverdeel die gewysigde model terug na die oorspronklike outeur
- Soortgelyke werk vir transformatormodelle, TM1 -toepassings en beplanningstoepassings wat teen die oorspronklike naamruimte beveilig is
- [en nog vele meer]
Terwyl sommige Cognos -masochiste heimlik van blydskap giggel oor die idee om 400,000 XNUMX keer in Cognos Connection te klik, is die benadering vir die meeste verstandige mense uiters vervelig, tydrowend en geneig tot foute. Dit is egter nie die grootste probleem met hierdie benadering nie.
Die grootste probleem met hierdie benadering is dat dit amper altyd lei tot 'n onvolledige migrasie.
Deur hierdie benadering te gebruik, vind en probeer u (pynlik) die CAMID -verwysings waarvan u weet, in kaart bring, maar is geneig om al die CAMID -verwysings wat u weet nie van nie.
Sodra jy dink as u klaar is met hierdie benadering, is u dit dikwels nie werklik gedoen.
U het voorwerpe in u inhoudswinkel wat nie meer beveilig is soos u dink nie ... dit is, en u kan selfs onverklaarbare foute hê vir sekere bewerkings wat jy kan nie regtig jou vinger aansit nie.
Redes waarom die slegte en lelike benaderings vreeslik kan wees:
- Geautomatiseerde naamruimte -migrasies plaas baie spanning op die inhoudsbestuurder. Die inspeksie en moontlike opdatering van elke enkele voorwerp in u Content Store kan dikwels lei tot tienduisende SDK -oproepe na Cognos (wat feitlik almal deur die inhoudsbestuurder vloei). Hierdie abnormale navraag verhoog gewoonlik die gebruik / laai van geheue en stel die inhoudsbestuurder in gevaar om tydens die migrasie ineen te stort. As u reeds 'n mate van onstabiliteit in u Cognos -omgewing het, moet u baie bang wees vir hierdie benadering.
- Naamruimte -migrasies benodig 'n aansienlike instandhoudingsvenster. Cognos moet aan die gang wees, maar u wil nie hê dat mense veranderinge aanbring tydens die migrasieproses nie. Dit vereis gewoonlik dat die naamruimte -migrasie moet begin as niemand anders werk nie, laat ons om 10:10 op 'n Vrydagaand sê. Niemand wil 'n stresvolle projek om XNUMX:XNUMX op 'n Vrydagaand begin nie. Om nie te praat nie, u geestesvermoëns is waarskynlik nie op hul beste werksaande en naweke op 'n projek wat nie vereis dat jy skerp is!
- Ek het genoem dat naamruimte -migrasies tyd- en arbeidsintensief is. Hier is 'n bietjie meer daaroor:
- Die inhoudskaartproses moet met akkuraatheid gedoen word, en dit verg spanwerk en baie manure.
- Dit is nodig om verskeie drooglopies te ondersoek om te kyk of daar foute of probleme met 'n migrasie is. 'N Tipiese migrasie loop nie perfek in die eerste poging nie. U benodig ook 'n geldige rugsteun van u Content Store wat in sulke gevalle herstel kan word. Ons het baie organisasies gesien wat nie 'n goeie rugsteun beskikbaar het nie (of 'n rugsteun het wat hulle nie besef onvolledig is nie).
- U moet alles identifiseer buite die inhoudswinkel wat moontlik geraak kan word (raamwerkmodelle, transformatormodelle, ens.). Hierdie taak kan koördinering tussen verskeie spanne behels (veral in groot gedeelde BI -omgewings).
- U benodig 'n goeie toetsplan wat verteenwoordigende mense met verskillende toegang tot u Cognos -inhoud behels. Die sleutel hier is om kort nadat die migrasie voltooi is, te verifieer dat alles volledig gemigreer is en werk soos u verwag. Dit is gewoonlik onprakties om alles te verifieer, sodat u uiteindelik kan verifieer dat dit verteenwoordigende voorbeelde is.
- Jy moet broad kennis van die Cognos -omgewing en dinge wat daarvan afhang. Byvoorbeeld, historiese kubusse met pasgemaakte aansigte MOET herbou word as u die NSM -roete volg.
- Wat as u of die onderneming wat u die naamruimte -migrasie uitgekontrakteer het om iets te vergeet, soos… SDK -toepassings? As u die skakelaar omgedraai het, werk hierdie dinge op as dit nie behoorlik bygewerk is nie. Het u die nodige ondersoeke om dit onmiddellik op te let, of sal dit 'n paar weke / maande duur voordat die simptome verskyn?
- As u talle Cognos -opgraderings ondergaan het, kan u moontlik objekte in u Content Store in 'n inkonsekwente toestand hê. As u nie met die SDK werk nie, kan u nie sien watter voorwerpe in hierdie toestand is nie.
Waarom die vervanging van naamruimte die beste opsie is
Die belangrikste risikofaktore en tydrowende stappe wat ek so pas uiteengesit het, word uitgeskakel wanneer die Persona Namespace Replacement -metode gebruik word. As u die Namespace Replacement -benadering gebruik, het u 5 minute stilstand by Cognos, en niks van u inhoud hoef te verander nie. Die "goeie" metode lyk vir my na 'n sny en droë "no-brainer". Vrydagaande is 'n ontspanningsplek, nie om die spanning te beklemtoon oor die feit dat u inhoudsbestuurder net in die middel van 'n naamruimte -migrasie neergestort het nie.
