Sobre a Amostra Rotina de Tratamento de Erro

Uma amostra de Manipulador de Erros é baseada em um cenário onde um negócio que está envolvido no processamento de transações deseja desenvolver uma rotina para manipulação de erros. Uma amostra demonstra como usar alguns dos recursos que são fornecidos no Intermediário de Mensagem WebSphere.

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

As duas mensagens de entrada são fornecidas para executar a amostra de Manipulador de erros:

A mensagem de equipe válida é mostrada no seguinte código XML:

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

A mensagem de equipe inválida é mostrada no seguinte código XML:

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

 

Os Fluxos de Mensagens

O diagrama a seguir mostra o fluxo de mensagens principal.

Captura de Tela do Fluxo de Mensagens Principal.

O diagrama a seguir mostra o subfluxo de manipulação de erros.

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ó de Subfluxo não é tecnicamente um nó e não está disponível na paleta do nó; o nó de Subfluxo 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; STAFF_UPDATE_ERROR
Compute Copy Message; Create Message for Output
Filtro Check Valid Staff Number; Check Backout Count
Throw Throw; Throw to Complete Rollback
TryCatch TryCatch
Subfluxo Error_Handler

Para obter mais informações, consulte Nós integrados e Usando subfluxos na documentação do WebSphere Message Broker.

A Rota da Mensagem de Equipe Válida

Quando você coloca a mensagem de equipe válida na fila de entrada, a mensagem viaja através dos nós. Se alguma das filas estiver desativada, a mensagem não pode seguir esse caminho.

  1. No Fluxo de Mensagens Principal:
    1. Nó STAFF_IN. Esse nó obtém a mensagem de entrada da fila de entrada.
    2. Nó Error_Handler. Esse nó representa o subfluxo de tratamento de erros. A mensagem deixa o fluxo de mensagem principal e entra no subfluxo.
  2. No Subfluxo:
    1. Inicie o nó de Subfluxo. A mensagem é transmitida para o próximo nó do fluxo.
    2. Verifique o nó Contagem de Retorno. Esse nó verifica se a contagem de restauração é zero. Como é a primeira vez que a mensagem de entrada é transmitida através desse nó, a contagem realmente está em zero, e a mensagem é transmitida para o próximo nó. Se a contagem for superior a zero, a mensagem é descartada.
    3. Nó 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 na mensagem for inválido e o processamento da mensagem descobrir este número, a mensagem é transmitida para os nós Copy Message e STAFF_UPDATE_ERROR.
    4. Nó Retorno ao Fluxo Principal. A mensagem deixa o subfluxo e retorna para o fluxo de mensagens principal.
  3. No Fluxo de Mensagens Principal:
    1. Nó Verificar Número de Equipe Válido. Como o número de equipe é válido, a mensagem é transmitida para o nó Update Staff Database.
    2. Nó Atualizar Banco de Dados da Equipe. O banco de dados STAFFDB é atualizado com os detalhes da equipe na mensagem.
    3. Nó STAFF_OUT. Esse nó coloca a mensagem na fila STAFF_OUT.
    4. Se não possuir um banco de dados, a mensagem ainda é colocada na fila no terminal Failure. Este cenário demonstra essa amostra sem o uso de um banco de dados e não deve ser usada na produção.

A Rota da Mensagem de Equipe Inválida

Quando você coloca a mensagem de equipe inválida na fila de entrada, a mensagem viaja através dos nós conforme descrito posteriormente nesta seção. Se alguma das filas estiver desativada, a mensagem não pode seguir esse caminho. Para obter mais informações sobre qual nó segue, consulte Nós Integrados na documentação do WebSphere Message Broker.

  1. No Fluxo de Mensagens Principal:
    1. Nó STAFF_IN. Esse nó obtém a mensagem de entrada da fila de entrada.
    2. Nó Error_Handler. Esse nó representa o subfluxo de tratamento de erros. A mensagem deixa o fluxo de mensagem principal e entra no subfluxo.
  2. No Subfluxo:
    1. Inicie o nó de Subfluxo. A mensagem é transmitida para o próximo nó do fluxo.
    2. Verifique o nó Contagem de Retorno. Esse nó verifica se a contagem de restauração é zero. Como essa é primeira vez que a mensagem de entrada é transmitida através desse nó, a contagem realmente está em zero, e a mensagem é transmitida para o próximo nó. Compare com a etapa 5b posteriormente nesta seção.
    3. Nó TryCatch. O número de equipe na mensagem é inválido, mas ele ainda não foi descoberto. A mensagem de entrada é transmitida ao nó Back To Main Flow, ao invés do nó STAFF_UPDATE_ERROR.
    4. Nó Retorno ao Fluxo Principal. A mensagem deixa o subfluxo, e retorna ao fluxo de mensagens principal.
  3. No Fluxo de Mensagens Principal:
    1. Nó Verificar Número de Equipe Válido. Como o número de equipe é inválido, a mensagem é transmitida ao nó Throw, ao invés do nó Update Staff Database.
    2. Nó Lançamento. Esse nó pára o processamento da mensagem e registra o número do erro "3001", e o texto "Número de equipe inválido" para o conteúdo da mensagem. A mensagem é retornada, ou seja, a mensagem é propagada de volta para o ponto de controle, o qual neste o caso é o nó TryCatch no subfluxo.
  4. No Subfluxo:
    1. Nó TryCatch. Este nó reconhece que ocorreu uma exceção no processamento da mensagem e a transmite ao nó STAFF_UPDATE_ERROR.
    2. Nó STAFF_UPDATE_ERROR. A mensagem é enviada à fila STAFF_UPDATE_ERROR.
    3. Nó Lançamento para Concluir Retrocesso. Este nó para o processamento da mensagem e registra o número "3002" e o texto "A partir do fluxo de mensagens Error_Handler." para o 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 estágio é 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 STAFF_UPDATE_ERROR, que está fora do controle transacional, ainda está comprometida.
  5. No Fluxo de Mensagens Principal:
    1. Nó STAFF_IN. Como ocorreu uma exceção no processamento da mensagem, a mensagem é transmitida para o nó STAFF_FAIL, em vez de ser transmitido através do fluxo de mensagens novamente.
    2. Nó 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, A mensagem é transmitida de volta para o nó STAFF_IN e, em seguida, para o subfluxo. A mensagem então atinge o nó Verificar Contagem de Retorno, que verifica se a contagem de restauração está em zero. Como a mensagem foi transmitida através desse nó anteriormente, a contagem de restauração não está mais em zero, e a mensagem é descartada. O descarte da mensagem impede uma situação em que, se a fila STAFF_FAIL estiver desativada, a mensagem continua viajando através do fluxo. Compare essa etapa à etapa 2b.

Quando você utiliza um nó TryCatch, ou quando conecta nós ao terminal de Captura de um nó MQInput, pode presumir que qualquer processamento que tenha ocorrido no caminho de tentativa, se os nós estiverem corretamente configurados, não é efetivado se o caminho de captura for invocado. Essa suposição não está correta. Por exemplo, se um banco de dados é atualizado no caminho de tentativa sob o controle transacional e o caminho de captura for invocado e concluir normalmente, a atualização de banco de dados ainda será efetivada.

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 de captura atualiza o banco de dados de erros com os detalhes do erro e grava a mensagem original na fila de falhas. Em termos de programação, o exemplo a seguir mostra o que acontece.

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
   Send message to STAFF_UPDATE_ERROR queue
   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. Portanto, a amostra Manipulador de Erros utiliza as seguintes estruturas:

Para obter informações adicionais, consulte Transações de Fluxo de Mensagem na documentação do WebSphere Message Broker.

Voltar para Home da Amostra