qRFC Channel

Using a qRFC, data can be exchanged between two application components in multiple queues on a first-in-first-out basis (FIFO) for the function modules. Several applications can place function modules in the same queues. The function modules can be processed on the receiving system in the order defined by the applications in the sending system. The number of queues used is defined by the applications.

The following communication model shows what communication scenarios may look like in reality. The actual sending process is still executed by the tRFC (transactional Remote Function Call). Inbound and outbound queues are added to the tRFC, leaving us with a qRFC (queued Remote Function Call). The sender system is also called the client system, while the target system corresponds to the server system. In practice, the following three scenarios for data transfer with qRFC and tRFC exist:


Scenario 1: tRFC This scenario is appropriate if the data being sent is independent of each other. A calling application (or client) in system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario data is transferred by tRFC, meaning that each function module call sent to the target system is guaranteed to be executed only once. You can neither define the sequence in which the function module calls are executed nor the time of execution. If an error occurs during the transfer, a batch job is scheduled which sends the function module call again after 15 minutes.

Scenario 2: qRFC with outbound queue In this scenario, the sender system uses an outbound queue to serialize the data that is being sent. This means that function module calls 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. The programming code of the server system does not have to be changed. However, it must be tRFC-capable.

Scenario 3: qRFC with inbound queue (and outbound queue)  In this scenario, an outbound queue in the sender system (client) is used in parallel to an inbound queue in the target system (server). If a qRFC with inbound queue exists, this always means that an outbound queue 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 module calls as the system resources in the target system (server) at that time allow.

Although qRFCs are serialized tRFC LUWs, you cannot maintain or display these LUWs using the tRFC administration transaction SM58. You have to use the qRFC queue administration transaction SMQ1 for outbound queues and SMQ2 for inbound queues. The following functions are available:

  • List queues
  • Display queues with a list of accompanying LUWs and function modules including input data
  • Start/stop transmitting the queues
  • Delete queues or queue entries

Technical Prerequisites

The following technical prerequisites have to be met in order to use the qRFC Monitoring:

  • Managed system is ABAP-based SAP system of Basis release ≥ 7.00
  • Add-on ST-A/PI (minimum release 01R) implemented on the managed system

Available Monitoring Content

The qRFC monitoring allows monitoring the qRFC processing and its individual queues for status and backlog. This way you can be notified if the number of queue entries is higher than expected, the age of the oldest entry of the queue is too high, as well as the combinations. 

Monitoring Template: qRFC

This template contains metrics for the real-time monitoring of exception and performance of qRFC inbound and outbound queues. 

The following metrics have been available since add-on ST-A/PI 01K:

Metric Name Description MAI Category Since SP

Number of individual qRFC queues

This metric measures the number of individual queues within the specified queue group. This means that the number of queues with the same name prefix that have at least one entry at the time of the data collection is measured.

Performance

 SM 7.1 SP12

Total number entries in all queues

This metric measures the total number of all entries in all queues that belong to the monitored queue group at the time of the data collection.

Performance

 SM 7.1 SP12 

Average number of entries per queue

This metric measures the average number of entries in all queues that belong to the monitored queue group at the time of the data collection. In order to determine the measured value for this metric, the "Total number entries in all queues" is divided by the "Number of individual qRFC queues". The average number (as shown in the alert text) has two decimals. However, for the measured value it is rounded to an integer number. This integer number is basis for the alert determination.

Performance

 SM 7.1 SP12

Maximum number of entries per queue

This metric measures the number of entries in the largest queue of the monitored queue group.

Performance

 SM 7.1 SP12

Age of oldest entry

This metric measures the age (in minutes) of the oldest entry within any of the queues of the monitored queue group.

Performance

 SM 7.1 SP12

Total number entries in all queues (combination with oldest entry)(1)

Total number of entries in all queues with specific prefix in queue name. Shares a common event with metric “Age of oldest entry (combination with total number)”

Performance

 SM 7.1 SP12

Age of oldest entry (combination with total number)(1)

Age (in minutes) of oldest entry in all queues with specific prefix in queue name. Shares a common event with metric “Total number entries in all queues (combination with oldest entry)”

Performance

 SM 7.1 SP12

Number of qRFC entries with critical status in group

Number of queues with critical state in a queue group.

Exceptions

 SM 7.1 SP10

Age of oldest critical status in group

Age (in minutes) of oldest critical state queue with specific prefix in queue name

Exceptions

 SM 7.1 SP10

Number of qRFC entries with critical status in group (combination with Age)(1)

Number of queues with critical state with specific prefix in queue name. Shares a common event with metric “Age of oldest critical status in group (combination with Number)”

Exceptions

 SM 7.1 SP12

Age of oldest critical status in group (combination with Number)(1)

Age (in minutes) of oldest critical state queue with specific prefix in queue name. Shares a common event with metric “Number of qRFC entries with critical status in group (combination with Age)”

Exceptions

 SM 7.1 SP12

Number of entries with interim status in group

Number of queues with interim state with specific prefix in queue name

Performance

 SM 7.1 SP10

Age of oldest interim status in group

Age (in minutes) of oldest interim state queue with specific prefix in queue name

Performance

 SM 7.1 SP10

Number of entries with interim status in group (combination with Age)(1)

Number of queues with interim state with specific prefix in queue name. Shares a common event with metric “Age of oldest interim status in group (combination with Number)”

Performance

 SM 7.1 SP12

Age of oldest interim status in group (combination with Number)(1)

Age (in minutes) of oldest interim state queue with specific prefix in queue name. Shares a common event with metric “Number of entries with interim status in group (combination with Age)”

Performance

 SM 7.1 SP12

Number of AppLog Errors (qRFC)

This metric calculates the number of application log errors which are related to qRFC processing

Exceptions

 SM 7.1 SP12

Note: Key figures with combined rating strategy (number & age)

(1) In classic BPMon you had the possibility to use key figures that had a combined rating for number of entries and age of entries for critical and interim state. For example you could create an alert only when you had a certain number of qRFC entries in critical state AND when these entries where older than a defined age.

To model this behavior in ICMon these key figures are presented by two metrics that are correlated on alert level.

From a functional point of view these metrics behave in the same way as the single metrics. However, they share a common event, which means an alert is only raised if both metrics exceed their threshold values. If you do not configure one of the metrics the system behaves as if only the single metric has been configured. E.g. not configuring the “Age of oldest entry (combination with total number)” metric means that alerts are created based on the output of metric “Total number entries in all queues (combination with oldest entry)” solely.

Use these metrics if you are not just interested in the pure number of queue entries or the oldest individual entry, but in the age of the oldest queue entry if a certain number of queue entries has been reached. This way, you can avoid being alerted about a single old queue entry and instead be only alerted if a more severe problem with the RFC queues exists on the system. Similarly, you can also use these metrics to be alerted about the number of queue entries only if the oldest of these entries has reached a certain age.

The following table shows the grouping of the metrics:

Key Figure Alert Metrics
BL: Combi of Total entries & Oldest age Critical combination of high number & oldest entry (qRFC)
  • Age of oldest entry (combination with total number)
  • Total number entries in all queues (combination with oldest entry)

ST: Combi Queues & Age in critical state

 Critical combination of qRFC entries & oldest age in error state
  • Age of oldest critical status in group (combination with Number)
  • Number of qRFC entries with critical status in group (combination with Age)
ST: Combi Queues & Age in interim state Critical combination of qRFC entries & oldest age in interim status
  • Age of oldest interim status in group (combination with Number)
  • Number of entries with interim status in group (combination with Age)

Monitoring Template: qRFC Reporting

This template contains metrics for the reporting of the qRFC throughput for inbound and outbound queues. 

Metric Name Description MAI Category Since SP
qRFC Throughput Inbound This metric is used to measure the throughput of qRFC inbound processing. It is not meant for creating alerts, but just feeds the data into reporting for the usage in dashboards. Performance SM 7.1 SP12
qRFC Throughput Outbound This metric is used to measure the throughput of qRFC outbound processing. It is not meant for creating alerts, but just feeds the data into reporting for the usage in dashboards. Performance SM 7.1 SP12

Configuration

The Interface and Connection Monitoring setup can be accessed via SAP Solution Manager Configuration (SOLMAN_SETUP). 

To access the Integration Monitoring setup, go to SAP Solution Manager Configuration (SOLMAN_SETUP) → Application Operations → Integration Monitoring → Interface and Connections.

Note: If you didn't perform the infrastructure configuration yet, please follow the Interface and Connection Monitoring Setup with SAP Solution Manager 7.2.

Monitoring Template: qRFC

Navigate to the Define Scope step. You can create a new scenario or use an existing one. Make sure the sender and the receiver system are part of the Interface and Connection Monitoring scenario.

Create the Interface Channel:

  1. Select the scenario and click Next.
  2. In the Preparation step, perform all relevant manual activities and run all automatic activities.
  3. In the Configuration step, click the Add button.
    • Channel Name: Enter a meaning full name (max. 30 characters)
    • Type: Select qRFC
    • Monitoring Template: Select qRFC
    • Description: Enter a description for the channel
  4. Click Next.
  5. Source Type:
    • Select Technical System
    • If the source system is not on-premise, select External Service if it is a cloud service or Unspecified Managed Object.
  6. Source: Select the source system from the drop-down list or enter the name for the unspecified managed object
  7. Target Type:
    • Select Technical System
    • If the target system is not on-premise, select External Service if it is a cloud service or Unspecified Managed Object.
  8. Target: Select the target system from the drop-down list or enter the name for the unspecified managed object.
  9. The measuring point is selected automatically. Note that for this template either the target or the source system must be an ABAP system. If both source and target are ABAP systems you can select the measuring point as necessary.
  10. If more than one client are connected for the on premise system please select the correct client for the monitoring.
  11. Click Next.
  12. Click Finish.

Maintain the Interface:

  1. Select the interface channel you created.
  2. On Interfaces the tab click the Add button.
  3. Provide the following information
    • Interface Name: The name of the interface
    • qRFC direction (mandatory): restricts the selection on either an inbound or outbound qRFC. This parameter is mandatory and only the values I (for inbound) and O (for outbound) are allowed.
    • RFC destination: The RFC destination parameter is mandatory for outbound qRFCs, it is not relevant for inbound qRFCs (just leave empty). You can use wildcard '*' to include all destinations, or use the wildcard to define a destination group, for example ‘M50CLNT*'. Wildcards in any other place than the last character are not supported and ignored. The value help returns all RFC destinations of connection types 3, I or L (ABAP, Internal or Logical).
    • Queue Group (mandatory): defines a prefix to combine all single queues with the same prefix into a queue group. The value help shows typical queue groups for CRM, SCM and PI as examples. You can enter a different group name; but need to make sure that the chosen queue group exists in the monitored system, as otherwise the measured values for the metric will be zero. Wildcards in any other place than the last character are not supported and ignored.
    • Status for Critical: You can overwrite the standard statuses considered for critical.
    • Status for Interim: You can overwrite the standard statuses considered for interim.
    • Status for Backlog: You can define which statuses should be considered to determine the number of queues in backlog status.
    • Activate Delta Mode: With this switch you can define that only status changes since the last data collection. should be considered. X or ' '. 

Obsolete Parameters: Command SMD Backlog Collector and Command SMD Status Collector.

In older ST-A/PI release (earlier than 01R) there was a so-called SMD integration. The data collector was able to collect the metrics from certain function modules developed for Solution Manager Diagnostics (SMD). These function modules read the qRFC tables data and wrote this information into the ST-A/PI cluster table, from where the data was evaluated by the data collector. The data collector read the stored results, parsed the metric strings, and returned the measured values to SAP Solution Manager. As of ST-A/PI release 01R this integration has been discontinued. This means that the data collector always does its own raw data selection in the RFC database tables, comparable with the old option DIRECT-SELECT', which no longer needs to be explicitly specified.

Select Metrics:

  1. On the Metrics tab, select the metrics you want to monitor. Note that the selected metrics are collected for each interface entered above.

  2. Enter Metric Parameters:

    • Metric: Number of AppLog Errors (RFC)
      • Parameter set name: You can enter a name for the parameter set to distinguish it if you have more than one.
      • Technical System (mandatory): The technical system in which the application log is written.
      • Object name (mandatory): The object name for the application log entry.
      • Sub-object name (mandatory): The sub-object for the application log entry.
      • User name: Name of the user who caused the logged event.
      • External ID (Expert field): External ID for the application log entry.
      • Message ID (Expert field): Message ID for the application log entry.
      • Message no. (Expert field): Message number for the application log entry.
      • Message text (Expert field): Message text for the application log entry.
      • Program (Expert field): Name of the program which caused the logged event.
      • Transaction code (Expert field): Name of the transaction which caused the logged event.

Usually it is not necessary to include all these metrics.

  • Backlog Monitoring - For backlog monitoring, it can be sufficient to just use the Total number entries in all queues metric, if you do not care whether all the entries are in many small queues or in a few large queues. Or, if you are just interested in having all entries processed within a certain time frame (regardless of how many entries occur), it is good enough to use Age of oldest entry.
  • Status Monitoring - For status monitoring, you might also not be interested in the number of erroneous states, as you have to react anyway, no matter whether it is just one failed queue or several of them. So instead of Number of entries, you can just monitor Age of oldest critical/interim status with a small threshold value.

You can maintain attributes as described in the Interface and Connection Monitoring Setup with SAP Solution Manager 7.2 on the Attributes tab.

Thresholds and the collection schedule are maintained in the next step of the guided procedure. Once you have maintained all your channels, click Next in the main guided procedure to move to the Activation step.

Maintain Thresholds and Schedule:

  1. Select the Alert for the channel (the alert is the line with the red flash icon next to it).
    • On alert level you can maintain notification and incident message creation.
  2. Select the Metrics
    • You can adjust the thresholds on the Thresholds tab. The recommended rating strategies for this metric are Info Only and Numeric Threshold (Green/Yellow/Red).
    • Do not change the data collector type or data collector name on the Data Collection tab as the monitor will not work anymore if this is changed.
    • Only change the collection interval if you know what you do or if advised to do this by SAP.
  3. Click Apply and Activate → <Choose one option> to activate the monitoring

Monitoring Template: qRFC Reporting

Navigate to the Define Scope step. You can create a new scenario or use an existing one. Make sure the sender and the receiver system are part of the Interface and Connection Monitoring scenario.

Create the Interface Channel:

  1. Select the scenario and click Next.
  2. In the Preparation step, perform all relevant manual activities and run all automatic activities.
  3. In the Configuration step, click the Add button.
    • Channel Name: Enter a meaning full name (max. 30 characters)
    • Type: Select qRFC
    • Monitoring Template: Select qRFC Reporting
    • Description: Enter a description for the channel
  4. Click Next.
  5. Source type:
    • Select Technical System
    • If the source system is not on-premise, select External Service if it is a cloud service or Unspecified Managed Object.
  6. Source: Select the on premise system from the drop-down list.
  7. Target Type:
    • Select Technical System
    • If the target system is not on-premise, select External Service if it is a cloud service or Unspecified Managed Object.
  8. Target: Select the on system from the drop-down list or enter the name for the unspecified managed object.
  9. The measuring point is selected automatically. Note that for this template either the target or the source system must be an ABAP system. If both source and target are ABAP systems you can select the measuring point as necessary.
  10. If more than one client are connected for the on premise system please select the correct client for the monitoring.
  11. Click Next.
  12. Click Finish.

This interface can only be created between an ABAP system and any other system. You need an ABAP system in this channel because this is where the data collector is running.

Maintain the Interface:

  1. The interface channel type does not have any configurable parameters on interface level. Move directly to the metric configuration.

Select Metrics:

  1. On the Metrics tab, select the metrics you want to monitor. Note that the selected metrics are collected for each interface entered above.

  2. Enter Metric Parameters:

    • Parameter set name: You can enter a name for the parameter set to distinguish it if you have more than one.
    • Queue name prefixes: defines a prefix to combine all single queues with the same prefix into a queue group. The value help shows typical queue groups for CRM, SCM and PI as examples. You can enter a different group name; but need to make sure that the chosen queue group exists in the monitored system, as otherwise the measured values for the metric will be zero.
    • Group-by-flag: If set, metric variants will be created per distinct parameter value. 

You can maintain attributes as described in the Interface and Connection Monitoring Setup on the Attributes tab.

Thresholds and the collection schedule are maintained in the next step of the guided procedure. Once you have maintained all your channels, click Next in the main guided procedure to move to the Activation step.

Maintain Thresholds and Schedule:

  1. Select the Alert for the channel (the alert is the line with the red flash icon next to it).
    • On alert level you can maintain notification and incident message creation.
  2. Select the Metrics
    • You can adjust the thresholds on the Thresholds tab. This metric is not intended to create alerts but for the reporting on the qRFC throughput. Consider leaving the threshold as Info Only.
    • Do not change the data collector type or data collector name on the Data Collection tab as the monitor will not work anymore if this is changed.
    • Only change the collection interval if you know what you do or if advised to do this by SAP.
  3. Click Apply and Activate → <Choose one option> to activate the monitoring 

Further Information

qRFC Status Codes

The following status codes are taken into account for error and interim statuses:

Direction Severity qRFC Status Code
Outbound Critical ANORETRY, SYSFAIL, VBERROR
Interim ARTRY, CPICERR, EXECUTED, MODIFY, NOSENDS, RETRY, RUNNING, STOP, SYSLOAD, WAITING, WAITSTOP, WAITUPDA
Inbound Critical ANORETRY, SYSFAIL
Interim ARETRY, CPICERR, MODIFY, NOEXEC, RETRY, RUNNING, STOP, WAITING, WAITSTOP