Acerca del flujo de mensajes XML_CancelReservation

El flujo de mensajes XML_CancelReservation cancela las reservas listadas en el mensaje de entrada y actualiza la base de datos del usuario para mostrar que hay menos reservas y más asientos disponibles. El flujo de mensajes XML_CancelReservation puede procesar una lista de números de reserva de forma que las reservas no tengan que cancelarse una a una.

El diagrama siguiente muestra el flujo de mensajes XML_CancelReservation.

Una captura de pantalla del flujo de mensajes XML_CancelReservation

La siguiente tabla lista los tipos de nodos utilizados en el flujo de mensajes XML_CancelReservation.

Tipo de nodo Nombre de nodo
MQInput XML_CANCELRESERVATION_IN
Compute DeleteReservation; IncrementSeat
Trace Trace; Trace1; Trace2
MQOutput XML_CANCELRESERVATION_FAIL1_1; XML_CANCELRESERVATION_FAIL1_2; XML_CANCELRESERVATION_FAIL2; XML_CANCELRESERVATION_OUT

Para obtener más información sobre los nodos que se utilizan en este ejemplo, consulte Nodos incorporados en la documentación de WebSphere Message Broker. Para ver el ESQL que se utiliza en el flujo de mensajes, consulte Crear el flujo de mensajes XML_CancelReservation.

El flujo de mensajes XML_CancelReservation realiza las siguientes operaciones:

  1. El nodo XML_CANCELRESERVATION_IN obtiene el mensaje de entrada de la cola XML_CANCELRESERVATION_IN e identifica el mensaje de entrada como perteneciente al dominio XMLNSC. Por lo tanto, el flujo de mensajes debe analizar el mensaje utilizando el analizador XMLNSC.
  2. El nodo XML_CANCELRESERVATION_IN pasa el mensaje a través del terminal Out al nodo DeleteReservation. De forma alternativa, si se ha generado una excepción en sentido descendente y el mensaje se ha restituido a este punto, el nodo XML_CANCELRESERVATION_IN pasa el mensaje a través del terminal Catch al nodo XML_CANCLERESERVATION_FAIL1_1, que coloca el mensaje en la cola XML_CANCELRESERVATION_FAIL1.
  3. El nodo DeleteReservation comprueba la tabla XMLPASSENGERTB de la base de datos RESERVDB para ver si las reservas listadas en el mensaje de entrada existen.
  4. Si la reserva existe, el nodo DeleteReservation elimina la tabla de pasajeros XMLPASSENGERTB listada en el mensaje de entrada. El nodo DeleteReservation pasa el mensaje a través del terminal de salida al nodo Trace1. El nodo Trace1 anota el estado del mensaje después de que haya salido del nodo DeleteReservation. El rastreo se almacena en las anotaciones de error locales, que son el visor de sucesos en Windows y el syslog en Linux. El nodo Trace1 pasa el mensaje al nodo IncrementSeat.
  5. Si no existen reservas, el nodo DeleteReservation pasa el mensaje a través del terminal Failure al nodo Trace. El nodo Trace rastrea y anota los problemas, como por ejemplo XML no válido, que ha provocado que el mensaje pasara al nodo Trace. El rastreo se almacena en las anotaciones de error locales. El nodo Trace pasa entonces el mensaje a través del terminal Out a XML_CANCELRESERVATION_FAIL1_2, que transfiere el mensaje a la cola XML_CANCELRESERVATION_FAIL1.
  6. El nodo IncrementSeat actualiza la tabla XMLFLIGHTTB en la base de datos RESERVDB para mostrar que han quedado disponibles cuatro asientos (dos en cada clase). El nodo IncrementSeat pasa entonces el mensaje a través del terminal Out al nodo XML_CANCELRESERVATION_OUT, que transfiere el mensaje a la cola XML_CANCELRESERVATION_OUT. De forma alternativa, si hay algún problema al actualizar la tabla XMLFLIGHTTB, el nodo IncrementSeat pasa el mensaje al nodo Trace2. El nodo Trace2 rastrea el mensaje mientras fluye entre el nodo IncrementSeat y el nodo XML_CANCELRESERVATION_FAIL2. El rastreo se almacena en las anotaciones de error locales. El nodo XML_CANCELRESERVATION_FAIL2 transfiere el mensaje a la cola XML_CANCELRESERVATION_FAIL2.

El flujo de mensajes XML_CancelReservation ilustra un diseño de mensajes verdaderamente asíncrono en el que la entrega está asegurada. Aunque hay nodos MQOutput en el flujo de mensajes, sólo son para realizar pruebas y no tienen ningún significado dentro de la aplicación de ejemplo. El flujo de mensajes XML_CancelReservation coloca una copia del mensaje de entrada en la cola XML_CANCELRESERVATION_OUT cuando ha finalizado el proceso del mensaje. Por lo tanto, no es necesario que el flujo de mensajes confirme que el mensaje ha llegado a su destino porque, si el mensaje es permanente, éste se ha anotado de forma segura.

Volver a Acerca del Ejemplo Reserva de vuelos