The following outlines the solution workflow as an item is accepted
and processed by an ItemDispatcher collaboration object. Based on whether
the item has any cascaded GLNs within it, one or more items are then sent
to a WebSphere® MQ
Workflow process for review/approval.
Related information
For more detailed process logic
behind the steps in this high-level flow, see the following collaboration
templates:
Also, refer to the Installation guide for detailed information on creating
port connections between collaboration objects and between collaboration objects
and connectors.
Workflow
- An ItemDispatcher collaboration object is triggered by the receipt of
a Retail_Item business object on its From port.
- The ItemDispatcher collaboration object examines the item to see if it
contains cascaded GLNs and then directs processing, as follows:
- If no cascaded GLNs exist, the collaboration object sends the item through
its To port to the WebSphere MQ Workflow process, and processing
by the ItemDispatcher collaboration object ends.
- If cascaded GLNs do exist, the collaboration object continues processing
the item.
For the purposes of this example, assume that cascaded GLNs do exist.
- The ItemDispatcher collaboration object checks if a filename exists in
its GLN_CASCADE_GROUPING_FILE property and directs processing, as follows:
- If this property is empty, the collaboration object uses the value of
the GLN_CASCADE_GROUPING_DEFAULT configuration property to guide on-going
processing.
- If a filename exists in this property, the collaboration object verifies
that the file exists and parses correctly. Based on the results of this check,
it guides processing, as follows:
- If the file exists and parses correctly, the collaboration object continues
processing the item.
- If the file does not exist or does not parse correctly, the collaboration
object raises an exception, sends the item to its Notify port with
appropriate error attributes filled in, and processing ends.
For the purposes of this example, assume that a filename and file exist
and that the file parses correctly.
- The ItemDispatcher collaboration object checks if the RetailUtility class
file specified in its UTILITY_CLASS property exists. It then directs processing,
as follows:
- If a file exists, the collaboration object continues processing the item.
- If a file does not exist, the collaboration object raises an exception,
sends the item to its Notify port with appropriate error attributes
filled in, and processing ends.
For the purposes of this example, assume that a RetailUtility class file
exists.
- The ItemDispatcher collaboration object uses the information in the file
specified in its GLN_CASCADE_GROUPING_FILE property to determine how to group
the cascaded GLNs. See Using the GLN Cascade Grouping File.
- For each cascaded GLN identified in Step 5, which will be sent to the WebSphere MQ
Workflow process, the ItemDispatcher collaboration object creates one copy
of the Retail_Item business object. It removes the extra cascaded GLNs from
each copy and sends each to its LocalItemStore port with a Create
verb to an ItemStore collaboration object. The key used for each new item
is the concatenation of the internals.correlationID attribute value of the
original triggering business object and the internals.cascadedGlns.gln attribute
value of the newly created business object.
- The ItemStore collaboration object receives each new business object on
its From port and, through a series of interactions with the IBM® WebSphere Business
Integration Data Handler for XML, stores each in the item store database.
The section describes in detail how a business object is persisted to the
item store.
- The collaboration object creates a new copy of the triggering Retail_Item
business object for each group, removing extra cascaded GLNs that do not belong
in the group from each Retail_Item.
- The new Retail_Item business objects are sent through the To port
to the WebSphere MQ
Workflow process for approval.
- The original Retail_Item business object is updated with the number of
cascaded items sent to the WebSphere MQ Workflow process and is then
sent to the LocalItemStore port with an Update verb to an ItemStore
collaboration object.
- The ItemStore collaboration object receives the business object on its From port and, through a series of interactions with the IBM WebSphere Business
Integration Data Handler for XML, updates the item store database. See Persisting, retrieving, updating, or deleting an item to or from a local item store.
This workflow is continued in Detailed workflow: completing the WebSphere MQ Workflow process and merging updated information into a complete business object.
An ItemDispatcher collaboration object can
be configured to initiate notification if errors are detected during processing.
It connects through its Notify port to a Role_Email collaboration
object, which actually controls the e-mail. See Controlling e-mail.
An ItemDispatcher collaboration object can
also log when errors occur. See Logging.