Acerca del ejemplo del Manejador de errores

El ejemplo del Manejador de errores se basa en un escenario en el que un negocio implicado en el proceso de transacciones desea desarrollar una rutina para gestionar errores. El ejemplo muestra cómo utilizar algunas de las características proporcionadas con WebSphere Message Broker.

Algunas empresas, como los bancos, desean asegurarse de que las transacciones se procesan sólo una vez y que hay un registro de errores. En el ejemplo del Manejador de errores, los mensajes sobre números de empleado pasan a través de un flujo de mensajes que actualiza una base de datos con esta información. Al poner un mensaje con un número de personal no válido, se puede observar cómo funciona la rutina de gestión de errores.

El ejemplo del Manejador de errores muestra las siguientes tareas:

Los mensajes

Se facilitan dos mensajes de entrada para ejecutar el ejemplo de Manejador de errores: un mensaje que contiene un número de serie válido de personal y un mensaje que contiene un número de serie no válido de personal.

El mensaje de personal válido se proporciona en XML, de la manera siguiente:

<Staff>
   <StaffNumber>1</StaffNumber>
   <NameInfo>
      <LastName>Smith</LastName>
      <FirstName>Jack</FirstName>
   </NameInfo>
</Staff>

 

El mensaje de personal no válido se proporciona en XML, de la manera siguiente:

<Staff>
   <StaffNumber>99</StaffNumber>
   <NameInfo>
      <LastName>Doe</LastName>
      <FirstName>Jane</FirstName>
   </NameInfo>
</Staff>

 

Los flujos de mensajes

La siguiente figura muestra el flujo de mensajes principal (main).

Una captura de pantalla del flujo de mensajes principal.

La figura siguiente muestra el subflujo de manejo de errores.

Una captura de pantalla del subflujo de manejo de errores.

La siguiente tabla lista los tipos de nodos que se usan en el ejemplo de Manejador de errores. El nodo Subflow no es técnicamente un nodo y no está disponible en la paleta de nodos; el nodo Subflow representa únicamente de dónde se llama al subflujo, Error_Handler.msgflow, dentro del flujo de mensajes principal.

Tipo de nodo Nombre de nodo
MQInput STAFF_IN
MQOutput STAFF_FAIL; STAFF_OUT
Database Update Staff Database; Update Error Database
Filter Check Valid Staff Number; Check Backout Count
Throw Throw; Throw to Complete Rollback
TryCatch TryCatch
Subflow Error_Handler

Si desea ver más información, lea lo referente a los nodos en los flujos de mensajes del ejemplo de Manejador de errores en la documentación de WebSphere Message Broker.

Ruta seguida por el mensaje válido de personal

Cuando pone el mensaje de personal válido en la cola de entrada, el mensaje se desplaza a través de los nodos, tal como se describe a continuación. Si se ha inhabilitado alguna de las colas, el mensaje no podrá seguir esta ruta.

En el flujo de mensajes principal:

  1. STAFF_IN. El nodo obtiene el mensaje de entrada de la cola de entrada.
  2. Error_Handler. Este nodo representa el subflujo de gestión de errores. Ahora el mensaje deja el flujo de mensajes principal y entra en el subflujo.

En el subflujo:

  1. Start Subflow. El mensaje se pasa al nodo siguiente en el flujo.
  2. Check Backout Count. El nodo comprueba si el contador de restituciones es cero. Puesto que es la primera vez que el mensaje de entrada pasa por este nodo, actualmente el contador es cero y el mensaje se pasa al nodo siguiente. Si el contador fuera mayor que cero, el mensaje se elimina.
  3. TryCatch. Ya que el número de personal es válido, el mensaje se pasa al nodo Back To Main Flow. Si el número de personal en el mensaje no es válido y el proceso del mensaje ha llegado a un punto en el que esto se ha descubierto, el mensaje se pasa al nodo Update Error Database.
  4. Back To Main Flow. En este punto, el mensaje deja el subflujo y vuelve al flujo de mensajes principal.

En el flujo de mensajes principal:

  1. Check Valid Staff Number. Ya que el número de personal es válido, el mensaje se pasa al nodo Update Staff Database.
  2. Update Staff Database. La base de datos STAFFDB se actualiza con los detalles de personal que hay en el mensaje.
  3. STAFF_OUT. El nodo pone el mensaje en la cola STAFF_OUT.

Ruta seguida por el mensaje no válido de personal

Cuando pone el mensaje de personal no válido en la cola de entrada, el mensaje se desplaza a través de los nodos, tal como se describe a continuación. Si se ha inhabilitado alguna de las colas, el mensaje no podrá seguir esta ruta. Para obtener más información sobre lo que hace cada nodo, pulse en los nodos de las figuras, en el tema principal.

En el flujo de mensajes principal:

  1. STAFF_IN. El nodo obtiene el mensaje de entrada de la cola de entrada.
  2. Error_Handler. Este nodo representa el subflujo de gestión de errores. Ahora el mensaje deja el flujo de mensajes principal y entra en el subflujo.

En el subflujo:

  1. Start Subflow. El mensaje se pasa al nodo siguiente en el flujo.
  2. Check Backout Count. El nodo comprueba si el contador de restituciones es cero. Puesto que es la primera vez que el mensaje de entrada pasa por este nodo, actualmente el contador es cero y el mensaje se pasa al nodo siguiente. Compare con el paso 13, más abajo.
  3. TryCatch. El número de personal en el mensaje no es válido, pero esto todavía no se ha descubierto. Como resultado, el mensaje de entrada se pasa al nodo Back To Main Flow, en lugar de al nodo Update Error Database.
  4. Back To Main Flow. En este punto, el mensaje deja el subflujo y vuelve al flujo de mensajes principal.

En el flujo de mensajes principal:

  1. Check Valid Staff Number. Puesto que el número de personal no es válido, el mensaje se pasa al nodo Throw Exception, en lugar de al nodo Update Staff Database.
  2. Throw Exception. El nodo detiene el proceso del mensaje y añade el número de error "3001" y el texto "Invalid staff number" al contenido del mensaje. Ahora se 'restituye' el mensaje. Es decir, el mensaje se propaga de vuelta al punto de control que, en este caso, es el nodo TryCatch en el subflujo.

En el subflujo:

  1. TryCatch. El nodo reconoce que se ha producido una excepción en el proceso del mensaje y lo pasa al nodo Update Error Database.
  2. Update Error Database. La base de datos ERRORDB se actualiza con los detalles del error, tal como se ha definido en el nodo Throw exception (paso 8).
  3. Throw To Complete Rollback. El nodo detiene el proceso del mensaje y añade el número "3002" y el texto "From Error_Handler message flow. See ERRORDB for details" al contenido del mensaje. A continuación, el mensaje se propaga de vuelta al punto de control, que es el nodo STAFF_IN en el flujo de mensajes principal.
    Esta es la fase final del proceso de captación. Tiene el efecto de restituir toda la transacción, incluidas las actualizaciones de base de datos bajo control transaccional (es decir, la actualización STAFFDB en el flujo principal) en la ruta de intento original. Sin embargo, la actualización ERRORDB, que está fuera del control transaccional, sigue confirmada.

En el flujo de mensajes principal:

  1. STAFF_IN. Puesto que se ha producido una excepción en el proceso del mensaje, éste se pasa al nodo STAFF_FAIL en lugar de pasarlo a través del flujo de mensajes de nuevo.
  2. STAFF_FAIL. El nodo pone el mensaje en la cola STAFF_FAIL. De forma alternativa, si la cola STAFF_FAIL está inhabilitada, el mensaje no se detiene aquí. Se pasa de nuevo al nodo STAFF_IN y, a continuación, al subflujo. A continuación, el mensaje llega al nodo Check Backout Count. El nodo comprueba si el contador de restituciones es cero. Puesto que el mensaje ha pasado a través de este nodo anteriormente, el contador de restituciones ya no es cero y el mensaje se elimina. Al eliminar el mensaje se evita que se produzca una situación en la que, si la cola STAFF_FAIL está inhabilitada, el mensaje sigue desplazándose por el flujo una y otra vez. Compare con el paso 4, más arriba.

Cuando utiliza un nodo TryCatch o cuando adjunta nodos al terminal de captación de un nodo MQInput, puede suponer que cualquier proceso que se haya producido en la ruta de prueba, si los nodos están configurados correctamente, no se confirmarán si se llama a la ruta de captación. Sin embargo, éste no es el caso. Por ejemplo, si se actualiza una base de datos en la ruta de prueba bajo control transaccional, y se llama a la ruta de captación y ésta se completa normalmente, la actualización de base de datos seguirá confirmada.

El requisito en este ejemplo es leer un mensaje, actualizar una base de datos y escribir el mensaje en otra cola. Si se produce un error, se restituye la actualización de la base de datos. El proceso de captación actualiza la base de datos de errores con los detalles del error y graba el mensaje original en la cola de anomalías. En términos de programación, esto es lo que sucede:

BEGIN (Start 'outer' unit-of-work.)
MQGET (Get message from the input queue.)
TRY
   BEGIN (Start 'inner' unit-of-work.)
   Update database
   MQPUT (Put message onto the output queue.)
   IF ERROR
      ROLLBACK inner unit-of-work GO TO CATCH
   ELSE
      COMMIT inner and outer unit-of-work as one unit-of-work
   END IF
CATCH
   Update error database
   MQPUT (Put message onto the failure queue.)
   COMMIT unidad de trabajo externa

Sin embargo, el gestor de transacciones XA y WebSphere MQ no dan soporte a dos niveles de unidades de trabajo en la misma aplicación. A consecuencia de esto, el ejemplo de manejador de errores utiliza las siguientes estructuras:

Hay dos bases de datos en este ejemplo, en lugar de sólo una, porque en WebSphere MQ no se puede utilizar la misma conexión de base de datos para las transacciones coordinadas y las no coordinadas, en el mismo flujo de mensajes. En el ejemplo del Manejador de errores, la actualización de base de datos en el flujo de mensajes principal está bajo control transaccional, de forma que si se produce un error, la actualización se restituye y no se confirma. La actualización de base de datos en el subflujo no está bajo control transaccional, de forma que la actualización siempre se confirma. Como resultado, el ejemplo del Manejador de errores requiere dos bases de datos aparte.

Si desea ver más información, lea lo referente a la coordinación de transacciones en flujos de mensajes en la documentación de WebSphere Message Broker.

Icono de la página principal   Volver a la Página de presentación de ejemplos