My previous post, “SAP Parallel Process Introduction“, mentions parallel process can be implemented via SAP background process or SAP dialog process as well as factors which should be considered when we design a parallel solution. When parallel solution is implemented via SAP dialog process, SAP server group is the typical SAP solution used to control resource allocation. Resource allocation includes which server/instance of a SAP system should be engaged and how many “dialog work process” from a SAP instance can be engaged during an execution of a parallel solution. This post would walk you through technical steps on how to use SAP transaction RZ12 to configure and maintain a SAP RFC server group.
- How to start SAP RZ12 transaction,
- How to run SAP RZ12 transaction to create a new server group?
- How to run SAP RZ12 transaction to change existing server group?
- Understand SAP RFC Server group quota/resource parameters and
- Verify RZ12 RFC server group resource change.
1. How to start SAP RZ12 transaction
You can type “/nRZ12” in the SAP command/OK window to start the technical process of creating RFC server group. After you enter the code “/nRZ12” and press return key, you would see initial RZ12 screen similar to Figure 1.
Figure 1 SAP RZ12 initial screen
From RZ12 initial screen, you can do following
- Create a new SAP RFC server group,
- Add a SAP instance to a SAP RFC server group,
- Change a SAP instance’s RFC quotas/resources on the fly
- Remove a SAP instance from a SAP RFC server group and
- Remove a SAP RFC server group and a SAP instance from all SAP RFC server groups.
2. How to create a new SAP RFC server group
A new parallel solution is developed and a new server group is needed. Before you run SAP RZ12 transaction, the server group details like which and how many instance the server group should contain, how many dialog processes is needed etc. should be decided together with server group name. How to understand those RZ12 screen fields/RFC quota parameters is discussed in subsequent section of this post.
Here I would create a new server group “1_order” which would engage two instances/servers.
2.1 Start to create RFC server group
You can click the “create” Icon to create a new server group as showed in figure 1. You would get a pop-up screen similar to figure 2 for you to enter sever group details
Figure 2 Blank RZ12 Server group data screen
2.2 Enter RZ12 RFC server group detail
Based on your parallel solution need and your SAP environment, input to all fields in figure 2 should be decided. Let’s assume following inputs are entered.
Figure 3 SAP RZ12 server group input
Click “copy” button, you would see initial screen of RZ12 again but with the new server group “1_order” as showed in figure 4.
Figure 4 SAP RZ12 new server group creation 1
Now the above process is repeated to add another instance to this server group “1_order”. So the RZ12 sever group “1_order” is as showed in Figure 5.
Figure 5 SAP RZ12 new server group creation 2
If you are satisfied with your changes, you can click the “save” button in Figure 5 to save your changes. Make sure that SAP system message “Changes saved” is appeared after you clicked “Save” button. If you exit RZ12 transaction without save, your changes would be lost.
Please take note, you can only need to enter “sever group name” and “instance”, you can use instance default setting for remaining fields. To do this, you can click “copy” button in Figure 3 without entering “RFC resource parameters”, then click “Yes” on pop-up window similar to Figure 6. If you click “No”, then those RFC parameters would be left “blank”.
Figure 6 SAP RZ12 server group – copy default data
It might be efficient to copy instance default value for RZ12 fields and make additional changes on top of that. If you are using different value from what specified in instance parameters, then the parameter in the instance profile should be updated accordingly in another time. Otherwise your RZ12 value would be overwritten by instance parameters upon SAP instance/server reboot. Your changes to SAP RZ12 parameters become effective upon save. Those RFC resource parameters in RZ12 can be changed dynamically.
3 How to run SAP RZ12 transaction to change existing RFC server group.
3.1 Add new SAP instance to an existing RFC server group
This is similar to creation of new server group. You just need to click expected server group once then click the “creation” icon in the RZ12 initial screen.
3.2 Remove a SAP instance from an existing server group
To remove an instance from a server group, you can click the instance of a group which you would like to remove, then click the “Delete Assignment” button in figure 1. Here, I clicked server “b*10” entry in “1_order” group first, then I click the “Delete Assignment” button, then following screen showed up
Figure 7 RZ12 server group – remove instance
Click the “delete” button in Figure 7, you would back to RZ12 initial screen reflecting your changes, which actually gave me the same screen I had in Figure 4. If you are ok with your changes, you can save your changes now by clicking the “save” button before you exit. All RZ12 changes are not automatically saved by the system.
3.3 Change SAP RFC resources/quotas dynamically
RFC resources change is at instance level. All server groups would share the same RFC resources/quotas for the same server/instance. All RZ12 resources/quota changes are dynamic changes and it can be lost upon system reboot. If your changes are going to be permanent, you need to update the corresponding RFC parameter in the instance profile to reflect RZ12 change.
To change a resource, you can double click on any entry which contains the expected instance. Here I double clicked “B*04” instance in the initial screen, Figure 8 screen appeared
Figure 8 RZ12 Server group – change RFC resources
You can make expected changes in Figure 8. The typical change is to increase or reduce data showed in “Max. Number of WPs Used (%)” and “Minimum Number of Free WPs” fields. After you changes, you can click “copy” button in Figure 8, that brings you back to initial screen where you can save your changes.
3.4 Remove a SAP RFC server group and remove a SAP instance from all RFC server groups
To remove a server group, you can click any entry of the server group in the initial screen, then click “Delete Group” button, then the entire group is removed from RZ12.
Sometimes, an instance might be removed from the system. so this instance needs to be removed from all existing server groups in the system, to do that, you need to click “Remove Instance” button , provide instance name in following window , then click “delete” button
Figure 9 RZ12 server group – remove instance
As usual, your changes would only come into effect after you click “Save” button.
4 Understand SAP RFC Server group quota/resource parameters
Up to now, we have gone through the process of maintaining RFC server group. Here I would like to help you to understand what those parameters mean. Please refer to following chart to understand RFC parameters
Table 1 SAP RZ12 RFC quotas/parameter explanation
|Screen Field||Explanation||Associated Profile Parameter||Example|
|Activated (0 or 1)||0: Routine for resource determination is deactivated
1: Routine for resource determination is activated. You should always use 1.
Default value: 1
|Max. Requests in Queue (%)||The maximum number of waiting requests in the dialog queue of the dispatcher based on number specified by rdisp/elem_per_queue. This is to ensure that system is not overloaded further when queue has been built up.
When number of waiting requests hits this quota, then No more parallel process can be started.
Current queue length can be checked via menu Goto ->Server name -> information-> queue information in SAP transaction SM51.
default value: 5
5 means 5%.
|Assume rdisp/elem_per_queue = 2,000 (SAP default) and rdis/rfc_max_queue = 5 , then no more parallel process can be started if number of waiting request is 100 (2,000 X 5%) or more.|
|Max. No. of Logons (%)||The maximum percentage of logons to this instance (maximum total number rdisp/tm_max_no) that can be due to asynchronous RFCs. The remaining % is the reserved for non-RFC users like dialog and HTTP users. So those operations are not impacted by RFC.
Every RFC is linked to a logon in the targeted instance/server. When number of active logons hits this quota, then No more parallel process can be started.
SAP transaction SM04 can be used to display logon – one entry in SM04 screen is counted one logon in this view.
|rdisp/rfc_max_loginDefault value: 90
90 means 90%
|Assume rdisp/tm_max_no = 200(SAP default) and rdisp/rfc_max_login = 90, then no more parallel process can be started if number of RFC logon showed in SAP SM04 transaction is 180 or more for this instance.|
|Maximum No. Separate Logons(%)||The maximum percentage of logons to this instance (maximum total number rdisp/tm_max_no) that can be due to the asynchronous RFCs of one user. User is referring to USERID. If you are sharing same logon with different people, all logons are counted under one user.
When number of active logons for a user hits this quota, then user cannot start RFC process anymore.
SAP transaction SM04 can check active logons.
|Rdisp/rfc_max_own_loginDefault value: 25||Assume rdisp/tm_max_no = 200 and rdisp/rfc_max_own_login = 25, the no more parallel process can be started for a particular user after # of logon under the user is 50 or more.|
|Max. Number of WPs Used (%)||The maximum percentage of the dialog work processes that can be occupied by one RFC user session or a single job.
SAP transaction SM50 can be used to check active SAP work process.
SAP parameter rdisp/wp_no_dia shows # of dialog work process in an instance.
Default value: 75
|Assume rdisp/wp_no_dia = 50 and rdisp/rfc_max_own_used_wp = 75. Then no more parallel process can be started if # of concurrent dialog process used by the parallel session has reached 37 ( 50 X 75% = 37.5 ).|
|Minimum Number of Free WPs||Number of dialog work processes that cannot be occupied by RFCs. At least this number of dialog work processes is therefore reserved for dialog users to avoid RFC processing impact online user activities. When number of free dialog work process is equal or less than this number, no more RFC call can be started in the instance/server. SAP transaction SM50 can be used to check number of free dialog process in an instance.
Total number of available dialog work process for RFC = rdisp/wp_no_dia – rdisp/rfc_min_wait_dia_wp. Number of available dialog work process for RFC in the instance should be bigger than quota specified by rdisp/rfc_max_own_used_wp.
Default value: 1
|Assume rdisp/wp_no_dia = 50 and rdisp/rfc_min_wait_dia_wp = 10. Then no more parallel process can be started if number of free dialog work process showed in SM50 is equal or less than 10.
Total number of work processes which can be used by RFC call is 40 (50 -10 = 40).
|Max. No. of Comm. Entries (%)||the maximum percentage of communication entries of an instance (rdisp/max_comm_entries) may be occupied by parallel RFCs. You can review current active # of communication entry via menu path “Goto ->Server name -> information-> Communication Table” in SAP transaction SM51. This is to ensure that there is enough free communication entries in the instance.
When Number of entry in communication table is bigger than the quota specified by this parameter, then No more parallel process can be started.
Default value: 90
|Assume rdisp/max_comm_entries = 500 and ridsp_max_comm_entries = 90, then no more parallel process(RFC call) can be started if number of entries in the communication table reaches 450( 500 X 90%).|
|Max. wait time||The maximum period of time in seconds which system waits for subsequent check when resource is not available after load check in the system. The wait time is calculated dynamically using following formula –
wait = min (max(1,count-quota), max_wait). The count is number of used resources which are specified in above parameters like dialog process, communication entries, and quota is the resource requirement specified by the RFC parameters. Few resources that are available, the longer the wait time up to Max_wait.
You can increase the wait time to accept a longer wait time when there is a resource bottleneck.
Default value: 10
|Assume the same quota as above and rdisp/rfc_max_wait_time is 10 seconds. If there are 455 communication entries, then the wait time would be 5 seconds.
Wait = min( max( 1, 455 – 450), 10). For 458 entries, wait would be 8 seconds, if active entry is above 460 seconds, then the wait time would be 10 seconds.
In table 1, all fields with % are percentage number. For most of SAP RFC quotas, we normally use SAP default data. The often changed fields are rdisp/rfc_max_own_used_wp and rdisp/rfc_min_wait_dia_wp. Rdisp/rfc_max_own_used_wp specifies how many concurrent dialog processes a single job/user-session can engage at the same time. This should be determined based on actual performance of the business transaction/process, projected volume growth and the business performance goal for the transaction/process. I would suggest that we do not give more parallel processes than what business really needs. More parallel processes means more risk – any bug(now and future) in the solution would be amplified. In most cases, there is no linear performance improvement with added parallel processes. A parent job can launch child process which can launch it’s own RFC call some times. So higher degree of parallel process can create higher risk where resource lock( work process level lock) among RFC calls due to resource shortage can occurs. a higher value for parameter rdisp/rfc_min_wait_dia_wp instead of SAP default value 1 should be selected so online user’s experience are not impacted by possible activities. Of course, this is not an issue, if your RFC solution and online users activities happened in different hours…
In Summary, RFC quota parameters specify quotas in
- Caps on how many ARFC logons in an instance – no more aRFC is allowed in the instance if the caps is reached.
- Caps on how many ARFC logons by a single SAP user – no more aRFC allowed in the instance if this cap is reached.
- Caps on how many requests in a dispatcher queue in an instance – no more aRFC is allowed in the instance if this caps is reached.
- Caps on how many communication entries should be exist in an instance – no more aRFC is allowed in the instance if this caps is reached.
- Caps on how many parallel work processes a single execution of program/transaction can engaged – no more aRFC is allowed if this caps is reached.
- Caps on how many dialog work process should be kept free for online activities at least– no more aRFC is allowed if this caps is reached.
If a SAP instance of a SAP RFC server group is “passive”, then the instance would not be engaged in parallel solution. However, MRP job can still engaged “passive” SAP instance for parallel processing as long as the passive server is set up in SAP transaction OMIQ in the SAP version I am working with. SAP transaction SM51 can be used to check SAP server/instances status.
Again, those parameters are at instance/server level not at RZ12 RFC server group level. If you are using different value other than what specified in SAP instance profile. Please remember to update the SAP instance profile before the instance is rebooted so your changes are not lost.
5 Verify RZ12 RFC server group resource change
You can use SPBT to verify your SAP server group RFC resource quota configuration. To do this, you can run SAP transaction SPBT, then do following
- Enter SAP RFC server group you would like to check
- Click on “Init PBT Env.” Button
- Review the result to see whether it is what you expected in terms of instance engagement and number of concurrent dialog processes can be engaged by a single job/user session.
Figure 10 SPBT validate RFC resources
In Figure 10:
- Max. WPs = rdisp/wp_no_dia – rdisp/rfc_min_wait_dia_wp. SAP Instance level
- Free wps = rdisp/rfc_max_own_used_wp * rdisp/wp_no_dia / 100
- Total Wps = Sum of Max. WPS from all instance.
SAP RFC Server group name is “case sensitive” so make sure that you use the server group name exactly as what showed in RZ12.
6 Further clarification
SAP IDOC inbound program, CIF model activation program, SAP inbound and outbound scheduler etc. are using server group in their parallel solution. Some parallel solutions are not using server group, for example MRP program is using transaction OMIQ to configure the RFC resources quota.
Even RFC server group is configured but there is no guarantee that resource configured is available since quotas configured is shared by all RFC calls at SAP instance/server and resource picture of a SAP instance/server is very dynamic.
You can use SAP transaction RZ11 to review and change SAP parameters like SAP RFC resource parameters. There is another RFC parameter rdisp/RFC_CHECK. This parameter determines level of details of check on whether enough free dialog work processes are available for aRFC calls. SAP recommends that you do not change default value for this parameter.
There are parallel solutions which depend on SAP job server group. SAP job server group can be configured via SAP transaction SM61. I can cover how to use SM61 this in separate post.