Configurando Fluxos de Mensagens Coordenados Globalmente

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.

Antes de começar:

Você deve ter concluído as seguintes tarefas:

  1. Configurando Bancos de Dados para Coordenação Global de Transações.
  2. Configurando a Coordenação Global de Transações (two-phase commit).
  3. Criação de um Fluxo de Mensagens.
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:

  1. No Message Brokers Toolkit, vá para a Perspectiva do Desenvolvimento de Aplicativos do Intermediário.
  2. Abra o fluxo de mensagens que você deseja configurar.
  3. Configure a propriedade Transação para os seguintes nós, se eles forem utilizados no fluxo de mensagens:
    • Compute
    • Banco de Dados
    • DataDelete
    • DataInsert
    • DataUpdate
    • Filter
    • Mapeamento
    • 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:
    • Em sistemas distribuídos, todo o trabalho realizado a essa origem de dados nesse fluxo de mensagens até a data atual, incluindo as ações tomadas nesse nó, será consolidado, independente do sucesso ou falha subseqüente do fluxo de mensagens.
      Nota: Em sistemas diferentes de z/OS, os bancos de dados relacionais individuais podem ou não suportar esse modo de operação.
    • z/OS platform No z/OS, as ações executadas neste nó são apenas confirmadas, independentemente do êxito ou falha subseqüente do fluxo de mensagens. Nenhuma ação tomada antes desse nó, sob transacionalidade automática, será confirmada, mas permanecerá em uma unidade de trabalho e poderá ser confirmada ou revertida, dependendo do êxito do fluxo de mensagens.
    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.

  4. Configure a propriedade Modo de transação para os seguintes nós, se eles estiverem neste fluxo de mensagens:
    • MQInput
    • MQOutput
    • MQReply
    • SCADAInput
    • JMSInput
    • 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:
    1. 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.
    2. A configuração da propriedade do nó MQOutput ou MQReply substitui o valor configurado aqui.
    3. 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.

  5. 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.
  6. Adicione o fluxo de mensagens a um archive do intermediário.
  7. 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.

    z/OS platform 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.

Conceitos relacionados
Visão Geral de Fluxos de Mensagens
Transações de Fluxos de Mensagens
Modelo Transacional
Tarefas relacionadas
Projetando um Fluxo de Mensagens
Criação de um Fluxo de Mensagens
Definindo o Conteúdo do Fluxo de Mensagens
Acessando Bancos de Dados em Fluxos de Mensagens
Configurando Fluxos de Mensagens Coordenados Globalmente
Tratando Erros em Fluxos de Mensagens
Incluindo Arquivos em um Broker Archive
Editando Propriedades Configuráveis
Referências relacionadas
Fluxos de Mensagens Coordenados
Nós Internos
Bancos de Dados Suportados
Nó JMSInput
Nó JMSOutput
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última atualização : 2009-02-13 16:11:34

ac00390_