You have the option of choosing a dynamic processing mode for a block. The following considerations will help you to decide which mode is appropriate for your particular use case.
A ParForEach is not a means of improving performance. A ParForEach will not result in a split into threads.
A ParForEach is resource-intensive because a work item is created each time a loop is executed.
A ParForEach is recommended if:
● The messages are processed further in the parallel processing branches.
● The individual processing branches are not dependent on each other on a business level.
● There are less than 999 parallel processing branches (the multiline table element that is processed in the ParForEach contains less than 999 lines).
A ParForEach would be beneficial in the following example:
You want to send a message to multiple receivers, wait for the respective answers, and then edit each one independently of the others in a separate context. Once the messages have been sent asynchronously in the ParForEach, the step can wait for an acknowledgment or some kind of business confirmation, for example.
A ParForEach is not recommended if:
● The messages are not processed further in the processing branches.
If, for example, you want to send a message to multiple receivers, but do not want the step to wait for a response or acknowledgment, use a ForEach instead of a ParForEach.
● There are more than 999 processing branches.
Check whether you can use a ForEach instead of a ParForEach. In the case of a ForEach you can set the maximum number of processing branches as part of the absolute upper limit (transaction SWPA). The absolute upper limit is set to 999999.