• For Decision Groups, context defines the target of its ‘action’ (usually create or update).
• For Decisions, context defines the target location of the output of its Formula.
• For Formulas, context is used to determine reachability of nodes that it wants to read.

It is common for a Formula to need to reach into collections. This can normally be accomplished with the range of node operators that are explicitly provided for this purpose, including the important ‘PositionToNode’ operator. These operators are accessed by simply dragging the multi-valued node onto the formula palette from the schema tree. Note that you can directly access multi-valued children of multi-valued nodes – you do not need to ‘walk the tree’ (i.e. go straight to the lowest level collection that is required and ignore the intervening parent collections – these will all be seen as ’single valued’ from the perspective of the lowest level collection).

When using the node operators, the context tree is maintained. To the left of (’above’) the node operator lies the ‘previous context’; to its right (’below’) is the current context. You can directly access the previous context variables using the PreviousContext operator. If you have nested collections, then you can step back by using multiple ‘Previous Context’ operators in succession, each one stepping you up one context. However, when using this approach there is only one context available to the formula – you can think of this as having only one cursor available to record your position within the formula. Tip: as you move around the Formula, operations that are sitting in another context are ‘greyed out’ – crossing a context boundary causes the change in color of the operators.

The following example shows a context shift across the ‘AddNodes’ operator; and then use of the PreviousContext operator to reach back into the parent context.

Sometimes this is not enough. If you want to compare 2 lists, then you need 2 cursors at the same time - one for each list.

Additional cursors can be obtained by using a feature called ‘External Context’. External Context uses the decision model to position on multiple collections in a stack. Each Decision Group ancestor of a Decision represents an available cursor. This cursor is accessed by using the ExternalContext operator. Any child operations of the ExternalContext operator have context on that Decision Group’s cursor. Multiple External Contexts can be nested, although this is rarely required.

Here is an example using external context. The example is building a master lists of Payees that have activity during the month. This list is derived when a member has a transaction for the Payee. Therefore we will cycle through the transactions (the Mbr_Rollover_History file) and for each Payee name in the transaction file, we will cycle through the Payee file and see if it already exists. If it does, we will do nothing (’AbortDecision’) ; if it does not, we return the new Payee name, which creates a new Payee element.

Here is the transactions file (Mbr_Rollover_History):

Here is the Payee file:

The Decision Model shows a Decision Group [Cycle through Rollovers] on the transaction file. The @PayeeName decision is an action that will create the target node and its immediate parents (indicated by the mauve color) - this means that if the decision completes normally, a new node and its parent will be created:

The @PayeeName Formula is constructed as follows. The Formula context is the same as the Decision - on a NEW Payee. If the Formula does not Abort or Exit the Decision, then the Payee will be created. The Formula then steps into a multi-valued context – the list of all Payees, using the ‘AnyNodeTrue’ operator. For each Payee node, it compares the Payee name with the ExternalContext Payee, that being the transaction Payee. If any names match, then the Payee already exists and the Decision can be aborted. Otherwise return the ExternalContext (transaction) Payee and complete the creation of the Payee element.