Lorsque vous devez reconfigurer un environnement Cognos existant pour utiliser une autre source de sécurité externe (par exemple, Active Directory, LDAP, etc.), vous pouvez adopter plusieurs approches. J'aime les appeler "Le Bon, la Brute et le Truand". Avant d'explorer ces approches bonnes, mauvaises et laides, examinons quelques scénarios courants qui ont tendance à entraîner des modifications d'espace de noms d'authentification dans un environnement Cognos.
Facteurs commerciaux courants:
Mise à jour du matériel ou du système d'exploitation – La modernisation du matériel/de l'infrastructure BI peut être un moteur fréquent. Alors que le reste de Cognos peut fonctionner comme un champion sur votre nouveau matériel élégant et votre système d'exploitation 64 bits moderne, bonne chance pour la migration de votre version d'Access Manager vers 2005 vers cette nouvelle plate-forme. Access Manager (publié pour la première fois avec la série 7) est un vestige vénérable d'antan pour de nombreux clients de Cognos. C'est la seule raison pour laquelle de nombreux clients conservent cette vieille version grossière de Windows Server 2003. L'écriture a été sur le mur pour Access Manager pendant un certain temps. C'est un logiciel hérité. Plus tôt vous pourrez vous en éloigner, mieux ce sera.
Normalisation des applications– Les organisations qui souhaitent consolider l'authentification de toutes leurs applications par rapport à un serveur d'annuaire d'entreprise administré de manière centralisée (par exemple LDAP, AD).
Fusions et acquisitions– L'entreprise A achète l'entreprise B et a besoin que l'environnement Cognos de l'entreprise B pointe vers le serveur d'annuaire de l'entreprise A, sans causer de problèmes au contenu ou à la configuration BI existants.
Cessions d'entreprises– C'est le contraire du scénario de fusion, une partie d'une entreprise est scindée dans sa propre entité et doit maintenant pointer son environnement BI existant vers la nouvelle source de sécurité.
Pourquoi les migrations d'espaces de noms peuvent être compliquées
Pointer un environnement Cognos vers une nouvelle source de sécurité n'est pas aussi simple que d'ajouter le nouvel espace de noms avec les mêmes utilisateurs, groupes et rôles, déconnecter l'ancien espace de noms et VOILA ! - tous vos utilisateurs Cognos dans le nouvel espace de noms sont mis en correspondance avec leur contenu. En fait, vous pouvez souvent vous retrouver avec un désordre sanglant sur les mains, et voici pourquoi…
Tous les principaux de sécurité de Cognos (utilisateurs, groupes, rôles) sont référencés par un identifiant unique appelé CAMID. Même si tous les autres attributs sont égaux, le CAMID d'un utilisateur dans un existant l'espace de noms d'authentification ne sera pas le même que le CAMID pour cet utilisateur dans le neufs espace de noms. Cela peut faire des ravages dans un environnement Cognos existant. Même si vous n'avez que quelques utilisateurs de Cognos, vous devez savoir que les références CAMID existent à BEAUCOUP d'endroits différents dans votre Content Store (et peuvent même exister en dehors de votre Content Store dans les modèles Framework, Transformer Models, TM1 Applications, Cubes, Planning Applications, etc. ).
De nombreux clients de Cognos pensent à tort que CAMID n'a d'importance que pour le contenu de Mon dossier, les préférences des utilisateurs, etc. Cela ne pourrait pas être plus éloigné de la vérité. Ce n'est pas seulement une question de nombre d'utilisateurs que vous avez, c'est la quantité d'objets Cognos dont vous devez vous préoccuper. Il existe plus de 140 types d'objets Cognos différents uniquement dans le Content Store, dont beaucoup peuvent avoir plusieurs références CAMID.
Par exemple :
- Il n'est pas rare qu'un seul programme dans votre magasin de contenu ait plusieurs références CAMID (le CAMID du propriétaire du programme, le CAMID de l'utilisateur sous lequel le programme doit s'exécuter, le CAMID de chaque utilisateur ou liste de distribution à laquelle il doit envoyer par courrier électronique la sortie du rapport généré , etc.).
- Chaque objet de Cognos possède une politique de sécurité qui détermine quels utilisateurs peuvent accéder à l'objet (pensez à « Onglet Autorisations »). Une seule politique de sécurité suspendue à ce dossier dans Cognos Connection possède une référence CAMID pour chaque utilisateur, groupe et rôle spécifié dans cette politique.
- Espérons que vous comprenez le point - cette liste s'allonge encore et encore!
Il n'est pas rare qu'un magasin de contenu important contienne des dizaines de milliers de références CAMID (et nous en avons vu de grandes avec des centaines de milliers).
Maintenant, faites le calcul sur ce qu'il y a dans Un flux efficace peut augmenter l'environnement Cognos et vous pouvez voir que vous avez potentiellement affaire à des hordes de références CAMID. Cela peut être un cauchemar ! Le changement (ou la reconfiguration) de votre espace de noms d'authentification peut laisser toutes ces références CAMID dans un état insoluble. Cela conduit inévitablement à des problèmes de contenu et de configuration de Cognos (par exemple, des programmes qui ne s'exécutent plus, un contenu qui n'est plus sécurisé comme vous le pensez, des packages ou des cubes qui n'implémentent plus correctement la sécurité au niveau des données, la perte de contenu My Folder et préférences, etc.).
Méthodes de transition d'espace de noms Cognos
Maintenant, sachant qu'un environnement Cognos peut contenir des dizaines de milliers de références CAMID qui nécessiteront la recherche, le mappage et la mise à jour de leur nouvelle valeur CAMID correspondante dans le nouvel espace de noms d'authentification, discutons des approches Good, Bad & Ugly pour résoudre ce problème.
Le bon: Remplacement de l'espace de noms avec Persona
La première méthode (Namespace Replacement) utilise Motioest, QI personnel produit. En adoptant cette approche, votre espace de nom existant est « remplacé » par un espace de nom Persona spécial qui vous permet de virtualiser tous les principaux de sécurité exposés à Cognos. Les principaux de sécurité préexistants seront exposés à Cognos avec exactement le même CAMID qu'auparavant, même s'ils peuvent être soutenus par un certain nombre de sources de sécurité externes (par exemple, Active Directory, LDAP ou même la base de données Persona).
L'avantage de cette approche est qu'elle ne nécessite aucune modification de votre contenu Cognos. En effet, Persona peut conserver les CAMID des principaux préexistants, même lorsqu'ils sont soutenus par une nouvelle source. Alors… toutes ces dizaines de milliers de références CAMID dans votre Content Store, modèles externes et cubes historiques ? Ils peuvent rester exactement tels qu'ils sont. Il n'y a pas de travaux à prévoir.
Il s'agit de loin de l'approche la moins risquée et la moins impactante que vous puissiez utiliser pour faire passer votre environnement Cognos existant d'une source de sécurité externe à une autre. Cela peut être fait en moins d'une heure avec environ 5 minutes d'indisponibilité de Cognos (le seul temps d'arrêt de Cognos est le redémarrage de Cognos une fois que vous avez configuré l'espace de noms Persona).
Le mauvais: Migration d'espace de noms à l'aide de Persona
Si l'approche facile et à faible risque n'est tout simplement pas votre tasse de thé, alors il is une autre option.
Persona peut également être utilisé pour effectuer une migration d'espace de noms.
Cela implique l'installation d'un deuxième espace de noms d'authentification dans votre environnement Cognos, le mappage (espérons-le) de tous vos principaux de sécurité existants (de l'ancien espace de noms) aux principaux correspondants dans le nouvel espace de noms, puis (voici la partie amusante), la recherche, le mappage et la mise à jour de chaque référence CAMID unique qui existe dans votre environnement Cognos : votre Content Store, les modèles de framework, les modèles de transformateur, les cubes historiques, les applications TM1, les applications de planification, etc.
Cette approche a tendance à être stressante et exigeante en termes de processus, mais si vous êtes le genre d'administrateur Cognos qui a besoin d'un peu d'adrénaline pour se sentir vivant (et que cela ne dérange pas les appels téléphoniques tard le soir/tôt le matin), alors peut-être… this est l'option que vous recherchez ?
Persona peut être utilisé pour aider à automatiser des parties de ce processus. Cela vous aidera à créer un mappage entre les anciens principaux de sécurité et les nouveaux principaux de sécurité, à automatiser la logique de force brute « rechercher, analyser, mettre à jour » pour le contenu de votre magasin de contenu, etc. Ce que Persona peut automatiser certaines des tâches ici, beaucoup du travail dans cette approche implique « les personnes et les processus » plutôt que la technologie réelle.
Par exemple, compiler des informations sur chaque modèle Framework Manager, chaque modèle Transformer, chaque application Planning / TM1, chaque application SDK, qui les possède et planifier la manière dont ils seront mis à jour et redistribués peut représenter beaucoup de travail. La coordination des interruptions pour chacun des environnements Cognos dans lesquels vous souhaitez effectuer cette opération et des fenêtres de maintenance pendant lesquelles vous pouvez tenter la migration peut impliquer une planification et un « temps d'arrêt » Cognos. Élaborer (et exécuter) un plan de test efficace après votre migration peut également être un véritable casse-tête.
Il est également tout à fait normal que vous souhaitiez effectuer ce processus en premier dans un environnement de non-production before l'essayer en production.
Bien que la migration d'espace de noms avec Persona fonctionne (et c'est bien mieux que l'approche "laid" ci-dessous), elle est plus invasive, plus risquée, implique beaucoup plus de personnel et prend beaucoup plus d'heures de travail que le remplacement d'espace de noms. En règle générale, les migrations doivent être effectuées pendant les « heures creuses », alors que l'environnement Cognos est toujours en ligne, mais son utilisation est limitée par les utilisateurs finaux.
The Ugly: Services de migration manuelle d'espaces de noms
La méthode Ugly implique l'approche peu enviable d'essayer de manuellement migrer d'un espace de noms d'authentification à un autre. Cela implique de connecter un deuxième espace de noms d'authentification à votre environnement Cognos, puis d'essayer de déplacer ou de recréer manuellement une grande partie du contenu et de la configuration Cognos existants.
Par exemple, en utilisant cette approche, un administrateur Cognos peut tenter de :
- Recréez les groupes et les rôles dans le nouvel espace de noms
- Recréez les appartenances de ces groupes et rôles dans le nouvel espace de noms
- Copiez manuellement le contenu de mes dossiers, les préférences utilisateur, les onglets du portail, etc. de chaque compte source vers chaque compte cible
- Recherchez chaque ensemble de stratégies dans le Content Store et mettez-le à jour pour référencer les principaux équivalents dans le nouvel espace de noms de la même manière qu'il a référencé les principaux de l'ancien espace de noms
- Recréez toutes les planifications et remplissez-les avec les informations d'identification, les destinataires, etc.
- Réinitialiser toutes les propriétés « propriétaire » et « contact » de tous les objets dans le Content Store
- [Environ 40 autres choses dans le Content Store que vous allez oublier]
- Rassemblez tous les modèles FM avec une sécurité au niveau des objets ou des données :
- Mettez à jour chaque modèle en conséquence
- Republier chaque modèle
- Redistribuer le modèle modifié à l'auteur d'origine
- Travail similaire pour les modèles Transformer, les applications TM1 et les applications de planification qui sont sécurisées par rapport à l'espace de noms d'origine
- [et beaucoup plus]
Alors que certains masochistes de Cognos pourraient secrètement rire de joie à l'idée de cliquer 400,000 XNUMX fois dans Cognos Connection, pour la plupart des gens sensés, cette approche a tendance à être extrêmement fastidieuse, longue et sujette aux erreurs. Ce n'est pas le plus gros problème avec cette approche, cependant.
Le plus gros problème de cette approche est qu'elle toujours conduit à une migration incomplète.
En utilisant cette approche, vous trouvez (douloureux) et essayez de mapper les références CAMID que vous connaissez… mais avez tendance à laisser toutes ces références CAMID que vous ne sais pas.
Une fois que vous penser vous avez terminé avec cette approche, vous n'êtes souvent pas vraiment terminé.
Vous avez des objets dans votre magasin de contenu qui ne sont plus sécurisés comme vous le pensez… vous avez des planifications qui ne fonctionnent pas comme avant, vous avez des données qui ne sont plus sécurisées comme vous le pensez c'est le cas, et vous pouvez même avoir des erreurs inexpliquées pour certaines opérations qui tu ne peux pas vraiment mettre le doigt dessus.
Raisons pour lesquelles les approches mauvaises et laides peuvent être terribles :
- Les migrations automatisées d'espaces de noms mettent beaucoup de pression sur le gestionnaire de contenu. L'inspection et la mise à jour potentielle de chaque objet de votre Content Store peuvent souvent entraîner des dizaines de milliers d'appels SDK à Cognos (pratiquement tous transitent par Content Manager). Cette requête anormale augmente généralement l'utilisation/la charge de la mémoire et expose le gestionnaire de contenu à un risque de plantage pendant la migration. Si vous avez déjà une certaine instabilité dans votre environnement Cognos, vous devriez avoir très peur de cette approche.
- Les migrations d'espaces de noms nécessitent une fenêtre de maintenance importante. Cognos doit être opérationnel, mais vous ne voulez pas que des personnes effectuent des modifications pendant le processus de migration. Cela nécessitera généralement le démarrage de la migration de l'espace de noms lorsque personne d'autre ne travaille, disons à 10 heures un vendredi soir. Personne ne veut démarrer un projet stressant à 10 heures un vendredi soir. Sans oublier que vos facultés mentales ne sont probablement pas à leur meilleur en travaillant les nuits et les week-ends sur un projet qui vous oblige à être pointu!
- J'ai mentionné que les migrations d'espaces de noms demandent beaucoup de temps et de travail. Voici un peu plus à ce sujet:
- Le processus de mappage de contenu doit être effectué avec précision et nécessite une collaboration d'équipe et de nombreuses heures de travail.
- Plusieurs essais à sec sont nécessaires pour vérifier les erreurs ou les problèmes liés à une migration. Une migration typique ne se passe pas parfaitement du premier coup. Vous aurez également besoin d'une sauvegarde valide de votre Content Store qui peut être restaurée dans de tels cas. Nous avons vu de nombreuses organisations ne pas disposer d'une bonne sauvegarde (ou avoir une sauvegarde dont elles ne réalisent pas qu'elle est incomplète).
- Vous devez tout identifier au contrôle le Content Store qui peut être potentiellement impacté (modèles de framework, modèles de transformateur, etc.). Cette tâche peut impliquer une coordination entre plusieurs équipes (en particulier dans les grands environnements de BI partagés).
- Vous avez besoin d'un bon plan de test impliquant des personnes représentatives ayant divers degrés d'accès à votre contenu Cognos. La clé ici est de vérifier peu de temps après la fin de la migration que tout est entièrement migré et fonctionne comme prévu. Il est généralement peu pratique de tout vérifier, vous finissez donc par vérifier ce que vous espérez être des échantillons représentatifs.
- Vous devez avoir broad connaissance de l'environnement Cognos et des éléments qui en dépendent. Par exemple, les cubes historiques avec des vues personnalisées DOIVENT être reconstruits si vous suivez la route NSM.
- Que se passe-t-il si vous ou l'entreprise à laquelle vous avez sous-traité la migration de l'espace de noms oublie quelque chose, comme… les applications SDK ? Une fois que vous avez basculé le commutateur, ces éléments cessent de fonctionner s'ils ne sont pas mis à jour correctement. Avez-vous mis en place les contrôles appropriés pour le remarquer immédiatement, ou faudra-t-il plusieurs semaines/mois avant que les symptômes ne commencent à faire surface ?
- Si vous avez subi de nombreuses mises à niveau de Cognos, vous pouvez potentiellement avoir des objets dans votre Content Store qui sont dans un état incohérent. Si vous ne travaillez pas avec le SDK, vous ne pourrez pas voir quels objets sont dans cet état.
Pourquoi le remplacement d'espace de noms est la meilleure option
Les principaux facteurs de risque et les étapes chronophages que je viens de décrire sont éliminés lorsque la méthode de remplacement de l'espace de nom Persona est utilisée. En utilisant l'approche de remplacement d'espace de noms, vous disposez de 5 minutes d'indisponibilité de Cognos et aucun de vos contenus n'a besoin de changer. La méthode « bonne » me semble être une « évidence » tranchée. Les vendredis soirs sont faits pour se détendre, pas pour stresser sur le fait que votre gestionnaire de contenu vient de planter au milieu d'une migration d'espace de noms.
