Implementation Options for Parallel Processing (SAP Library

Implementation Options for Parallel Processing

You have some objects that can and are to be processed in parallel and independently of each other.

This section compares three concepts in order to give you some assistance in making your decision as to how to proceed:

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 processed for all objects before the next step in the workflow can be executed.	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 dialog, background or workflow work item is created for each object in the list. This work item is processed in the normal manner.	At runtime, an appropriate work item is created for each step of the forks. This work item is 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 processed in the normal manner. The underlying objects methods are executed directly and sequentially for each work queue entry processed with a background task. 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 container 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.