In the process overview (transaction SM50), there are processes with the status "stopped RFC". A work process is assigned and cannot be interrupted (rolled out) during a data transfer, that is, when sending or receiving parameters of a remote function module. You can roll out the ABAP context from a work process and release the work process only after the transfer.
If a remote function module is called from a batch, update, update2 or spool process (no dialog work process), the work process remains in the status "stopped" with the reason "RFC" for the entire execution time of the remote function module. This is because this type of work process may not be interrupted (rolled out). This behaviour is not an error.
Related: Add on installation Stops in IMPORT_PROPER phase via SPAM or SAINT
Also, when RFCs are executed from a dialog process, the ABAP context cannot be rolled out (interrupted) if the following conditions exist:
* The language element "SET UPDATE TASK LOCAL" is set in the program.
* Update function modules are processed in the program.
* RFCs are executed from an update function module.
Comment: Through the language element "SET UPDATE TASK LOCAL", the update function modules are executed without an interruption in the same context. As a result, remote function modules must be executed without interruption. This means that, during the execution phase of the remote function module, the status of the dialog work process is displayed as "Stopped" with the reason "RFC". Solution
If a remote function module is called from a dialog process, the problem is usually due to a resource bottleneck (in other words, the gateway memory in the sending and receiving application server, the number of available dialog work processes on the receiving application server, and the corresponding performance of the application servers involved).
Related: Work Process: Types in SAP
If there are work processes in the status "Stopped" with the reason "RFC" (or "CPIC") in the process overview transaction (SM50), the problem may involve one of the following situations.
- The RFC module executes activities that can incur a long processing time. This can happen because, for exampe, in the context of the RFC module the program executes additional RFCs that communicate with external (non-SAP) RFC servers. In this case, the participating application must examine the possible causes of the processing delays. Determine what participating RFC applications have the status "Stopped RFC" in SM50, and forward the problem message to the affected components for a more thorough examination.
- There is a gateway memory bottleneck: Each application server has its own gateway. During RFC communication between two SAP application servers, the RFC data is transferred via the local gateways of the sending and receiving application server. You must therefore ensure that the gateways involved have the necessary memory for the RFC data communication. You can use the following profile parameters to adjust (increase) the memory setting of the gateways accordingly.
"gw/max_overflow_size": This parameter specifies the size of the local memory area in which the SAP Gateway manages the received requests.
"gw/max_overflow_usage": This specifies the maximum proportion of the overflow area (in %) that can be used before the gateway "halts" its clients (in other words, it sends SYSN requests).
Comment: These are dynamic profile parameters that can also be changed temporarily for the purposes of testing (either by executing transaction RZ11, or by executing transaction SMGW and choosing "Goto" -> "Parameters" -> "Change").
RFCs of any type (synchronous, asynchronous, parallel, transactional and queued RFC) are processed in dialog processes, even if they are started from a non-dialog work process (such as background or update). Therefore, a bottleneck in the available dialog work processes for each application server may also contribute to this situation. You must check the following settings for each application server:
You must make sure that the number of configured dialog work processes for each application server is greater than the number of non-dialog work process types (in other words, update, update2 and spool work processes). This is because, in principle, RFCs executed in dialog work processes can be processed from all process types (see 74141 for information).
Setting the load distribution profile parameters to inappropriate values (see 74141) to avoid the overload may cause the number of dialog processes for executing RFCs to be drastically reduced. Check the settings of the profile parameters rdisp/rfc_check and rdisp/min_wait_dia_wp, among others.
If you encounter this situation, you can gather more information to localize the cause of the problem as follows:
1. Display the details of the work process information in transaction SM50: Select the affected work process and choose "Process" -> "Details". For example, for the following entry:
BTC 32420 stopped RFC Yes 42 RSMRFC02 000 AGHADAVOODI
2. Here, you can determine the affected conversation ID for RFC communication in the area "Function/Conversation ID". By analyzing this conversation ID (either by selecting the conversation ID in the details display or by selecting in transaction SMGW), you can determine the target server (the communication partner). In our example:
Gateway ld0011 CMRCV / 42484534 15:08:50
And the detailed information for the conversation ID 42484534 is:
Client Server
LU Name ld0011 10.21.81.241
TP Name sapgw01 sapdp01
Host name ld0011.wdf.sap.corp ld0012.wdf.sap.corp
Host address 10.21.80.211 10.21.81.241
System type LOCAL_R3 REMOTE_GATEWAY
Number 0 59
As already mentioned, by determining the target server, you can (provided it is a SAP Web Application Server) analyze the settings of the gateway parameters concerning memory profiles and the number of configured dialog work processes, and adjust them if necessary.
Comment: Before you adjust the gateway profile parameters gw/max_overflow_size and gw/max_overflow_usage, you must use the gateway statistics to analyze the status of the gateway memory consumption. This is because it only makes sense to increase the profile parameters in question if there is a gateway memory bottleneck in the area. To this end, the gateway transaction (SMGW) provides statistics under the following menu options:
- Basis Release 46C/46D: Choose '"Goto" -> "Statistics"
- Basis Release 620 and higher: Choose '"Goto" -> "Expert functions" -> "Statistics"
If you have not already activated the gateway statistics, you must make sure that they remain activated at least until the "Stopped RFC" status appears.
When you display the statistics, under the entry "Maximum memory use (%)" you can use the profile parameter "gw/max_overflow_size" to determine the maximum amount of gateway memory that is used. If this value reaches or exceeds 70%, you should consider increasing the value of the profile parameter.
To be able to estimate the influence of the profile parameter "gw/max_overflow_usage" on the process status, increase the current setting to 50% and monitor its effect on the overall situation. If this does not improve the situation, reset the parameter to its old value.
Also, you can use the statistics entry "kB/sec (written/read)" to control the average data throughput. By observing this value, you can also establish whether the adjustments you have made to the profile parameters "gw/max_overflow_size" and "gw/max_overflow_usage" have led to significant improvements in the data throughput of the gateway.