About the XML_CancelReservation message flow

The XML_CancelReservation message flow cancels the reservations listed in the input message, and updates the user database to show that there are fewer reservations made and more seats available. The XML_CancelReservation message flow can process a list of Reservation Numbers, so reservations do not have to be canceled one at a time.

The following figure shows the XML_CancelReservation message flow.

A screen capture of the XML_CancelReservation message flow

The following table lists the types of nodes that are used in the XML_CancelReservation message flow.

Node type Node name
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

For more information, read about the nodes in the XML_CancelReservation message flow in the WebSphere Message Broker documentation. To see the ESQL that is used in this message flow, see Creating the XML_CancelReservation message flow.

The XML_CancelReservation message flow performs the following actions:

  1. The XML_CANCELRESERVATION_IN node gets the input message from the XML_CANCELRESERVATION_IN queue and identifies the input message as being in the XML domain. The message flow must, therefore, parse the message using the XML parser.
  2. The XML_CANCELRESERVATION_IN node passes the message, through the Out terminal, to the DeleteReservation node. Alternatively, if an exception has been thrown downstream and the message has been rolled back to here, the XML_CANCELRESERVATION_IN node passes the message, through the Catch terminal, to the XML_CANCLERESERVATION_FAIL1_1 node, which puts the message on the XML_CANCELRESERVATION_FAIL1 queue.
  3. The DeleteReservation node checks the XMLPASSENGERTB table in the RESERVDB database to see if the reservations listed in the input message actually exist.
  4. If the reservation exists, the DeleteReservation node removes from the XMLPASSENGERTB table the passengers listed in the input message. The DeleteReservation node passes the message, through the Out terminal, to the Trace1 node. The Trace1 node logs the state of the message after it leaves the DeleteReservation node. The trace is stored in the local error log, which is the Event Viewer on Windows, or the syslog on Linux. The Trace1 node passes the message to the IncrementSeat node.
  5. If the reservations do not exist, the DeleteReservation node passes the message, through the Failure terminal, to Trace. The Trace node traces and logs problems, such as invalid xml, that have caused the message to be passed to the Trace node. The trace is stored in the local error log. The Trace node then passes the message, through the Out terminal, to XML_CANCELRESERVATION_FAIL1_2, which puts the message on the XML_CANCELRESERVATION_FAIL1 queue.
  6. The IncrementSeat node updates the XMLFLIGHTTB table in the RESERVDB database to show that four seats (two in each class) have become available. The IncrementSeat node then passes the message, through the Out terminal, to the XML_CANCELRESERVATION_OUT node, which puts the message on the XML_CANCELRESERVATION_OUT queue. Alternatively, if there is a problem when updating the XMLFLIGHTTB table, the IncrementSeat node passes the message to the Trace2 node. The Trace2 node traces the message as it flows between the IncrementSeat node and the XML_CANCELRESERVATION_FAIL2 node. The trace is stored in the local error log. The XML_CANCELRESERVATION_FAIL2 node puts the message on the XML_CANCELRESERVATION_FAIL2 queue.

The XML_CancelReservation message flow illustrates a true asynchronous messaging design, in which delivery is assured. Although there are MQOutput nodes in the message flow, they are only for testing purposes and have no meaning within the sample application. The XML_CancelReservation message flow just puts a copy of the input message on the XML_CANCELRESERVATION_OUT queue when it has finished processing the message. It is not necessary for the message flow to confirm that the message has arrived at its destination because if the message is persistent, it has been securely logged.

Main Page icon   Back to About the Airline Reservations sample