QRFC Queues Test

All types of applications are instructed to communicate with other applications. This communication may take place within an SAP system, with another SAP system, or with an application from a remote external system. An interface that can be used for dealing with this task is the RemoteFunction Call (RFC).  RFCs can be used to start applications in remote systems, and to execute particular functions.

Whereas the first version of the RFC, the synchronous RFC, (sRFC) required both systems involved to be active in order to produce a synchronous communication, the subsequent generations of RFC had a greater range of features at their disposal (such as serialization, guarantee for one-time-only execution, and that the receiver system does not have to be available). These features were further enhanced through the queued RFC with inbound/outbound queue.  

qRFC performs a serialization of tRFC (Transactional RFC) using wait queues. While the actual sending process is done by the tRFC, inbound and outbound queues are added to the tRFC, thus resulting in a qRFC (queued Remote Function Call). The sender system is called the client system, while the target system corresponds to the server system.

In qRFC, the following communication scenarios are possible:

  • qRFC with outbound queue
  • qRFC with inbound queue (and outbound queue)

Figure 2.21 depicts both these communication scenarios:

As you can see, in a qRFC with an outbound queue, the sender system uses an outbound queue to serialize the data that is being sent. This means that function modules which depend on each other (such as update and then change) are put into the outbound queue of the sender system, and are guaranteed to be sent to the target system one after each other and one time only. The called system (server) has no knowledge of the outbound queue in the sender system (client), meaning that in this scenario, every SAP system can also communicate with a non-SAP system. (Note: the programming code of the server system must not be changed. However, it must be tRFC-capable.)

In the qRFC with inbound queue scenario on the other hand, for an outbound queue in the sender system (client), there is also an inbound queue in the target system (server). In other words, if a qRFC with inbound queue exists, it means that an outbound queue also exists in the sender system. This guarantees the sequence and efficiently controls the resources in the client system and server system. The inbound queue only processes as many function modules as the system resources in the target system (server) at that time allow. This prevents a server from being blocked by a client.

Two systems can engage in smooth, uninterrupted communication using qRFC only if the outbound and inbound queues operate in an error-free manner. To be able to promptly capture deficiencies in queue execution and rapidly isolate the reasons for the same, administrators should closely monitor the inbound and outbound qRFC queues. This can be achieved using the QRFC Queues test. For each type (inbound and outbound) of queue, this test reports the number of queues that are experiencing errors currently and the count of queues that took too long to complete. In the process, the test turns the spotlight on those queues that may be responsible for unexpected breaks or prolonged delays (if any) in inter-system communication, and also reveals what could be causing such queues to perform poorly.

Target of the test : A SAP ABAP instance

Agent deploying the test : An internal/remote agent

Outputs of the test : One set of results for every qRFC queue type on the server being monitored; an additional All descriptor is also supported, which aggregates metrics across queue types.

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed

Host

Host name of the server for which the test is to be configured.

PortNo

Enter the port to which the specified host listens.

ClientName

Specify the ID of the client system as what the eG agent will be connecting to the SAP ABAP instance. To know how to determine the client ID to use, follow the instructions provided in Determining the Client ID/Name for the eG Agent to Connect to the SAP ABAP Instance.

SAPUser

Typically, to connect to a SAP ABAP instance and run tests, the eG agent requires the permissions of a SAP user who has been assigned with certain authorization objects. Ideally, you will have to create a new user role on the SAP ABAP instance for this purpose, associate the above-mentioned authorization objects with that role, and assign the new role to an existing SAP user. The procedure for the same has been provided in Creating a New User Role for Monitoring and Assigning it to a SAP User. Once the new role is assigned to a SAP user, specify the name of this user against SAPUser.

Password

The password of the specified SAPUser.

Confirm Password

Confirm the password by retyping it here.

SysNo

This parameter appears only if the Use SAPControl flag is set to No – i.e., if the test uses SAPJCO to collect measures. An indicator of the TCP/IP port at which the SAP server listens. For example, for a server that listens at port 3200, the SysNo will be ‘00’. Similarly, if the SAP server port is 3201, the SysNo will have to be specified as ‘01’. Therefore, in the SysNo text box specify the system number of the SAP server with which the specified client communicates. To know the system number for the ABAP server being monitored, follow the procedure detailed in Identifying the SAP Router String and System Number.

Router

This parameter appears only if the Use SAPControl flag is set to No – i.e., if the test uses SAPJCO to collect measures. If the SAP client with the specified ClientName exists in a network external to the SAP server, then a router will be used to enable the server-client communication. In such a case, specify the router string of the router in the Router text box. If both the client and the server exist in the same network, then specify ‘none’ against the Router text box. To know what is the SAP Router string for the ABAP server being monitored, follow the procedure detailed in Identifying the SAP Router String and System Number.

InstanceName

This parameter appears only if the Use SAPControl flag is set to No – i.e., if the test uses SAPJCO to collect measures. This is set to none by default. This implies that the eG agent automatically discovers the instance name at run time. 

Timeout

Indicate the duration (in seconds) for which this test should wait for a response from the SAP ABAP instance. By default, this is set to 120 seconds.

JCO Version

The eG agent uses the SAP JCO library to connect to the SAP ABAP system and pull out metrics. To enable the eG agent to make this connection and query the metrics, you need to specify the version of the SAP JCO library that the agent needs to use. For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the ‘major version number’ alone against JCO Version – in the case of this example, this will be 2.x. Note that if you have downloaded the SAP JCO CONNECTOR files for SAP JCO version 3 from the SAP market place (as instructed by Downloading the SAP JCO Connector files Required for Monitoring), then the JCO Version configuration should be 3.x. 

LongReadyCutoff (HRS)

This test reports the Long ready state queues measure, which is the number of queues stuck in the Ready state for a long time. To report this measure, this test counts all queues that have been in the Ready state in excess of the duration (in hours) specified against LongReadyCutoff (HRS).

LongRunningcCutoff (HRS)

This test reports the Long running queues measure, which is the number of queues that have been running for a long time. To report this measure this test counts all queues that have been running for over a period of time (in hours) specified against LongRunningcCutoff (HRS).

DD Frequency

Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD Frequency.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise suite embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Number of queue entries

Indicates the number of queue entries for this queue type.

Number

Queue entries refer to the function modules that are sequentially arranged and placed in an inbound/outbound queue (as the case may be), for consumption by a target system.

A high value or a consistently increasing value for this measure therefore indicates that the inbound/outbound queue is long or is growing. This could imply an overload or a processing bottleneck at the sender/receiver system (as the case may be).  You can compare the value of this measure between inbound and outbound queues to understand where the bottleneck is – at the sender system or the target system? .   

Number of queues

Indicates the current number of queues of this queue type.

Number

The inbound queue scheduler and the outbound queue scheduler ensure that the corresponding queues (inbound and outbound) are processed in parallel. An increase in the number of queues impairs the performance of the scheduler, as it can no longer process the queues in parallel. Its hence best to limit the number of inbound/outbound queues.

Blocked queues

Indicates the current number of queues in blocked state.

Number

Ideally, the value of this measure should be 0. A non-zero value indicates that one/more inbound/outbound queues are blocked. qRFC queues can be blocked due to various reasons such as no free work processes (SYSLOAD), target system error (SYSFAIL), transmission error(CPICERR), explicit lock, dependent lock, debugging, waiting for update, LUW execution error, LUW data modification.

SYSFAIL queues

Indicates the current number of queues of this type in the  SYSFAIL error status.

Number

Ideally, the value of this measure should be 0. If this measure reports a non-zero value instead, it indicates that a serious error occurred when the first logical unit of work (LUW) of one/more queues was being executed. SYSFAIL errors interrupt execution of the LUW and generates short dumps on the target system.

To know which queues encountered SYSFAIL errors, use the detailed diagnosis of this measure.

SYSLOAD queues

Indicates the current number of queues of this type in the SYSLOAD error state.

Number

Ideally, the value of this measure should be 0. If this measure reports a non-zero value instead, it indicates that at the time of the qRFC call, no DIALOG work processes were free in the sending system. If these errors persist, the number of dialog work processes can be increased accordingly. 

To know which queues encountered SYSLOAD errors, use the detailed diagnosis of this measure.

CPICERR queues

Indicates the current number of queues of this type in the CPICERR error state.

Number

Ideally, the value of this measure should be 0. If this measure reports a non-zero value instead, it indicates that during transmission or processing of the first LUW of one/more queues, a network or communication error occurred. Status CPICERR may also exist in the following cases although no communication error occurred: A qRFC application finds out that a LUW cannot be processed any further due to a temporary error in the application and therefore calls the RESTART_OF_BACKGROUNDTASK function module to prompt the qRFC Manager to cancel the execution of this LUW and to repeat this LUW later. In this case, qRFC simulates a communication error with the text “Command to tRFC/qRFC: Execute LUW once again.” If this error occurs very often, you must contact the corresponding application.

To know which queues encountered the CPICERR errors, use the detailed diagnosis of this measure.

Waiting queues

Indicates the current number of queues of this type in the WAITING state.

Number

Ideally, the value of this measure should be 0. If this measure reports a non-zero value instead, it indicates that the first LUW of some queues has dependencies to other queues, and at least one of these queues currently still contains other LUWs with higher priorities. Queues can also go into waiting, if there are updates in the transaction and the queues have to wait until the update ends.

To know which queues are in the WAITING state currently, use the detailed diagnosis of this measure.

NoSend queues

Indicates the current number of queues of this type in the NOSEND state.

Number

If this measure reports a non-zero value, it indicates that the LUWs of some queues were never sent but retrieved by a special application. These queues are only used internally at SAP. Even if a LUW has been read by the corresponding application (BW, CRM), this status does not change. This LUW is only deleted from the queue if this application confirms collection (collective confirmation possible). Under no circumstances should this status be reset and the queue activated.

Use the detailed diagnosis of this measure to know which queues are NOSEND queues.

Long ready state queues

Indicates the number of queues that have been in the READY state for a long time.

Number

This measure reports the count of all queues that have been in the READY state for a period of time greater than the longreadycutoff (HRS) specification.

Typically, the READY state is a temporary state. If this state becomes permanent for a queue or is prolonged, it could be because that queue has been locked manually via a transaction/program and then unlocked without being activated at the same time. Under such circumstances, the queue must be activated explicitly.

Long running queues

Indicates the number of queues that have been running for a long time.

Number

This measure reports the count of all queues that have been in the RUNNING state for a period of time greater than the longrunningcutoff (HRS) specification.

If a queue hangs in the RUNNING state for more than 30 minutes, this may mean that the work process responsible for sending this LUW has been terminated. In this case, you can activate this queue again.

Note that activating a queue in status RUNNING may cause a LUW to be executed several times if this LUW is still being processed in the target system at that time. SAP therefore recommends a waiting time of at least 30 minutes before you reactivate the queue.