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.

La siguiente figura 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

Si desea ver más información, lea lo referente a los nodos en el flujo de mensajes XML_CancelReservation 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 XML. Por tanto, el flujo de mensajes debe analizar el mensaje utilizando el analizador XML.
  2. El nodo XML_CANCELRESERVATION_IN pasa el mensaje, a través del terminal de salida (Out), al nodo DeleteReservation. De forma alternativa, si ha generado una excepción en sentido descendente y se ha restituido el mensaje, el nodo XML_CANCELRESERVATION_IN pasa el mensaje, a través del terminal de captación, al nodo XML_CANCLERESERVATION_FAIL1, que transfiere el mensaje a 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 realmente.
  4. Si la reserva existe, el nodo DeleteReservation elimina de la tabla de pasajeros XMLPASSENGERTB listada en el mensaje de entrada. El nodo DeleteReservation pasa el mensaje, a través del terminal Out, 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 las reservas no existen, el nodo DeleteReservation pasa el mensaje, a través del terminal Failure, a Trace. El nodo Trace rastrea y anota los problemas, como, por ejemplo, un xml no válido, que han hecho que el mensaje se pase 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 solamente pone 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.

Icono de la página principal   Volver al ejemplo Acerca de la Reserva de vuelos