-
Technical Assistance
Request product support from SAP
-
Non-Technical Assistance
Request non-product support or provide feedback on SAP Support Portal site
Technical Assistance
Request product support from SAP
Non-Technical Assistance
Request non-product support or provide feedback on SAP Support Portal site
Via tRFC, data can be transferred safely and reliably between applications. The RFC client calls a specific function module on the RFC server. The called function module is executed exactly once on the server. The resulting data is then stored temporarily in the SAP database under a unique transaction ID (TID), that is, data creation and data transmission are two separate processes. The tRFC is used for example to send business documents from one SAP system to another SAP system, often by using the ALE/IDoc layer.
One or several functional module calls can be grouped into a single tRFC LUW (logical unit of work). Due to its asynchronous nature, the tRFC can handle situations where the called remote system is not available at the time of posting. In such a case a reprocessing is triggered by the tRFC framework.
The status of the transmission and processing can be monitored in the SAP system using transaction SM58. Errors can occur during communication and/or in the function module or the processing program.
The following technical prerequisites have to be met in order to use the tRFC monitoring:
On the managed system, use transaction SM58 to check whether there are tRFC entries present. Get an understanding what kind of tRFC calls exist in your system, based on function modules, user names, receiver destinations, and especially typical status codes that may appear in normal or error situations. This heavily depends on the used product, the implemented business processes, and of course on the interfaces to other systems and applications.
The metrics of this monitoring template monitor the tRFC entries (transactional remote function calls). It can be used for an automatic monitoring and alerting instead of the standard transaction SM58.
Metric Name | Description | MAI Category | Since SP |
---|---|---|---|
Number of tRFC entries in critical state |
Evaluates the number of specific tRFC entries in a critical state. |
Exceptions |
7.1 SP10 |
Age of oldest entry in critical state |
Evaluates the age of the oldest specific tRFC entry in a critical state. |
Exceptions |
7.1 SP10 |
Number of tRFC entries in critical state (combination with age)(1) |
Evaluates the number of specific tRFC entries in a critical state. Shares a common event with metric “Age of oldest entry in critical state (combination with number)”. |
Exceptions |
7.1 SP12 |
Age of oldest entry in critical state (combination with number)(1) |
Evaluates the age of the oldest specific tRFC entry in a critical state. Shares a common event with metric “Number of tRFC entries in critical state (combination with age)”. |
Exceptions |
7.1 SP12 |
Number of tRFC entries in interim state |
Evaluates the number of specific tRFC entries in an interim state. |
Performance |
7.1 SP10 |
Age of oldest entry in interim state |
Evaluates the age of the oldest of specific tRFC entries that are in an interim state. |
Performance |
7.1 SP10 |
Number of tRFC entries in interim state (combination with age)(1) |
Evaluates the number of specific tRFC entries in an interim state. Shares a common event with metric “Age of oldest entry in interim state (combination with number)” |
Performance |
7.1 SP12 |
Age of oldest entry in interim state (combination with number)(1) |
Evaluates the age of the oldest of specific tRFC entries that are in an interim state. Shares a common event with metric “Number of tRFC entries in interim state (combination with age)” |
Performance |
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 tRFC 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.
It is important that you select BOTH of the metrics in the metric configuration, otherwise they will not be correlated correctly. 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 in critical state (combination with number)” metric means that alerts are created based on the output of metric “Number of tRFC entries in critical state (combination with age)” solely.
The metrics are correlated by a best case rule. this means only if both metrics get a red rating the overall event rating will be red.
Use these metrics if you are not interested in just the pure number or the oldest individual entry, but in the age of the oldest entry in a critical/interim state if a certain number of entries in critical/interim state has been reached. This way, you can avoid being alerted about a single old entry and instead be only alerted if a more severe problem with tRFCs exists on the managed system. Similarly, you can also use these metrics to be alerted about the number of tRFC entries in critical/interim state only if the oldest of these entries has reached a certain age.
Please refer to SAP note 2010999 for more details on the migration from classical BPMon to MAI.
Key Figure | Alert | Metric |
---|---|---|
Combi of Entries & Age in critical state | Critical combination of high number & age of tRFC entries in critical state |
|
Combi of Entries & Age in interim state | Critical combination of high number & age of tRFC entries in interim state |
|
Severity | tRFC Status Code |
---|---|
Critical | ANORETRY, ARETRY, CPICERR, RETRY, SYSFAIL, VBERROR |
Interim | AFINISH, CONFAIL, DEBUG, EXECUTED, MAILED, READ, RECORDED, SENDED, SYSLOAD, VBRECORD, VXRECORD |
Note that the term “Critical” as used above indicates an immediate error state, with no automatic reprocessing, manual action is required. The term “Interim” indicates a temporary error or backlog situation only. Usually automatic reprocessing is in place.
The Interface and Connection Monitoring setup can be accessed via SAP Solution Manager Configuration (SOLMAN_SETUP).
To access the Integration Monitoring setup please 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.
Navigate to the step 'Define Scope'. 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:
Maintain the Interface:
Select Metrics:
On the tab 'Metrics' select the metrics you want to monitor. Please note that the selected metrics are collected for each tRFC destination entered above.
For status monitoring, you might not be interested in the number of entries in a critical or interim state, as you have to react anyway, no matter whether it is just one failed tRFC or several of them. So instead of monitoring “Number of entries” you can just monitor “Age of oldest entry in critical/interim state” with a very small threshold value.
Note: Please note that the interim states are not included in the monitoring of critical states. So you are advised to set up at least one metric for both critical and interim states, typically with different thresholds.
You can maintain attributes as described in the Interface and Connection Monitoring Setup with SAP Solution Manager 7.2 on the tab 'Attributes'.
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 step 'Activation'.
Maintain Thresholds and Schedule:
The status monitoring distinguishes between two severities. Several status codes are grouped in either critical or interim states. A critical state indicates an immediate error situation. An interim state means a temporary error or backlog situation, typically subject to automatic (re-)processing.
This grouping of severities has two advantages: You do not have to take care of monitoring individual status codes, and you can define individual sets of thresholds. Usually you should use smaller thresholds for critical states to get a timely alerting, and larger thresholds for interim states, to get alerted only when they persist for a longer time period.
List of status codes per severity:
Severity | tRFC Status Code |
---|---|
Critical |
ANORETRY |
Critical |
ARETRY |
Critical |
CPICERR |
Critical |
RETRY |
Critical |
SYSFAIL |
Critical |
VBERROR |
Interim |
AFINISH |
Interim |
CONFAIL |
Interim |
DEBUG |
Interim |
EXECUTED |
Interim |
MAILED |
Interim |
READ |
Interim |
RECORDED |
Interim |
SENDED |
Interim |
SYSLOAD |
Interim |
VBRECORD |
Interim |
VXRECORD |