About the XML_Reservation message flow
The XML_Reservation message flow reserves seats on the flight listed in the input message, and generates reply messages for the passengers to confirm their reservations. The reply messages are put on the XML_RESERVATION_OUT queue.
The following figure shows the XML_Reservation message flow.

The following table lists the types of nodes that are used in the XML_Reservation message flow.
Node type |
Node name |
MQInput |
XML_RESERVATION_IN |
Database |
UpdateFlightTable |
Compute |
UpdatePassengerTable; BuildSingleMessage; PropagateMultipleMessages |
Filter |
MultipleOrSingleMessage
|
Throw |
InvalidRequest |
MQOutput |
XML_RESERVATION_FAIL; XML_RESERVATION_OUT |
Trace |
LogException |
For more information, read about the nodes in the XML_Reservation message flow in the WebSphere Message Broker documentation. To see the ESQL that is used in this message flow, see Creating the XML_Reservation message flow.
The XML_Reservation message flow performs the following actions:
- The XML_RESERVATION_IN node gets the input message from the XML_RESERVATION_IN queue, and identifies the message as being a self-defining XML message.
- The XML_RESERVATION_IN node fully parses the message using the XML parser, then passes the input message, through the Out terminal, to the UpdateFlightTable node. Alternatively, if there is an exception thrown downstream and the message is rolled back, the node passes the input message, through the Catch terminal, to the XML_RESERVATION_FAIL node, which passes the message to the LogException node. The LogException node then writes the error to the local error log, which is the Event Viewer on Windows, and the syslog on Linux.
- The UpdateFlightTable node checks the XMLFLIGHTTB table to see whether the requested seats are available, then updates the XMLFLIGHTTB table to show that the seats are being allocated and fewer seats are now available.
- The UpdateFlightTable node inserts the value of the RESERVATIONSEQNO from the XMLFLIGHTTB table into an Environment variable, which is passed to the UpdatePassengerTable node. The UpdateFlightTable node also puts into an Environment variable the number of seats remaining in each class.
- The UpdateFlightTable node passes the input message, through the Out terminal, to the UpdatePassengerTable node.
- The UpdatePassengerTable node gets the passenger list from the input message and the flight data from the Environment tree, and adds the names and reservation information of the new passengers to the XMLPASSENGERTB table in the RESERVDB database.
- The UpdatePassengerTable node creates and assigns a unique reservation number to each passenger. The reservation number is made up from:
FlightNumber + FlightDate + RESERVATIONSEQNO
The value in RESERVATIONSEQNO is taken from the Environment variable received from the UpdateFlightTable node. For example Mary Smith's Reservation Number is CA937200305251. The UpdatePassengerTable node updates the XMLPASSENGERTB table with these reservation numbers.
- The UpdatePassengerTable node passes the input message, through the Out terminal, to the MultipleOrSingleMessage node.
- The MultipleOrSingleMessage node checks the input message field called Request and determines where to pass the message next:
- The Request field in the first XML_Reservation input message (reservation1.mbtest) contains the value 'M', so the node passes the message, through the True terminal, to the PropagateMultipleMessages node.
- The Request field in the second XML_Reservation input message (reservation2.mbtest) contains the value 'S', so the node passes the message, through the False terminal, to the BuildSingleMessage node.
- If the node cannot determine the value in the Request field, it passes the message, through the Unknown terminal, to the Invalid Request node. The InvalidRequest node generates an error message that includes the Message Catalog, Message Number, and Message Text, which
are all taken from the ExceptionList tree.
- If the message goes to the PropagateMultipleMessages node, the PropagateMultipleMessages node creates a reply message for one of the passengers listed in the input message, then passes the reply, through the Out terminal, to the XML_RESERVATION_OUT node. The PropagateMultipleMessages node creates a reply message like this for each passenger listed in the input message.
- If the message goes to the BuildSingleMessage node, the BuildSingleMessage node creates a single reply message containing a list of the passengers and their reservation numbers, then passes the reply, through the Out terminal, to the XML_RESERVATION_OUT node.
- The XML_RESERVATION_OUT node puts the reply messages on the XML_RESERVATION_OUT queue.
The input messages for the XML_Reservation message flow manipulate the data in the RESERVDB database. These manipulations include adding data to the XMLPASSENGERTB table. The other message flows retrieve some of the data that is stored in the RESERVDB database by the XML_Reservation message flow. So that there is enough data stored in the database for the other message flows to query, two input messages are supplied to run the XML_Reservation message flow. You must run XML_Reservation with both messages before you run any of the other message flows.
Design suggestion: Using a single Compute node
The XML_Reservation message flow has two separate nodes to update the XMLFLIGHTTB and XMLPASSENGERTB tables in the RESERVDB database:
- UpdateFlightTable (a Database node)
- UpdatePassengerTable (a Compute node)
UpdateFlightTable updates XMLFLIGHTTB with the number of reservations requested for a particular flight. It puts the flight details into the Environment tree to pass to the UpdatePassengerTable node. The UpdatePassengerTable node updates XMLPASSENGERTB with the details of the passengers who have made the reservations, and adds their unique reservation numbers. The node then adds the passengers' unique reservation numbers to the message.
It would be possible to combine the two nodes into a single Compute node to improve the performance of the message flow. You could not, however, combine them into a single Database node because the Database node cannot make changes to the message. The message flow shown here uses two separate nodes to show what Compute and Database nodes can do.
Back to About the Airline Reservations sample