Conector JMS Escuchar y Reconocer Actividades en Sesiones Transaccionadas¶

Objetivo¶

Una sesión transaccionada para una actividad de escucha JMS permite que un usuario reciba un mensaje y trabaje con sus datos, todo dentro de una transacción.

Mientras el mensaje se envía al sistema Jitterbit, el intermediario (como Apache ActiveMQ) bloquea el mensaje para que otros oyentes no puedan captar el mismo mensaje. Cuando el usuario está satisfecho con el procesamiento del mensaje, utiliza una actividad de reconocimiento para notificar al intermediario que elimine el mensaje bloqueado de la cola (acción: JBXCommit); en otras palabras, el mensaje se procesó con éxito y ya no es necesario.

Hay casos en los que, mientras se procesa el mensaje en el flujo de proceso, resulta adecuado devolver el mensaje a la cola para que pueda ser procesado de nuevo o por un agente de escucha diferente. En esos casos, la actividad de reconocimiento se puede utilizar para que el intermediario sepa que debe liberar el bloqueo del mensaje y dejar que se procese de nuevo (acción: JBXRollback).

Uno de estos casos son los eventos de falla. Por lo general, los mensajes se envían al sistema Jitterbit y luego a un Agente Privado de Jitterbit. Si bien la operación se ejecuta a través de la lógica comercial, es posible que el agente se bloquee, el servidor se apague o se produzca una excepción. En cualquiera de estos eventos, donde no se envió un JBXCommit explícito al intermediario, el intermediario revertirá el mensaje para evitar perder los datos. Revertir significa que el mensaje se devuelve a la cola para que cualquier consumidor activo de esa cola lo vuelva a procesar.

Descripción General¶

Para usar sesiones con transacciones con Jitterbit JMS Connector, se deben usar ciertas configuraciones. Este documento cubre esas configuraciones y brinda escenarios de ejemplo que muestran cómo se pueden usar las transacciones.

Actividad de Escucha de JMS¶

La actividad de escucha de JMS se configura como se describe en Actividades de escucha del conector JMS. Para aprovechar el reconocimiento basado en el cliente, la propiedad Sesión transaccionada debe establecerse en Verdadero.

Cuando un agente de escucha JMS de transacciones recoge un mensaje, esperará hasta que:

• Recibe un reconocimiento de JBXCommit:
  En este caso, la sesión se confirma y el mensaje se elimina del intermediario.
• Recibe un reconocimiento de JBXRollback:
  En este caso, la sesión se revierte, el intermediario elimina el bloqueo y el mensaje se vuelve a colocar en la cola.
• Desconexión de la conexión o sesión con el intermediario (Agente Privado detenido o fallado, apagado o fallado del servidor, etc.):
  En este caso, el corredor realizará una reversión automática para conservar el mensaje. La reversión solo ocurrirá siempre que el intermediario no haya recibido un JBXCommit explícito.
• Se alcanzó el tiempo de espera de reconocimiento:
  En este caso, se envía automáticamente un acuse de recibo de reversión al intermediario para liberar el mensaje nuevamente en la cola. Este umbral está ahí para abordar los casos en los que una operación se atasca en un estado de ejecución muy prolongado que está fuera del rango aceptable de procesamiento de mensajes.

Actividad de Reconocimiento de JMS¶

La actividad de reconocimiento de JMS permite controlar el destino de un mensaje mediante el envío de la acción JBXCommit o JBXRollback. Esto se logra especificando la actividad en Acknowledge Request Transformation.

• AcknowledgmentAction
  • Valores válidos: "JBXCommit" o "JBXRollback"
  • No distingue entre mayúsculas y minúsculas, pero debe escribirse como se indica
  • Cuando se ingrese en la transformación, incluya las comillas dobles de apertura y cierre, ya que es un tipo de cadena

• AcknowledgmentMessageID

  • Valor válido: el ID de mensaje JMS del mensaje recibido por JMS Listener

  • Este ID se puede extraer y guardar en una variable global al recibir el mensaje en Listen Response Transformation (ver captura de pantalla)

    

  • La variable global se puede usar para la propiedad AcknowledgmentMessageID en la Acknowledge Request Transformation

Tiempo de Espera de Reconocimiento¶

Esta propiedad permite al usuario especificar la cantidad de segundos después de los cuales un mensaje se retrotrae automáticamente. Esto evita que un mensaje se quede atascado en el procesamiento para siempre o durante más tiempo que el aceptable. Esta propiedad debe establecerse en la Transformación de solicitud de envío/publicación para la actividad JMS SendOrPublish.

Ejemplos¶

En estos ejemplos, recibimos un mensaje de una actividad de escucha JMS, extraemos el ID del mensaje JMS y lo guardamos en una variable. Luego, adjuntamos una Actividad de reconocimiento de JMS como la operación"En caso de éxito". Si todo va bien con la actividad de escucha de JMS, la actividad de reconocimiento simplemente confirma la transacción (eliminando el mensaje de la cola) cuando terminamos de procesar ese mensaje. De manera similar, se puede crear y adjuntar otra actividad de reconocimiento de JMS como la operación"En caso de falla".

Es importante tener en cuenta que, en muchos casos de uso, el reconocimiento de JMS no debería ser la siguiente operación en la cadena "En caso de éxito" si hay trabajo adicional que realizar con los datos del mensaje. En su lugar, se debe agregar la actividad de reconocimiento de JMS cuando todas (o casi todas) las operaciones se hayan completado correctamente y ya no necesitemos el mensaje.

Variación 1¶

JMS Listener con reconocimiento de compromiso con OnSuccess y reconocimiento de reversión con eventos OnFailure.

Variación 2¶

Esta variación muestra el uso de una operación de lógica de negocios adicional que realiza un trabajo adicional con los datos del mensaje. En esta variación, si el Listener o la lógica empresarial fallan, se producirá una reversión. Si todo pasa y Business Logic finaliza correctamente, confirmará la transacción.

Variación 3¶

Esta variación es muy similar al escenario anterior. Sin embargo, en lugar de comprometer automáticamente OnSuccess de la operación Business Logic, usamos una llamada a Jitterbit RunOperation() función en el Customer Logic Script para controlar exactamente en qué momento del secuencia de comandos queremos confirmar:

RunOperation("<TAG>Operations/4. JMS Acknowledge (Commit)</TAG>", true);

y una llamada similar en el secuencia de comandos si hay un error y es necesario revertir la transacción:

RunOperation("<TAG>Operations/3. JMS Acknowledge (Rollback)</TAG>", true);

Esto pone sobre el desarrollador la responsabilidad de determinar las condiciones para el éxito o el fracaso. Sin embargo, en ciertos casos de uso, esto puede ser esencial para el control deseado.

Consejos y Sugerencias¶

Configuración del Tiempo de Espera de Reconocimiento Cuando No Se Utiliza el Sistema Jitterbit¶

La propiedad de tiempo de espera de reconocimiento está disponible (en la actividad SendOrPublish) si se envía un mensaje a una cola desde dentro de Jitterbit. Pero, ¿qué sucede si desea controlar el tiempo de espera pero tiene un sistema diferente que inserta los mensajes en la cola? La solución: al crear un mensaje, simplemente agregue una propiedad Integer en el mensaje JMS con la clave JBXAcknowledgmentTimeout y un valor del tiempo de espera requerido en segundos.

Los Mensajes JMS Se Confirman Automáticamente Incluso Sin Llamar a la Actividad de Reconocimiento¶

Verifique para asegurarse de que JMS Listener esté configurado con Transacted Session establecido en True. Confirme que no hay ninguna actividad de reconocimiento relacionada que se esté disparando.

Los Mensajes Que Fallan Siguen Apareciendo Nuevamente y Fallando Nuevamente¶

Si, cuando ocurre una falla, los mensajes se revierten, se volverán a colocar en la cola. Dado que hay un oyente en la cola, recogerá el mensaje e intentará procesarlo nuevamente. Una solución es modificar la política de reenvío del intermediario (por ejemplo, Apache ActiveMQ) para ajustar los retrasos y contar para la cola de mensajes fallidos (DLQ).

Los Mensajes Que Siguen Fallando Eventualmente Desaparecen¶

Si el Modo de entrega de un mensaje se configuró en PERSISTENTE, entonces el mensaje no se perderá. Simplemente se ha movido a la Cola de mensajes fallidos (DLQ), según lo configuró el intermediario. Si el Modo de entrega de un mensaje era NON_PERSISTENT, entonces el mensaje se perdió después de una determinada cantidad de reenvíos (si supera la configuración del intermediario para el máximo de reenvíos).