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 that reservations
do not have to be canceled one at a time.
The following diagram shows 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 about the nodes that are used in this sample, see
Built-in nodes 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:
- The XML_CANCELRESERVATION_IN node gets the input message from the XML_CANCELRESERVATION_IN queue and
identifies the input message as being in the XMLNSC domain. The message flow must, therefore, parse the
message by using the XMLNSC parser.
- The XML_CANCELRESERVATION_IN node passes the message through the Out terminal
to the DeleteReservation node. Alternatively, if an exception has been produced 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.
- The DeleteReservation node checks the XMLPASSENGERTB table in the RESERVDB database to see if the reservations
listed in the input message exist.
- If the reservation exists, the DeleteReservation node removes the passengers listed in the input message
from the XMLPASSENGERTB table. 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.
- If the reservations do not exist, the DeleteReservation node passes the message through the Failure
terminal to the Trace node. The Trace node traces and logs any 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.
- 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 for testing purposes only and have no meaning within the sample application.
The XML_CancelReservation message flow 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.
Back to About the Airline Reservations sample