Request flow for the Message Splitter for WebSphere MQ: one-way (for XML) pattern
This pattern uses a single message flow.
- The Input node expects a well formed XML message and is
configured to use the XMLNSC parser. If any incoming message contains an MQRFH2 header that
changes the domain, it causes an error and the message is backed out.
- Validation of the message is optional and is specified in the
Validation required
pattern parameter.
Validation is not immediate and is carried out as each element is extracted.
- The message flow runs as a transaction and is not committed
unless all required elements are successfully extracted and written to a queue.
- The main control in this flow is the Propagate Element Compute node.
This node creates a local variable to
hold a mutable tree that is a copy of the input.
This flow loops through the message tree, moving to a child
element within a container tag and propagating it onwards.
As each element is selected the previous element is deleted to reduce memory usage.
- The structure of the message is determined by the pattern parameters,
and if a message does not conform to this structure an error is produced.
- A check is made that the message includes the container path, that is, the container for all of the
elements to be processed. If this container path is specified as *:*,
the container is considered to be the root tag, whatever its name, and
message elements that are children of the root are extracted.
- If the Message element name pattern parameter is
*:*, all elements
that are children of the container are processed.
If any other value is specified, only message elements that have tags that match the
Message element name are extracted.
The extracted message element is passed on for further processing.
- The message flow includes the MessageProcessor subflow, which by default has no impact
because it contains only a Passthrough node. The subflow is included to provide a place where a
pattern instance can be customized by using standard tooling, without any changes to the structure of
the pattern.
- The message is passed to the Route subflow, which directs it to the correct WebSphere MQ queue.
Failure to find a route, or any exception, sets the failure status and
directs control to the Failure node.
- If the Bad message action is Save,
the Failure node is connected to an MQOutput node to save
the message. Control returns to the Compute node to extract the next element.
- If the Bad message action is Cancel, the
Failure node is not connected and the Compute node produces a user error
causing the flow to back out.
- When a move to next element fails, because all of the elements have been processed,
the Log subflow is called, if logging is required by the pattern parameters.
At this point the message flow always stops successfully
and the transaction is committed. Any errors that occur in logging are caught and processed
by writing to a Trace node.
- If the Routing parameter is
set to Lookup Routes and the
Cache refresh
pattern parameter specifies that a cache refresh is required, the main flow contains a second Input
node that reads from the queue that is defined by the Refresh queue
pattern parameter. Any message that is sent to this queue
clears the shared variable CacheQueueTable.valid, so that the cache is
refreshed before the next look up.