Regras de reconciliação

  • Versão de lançamento: Xanadu
  • Atualizado 1 de ago. de 2024
  • 5 min. de leitura
  • As regras de reconciliação determinam quais origens de descoberta podem atualizar atributos de IC.

    Origens de descoberta como EventManagement, ImportSet, ManualEntry e Tivoli, são usadas com a API createOrUpdateCI() para simular atualizações manuais aos ICs. Sem regras de reconciliação, as origens de descoberta podem substituir as atualizações umas das outras nos valores de atributo.

    Existem dois tipos de regras de reconciliação:
    Regras de reconciliação estática

    Regras de reconciliação estática são as regras de reconciliação legadas que definem prioridades para as várias origens de descoberta a fim de atualizar atributos de IC. As regras de reconciliação estática especificam quais origens de descoberta podem atualizar atributos de classe e a ordem de precedência entre essas origens de descoberta.

    Ao criar regras de reconciliação estática, verifique se há uma regra de reconciliação para cada origem de descoberta que está autorizada a atualizar um atributo. As regras de reconciliação podem ser definidas no âmbito da classe primária e secundária.

    As regras de reconciliação estática são armazenadas na tabela Definição de reconciliação [cmdb_reconciliation_definition].

    Regras de reconciliação dinâmica

    As regras de reconciliação dinâmica são baseadas em valores de atributo processados por CMDB 360 / CMDB de várias origens em vez de na prioridade de origem da descoberta. Primeiro, o CMDB 360 processa os dados de carga atual no armazenamento de dados do CMDB 360. Em seguida, aplicando uma regra de reconciliação dinâmica, o IRE seleciona o maior valor ou o valor relatado, por exemplo, em todas as origens de descoberta. Como as regras de reconciliação dinâmica aproveitam o CMDB 360, você deve habilitar esse recurso para usar regras de reconciliação dinâmica.

    Criar regras de reconciliação dinâmicas pode ser útil, por exemplo, se tornar difícil definir a ordem de prioridade para várias origens de descoberta. Só pode haver uma regra de reconciliação dinâmica por atributo de classe.

    As regras de reconciliação dinâmica são armazenadas na tabela Definições de reconciliação dinâmica [cmdb_dynamic_reconciliation_definition].

    Exemplos de regras de reconciliação estática

    Os exemplos de regras de reconciliação estática a seguir são criados para a classe cmdb_ci_computer e sua classe secundária cmdb_ci_linux_server:
    1. A Descoberta está autorizada exclusivamente a atualizar o atributo name na classe cmdb_ci_computer.

      Como as regras de reconciliação são derivadas por classes secundárias de classes primárias, essa regra também autoriza a Descoberta a atualizar o atributo name em qualquer classe secundária da classe cmdb_ci_computer.

    2. O ServiceWatch está exclusivamente autorizado a atualizar o atributo name da classe cmdb_ci_linux_server.
    3. O ServiceWatch está autorizado exclusivamente a atualizar todos os atributos da classe cmdb_ci_linux_server, conforme configurado ao deixar o campo Atributos vazio na regra.

    Confira Criar uma regra de reconciliação de IC para obter detalhes sobre como criar uma regra de reconciliação estática que, por exemplo, autoriza uma origem de descoberta a atualizar um atributo específico, como name.

    Como usar regras de reconciliação

    Ao criar regras de reconciliação, tenha em mente os seguintes princípios, que foram projetados para oferecer flexibilidade e refinamento de regras no nível de atributos:

    Precedência das regras de reconciliação dinâmica

    Quando existem regras de reconciliação estática e dinâmica para o mesmo atributo de IC, a regra de reconciliação dinâmica tem precedência sobre a regra de reconciliação estática.

    Autorização para todos os atributos de uma classe

    Uma regra de reconciliação estática permite que você autorize uma origem de descoberta a atualizar todos os atributos em uma classe. No entanto, esta autorização pode ser substituída para alguns dos atributos por regras de classes secundárias nas quais atributos específicos estão listados.

    Por exemplo, se apenas as regras de exemplo nº 1 e nº 3 acima forem criadas, a Descoberta estará autorizada a atualizar o atributo name da classe cmdb_ci_linux_server. O ServiceWatch está autorizado a atualizar todos os outros atributos da classe, exceto o atributo name.

    Para substituir a autorização da Descoberta a fim de atualizar o atributo name, a regra de exemplo nº 2 acima é adicionada para autorizar especificamente o ServiceWatch a atualizar o atributo.

    Autorização apenas para atributos específicos de uma classe

    Para autorizar uma origem de descoberta a atualizar atributos específicos em uma classe, crie uma regra de reconciliação estática para a origem de descoberta e liste esses atributos na regra. Uma regra que concede acesso a atributos específicos em uma classe substitui outras regras de reconciliação estática com uma lista de atributos vazia que concede acesso a toda a classe.

    O exemplo de regra nº 1 acima concede à Descoberta autoridade exclusiva para atualizar o atributo name da classe cmdb_ci_computer. Todas as outras origens de descoberta são impedidas de atualizar o atributo name de qualquer IC da classe cmdb_ci_computer.

    As regras da classe secundária substituem as regras da classe primária

    Quaisquer regras de reconciliação definidas para uma classe secundária substituem as regras definidas para a respectiva classe primária. Esta regra também se aplica quando a regra de reconciliação da classe secundária é estática e a regra da classe primária é dinâmica (as regras de reconciliação dinâmica têm precedência sobre as regras de reconciliação estáticas quando são para uma classe do mesmo nível).

    Por exemplo, a regra nº 1 acima permite que a Descoberta atualize o atributo name da classe cmdb_ci_computer e todas as respectivas classes secundárias. No entanto, a regra nº 2 da classe secundária cmdb_ci_linux_server, que substitui a regra nº 1 da classe primária, autoriza explicitamente o ServiceWatch a atualizar este atributo na classe secundária.

    Como resultado:
    • A Descoberta não pode atualizar o atributo name da classe secundária cmdb_ci_linux_server. Somente o ServiceWatch está autorizado a atualizar este atributo.
    • A Descoberta está autorizada a atualizar o atributo name de registros de IC em todas as outras classes secundárias da classe cmdb_ci_computer.
    Sobreposição das regras de reconciliação estática

    Regras de reconciliação estática que autorizam diferentes origens de descoberta para os mesmos atributos da mesma classe podem coexistir e não se excluir.

    Por exemplo, suponha que a regra a seguir seja adicionada. É semelhante à regra de exemplo nº 1 acima, mas autoriza uma origem de descoberta diferente:

    O ServiceWatch está autorizado a atualizar o atributo name da classe cmdb_ci_computer.

    Como a regra de exemplo nº 1 acima, esta nova regra se aplica ao atributo name na classe cmdb_ci_computer para que a Descoberta e o ServiceWatch possam atualizar o atributo. Todas as regras de reconciliação são aplicadas para impedir que as origens de descoberta substituam as atualizações umas das outras.

    Para obter mais informações sobre regras de reconciliação, consulte o artigo da base de conhecimento [CMDB - Regras de precedência de dados] Noções básicas sobre as regras de precedência de dados do CMDB e solução de problemas [KB0756709] (A partir da versão Paris, as regras de reconciliação e de precedência de dados são mescladas.

    Separação de Domínio

    Se a Separação de domínios estiver habilitada, você poderá definir o escopo das regras de reconciliação para domínios específicos. As regras do domínio primário, se não forem substituídas, se aplicam aos ICs do domínio secundário. Todas as regras visíveis a um domínio são aplicadas e uma regra que substitui o domínio primário exibe a versão do domínio secundário.

    Noções básicas sobre as regras de reconciliação do CMDB e solução de problemas [KB0756709]