Table-driven dynamic parallel processing

Fork

Work queue

The objects to be processed are all of the same type.

The objects to be processed can be of different types.

The objects in the work queue can be of different types.

All objects are processed with the same task, which is determined once for the whole list. This task can be a:

Task with dialog

Task without dialog

Workflow

Each object is processed in "its" fork individually, possibly in several steps.

The objects are each processed with an individually-assigned task. It can also be the same task for all objects. These tasks can be:

Task with dialog

Task without dialog

The object list must be either processed completely or until the specified end condition is met. 

Not all branches have to be processed (n from m logic), depending on the definition of the fork.

The work queue must be processed for all objects before the next step in the workflow can be executed.

The scope of the object list (= the number of objects to be processed) is not yet finalized at definition time.

The number of objects to be processed is final at definition time.

The scope of the work queue (= the number of objects to be processed) is not yet finalized at definition time.

The object list is available in a multiline container element.

The objects are available at runtime in the various container elements of the workflow container.

The work queue is compiled on the application side outside the workflow as a list of object/task pairings, and then processed as a work queue work item.

The work queue as a whole can still be processed at runtime: It is possible to remove objects from the list, add objects, and track statuses regarding the processing of the individual entries.

At runtime, a work item is created for each object in the list and processed in the normal manner.

In the case of a ParForEach activity, this is a dialog, background, or workflow work item. In the case of a block with ParForEach, this is a block work item.

At runtime, a corresponding work item is created for each step of the fork and processed in the normal manner.

At runtime, a dialog work item is created for each work queue entry processed with a dialog task. This work item is then processed in the normal manner.

For each work queue entry processed with a background task, the underlying object methods are executed directly and sequentially. No background work item is created.

Deadline monitoring, rules for agent determination and binding can be defined once and then apply equally to each work item created.

Deadline monitoring, rules for agent determination and binding are defined individually in the normal manner.

Deadline monitoring is defined for the work queue as a whole, and then passed on to the individual dialog work items derived from the work queue.

The recipients can be passed to the work queue as parameters, and then apply to all dialog work items derived from the work queue. If the individual tasks in the work queue are defined with default rules, these are resolved.

A binding between the workflow container and the task containers of the individual tasks in the work queue cannot be defined explicitly, but is instead executed automatically by the system. For this, all elements in all task containers must exist with the same names in the workflow container.