Quan necessiteu reconfigurar un entorn de Cognos existent per utilitzar una font de seguretat externa diferent (per exemple, Active Directory, LDAP, etc.), hi ha un grapat d'aproximacions que podeu adoptar. M'agrada anomenar-los: "El bo, el dolent i el lleig". Abans d’explorar aquests enfocaments bons, dolents i lletjos, donem un cop d’ull a alguns escenaris habituals que tendeixen a impulsar els canvis d’espai de noms d’autenticació en un entorn Cognos.
Controladors comercials comuns:
Actualització de maquinari o sistema operatiu - La modernització del maquinari / infraestructura de BI pot ser un controlador freqüent. Tot i que la resta de Cognos pot funcionar com un campió en el vostre nou i elegant sistema operatiu de 64 bits modern, sorteu la migració de la vostra versió del 2005 d’Access Manager cap a aquesta nova plataforma. Access Manager (llançat per primera vegada amb la sèrie 7) és una venerable reserva dels dies passats per a molts clients de Cognos. És l'única raó per la qual molts clients mantenen aquesta cruel versió antiga de Windows Server 2003. L'escriptura ha estat a la paret per a Access Manager des de fa força temps. És un programari heretat. Com més aviat pugueu fer la transició, millor.
Normalització de l'aplicació- Organitzacions que vulguin consolidar l'autenticació de totes les seves aplicacions amb un servidor de directori corporatiu administrat de forma centralitzada (per exemple, LDAP, AD).
Fusions i adquisicions- L’empresa A compra l’empresa B i necessita l’entorn Cognos de l’empresa B per apuntar al servidor de directoris de l’empresa A, sense causar problemes al seu contingut o configuració de BI existents.
Desinversions corporatives- Això és el contrari de l'escenari de fusió, una part d'una empresa es separa en la seva pròpia entitat i ara ha d'assenyalar el seu entorn de BI existent a la nova font de seguretat.
Per què les migracions d'espais de noms poden ser desordenades
Assenyalar un entorn Cognos cap a una nova font de seguretat no és tan senzill com afegir el nou namesapce amb els mateixos usuaris, grups i funcions, desconnectar l’antic espai de noms i VOILA. el seu contingut. De fet, sovint podeu acabar amb un embolic sanguinolent a les mans, i aquí teniu per què ...
Tots els principis de seguretat de Cognos (usuaris, grups, rols) tenen referència a un identificador únic anomenat CAMID. Fins i tot si la resta d’atributs són iguals, el CAMID per a un usuari d’un fitxer existent l'espai de noms d'autenticació no serà el mateix que el CAMID per a aquest usuari a nou espai de noms. Això pot destrossar un entorn Cognos existent. Fins i tot si només teniu uns quants usuaris de Cognos, heu d’adonar-vos que les referències CAMID existeixen a MOLTS llocs diferents del vostre Content Store (i fins i tot poden existir fora del Content Store en models Framework, models de transformadors, aplicacions TM1, cubs, aplicacions de planificació, etc.) ).
Molts clients de Cognos creuen erròniament que CAMID només importa el contingut de La meva carpeta, les preferències de l'usuari, etc. Això no podria estar més lluny de la veritat. No és només una qüestió del nombre d’usuaris que teniu, sinó de la quantitat d’objectes Cognos que us han de preocupar. Hi ha més de 140 tipus diferents d’objectes Cognos al Content Store, molts dels quals poden tenir diverses referències CAMID.
Per exemple:
- No és estrany que una única programació del vostre magatzem de contingut tingui diverses referències CAMID (el CAMID del propietari de la programació, el CAMID de l’usuari al qual s’ha d’executar la programació, el CAMID de cada usuari o la llista de distribució a la qual hauria de generar l’informe generat per correu electrònic. , etc.).
- Tots els objectes de Cognos tenen una política de seguretat que regula quins usuaris poden accedir a l'objecte (penseu a la "pestanya Permisos"). Una única política de seguretat que penja aquesta carpeta al Cognos Connection té una referència CAMID per a cada usuari, grup i funció que s’especifica en aquesta política.
- Esperem que entengueu el punt: aquesta llista continua i continua.
No és estrany que una gran botiga de contingut contingui desenes de milers de referències CAMID (i n’hem vist algunes de grans amb centenars de milers).
Ara, feu el càlcul del que hi ha seva Cognos amb l’entorn i podeu veure que potencialment teniu problemes amb hordes de referències CAMID. Pot ser un malson! Canviar (o tornar a configurar) l’espai de noms d’autenticació pot deixar totes aquestes referències CAMID en un estat irresoluble. Això condueix inevitablement a problemes de configuració i contingut de Cognos (p. Ex., Programacions que ja no s’executen, contingut que ja no està protegit tal com creieu que és, paquets o cubs que ja no implementen correctament la seguretat del nivell de dades, la pèrdua de contingut i usuari de La meva carpeta preferències, etc.).
Mètodes de transició d’espai de noms Cognos
Ara, sabent que un entorn Cognos pot tenir desenes de milers de referències CAMID que requeriran trobar, mapear i actualitzar al seu nou valor CAMID corresponent al nou espai de noms d’autenticació, analitzem els enfocaments Bons, dolents i lletjos per resoldre aquest problema.
El bo: Substitució de l'espai de noms per Persona
Es fa servir el primer mètode (substitució de l'espai de noms) Motio's, QI de Persona producte. Amb aquest enfocament, el vostre espai de noms existent es "reemplaça" per un espai de noms Persona especial que us permet virtualitzar tots els principis de seguretat exposats a Cognos. Els principis de seguretat preexistents estaran exposats a Cognos amb el mateix CAMID que abans, tot i que poden estar recolzats per qualsevol nombre de fonts de seguretat externes (per exemple, Active Directory, LDAP o fins i tot la base de dades Persona).
La part més bella d’aquest enfocament és que requereix ZERO canvis al vostre contingut de Cognos. Això es deu al fet que Persona pot mantenir els CAMID dels principis preexistents, fins i tot quan estan recolzats per una font nova. Llavors ... totes aquestes desenes de milers de referències CAMID al vostre Content Store, models externs i cubs històrics? Poden romandre exactament com són. No cal treballar.
Aquest és, amb diferència, l'enfocament de menys impacte i de menor risc que podeu utilitzar per fer la transició del vostre entorn Cognos existent d'una font de seguretat externa a una altra. Es pot fer en menys d'una hora amb uns 5 minuts de temps d'inactivitat de Cognos (l'únic temps d'inactivitat de Cognos és reiniciar Cognos un cop hàgiu configurat l'espai de noms Persona).
el dolent: Migració de l'espai de noms mitjançant Persona
Si l’enfocament fàcil i de baix risc no és la vostra tassa de te, llavors hi ha is una altra opció.
Persona també es pot utilitzar per realitzar una migració d'espai de noms.
Això implica instal·lar un segon espai de noms d’autenticació al vostre entorn Cognos, assignar (amb sort) tots els principals de seguretat existents (des de l’antic espai de noms) als principals corresponents al nou espai de noms i, a continuació (aquí teniu la part divertida), cercar, assignar i actualitzar única referència CAMID que existeix al vostre entorn Cognos: el vostre magatzem de contingut, models de marcs, models de transformadors, cubs històrics, aplicacions TM1, aplicacions de planificació, etc.
Aquest enfocament sol ser estressant i intensiu en processos, però si sou el tipus d’administrador de Cognos que necessita una mica d’adrenalina per sentir-se viu (i no li importen les trucades telefòniques a altes hores de la nit o al matí), potser ... aquest és l'opció que busqueu?
Es pot utilitzar Persona per ajudar a automatitzar parts d’aquest procés. Us ajudarà a crear un mapatge entre els principis de seguretat antics i els nous principis de seguretat, automatitzarà la lògica de força bruta "cercar, analitzar, actualitzar" el contingut del vostre magatzem de contingut, etc. Què Persona pot automatitzar algunes de les tasques aquí, molt del treball en aquest enfocament implica "persones i processos" en lloc de tecnologia real.
Per exemple: recopilar informació sobre cada model de Framework Manager, cada model de Transformer, totes les aplicacions de Planning / TM1, totes les aplicacions de l’SDK, qui en té les propietats i planificar com s’actualitzaran i es redistribuiran pot ser molt útil. La coordinació de les interrupcions de cadascun dels entorns de Cognos en què vulgueu provar-ho i les finestres de manteniment durant les quals podeu provar la migració pot implicar la planificació i el "temps d'inactivitat" de Cognos. Aconseguir (i executar) un pla de prova eficaç per després de la vostra migració també pot ser molt útil.
També és bastant normal que vulgueu fer aquest procés primer en un entorn que no sigui de producció abans provant-ho en producció.
Tot i que la Migració d’espais de noms amb Persona funciona (i és molt millor que l’enfocament “lleig” que es mostra a continuació), és més invasiva, més arriscada, implica molt més personal i triga molt més hores d’home a fer que la substitució de l’espai de noms. Normalment, les migracions s'han de fer durant les "hores de descans", mentre que l'entorn de Cognos continua en línia, però l'ús del formulari està restringit pels usuaris finals.
The Ugly: Serveis manuals de migració d'espais de noms
El mètode lleig implica l’enfocament poc envejable d’intentar-ho manualment migrar d'un espai de noms d'autenticació a un altre. Això implica connectar un segon espai de noms d’autenticació al vostre entorn Cognos i després intentar moure o recrear manualment gran part del contingut i la configuració existents del Cognos.
Per exemple, mitjançant aquest enfocament, un administrador de Cognos pot intentar:
- Recreeu els grups i les funcions al nou espai de noms
- Recreeu els membres d'aquests grups i rols al nou espai de noms
- Copieu manualment el contingut de les meves carpetes, les preferències de l'usuari, les pestanyes del portal, etc. de cada compte d'origen a cada compte de destinació
- Cerqueu tots els conjunts de polítiques al magatzem de contingut i actualitzeu-los per fer referència als principals equivalents al nou espai de noms de la mateixa manera que feia referència als principals de l’antic espai de noms.
- Recreeu tots els horaris i empleneu-los amb la credencial corresponent, els destinataris, etc.
- Restableix totes les propietats del propietari i del contacte de tots els objectes de la botiga de contingut
- [Al voltant de 40 coses més a la botiga de contingut que oblidareu]
- Reuneix tots els models FM amb seguretat a nivell d'objectes o dades:
- Actualitzeu cada model en conseqüència
- Torneu a publicar cada model
- Torneu a distribuir el model modificat a l'autor original
- Treballs similars per als models Transformer, les aplicacions TM1 i les aplicacions de planificació que estan protegides contra l’espai de noms original
- [i molts més]
Tot i que alguns masoquistes de Cognos podrien riure d’alegria amb la idea de fer clic 400,000 vegades a Cognos Connection, per a la majoria de gent sensata, aquest enfocament tendeix a ser extremadament tediós, lent i propens als errors. Aquest no és el problema més gran d’aquest enfocament.
El problema més gran d’aquest enfocament és que gairebé sempre condueix a una migració incompleta.
Utilitzant aquest enfocament, (dolorosament) trobareu i provareu de mapar aquelles referències CAMID que coneixeu ... però acostumeu a deixar totes aquestes referències CAMID que no ho sé.
Quan pensar heu acabat amb aquest enfocament, sovint no realment fet.
Teniu objectes a la vostra botiga de contingut que ja no estan protegits tal com creieu que teniu ... teniu programacions que no funcionen de la mateixa manera que teníeu abans, teniu dades que ja no estan protegides de la vostra manera de pensar és així, i fins i tot podeu tenir errors inexplicables per a determinades operacions que realment no es pot posar el dit.
Motius pels quals els enfocaments dolents i lletjos poden ser terribles:
- Les migracions automàtiques d’espais de noms posen molt d’accent al Gestor de continguts. La inspecció i l’actualització potencial de tots els objectes del vostre magatzem de contingut sovint poden provocar desenes de milers de trucades de l’SDK a Cognos (pràcticament totes flueixen a través del gestor de continguts). Aquesta consulta anormal sol augmentar l'ús / la càrrega de la memòria i posa el gestor de contingut en risc de bloquejar-se durant la migració. Si ja teniu una certa inestabilitat al vostre entorn Cognos, hauríeu de tenir molta por d’aquest enfocament.
- Les migracions d’espais de noms requereixen una finestra de manteniment considerable. Cognos ha d’estar activat, però no voleu que la gent faci canvis durant el procés de migració. Normalment, caldrà que comenci la migració de l'espai de noms quan ningú més no treballi, diguem-ne a les 10:10 del divendres a la nit. Ningú vol iniciar un projecte estressant a les XNUMX hores del divendres a la nit. Per no parlar, les vostres facultats mentals probablement no estiguin en les millors nits i caps de setmana laborables en un projecte que fa requereixen que siguis agut!
- He esmentat que les migracions d’espais de noms requereixen molt de temps i mà d’obra. Aquí hi ha una mica més sobre això:
- El procés de mapatge de contingut s’ha de fer amb precisió i això requereix col·laboració en equip i moltes hores laborals.
- Es requereixen diverses sèries per comprovar si hi ha errors o problemes amb una migració. Una migració típica no va perfectament al primer intent. També necessitareu una còpia de seguretat vàlida del vostre Content Store que es pugui restaurar en aquests casos. Hem vist moltes organitzacions que no tenen una bona còpia de seguretat disponible (o que tenen una còpia de seguretat que no saben que és incompleta).
- Cal identificar-ho tot fora el magatzem de contingut que es pot veure afectat (models de marcs, models de transformadors, etc.). Aquesta tasca pot implicar la coordinació entre diversos equips (especialment en entorns de BI compartits grans).
- Necessiteu un bon pla de proves que impliqui persones representatives amb diferents graus d’accés al vostre contingut de Cognos. La clau aquí és verificar poc després de completar la migració que tot es migri completament i funcioni tal com espereu. Normalment no és pràctic verificar-ho tot, de manera que acabareu verificant allò que espereu que siguin mostres representatives.
- Heu de tenir broad coneixement de l’entorn Cognos i coses que en depenen. Per exemple, s’han de reconstruir cubs històrics amb vistes personalitzades si aneu per la ruta NSM.
- Què passa si vosaltres o l’empresa que heu subcontractat la migració de l’espai de noms per oblidar alguna cosa, com ara ... les aplicacions SDK? Un cop heu activat el commutador, aquestes coses deixen de funcionar si no s’actualitzen correctament. Teniu els controls adequats per notar-ho immediatament o passaran diverses setmanes / mesos abans que els símptomes comencin a aparèixer?
- Si heu sofert nombroses actualitzacions de Cognos, podeu tenir objectes al vostre magatzem de contingut que estiguin en un estat inconsistent. Si no treballeu amb l'SDK, no podreu veure quins objectes es troben en aquest estat.
Per què la substitució de l'espai de noms és la millor opció
Els factors de risc clau i els passos que consumeixen molt de temps que acabo d’esbossar s’eliminen quan s’utilitza el mètode de substitució de l’espai de noms de Persona. Mitjançant l’enfocament de substitució de l’espai de noms, teniu 5 minuts de temps d’inactivitat de Cognos i cap contingut ha de canviar. El mètode "bo" em sembla un "no-brainer" tallat i sec. Les nits de divendres són per relaxar-se, sense preocupar-se del fet que el gestor de contingut s’ha estavellat enmig d’una migració d’espais de noms.
