eG Monitoring
 

Measures reported by AsAbapQrfcTest

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)
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 AsAbapQrfcTest 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.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
qEntriesCount 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?.

noOfQueues 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.
noOfQBlocked 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.
noOfSYSFAILs 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.

noOfSYSLOADs 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.

noOfCPICERRs 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.
noOfWaitStatus 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 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.
noOfNoSendStatus 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.

longReadyQueues 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.

longRunningQueues 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.