Request flow for the Message Splitter for WebSphere MQ: one-way (for XML) pattern

This pattern uses a single message flow.

  1. 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.
  2. 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.
  3. The message flow runs as a transaction and is not committed unless all required elements are successfully extracted and written to a queue.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
Back to the Message Splitter for WebSphere MQ: one-way (for XML) pattern specification