QRFC Queues Test

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

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.

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.

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.

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.

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.

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.

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.

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.