Checklist: Making Correct Use of Dynamic Processing 

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.

ParForEach or ForEach?

 

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.

ParForEach Recommended

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.

ParForEach Not Recommended

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.