Participe da Maratona Behind the Code! Prêmios e desafios incríveis te esperam, não perca! Inscreva-se aqui

Tratamento de Erros no IBM WebSphere Datapower SOA Appliance

Introdução

Atire a primeira pedra quem nunca passou por uma situação onde um erro inesperado aconteceu e o comportamento do seu software foi por água abaixo.

Durante o desenvolvimento de software tentamos evitar, identificar e remover condições de erros, entretanto não podemos assumir que a nossa entrega esteja livre de erros ou que erros gerados por falhas externas não venham a acontecer.

Esse tipo de situação é muito comum e praticamente todas as linguagens de programação modernas oferecem suporte para tratamento de erros em tempo de execução.

Uma prática adotada é tentar identificar e antecipar o maior número de situações de erros possíveis durante o desenvolvimento do software, seja através de depuração em busca de erros de projeto ou por outros tipos de erros, como os oriundos de falhas externas, como por exemplo: um conjunto de dados de entrada inválido, um timeout em uma conexão com um servidor banco de dados, uma chamada para um operação não permitida em um WebService, etc.

Uma vez que esses erros foram identificados, em tempo de desenvolvimento, passamos a nos preocupar em como implementar o tratamento adequado no nosso software para a recuperação desses erros ou até mesmo o término do programa de forma consistente. Uma saída comum é apresentar para o usuário uma mensagem mais agradável e descritiva sobre o estado de erro que o software passa ou passou, para o que mesmo tome alguma atitude, quando aplicável.

Existem ainda situações onde não conseguimos antecipar e nos preparar para um determinado erro, nesse caso, podemos lançar mão de um tratamento de erro mais genérico.

Na sequencia deste artigo iremos abordar algumas das opções para o tratamento de erros no desenvolvimento de fluxos de integração do IBM WebSphere DataPower SOA Appliance.

Estas opções são validas para os appliances: IBM WebSphere DataPower XA35 XML Accelerator, IBM WebSphere DataPower XS40 Security Gateway, IBM WebSphere DataPower XI50/XI50B/XI50z/XI52 Integration Appliance, IBM WebSphere DataPower XM70 Low Latency e IBM WebSphere DataPower XB60/XB62 B2B Integration. Com firmware versão 3.8.0.0 ou superior.

Tratamento de Erros no IBM WebSphere DataPower SOA Appliance

O IBM WebSphere DataPower possui suporte para tratamento de erro (Error Handling) para Políticas de Processamento (Processing Policy). Nesta seção vamos conhecer como utilizar os recursos disponíveis para isso (Error Rule e On Error action).

A forma mais rápida e simples de tratar um erro no WebSphere DataPower é através de um Error Rule.

Vamos entender melhor um pouco o funcionamento de uma regra do tipo Error Rule.

Error Rule é uma regra que podemos incluir dentro da lista de regras da política de processamento (Processing Policy) que estamos trabalhando, cujo valor para o campo Rule Direction deve ser Error, conforme apresentado na Figura 1.

Figura 1. Rule Directon definido como Erro

alt

Quando uma condição de erro surge dentro de uma política (mais precisamente durante a execução de alguma regra dessa política), o WebSphere DataPower automaticamente começa uma busca sequencial à procura de uma regra do tipo Error Rule que tenha sido configurada.

Essa pesquisa ocorre da primeira regra para a última, filtrando por regras definidas como Error no campo Direction. A busca é interrompida quando uma dessas regras atenda os critérios definidos no Match Action e então a regra encontrada é iniciada.

Figura 2. Mecanismo de busca para Error Rule

alt

Na Figura 2, temos um exemplo de uma regra (error_handler_devworks_br) que é utilizada para gerar um HTML de uma página de erro para o usuário através da ação Transform.

É possível existir mais de uma regra de erro na lista de regras. O que vai determinar qual delas será a escolhida é o primeiro Match Action que seja avaliado como verdadeiro, daí também a importância de nos preocuparmos com a ordenação das regras, da mesma forma que é feito para as normais (Figura 3).

Figura 3. Ordenação de regras

alt

Agora que já sabemos como trabalhar com o Error Rule, vamos conhecer uma outra forma de tratamento de erros, que permite um controle maior e mais refinado na maneira de tratar os erros.

Em qualquer tipo de regra que não seja um Error Rule – por exemplo, Server to Client, Client to Server ou Both Directions – pode-se inserir, como parte do fluxo, uma ação chamada On Error, a qual nos permite ter um controle mais preciso sobre como vamos tratar os erros dentro do fluxo em questão.

Figura 4. Uma ação On Error inserida dentro de uma regra Server to Client

alt

Nos passos a seguir, veremos como inserir uma ação On Error em uma regra e conhecer as configurações possíveis.

Muito embora o tratamento de erros seja algo bastante utilizado, a ação On Error não está visível na paleta de ações padrão, mas sim listada junto com outras opções disponíveis dentro da ação Advanced .

Figura 5. Ação Advanced na paleta de ações

alt

O procedimento não foge do padrão; devemos arrastar e soltar a ação Advanced para dentro do fluxo. Lembrando que essa ação deve estar depois da ação de Match e antes da ação de Return.

Figura 6. Ação Advanced inserida em um regra

alt

A ação Advanced é bem versátil, afinal podemos configurá-la para diferentes tipos de ações e a que estamos interessados agora é a ação On Error. Com um duplo clique uma nova janela é apresentada, e então podemos selecionar a ação desejada, nesse caso, a ação relacionada com o tratamento de erros (Figura 7).

Figura 7. Configurando uma ação Advanced

alt

Ainda na mesma janela, pressionando o botão Next , temos acesso a todas as configurações da ação On Error.

Antes de falarmos das configurações dessa ação, vamos entender em quais situações e condições ela entra em cena.

Um ponto muito importante para destacar é que na presença de uma ação On Error, o comportamento do WebSphere DataPower é diferente daquele que vimos no início desse artigo, pois quando On Error faz parte do fluxo, o WebSphere DataPower não mais fará automaticamente a varredura buscando por uma regra do tipo Error Rule, como visto na Figura 2, que atenda a condição determinada na ação de Match . Dessa vez, o WebSphere DataPower passará o controle para a ação On Error , que deverá saber como proceder de acordo com suas configurações. Logo veremos como fazer isso.

Existem ainda situações onde em uma mesma regra queremos tratar erros de formas diferentes. Por exemplo, em uma regra onde exista uma ação de validação de Schema XML e outra ação para transformação XSLT, podemos facilmente inserir nessa mesma regra duas (ou mais) ações On Error para cada situação distinta de erro a ser tratada.

Figura 8. Duas ações On Error na mesmo regra

alt

Para o caso apresentado na Figura 8, devemos sempre ter em mente que na execução da regra, ao encontrar uma ação On Error, a mesma é colocada no escopo (foco). A partir desse momento, qualquer erro que ocorra nas ações posteriores fará com que o controle seja passado para a ação On Error que esta no escopo. Esse comportamento é válido até que uma outra ação On Error seja executada durante o fluxo; nesse caso, o ciclo se repete, ou seja, essa ação On Error pelo qual o processamento esta passando é colocada em escopo, substituindo a anterior e ficando responsável pelo tratamento dos erros daquele ponto em diante. Vamos entender melhor analisando a Figura 9.

Figura 9. Comportamento com duas ações On Error na mesma regra

alt

Verificando a Figura 9 podemos entender que caso um erro durante o processamento da regra aconteça em qualquer umas das ações marcadas em verde (Verify ou Validate) o controle será passado para a ação On Error definida antes destas ações (indicada com a letra A na figura). O mesmo se repete na parte final da regra, ou seja, qualquer erro que aconteça nas ações marcadas em laranja fará com que o processamento da regra seja passado para a ação On Error definida anteriormente a estas ações (indicada com a letra B na figura). Isso se torna bastante útil quando temos que oferecer tratamento de erros distintos para cada ação, ou grupo de ações dentro da regra.

Por exemplo, para erros em validação de Schema XML, poderíamos devolver uma mensagem customizada para a aplicação cliente informando sobre a situação de erro. Já para erros em uma transformação, poderíamos desviar o fluxo e tentar transformar o conteúdo para um formato padrão. Esses dois exemplos são possíveis através das configurações das ações On Error

Agora que vimos como a ação On Error é acionada, veremos como utilizá-la, para isso é necessário configurar individualmente cada uma das ações On Error presentes.

Durante a criação de um On Error ( ou através de um duplo clique), a janela de configuração é carregada e nela encontramos várias possibilidades de configurações para o tratamento de erro. É nessa janela que podemos definir se a execução da regra atual será cancelada (Cancel) na existência de um erro, ou irá continuar (Continue), ou ainda ser direcionada para outra regra (Alternative).

Figura 10. As três opções para Error Mode

alt

Falando mais de cada uma dessas opções, Continue irá direcionar o controle para a Error Rule indicada e logo após irá continuar o processamento na ação subsequente àquela em que o erro foi gerado. É o cenário típico onde um erro não é critico o suficiente a ponto de interromper o fluxo, mas mesmo assim se faz necessário uma ação para tratar esse erro (a geração de um log, ou evento snmp, etc.). O Error Mode como Cancel é a opção que interrompe definitivamente o processamento da regra onde o erro aconteceu, sem ir até o seu final, e opcionalmente entrega o controle para a regra Error Rule selecionada.

Figura 11. Definição de um Error Rule para execução em caso de erro

alt

Já o campo Error Mode como Alternative permite que uma outra regra, definida como reutilizável (não é um Error Rule), seja executada. Esta seria uma maneira de executar um processamento alternativo em uma situação de erro.

Figura 12. Configuração de Error Mode como Alternative

alt

Opcionalmente podemos usar o campo Processing Rule para ler qual regra deverá ser executada através do conteúdo de uma variável que pode ser definida previamente.

Figura 13. Usando variável para buscar a regra a ser executada

alt

Para finalizar a configuração da ação On Error, ainda podemos alterar os valores para os campos Error Input, Error Output e Asynchronous, todos opcionais.

Figura 14. Possibilidade de Configurar os contextos para Input e Output

alt

Para os campos Error Input e Error Output definimos quais contextos de Input e Output , respectivamente, serão usados na regra Error Rule que será acionada para o tratamento de erro. Quando não preenchemos esses campos, o comportamento padrão é passar para os contextos de Input e Output da Error Rule os mesmos contextos presentes na ação que gerou o erro. Por exemplo, durante o processamento em uma regra, uma ação de validação falhou; neste momento, o contexto (input e output) da validação, será passado para a regra de tratamento de erro definida (Error Rule) na configuração da ação On Error. Esse é o comportamento padrão, que pode ser facilmente alterado escolhendo outros contextos nomeados através do preenchimento explícito dos campos Error Input e Error Output.

Vale lembrar que se um Error Rule tem como objetivo final devolver uma mensagem para a aplicação cliente (um browser, por exemplo), o contexto para Error Output deve ser definido como OUTPUT.

Conclusão

Neste artigo verificamos que, existindo ou não uma ação On Error, o tratamento de erros sempre passa por uma regra do tipo Error Rule. Podemos entender, então, que uma regra do tipo Error Rule é o ponto final para o tratamento de erros. Entretanto, quando usamos uma ação On Error como parte de uma regra normal, nos é permitido um controle maior e um certo vínculo sobre quais ações dentro dessa regra deverão ser tratadas por um determinado Error Rule, lembrando também que podemos ter mais de um Error Rule por política e mais do que um On Error por regra.

Embora a simplicidade seja um ponto forte na implementação do tratamento de erros no IBM WebSphere DataPower, esse mecanismo traz algumas peculiaridades que devemos entender a fim de saber quando utilizar somente um Error Rule ou uma ação On Error, ou os dois em conjunto para compor um cenário mais poderoso e flexível .

Nos próximos artigos será mostrado como construir exemplos para cada um dos cenários de configuração abordados neste texto.

Recursos