Como Entender Transações Remotas do Distributed Data Manager


Visão Geral

Exemplos

Incluído com

Administração do Tivoli Problem Management

Visão Geral

Como entender transações remotas

Uma transação para um site remoto é concluída com êxito, quando todos os computadores, softwares e redes relacionadas ao Tivoli Problem Management em sua empresa estiverem operando corretamente. Uma transação pode ser uma transferência de problema para um site remoto, conexão de uma chamada a um problema em um site remoto, exibição de todas as informações atuais sobre um problema em um site remoto e assim por diante. Para obter mais informações sobre os tipos de transação remotas, consulte o tópico de auxílio apropriado.

O Distributed Data Manager completa as transações para sites remotos da seguinte maneira:

  1. O Site A compacta os dados e os envia para o Site B.
  2. O Site B descompacta os dados de transações.
  3. O Site B envia um aviso de confirmação da transação concluída para o Site A. Este aviso de confirmação pode representar uma transação bem-sucedida ou falha para o Site B.
  4. O Site A executa tarefas adicionais baseadas no sucesso ou na falha da transação remota.

As transações para os sites remotos são executadas pelos servidores de aplicativos do Distributed Data Manager em sua empresa, utilizando as tabelas de controle. As tabelas de controle são registros de bancos de dados que contêm os dados requeridos para iniciar e processar transações para sites remotos, conforme mostrado na tabela a seguir.

Tabela de Controle Descrição
REMOTE_WORK Cada registro armazena os dados específicos requeridos para executar uma transação remota particular. Um registro REMOTE_WORK é semelhante a um registro PROBLEM_CLOSURE do Tivoli Problem Management.
REMOTE_TASKS Um registro que é criado para cada site, onde uma transação REMOTE_WORK particular deve ser executada.
LOCAL_WORK Um registro que é criado pelo site remoto quando ele inicia a transação remota. Quando a transação remota é concluída, o site local é notificado. Se o site local não puder ser notificado por algum motivo, o registro LOCAL_WORK será utilizado para notificar o site local em um período posterior.

Exemplos

Transação bem-sucedida

Uma transação para um site remoto é bem-sucedida quando ocorre o seguinte:
  1. Um analista no Site A inicia uma transação para o Site B.
  2. O servidor de aplicativos do Site A compacta e envia a transação para o servidor de aplicativos do Site B.
  3. O servidor de aplicativos do Site B descompacta a transação e executa o trabalho associado.
  4. O servidor de aplicativos do Site B envia um aviso de confirmação para o servidor de aplicativos do Site A.
  5. O servidor de aplicativos do Site A remove o registro REMOTE_TASKS.
Transação pendente Uma transação para um site remoto fica pendente (PEND) quando ocorre o seguinte:
  1. Um analista no Site A inicia uma transação para o Site B.
  2. O servidor de aplicativos do Site A compacta a transação e a envia para o servidor de aplicativos do Site B.
  3. O servidor de aplicativos do Site B descompacta a transação e executa o trabalho associado.
  4. O servidor de aplicativos do Site B não consegue enviar um aviso de confirmação para o servidor de aplicativos do Site B.
  5. O servidor de aplicativos do Site A rotula o registro REMOTE_TASKS como pendente.
    Um problema de rede, do servidor de aplicativos ou do banco de dados no Site B pode resultar em uma transação pendente.
  6. O site do Site B repete periodicamente o envio de um aviso de confirmação contido no registro LOCAL_WORK para o servidor de aplicativos do Site A. Quando o servidor de aplicativos no Site B pode enviar um aviso de confirmação, a transação é concluída pelo servidor de aplicativos do Site A.

Transação falha 1

Uma transação para um site remoto falha quando ocorre o seguinte:
  1. Um analista no Site A inicia uma transação para o Site B.
  2. O servidor de aplicativos do Site A compacta a transação e não consegue enviá-la para o servidor de aplicativos do Site B ou o servidor de aplicativos do Site B não consegue receber a transação.
    Um problema de rede ou um servidor de aplicativos encerrado ou suspenso no Site B pode provocar falha de uma transação.
  3. O servidor de aplicativos do Site A rotula o registro REMOTE_TASKS como falho.
  4. O servidor de aplicativos do Site A repete periodicamente o envio da transação. A exceção para isso será se o Distributed Data Manager no Site A for configurado automaticamente para cancelar as transferências de problemas falhos para sites remotos.

Transação falha 2

As transações para sites remotos também podem falhar no nível do banco de dados, quando ocorrer o seguinte:
  1. Um analista no Site A inicia uma transação para o Site B.
  2. O servidor de aplicativos do Site A compacta e envia a transação para o servidor de aplicativos do Site B.
  3. O servidor de aplicativos do Site B descompacta a transação, mas não consegue executar o trabalho associado ao nível do banco de dados.
  4. O servidor de aplicativos do Site B envia um aviso de confirmação para o servidor de aplicativos do site do Site A que a transação falhou.