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:
- Como usar uma rotina de tratamento de erros para as informações de
trap sobre erros e armazenar as informações em uma fila do WebSphere MQ.
A rotina do manipulador de erros que é utilizada na amostra é um subfluxo que você
pode incluir, inalterado, em qualquer fluxo de mensagens.
- Como configurar fluxos de mensagens para controlar a capacidade das transações.
Em particular, a amostra demonstra o uso de transações globalmente coordenadas para
garantir integridade geral dos dados, que é o modo padrão da operação em z/OS.
Em plataformas distribuídas, a coordenação global requer etapas de configuração
específicas, e é implementada usando protocolos XA.
Nesta amostra, o fluxo de mensagens principal da amostra atualiza um banco de dados com informações sobre
números de equipe.
O subfluxo da manipulação de erros emite quaisquer mensagens em que o
processamento de erros ocorreu em uma fila.
A atualização do banco de dados
no fluxo principal está sob controle transacional para que, se ocorrer um erro e a
mensagem for processada pelo subfluxo de tratamento de erros, a atualização do banco de
dados sobre o número de equipe seja revertida e não consolidada.
A atualização da fila no subfluxo do manipulador de erros está fora do
controle transacional, para assegurar que as informações sobre os erros não foram revertidas, pois as
informações devem estar comprometidas a fornecer um registro de erros.
As Mensagens
As duas mensagens de entrada são fornecidas para executar a amostra de Manipulador de erros:
- Uma mensagem que contém um número de série de equipe válido
- Uma mensagem que contém um número de série de equipe inválido
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.

O diagrama a seguir mostra o subfluxo de manipulação 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.
- No Fluxo de Mensagens Principal:
- Nó STAFF_IN. Esse nó obtém a mensagem de entrada da fila de entrada.
- Nó Error_Handler. Esse nó representa o subfluxo de tratamento de erros.
A mensagem deixa o fluxo de mensagem principal e entra no subfluxo.
- No Subfluxo:
- Inicie o nó de Subfluxo. A mensagem é transmitida para o próximo nó do fluxo.
- 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.
- 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.
- Nó Retorno ao Fluxo Principal. A mensagem deixa o subfluxo e retorna para o fluxo de mensagens principal.
- No Fluxo de Mensagens Principal:
- 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.
- Nó Atualizar Banco de Dados da Equipe. O banco de dados STAFFDB é atualizado com os detalhes da equipe na
mensagem.
- Nó STAFF_OUT. Esse nó coloca a mensagem na fila STAFF_OUT.
- 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.
- No Fluxo de Mensagens Principal:
- Nó STAFF_IN. Esse nó obtém a mensagem de entrada da fila de entrada.
- Nó Error_Handler. Esse nó representa o subfluxo de tratamento de erros.
A
mensagem deixa o fluxo de mensagem principal e entra no subfluxo.
- No Subfluxo:
- Inicie o nó de Subfluxo. A mensagem é transmitida para o próximo nó do fluxo.
- 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.
- 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.
- Nó Retorno ao Fluxo Principal. A mensagem deixa o subfluxo, e retorna ao fluxo
de mensagens principal.
- No Fluxo de Mensagens Principal:
- 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.
- 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.
- No Subfluxo:
- Nó TryCatch. Este nó reconhece que ocorreu uma exceção no
processamento da mensagem e a transmite ao nó STAFF_UPDATE_ERROR.
- Nó STAFF_UPDATE_ERROR. A mensagem é enviada à fila
STAFF_UPDATE_ERROR.
- 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.
- No Fluxo de Mensagens Principal:
- 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.
- 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:
- A atualização do banco de dados, STAFFDB, no caminho de tentativa está dentro do controle transacional
- A fila, STAFF_UPDATE_ERROR, atualizada no caminho de captura está
fora do controle transacional.
- O terminal Failure do nó MQInput está conectado a um nó MQOutput, que aponta para uma fila de falhas.
- O estágio final do processamento de captura é produzir um erro novamente
utilizando um nó Lançamento.
- A mensagem então retorna ao longo do caminho de falhas para o nó MQInput e, de lá,
para a fila de falhas.
Para obter informações adicionais, consulte
Transações de Fluxo de Mensagem
na documentação do WebSphere Message Broker.
Voltar para Home da Amostra