Um fluxo de mensagens coordenado é executado em uma única transação,
que é iniciada quando uma mensagem é recebida por um nó input e pode ser confirmada
ou receber rollback quando todo o processamento estiver concluído. Também é
possível controlar como os erros no banco de dados são manipulados
pelo nó que interage com o banco de dados.
Se você quiser que as ações de fluxo de mensagens sejam coordenadas globalmente (isto é, ele deve completar todos os processos com sucesso ou não completar nenhum), certifique-se de que a configuração suporte essa ação. Para
obter mais informações sobre coordenação global de transações de fluxo de mensagens,
consulte
Modelo Transacional.
A amostra a seguir demonstra a utilização de
transações coordenadas globalmente e as diferenças no fluxo de mensagens quando
as atualizações de banco de dados são coordenadas (o fluxo principal) e quando não
são (o fluxo de erros).
Você
pode visualizar amostras apenas quando utilizar o centro de informações integrado
ao Message
Brokers Toolkit.
Para
configurar um fluxo de mensagens para coordenação global:
- No Message
Brokers Toolkit, vá para a Perspectiva do Desenvolvimento de Aplicativos do Intermediário.
- Abra o fluxo de mensagens que você deseja configurar.
- Configure a propriedade Transação para os seguintes nós, se
eles forem utilizados no fluxo de mensagens:
- Nó Compute
- Nó Banco de Dados
- Nó DataDelete
- Nó DataInsert
- Nó DataUpdate
- Nó Filter
- Nó Mapeamento
- Nó Warehouse
Você pode definir a propriedade
Transaction para os
seguintes valores:
- Automático
- Todas as atualizações, exclusões e inclusões realizadas pelo nó
serão consolidadas ou revertidas quando o processamento do fluxo de
mensagens for concluído.
Se o fluxo de
mensagens for concluído com êxito, todas as alterações serão
consolidadas.
Se o fluxo de mensagens não for concluído com êxito, será feita a
reversão de todas as alterações.
Se desejar que todo o processamento
pelo fluxo de mensagens seja coordenado, será necessário selecionar
este valor.
- Commit
- A ação tomada depende do sistema no qual o fluxo de mensagens foi
implementado:
Para misturar nós com transacionalidade
Automático (Automatic) e
Confirmado (Commit) no mesmo fluxo
de mensagens, em que os nós operam no mesmo banco de dados externo, utilize conexões ODBC
separadas: uma para os nós que não são confirmados até a conclusão do fluxo de mensagens
e uma para os nós que são confirmados imediatamente. Se você não utilizar conexões ODBC separadas, os nós
consolidados imediatamente também consolidarão todas as operações executadas por nós
Automatic precedentes.
Nota: Em sistemas diferentes de z/OS, os bancos de dados relacionais individuais podem ou não suportar esse modo de operação.
Se você definir mais de uma conexão ODBC, poderão ocorrer
problemas de travamento no banco de dados. Em
especial, se um nó com transacionalidade Automatic
realizar uma operação, como INSERT ou UPDATE, que cause o travamento
de um objeto do banco de dados (como uma tabela) e um nó seguinte
tentar acessar esse objeto do banco de dados utilizando uma conexão
ODBC diferente, ocorrerá um travamento (congelamento) infinito.
O segundo nó aguarda pela
liberação do travamento do primeiro, mas o primeiro nó não
consolidará suas operações e liberará seu travamento até que seja
concluído o fluxo de mensagens; isso nunca ocorrerá porque o segundo
nó está aguardando pela liberação do travamento do banco de dados do
primeiro nó.
Esta situação não pode ser detectada por nenhuma das rotinas de evitação
de conflitos automáticas do DBMS, porque as duas operações estão interferindo
entre si indiretamente utilizando o intermediário.
Existem duas maneiras de evitar este tipo de problema de bloqueio:
- Projete o fluxo de mensagens para que as operações (automáticas)
não consolidadas não travem objetos do banco de dados, cujas
operações subseqüentes que utilizem uma conexão ODBC diferente,
precisam acessar.
- Configure o parâmetro de tempo limite da trava do banco de dados
para que uma tentativa de adquirir uma trava falhe após um período de
tempo específico. Se uma operação do banco de dados falhar devido a um tempo limite de bloqueio, será
emitida uma exceção que o intermediário manipula de maneira comum.
Para obter informações relativas a quais objetos do banco de
dados serão travados por determinadas operações e como configurar o
parâmetro de tempo limite do banco de dados, consulte a documentação
do produto do banco de dados.
- Configure a propriedade Modo de transação para os seguintes
nós, se eles estiverem neste fluxo de mensagens:
- Nó MQInput
- Nó MQOutput
- Nó MQReply
- Nó SCADAInput
- Nó JMSInput
- Nó JMSOutput
A tabela a seguir fornece um resumo da ações realizadas em resposta às configurações de propriedade específicas para os nós de entrada e saída.
Persistência de Mensagem a |
Modo de transação do nó Input |
Modo de transação do nó
MQOutput ou MQReply |
O fluxo de mensagens é globalmente coordenado? |
Sim |
Sim |
Automático |
Sim |
Não |
Sim |
Automático |
Sim |
Sim |
Não |
Automático |
Não |
Não |
Não |
Automático |
Não |
Sim |
Automático |
Automático |
Sim |
Não |
Automático |
Automático |
Não |
Qualquer b |
Qualquer b |
Sim |
Sim |
Qualquer b |
Qualquer b |
Não |
Não |
Notas: - A persistência é relevante apenas para mensagens recebidas através dos protocolos WebSphere MQ
Enterprise Transport, WebSphere MQ Mobile Transport
e WebSphere MQ
Telemetry Transport.
- A configuração da propriedade do nó MQOutput ou MQReply
substitui o valor configurado aqui.
- As configurações do Modo de transação dos nós JMSInput e
JMSOutput são efetuadas de maneira diferente da tabela precedente. Consulte Nó JMSInput e Nó JMSOutput.
O padrão em cada nó input é
Sim, o que
significa que as mensagens que chegam são processadas sob o ponto de
sincronização. Além disso, as mensagens enviadas para
o nó output são entregues sob o ponto de sincronização. É possível alterar este comportamento se o nó de
saída for um nó MQOutput ou
MQReply, se os dois tiverem uma propriedade
Modo de transação.
Se você configurar a propriedade Modo de transação em um nó de
entrada como Automática, as mensagens que chegam serão
processadas sob o ponto de sincronização apenas se estiverem definidas como persistentes. As mensagens
enviadas para o nó MQOutput são entregues sob o ponto de
sincronização, a menos que você altere explicitamente a configuração da propriedade
Modo de transação no nó
MQOutput.
- Configure as propriedades Tratar avisos como erros e
Emitir exceção em erro do banco de dados para cada nó que acessa um
banco de dados para indicar como você deseja que o nó manipule avisos e erros do banco de dados. No caso de
você selecionar essas propriedades e como você conecta os terminais
com falha dos nós, também afetam a maneira na qual as atualizações de
banco de dados são consolidadas ou revertidas.
- Adicione o fluxo de mensagens a um archive do intermediário.
- Selecione a guia Configurar abaixo da visualização do editor de
archive do intermediário e selecione o fluxo de mensagens. Isso exibe as propriedades configuráveis para o fluxo de mensagens
no archive do intermediário. Selecione coordinatedTransaction
para configurar o fluxo de mensagens como coordenado globalmente.
No
z/OS, as transações são sempre coordenadas
globalmente. A definição da propriedade coordinatedTransaction para um fluxo de mensagens é ignorada. A coordenação é sempre fornecida
por RRS.
O fluxo de mensagens agora está configurado para coordenação
global.
Agora você pode implementar o fluxo de mensagens no
intermediário. Assegure-se de que o ambiente do intermediário (incluindo o gerenciador de
filas do intermediário) e os bancos de dados estejam configurados corretamente para
coordenação global antes de implementar o fluxo de mensagens.
Se o ambiente do
intermediário e os bancos de dados não estiverem configurados corretamente para
coordenação global, as transações de fluxo de mensagens não serão coordenadas globalmente.