Introducing Variable Scoping

Before v22.2, a process instance was executed from a single process diagram, and the developer was responsible for managing the process variables on the diagram. All process variables were accessible by the instance.

Flows for APEX v22.2 introduced Call Activities – where a single process instance can start a process using one process diagram (model) and then can call other diagrams. A process instance could be configured to call the same diagram multiple times – which would result in multiple process variables having the same name present in a single process instance. To keep process variable separate in each invocation of a diagram (within the same process instance), v22.2 introduced variable scoping.

Flows for APEX v24.1 Enterprise Edition introduced task and sub-process iteration, where a task or sub-process is executed many times. Where this is is parallel, we can simiarly have multiple copies of the same process variable – and so we use variable scoping to keep these different copies of the same variable apart.

Scoping in Call Activities

Process variables are now scoped at diagram invocation level. Each separate Call Activity creates a new scope for the called diagram to operate in.

Variable Scoping in Call activity

In the example above, the top level process diagram, diagram A, calls diagram B and diagram C. The initial diagram operates with its scope, scope 0. When Diagram B is called, a new scope is dynamically created at runtime for variables in this diagram – in this case, scope 2. Then control passes back to diagram A, operating at scope 0, before it calls diagram C. when C is called, a new scope is created for variables inside this diagram – in our example, scope 3.

All three diagrams in the example have a process variable myVar. As these are on three different diagram calls, scoping results in MyVar in Diagram A being a different variable to MyVar in Diagram B (scope 2), and different again from MyVar in Diagram C (scope 3).

Variable Scoping in Call activity 2

To further develop the example, the second diagram shows a top level diagram D which calls Diagram E twice, in parallel.

The process instance starting diagram operates with scope 0; in fact, the top level scope in any process instance is always at scope 0. The instance calls Diagram E twice. One copy of Diagram E operates with scope 4, and the second operates with scope 5. Again, the variable MyVar in each diagram is a different variable.

Scoping and Single Model Instances.

If your process is defined in a single diagram (model), and does not call another diagram, everything operates at scope 0. The system will operate as it did with previous versions of Flows for APEX, and you don’t need to worry about scoping.

All process variable API calls have scoping as an optional parameter, and if no scope is provided, they default to scope 0.

Using Scope in a Multi-Model Application

All of the API calls to the process variable system have a signature that allows you to identify the scope of a variable. But how do you keep track of scope? Typically an application will not need to explicitly keep track of the scope that it is operating at. Instead, the application can supply the Subflow ID of the subflow it is currently operating on – and the Flows for APEX engine will use the appropriate scope for that subflow. The engine knows which diagram (or which call of a diagram) every subflow is processing, and can get the appropriate scope information.

If no scope or sublow information information is provided, the scope defaults to scope 0.

Scoping in Iterations and Loops (Enterprise Edition)🆕

Sequential Iterations and Loops execute the same task or sub-process multiple times, sequentially – and there is no problem with multiple copies of the same variable being updated simultaneously. For Parallel Iterations, we start multiple copies of the same. task or sub-process, simultaneously, in paralllel. Any variables that are used in the parallel iterated section need to be separated in a different scope from other variables with the same name. We use scoping to do this. Each parallel iteration path operates with its own scope. The scope_id is the subflow_id of the initial subflow in the iteration path.

The Iteration Array, which contains any iteration output variables, is always created on the subflow of the object which is iterated, not of any of the iterations.