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:
Please, provide a valid admin page (see the wiki for details)
Enter the preview mode to see the content - a reminder that the admin page should be activated separately.
Available Monitoring Categories
The available monitoring categories are:
Please, provide a valid admin page (see the wiki for details)
Enter the preview mode to see the content - a reminder that the admin page should be activated separately.
Available Filter Options
qRFC
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:
Please, provide a valid admin page (see the wiki for details)
Enter the preview mode to see the content - a reminder that the admin page should be activated separately.
Available Metrics
For interfaces of type qRFC the following metrics are collected:
qRFC
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 |