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.
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).
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 technical prerequisites have to be met in order to use the qRFC Monitoring:
To be able to monitor interfaces of an on-premise system you first have to add it to Interface & Cloud Monitoring and select the monitoring categories you want to monitor for the system.
In the next step, you see all monitoring categories which are available for the system, depending on the system type and the installed software components. Some recommended standard monitoring categories are preselected.
Select the monitoring categories in scope.
Available Monitoring Categories
The available monitoring categories are:
After selecting your monitoring categories you have to maintain filters to define what exactly you want to monitor. Some monitoring categories come with standard filters that usually just select all items of this monitoring category. Focused Run can handle this high amount of monitoring data, so you can stick to this standard filters. Or you can set up filters of your own. You can create more than one filter for a monitoring category.
Available Filter Options
For qRFC Monitoring, you can collect all qRFC entries in the managed system. You can also use the following filter parameters, to restrict the data collection:
The setup of the filters for the monitoring categories only makes sure that the data is collected, however, alerts are not created automatically. To create alerts and notifications you have to create an alert individually. If you didn't use specific filters in the setup before, but rather opted to collect all data, you have to create filters for the alerts.
In the next sub-step, you have to maintain the filter. The filter values are the same as described above. For some metrics, you have to maintain metric parameters. Find details below in the overview of the available metrics.
In the last sub-step you have to activate the alert:
For single exceptions, the threshold type is always 'Already Rated'. This means depending on the calculation frequency the number of exceptions is checked and an alert is created if this number is bigger than 0. If you want to reduce the number of alert for these metrics, you could increase the value for the calculation frequency to increase the time between checks.
For interfaces of type qRFC the following metrics are collected:
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|
||ARETRY, CPICERR, MODIFY, NOEXEC, RETRY, RUNNING, STOP, WAITING, WAITSTOP|