minimizar o impacto de erros de sistema e aplicativo.
Tópicos em Planejando a Prevenção e Recuperação de Erros incluem links para uma variedade de recursos, tais como tópicos do centro de informações, artigos técnicos e IBM Redbooks que fornecem informações detalhadas sobre processos de
desenvolvimento e padrões de configuração do sistema projetados para tirar vantagem dos recursos de recuperação do sistema WebSphere.
Visão Geral de Prevenção e Recuperação de Erros
As informações de prevenção e recuperação de erros descrevem como evitar problemas que podem causar falhas do sistema e fornece ou aponta para
informações sobre como recuperar-se de falhas do sistema que podem resultar de circunstâncias ordinárias e extraordinárias.
WebSphere Process Server é um servidor de middleware otimizado para ativar a execução e o gerenciamento das soluções BPM (Business Process Management) e SOA (Arquitetura Orientada a Serviços). WebSphere Process Server é baseado nos recursos fundacionais do WebSphere Application Server.
Os sistemas de middleware são executados em várias condições, nem todas são tradicionalmente condições de “caminho correto”. Muitos dos principais recursos no WebSphere Process Server destinam-se a lidar com a incerteza que pode surgir através do que parece ser uma operação normal.
Suposições e Expectativas
Antes de utilizar a informações sobre falha e recuperação do sistema conforme descrito na seção Planejando a Prevenção e Recuperação de Erros, leia a seguinte lista de suposições:
v Você está familiarizado com o WebSphere Process Server e os princípios
arquiteturais básicos sob os quais ele é baseado e os tipos básicos de aplicativos que ele executa.
v Você tem um entendimento fundacional dos projetos de integração, incluindo como planejar e implementar os projetos de integração.
v A menos que seja especificado de outra forma, as informações sobre falha e recuperação do sistema são relevantes para a versão 6.1.0 e posterior do WebSphere Process Server.
Nota: As informações contidas na seção Planejando a Prevenção e Recuperação de
Erros assume um padrão de sistema de mensagens remoto e de suporte remoto,
que consiste em três clusters separados, um para o WebSphere Process Server e um para o mecanismo do sistema de mensagens e o outro para o servidor de eventos de CEI.
Conceitos relacionados
“Topologias e Padrões de Ambiente de Implementação” na página 77
Há diferentes layouts de topologia. Antes de instalar e configurar o WebSphere Process Server, revise as informações nesta seção. Entender os conceitos da
topologia o ajudará a tomar decisões mais seguras sobre como instalar e configurar o produto.
Referências relacionadas
“Recuperação no mesmo Nível” na página 162
Recuperação no mesmo nível é uma recuperação conforme desempenhada por outro membro do mesmo cluster, e pode ser iniciada manual ou automaticamente. O processamento de recuperação no mesmo nível (recuperação no mesmo nível automatizada ou recuperação no mesmo nível manual) está estritamente ligado ao ambiente de alta disponibilidade do WebSphere.
Planejando a Prevenção de Erros
Assim como todos os esforços de TI, o planejamento e práticas para situações extremas aumentarão a possibilidade de uma recuperação bem-sucedida.
Existem várias considerações necessárias associadas à preparação para recuperação do sistema e do aplicativo. Estas considerações podem ser agrupadas em duas categorias, conforme a seguir:
v Práticas de prevenção de erros como parte do design do aplicativo
v Práticas de prevenção de erros como parte do processo de desenvolvimento
Prevenção de Erro como Parte do Design do Aplicativo
Incluir práticas de prevenção de erros como parte do design do aplicativo significa implementar técnicas de design específicas e usar os recursos do produto para evitar erros do sistema e do aplicativo.
Um sistema de controle forte, completo com diretrizes arquiteturais e de design e padrões apropriados combinados com revisões e pontos de verificação é essencial para criar o tipo de aplicativo correto.
As práticas de prevenção de erros como parte do design do aplicativo incluem o seguinte:
v Implementação de considerações de design para exceções e falhas
v Implementação de uma estratégia de manipulação de erros que use recursos e ferramentas de manipulação de erros do WebSphere Process Server
v Criação de grupos de conectividade e uso de técnicas de design do aplicativo do módulo
Grupos de Conectividade
Um grupo de conectividade representa um padrão específico de comportamento localizado em um módulo SCA.
Crie grupos de conectividade para representar as possíveis fontes do pedido para o sistema.
Em um grupo de conectividade, você:
v Coloca toda a lógica para obter os dados de entrada em um módulo Isto também ocorre para os dados de saída quando eles estão indo para um sistema externo ou um sistema legado
v Coloca toda a lógica para conectar e transformar os dados em um módulo Todos os outros módulos agora podem utilizar um conjunto padrão de interfaces e não precisam se preocupar com transformações extras.
O grupo de conectividade não conterá tipos de componentes com estado como processos de negócios de longa execução e Business State Machines. Estes grupos de conectividade fornecem encapsulação e isolamento dos requisitos de integração do terminal específico. Comumente, os módulos de mediação do WebSphere ESB são utilizados para esta finalidade por eles representam maneiras convenientes de implementar tarefas relacionadas à "infraestrutura".
O conceito de grupos de conectividade também oferece uma maneira conveniente de tornar o sistema inativo em caso de necessidade de recuperação. Como o módulo do grupo de conectividade é sem estado, o módulo pode ser parado temporariamente, interrompendo, assim, o fluxo de entrada de novos eventos enquanto o sistema conclui o processamento dos eventos que ele possui.
Nota: Se você desejar parar o fluxo de eventos de entrada, os módulos de
conectividade não deverão suportar entrada e saída no mesmo módulo (embora o mesmo sistema EIS possa ter entrada e saída). Se os suportes de entrada e saída estiverem no mesmo módulo, a saída será desativada com a entrada. Isto pode fazer com que o trabalho interno pare de concluir. Considere separar a entrada e a saída neste caso.
Quando o sistema é recuperado e está capaz de processar novo trabalho, esses módulos podem ser reiniciados.
O módulo descrito na captura de tela a seguir é considerado parte de um grupo de conectividade.
Os grupos de conectividade podem ser utilizados para entrada de uma fonte externa ou um sistema existente, como o SAP ou o CICS. Ou para novo trabalho a partir de clientes baseados em um navegador da Web.
Conceitos relacionados
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.
Referências relacionadas
“Ligações de Exportação” na página 164
Para tornar um sistema totalmente inativo, considere os diferentes tipos de chamadas de pedido suportadas pelas ligações de Exportação disponíveis.
Considerações de Design do Aplicativo para Exceções e Falhas
É necessário considerar o design do seu aplicativo para que ele possa tirar vantagem dos recursos de manipulação de erros e de processamento de falhas no WebSphere Process Server.
Para criar uma estratégia de manipulação de erros abrangente, os arquitetos da solução precisam entender como o WebSphere Process Server e o WebSphere ESB representam exceções declaradas e não declaradas.
O modelo de programação de SCA fornece dois tipos de exceções: v Service Business Exceptions
As Service Business Exceptions são exceções verificadas declaradas na assinatura de função de um método de negócios (falhas de WSDL ou lançamentos Java). As Service Business Exceptions identificam condições de erro que são previstas pelo aplicativo ou serviço. Estas exceções são, às vezes, referidas como "exceções verificadas"
Um exemplo é uma InvalidSymbolException para um serviço de cotação de ações. Tais exceções são agrupadas por ServiceBusinessException e retornadas ao cliente.
v Service Runtime Exceptions
Também conhecidas como "exceções do sistema", as service runtime exceptions não são declaradas na assinatura de método. Em geral, elas representam condições de erro que não são antecipadas pelo aplicativo, como uma NullPointerExceptionem um Componente Java.
Estas exceções são agrupadas por ServiceRuntimeException e retornadas ao cliente, que pode interrogar a ServiceRuntimeException para determinar a causa.
Nota: Ao trabalhar no nível de SCA, estas exceções são, às vezes, referidas como falhas. Entretanto, ao utilizar o código Java, elas geralmente são referidas como exceções.
Quando um ServiceRuntimeException é lançado de um componente, a transação atual é retornada.
Manipulação de Service Business Exception:
Service Business Exceptions representam exceções conhecidas e declaradas, previstas pelo aplicativo ou serviço.
Os desenvolvedores de componentes devem ter cuidado ao declarar as possíveis exceções que podem ser lançadas, para que o serviço de consumo possa
manipulá-las. Por exemplo, uma falha de negócios para um aplicativo financeiro incluiria "Número da Conta Inválido" ou "Fundos Insuficientes" como exceções de
negócios. Portanto, o aplicativo que chama o serviço precisa incluir a lógica para
manipular uma situação na qual ele transmitiu um número de conta inválido ou na qual ele tentou transferir $100, mas havia apenas $50 na conta. Existem os tipos de erros de negócios que um aplicativo de chamada foi projetado para manipular. As exceções de negócios do WebSphere Process Server são retornadas ao cliente para captura e manipulação de maneira apropriada.
Ao manipular exceções do serviço de negócios, os consumidores de serviço devem implementar o cliente para que ele desempenhe uma das seguintes ações para uma exceção de negócios declarada:
1. Capturar a exceção e criar a Service Business Exception apropriada para o aplicativo de chamada.
Isto poderia significar incluir a exceção original na nova exceção (agrupando-a). Isto é feito com mais frequência quando o módulo de chamada não possui as mesmas Business Exceptions que o serviço que ele está chamando. A seguir há um exemplo do fluxo capturando uma exceção e criando uma Service Business Exception para o aplicativo de chamada:
a. Módulo Apossui SBE "MoneyTransferFailed" b. Módulo Bpossui SBE "InsufficientFunds"
c. Módulo Achama Módulo B e obtém a exceção "InsufficientFunds"
d. Módulo A deve criar uma nova exceção "MoneyTransferFailed", que pode ter um local onde uma cadeia definindo o erro original de fundos insuficientes pode ser incluída.
2. Capture a exceção e desempenhe a lógica alternativa.
Conceitos relacionados
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.
Manipulação de Service Runtime Exception:
Service Runtime Exceptions são exceções não declaradas. Em geral, elas representam condições de erro que não são previstas pelo aplicativo.
Service Runtime Exceptions são utilizadas para sinalizar uma condição inesperada no tempo de execução.
Os desenvolvedores de componentes podem manipular Service Runtime Exceptions das seguintes maneiras:
1. Captura-as e desempenhar alguma lógica alternativa.
Por exemplo, se um parceiro não puder atender a um pedido, talvez outro possa.
2. Capturar a exceção e "relançá-la" para seu cliente. 3. Remapear a exceção para uma exceção de negócios.
Por exemplo, um tempo limite para um parceiro pode resultar em uma exceção de negócios que indica que a maioria dos pedidos foram processados, mas
houve uma parte do pedido que não foi concluída e deve ser tentada outra vez posteriormente com diferentes parâmetros.
Se uma exceção não for capturada, a exceção será transmitida para o componente que chamou o componente atual. Esta cadeia de chamadas continua de volta ao responsável pela chamada original na cadeia. Por exemplo, o Módulo A chama o Módulo B e o Módulo B chama o Módulo C e então o Módulo C lança uma exceção, o Módulo Bpode capturar ou não essa exceção. Se o Módulo B não capturar a exceção, então a exceção viaja de volta para o Módulo A.
Quando um ServiceRuntimeException é lançado de um componente, a transação atual é retornada. Esse tipo de processamento de exceção é repetido para todos os componentes na cadeia. Por exemplo, se uma ServiceRuntimeException é lançada de um Módulo C, essa transação será marcada para retroceder. Em seguida, a exceção é lançada para o Módulo B, onde se ela não for capturada e uma outra transação estiver presente, essa transação também retrocederá. Desenvolvedores de componente podem utilizar qualificadores quality of service (QoS) para controlar se chamadas ocorrem na transação atual ou em uma nova transação. Assim, se o Módulo A chama o Módulo B e o Módulo B é parte de uma nova transação, então o Módulo A pode "capturar" um ServiceRuntimeException do Módulo B e continuar o processamento, sem precisar do retorno da transação do Módulo A.
Nota: Como as exceções de tempo de execução não são declaradas como parte da interface, os desenvolvedores de componentes devem tentar resolver a exceção e, portanto, impedir que seja propagada inadvertidamente para o cliente, se o cliente for uma interface com o usuário.
Você precisa estar ciente de que o conteúdo da transação retornada pode variar, dependendo da natureza da transação. Por exemplo, processos BPEL de execução longa podem ser segmentados em muitas transações menores. Pedido assíncrono e chamadas de resposta são interrompidas por uma transação automaticamente (caso contrário o aplicativo de chamada teria que aguardar muito tempo pela resposta). Em ocorrências em que uma transação é dividida em várias chamadas assíncronas (em oposição a uma transação grande), o trabalho inicial da transação seria retornar a ocorrência de um ServiceRuntimeException. Entretanto, a resposta da chamada assíncrona seria enviada de uma transação diferente, e como a resposta da chamada assíncrona não teria lugar para ir, um evento é criado no Failed Event Manager (FEM).
A lista a seguir é de 4 subclasses atuais de ServiceRuntimeException: 1. ServiceExpirationRuntimeException
Esta exceção é utilizada para indicar que uma mensagem SCA assíncrona expirou. Os tempos de expiração podem ser configurados utilizando o qualificador RequestExpiration em uma referência de serviço.
2. ServiceTimeoutRuntimeException
Esta exceção é utilizada para indicar que a resposta a um pedido assíncrono não foi recebida dentro do período de tempo configurado. Os tempos de expiração podem ser configurados utilizando o qualificador ResponseExpiration em uma referência de serviço.
3. ServiceUnavailableException
Esta exceção é utilizada para indicar que foi lançada uma exceção durante a chamada de um serviço externo através de uma importação.
Esta exceção é utilizada para indicar que a referência de serviço no componente não está conectada corretamente.
Conceitos relacionados
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.
Informações relacionadas
Configurando Qualificadores e Transações
Prevenção de Erros como Parte do Desenvolvimento
Você pode incluir processos de prevenção de erros como parte de seus processos de desenvolvimento.
As práticas de prevenção de erros como parte de seu processo de desenvolvimento destinam-se a focalizar a governança e o processo de desenvolvimento em vigor para lançar projetos e envolve principalmente atividades de teste, ajuste, medida e novo teste.
As práticas de prevenção de erros como parte de seu processo de desenvolvimento podem incluir o seguinte:
v Prevenindo Problemas através do Teste Abrangente
v Ajuste de Desempenho Contínuo e Planejado Regularmente v Monitoramento de Infraestrutura
Prevenção de Erros: Teste Abrangente
É possível prevenir problemas que precisarão de recuperação implementando um plano de teste abrangente funcional e do sistema.
Em geral, os testes para soluções implementadas podem ser categorizados da seguinte forma:
v Teste funcional
Testes funcionais confirmam se a funcionalidade implementada em um
aplicativo atende aos requisitos de negócios indicados. Os testes funcionais são criados por usuários de negócios e designers do aplicativo.
v Teste do sistema
Os testes do sistema são designados para verificar o desempenho, alta disponibilidade e acordos de nível de serviço de recuperação.
Em um teste do sistema, é importante combinar aspectos como o teste de desempenho e o teste de alta disponibilidade para avaliar a recuperação de um sistema em situações de produção extrema.
Para os testes funcional e do sistema, a automação é altamente recomendada. O teste automatizado fornece à organização uma maneira eficiente de evitar a introdução de erros de regressões.
Conceitos relacionados
Recuperação: First Steps
Administradores podem facilitar os processos de recuperação da solução seguindo uma lista de verificação do First Steps de práticas gerais.
Informações relacionadas
Problem determination in WebSphere Process Server
Prevenção de Erros: Ajuste do Ambiente
Os exercícios de ajuste são uma parte regular do ciclo de vida de desenvolvimento do sistema. Com cada implementação do aplicativo principal, você deve planejar uma avaliação de desempenho.
Como um pré-requisito para implementação de uma solução em um ambiente de produção, você deve avaliar e testar a solução em um ambiente de pré-produção. Isto permitirá medir o impacto da nova solução em aplicativos existentes e os parâmetros e recursos atuais do sistema. Se não forem feitos a avaliação e teste da solução em um ambiente de pré-produção, haverá maior probabilidade de que a solução tenha problemas com recuperação.
Existem muitos recursos disponíveis publicamente que descrevem o processo e execução de planos de teste de desempenho. Revise os materiais e construa um plano de teste que seja apropriado para seu aplicativo e topologia.
Consulte os IBM Redbooks que contêm informações sobre o desempenho e o ajuste de WebSphere Process Server, bem como white papers técnicos sobre o
desempenho e ajuste do WebSphere Process Server. Além disso, você deve consultar os relatórios de desempenho que acompanham cada novo release do BPM (business process management) e produtos Connectivity da IBM.
Informações relacionadas
Ajustando
IBM WebSphere Business Process Management Performance Tuning Endurance testing with WebSphere Process Server
WebSphere Business Integration V6.0.2 Performance Tuning
Processos de Negócios Automáticos de Ajuste de Desempenho para Cenários de Produção com o DB2
WebSphere Process Server V6 – Ajuste de Desempenho de Fluxos de Trabalhos Manuais do Business Process Choreographer Utilizando Visualizações
Materializadas
Prevenção de Erro: Monitoramento de Infraestrutura
O monitoramento de infraestrutura e a utilização de ferramentas de
monitoramento de infraestrutura são um requisito para um sistema de produção. As ferramentas de monitoramento como ITCAM for SOA e Tivoli Performance Viewer permitem que os administradores do sistema monitorem o comportamento do sistema crítico e detectem problemas que possam causar uma interrupção. Um nível básico de monitoramento de TI para o sistema de produção é essencial para atender os acordos de nível de serviço de disponibilidade.
Para obter informações adicionais sobre como monitorar o desempenho e processos de negócios de seus eventos do componente de serviço, consulte a seção sobre Monitoramento no centro de informações do WebSphere Process Server.
Informações relacionadas
Monitoramento
Família IBM Tivoli Composite Application Manager for SOA:
É possível usar o IBM Tivoli Composite Application Manager Family (ITCAM) para a Arquitetura Orientada a Serviços (SOA) para monitorar o WebSphere Process Server. Além disso, é possível utilizar o ITCAM for SOA para automatizar a mediação de problemas e gerenciar a configuração e implementação da solução. O ITCAM for SOA inclui os seguintes recursos:
Gerenciar serviços SOA
v Visibilidade para interações de serviço SOA
v Visibilidade para o conteúdo da mensagem e padrões do fluxo de transações v Habilidade para identificar e isolar gargalos de desempenho nos limites de
tecnologia e de plataforma
v Instrumentação de Desempenho com base em Application Response Measurement (ARM) leve e Padrão de mercado
v Aplicação de políticas de alto desempenho e flexível v Instrumentação baseada em padrões para fácil integração
Monitorar processos de negócios
v Gerenciar processos em andamento
v Monitorar o Desempenho de Negócios de processos ativos v Detectar Situações de Negócios e executar ação
v Reunir Business Intelligence dos dados do processo coletados
v Monitoramento extremamente abrangente para identificar e corrigir rapidamente aplicativos inativos ou com pouco desempenho
v Métricas e análise de dados históricos em tempo real
Exemplos da Família ITCAM (IBM Tivoli Composite Application Manager) for SOA
O exemplo a seguir mostra como a Família ITCAM (IBM Tivoli Composite Application Manager) for SOA monitora serviços, tempos de resposta, contas de mensagens e tamanhos de mensagem.
O exemplo a seguir mostra uma tela medindo estatísticas por operação e limites