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.
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.
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.
En este momento “Process” aparecerá “Recovered”
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:
Segundo ciclo, se vuelve a llamar a “Process”
La secuencia:
QUE HUBIERA PASADO SIN CONTROL DE EXCEPCIONES?
Al ser la parada del endpoint un error recuperable, podríamos haberlo recuperado mediante la consola /em:
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
approaching off the bow 