Show TOC

 Set Up Monitoring of qRFC CallsLocate this document in the navigation structure


Queued RFC is a variant of the Remote Function Call that makes the data transfer between different systems more reliable and more secure; among other things, queued RFC guarantees chronological processing of RFC calls.

For monitoring tRFC and qRFC calls, there is the Transactional RFC and Queued RFC subtree in the Alert Monitor. For information about the structure of the subtree, see Transactional RFC and Queued RFC Monitor . This section describes how to set up the monitoring.

For optimal usage of qRFC, there are different queues for different applications, so that a blocked queue does not affect the other application processes. These queues are differentiated using their names; in this way, you can assign each queue to the associated application.

To provide a better overview, each of these queues that is being monitored using the monitoring architecture should be assigned a separate subtree. Without Customizing, all queue errors are reported in a single subtree. You can create the desired monitoring subtrees in Customizing. You can make the following changes:

  • You can create separate subtrees for specific queues. In this way, you can display the errors for queues whose names begin with CRM_SITES* in a separate tree. Error messages for these queues are then no longer displayed in the default subtree Queues Not Otherwise Monitored.
  • You can activate additional monitoring functions separately for each subtree using exit function modules. Function modules for checking the age of the queue (the age of the oldest call that is waiting for processing) and the number of calls waiting in a queue are already available to you.
  • You can change the color of the alerts that are reported to the monitoring architecture separately for each subtree. This can be done by assigning a queue status to an alert color or flexibly using function modules.

    Default Customizing settings are delivered for applications and components that use the qRFC monitoring data. This means that the associated subtrees should already be active after delivery. You only need to perform more far-reaching Customizing if the default Customizing does not meet your particular needs.

Process Flow
  1. Choose CCMS → Configuration → Alert Monitor, or call transaction RZ21.
  2. The system displays the Monitoring: Properties and Methods screen. Choose Technical Infrastructure → Configure qRFC monitoring.
  3. Confirm the warning that the table is cross-client.
  4. The system displays the Change Settings Owner: Overview screen. Changes to Customizing always belong to an owner. Originally, there is only the owner SAP here. Since you cannot make any changes to owners that begin with SAP, you must first create an owner for Customizing.
  5. Now select the settings owner for which you want to perform Customizing, and choose the Queue Groups level at the left edge in the Dialog Structure tree. The system displays the Change Queue Groups: Overview screen.
  6. On this screen, you specify which subtrees are to be created for inbound or outbound queues. These are the queue groups. Each queue group creates a subtree in the qRFC monitor (see Creating Queue Groups).
  7. You can assign one or more queues to each queue group. Select the desired queue group and double-click the Queue Assignments level on the left side in the Dialog Structure tree. The system displays the Change Queue Assignments screen (see Creating Queue Assignments).
  8. You can change the color of the alerts that are reported to the monitoring architecture separately for each subtree or queue. Select the desired queue group or queue assignment, and double-click the Alert Value Shifts level on the left side in the Dialog Structure tree. The system displays the Alert Value Shifts screen (see Creating Alert Value Shifts).
  9. Save your data.

Your Customizing changes become active the next time the data collection method CCMS_tRFC_Collector runs. By default, this method runs every 15 minutes.

  • You can only add subtrees for new queue groups using Customizing. If you delete queue groups, the associated subtrees in the monitoring architecture are simply no longer provided with data. The subtrees in the Alert Monitor are not automatically deleted. Delete the corresponding subtree in the Alert Monitor tree manually (see Deleting and Recreating Nodes in the Alert Monitoring Tree).
  • If you are making extensive changes, it can be easier to delete the complete Transactional RFC and Queued RFC monitor and to start again. You can force a rebuild by resetting the monitoring segment of the central server of your system (the server with the enqueue service) to WARMUP status.
  • You can restore the default settings by setting the Active field for the owner SAP to X.

More information:

SAP Note 441269