Quando você precisa reconfigurar um ambiente Cognos existente para usar uma fonte de segurança externa diferente (por exemplo, Active Directory, LDAP, etc), existem várias abordagens que você pode adotar. Gosto de chamá-los de “Os bons, os maus e os feios”. Antes de explorarmos essas abordagens Good, Bad e Ugly, vamos dar uma olhada em alguns cenários comuns que tendem a conduzir mudanças de namespace de autenticação em um ambiente Cognos.
Motivadores de negócios comuns:
Atualizando Hardware ou SO - A modernização do hardware / infraestrutura de BI pode ser um fator frequente. Enquanto o resto do Cognos pode funcionar como um campeão em seu novo hardware e sistema operacional moderno de 64 bits, boa sorte ao migrar sua versão de aproximadamente 2005 do Access Manager para essa nova plataforma. O Access Manager (lançado pela primeira vez com a Série 7) é um venerável resquício de dias passados para muitos clientes Cognos. Essa é a única razão pela qual muitos clientes mantêm essa versão velha e malcriada do Windows Server 2003. O Access Manager está na parede há algum tempo. É um software legado. Quanto mais cedo você puder fazer a transição, melhor.
Padronização de aplicativos- Organizações que desejam consolidar a autenticação de todos os seus aplicativos em um servidor de diretório corporativo administrado centralmente (por exemplo, LDAP, AD).
Fusões e Aquisições- A Empresa A compra a Empresa B e precisa do ambiente Cognos da Empresa B para apontar para o servidor de diretório da Empresa A, sem causar problemas ao conteúdo ou configuração de BI existente.
Desinvestimentos Corporativos- Este é o oposto do cenário de fusão, uma parte de uma empresa é dividida em sua própria entidade e agora precisa apontar seu ambiente de BI existente para a nova fonte de segurança.
Por que as migrações de namespace podem ser complicadas
Apontar um ambiente Cognos para uma nova fonte de segurança não é tão simples quanto adicionar o novo namesapce com os mesmos usuários, grupos e funções, desconectar o namespace antigo e VOILA! - todos os seus usuários do Cognos no novo namespace são combinados com seu conteúdo. Na verdade, muitas vezes você pode acabar com uma bagunça sangrenta em suas mãos, e aqui está o porquê ...
Todos os principais de segurança do Cognos (usuários, grupos, funções) são referenciados por um identificador exclusivo chamado CAMID. Mesmo que todos os outros atributos sejam iguais, o CAMID para um usuário em um existente namespace de autenticação não será o mesmo que o CAMID para esse usuário no novo namespace. Isso pode causar estragos em um ambiente Cognos existente. Mesmo se você tiver apenas alguns usuários do Cognos, é necessário perceber que as referências CAMID existem em MUITOS lugares diferentes em seu Armazenamento de Conteúdo (e podem até mesmo existir fora de seu Armazenamento de Conteúdo em modelos de Estrutura, Modelos de Transformador, Aplicativos TM1, Cubos, Aplicativos de Planejamento, etc. )
Muitos clientes do Cognos acreditam erroneamente que o CAMID realmente importa apenas para o conteúdo da Minha pasta, preferências do usuário, etc. Isso não poderia estar mais longe da verdade. Não é apenas uma questão de número de usuários que você tem, é a quantidade de objetos Cognos com os quais você precisa se preocupar. Existem mais de 140 tipos diferentes de objetos Cognos apenas no armazenamento de conteúdo, muitos dos quais podem ter várias referências CAMID.
Por exemplo:
- Não é incomum que um único Agendamento em seu Armazenamento de Conteúdo tenha várias referências CAMID (o CAMID do proprietário do agendamento, o CAMID do usuário como o agendamento deve ser executado, o CAMID de cada usuário ou lista de distribuição que deve enviar por e-mail a saída do relatório gerado para , etc.).
- Cada objeto no Cognos tem uma política de segurança que rege quais usuários podem acessar o objeto (pense na “Guia Permissões”). Uma única política de segurança pendurada nessa pasta no Cognos Connection tem uma referência CAMID para cada usuário, grupo e função que é especificado nessa política.
- Espero que você tenha entendido - esta lista é infinita!
Não é incomum que um armazenamento de conteúdo de tamanho considerável contenha dezenas de milhares de referências CAMID (e vimos algumas grandes com centenas de milhares).
Agora, faça as contas sobre o que está dentro os Ambiente Cognos e você pode ver que está lidando potencialmente com hordas de referências CAMID. Pode ser um pesadelo! Alternar (ou reconfigurar) seu namespace de autenticação pode deixar todas essas referências CAMID em um estado insolúvel. Isso inevitavelmente leva a problemas de conteúdo e configuração do Cognos (por exemplo, cronogramas que não são mais executados, conteúdo que não está mais protegido da maneira que você pensa, pacotes ou cubos que não implementam mais a segurança de nível de dados corretamente, a perda do conteúdo de Minha pasta e do usuário preferências, etc.).
Métodos de transição de namespace Cognos
Agora, sabendo que um ambiente Cognos pode ter dezenas de milhares de referências CAMID que exigirão encontrar, mapear e atualizar seu novo valor CAMID correspondente no novo namespace de autenticação, vamos discutir as abordagens Good, Bad & Ugly para resolver esse problema.
O bom: Substituição de namespace com Persona
O primeiro método (substituição de namespace) utiliza Motioé, QI de personalidade produtos. Usando essa abordagem, seu namespace existente é “substituído” por um namespace Persona especial que permite virtualizar todos os principais de segurança expostos ao Cognos. Os principais de segurança pré-existentes serão expostos ao Cognos com o mesmo CAMID de antes, mesmo que eles possam ser apoiados por qualquer número de fontes de segurança externas (por exemplo, Active Directory, LDAP ou mesmo o banco de dados Persona).
A parte bonita dessa abordagem é que ela requer ZERO mudanças no conteúdo do Cognos. Isso ocorre porque Persona pode manter os CAMIDs de principais preexistentes, mesmo quando eles são apoiados por uma nova fonte. Então ... todas aquelas dezenas de milhares de referências CAMID em seu armazenamento de conteúdo, modelos externos e cubos históricos? Eles podem ficar exatamente como estão. Não há trabalho necessário.
Esta é de longe a abordagem menos arriscada e de menor impacto que você pode usar para fazer a transição de seu ambiente Cognos existente de uma fonte de segurança externa para outra. Isso pode ser feito em menos de uma hora com cerca de 5 minutos de tempo de inatividade do Cognos (o único tempo de inatividade do Cognos é reiniciar o Cognos depois de configurar o namespace Persona).
O mal: Migração de namespace usando Persona
Se a abordagem fácil e de baixo risco não for do seu agrado, então há is outra opção.
Persona também pode ser usado para executar uma migração de namespace.
Isso envolve a instalação de um segundo namespace de autenticação em seu ambiente Cognos, mapeando (esperançosamente) todos os seus principais de segurança existentes (do antigo namespace) para os principais correspondentes no novo namespace, então (aqui está a parte divertida), encontrando, mapeando e atualizando cada referência CAMID única que existe em seu ambiente Cognos: seu armazenamento de conteúdo, modelos de estrutura, modelos de transformador, cubos históricos, aplicativos TM1, aplicativos de planejamento, etc.
Essa abordagem tende a ser estressante e intensiva em processos, mas se você é o tipo de administrador do Cognos que precisa de um pouco de adrenalina para se sentir vivo (e não se importa com telefonemas de madrugada / madrugada), então talvez ... isto é a opção que você está procurando?
Persona pode ser usado para ajudar a automatizar partes desse processo. Isso o ajudará a criar um mapeamento entre os antigos princípios de segurança e os novos princípios de segurança, automatizar a lógica de "encontrar, analisar, atualizar" de força bruta para conteúdo em seu armazenamento de conteúdo, etc. Qual Persona pode automatizar algumas das tarefas aqui, muito do trabalho nesta abordagem envolve “pessoas e processos” em vez de tecnologia real.
Por exemplo - compilar informações sobre cada modelo do Framework Manager, cada modelo do Transformer, cada aplicativo Planning / TM1, cada aplicativo SDK, quem os possui e planejar como eles serão atualizados e redistribuídos pode ser muito trabalhoso. A coordenação de interrupções para cada um dos ambientes Cognos que você deseja tentar e as janelas de manutenção durante as quais você pode tentar a migração pode envolver planejamento e “tempo de inatividade” do Cognos. Criar (e executar) um plano de teste eficaz para depois da migração também pode ser muito difícil.
Também é normal que você queira fazer este processo primeiro em um ambiente de não produção antes tentando em produção.
Embora a Migração de Namespace com Persona funcione (e é muito melhor do que a abordagem “Feia” abaixo), é mais invasiva, mais arriscada, envolve muito mais pessoal e leva muito mais horas de trabalho para ser realizada do que a Substituição de Namespace. Normalmente, as migrações precisam ser feitas fora do horário de trabalho, enquanto o ambiente Cognos ainda está online, mas de forma restrita para uso por usuários finais.
The Ugly: Serviços manuais de migração de namespace
O método feio envolve a abordagem nada invejável de tentar manualmente migrar de um namespace de autenticação para outro. Isso envolve a conexão de um segundo namespace de autenticação ao ambiente do Cognos e, em seguida, a tentativa de mover ou recriar manualmente muito do conteúdo e configuração do Cognos existente.
Por exemplo, usando esta abordagem, um administrador Cognos pode tentar:
- Recrie os grupos e funções no novo namespace
- Recrie as associações desses grupos e funções no novo namespace
- Copie manualmente o conteúdo das minhas pastas, preferências do usuário, guias do portal, etc. de cada conta de origem para cada conta de destino
- Encontre cada conjunto de políticas no armazenamento de conteúdo e atualize-o para fazer referência a entidades equivalentes no novo namespace da mesma maneira que referia as entidades do antigo namespace
- Recrie todas as programações e preencha-as com as credenciais, destinatários, etc. correspondentes
- Redefinir todas as propriedades de "proprietário" e "contato" de todos os objetos no armazenamento de conteúdo
- [Cerca de 40 outras coisas no armazenamento de conteúdo que você vai esquecer]
- Reúna todos os modelos FM com segurança de nível de objeto ou dados:
- Atualize cada modelo de acordo
- Republicar cada modelo
- Redistribua o modelo modificado de volta ao autor original
- Trabalho semelhante para modelos de Transformer, TM1 Applications e Planning Applications que são protegidos contra o namespace original
- [e muitos mais]
Embora alguns masoquistas do Cognos possam secretamente rir de alegria com a ideia de clicar 400,000 vezes no Cognos Connection, para a maioria das pessoas sensatas, essa abordagem tende a ser extremamente tediosa, demorada e sujeita a erros. Esse não é o maior problema com essa abordagem, no entanto.
O maior problema com essa abordagem é que quase sempre leva a uma migração incompleta.
Usando esta abordagem, você (dolorosamente) encontra e tenta mapear as referências CAMID que você conhece ... mas tende a deixar todas as referências CAMID que você não sei sobre.
Uma vez que você think você acabou com essa abordagem, muitas vezes não clientes feito.
Você tem objetos em seu armazenamento de conteúdo que não estão mais protegidos da maneira que você pensa que estão ... você tem agendas que não estão funcionando da maneira que costumavam ser, você tem dados que não estão mais protegidos da maneira que você pensa é, e você pode até ter erros inexplicáveis para certas operações que você não pode realmente colocar o dedo.
Razões pelas quais as abordagens ruins e feias podem ser terríveis:
- As migrações automatizadas de namespace colocam muito estresse no Gerenciador de conteúdo. A inspeção e atualização potencial de cada objeto em seu armazenamento de conteúdo, muitas vezes pode resultar em dezenas de milhares de chamadas SDK para Cognos (virtualmente todas fluem através do Content Manager). Essa consulta anormal normalmente aumenta o uso / carga de memória e coloca o Content Manager em risco de travar durante a migração. Se você já tem alguma instabilidade em seu ambiente Cognos, deve ter muito medo dessa abordagem.
- As migrações de namespace exigem uma janela de manutenção considerável. O Cognos precisa estar ativo, mas você não quer que as pessoas façam alterações durante o processo de migração. Isso normalmente exigirá que a migração do namespace comece quando ninguém mais estiver trabalhando, digamos às 10h de uma sexta-feira à noite. Ninguém quer começar um projeto estressante às 10h de uma sexta-feira à noite. Sem mencionar que suas faculdades mentais provavelmente não estão em suas melhores noites de trabalho e fins de semana em um projeto que parece exigem que você seja afiado!
- Mencionei que as migrações de namespace exigem muito tempo e trabalho. Aqui está um pouco mais sobre isso:
- O processo de mapeamento de conteúdo deve ser feito com precisão e isso requer a colaboração da equipe e muitas horas de trabalho.
- Vários testes são necessários para verificar se há erros ou problemas com uma migração. Uma migração típica não ocorre perfeitamente na primeira tentativa. Você também precisará de um backup válido de seu armazenamento de conteúdo que pode ser restaurado em tais casos. Vimos muitas organizações que não têm um bom backup disponível (ou têm um backup que não percebem que está incompleto).
- Você precisa identificar tudo lado de fora o armazenamento de conteúdo que pode ser potencialmente impactado (modelos de framework, modelos de transformador, etc). Esta tarefa pode envolver coordenação entre várias equipes (particularmente em grandes ambientes de BI compartilhados).
- Você precisa de um bom plano de teste que envolva pessoas representativas com vários graus de acesso ao conteúdo do Cognos. A chave aqui é verificar, logo após a conclusão da migração, se tudo foi totalmente migrado e está funcionando conforme o esperado. Normalmente é impraticável verificar tudo, então você acaba verificando o que espera que sejam amostras representativas.
- Você deve ter broad conhecimento do ambiente Cognos e coisas que dependem dele. Por exemplo, cubos históricos com visualizações personalizadas TÊM que ser reconstruídos se você seguir a rota NSM.
- E se você ou a empresa que terceirizou a migração do namespace se esquecer de algo, como… aplicativos SDK? Depois de girar o botão, essas coisas param de funcionar se não forem atualizadas corretamente. Você tem as verificações adequadas para perceber isso imediatamente ou vai demorar várias semanas / meses antes que os sintomas comecem a aparecer?
- Se você passou por diversos upgrades do Cognos, é possível que haja objetos em seu armazenamento de conteúdo que estão em um estado inconsistente. Se você não trabalhar com o SDK, não poderá ver quais objetos estão neste estado.
Por que a substituição do namespace é a melhor opção
Os principais fatores de risco e etapas demoradas que acabei de descrever são eliminados quando o método Persona Namespace Replacement é usado. Usando a abordagem de substituição de namespace, você tem 5 minutos de tempo de inatividade do Cognos e nenhum conteúdo precisa ser alterado. O método “Bom” parece um “acéfalo” direto para mim. As noites de sexta-feira são para relaxar, sem se estressar com o fato de seu Gerenciador de conteúdo ter travado no meio de uma migração de namespace.
