WebSphere Enterprise Service Bus, Versão 6.2.0 Sistemas Operacionais: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Caso de Uso: Recuperando Dados de Eventos com Falha

Um caso de uso fornece um contexto para um cenário de recuperação. No caso de uso, os negócios têm um aplicativo que recebe um pedido para criar uma nova Conta.

A solução é composta de vários módulos conforme recomendado pelas boas práticas de módulos.

O primeiro módulo media o pedido e delega trabalho a um processo de Criação de Conta. No exemplo abaixo implementamos a solução como módulos separados nos quais o pedido é transmitido entre o módulo de mediação (AccountRouting) e o módulo de processamento (AccountCreation) através de uma importação/exportação de SCA. Consulte a captura de tela a seguir para obter uma ilustração dos dois módulos.

Figura 1. Diagrama de montagem do processo de roteamento de conta
Um Pedido É Transmitido Entre o Módulo de Mediação (AccountRouting) e o Módulo do Processamento (AccountCreation) a partir da Importação de SCA para a Exportação de SCA.

No diagrama de montagem mostrado na Figura 1, você pode começar a ver em quais locais no fluxo essas falhas podem ocorrer. Qualquer um dos pontos de chamada no diagrama de montagem pode propagar ou envolver uma transação. Existem algumas áreas no fluxo nas quais os dados serão coletados como um resultado de falhas do aplicativo ou do sistema.

Em geral, os limites de transação são criados e gerenciados pela interação (síncrona e assíncrona) entre componentes e ligações de importação/exportação e seus qualificadores associados. Os dados de negócios são acumulados em locais de recuperação específicos, geralmente devido à falha, conflito ou recuperação de transação.

Os recursos de transação na ajuda do WebSphere Application Server WebSphere ESB registram transações com provedores de serviços. É importante entender estas interações incluídas, principalmente em relação às ligações de importação e exportação. Entender como as importações e exportações são utilizadas em seus casos de negócios específicos é importante na determinação de onde os eventos que precisam de recuperação são acumulados.

Uma estratégia de manipulação de erros deve definir padrões de interação, transações utilizadas, uso de importação e exportação antes de desenvolver o aplicativo. O arquiteto da solução deve identificar as preferências para utilização, diretrizes, que são, então, utilizadas conforme o aplicativo é criado. Por exemplo, o arquiteto precisa entender quando utilizar chamadas síncronas versus chamadas assíncronas, quando utilizar manipulação de falha de BPEL e assim por diante. O arquiteto precisa saber se todos os serviços podem ou não participar das transações e, para esses serviços que não podem participar, como tratar da compensação se problemas forem encontrados.

Além disso, o aplicativo mostrado no diagrama de montagem na Figura 1 alavanca boas práticas de grupos de conectividade e de desenvolvimento de módulos. Alavancando este padrão agora temos a capacidade de parar o fluxo de entrada de novos eventos, parando o módulo AccountRouting.

As seções a seguir abordam o local de dados de negócios em caso de falha e recuperação.

Business Flow Manager ou Gerenciador de Tarefas Humanas

Em nosso caso de negócios, alavancamos um processo BPEL para o processo AccountCreation.

Em relação à recuperação, existem algumas perguntas que você precisa fazer a si mesmo em relação ao BPEL e ao gerenciamento de Tarefas Humanas, conforme a seguir:
  1. Qual tipo de processo está sendo executado (execução curta ou execução longa, máquina de estado de negócios, tarefa humana)?

    Os processos de execução curta são conhecidos como microfluxos.

  2. O processo foi desenvolvido corretamente e está utilizando a manipulação de falhas para promover a integridade de dados?
  3. Como os padrões de chamada e as propriedades da unidade de trabalho estão configurados para prever e controlar limites de transações?

Saber as respostas para estas perguntas impactará sua estratégia de recuperação para as chamadas 7 e 8 mostradas no diagrama de montagem, conforme realçado na captura de tela abaixo:

Figura 2. Diagrama de montagem de roteamento de conta - chamadas 7 e 8
Captura de tela mostra o diagrama de montagem com as chamadas 7 e 8 realçadas.

Componentes estáveis, como processos BPEL de Execução Longa e Máquina de Estado de Negócios, envolvem muitas transações do banco de dados onde a atividade do processo muda e as alterações de estado são entregues ao banco de dados. O trabalho progride atualizando o banco de dados e colocando uma mensagem em uma fila interna que descreve o que será feito em seguida.

Se houver problemas ao processar mensagens que são internas ao Business Flow Manager, estas mensagens serão movidas para uma Fila de Retenção. O sistema continuará processando mensagens. Se uma mensagem subsequente for processada com êxito, as mensagens na Fila de Retenção serão reenviadas para processamento. Se a mesma mensagem for colocada na Fila de Retenção cinco vezes, ela será colocada na Fila de Suspensão.

Informações adicionais sobre como visualizar o número de mensagens e como reproduzir mensagens podem ser localizadas em Reproduzindo Mensagens da Fila de Retenção / Fila de Suspensão.

Gerenciador de Evento de Falha

O FEM (Failed Event Manager) é utilizado para reproduzir eventos ou pedidos de chamada de serviço que são feitos assincronamente entre a maioria dos tipos de componentes.

Serão criados eventos com falha se o componente AccountRouting fizer uma chamada assíncrona para a ligação de Importação de SCA AccountCreationSCAImport e será retornada uma ServiceRuntimeException.

É importante observar que os eventos com falha não são gerados na maioria dos casos em que o BPEL é o cliente na interação do serviço. Isto significa que a chamada para 7 e 8 (conforme mostrado na Figura 2) geralmente não resultará em um evento com falha. O BPEL fornece manipuladores de falhas e outras formas de modelo para falha. Por esta razão, se houver uma falha SRE (ServiceRuntimeException) ao chamar "JDBCOutboundInterface", a SRE será retornada ao BPEL para processamento. A estratégia de manipulação de erros para o projeto deve definir como as exceções de tempo de execução são manipuladas consistentemente no BPEL.

No entanto, é importante observar que serão criados eventos com falha para mensagens de resposta assíncrona para o cliente BPEL se estas mensagens não puderam ser entregues na instância do processo devido a uma falha de infraestrutura.

O diagrama a seguir ilustra como funciona o componente Failed event manager. As descrições do processamento associadas a cada etapa numerada são fornecidas após o diagrama.

Figura 3. Processamento do Failed event manager
Diagrama de Processamento do Failed Event Manager. O diagrama é numerado e as etapas numeradas são fornecidas em uma lista após o diagrama.
Processamento do Failed event manager
  1. O componente de origem faz uma chamada utilizando um padrão de chamada assíncrono.
  2. O MDB SCA remove a mensagem do destino de SCA
  3. O MDB SCA faz a chamada para o componente de destino correto
  4. O componente de destino lança uma ServiceRuntimeException
  5. A transação do MDB SCA é recuperada para o destino de SCA
  6. As informações da exceção estão armazenadas no banco de dados do Failed event manager com um status de não confirmado
  7. A chamada é tentada novamente pelo SIBus n vezes

    O valor padrão do limite de novas tentativas é 5 - um original e 4 novas tentativas. É possível alterar o valor padrão no console administrativo. Por exemplo, fornecido um módulo SCA M, você pode navegar para Barramentos > SCA.SYSTEM.<CELL>.BUS > Destinos > sca/M e alterar o valor no campo Máximo de Entregas com Falha.

  8. Quando o número de novas tentativas atingir o limite especificado, a mensagem será movida para o destino do FEM.
  9. O banco de dados do Failed Event Manager coleta a mensagem
  10. O banco de dados do Failed Event Manager atualiza o evento com falha no banco de dados e o status é configurado como com falha.

Quando os "eventos com falha" são criados?

Conforme afirmado, os eventos com falha não são criados para chamadas síncronas nem geralmente para interações do processo de negócios de duas vias.

Os eventos com falha geralmente são criados quando os clientes utilizam um padrão de chamada assíncrona e é lançada uma ServiceRuntimeException pelo provedor de serviços.

Se tudo for feito sincronamente e na mesma transação, os dados não serão coletados em nenhum lugar. Em vez disso, eles serão todos recuperados para o cliente que fez a chamada. Onde quer que uma confirmação ocorra, dados são coletados. Se as chamadas forem todas síncronas, mas houver várias confirmações, estas confirmações se tornarão um problema.

Em geral, você deve utilizar chamadas de processamento assíncrono ou BPEL de longa execução se várias transações forem necessárias. Portanto, cada chamada ASYNC é uma chance para que dados sejam coletados. O processo BPEL de execução longa é um ponto de coleta.

Tabela 1. Padrões de Chamada e Relacionamento para a Criação de Eventos com Falha: Service Business Exceptions
Padrão de Chamada Evento com Falha Criado S/N? Notas
Síncrono Não Eventos com falha não são criados para service business exceptions ou ao utilizar um padrão síncrono
Assíncrono - Uma Via Não Por definição, as chamadas de uma via não podem declarar falhas, significando que é impossível lançar uma ServiceBusinessException.
Assíncrono - Resposta Adiada Não Eventos com falha não são criados para service business exceptions
Assíncrono - Retorno de Chamada Não Eventos com falha não são criados para service business exceptions
Tabela 2. Padrões de Chamada e Relacionamento para a Criação de Eventos com Falha: Service Runtime Exceptions
Padrão de Chamada Evento com Falha Criado S/N? Notas
Síncrono Não Eventos com falha não são criados para service runtime exceptions ou ao utilizar um padrão síncrono.
Assíncrono - Uma Via Sim  
Assíncrono - Resposta Adiada Sim  
Assíncrono - Retorno de Chamada Sim  
BPEL - Duas Vias Não
Eventos com falha não são criados quando o componente de origem é um processo de negócios.
Nota: Para uma chamada assíncrona, se a resposta não puder ser retornada ao BPEL, um evento com falha será criado.
BPEL - Uma Via Sim  
Para obter informações adicionais, revise o tópico do centro de informações chamado Gerenciando Eventos com Falha.

Informações adicionais sobre como visualizar e reenviar eventos com falha podem ser localizadas na seção Reenviando Eventos com Falha.

Destinos do Barramento de Integração de Serviços

As mensagens que estão aguardando para serem processadas podem acumular em alguns destinos de Service Integration Bus (SIBus). Para a maior parte, estes destinos são destinos do "sistema". As mensagens nestes destinos geralmente são uma combinação de três tipos, conforme a seguir:
  • Pedidos assíncronos para processamento
  • Respostas assíncronas para pedidos
  • Mensagens assíncronas que falharam na desserialização ou na resolução do seletor de função
    Nota: As respostas assíncronas podem ser Objetos de Negócios válidos ou falhas retornadas como resultado de um pedido.

Destino do Módulo SCA

Novamente, consultamos nosso caso de negócios.

Haveria dois destinos de "Módulo SCA" na solução:
  • sca/AccountRouting
  • sca/AccountCreation

Estes destinos são criados quando o módulo é implementado em um servidor de aplicativos ou cluster.

Raramente as mensagens são acumuladas nestes destinos. A acumulação de mensagens nestes locais é uma forte indicação de que pode haver um problema de desempenho ou um defeito no aplicativo. Investigue imediatamente. É importante monitorar a profundidade dos destinos do módulo, (com sua solução de monitoramento de TI escolhida) pois um backup de mensagens poderia conduzir a uma interrupção do sistema ou a um tempo de reciclagem prolongado.

Nós chamamos estes destinos de "Módulo SCA" porque o nome gerado é o mesmo que o nome do módulo com o "sca/" adicional. Estes destinos são essenciais para o funcionamento de chamadas assíncronas de SCA (intermediando pedidos e respostas). Existe um número variável de destinos adicionais que são gerados durante a instalação do aplicativo no barramento SCA.SYSTEM mas, para a finalidade da discussão, estaremos abordando a importância do destino de "Módulo SCA".

Nova Tentativa de System Integration Bus

Conforme aprendemos acima, o FEM possui um mecanismo de nova tentativa integrado com o message driven bean (MDB) SCA. Este comportamento de nova tentativa pode ser controlado modificando o atributo "Máximo de Entregas com Falha" no destino do módulo.
Nota: Geralmente, não há razão para ajustar este recurso de nova tentativa. As informações fornecidas aqui servem para totalidade.

Consultando nosso caso de negócios, existem vários destinos SI Bus criados pelo SCA para suportar a comunicação assíncrona.

Como aprendemos, um destes destinos é chamado "sca/AccountRouting". É possível ajustar o número de novas tentativas que ocorrem durante uma ServiceRuntimeException de uma chamada de serviço assíncrono alterando o valor da propriedade "Máximo de Entregas com Falha" através do console administrativo. No entanto, você não pode configurar o valor como menor que 2 em módulos com um processo BPEL. A segunda entrega é necessária para retornar ServiceRuntimeExceptions ao BPEL para processamento.

Destinos de Exceções do Sistema

O failed event manager é um local que podemos consultar para administrar falhas. Ao lidar com Importações e Exportações baseadas em JMS ou EIS, é necessário considerar outro local importante.

Os destinos no barramento SCA.Application são configurados para rotear mensagens com falha para o destino de exceção do sistema SIB para esse barramento. Portanto, se uma exportação JMS coletar uma mensagem do barramento do Aplicativo SCA e se chegar em uma situação de recuperação, a mensagem com falha será roteada para o destino de exceção SIB em vez do destino de exceção de recuperação WBI. Este cenário se difere da discussão de eventos com falha acima porque uma falha ao desserializar uma mensagem no barramento SCA.Application não resultará em um evento com falha. Há um destino de exceção do sistema em cada barramento na solução. Estes destinos devem ser monitorados e administrados de maneira semelhante à "fila de devoluções" comum à infraestrutura do MQ.

Considere o seguinte cenário.

Diagrama Mostrando como Exceções do Sistema São Processadas.
Um cliente JMS externo coloca uma mensagem em uma fila de entrada exposta por meio de uma Exportação JMS. o MDB de Ligação de Exportação JMS coleta a mensagem para processamento. Aqui, ocorrerá uma de duas situações:
  1. A exportação JMS analisará com êxito a mensagem e determinará qual operação chamar na interface, em qual ponto a mensagem será enviada para o tempo de execução SCA para processamento.
  2. A exportação JMS falhará ao reconhecer o corpo da mensagem como um objeto de negócios válido ou a ligação de exportação JMS desserializará o corpo da mensagem mas não poderá determinar a operação apropriada na interface a ser chamada. Neste ponto, a mensagem é colocada no Destino de Exceção do Sistema para o barramento.

Podemos ter este tipo de falha ao tentar receber pedidos de AccountRoutingJMSExport (1). Esta exportação é uma exportação JMS e há uma possibilidade de os eventos acumularem no Destino de Exceção do Sistema no SCA.Application.Bus. Utilize a solução de monitoramento de TI escolhida para observar a profundidade deste destino.

Failed Event Manager e Destinos SIB

Para WebSphere ESB, o destino da exceção é configurado como a fila de destino de exceção do WebSphere ESB. Esta fila segue uma convenção de nomenclatura da seguinte forma:
Nome do Nó: WESBNode
Nome do servidor: server1
Destino de exceção de recuperação: WBI.FailedEvent.WESBNode.server1
Em geral, todos os destinos criados no barramento SCA.System serão configurados para rotear mensagens com falha para o destino de exceção de recuperação.

Quando ocorre uma falha do sistema, além de capturar a mensagem de falha neste destino de exceção, o recurso de recuperação do WebSphere ESB também gera um evento com falha que representa o erro do sistema e o armazena no banco de dados de Recuperação conforme descrito na seção Gerenciador de Eventos com Falha deste documento.

Resumo

Em resumo, WebSphere ESB fornece recursos administrativos acima e além da plataforma WebSphere Application Server subjacente. Medidas apropriadas devem ser tomadas para entender e utilizar estes recursos juntamente com seguir a orientação fornecida na seção Planejando a Prevenção de Erros de Planejando a Prevenção e Recuperação de Erros.

Tabela 3. Recursos Administrativos para Ajudar a Gerenciar Falhas
Recurso Administrativo Fornecido com o WebSphere ESB S/N? Resumo
Failed Event Manager Sim Acesso de Leitura/Edição/Exclusão. Este é o local central para administrar Service Runtime Exceptions e outras formas de falhas de infraestrutura.

Navegador do Barramento de Integração de Serviços

Sim

Leitura/Exclusão. Utilize o Navegador do Barramento de Integração de Serviços no console administrativo para procurar e desempenhar tarefas operacionais diárias nos barramentos de integração de serviços.

Nota: O número de eventos ou registros que podem ser administrados simultaneamente por estas ferramentas é específico para fatores externos como alocação de memória, conjuntos de resultados e ajuste do BD, tempo limite de conexão. Execute testes e configure os limites apropriados para evitar exceções (OOM, TransactionTimeOut).

concept Tópico de Conceito

Termos de Uso | Feedback


Ícone de registro de data e hora Última Atualização: 01 julho 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/crec_use_case_recovery.html
Copyright IBM Corporation 2005, 2010. Todos os Direitos Reservados.
Este Centro de Informações foi desenvolvido com tecnologia Eclipse (http://www.eclipse.org).