Workflow XML file

The workflow XML file declares the nodes to be used in a workflow and the connections between them.

The <nodes> section must include every node that can be called. The <connections> section directs the flow from one node to the next. When the Business Rules Server processes a client application message, it calls the first node in the <nodes> list and then follows the flow as defined in the <connections> section.

This example uses a PVR transaction workflow, but the concepts apply to all workflows. After the PvrRoutingTransitNode runs, control is passed to the PvrAccountNode. After the PvrAccountNode, control goes to the PvrProcessControlNode, and on down the list. This example shows all of the available PVR nodes.

<?xml version="1.0" ?>
<workflowDescriptor name="ipdPvrItemWorkflow">
  <nodes>
    <node name="PvrRoutingTransitNode"/>
    <node name="PvrAccountNode"/>
    <node name="PvrProcessControlNode"/>
    <node name="PvrAuxOnUsNode"/>
    <node name="PvrAmountNode"/>
    <node name="PvrField4Node"/>
    <node name="PvrExtProcCodeNode"/>
    <node name="AutoCorrectNode"/>
    <node name="PvrEndorseNode"/>
    <node name="PvrPocketMapNode"/>
  </nodes>
  <connections>
    <connection srcName="PvrRoutingTransitNode" dstName="AutoCorrectNode" 
                results="FAILURE" recordId="61"/>
    <connection srcName="PvrRoutingTransitNode" dstName="AutoCorrectNode" 
                results="SUCCESS">
      <paymentCheck field="ibmNprValidationError" operator="EQ" value="true"/>
    </connection>
    <connection srcName="PvrRoutingTransitNode" dstName="PvrEndorseNode" 
                results="SUCCESS">
      <paymentCheck field="ibmNprControlDoc" operator="EQ" value="true"/>
    </connection>
    <connection srcName="PvrRoutingTransitNode" dstName="PvrAccountNode" 
                results="SUCCESS"/>
    <connection srcName="PvrAccountNode"        dstName="AutoCorrectNode" 
                results="FAILURE" recordId="83"/>
    <connection srcName="PvrAccountNode"        dstName="PvrProcessControlNode"/>
    <connection srcName="PvrProcessControlNode" dstName="PvrField4Node"/>
    <connection srcName="PvrField4Node"         dstName="PvrAuxOnUsNode"/>
    <connection srcName="PvrAuxOnUsNode"        dstName="PvrExtProcCodeNode"/>
    <connection srcName="PvrExtProcCodeNode"    dstName="PvrAmountNode"/>
    <connection srcName="PvrAmountNode"         dstName="AutoCorrectNode">
      <paymentCheck field="ibmNprValidationError" operator="EQ" value="true"/>
    </connection>
    <connection srcName="PvrAmountNode"         dstName="PvrEndorseNode"/>
    <connection srcName="AutoCorrectNode"       dstName="PvrRoutingTransitNode" 
                results="SUCCESS"/>
    <connection srcName="AutoCorrectNode"       dstName="PvrEndorseNode"/>
    <connection srcName="PvrEndorseNode"        dstName="PvrPocketMapNode"/>
  </connections>
</workflowDescriptor>

In a PVR transaction workflow, the PvrRoutingTransitNode must be the first of the PVR nodes set. All PocketMapNode nodes must be the last ones set. The remaining PVR nodes can be configured in any order.

Other node types, for example ESortNode and UserNode, can also be used in setting up the workflow. No restrictions exist for the number of or the location of these nodes in the connections list.

The next example shows how to control the downstream flow based on the execution results of a node. The first line in the connections list was added with the results=FAILURE qualifier. It can be interpreted as "if the RTNode returns with a failure, run the PocketMapNode next; otherwise, check the next connection in the list".

Following the example, if the RTNode returns successfully, the second line runs.

<?xml version="1.0" ?>
<workflowDescriptor name="PvrWorkflow">
  <nodes>
    <node name="RTNode"/>
    <node name="AccountNode"/>
    <node name="ProcessControlNode"/>
    <node name="AuxOnUsNode"/>
    <node name="AmountNode"/>
    <node name="EndorseNode"/>
    <node name="PocketMapNode"/>
  </nodes>
  <connections>
    <connection srcName="RTNode"             dstName="PocketMapNode"
                results="FAILURE"/>
    <connection srcName="RTNode"             dstName="AccountNode"/>
    <connection srcName="AccountNode"        dstName="ProcessControlNode"/>
    <connection srcName="ProcessControlNode" dstName="AuxOnUsNode"/>
    <connection srcName="AuxOnUsNode"        dstName="AmountNode"/>
    <connection srcName="AmountNode"         dstName="EndorseNode"/>
    <connection srcName="EndorseNode"        dstName="PocketMapNode"/>
  </connections>
</workflowDescriptor>

The following rearrangement of the first two lines results in the same outcome.

    <connection srcName="RTNode"             dstName="AccountNode"
                results="SUCCESS"/>
    <connection srcName="RTNode"             dstName="PocketMapNode"/>
    <connection srcName="AccountNode"        dstName="ProcessControlNode"/>
    <connection srcName="ProcessControlNode" dstName="AuxOnUsNode"/>
    <connection srcName="AuxOnUsNode"        dstName="AmountNode"/>
    <connection srcName="AmountNode"         dstName="EndorseNode"/>
    <connection srcName="EndorseNode"        dstName="PocketMapNode"/>

The timing of when a node returns to the workflow control program and the way it processes the connections list are described in the following list.

The omission of the results qualifier means to always go to the destination node.
The connections list is scanned from beginning to end. Processing starts when the node name is located.
The workflow control program returns to the client when it makes it all the way through the list without finding a destination node.

The results qualifier acts as a filter that controls whether to go to the destination node. A data field can be used as an extra filter. The following example shows how to set this up.

  <connections>
    <connection srcName="RTNode"  dstName="PocketMapNode"  results="FAILURE"/>
    <connection srcName="RTNode"  dstName="PocketMapNode"  results="SUCCESS">
      <paymentCheck field="ibmNprValidationError" operator="EQ" value="true"/>
    </connection>
    <connection srcName="RTNode"             dstName="AccountNode"/>
    <connection srcName="AccountNode"        dstName="ProcessControlNode"/>
    <connection srcName="ProcessControlNode" dstName="AuxOnUsNode"/>
    <connection srcName="AuxOnUsNode"        dstName="AmountNode"/>
    <connection srcName="AmountNode"         dstName="EndorseNode"/>
    <connection srcName="EndorseNode"        dstName="PocketMapNode"/>
  </connections>

The <paymentCheck> element identifies the field name, the operator, and the value that is used to run the compare. In the previous example, if the result is successful and the value of the ibmNprValidationError data field at the time the RTNode returns is equal to true, control passes to the PocketMapNode.

The operators in the following list can be used.

EQ - equal
NE - not equal
LT - less than
GT - greater than
LE - less than or equal
GE - greater than or equal
Null - value is null
NotNull - value is not null
Current - value is current
NotCurrent - value is not current
CurrentNotNull - value is current and not null

Multiple payment check filters can be used. For example, when defined in the following way, the data field comparisons act as an OR condition. If the first comparison fails, the second one might satisfy the condition.

  <connections>
    <connection srcName="RTNode"  dstName="PocketMapNode"  results="FAILURE"/>
    <connection srcName="RTNode"  dstName="PocketMapNode"  results="SUCCESS">
      <paymentCheck field="ibmNprValidationError" operator="EQ" value="true"/>
      <paymentCheck field="ibmNprCredit"          operator="EQ" value="true"/>
    </connection>
    <connection srcName="RTNode"             dstName="AccountNode"/>
    <connection srcName="AccountNode"        dstName="ProcessControlNode"/>
    <connection srcName="ProcessControlNode" dstName="AuxOnUsNode"/>
    <connection srcName="AuxOnUsNode"        dstName="AmountNode"/>
    <connection srcName="AmountNode"         dstName="EndorseNode"/>
    <connection srcName="EndorseNode"        dstName="PocketMapNode"/>
  </connections>

Multiple payment checks that all must succeed before a connection is made can be specified. These payment checks are specified by setting the and attribute on the <paymentCheck> element to true. In the following example, all three of the conditions must be met to continue to the next connection.

    <connection srcName="ValMICRValNode" dstName="ItemReviewsRequiredNode">
      <paymentCheck field="ibmNprValidationError" operator="EQ" value="0"   and="true"/>
      <paymentCheck field="ibmAmountDelta"        operator="NE" value="0000000000" and="true"/>
      <paymentCheck field="ibmClientType"         operator="EQ" value="Repair"/>
    </connection>

More complex conditions can be created as shown in the following example.

    <connection srcName="ValMICRValNode" dstName="ItemReviewsRequiredNode">
      <paymentCheck field="ibmNprValidationError" operator="EQ" value="0" and="true"/>
      <paymentCheck field="ibmClientType"         operator="EQ" value="Payment Repair"/>
      <paymentCheck field="ibmNprValidationError" operator="EQ" value="0" and="true"/>
      <paymentCheck field="ibmClientType"         operator="EQ" value="Auto Adjust"/>
    </connection>

This example implements the following logic.

If ((ibmNprValidationError==0 AND ibmClientType=="Payment Repair") OR 
    (ibmNprValidationError==0 AND ibmClientType=="Auto Adjust")) 
   goto  ItemReviewsRequiredNode

Several restrictions exist regarding the <paymentCheck> element.

If the field name is not known by the workflow (for example, it is not found in the DecisionRequest data field collection), it is ignored. Check the spelling because the field name is case-sensitive.
For all operators except the NotCurrent operator, the conditional doesn't succeed when the condition of the data field is notCurrent.
BYTE data types are treated as Shorts. The number must be between -32768 and 32767. CHAR types are now supported.
It interprets true and false in the value field as Boolean values. Only the EQ and NE operators work with Boolean data fields.

Note: When the <paymentCheck> element is added to an existing <connection>, the implicit forward slash terminator at the end of the element must be removed and the explicit </connection> terminator must be added.

After the destination node is determined, the value of ibmNprRecordId can be changed before the destination node is run. The value, recordId="61", sets the ibmNprRecordId field to 61 and the ibmNprValidationError field to true. These fields are located in the DecisionRequest object. Only invalid record IDs can be set this way. No range checking is done on the record ID value.

  <connections>
    <connection srcName="RTNode"             dstName="PocketMapNode"
                results="FAILURE" recordId="61"/>
    <connection srcName="RTNode"             dstName="PocketMapNode"
                results="SUCCESS">
      <paymentCheck field="ibmNprValidationError" operator="EQ" value="true"/>
      <paymentCheck field="ibmNprCredit" operator="EQ" value="true" recordId="62"/>
    </connection>
    <connection srcName="RTNode"             dstName="AccountNode"/>
    <connection srcName="AccountNode"        dstName="ProcessControlNode"/>
    <connection srcName="ProcessControlNode" dstName="AuxOnUsNode"/>
    <connection srcName="AuxOnUsNode"        dstName="AmountNode"/>
    <connection srcName="AmountNode"         dstName="EndorseNode"/>
    <connection srcName="EndorseNode"        dstName="PocketMapNode"/>
  </connections>