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:
- Como utilizar uma rotina de tratamento de erros para capturar informações sobre erros e armazenar
as informações em um banco de dados. A rotina de tratamento de erros utilizada na amostra é um
subfluxo que pode ser incluído, sem alteração, a qualquer fluxo de mensagens.
- Como configurar fluxos de mensagens para controlar a capacidade das transações. Na verdade, a amostra
demonstra a utilização de transações coordenadas globalmente para assegurar a integridade
geral dos dados. No z/OS, esse é o modo padrão de operação. Nas plataformas distribuídas,
a coordenação global requer etapas de configuração específicas e é implementada
através de protocolos XA. Nessa amostra, o fluxo de mensagens principal atualiza um
banco de dados DB2 com informações sobre os números de equipes.
O subfluxo de tratamento de erros atualiza outro banco de dados DB2 com informações
sobre todos os erros ocorridos quando o número de equipe foi processado. 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 do banco de dados
no subfluxo da rotina de tratamento de erros está fora do controle transacional para assegurar
que as informações sobre os erros não sejam revertidas, já que as informações precisam
ser consolidadas para fornecer um registro de erros.
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.

A figura a seguir mostra o 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:
- STAFF_IN. O nó obtém a mensagem de entrada da fila de entrada.
- 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:
- Iniciar Subfluxo. A mensagem é transmitida para o próximo nó do fluxo.
- 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.
- 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.
- Back To Main Flow. Nesse ponto, a mensagem sai do subfluxo e retorna ao fluxo de
mensagens principal.
No Fluxo de Mensagens Principal:
- Check Valid Staff Number. Como o número de equipe é válido, a mensagem é transmitida para o nó
Update Staff Database.
- Update Staff Database. O banco de dados STAFFDB é atualizado com os detalhes da equipe na
mensagem.
- 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:
- STAFF_IN. O nó obtém a mensagem de entrada da fila de entrada.
- 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:
- Iniciar Subfluxo. A mensagem é transmitida para o próximo nó do fluxo.
- 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.
- 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.
- Back To Main Flow. Nesse ponto, a mensagem sai do subfluxo e retorna ao fluxo de
mensagens principal.
No Fluxo de Mensagens Principal:
- 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.
- 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:
- TryCatch. O nó reconhece que ocorreu uma exceção no processamento da mensagem e
transmite a mensagem para o nó Update Error Database.
- Update Error Database. O banco de dados ERRORDB é atualizado com os detalhes do erro, conforme
definido no nó Throw exception (etapa 8).
- 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:
- 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.
- 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:
- A atualização do banco de dados no caminho de teste está dentro do controle transacional. Na amostra,
é a atualização do STAFFDB.
- A atualização do banco de dados no caminho de captura está fora do controle transacional.
É o banco de dados ERRORDB.
- O terminal de falha do nó MQInput está conectado a um nó MQOutput, que aponta para uma fila de falhas.
- O estágio final do processamento de captura é lançar um erro novamente, utilizando o nó Throw.
- A mensagem então é revertida pelo caminho de falha para o nó MQInput e, de lá, para
a fila de falha.
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.
Voltar para Home da Amostra