Sobre a Amostra Rotina de Tratamento de Erro

A amostra Rotina de Tratamento de Erro é baseada em um cenário no qual uma empresa envolvida no processamento de transações deseja desenvolver uma rotina para o tratamento de erros. A amostra demonstra como utilizar alguns dos recursos fornecidos no WebSphere Message Broker.

Empresas como bancos precisam certificar-se de que as transações sejam processadas uma vez e apenas uma vez e de que haja registro de todos os erros. Na amostra Rotina de Tratamento de Erro, você coloca mensagens sobre números de equipes através de um fluxo de mensagens que atualiza um banco de dados com essas informações. Ao colocar uma mensagem com um número de equipe inválido, você poderá observar como a rotina de tratamento de erros funciona.

A amostra Rotina de Tratamento de Erro demonstra as seguintes tarefas:

As Mensagens

Duas mensagens de entrada são fornecidas para execução da amostra Rotina de Tratamento de Erro: uma mensagem que contém um número de série de equipe válido e uma mensagem que contém um número de série de equipe inválido.

A mensagem de equipe válida é apresentada no XML da seguinte forma:

<Staff>
   <StaffNumber>1</StaffNumber>
   <NameInfo>
      <LastName>Smith</LastName>
      <FirstName>Jack</FirstName>
   </NameInfo>
</Staff>

 

A mensagem de equipe inválida é apresentada em XML da seguinte forma:

<Staff>
   <StaffNumber>99</StaffNumber>
   <NameInfo>
      <LastName>Doe</LastName>
      <FirstName>Jane</FirstName>
   </NameInfo>
</Staff>

 

Os Fluxos de Mensagens

A figura a seguir mostra o fluxo de mensagens principal.

Uma Captura de Tela do Fluxo de Mensagens Principal.

A figura a seguir mostra o subfluxo de tratamento de erros.

Uma Captura de Tela do Subfluxo de Tratamento de Erros.

A tabela a seguir lista os tipos de nós que são utilizados na amostra Rotina de Tratamento de Erro. O nó Subflow não é tecnicamente um nó e ele não está disponível na Paleta de Nós; o nó Subflow apenas representa onde o subfluxo, Error_Handler.msgflow, é chamado dentro do fluxo de mensagens principal.

Tipo de Nó Nome do Nó
MQInput STAFF_IN
MQOutput STAFF_FAIL; STAFF_OUT
Database Update Staff Database; Update Error Database
Filter Check Valid Staff Number; Check Backout Count
Throw Throw; Throw to Complete Rollback
TryCatch TryCatch
Subflow Error_Handler

Para obter informações adicionais, leia sobre os nós nos fluxos de mensagens da amostra Rotina de Tratamento de Erro na documentação do WebSphere Message Broker.

A Rota da Mensagem de Equipe Válida

Quando a mensagem da equipe válida é colocada na fila de entrada, a mensagem viaja pelos nós, conforme descrito abaixo. Se alguma das filas tiver sido desativada, a mensagem não poderá seguir esse caminho.

No Fluxo de Mensagens Principal:

  1. STAFF_IN. O nó obtém a mensagem de entrada da fila de entrada.
  2. Error_Handler. Esse nó representa o subfluxo de tratamento de erros. A mensagem agora sai do fluxo de mensagens principal e entra no subfluxo.

No Subfluxo:

  1. Iniciar Subfluxo. A mensagem é transmitida para o próximo nó do fluxo.
  2. Verificar Contagem de Retirada. O nó verifica se a contagem de retirada é zero. Como essa é a primeira vez que a mensagem de entrada está sendo transmitida por esse nó, a contagem atualmente é zero e a mensagem é transmitida ao próximo nó. Se a contagem for superior a zero, a mensagem é descartada.
  3. TryCatch. Como o número de equipe é válido, a mensagem é transmitida para o nó Back To Main Flow. Se o número de equipe da mensagem for inválido e o processamento da mensagem tiver prosseguido para um estágio onde isso foi descoberto, a mensagem será transmitida para o nó Update Error Database.
  4. Back To Main Flow. Nesse ponto, a mensagem sai do subfluxo e retorna ao fluxo de mensagens principal.

No Fluxo de Mensagens Principal:

  1. Check Valid Staff Number. Como o número de equipe é válido, a mensagem é transmitida para o nó Update Staff Database.
  2. Update Staff Database. O banco de dados STAFFDB é atualizado com os detalhes da equipe na mensagem.
  3. STAFF_OUT. O nó coloca a mensagem na fila STAFF_OUT.

A Rota da Mensagem de Equipe Inválida

Quando a mensagem da equipe inválida é colocada na fila de entrada, a mensagem viaja pelos nós, conforme descrito abaixo. Se alguma das filas tiver sido desativada, a mensagem não poderá seguir esse caminho. Para obter informações adicionais sobre o que cada nó faz, clique nos nós das figuras no tópico principal.

No Fluxo de Mensagens Principal:

  1. STAFF_IN. O nó obtém a mensagem de entrada da fila de entrada.
  2. Error_Handler. Esse nó representa o subfluxo de tratamento de erros. A mensagem agora sai do fluxo de mensagens principal e entra no subfluxo.

No Subfluxo:

  1. Iniciar Subfluxo. A mensagem é transmitida para o próximo nó do fluxo.
  2. Verificar Contagem de Retirada. O nó verifica se a contagem de retirada é zero. Como essa é a primeira vez que a mensagem de entrada está sendo transmitida por esse nó, a contagem atualmente é zero e a mensagem é transmitida ao próximo nó. Compare à etapa 13, abaixo.
  3. TryCatch. O número de equipe na mensagem é inválido, mas isso ainda não foi descoberto. Como resultado, a mensagem de entrada é transmitida para o nó Back To Main Flow em vez de ao nó Update Error Database.
  4. Back To Main Flow. Nesse ponto, a mensagem sai do subfluxo e retorna ao fluxo de mensagens principal.

No Fluxo de Mensagens Principal:

  1. Check Valid Staff Number. Como o número de equipe é inválido, a mensagem é transmitida para o nó Throw Exception, em vez de para o nó Update Staff Database.
  2. Throw Exception. O nó pára o processamento da mensagem e registra o número do erro "3001" e o texto "Invalid staff number" no conteúdo da mensagem. A mensagem agora á 'revertida'. Ou seja, a mensagem é propagada de volta ao ponto de controle que, nesse caso, é o nó TryCatch do subfluxo.

No Subfluxo:

  1. TryCatch. O nó reconhece que ocorreu uma exceção no processamento da mensagem e transmite a mensagem para o nó Update Error Database.
  2. Update Error Database. O banco de dados ERRORDB é atualizado com os detalhes do erro, conforme definido no nó Throw exception (etapa 8).
  3. Throw To Complete Rollback. O nó pára o processamento da mensagem e registra o número "3002" e o texto "From Error_Handler message flow. Consulte ERRORDB para obter detalhes" no conteúdo da mensagem. A mensagem agora é propagada de volta ao ponto de controle, que é o nó STAFF_IN do fluxo de mensagens principal.
    Esse é o estágio final do processamento de captura. Ele tem o efeito de reverter toda a transação, inclusive as atualizações do banco de dados sob controle transacional (ou seja, a atualização de STAFFDB no fluxo principal) no caminho de teste original. No entanto, a atualização de ERRORDB, que está fora do controle transacional, ainda é consolidada.

No Fluxo de Mensagens Principal:

  1. STAFF_IN. Como ocorreu uma exceção no processamento da mensagem, a mensagem é transmitida para o nó STAFF_FAIL, em vez de ser transmitida através do fluxo de mensagens novamente.
  2. STAFF_FAIL. O nó coloca a mensagem na fila STAFF_FAIL. Como alternativa, se a fila STAFF_FAIL for desativada, a mensagem não pára aqui, Ela é transmitida de volta ao nó STAFF_IN e, em seguida, ao subfluxo. A mensagem, então, alcança o nó Verificar Contagem de Retirada. O nó verifica se a contagem de retirada é zero. Como a mensagem foi transmitida por esse nó anteriormente, a contagem de retirada não é mais zero e a mensagem será descartada. Descartar a mensagem impede que ocorra uma situação em que, se a fila STAFF_FAIL estiver desativada, a mensagem continue a viajar pelo fluxo ininterruptamente. Compare à etapa 4, acima.

Ao utilizar um nó TryCatch ou ao anexar nós ao terminal de captura do nó MQInput, você pode supor que todo o processamento ocorrido no caminho de teste não será consolidado, se os nós estiverem corretamente configurados, se o caminho de captura for chamado. Esse, no entanto, não é o caso. Por exemplo, se um banco de dados for atualizado no caminho de teste sob controle transacional e o caminho de captura for chamado e concluído normalmente, a atualização do banco de dados ainda será consolidada.

O requisito nessa amostra é ler uma mensagem, atualizar um banco de dados e gravar a mensagem em outra fila. Se ocorrer um erro, a atualização do banco de dados é revertida. O processamento da captura atualiza o banco de dados de erros com os detalhes do erro e grava a mensagem original na fila de falha. Em termos de programação, isto é o que ocorre:

BEGIN (Iniciar unidade de trabalho 'externa'.)
MQGET (Obter mensagem da fila de entrada.)
TRY
   BEGIN (Start 'inner' unit-of-work.)
   Update database
   MQPUT (Put message onto the output queue.)
   IF ERROR
      ROLLBACK inner unit-of-work GO TO CATCH
   ELSE
      COMMIT inner and outer unit-of-work as one unit-of-work
   END IF
CATCH
   Update error database
   MQPUT (Put message onto the failure queue.)
   COMMIT outer unit-of-work

No entanto, o XA Transaction Manager e o WebSphere MQ não suportam dois níveis de unidade de trabalho no mesmo aplicativo. Como resultado, a amostra Rotina de Tratamento de Erro utiliza as seguintes estruturas:

Há dois bancos de dados nessa amostra, em vez de um, porque no WebSphere MQ, a mesma conexão de banco de dados não pode ser utilizada para transações coordenadas e descoordenadas no mesmo fluxo de mensagens. Na amostra Rotina de Tratamento de Erro, a atualização do banco de dados no fluxo de mensagens principal está sob o controle transacional para que, se um erro ocorrer, a atualização seja revertida e não consolidada. A atualização do banco de dados no subfluxo não está sob controle transacional para que a atualização sempre seja consolidada. Como resultado, a amostra Rotina de Tratamento de Erro requer dois bancos de dados separados.

Para obter informações adicionais, leia sobre fluxos de mensagens em transações coordenadas na documentação do WebSphere Message Broker.

Ícone Página Principal   Voltar para Home da Amostra