Using the GLN Cascade Grouping File

A file of information the ItemDispatcher collaboration object needs to determine how to group the GLNs for a given item in messages sent to WebSphere® MQ Workflow for approval.

Purpose

The GLN Cascade Grouping File is a user-created text file, which provides information the ItemDispatcher collaboration object needs to determine how to group the GLNs for a given item in messages sent to WebSphere MQ Workflow for approval. It can contain any number of sections, each section containing FILTER and GLN_GROUPS subsections. A final optional "filterless" subsection, containing only a GLN_GROUPS subsection, can also be included.

Each FILTER subsection filters on one or more Retail_Item business object attributes. A FILTER subsection contains the following:
  • A fully qualified Retail_Item attribute on a single line.
  • On the next single line, a comma-delimited list of valid values for the attribute.
  • If filtering on multiple attributes, on the next single line, a value of AND.
  • On the next single line, another fully qualified Retail_Item attribute.
  • On the next single line, a comma-delimited list of valid values for that attribute.
Any number of attributes can be filtered in this way.

Each FILTER subsection must be followed by a GLN_GROUPS subsection. A GLN_GROUPS subsection must contain at least one comma-delimited list of cascaded GLN values grouped together on a single line. Additional groups of cascaded GLNs can be defined simply by adding more lines of comma-delimited GLN lists to this subsection. A GLN_GROUPS subsection can be followed by a FILTER subsection, another GLN_GROUPS subsection without a filter, or an optional END separator at the end of the file.

The ItemDispatcher collaboration object reads through the GLN Cascade Grouping File specified in the GLN_CASCADE_GROUPING_FILE configuration property until it finds a FILTER subsection that is satisfied by the attribute values contained in the Retail_Item being processed. The collaboration object then groups the GLNs according to the GLN_GROUPS subsection associated with the satisfied FILTER subsection. If an item satisfies the conditions of multiple filters, only the first filter in the file is ever considered.

The following is an example and an explanation of a filtering file.

FILTER
internals.fromGln
0001000000001,0001000000002
AND
item.catalogueItem.tradeItem.tradeItemInformation.classificationCategoryCode.   \
additionalClassification[].additionalClassificationCategoryCode
0001.001.001,0001.001.002,0001.001.003
GLN_GROUPS
0005000000001,0005000000002,0005000000003
0005000000004,0005000000005,0005000000006
FILTER
internals.fromGln
0001000000005
GLN_GROUPS
0005000000001,0005000000002
0005000000003,0005000000004
0005000000005,0005000000006
GLN_GROUPS
0005000000001
0005000000002
0005000000003
0005000000004
0005000000005
0005000000006

Explaining the example

The first section reads:
FILTER
internals.fromGln
0001000000001,0001000000002
AND
item.catalogueItem.tradeItem.tradeItemInformation.classificationCategoryCode.   \
additionalClassification[].additionalClassificationCategoryCode
0001.001.001,0001.001.002,0001.001.003
GLN_GROUPS
0005000000001,0005000000002,0005000000003
0005000000004,0005000000005,0005000000006
If the Retail_Item business object being processed has a fromGln attribute value of 0001000000001 or 0001000000002 and one of the following additionalClassificationCategoryCode attribute values:
0001.001.001
0001.001.002
0001.001.003
then the GLNs are grouped as follows:
Group 1 Contains GLNs 0005000000001, 0005000000002, and 0005000000003, if they exist.
Group 2 Contains GLNs 0005000000004, 0005000000005, and 0005000000006, if they exist.
The second section contains:
FILTER
internals.fromGln
0001000000005
GLN_GROUPS
0005000000001,0005000000002
0005000000003,0005000000004
0005000000005,0005000000006
If the first filter conditions were not satisfied, the collaboration object now checks to see if the Retail_Item business object has a fromGln value of 0001000000005. If it does, then the GLNs are grouped as follows:
Group 1 Contains GLNs 0005000000001 and 0005000000002, if they exist.
Group 2 Contains GLNs 0005000000003 and 0005000000004, if they exist.
Group 3 Contains GLNs 0005000000005 and 0005000000006, if they exist.
Any GLNs that are not in the GLN_GROUPS subsection are disregarded. Each group of GLNs is sent separately to WebSphere MQ Workflow for approval, so a maximum of three messages are sent.

The next section contains:

GLN_GROUPS
0005000000001
0005000000002
0005000000003
0005000000004
0005000000005
0005000000006
If none of the preceding filters has been satisfied, the filterless GLN_GROUPS subsection is assumed to apply. Each of the six listed GLNs will be sent to WebSphere MQ Workflow in its own message. Unlisted GLNs are disregarded, so a maximum of six messages are sent.

If no FILTER subsection is satisfied and there is no filterless GLN_GROUPS subsection, then the behavior is determined by the value of the GLN_CASCADE_GROUPING_DEFAULT property.

Parent topic: Overall process logic