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.
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.
Em nosso caso de negócios, alavancamos um processo BPEL para o processo AccountCreation.
Os processos de execução curta são conhecidos como microfluxos.
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:
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.
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.
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
e alterar o valor no campo Máximo de Entregas 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.
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 |
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 |
Informações adicionais sobre como visualizar e reenviar eventos com falha podem ser localizadas na seção Reenviando Eventos com Falha.
Destino do Módulo SCA
Novamente, consultamos nosso caso de negócios.
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
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.
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
Nome do Nó: WESBNode Nome do servidor: server1 Destino de exceção de recuperação: WBI.FailedEvent.WESBNode.server1Em 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.
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.
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. |