La actividad “CheckPoint” salva el estado y datos de la
instancia de proceso en disco para, en caso de fallo del motor de BW, poder recuperar el estado en el punto del último
checkpoint salvado. Los checkpoints se utilizan para recuperar el estado de
las instancias de procesos en caso de fallo de motor por una excepción no
controlada o por una parada del motor desde TIBCO Administrator o TIBCO Hawk.
El comportamiento normal de BW en caso de fallo del engine
es el de recuperar la ejecución de todas la instancias de proceso que estaban
en ejecución desde el último “CheckPoint” especificado. Si no hay
“CheckPoint” especificado se recuperan las instancias desde la actividad de
inicio.
La Activad tiene gran
importancia en el caso de que el proceso de integración hay realizado alguna
acción que no deba realizarse 2 veces, es decir, que no queramos que un proceso
en caso de fallo/parada del engine se recupere desde la tarea de inicio.
1.1.1
Casos de Uso
- Recuperación
controlada después de caídas del motor
- Detección
de duplicados
1.1.2
Configuración
1.1.2.1
Configuración
Campos de la pestaña de configuración:
- Name.
Nombre de la actividad.
- Description:
Breve descripción de la actividad
1.1.2.1
Input
Por medio de la actividad
“CheckPoint” se puede detectar si se está procesando más de una vez un evento.
Configurando la pestaña “Input” es posible detectar y descartar el
procesamiento duplicado de eventos ya sea en una nueva instancia de proceso o
en una instancia recuperada (después de un fallo del engine).
En el campo “duplicateKey” se especifica un valor que debe
ser único para cada instancia de proceso. Este será el valor por el cual se
determine la existencia o no de eventos duplicados, por tanto debe escogerse un
valor de entrada de la tarea “Start” del proceso cuyo valor sea único para cada
evento.
Es posible colocar varias actividades “CheckPoint” en el
proceso, pero el valor de “duplicateKey” debe ser el mismo para todas las
actividades “checkPoint” de una instancia de proceso.
Procedimiento de detección de procesos duplicados:
1.
Recepción del mensaje de entrada y arranque de
la instancia de proceso.
2.
Ejecución de las actividades del proceso hasta
la primera actividad de “CheckPoint”. Fijación de un valor en “duplicateKey”,
3.
El motor de BW chequea la lista de valores de
“duplicateKey”
a.
Si ninguna otra instancia de proceso ha guardado
el mismo valor de “duplicateKey” entonces se almacena el valor y se completa la
actividad de “CheckPoint”
b.
Si alguna otra instancia ha almacenado
previamente el valor de “duplicateKey” se termina el proceso y se lanza una
excepción “DuplicateException”.
4. Una vez que se ha procesado
la primera actividad de “CheckPoint” y se ha almacenado un “duplicateKey” no se
puede utilizar otro valor distinto de “duplicateKey” en la misma instancia de
proceso.
Detalles del comportamiento
de la actividad de CheckPoint dependiendo del escenario en que se utilice.
1.1.3.1
Tolerancia a Fallo y Balanceo de Carga
En caso de configurar BW en FT (Foult Tolerante) o LB (Load
Balance) no encontramos en un escenario con múltiple motores de BW ejecutando
las instancias de los procesos.
La información de checkpoint se puede almacenar en base de
datos o sistema de ficheros. En el caso de tener múltiples engines de BW
ejecutándose en paralelo en diferentes máquinas es necesario almacenar la información
en base de datos.
1.1.3.2
Detección de Duplicados
En el caso de que el evento/mensaje que produce la creación
de una instancia de proceso necesite de confirmación para indicar que ha sido
tratado, después de la detección del duplicado hay que confirmar el mensaje
para que no se vuelva a tratar. El siguiente diagrama muestra esta situación:
Para tener más control sobre la detección de duplicados
tenemos varias propiedades del motor de BW:
- bw.engine.dupKey.enabled. Valor por
defecto ‘true’ indicando que se realiza detección de duplicados. Valor
‘false’ para no realizar detección de duplicados.
- bw.engine.dupKey.timeout.minutes.
Tiempo que permanecen almacenadas las claves duplicadas.
- -1.
Por tiempo indefinido
- 0.
Se elimina en cuanto se detecta un duplicado.
- bw.engine.dupKey.pollPeriod.minutes.
Periodo de polling para las dupkey expiradas.
Consultar
tib_bw_administration.pdf (capitulo 8) para ver cómo dar valor a estas variables.
1.1.3.3
Llamadas
a Procesos
La
actividad de CheckPoint salva el estado completo de la instancia de proceso. En
el caso de llamada a procesos dentro de un proceso tenemos dos posibilidades:
La
primera y por defecto, el subproceso se ejecuta en la misma instancia de
proceso, por tanto, la ejecución de una actividad de CheckPoint en el subproceso
guarda también el estado del proceso padre.
La
segunda opción es la de “spawn”. En este caso el subproceso se ejecuta en una
nueva instancia por lo que la ejecución de una actividad de CheckPoint en el
proceso hijo no almacena el estado del proceso padre.
La
opción de Spawn está disponible en la llamada al subproceso.
1.1.3.4
Arranque de proceso con http Request
Cuando
se produce una caída del motor de BW se cierra el socket para la tarea “http
Request” que produce el arranque del proceso, por lo tanto, la actividad de
CheckPoint debe estar después de la tarea “http Response”. En caso contrario,
al intentar hacer “http Response” se produce una excepción por no poder
responder al Request.
Esta situación también es aplicable a la actividad de “SOAP Request”.
1.1.3.5 Tareas de Confirmación
Tener
en consideración los procesos cuyo arranque se corresponde con un
evento/mensaje que requiere de confirmación para indicar que se ha procesado.
Para este tipo de procesos tenemos dos situaciones:
1. colocar
la actividad de CheckPoint antes de la confirmación del mensaje/evento. En este
caso el proceso recuperado en el punto de CheckPoint no podrá confirmar el
mensaje/evento. Por otro lado, como consecuencia del arranque del motor, se
volverá a gestionar (arrancar una nueva instancia de proceso) para el
evento/mensaje que no ha sido confirmado.
2. colocar la actividad de CheckPoint después de la actividad de
confirmación del evento/mensaje. En este caso la caída y re-arranque del motor
de BW no produce que se arranque una nueva instancia de proceso para el
evento/mensaje puesto que fue confirmado antes de la actividad de CheckPoint.
1.1.3.6
Fichero .tra
En el
fichero .tra del engine se puede activar/desactivar la recuperación desde
checkpoint a través de la propiedad:
bw.engine.autoCheckpointRestart={true|false}
1.1.3.7
Fallo
en instancia de proceso
El
comportamiento por defecto cuando una instancia de proceso falla es que se
elimine la información de los checkpoints. Para modificar este comportamiento y
posibilitar la recuperación de instancias de procesos que han fallado desde los
checkpoints definidos tenemos la propiedad:
bw.engine.enableJobRecovery={false|true}
Esta
propiedad se encuentra en el fichero de propiedades .tra del engine.
