102 Using IBM WebSphere Message Broker as an ESB with WebSphere Process Server
5.5.3 Message flow nodes
In this section, we describe each node in the message flow (see Figure 5-17 on
page 97).
JMSInput node
The JMSInput node begins the processing of the message by getting the
message from the input queue, parsing the message, and propagating the
message to the JMSMQTransform node.
The Basic properties (Figure 5-20) define the source input queue for this
message flow. The MQ queue name must be exactly the same as the JNDI name
defined in the JNDI bindings file.
Figure 5-20 JMSInput Node - Basic
Chapter 5. Scenario: Message splitting and routing 103
The JMS Connection properties (Figure 5-21) include the initial context factory,
the location of the JNDI bindings file, the name of the connection factory, and the
backout queue for this JMS connection. The JNDI definitions must match those
created in 5.3.2, “JMS entries” on page 82.
Figure 5-21 JMSInput Node - JMS Connection
The Input Message Parsing properties define how the message is modeled. The
properties shown in Figure 5-22 indicate that the message type used is
ProcessOrdersRequest of the Scenario1MsgSet(O1FD9CO002001) message
set. Messages are expected to be in an XML wire format that conforms to the list
of properties that are contained in the XML1 wire format label in the message
set.
Figure 5-22 JMSInput Node - Input Message Parsing
104 Using IBM WebSphere Message Broker as an ESB with WebSphere Process Server
The Input Message Parsing properties consist of the following fields:
?
Message domain specifies the parser being used.
?
Message set is a unique ID that is generated for each message set created
(Figure 5-18 on page 100).
?
Message type can be a list of messages that are defined in the message set.
Because only one message was defined in our message set, we have just
one message type that we can select from the drop-down list.
?
Message format is the name of the container for the physical representation of
a message. The default name for this container is XML1. We have accepted
the default name and default values for the physical properties of the
message.
The Parser Options properties (Figure 5-23) specify that the entire message is
parsed upon entry to the JMSInput node. Should parsing fail, the message is
backed out to the backout queue.
Figure 5-23 JMSInput Node - Parser Options
Tip: For a production message flow, we recommend that you configure a
series of nodes that are attached to the catch and failure terminals, so that
parsing or message validation failures are handled more comprehensively.
You can find further information about error handling routines in WebSphere
Message Broker V6, Best Practices Guide: Bullet Proofing Message Flows,
REDP-4043.
Chapter 5. Scenario: Message splitting and routing 105
JMSMQTransform node
The JMSMQTransform node converts messages from the JMS format to the MQ
format. The node is not configurable.
RouteMsgToDestinationQ Compute node
The RouteMsgToDestinationQ Compute node parses the incoming message and
creates new messages for each order that is found. The node sets the
destination queue for the new message based on a database lookup.
The Basic properties (Figure 5-24) define the location of the extended SQL
(ESQL) module that is used to implement the logic of this node and the data
source name of the database that is used to host the routing table that is
accessed by this node.
Figure 5-24 RouteMsgToDestinationQ - Basic properties
Tip: The elements selected in the Compute mode field (LocalEnvironment and
Message) are the parts of the message that will be altered in the Compute
node. All other elements are copied unaltered to the Output terminal.
Select only those parts of the message tree that you need to alter in the
Compute node. By selecting on those parts, you can improve performance
since only those elements that are selected will be held in memory during that
portion of processing.
106 Using IBM WebSphere Message Broker as an ESB with WebSphere Process Server
Example 5-5 shows the ESQL code that implements the node. It performs the
following actions:
1. The message is split into individual orders.
2. Each order is parsed to determine the supplier ID that is associated with the
order. The destination queue to which this order is delivered must match the
supplier’s queue.
3. To determine the destination queue for the order, a database table is
searched for the destination queue that is associated with the supplier ID.
4. If the destination queue is returned from the database successfully, the
destination queue of the message is set to that queue.
5. If database errors are reported by the select statement, the message is
routed to a holding queue for messages for which no destination queue could
be determined due to issues in communicating with the database.
6. If no database error occurred, but no destination queue is returned, the
message is routed to a different holding queue.
7. For each message contained in the multipart message, a single message is
sent to the out terminal of the compute node. Each of these single messages
will have a destination queue set in LocalEnvironment.
Example 5-5 ESQL code for RouteMsgToDestinationQ
CREATE COMPUTE MODULE RouteMsgToDestinationQ
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
/* In this module, we loop through all the instances in the incoming message.
We query the database for an onward routing queue for each supplier id.
If we have a match, we route that instance of the message to the relevant
queue. If we do not have a match or if we encounter problems, we craft an
appropriate message and write that message to a queue.
*/
DECLARE forRef REFERENCE TO InputRoot.MRM;--used to loop through input msg
DECLARE ileRef REFERENCE TO InputLocalEnvironment;
DECLARE oleRef REFERENCE TO OutputLocalEnvironment;
DECLARE suppID CHAR; -- used to store the supplier id
MOVE forRef FIRSTCHILD NAME 'Orders'; -- Move our loop reference to the start
-- of the folder holding all instances
-- of Order elements.
-- Perform the following actions for each instance of
-- 'Order' within the incoming message
FOR forRef AS forRef.Order[] DO
(1)
CALL CopyMessageHeaders();
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.