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 diagram 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 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_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 by using the XMLNSC parser, then passes the input
message through the Out terminal to the UpdateFlightTable node. Alternatively, if an exception is
produced 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 if the requested seats are available,
then updates the XMLFLIGHTTB table to show that the seats are 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, therefore 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, therefore 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 similar reply message
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. Two input messages are supplied to run the XML_Reservation message flow
so that there is enough data stored in the database for the other message
flows to query.
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)
The UpdateFlightTable node 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.
You can combine the two nodes into a single Compute node to improve the performance of the
message flow. You cannot, 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