Contact Us

IDoc Channel

Scenario Overview

IDocs (Intermediate Documents) are standard containers for exchanging data between applications. Between SAP applications they are transferred using the ALE (Application Link Enabling) layer which again uses either tRFC or File technology as the underlying technique.

An IDoc contains different types of information. It contains the application data to be exchanged (e.g. a sales orders) as well as technical data providing information from where to where the IDoc is supposed to be sent. Furthermore, the IDoc also contains status information that shows which processing step within the data exchange the IDoc is currently in. These statuses can indicate error situations or success situations. Some of them can be intermediate statuses that are indicating backlog situations.

 

For an end-to-end ALE monitoring it is necessary to monitor the various IDoc statuses in the outbound as well as the inbound direction.

The IDoc monitoring functions in IF Monitoring enable you to restrict the monitoring to specific IDoc interfaces based on the IDoc's header and status information. The monitoring intends to report on errors and growing backlogs for these specific IDoc interfaces on the one hand (monitoring template  “IDoc (Real-time Monitoring)”), and to provide statistical data on the IDoc traffic like the throughput and the performance of IDoc processing on the other hand (monitoring template “IDoc (Analysis)”). If needed the monitoring can also be restricted to certain IDoc contents which enables you to increase the granularity of the monitoring even more.

Technical Prerequisites

Technical Prerequisites

The following technical prerequisites have to be met in order to use this template:

  • Basis release ≥ 7.00 on all managed systems
  • Current ST-A/PI is implemented on all managed systems

  • If you want to use the parameters filtering the IDocs based on their payload (IDoc data records) the system user that executes the data collection has to be assigned additional authorizations on all managed systems:

    • Check which user runs the background job: BPM_DATA_COLLECTION*

    • Add the following authorizations to this user:

Authorization Object ID Field
S_IDOCDEFT EDI_TCD WE30
ACTVT 03
S_CTS_ADMI CTS_ADMFCT TABL

Available Monitoring Content

Monitoring Template: IDoc (Real-time Monitoring)

This monitoring template provides metrics to monitor IDoc errors and IDoc throughput. 

Note: The metrics of this managed object can be used for monitoring and alerting. However, the data cannot be used as an input for Business Process Analytics and BPO Dashboards.

Metric Name Description MAI Category Since SP
Current number of erroneous IDocs (Real-time) (Delta) Number of erroneous IDocs since the last collector run. Exceptions 7.1 SP12
Current number of erroneous IDocs (Real-time) (Total) Number of erroneous IDocs for a specified timeframe (measured in hours). Exceptions 7.1 SP12
Current number of processed IDocs (Real-time) (Delta) Number of processed IDocs since the last collector run. Performance 7.1 SP12
Current number of processed IDocs (Real-time) (Total) Number of processed IDocs for a specified timeframe (measured in hours). Performance 7.1 SP12

Monitoring Template: IDoc (Analysis)

Metric Name Description MAI Category Since SP
Total number of erroneous IDocs (Analysis) Number of erroneous IDocs created within a specified timeframe. Exceptions 7.1 SP10
Total number of processed IDocs (Analysis) Number of processed IDocs created within a specified timeframe. Performance 7.1 SP12
Average time to process IDocs (Analysis) Average time to process IDocs within a specified timeframe. Performance 7.1 SP10
Maximum time to process IDocs (Analysis) Maximum time to process IDocs within a specified timeframe. Performance 7.1 SP12
Percentage of IDocs in total (Analysis) Number of matching IDocs compared against the total number of IDocs created within the same timeframe for the same interface. Performance 7.1 SP12
Current number of erroneous IDocs (Analysis) Number of erroneous IDocs created within a specified timeframe whose current IDoc status matches the customized values. Exceptions 7.1 SP12
Current number of processed IDocs (Analysis) Number of processed IDocs created within a specified timeframe whose current IDoc status matches the customized values. Performance 7.1 SP10
Percentage of current IDocs (Analysis) Number of matching IDocs whose current IDoc status matches the customized values compared against the total number of IDocs created within the same timeframe for the same interface. Performance 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 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.

Monitoring Template: IDoc (Real-time Monitoring)

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 IDoc
    • Monitoring Template: Select IDoc (Real-time Monitoring)
    • 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:

The information needed to maintain header information of the managed objects can be found either by viewing the control record of an example IDoc (BD87), in transaction WE20, WE05, or directly in table EDIDC. 

Wildcards can be used in all select-option fields. Click the Expert Mode button to display all available parameters.

  1. Select the interface channel you created.
  2. On the Interfaces tab, click the Add button.
  3. Provide the following information
    • Interface Name: The name of the interface

    • Direction (mandatory): Direction of the message flow from the perspective of the monitored system. If the direction is INBOUND fill in sender information for the parameters below. If the direction is OUTBOUND fill in receiver parameters below. This field is automatically filled based on the measuring point.

    • Partner Port: Receiver Port or Sender Port e.g. FILEPORT
    • Partner Number: Receiver Partner Number or Sender Partner Number e.g. SIDCLNT110
    • Partner Type (Expert field): Receiver Partner Type or Sender Partner Type e.g. LS
    • Partner Function (Expert field): Receiver Partner Function or Sender Partner Function: e.g. Payer in SD Only available if the managed system is an application system.
    • Message Type: Message type, e.g. ORDERS
    • Basic Type (Expert field): IDoc type, e.g. ORDERS05
    • Message Code (Expert field): Message variant of the IDoc
    • Message Function (Expert field): Message function of the IDoc
    • Max. IDoc age (hrs) (mandatory): Ignore IDocs which are older than x hours. Caution: The collector will ignore values higher than 2 weeks = 336 hours or zero.
    • Count Segment (Expert field): Count the number of all segments with this segment name, e.g. E1EDP01. Please note: You cannot set a threshold on this field and i.e. filter only for IDocs that have a certain segment. The information collected here is only used for the content view in the IDoc detail list.
    • Segment Field Name 1 (Expert field): e.g. E1EDK01-BELNR
    • Segment Field Value 1 (Expert field): any field value that should be contained in the specified segment name. Case sensitive.
    • Segment Field Name 2 (Expert field): e.g. E1EDK01-BELNR
    • Segment Field Value 2 (Expert field): any field value that should be contained in the specified segment name. Case sensitive.
    • Header Field Name 1 (Expert field): additional field from IDoc header table EDIDC, e.g. SNDLAD
    • Header Field Value 1 (Expert field): content of the additional IDoc header field
    • Header Field Name 2 (Expert field): additional field from IDoc header table EDIDC, e.g. SNDLAD
    • Header Field Value 2 (Expert field): content of the additional IDoc header field
    • Header Field Name 3 (Expert field): additional field from IDoc header table EDIDC, e.g. SNDLAD
    • Header Field Value 3 (Expert field): content of the additional IDoc header field

Note: Additional Information

  • The input for the Segment Field Name 1/2 parameters has to be in the format; <segment name>-<field name>. Qualified segment can be monitored, too; the format of the input must then be [segment name]{blank}[value of qualifier]-[field name], for example: 'E1EDKA1 AG-PARTN'.
  • Two use cases for the Segment Field Name / Segment Field Value parameters exist:
    • Specify a field name that should be monitored, as well as the respective field value: Only IDocs are alerted that contain at least once the specified field value in one of the specified segment fields.
    • Specify a field name that should be monitored, but leave the respective field value empty: The field name is only used for the detail display of alerts. That is, all field values which are contained in the specified segment field(s) of the alerted IDocs are listed in the detail display. (See chapter to Detail Info List for details.)
  • The Header Field Name 1/2/3 and Header Field Value 1/2/3 parameters enable you to separate the IDocs further by any IDoc header field as available in table EDIDC which is not yet contained in the standard set of parameters (such as Message Type or Partner Number). Enter the name of the EDIDC field in the Header Field Name parameter which you like to use for selecting the right IDocs, and the needed value in the Header Field Value parameter. The data collector then dynamically selects the IDocs which match these additional selection criteria, too.

Select Metrics:

  1. On the Metrics tab, select the metrics you want to monitor. Please note that the selected metrics are collected for each IDoc interface defined above.

  2. Enter Metric Parameters:

    • All metrics:

      • Parameter set name: You can enter a name for the parameter set to distinguish it if you have more than one.

      • Status Number(s) (mandatory):  IDoc Status you want to monitor, e.g. 51 for IDoc in error.

      • Status Message Qualifier (Expert field): This field identifies the origin of the messages which are transmitted in the status, e.g. SAP messages are identified with SAP.

      • Status Message ID (Expert field): Status Message ID, e.g. E0.

      • Status Message Number (Expert field): Status Message Number, e.g. 099.

      • Status Message (Expert field): Combination of Status Message ID and Status Message Number.

      • Min. Status Age (Expert field): Defines the time an IDoc has to be in a certain status to be considered. "Minimum Status Age" needs to be specified in minutes.

      • Status Counter (Expert field): The number of times an IDoc has to have a certain status before being considered in the data collection.

For best practices on which statuses to use for which metric, refer to the Further Information section → Setup Best-Practice for Monitoring Template IDoc (Real-time Monitoring) below. 

Note: Additional Information

  • Minimum Status Age: Sometimes the status should be at least x minutes old before taking this IDoc into account. Default is 0 minutes. An example is if you want to monitor the IDoc backlog. Then you would monitor of intermediate statuses each IDoc goes through. If an IDoc is in an intermediate status for a short period of time, then this is not a problem. However, if an IDoc is in an intermediate status for en extended period of time, this could indicate a bottleneck or a backlog e.g. due to problems in the underlying infrastructure.
  • Status Counter: If an IDoc runs into an erroneous status, it might be reprocessed automatically. If the cause for the error still exists, the IDoc will encounter this status again. With this parameter, you can adjust the number of times the IDoc can take the specified status(es) before it will be alerted.
  • The parameters “Status Age” and “Status Counter” are logically linked with OR. This means, only one of the parameters needs to be exceeded to take the IDoc into account for alerting.
  • Status Message ID / Status Message Number: Note that those two parameters are logically linked with OR. This means, if you provide multiple values for both parameters, all combinations of the parameter values will be built. For example, if you provide Message ID = VG and = VA, and Message Number = 205 and = 206, all IDocs with status messages VA205, VA206, VG205, and VG206 are returned by the data collector. In case you want to exclude values you even have to be more careful. For example, if you provide Message ID <> VG and Message No. <> 205 , this will return all IDocs, independent from their status message, because either statement will be true: Message ID <> VG OR Message No. <> 205. To overcome this problem it's recommended to use parameter "Status Message" instead. Here you can provide the full combination of Message ID and Message No (which actually identifies the status message to be monitored), for example VG205. You can provide multiple values, or exclude values, like <> VG205 and <> VA206 at the same time. Parameters Message ID and Message No. are only intended to be used for simple configurations, for example, include a single status message (Message ID = VG, Message No. = 205), or, for example, if you want to filter all status messages which belong to the same message ID, independent of the status number.

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 IDoc metrics are Info Only, Numeric Threshold (Green/Yellow/Red) and Range Threshold. 
    • 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.
    • The monitoring works only if the data collection is executed in the background. Thus it is essential to keep the default setting for the Collection mode, which is asynchronous. Running in Background mode enables the data collector to read IDoc tables which can become very large. Dialog processing of the data collection would impact the performance of the managed system too much. Be aware that the Period [min] column determines the frequency how often the measured value is evaluated, not how often the data collection actually runs.
  3. Click Apply and Activate → <Choose one option> to activate the monitoring.

Monitoring Template: IDoc (Analysis)

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 IDoc
    • Monitoring Template: Select IDoc (Analysis)
    • 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 please select External Service if it is a cloud service or Unspecified Managed Object.
  8. 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:

The information needed to maintain header information of the managed objects can be found either by viewing the control record of an example IDoc (BD87), in transaction WE20, WE05, or directly in table EDIDC. 

Wildcards can be used in all select-option fields. Click the Expert Mode button to display all available parameters.

For some parameters you can select the Group-by flag (the check-box next to the parameter input field). If this flag is set one metric variant will be created for each distinct parameter value.

  1. Select the interface channel you created.
  2. On the Interfaces tab click the Add button.
  3. Provide the following information
    • Interface Name: The name of the interface

    • Direction (mandatory): Direction of the message flow from the perspective of the monitored system. If the direction is INBOUND fill in sender information for the parameters below. If the direction is OUTBOUND fill in receiver parameters below. This field is automatically filled based on the measuring point.

    • Partner Port: Receiver Port or Sender Port e.g. FILEPORT
    • Partner Number: Receiver Partner Number or Sender Partner Number e.g. SIDCLNT110
    • Partner Type (Expert field): Receiver Partner Type or Sender Partner Type e.g. LS
    • Partner Function (Expert field): Receiver Partner Function or Sender Partner Function: e.g. Payer in SD Only available if the managed system is an application system.
    • Message Type: Message type, e.g. ORDERS
    • Basic Type (Expert field): IDoc type, e.g. ORDERS05
    • Message Code (Expert field): Message variant of the IDoc
    • Message Function (Expert field): Message function of the IDoc
    • Selected Time Frame (mandatory): TD = Today, YD = Yesterday, or a calculated value that acts like the from value for the IDoc timeframe, like $TODAY-7. For more information see notes below.

    • End of Time Frame (Expert Field): A calculated value that acts like the "to" value for the IDoc timeframe. For more information see notes below.

    • Segment Field Name 1 (Expert field): e.g. E1EDK01-BELNR
    • Segment Field Value 1 (Expert field): any field value that should be contained in the specified segment name. Case sensitive.
    • Segment Field Name 2 (Expert field): e.g. E1EDK01-BELNR
    • Segment Field Value 2 (Expert field): any field value that should be contained in the specified segment name. Case sensitive.
    • Header Field Name 1 (Expert field): additional field from IDoc header table EDIDC, e.g. SNDLAD
    • Header Field Value 1 (Expert field): content of the additional IDoc header field
    • Header Field Name 2 (Expert field): additional field from IDoc header table EDIDC, e.g. SNDLAD
    • Header Field Value 2 (Expert field): content of the additional IDoc header field
    • Header Field Name 3 (Expert field): additional field from IDoc header table EDIDC, e.g. SNDLAD
    • Header Field Value 3 (Expert field): content of the additional IDoc header field

Note: Additional Information

The selection parameters; Selected Time Frame and End of Time Frame, define the time window for which IDocs should be evaluated on the managed system. As a minimum input, Selected Time Frame has to be filled which sets the maximum age for the IDocs. Optionally you can provide an input for End of Time Frame, which sets the minimum age of the IDocs. If you leave this parameter blank all IDocs up to the point of data collection are evaluated. The Selected Day parameter can be filled with values TD (to monitor the whole current day) or YD (to monitor the whole day yesterday).

For historic reasons, the Selected Time Frame parameter can be filled with values TD (to monitor the whole current day) or YD (to monitor the whole day yesterday). Apart it is possible to monitor dynamic time ranges. The parameter has to be maintained in the following way:

Syntax = {Placeholder}{Operator}{Offset}

The {Placeholder} has to be prefixed by a dollar sign ($). The optional {Offset} is entered as an integer value after the {Operator}. For {Operator}, you can choose the following signs:

"-": decrements the offset

"+": increments the offset

For the placeholder, the following keywords are available:

Placeholder Description Unit of Offset

$TIMEM

Timestamp now

Minutes

$TIMEH

Timestamp now

Hours

$TIMED

Timestamp now

Days

$HOURR

Current full hour

Hours

$TODAY

Current day

Days

$FDOCW

First day of current week

Days

$LDOCW

Last day of current week

Days

$FDOPW

First day of previous week

Days

$LDOPW

Last day of previous week

Days

$DELTA(1)

Delta read (only IDocs created since last data collection)

No Offset allowed

(1) Any offset for placeholder $DELTA is ignored. In delta mode, the data collector gets all IDocs which were created since the last data collection, up to the current time.

 

Note: Performance Warning

The dynamic time frame logic can technically select a long time frame (such as the last 180 days), but such selection conditions may severely impair the performance of the managed system, and even cause the data collector to dump. Select the timeframe carefully. You should run the data collector regularly (for example daily, for the previous day) rather than less often for a longer time frame. Longer time frames can be viewed in the BW reporting tools.

Select Metrics:

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

    • The processing time metrics expect two single status numbers, the initial and the final status, between which the processing time is to be calculated.
       

  2. Enter Metric Parameters:

    • Metrics: Total number of erroneous IDocs (Analysis), Total number of processed IDocs (Analysis), Current number of erroneous IDocs (Analysis), Current number of processed IDocs (Analysis):

      • For the Total Number metrics, an IDoc contributes to the measured value as soon as it took over one of the specified statuses at least once during its processing. This means, the current status of the IDoc does not necessarily has to be one of the specified statuses; all status records are considered. In contrast, the Current Number metrics counts only those IDocs whose current status is one of the statuses as provided in the Status Number(s) parameter.

      • Parameter set name: You can enter a name for the parameter set to distinguish it if you have more than one.

      • Status Number(s) (mandatory):  IDoc Status you want to monitor, e.g. 51 for IDoc in error. You can provide more than one status number here.

      • Status Message Qualifier (Expert field): This field identifies the origin of the messages which are transmitted in the status, e.g. SAP messages are identified with SAP .

      • Status Message ID (Expert field): Status Message ID, e.g. E0.

      • Status Message Number (Expert field): Status Message Number, e.g. 099.

      • Min. Status Age (Expert field): Defines the time an IDoc has to be in a certain status to be considered. The Minimum Status Age needs to be specified in minutes. Only available for current number metrics.

      • Status Counter (Expert field): The number of times an IDoc has to have a certain status before being considered in the data collection.

      • Relevant Status Rec. (Expert field): Rules against which status record the status message parameters are compared. Possible values are First, Last, and Match Status Parameter set. If no value is maintained the data collector uses value Last as the default.

      • Min. Proc. Time (s) (Expert field): If set, an IDoc is only taken into account if the time difference between IDoc creation time and the creation time of the relevant IDoc status exceeds the Minimum Processing Time.

    • Metrics Average Time to Process IDocs (Analysis) and Maximum Time to Process IDocs (Analysis):

      • These metrics measure the IDoc's processing time between two status numbers (initial and final status) and return either the average processing time for all IDocs, or the maximum time it took to process one of the IDocs out of the subset of all matching IDocs. For calculating the processing time the time-stamp of the status record which was created when the IDoc entered the specified status for the first time is used. 

      • Parameter set name: You can enter a name for the parameter set to distinguish it if you have more than one.

      • Initial Status Number (mandatory): Initial status number from which you want to start the measurement, e.g. 50 for IDoc added, or 51 to measure the TTR for IDoc Errors.

      • Final Status Number (mandatory): The status number for which you want to end the measurement, e.g. 53 for Application Document posted.

      • Final IDocs only?: Possible values are X and ' '. If set, only those IDocs are evaluated which already entered the Final Status Number.

      • Status Message Qualifier (Expert field): This field identifies the origin of the messages which are transmitted in the status, e.g. SAP messages are identified with SAP.

      • Status Message ID (Expert field): Status Message ID, e.g. E0.

      • Status Message Number (Expert field): Status Message Number, e.g. 099.

      • Status Counter (Expert field): The number of times an IDoc has to have a certain status before being considered in the data collection.

      • Relevant Status Rec. (Expert field): Rules against which status record the status message parameters are compared. Possible values are First, Last, and Match Status Parameter set. If no value is maintained the data collector uses value Las” as the default.

      • Min. Proc. Time (s) (Expert field for Avg. Time to Process IDocs): If set, an IDoc is only taken into account if the time difference between IDoc creation time and the creation time of the relevant IDoc status exceeds the Minimum Processing Time.

    • Metrics Percentage of IDocs in total (Analysis) and Percentage of Current IDocs (Analysis):

      • These metrics calculate the percentage of IDocs created in a specified status within a given time frame. In order to calculate the percentage, the number of matching IDocs (having one of the specified status(es)) is compared against the number of all IDocs created the same day in the same interface (i.e all IDocs which have the same IDoc header criteria)

      • For the Percentage of IDocs in total (Analysis) metric, an IDoc contributes to the measured value as soon as it took over one of the specified statuses at least once during its processing. This means, the current status of the IDoc does not necessarily have to be one of the specified statuses; all status records are considered. In contrast, the Percentage of Current IDocs (Analysis) metric considers only those IDocs whose current status is one of the statuses as provided in the Status Number(s) parameter.

      • Parameter set name: You can enter a name for the parameter set to distinguish it if you have more than one.

      • Status Number(s) (mandatory): IDoc Status you want to monitor, e.g. 51 for IDoc in error. You can provide more than one status number here.

      • Status Message Qualifier (Expert field): This field identifies the origin of the messages which are transmitted in the status, e.g. SAP messages are identified with SAP.

      • Status Message ID (Expert field): Status Message ID, e.g. E0.

      • Status Message Number (Expert field): Status Message Number, e.g. 099.

      • Min. Status Age (Expert field for Percentage of Current IDocs): Defines the time an IDoc has to be in a certain status to be considered. Minimum Status Age needs to be specified in minutes. Only available for current number metrics.

      • Status Counter (Expert field): The number of times an IDoc has to have a certain status before being considered in the data collection.

      • Relevant Status Rec. (Expert field): Rules against which status record the status message parameters are compared. Possible values are First, Last, and Match Status Parameter set. If no value is maintained the data collector uses value Last as the default.

      • Min. Proc. Time (s) (Expert field): If set, an IDoc is only taken into account if the time difference between IDoc creation time and the creation time of the relevant IDoc status exceeds the Minimum Processing Time.

Refer to the Further Information section →  Set up “IDoc (Analysis)” for Reporting Purposes  for a more detailed explanation on how the different metric parameters act together.  

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. The recommended rating strategies for IDoc metrics are Info Only, Numeric Threshold (Green/Yellow/Red) and Range Threshold. 
    • 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.
    • The monitoring works only if the data collection is executed in background. Thus it is essential to keep the default setting for the Collection Mode, which is asynchronous. Running in background mode enables the data collector to read IDoc tables which can become very large. Dialog processing of the data collection would impact the performance of the managed system too much. Be aware that the Period [min] column determines the frequency how often the measured value is evaluated, not how often the data collection actually runs.
  3. Click Apply and Activate → <Choose one option> to activate the monitoring

Further Information

Setup Best-Practice for Monitoring Template “IDoc (Real-time Monitoring)”

The monitor checks the status record of the selected IDocs and counts the number of IDocs that meet the selection criteria and are in the respective status. Depending on the key figure different statuses could be interesting. In the graphic in the beginning of this page all status in RED are real error status, while the status in YELLOW are intermediate status. An IDoc usually passes these intermediate statuses in its lifetime, so this doesn't mean a problem, however a very high or growing number of IDocs in intermediate status can indicate a backlog (e.g. a problem on ALE level).

We have two different types of key figures for exceptions and performance, Delta number and Total number monitors.

  • Delta number monitors only take IDocs into account that are new in this the monitored status since the last collector run. The Current number of erroneous IDocs (Real-time) (Delta) monitor should be used for error monitoring as it will alert on each new error since the last collector run, but not alert on the same error twice.
  • Total number monitors take all IDocs in a certain status into account up to the maximum IDoc age. The Current number of erroneous IDocs (Real-time) (Total) monitor should be used to detect a growing number of IDocs in an intermediate state, to detect if there is a backlog building up in the system.

Which statuses should be monitored depends very much on your individual ALE scenario and your past experience with IDoc processing.

In the following we will highlight statuses that are considered as being critical and are recommended to be monitored. Additionally it is recommended to check for errors or backlog situations in the past and include those into the monitoring concept, if necessary.

Outbound IDoc Monitoring

Error Monitoring

The following statuses are considered error statuses and should be monitored for error monitoring.

Status Description
02 Error passing data to port (e.g. port not available, file system not available etc.)
20 Error triggering EDI subsystem (e.g. error during OS script processing)
26 Syntax error (e.g. too many segments, wrong IDoc structure etc.)
29 Error in ALE service (e.g. errors with field conversion etc.)
37 IDoc added incorrectly

If ALE-Audit is used also the status 40 should be monitored representing application errors. The status is the status on the receiver system.

Status Description
40 Application document not posted (application specific error situations)

If converters (e.g. Seeburger, SAP Business Connector etc.) are used, the following statuses are relevant for technical error monitoring.

Status Description
04 Error within control information of EDI subsystem
05 Error During Translation
07 Error during syntax check
09 Error during interchange handling
11 Error during dispatch
15 Interchange Acknowledgement negative
17 Functional Acknowledgement negative

Backlog Monitoring

The following intermediate statuses should be considered for backlog monitoring.

For a backlog monitoring the Status Age parameter needs to be considered. In some ALE scenarios the IDocs will be processed immediately and in other scenarios the IDocs are gathered and processed by background jobs (e.g. every 60 minutes). Therefore, it makes sense to set the parameter for status age to e.g. 60 minutes in order to avoid being alerted because of an intermediate backlog situation.

Status Description
03 Data passed to port OK (Only if report RBDMOIND is running too many IDocs in status 03 indicate a backlog, as the report switches the status 03 to status 12! Otherwise 03 can be a final status.)
30 IDoc ready for dispatch (if immediately the alert should be triggered immediately, otherwise depending on the scheduling of the RSEOUT00)

If ALE-Audit is used also the status 39 on the receiver system should be monitored.

Status Description
39 IDoc ready to be transferred to application (if immediately the alert should be triggered immediately, otherwise depending on the scheduling of the RBDAPP01 report)

Inbound IDoc Monitoring

Error Monitoring

The following statuses are considered error statuses and should be monitored for error monitoring.

Monitoring for Application Errors

Status Description
51 Application document not posted (application specific error situations)

Monitoring for Technical Errors

Status Description
65 Error in ALE service (e.g. errors with field conversion etc.)
60 Syntax error (e.g. too many segments, wrong IDoc structure etc.)
56 IDoc with errors added (e.g. Partner not found)
66 IDoc is waiting for predecessor IDoc (serialization) [with buffer time on status]

Backlog Monitoring

The following intermediate statuses should be considered for backlog monitoring.

For a backlog monitoring the Status Age parameter needs to be considered.

Status Description
64 IDoc ready to be transferred to application (if immediately the alert should be triggered immediately, otherwise depending on the scheduling of the RBDAPP01)
75 IDoc is in inbound queue (if sent via qRFC)

Using the Detail Info List

In case of an IDoc alert it is desirable to have direct access to these IDocs without having to search for them in the managed system via WE05 or BD87. For this purpose the Detail Info view was developed also for IDocs.

The Detail Info function allows you to display IDoc details in different views. Error View (Alerted IDocs) is displayed by default when you first call this function. As the name indicates, this view contains information about all IDocerrors that triggered the selected alert. Once in the function you can switch to Content View (Alerted IDocs) which contains information on monitored segments.

 

Authorizations for Detail Info

To open the Detail Info list in the managed system, make sure you have the authorizations described in SAP Note 1875650 - Authorization check for accessing "Detail Info". 

 

You can access the Detail Info list by using the alert details for the real-time monitoring alerts.

Access Detail Info:

  1. Select alert in the alert inbox and open the alert details.
  2. Select the row with the metric you want to open in the alert details section.
  3. The link is located in the metric description for each metric.

Once you have entered the detail info, you can switch between the Error View and Content View using the corresponding buttons in the UI.

Both views show specific IDoc properties. The following columns remain the same in both views:

  • IDoc number
  • Message Type
  • Current Status Number
  • Status Group (traffic light grouping)
  • Age of last status change: This column displays the time since the IDoc resides in its current status.
  • Error Resolution Time: This time indicates how long it took to put the IDoc into an uncritical status after it has entered a critical status for the first time. The typical use-case would be that you monitor failed IDocs (like IDoc status 51), and you like to be informed on the time it took to resolve the error, this means, to put the IDoc to successful status 53. In a more general context, the terms “critical status” and “uncritical status” refer to the status numbers you have configured. Each status number which is part of the monitoring setup is regarded as a “critical status” (although you might monitor successfully created IDocs), and each status number which is not part of the configuration is regarded as “uncritical”. If, after entering a critical status for the first time, the IDoc is not processed any further, the point in time you call the detail info is used to calculate the Error Resolution Time.

Error View

The Error View displays the following additional IDoc properties:

  • Status Message Text of displayed status
  • Status Message Number of displayed status
  • Status Message ID of displayed status

Content View

The Content View provides information about selected IDoc contents:

  • Count Segment: <segment name> (as specified in the Count Segment parameter during monitoring configuration): displays the number of specified segments per IDoc
  • Values of Field: <segment name> - <field name> (as specified in the Field Name 1/2 parameter during monitoring configuration): Content of these fields within the IDoc (either as specified in the Field Value 1/2 parameter or all field values)

Additional Information

  • If you only want to view the field content of a single IDoc, select the relevant row in the Error View and choose Content View.
  • The specific columns of the Content View are only filled if the relevant parameters were configured. Otherwise the column names are marked correspondingly (e.g. Count Segment: not specified)
  • In case you specified any field content parameters in the setup tool, but the corresponding segment fields could not be found in the IDoc a generic info message is written into the table fields (e.g. Specified segment could not be found).

You can also choose between the Alerted IDocs and All IDocs modes using the corresponding button.

As previously stated, Alerted IDocs lists all IDocs that triggered the alert from which you called the detailed display (provided that the IDoc Age has not yet been exceeded; see above). The current status of these IDocs is displayed so that you can see whether the problem still exists or whether it was solved between when the alert was raised and the detail display was called.

Example

An alert was raised at 8 a.m. for IDocs with status 51. You call the detailed display at 9 a.m. Within this hour, a batch job was triggered that reprocessed these failed IDocs successfully. This means that these IDocs are displayed with final status 53 and it is clear that no further action is required.

If you switch to All IDocs, the database is searched for all IDocs that currently meet your selection criteria. This means IDocs that were reprocessed successfully between when the alert was raised and the detailed display was called are no longer displayed (because they no longer fulfill the IDoc status selection criterion). All IDocs that meet the selection criteria but were created after the alert was raised are displayed in addition. This enables you to immediately deal with IDoc errors for which alerts have not yet been triggered in the Alert Inbox.

Additional Push-buttons

In order to display more detailed information on the alerted IDocs and also to enable error handling, several additional functionalities can be accessed from the detail display functionality.

  • Button WE05 - Display IDocs: Select one or more IDocs (by highlighting the relevant rows) that are to be displayed in standard monitoring transaction WE05. This function is also offered for single IDocs when you double-click the IDoc row.
  • Button Reprocess - Reprocess IDocs: Select one or more IDocs (by highlighting the relevant rows) that are to be reprocessed immediately and choose the push-button to start reprocessing. This will trigger report RBDPROCESS which is the standard tool for IDoc reprocessing

Reprocessing of IDocs should only be executed when the underlying error of the IDoc failure is corrected. You can reprocess IDocs only if your user has assigned the appropriate authorizations, and if the IDoc is not in a final (green) status. The result of the IDoc reprocessing is displayed afterwards.

  • Button WEINBQUEUE -  Display Inbound Queue: For inbound IDocs which are processed in a serialized manner via qRFC, the IDocs might get stuck during queue processing, residing in status 75. For such IDocs you can display the corresponding inbound qRFC queue to which the IDoc belongs to, and search for the reason the inbound queue is being blocked.
  • Button Start Queue - Start Inbound Queue: By pushing this button you can start a blocked inbound qRFC queue using the standard report RSEINBQUEUE_PARTNER. This action can only be performed for IDocs in status 75. Be aware that the root cause for the blocked queue has to be resolved first (e.g. another IDoc might block the queue which has to be corrected first), otherwise the restart of the queue does not affect anything.
  • Refresh Display: Refreshes the current display and updates the current status of the IDoc, the status age and the error resolution time.
  • IDoc Statistics: This info box provides a brief summary of the IDocs currently displayed (depending on the mode Alerted IDocs or All IDocs):
    • Number of alerted / all IDocs
    • Number of Segments (only visible in case the Count Segment parameter was configured)
    • Age of oldest IDoc
    • Age of newest IDoc
    • Distinct Message Types with occurrence (the five message types that occur most frequently)
    • Distinct Receiver Partners with occurrence (the five receiver partners that occur most frequently)
    • Distinct Sender Partners with occurrence (the five sender partners that occur most frequently) 
  • Monitoring Configuration: This info box displays the complete configuration for the parameter set for which you called the detail info.

IDoc Buffering Period

All IDocs that trigger alerts are stored in a buffer table on the managed system so that they can be displayed later. However, buffering is restricted based on the IDoc Age parameter (see above). The buffering time is calculated as follows:

  • IDocs  are stored for at least two days after being created but are not stored for more than 14 days.
  • If you entered an  IDoc  age of between two and seven days, the time for which the IDocs are stored in the buffer table is doubled.

Examples:

  • If you set the IDoc Age parameter to two hours, IDocs are buffered for 48 hours.
  • If you set the IDoc Age parameter to 72 hours, IDocs are buffered for 144 hours (six days).
  • If you set the IDoc Age parameter to 240 hours (ten days), IDocs are buffered for 336 hours (14 days).

If you call the detailed display after the buffering time has passed, the display is either called with no IDocs listed at all, or it contains only some of the IDocs for the alert selected. Still you can always trigger a live data collection with the All IDocs button (see below) in order to get any IDocs that currently match the selection criteria but have not been alerted yet. 

 

How to Work with IDoc (Analysis) Parameters on Metric Level

This section contains additional information on the behavior of the parameters on metric level for the IDoc Analysis. You will also find some example monitoring scenarios here.

Status Counter Parameter

If you are interested in monitoring not the first occurrence of a certain status number (e.g. as the IDoc might be subject to automated reprocessing in failure case), you can set the Status Counter parameter to a finite value. Then, only IDocs are alerted which fulfill this additional condition.

Caution: For the count and percentage metrics only the lowest status number maintained will be taken into account for this additional check. For the processing time metrics the status counter check is only applied to the status number maintained as the final status.

Minimum Status Age Parameter

For the Current number of erroneous IDocs (Analysis), Current number of processed IDocs (Analysis) and Percentage of current IDocs (Analysis) metrics, it is also possible to provide a Minimum Status Age in minutes. If this parameter is set, the creation time-stamp of the current status is checked against the settings in this parameter. Only if the current status resides longer in this status than specified in Minimum Status Age, the IDoc is taken into consideration.

This way you avoid to be alerted too early on a certain critical situation. For example, if you like to monitor intermediate statuses, you might be interested only in IDocs which do not leave this intermediate status as expected, but remain in this status too long.

Minimum Processing Time Parameter

The Minimum Processing Time parameter enables you to restrict the data collection only to long-running IDocs, which took more time to reach the Final Status Number since their creation than specified in the Minimum Processing Time parameter.

Example

For example, you like to count the number of long-running IDocs in status 53.

Imagine IDocs on your system normally reach this status 53 in average 20 seconds after they have been created. Thus you like to count only the number of IDocs which exceed this average processing time. By setting the Minimum Processing Time to 20, the data collector ignores all IDocs which reached status 53 faster than these 20 seconds. In the example below, only IDoc 2049998 would be taken into account, but not 2050000: 

 


Parameters for the IDoc Content

The following further parameters are available aiming at the content of the IDoc status message:

  • Status Message Qualifier
  • Status Message ID
  • Status Message Number
  • Relevant Status Record

The first three parameters can be used to filter the IDocs by a certain status message (e.g. if you only want to be alerted for a specific application-related error the IDoc runs into). The Relevant Status Record parameter enables you to define which of the matching status records are to be queried against the status message parameters. Three options exist:

  • First status record with matching status: The first status record (in chronological order) which matches the IDoc header conditions and has the right status number is checked against the status message parameters.
  • Last (current) status record: The last status record (in chronological order) which matches the IDoc header conditions and has the right status number is checked against the status message parameters.
  • First status record with matching status considering Status Counter: This option takes into account the settings of the Status Counter parameter. This means, if the Status Counter parameter is set to a finite value, the data collector checks the status message of the first relevant status record which fulfills the status counter condition. For example, if you have set Status Counter to value 2, then the second matching status record within the IDoc's status record chronology is checked whether it fulfills the status message parameter conditions. Note: if you use this option but leave the Status Counter parameter blank, then the data collector behaves as if the First status record with matching status value has been chosen.