Control de excepciones en BPM12c


Tenemos un bpm al que queremos blindar en caso de fallos en llamadas a service tasks. Lo vamos a hacer de dos formas, ambas válidas.

Screenshot from 2015-02-25 00:53:31

En la primera “Service Task” hemos puesto un catch error y lo hemos configurado para que atrape todas las excepciones de negocio y de sistema.

Screenshot from 2015-02-25 00:58:20

En caso de error, el flujo va a ir por la rama que tiene la notificación y el temporizador, para volver a invocarse “Service Task” una vez que el temporizador ha terminado.

Para controlar erorres en “Service Task1”, el enfoque que hemos seguido es crear “Subprocess” con un comienzo con disparador de tipo “error”. En el subproceso hemos añadido “Service Task2” que en este caso invoca de nuevo a “Process”, es decir, volvemos al principio.

Para provocar errores vamos a parar y arrancar deliberadamente el enpoint de “Service Taskx”, que es en todos casos de este ejemplo un mismo proceso bpm al que invocamos a partir de su wsdl.

OBSERVACIONES

Si el endpoint del servicio no está operativo se atrapan los errores en “Service Task”, el temporizador salta y hasta que el servicio no está operativo, sigue repitiéndose indefinidamente hasta que el servicio está operativo.

Screenshot from 2015-02-25 01:11:35

En este momento “Process” aparecerá “Recovered”

Screenshot from 2015-02-25 01:14:53

El modo de protección mediante “Subprocess” es una manera de tener un manejador de errores para todo el proceso de manera que podemos compensar, volver a empezar, terminar o lo que proceda en cada caso de uso.

Primer ciclo:

Screenshot from 2015-02-25 01:20:41

Segundo ciclo, se vuelve a llamar a “Process”

Screenshot from 2015-02-25 01:20:12

La secuencia:

Screenshot from 2015-02-25 01:20:27

QUE HUBIERA PASADO SIN CONTROL DE EXCEPCIONES?

Al ser la parada del endpoint un error recuperable, podríamos haberlo recuperado mediante la consola /em:

Screenshot from 2015-02-25 01:24:57

CONCLUSIONES
Es recomendable blindar los BPM ante errores intentando no añadir excesiva complejidad en la gestión de excepciones para que sean fáciles de entender. Obviamente el principo de no complejidad también es recomendable aplicarlo al BPM primigenio cuando todavía no tiene la gestión de excepciones implementada, de lo contrario será “doblemete” complicado de entender y mantener.

ARTEFACTOS

https://www.dropbox.com/s/7hzykfslkt5eeq8/rob.exp?dl=0

DISCLAIMER

Este ejemplo, con fines didácticos, no debe aplicarse a casos reales porque:

– el mecanismo de timer cíclico sin fin no es adecuado para un caso real

– para errores técnicos, existen mecanismos del producto para controlar el número de reintentos

MAS INFO

https://community.oracle.com/docs/DOC-910406

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.