Regulating/distributing the workflow load
Bottlenecks can occur in the system if resources are not optimally distributed between workflow execution and dialog users or other RFC steps.
This note describes ways of regulating the load that results from the workflow, or limiting it to certain servers.
Workflows are usually started by “triggering events”. A tRFC does this in the background. All subsequent corresponding background steps trigger an additional RFC. This means that an RFC is not run for each background step. Dialog steps and asynchronous background steps interrupt the merger of these steps into a single RFC.
A large number of tRFCs will therefore be triggered if you have workflows in your system with lots of background steps that are frequently interrupted by dialog steps or asynchronous background steps.
In high-workflow systems such as IS-U, problems can also occur if a lot of synchronous steps are run in the background.
By default, the tRFCs are executed on the server on which they were started. If the dialog user starts the workflow, it is executed on the same server as the user, up to the first dialog step.
You can choose one of the following three options to influence the load that results from the workflow processing in the system.
1. Using the SMQS QOut Schedule
The recommended and simplest way to regulate the load that is executed by a workflow on a system is to register the workflow RFC destination WORKFLOW_LOCAL_
Here, under “Max. Conn.”, you can determine the maximum number of dialog work processes that the workflow can use. You can also define an RFC server group under “Host ID”. If you are using more than one server, it can be a good idea to use certain servers exclusively for RFC. Use Transaction RZ12 to create an RFC server group that contains only the servers for the RFC processing, and save it in the SMQS qOut Scheduler. Adjust the settings in RZ12 so that a large number of dialog work processes can be used for RFC, since no normal dialog users work on these servers. Note that this setting applies to all registered RFC destinations. Therefore, if you have registered several destinations, these will now only be carried out on these servers.
However, if the runtimes of the RFCs are very different, this setting may mean that the RFCs are not processed quickly enough even though there are enough resources available.
In the QOut Scheduler, the status is set to WAITING for the destination WORKFLOW_LOCAL_
Example: If “Max. Conn.” is set to 50, and there are sufficient resources, 50 tRFCs are taken from the tRFC Queue and processed in parallel.
If 49 tRFCs are processed in 500 milliseconds, and one tRFC lasts for 2 minutes, the queue is blocked for 2 seconds before the system can process a new package.
During the period, a maximum of one work process is in use, and the qOut Scheduler has the status ‘Waiting’. If this scenario occurs, find out why the runtime of the tRFC is so high.
In releases prior to 6.20, the tRFCs may be processed under another user . Also refer to Note 716263.
2. Using an R/3 connection instead of Logical Destination
You have several entries in the SMQS, or the problem described under Point 1 above has occurred, and you want to run the workflow on one or more dedicated servers rather than registering the Workflow RFC Destination.
By default, the type L workflow RFC destination is the logical destination. You can delete this destination in Transaction SM59 and create a new destination with the same name, but with a type 3 R/3 connection. Here, you can determine one or more servers for workflow processing by means of a log-on group. Define the workflow background user WF batch as the user. If you do not know the password, you can change it in Transaction SU01. Note that this can cause problems if you use the workflow background user somewhere else as well. Change the password there too.
If you are not using one specific server, but instead are using Load Balancing through a log-on group, set the flag “ext. RFC enabled” in the attributes of the defined logon group using Transaction SMLG (double click on the logon group Attributes). The RFCs are then distributed to the individual servers in the round robin procedure. This function is only available as of Release 6.20 or higher. Only the active server of the logon group is used in releases prior to 6.20. The system responds as if there were only one server. See also Note 593058.
Note that these settings can cause problems if you have a very high load. Set the Gateway parameter as described in Note 384971. Extreme loads can cause the gateway to overflow and the RFCs to terminate. If this happens, make sure you have sufficient resources (memory, dialog work processes, CPU) to process the load.
3. Start certain workflows on certain servers
You can execute each workflow on a specific server. To do this, you must first find out which workflows run on your system. If the workflows are triggered by events, there is a corresponding event entry for the workflow in Transaction SWE2, which displays the link between the above “triggered event” and the workflow model. In this transaction you can define an RFC Destination for each linkage. In SM59, you then create type 3 RFC Destinations that point to individual servers or, by means of Load Balancing, to several servers (set the flag “ext. RFC enabled” in Transaction SMLG). You should use WF-batch as a user. Also see the comments in section 2. Define these new destinations in Transaction SWE2.
If the event is now triggered, the workflow is started on the server that is defined in the destination. All further background steps that are part of this workflow will continue to be executed by means of workflow RFC destination WORKFLOW_LOCAL_
Workflow : Other Useful Links :
Org units in workflow steps?
‘No Administrator found’ workflow error
LIV & Payment Release workflow
Viewing another user’s workflow inbox
How can I temporarily disable a workflow in production?
Raising ABAP OO events for workflow