arfc_e- SAp ARFC and TRFC Monitoring Document

Configuring System Resources for Parallel RFC, tRFC, and

qRFC

HE

LP

.BC

CS

TA

DM

Re lease 630

SAP Online Help 05.06.2003

Configuring System Resources for Parallel RFC, tRFC, and qRFC 630 2

Copyright © Copyright 2003 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation. IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries. ORACLE® is a registered trademark of ORACLE Corporation. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA® is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One. SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are trademarks of their respective companies.



Icons

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Typographic Conventions

Type Style Description

Example text Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths and options.

Cross-references to other documentation. Example text Emphasized words or phrases in body text, titles of graphics and tables.

EXAMPLE TEXT Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example, SELECT and INCLUDE.

Example text Screen output. This includes file and directory names and their paths, messages, source code, names of variables and parameters as well as names of installation, upgrade and database tools.

EXAMPLE TEXT Keys on the keyboard, for example, function keys (such as F2) or the ENTER key.

Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.

<Example text> Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.



Content Configuring System Resources for Parallel RFC, tRFC, and qRFC ......................................... 5

RFC Resources on the Application Server ............................................................................ 6 Monitoring RFC Resources on the Application Server ...................................................... 8

System Configuration for Parallel RFCs .............................................................................. 10 Dynamically Configuring RFC Quotas ............................................................................. 11 rdisp/rfc_check ................................................................................................................. 13 rdisp/rfc_use_quotas ........................................................................................................ 13 rdisp/rfc_max_queue........................................................................................................ 14 rdisp/rfc_max_login .......................................................................................................... 14

rdisp/tm_max_no .......................................................................................................... 15 rdisp/rfc_max_own_login.................................................................................................. 15 rdisp/rfc_min_wait_dia_wp............................................................................................... 16 rdisp/rfc_max_own_used_wp........................................................................................... 16 rdisp/rfc_max_comm_entries ........................................................................................... 17

rdisp/max_comm_entries.............................................................................................. 17 rdisp/rfc_max_wait_time................................................................................................... 18

Calculating Resources for Asynchronous and Transactional RFC...................................... 18 Local Check...................................................................................................................... 20 Detailed Check ................................................................................................................. 20 Triggering the RFC Client Resource Check..................................................................... 23

Problems with RFC Resource Assignment.......................................................................... 24



Configuring System Resources for Parallel RFC, tRFC, and qRFC Use An application can make calculations and collect data simultaneously by using parallel RFCs. This can also happen indirectly, as with the inbound queue in qRFC. Every RFC request occupies a dialog work process on the application server on which the RFC is executed.

This section describes how to configure your system to use parallel RFCs.

Integration The following RFC types use the resource checks described in this documentation.

Asynchronous RFC with Load Balancing (Parallel RFC) You can use this RFC type to program parallel RFC calls. The resources are checked and assigned as far as the set quotas allow.

The required ABAP language element is:

CALL FUNCTION <func> STARTING NEW TASK <task> DESTINATION IN GROUP <group>

With this ABAP command, you are telling the SAP system to process function module calls in parallel. The command implements parallel processing by sending asynchronous RFC calls to the appropriate servers. These are servers in the RFC server group group specified as being available for processing requests. The group name DEFAULT means that all available application servers are being used.

qRFC with Outbound Queue The qRFC LUWs are executed using the outbound scheduler. The outbound scheduler uses parallel RFC for processing the outbound queue. For this to be possible, you have to maintain the destinations using transaction SMQS.

The outbound scheduler then checks the resources and executes parallel RFCs, if resources are available. If no resources are available, synchronous RFC is used.

qRFC with Inbound Queue If you are using the inbound queue, the inbound scheduler takes over the processing of the inbound queue. You have to register the queue names to be processed using the inbound scheduler. To do this, use transaction SMQR.

The inbound scheduler then checks the resources and executes parallel RFCs, if resources are available. If no resources are available, the scheduler waits until resources become available.

For more information, see Monitor Transactional RFC and Queued RFC [external documantation].

Transactional RFC Transactional RFC uses resource checking only. It does not use parallel RFCs.

The required ABAP language element is:

CALL FUNCTION <func> DESTINATION <dest> IN BACKGROUND TASK

This ABAP command flags the function module func for asynchronous processing. The module is not executed immediately. The data transferred with EXPORTING or TABLES is



placed in a database table. A COMMIT WORK then triggers the function module. There are various cases:

• The data is updated. In this case the function module is executed within the update following the V1 phase, usually even on a different server.

• The data is not updated. In this case the function module is executed in the same work process.

Note that RFC calls with CALL FUNCTION are processed in DIALOG work processes. Therefore, the DIALOG limitation for processing a dialog step (default: 300 seconds, system profile parameter rdisp/max_wprun_time) also applies to these RFC calls. Remember to take this limitation into consideration when you are dividing up your data packets for parallel processing.

See also the following sections:

Parallel Processing with Asynchronous RFC [external documantation]

Defining RFC Groups for Parallel Processing Jobs [external documantation]

Features The documentation on using parallel RFCs is divided into the following sections.

RFC Resources on the Application Server [page 6] describes which resources are relevant for the use of parallel RFCs, and how you can monitor the available resources system-wide.

System Configuration for Parallel RFCs [page 10] describes how you can manipulate RFC resources, either dynamically or using corresponding profile parameters.

Calculating Resources for Asynchronous and Transactional RFC [page 18] describes how resource checking in the system works. Both local checking and remote checking (that is, checking on another server) are described.

Constraints

Note that the techniques for monitoring and controlling resources described in this document only apply to the RFC types mentioned above.

Even if you have correctly configured the quotas, your system may still become flooded with RFCs if these are not of the correct types (such as synchronous RFCs, qRFC without inbound queue, asynchronous RFCs without the added DESTINATION IN GROUP …).

Known problems, their causes and solutions are described in the following section:

Problems with RFC Resource Assignment [page 24]

RFC Resources on the Application Server The graphic below shows the SAP application server resources relevant for parallel RFC.



Dialog queue

DB

Gat

eway

Oth

er a

pp. s

erve

ror

SA

P sy

stem

Message server

SAP application server

Dialog work processesNon-dialog

work processes

Non-dialog queue

RFCRFC RFC

GUIGUIGUI

Dispatcher

RFC logons

Comm. table

Dialog WPs to be kept free

RFC requestsin dialog queue

Entries in thecomm. table

Maximum number of dialog WPs occupied by a user

The resources that can be manipulated are discussed below.

Logging On to the SAP System A total of rdisp/tm_max_no [page 15] users can be simultaneously logged on to the server (using the GUI or RFC). If rdisp/rfc_max_login [page 14] percent of the maximum number of users are logged on, no more RFC logons can be accepted. An RFC user may occupy a maximum of rdisp/rfc_max_own_login [page 15] percent of the login slots (see isp/tm_max_no [page 15]).

Display: User List (transaction SM04). For more information, see Display and Manage User Sessions [external documantation].

RFC Requests in the Dialog Queue The dialog queue of the dispatcher contains rdisp/elem_per_queue entries. A maximum of rdisp/rfc_max_queue [page 14] percent of these may be filled by RFC requests.

Display: SAP servers (transaction SM51): Goto → Server Information → Queue Info. For more information, see Overview of SAP Application Servers [external documantation].

Entries in the Communication Table The communication table contains an entry for every CPIC communication for all parties involved. The table can contain a maximum of rdisp/max_comm_entries [page 17] entries. rdisp/rfc_max_comm_entries [page 17]percent of these may be occupied by one user.

Display: SAP servers (transaction SM51): Goto → Server Information → Communication table. See also Overview of SAP Application Servers [external documantation].

Dialog Work Processes When the server is started, it has rdisp/wp_no_dia dialog work processes. This number can, however, be changed while the server is running. One way to do this is to use operation mode switching. You can find out the current number of processes in the Process Overview (SM50; see also Display and Control Work Processes [external documantation]). Of the dialog work processes, the dispatcher keeps rdisp/rfc_min_wait_dia_wp [page 16] free for “genuine” dialog requests (not RFC).



A user may occupy a maximum of rdisp/rfc_max_own_used_wp [page 16] percent of dialog processes.

The same parameters are used to control the number of plugin requests (HTTP or SMTP requests coming from ICM [external documantation]) that can be processed at the same time. See ICM Parameters [external documantation].

Overview of All RFC Resources in the SAP System Transaction SARFC is used to monitor the resources on all servers in the SAP system. This is described in the section Monitoring RFC Resources on the Application Server [page 8].

Monitoring RFC Resources on the Application Server Use You can monitor the RFC resources on all application servers and thus find out the load incurred by parallel RFCs on a server.

You can also dynamically change the various quotas on all servers. For procedure for doing this is described in the section Dynamically Configuring RFC Quotas [page 11].

Procedure Execute the transaction SARFC.



You then see a list of all SAP servers with information for each server, stating whether resources for asynchronous RFCs are available at the time you executed the transaction (text Resources OK) . If no resources are available, a short text explaining the reason is displayed.

Note that this list only represents the situation at the exact moment that you executed the transaction. To get an impression of the overall situation, choose Refresh ( ) a number of times.

This is a list of the possible results of the resource check with return values and meanings.

0: resources are available on the server. The text ‘Resources ok’ is displayed.

1: the resource check is deactivated (parameter rdisp/rfc_use_quotas is set to 0).

The other return values indicate that the server currently has no available resources for asynchronous RFCs.

The server may have no resources for one of the following reasons:

• The server is not running.

• The server has been wrongly configured.

• An unexpected error has occurred.

In these cases, the text appears on a red background. You can find out the exact cause of the problem (for example, where exactly the incorrect configuration is located) by briefly activating and deactivating the trace for the server (see below). See the dispatcher trace file dev_disp of the server for the required information.

The individual return values are described below. Each value has a text (appears on a yellow background).

2: the server has too few free dialog work processes.

3: the quota for the RFC communication channels is too small. Increase the parameter rdisp/rfc_max_comm_entries [page 17] or change the value dynamically [page 11].

4: the quota for the RFC communication channels (rdisp/rfc_max_comm_entries [page 17]) has reached its maximum.

5: the local queue for asynchronous RFC responses is full. This queue retains the responses to asynchronous RFCs until they are sent back to the caller. You can increase the size of the queue by increasing the value of the parameter rdisp/max_arq.

6: the quota for a dialog work process occupied by an RFC user is too small. Increase the size of the parameter rdisp/rfc_max_own_used_wp [page 16] or change the value dynamically [page 11].

7: the quota for a dialog work process occupied by an RFC user (rdisp/rfc_max_own_used_wp [page 16]) is too small.

8: the quota for the RFC requests in the dialog queue is too small. Increase the size of the parameter rdisp/rfc_max_queue [page 14] or change the value dynamically [page 11].

9: the quota for the RFC requests in the dialog queue (rdisp/rfc_max_queue [page 14]) has reached its maximum.

10: an error occurred when the request queue length was being determined.

11: the quota for RFC logons to the server is too small. Increase the size of the value of the parameter rdisp/rfc_max_login [page 14].

12: the quota for RFC logons to the server (rdisp/rfc_max_login [page 14]) has reached its maximum.



13: the quota for own RFC logons to the server is too small. Increase the size of the parameter rdisp/rfc_max_own_login [page 15] or change the value dynamically [page 11].

14: the quota for own RFC logons to the server (rdisp/rfc_max_own_login [page 15]) has reached its maximum.

15: the server is deactivated and cannot process any requests.

16: the server is being stopped.

17: the server has been stopped.

18: the server is being started.

19: the server has just been started and is in the initialization phase.

20: the server is in an unknown state.

Activating the Trace Choose Goto → Activate Trace. The system then writes the detailed result of the check to the trace file of the dispatcher on the server in question. To read the file, you have to log on to the server in question. To do this, open transaction SM51, double-click on the server name, then choose Process → Trace → Dispatcher → Display File.

It may make sense to do this if, for example, a server constantly has too few resources, and you want to find out the exact cause.

System Configuration for Parallel RFCs Use You can optimize the configuration of your SAP system for the purposes of working with parallel RFCs. This section describes the tools (profile parameters, transactions, and so on) you use to do this.

Prerequisites To use parallel RFCs, your system has to be configured accordingly and must meet the following prerequisites.

More dialog work processes than non-dialog work processes have to be configured on every server that is available for processing parallel RFCs.

The profile parameter rdisp/wp_no_<wptyp> uses <wptyp> = dia, spo, vb, vb2, btc to determine the number of work processes of one type. This number is not, however, necessarily the most up-to-date number, as the work process types can be changed while the server is in operation (by means of operation mode switching, for example). You can find out the current number of work processes in the Process Overview (SM50; see also Display and Control Work Processes [external documantation]).

Procedure A range of profile parameters is available for resource distribution during the processing of parallel RFCs. These parameters are described in the following sections:

rdisp/rfc_check [page 13]

rdisp/rfc_use_quotas [page 13]

rdisp/rfc_max_queue [page 14]

rdisp/rfc_max_login [page 14]



rdisp/rfc_max_own_login [page 15]

rdisp/rfc_min_wait_dia_wp [page 16]

rdisp/rfc_max_own_used_wp [page 16]

rdisp/rfc_max_comm_entries [page 17]

rdisp/rfc_max_wait_time [page 18]

To view more RFC parameters, open transaction RZ11 and search for isp/rfc*.

Note that the parameters rdisp/rfc* only apply to the above-mentioned RFC types, and not to any other types, such as synchronous RFC or asynchronous RFC without a group.

In other words, the parameters only apply to qRFC and parallel RFC.

While setting the parameters, you can also change the aRFC resources. You can do this before running the application that uses a high volume of parallel RFCs.

To do this, use transaction SARFC, as described in the section Dynamically Configuring RFC Quotas [page 11].

Dynamically Configuring RFC Quotas Use The report RSARFCLD is used to dynamically configure the RFC quotas on the server to which you are logged on.

Unlike parameter changes in the profile, these settings are lost when you next restart the computer.

Procedure Execute the transaction SARFC.

You are then shown which servers are currently available in the system, and how the system is handling resources for asynchronous RFCs on the servers (see Monitoring RFC Resources on the Application Server [page 8]).

Double-click on a server name. You then see the following screen:



If you have the necessary authorization, you can enter change mode and change the values.

The values that you set here overwrite (until the next restart) the following parameter values (in the same order):

rdisp/rfc_use_quotas [page 13]








The new values are activated when you save.

Result The quotas for RFC resources have now been re-set.

Note that the settings you make using the report only apply to the instance to which you are currently logged on, and are lost when the instance is next re-started. The parameter settings in the profile file then apply again.



rdisp/rfc_check Definition In this parameter you can set the level of detail of the check made by the RFC server dispatcher. The dispatcher checks whether sufficient dialog work processes are free for processing asynchronous RFC calls.

Use The number of available dialog work processes depends on the number of free dialog work processes and on the number of work processes that must be kept free for the dialog application. (Compare with rdisp/rfc_min_wait_dia_wp [page 16]).

If no work process is free, the request is placed in the queue and processed later.

The check can be set at the following levels:

Level 0: no check

Level 1: monitors the start of all asynchronous RFCs

Level 2: Monitors, additionally to level 1, all RFCs started anew from asynchronous RFC sessions. This includes synchronous RFCs. So that applications that transmit a lot of RFCs can run at this level, the number of dialog processes used for RFCs may have to be increased. (rdisp/rfc_min_wait_dia_wp [page 16] may have to be reduced).

Level 3: monitors all RFCs (synchronous and asynchronous).

Unit: Whole number between 0 and 3

Default value: 1

rdisp/rfc_use_quotas Definition This parameter is used to activate the use of quotas for resource allocation. The following values are possible:

• 0: resource allocation deactivated

• 1: resource allocation activated (default)

Use

If the parameter is set to 0, all other rdisp/rfc* parameter settings are irrelevant. In this situation, you cannot use parallel RFCs. The system acts as if all resources were in use and always returns the same corresponding return value.

Therefore, we recommend that you do not change the default setting.

Resource allocation is either carried out dynamically (see Dynamically Configuring RFC Quotas [page 11]), via RFC group maintenance, or in the profile via the following parameters:










If you do not want your changes to be permanent, you have the option of dynamically configuring RFC quotas [page 11].

rdisp/rfc_max_queue Definition This parameter specifies the contingent for the maximum number of outstanding requests in the dialog queue.

Use RFC is executed on the target server in a dialog work process. Therefore, if there is currently no free dialog work process, the request is placed in the dialog queue of the dispatcher. You should ensure that the queue never becomes full.

The value is given as a percentage of the entire dialog queue. In other words, it is dependent on the value currently set in the profile. The parameter rdisp/elem_per_queue (default 2000) specifies the absolute number of requests in the queue.

Unit: percentage

Default value: 5

Integration You should set this value quite small, as the dialog requests are also kept in this queue, and it is important that the queue does not become full.

Example If you retain the default setting of 2000, the dialog queue can accept a maximum of 2000 requests. If you set rdisp/rfc_max_queue to 1 and the queue already contains 20 entries when a new RFC request comes in, the request is rejected.

rdisp/rfc_max_login Definition This parameter describes the contingent for the number of users logged on to the SAP system.

Use The parameter rdisp/tm_max_no specifies the absolute number of logons to the SAP system. Open the User List (transaction SM04, see Display and Manage User Sessions



[external documantation]) to see how many users are currently logged on to a server in the SAP system. The User List also displays whether each logon is a GUI or an RFC logon.

This parameter therefore sets the percentage of possible logons, which, once exceeded, causes any further RFC logons to the server to be rejected.

Unit: percentage

Default value: 90

Example Let us assume that rdisp/tm_max_no [page 15] is set to 100, and rdisp/rfc_max_login to 90. Once there are 90 logons on the system (whether they are GUI or RFC logons is not important), no more logons of the type RFC can be accepted. 10 more logons of the type GUI can, however, still be accepted. Once the eleventh GUI logon attempt is made, the server returns the message “Maximum number of terminals reached”.

rdisp/tm_max_no Definition This parameter restricts the maximum number of users per instance.

Use You can thus restrict how many users can log onto an instance simultaneously. All types of logons are counted (GUI, RFC, or HTTP).

You can display a list of the users logged on in an instance by opening the User List (transaction SM04) (see Display and Manage User Sessions [external documantation]).

Unit: integer

Default value: 200

Structure The dispatcher creates information about the logged on users in the structure tm_adm. This parameter defines the size of this structure. This value cannot be dynamically changed.

rdisp/rfc_max_own_login Definition This parameter is the cut-off value for the number of own logons in the SAP system. It is different from the parameter rdisp/rfc_max_login [page 14] in that in this case, it is the logons of one user only that may not exceed the quota.

Use This value is, therefore, a percentage of rdisp/tm_max_no [page 15]. It restricts the logons of an (RFC) user and thus prevents a program from sending RFCs to such a degree that other (RFC) users cannot log on to that server.

Unit: percentage



Default value: 25

Example If you want to assign to entire RFC resources of a server to one application, you have to increase the parameter. You could increase it to the value of rdisp/rfc_max_login [page 14], for example.

rdisp/rfc_min_wait_dia_wp Definition Number of work processes kept free for other users.

Use This parameter is used to reserve a number of dialog work processes for dialog mode. It prevents parallel RFCs from occupying all the processes.

The parameter rdisp/wp_no_dia specifies the absolute number of dialog work processes.

Unit: number of dialog work processes

Default value: 1

Example If 10 dialog work processes are configured for the instance (rdisp/wp_no_dia = 10) and the parameter rdisp/rfc_min_wait_dia_wp = 3 is set, parallel RFCs can occupy a maximum of 7 dialog work processes. 3 dialog work processes always remain free for dialog mode.

rdisp/rfc_max_own_used_wp Definition This parameter determines the contingent of dialog work processes that an RFC user may occupy simultaneously. The value is specified as a percentage of the configured dialog work processes.

Use You can use this parameter to prevent a user (or an application that is sending RFCs) from occupying all the dialog work processes on the target server.

• This parameter is effective only in dialog mode. If the report is running in

the background or in update mode, it is ignored.

• This parameter is valid only if the check is carried out on your local server (compare Determining Resources for Asynchronous and Transactional RFCs [page 18]). If the check is carried out on a remote server, the parameter is ignored and the next more restrictive quota takes effect.



• The user name is not checked. This means, if one user logs on several times with the same name (name appears several times in SM04), each of these entries is valid as an individual user (compare Displaying and Managing User Modes [external documantation]).

When the server is started, it has rdisp/wp_no_dia dialog work processes. This number can, however, be changed while the server is running. One way to do this is to use operation mode switching. You can find out the current number of processes in the Process Overview (SM50; see also Display and Control Work Processes [external documantation]).

Unit: percentage

Default value: 75

Example Let us assume that the parameter is set to the default value of 75, and you have 10 dialog work processes, of which 2 are reserved for dialog operation (rdisp/rfc_min_wait_dia_wp [page 16]). The parameter then has the effect that an RFC application can occupy a maximum of 7 work processes at any one time. This number represents the minimum number of work processes calculated from the work processes that are available for RFC (10-2=8) and the percentage defined by the parameter (75% of 10 is 7.5, of which the whole number is 7).

If you want an RFC application to have all the resources on the target server, set this parameter to 100. Then, rdisp/rfc_min_wait_dia_wp [page 16] is the last restricting factor.

rdisp/rfc_max_comm_entries Definition Contingent for the maximum number of communication entries that a user may occupy.

Use The value specifies the percentage of communication entries that may be occupied by parallel RFCs.

This guarantees that the communication table can still administrate other CPIC conversations.

If this value is exceeded, no more RFC requests can be accepted, so that the server does not become overloaded.

The parameter rdisp/max_comm_entries [page 17] specifies the absolute number of communication entries.

Unit: percentage

Default value: 90

rdisp/max_comm_entries Definition This parameter specifies the maximum number of communication entries on an application server.



Use This parameter allows you to control the number of RFC/CPIC connections on an application server.

Every RFC or CPIC communication with a partner program requires an entry. If the initiator and recipient of an RFC/CPIC program are running on the same application server, two entries per communication are required.

Every communication entry requires 100 bytes of shared memory.

Unit: number of RFC/CPIC connections

Default value: 500

rdisp/rfc_max_wait_time Definition This parameter determines the maximum period of time in seconds that the system waits after a load check. The wait time is calculated based on the amount of available resources. The fewer resources that are available, the longer the wait time.

Use You can increase the wait time if you suspect that a resource bottleneck is about to occur, and if you cannot resolve the bottleneck and are prepared to accept a longer wait time.

Unit: seconds

Default value: 10

Calculating Resources for Asynchronous and Transactional RFC There are two stages in calculating the resources for an application server. First, the system checks whether there are enough local resources for the check (communication channels and space for ARFC responses). Second, if there are enough resources, the detailed check is then carried out. If you want to carry out a check on the application server, this is done in the work process. If you want to carry out a check on another application server, the dispatcher of this server takes on the check.

The check algorithms are executed in the SAP kernel and are described in detail in the following chapters:

Local Check [page 20]

Detailed Check [page 20]

On the client you can also carry out a resource check on the RFC server. To do this use the ARFC options in transaction SM59. These are described in section: Triggering Resource Checks on RFC Client [page 23].



You can control how detailed the check is on the server using the parameter rdisp/rfc_check [page 13].

Checking the Resources on the Local Application Server To carry out a local check, call the function module TH_ARFC_LOCAL_RESOURCES.

This function module has the following parameters:

• CHECK_CLIENT_ONLY: if this parameter is set to 1, the check only checks whether there are enough communication channels and space for aRFC responses. This procedure of this check is described in the section Local Check [page 20].

If CHECK_CLIENT_ONLY is not set, the detailed check [page 20] is carried out next in the work process.

• TRACE: if the trace parameter is set, the calculated resources are written to the trace file of the dispatcher, dev_disp.

The function module returns the following export parameters:

• NORES: number of resources for asynchronous RFC

• WAIT: default value for wait time (in seconds)

• REASON: reason why no resources are available

• MAXRES: maximum number of available resources

• IREASON: reason why no resources are available (internal)

Checking the Resources of Another Application Server The function module TH_ARFC_REQUESTS is used to check the resources of another server. This function module has the following import parameters:

• SERVER: on which server should the resources be calculated?

• TRACE: see above

The function module has the following export parameters:

• NOREQ: number of possible asynchronous requests

• MAXREQ: maximum number of possible asynchronous requests

• REASON: reason why no resources are available

• CREASON: reason why no resources are available

When the resources of another application server are checked, first the local check [page 20], then the detailed check [page 20] are carried out by the dispatcher of the remote application server.

Reducing Resources Each resource may be reduced, if the current usage is very close to the quota. new_resource = min((quota-count),resource)

Default Wait Time If no more resources are available, the system offers the caller a wait time. The maximum wait time (max_wait) is set using the profile parameter rdisp/rfc_max_wait_time [page 18]. The default is 15 seconds. The wait time is calculated as follows: quota = resource * parameter value / 100 count = current usage of resource As no resources are provided, count > quota wait = min (max(1,count-quota), max_wait).



Local Check The local check checks whether any resources are available locally. It makes sense to carry out a detailed check [page 20] only if local resources are available. If no local resources are available, the detailed check [page 20] is not carried out. The local check is always carried out in the work process.

(Only the whole number counts, numbers after the decimal point are ignored.)

The check proceeds as follows.

Initially, the maximum resources are set to 10,000: resources = 10000. ...

1. The communication channels are checked. Specifically, the system checks that there are still enough entries in the communication table (display using transaction SM51 → Go to → Server information → Communication table).

...

a. The following calculation is performed: quota = (rdisp/max_comm_entries*rdisp/rfc_max_comm_entries) / 100 (only the whole number counts, numbers after the decimal point are ignored). If the quota is 0, the reason TH_ARFC_RES_LOCAL_LOW_MAX_COMM_ENTRIES and the return value = 2 (NEVER_GET_RESOURCES) are set.

b. The system determines the number of communication channels in use, sets the quota to this value, and checks whether the maximum quota has been exceeded.

c. If the quota has been exceeded (count>quota), no resources are returned, and the reason TH_ARFC_RES_LOCAL_MAX_COMM_ENTRIES and the return value 0 are returned.

d. Otherwise, the resources are calculated afresh (and may be reduced) (new_resources=min(quota – count, resources)), and the reason TH_ARFC_RES_OK and the return value 0 are returned.

2. Number of asynchronous messages. The work process can temporarily store only a limited number of asynchronous messages. The profile parameter rdisp/max_arq (default value=200) determines the exact number. This value cannot be dynamically changed.

...

a. quota = max(rdisp/max_arq – act_size – 20, 0 ). Besides the currently occupied queue entries, a buffer of 20 is subtracted.

b. count = asyn_rfcs (number of asynchronous RFCs).

c. If the quota has been exceeded (count>quota), no resources are returned, and the reason TH_ARFC_RES_LOCAL_ARFCQUEUE and the return value 0 are returned.

d. Otherwise, the resources are calculated afresh, and the reason TH_ARFC_RES_OK and the return value 0 are set.

Detailed Check This check can take place either in the dispatcher or in the work process. If the local application server is being checked, the check takes place in the work process; if another server is being checked, it takes place in the dispatcher of the server. This means that a free dialog work process is not needed to process the request. The caller’s time is thus not wasted, as it does not have to wait for a free work process.



The procedure is as follows: ...

1. The maximum number of available resources is calculated thus: number of dialog work processes (dia_wps) – number of dialog work processes that have to stay free for the dialog user (wait_dia_wps). The profile parameter rdisp/rfc_min_wait_dia_wp [page 16] performs this calculation. If the number of dialog work processes is smaller than the number of work processes that have to stay free, the number is then set to wait_dia_wp = dia_wps – 1.

2. The system also checks whether resource identification is active. If resource identification is not active – which is not allowed – the return value is set to 2 and the reason is set to TH_ARFC_RES_NOT_ACTIVATED.

3. The system checks whether there are free work processes available to accept requests.

...

a. The number of free work processes is calculated (waiting_wps).

b. If waiting_wps <= wait_dia_wps, no resources are returned and the reason TH_ARFC_RES_WAITING_DIAWP and the return value 0 are set.

c. The resources are calculated again.

First of all the number of work processes occupied with active RFCs is calculated. (function DpGetExtCheckedResourcesCnt). This number is deducted from the maximum number of processes available:

dia_wps-wait_dia_wps–DpGetExtCheckedResourcesCnt()

. Take this value and compare it to the number of currently free dialog work processes. Whichever is the lower of the two values equals the number of resources available.

resources=min(waiting_wps,(dia_wps–wait_dia_wps-DpGetExtCheckedResourcesCnt()))

4. The communication channels are checked. Specifically, the system checks that there are still enough entries in the communication table (display using transaction SM51 → Go to → Server information → Communication table).

...

a. quota = (rdisp/max_comm_entries * rdisp/rfc_max_comm_entries) / 100 (only the whole number counts, numbers after the decimal point are ignored). If the total is 0, the reason TH_ARFC_RES_LOW_MAX_COMM_ENTRIES and the return value 2 (NEVER_GET_RESOURCES) are set.

b. The system determines the number of communication channels in use, and checks whether the maximum quota has been exceeded.

c. If the quota has been exceeded (count>quota), no resources are returned, the reason TH_ARFC_RES_MAX_COMM_ENTRIES is set, and the return value 0 is set.

d. Otherwise, the resources are calculated afresh (and may be reduced) (new_resources = min(quota – count, resources )), and the reason TH_ARFC_RES_OK and the return value 0 are set.

5. Work processes check: is the user already occupying too many work processes (display in SM50)?

...

a. quota = (dia_wps * rdisp/rfc_max_own_used_wp) / 100 (only the whole number counts, numbers after the decimal point are ignored). If the quota is 0, the reason TH_ARFC_RES_LOW_OWN_USED_WP and the return value = 2 (NEVER_GET_RESOURCES) are set.

b. The system determines the number of communication channels in use, and checks whether the maximum quota has been exceeded.



c. If the quota has been exceeded (count>quota), no resources are returned, and the reason TH_ARFC_RES_OWN_USED_WP and the return value 0 are returned.

d. Otherwise, the resources are calculated afresh (and may be reduced) (new_resources=min(quota – count, resources)), and the reason TH_ARFC_RES_OK and the return value 0 are returned.

6. Dispatcher queue check (dispatcher dialog queue): because every RFC has an associated entry in the dialog queue, the system checks whether there is enough space in the dialog queue for new requests. (Display in SM51 → Goto → Server Information → Queue Information, profile parameter rdisp/elem_per_queue, default=2000). The latest queue information is then read.

...

a. If an error occurs, the reason TH_ARFC_RES_REQQUEUE_ERROR and the return value 2 are set. Otherwise que_max = maximum number of entries in the queue count = current number of entries in the queue

b. quota = (que_max * rdisp/rfc_max_queue) / 100 (only the whole number counts, numbers after the decimal point are ignored). If the quota is 0, the reason TH_ARFC_RES_LOW_REQQUEUE and the return value = 2 (NEVER_GET_RESOURCES) are set.

c. If the quota has been exceeded (count>quota), no resources are returned, and the reason TH_ARFC_RES_REQQUEUE and the return value 0 are returned.

7. Logon. As every RFC is linked to a logon in the target system, the system checks whether any further logons can be carried out (display in SM04, profile parameter rdisp/tm_max_no, default=200).

...

a. quota = (rdisp/tm_max_no * rdisp/rfc_max_login) / 100 (only the whole number counts, numbers after the decimal point are ignored). If the quota is 0, the reason TH_ARFC_RES_LOW_LOGIN and the return value = 2 (NEVER_GET_RESOURCES) are set. count = number of logons

b. If the quota has been exceeded (count>quota), no resources are returned, and the reason TH_ARFC_RES_LOGIN and the return value 0 are returned.

c. Otherwise, the resources are calculated afresh (and may be reduced) (new_resources=min(quota – count, resources)), and the reason TH_ARFC_RES_OK and the return value 0 are returned.

8. Own logons. As every RFC is linked to a logon in the target system, the system checks whether any further logons can be carried out. The amount of “own logons” is restricted (display in SM04, profile parameter rdisp/tm_max_no, default=200), so that any one user cannot log on to the system too many times.

...

a. quota = (rdisp/tm_max_no * rdisp/rfc_max_own_login) / 100 (only the whole number counts, numbers after the decimal point are ignored). If the quota is 0, the reason TH_ARFC_RES_LOW_OWN_LOGIN and the return value = 2 (NEVER_GET_RESOURCES) are set. count = number of logons

b. If the quota has been exceeded (count>quota), no resources are returned, and the reason TH_ARFC_RES_OWN_LOGIN and the return value 0 are returned. Otherwise, the resources are calculated afresh (and may be reduced).

9. Server status So that the server can process an RFC request, it must be ready for use. The normal status of the server is RUNNING. If the server has a different status, no resources are returned and the reason is set accordingly.

...



a. TH_ARFC_RES_SERVER_HIBERNATE: the server is deactivated (in SM51 or SMMS; this ensures that the server does not get any more requests – such as updates – from other servers).

b. TH_ARFC_RES_SERVER_SHUTDOWN: the server is being shut down.

c. TH_ARFC_RES_SERVER_STOP: the server was stopped after being shut down.

d. TH_ARFC_RES_SERVER_STARTING: the server is in the starting-up phase and is not yet operational.

e. TH_ARFC_RES_SERVER_INIT: the server is being initialized (before starting-up phase).

f. TH_ARFC_RES_SERVER_UNKNOWN: the server is in an unknown phase (should not happen).

Triggering the RFC Client Resource Check Use In transaction SM59 you can trigger from the server the resource check for an RFC destination. This delays the transmission of RFC calls.

Before the function module is executed the system checks whether the destination system has sufficient resources. If it hasn’t, the execution of the function module is delayed for a specified time.

The algorithm is the same as in the Detailed Check [page 20].

Prerequisites Note that this option is only available for destination systems as of Release 3.1H.

Procedure ...

1. In transaction SM59 select the required RFC destination and double-click on it. Then choose Destination → ARFC Options.

2. Choose Load Check Active.

You can select either a static or a dynamic check.

Static check after n calls: default is n=10. You can change this value.

After n asynchronous calls, the current system load of the remote system is evaluated.

Dynamic check: First of all the number of available resources for this destination is determined. If these resources are occupied by asynchronous calls, the next load check is carried out.

Result This check on the client system ensures that requests do not accumulate in the dispatcher queue on the RFC server.



Problems with RFC Resource Assignment You have set your parameters so that resource bottlenecks cannot arise and your application transmits only the RFC call types permitted. Yet you have realized that more work processes than allowed are occupied with RFC calls.

This can happen in the following circumstances:

An asynchronous RFC transmits a synchronous RFC The asynchronous RFC transmits one or more synchronous RFC calls in the destination system. The profile parameters are not valid for these calls.

This problem is due to an error in the kernel and can be fixed by a kernel patch. The attribute with makes parameters configurable is passed on from the first RFC (this must be the right type) to other RFC calls.

Work process is changed by roll-out/roll-in The asynchronous RFC occupies a work process in the destination system, but is rolled out because, for example, it contains the ABAP command COMMIT WORK or WAIT. If it is later rolled back in, the system does not check if the quotas have been exceeded.

This problem is due to an error in the kernel and can be fixed by a kernel patch. You can find out the patch number from the SAP Note 595032.

With the rdisp/rfc_check [page 13] parameter in the RFC server you can change the settings in the check for how many RFC work processes are available.

arfc_e- SAp ARFC and TRFC Monitoring Document

Documents