terça-feira, 21 de fevereiro de 2017

IDoc_Configuration

Navigate back to the Setup for ...

Background Information

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.

Interface Channel Configuration

Available Monitoring Templates

The following templates are available to monitor IDoc processing on the managed system:
Monitoring Template
Description
IDoc (Real-time Monitoring)
This template provides metrics to monitor the processing of IDocs, to check whether IDocs in an erroneous or intermediate status exist on the managed system.
It is supposed to be run with high frequency, to monitor and alert on critical situations in time.
IDoc (Analysis)This template provides metrics to measure IDoc statistics on the managed system. It is not supposed to be executed with high frequency, but rather on a regular basis to check the health of the IDoc processing, and to provide input for reporting on IDocs in SAP Solution Manager.
The decision which monitoring template you want to set up is made during the creation of the interface channel.
In the case of IDoc channels you can change the template of the channel later on by clicking on the link for the template. But note that all metric selection will be reset during this selection.

System Requirements

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 the following additional authorizations on all managed systems:
    Authorization ObjectIDField
    S_IDOCDEFTEDI_TCDWE30
    ACTVT03
    S_CTS_ADMICTS_ADMFCTTABL

Monitoring Template “IDoc (Real-time Monitoring)”

Available Metrics

This monitoring template provides metrics to monitor IDoc errors and IDoc throughput.  
Metric Name
Description
MAI Category
Current number of erroneous IDocs (Real-time) (Delta)Number of erroneous IDocs since the last collector run.Exceptions
Current number of erroneous IDocs (Real-time) (Total)Number of erroneous IDocs for a specified timeframe (measured in hours).Exceptions
Current number of processed IDocs (Real-time) (Delta)Number of processed IDocs since the last collector run.Performance
Current number of processed IDocs (Real-time) (Total)Number of processed IDocs for a specified timeframe (measured in hours).Performance
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.

Configuration

Configuration on Interface Level
When setting up an IDoc channel you have two configuration levels. The first level is the configuration on interface level. Here you enter selection criteria to select the specific IDocs you want to monitor. These selection criteria can select the IDoc based on header data, but also on information in the data segments. The second level is the monitoring of the status codes for the selected IDocs.
On Interface level the parameters “Direction” and “IDoc Age (in hours)” are mandatory.
For the parameter "IDoc Age (in hours)" the collector will ignore values higher than 2 weeks = 336 hours.
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 button "Expert Mode" to display all available parameters.
The following fields are available to define which IDocs are considered:
Parameter
Description
Mandatory
Select-Option
F4 Help
Direction (Inbound / Outbound)
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!
X

X
Partner Port
Receiver Port or Sender Port e.g. FILEPORT

X
X
Partner Number
Receiver Partner Number or Sender Partner Number e.g. SIDCLNT110

X
X
Partner Type
Receiver Partner Type or Sender Partner Type e.g. LS

X
X
Partner Function
Receiver Partner Function or Sender Partner Function: e.g. Payer in SDOnly available if the managed system is an application system. 

X
   X1)
Message Type
e.g. ORDERS

X
X
Basic Type
IDoc Type, e.g. ORDERS05

X
X
Message Code
further separator besides Message Type, when you display the Header Data
of the IDoc in WE05 this field refers to the field "Message variant" 

X

Message Function
further separator besides Message Type

X

IDoc age (in hours)
Ignore IDocs which are older than x hours.
Caution: The collector will ignore values higher than 2 weeks = 336 hours!
X


Count Segment
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
e.g. E1EDK01-BELNR



Segment Field Value 1 (case-sensitive)
any field value that should be contained in the specified segment name

X

Segment Field Name 2
e.g. E1EDK01-BELNR



Segment Field Value 2 (case-sensitive)
any field value that should be contained in the specified segment name

X

Header Field Name 1
additional field from IDoc header table EDIDC, e.g. SNDLAD



Header Field Value 1
content of the additional IDoc header field

X

Header Field Name 2
additional field from IDoc header table EDIDC, e.g. SNDLAD



Header Field Value 2
content of the additional IDoc header field

X

Header Field Name 3
additional field from IDoc header table EDIDC, e.g. SNDLAD



Header Field Value 3
content of the additional IDoc header field

X
 
Additional Information
  • The input for parameters “Segment Field Name 1/2” has to be in 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.)
  • Parameters “Header Field Name 1/2/3” and “Header Field Value 1/2/3” 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 (like “Message Type” or “Partner Number”). Simply enter the name of the EDIDC field in parameter “Header Field Name” which you like to use for selecting the right IDocs, and the needed value in parameter “Header Field Value”. The data collector then dynamically selects the IDocs which match these additional selection criteria, too.
Configuration on Metric Level
Once you have set up the selection criteria for the IDocs you are interested in, you can select the key figures you are interested in.
For each metric you can maintain the following restrictions for the IDoc status segments:
Parameter
Description
Mandatory
Select-Option
F4 Help
Status Number(s)
IDoc Status you want to monitor, e.g. 51 for IDoc in error
X
X
X
Status Message Qualifier
This field identifies the origin of the messages which are transmitted in the status,
e.g. SAP messages are identified with SAP.

X

Status Message ID
Status Message ID, e.g. E0

X

Status Message Number
Status Message Number, e.g. 099

X

Minimum Status Age
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
e.g. 2 (This means, the IDoc has to be at least 2 times in status 51 before being alerted)



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 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.
Threshold Configuration
The thresholds and the data collection settings are maintained in the next step "Activation" of the IFMon setup. When setting up the thresholds please note that due to historic reasons not all threshold types are supported. The recommended rating strategies for IDoc metrics are “Info Only”, “Numeric Threshold (Green/Yellow/Red)” and “Range Threshold”. 
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 column “Period [min]” determines the frequency how often the measured value is evaluated, not how often the data collection actually runs.

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 IDoc errors that triggered the selected alert. Once in the function you can switch the the "Content View (Alerted IDocs)" which contains information on monitored segments.
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.
You can access the "Detail Info" list via the metric information in the alert details for the real-time monitoring alerts.
Once you have entered the detailed display, you can switch between the “Error View” and “Content View” using the corresponding push-buttons.
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 parameter “Field Value 1/2", 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 modes “Alerted IDocs” and “All IDocs”. 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.
  • Display IDocs (WE05): 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.
  • 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
    Important
    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.
  • Display Inbound Queue (WEINBQUEUE): 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.
  • 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 parameter "Count Segment" 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.
     

Monitoring Template “IDoc (Analysis)” 

Available Metrics

Besides standard monitoring and alerting the metrics of this template can also feed the reporting tools Business Process Analytics and BPO Dashboards.
Metric Name
Description
MAI Category
Total number of erroneous IDocs (Analysis)Number of erroneous IDocs created within a specified timeframe.Exceptions
Total number of processed IDocs (Analysis)Number of processed IDocs created within a specified timeframe.Performance
Average time to process IDocs (Analysis)Average time to process IDocs within a specified timeframe.Performance
Maximum time to process IDocs (Analysis)Maximum time to process IDocs within a specified timeframe.Performance
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
Current number of erroneous IDocs (Analysis)Number of erroneous IDocs created within a specified timeframe whose current IDoc status matches the customized values.Exceptions
Current number of processed IDocs (Analysis)Number of processed IDocs created within a specified timeframe whose current IDoc status matches the customized values.Performance
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

Configuration

Configuration on Interface Level
As for the real-time monitoring you have again two setup levels. On the interface level you set up the selection criteria to select the IDocs you are interested in.
The parameters "Direction" and "Selected Time Frame" are mandatory. Wildcards can be used in all select-option fields.
For some parameters you can select the "Group-by" flag (the checkbox next to the parameter input field). If this flag is set one metric variant will be created for each distinct parameter value.
The following fields are available to define which IDocs are considered:
Parameter
Description
Mandatory
Select-Option
F4 Help
Direction (Inbound / Outbound)
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!
X

X
Partner Port
Receiver Port or Sender Port, e.g. FILEPORT

X
X
Partner Number
Receiver Partner Number or Sender Partner Number, e.g. SIDCLNT110

X
X
Partner Type
Receiver Partner Type or Sender Partner Type, e.g. LS

X
X
Partner Function
Receiver Partner Function or Sender Partner Function, e.g. Payer in SD
Only available if the managed system is an application system.

X
X
Message Type
e.g. ORDERS

X
X
Basic Type
IDoc Type, e.g. ORDERS05

X
X
Message Code
further separator besides Message Type, when you display the Header Data
of the IDoc in WE05 this field refers to the field "Message variant" 

X

Message Function
further separator besides Message Type

X

Selected Time Frame
(see notes below): e.g. $TODAY-7
X


End of Time Frame
(see notes below): e.g.  $TODAY-1



Segment Field Name 1
e.g. E1EDK01-BELNR



Segment Field Value 1 (case-sensitive)
any field value that should be contained in the specified segment name

X

Segment Field Name 2
e.g. E1EDK01-BELNR



Segment Field Value 2 (case-sensitive)
any field value that should be contained in the specified segment name

X

Header Field Name 1
additional field from IDoc header table EDIDC, e.g. SNDLAD



Header Field Value 1
content of the additional IDoc header field

X

Header Field Name 2
additional field from IDoc header table EDIDC, e.g. SNDLAD



Header Field Value 2
content of the additional IDoc header field

X

Header Field Name 3
additional field from IDoc header table EDIDC, e.g. SNDLAD



Header Field Value 3
content of the additional IDoc header field

X

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 parameter “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.
For historic reasons parameter “Selected Time Frame” 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 "$" 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
$DELTA1)
Delta read (only IDocs created since last data collection)
No Offset allowed
1) Any offset for placeholder $DELTA is ignored, and you cannot use it with an entry in the "End of Time Frame" parameter. In delta mode, the data collector gets all IDocs which were created since the last data collection, up to the current time.

Examples
a)     Using parameter “Selected Time Frame” only:
  • $TIMEM-45 = previous 45 minutes (from now)
  • $TIMEH-10 = previous 10 hours (from now)
  • $TIMED-3 = previous 3 days (from now)
  • $HOURR-1 = full last hour
  • $TODAY-2 = previous 2 full calendar days
  • $FDOPW+1 = Tuesday of last week
b)    Using parameter “End of Time Frame” in addition:
  • Selected Time Frame = $TIMEH-10
  • End of Time Frame = $TIMEH-2
=> Only IDocs which were created between 10 hours and 2 hours ago are considered.
Note that the parameter combination must make sense. For example, a configuration like ($TIMEH-10) -> ($TIMEH-20) doesn't make sense, so the data collector will not find any IDocs.
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.
Configuration on Metric Level
The input parameters on metric level depend on the selected key figure.
For each of the key figures you can maintain additional filters on metric level.
The metrics of monitoring template “IDoc (Analysis)” provide several parameters which enable you to further filter the IDocs which have already been pre-selected based on their header data. Basic and mandatory information is the status number which you intend to monitor. For count and percentage metrics you can provide more than one status number using the select-options functionality. This enables you e.g. to monitor all IDocs which have been created in an erroneous inbound status (like status numbers 51, 56, 60, 65, 66) at the same time. The processing time metrics expect two single status numbers, the initial and the final status, between which the processing time is to be calculated.
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)
These metrics measure the number of IDocs created within a specified time frame. The IDocs to be taken into account are defined by the header information you maintain on interface level, and based on the status record details that can be maintained on metric level.
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 parameter “Status Number(s)”.
On metric level you have to provide at least mandatory parameter “Status Number(s)”. Wildcards can be used in all select-option fields.
Parameter
Description
Mandatory
Select-Option
F4 Help
Status Number(s)
Status number of the IDoc you want to filter for, e.g. 51 for IDoc Error
X
X
X
Status Message Qualifier
This field identifies the origin of the messages which are transmitted in the status.
E.g. SAP messages are identified with SAP.

X

Status Message ID
Status Message ID, e.g. E0

X

Status Message Number
Status Message Number, e.g. 099

X

Minimum Status Age1)
e.g. 10 minutes. Only IDocs are taken into account whose current status is older
than the time specified in this parameter (to avoid that IDocs are alerted too early).



Status Counter
e.g. 2 (This means, the IDoc has to be at least 2 times in status 51 before being alerted.)



Relevant Status Record
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 a default.


X
Minimum Processing Time (s)
e.g. 180 secs. 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



1) Only available for the “Current Number” metrics
Refer to section  Set up “IDoc (Analysis)” for Reporting Purposes  for a more detailed explanation on how the different metric parameters act together.
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. The IDocs to be taken into account are defined by the header information you maintain on managed object level, and based on the status record details that can be maintained on metric level.
On metric level you have to provide at least mandatory parameters “Initial Status Number” and “Final Status Number”. Wildcards can be used in all select-option fields.
Parameter
Description
Mandatory
Select-Option
F4 Help
Initial Status Number
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 
X

X
Final Status Number
The status number for which you want to end the measurement, e.g. 53 for Application 
Document posted
X

X
Final IDocs only?
Possible values are ‘X’ and ‘<blank>’. If set only those IDocs are evaluated which already
entered the “Final Status Number”


X
Status Message Qualifier
This field identifies the origin of the messages which are transmitted in the status.
E.g. SAP messages are identified with SAP.

X

Status Message ID
Status Message ID, e.g. E0

X

Status Message Number
Status Message Number, e.g. 099

X

Status Counter
e.g. 2 (This means, the IDoc has to be at least 2 times in status 51 before being alerted.) 


Relevant Status Record
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 a default.
 

X
Minimum Processing Time (s)1)
e.g. 180 secs. 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



1) Only available for metric “Average Time to Process IDocs”
Refer to section  Set up “IDoc (Analysis)” for Reporting Purposes  for a more detailed explanation on how the different metric parameters act together.
Additional Information
  • Initial/Final Status Number: It can be that the IDoc takes over one of the specified statuses several times. For example, if reprocessing takes place for erroneous IDocs, status 51 can be taken over several times. For calculating the processing time the timestamp of the status record which was created when the IDoc entered the specified status for the first time is used. 
  • It can be that, to the point in time of data collection, IDocs exist on the system which took over the “Initial Status Number”, but did not reach the “Final Status Number” yet. If you set the flag in parameter “Final IDocs Only?”, such IDocs will be ignored and hence do not contribute to the processing time calculation. If you do not set the flag, those IDocs are taken into account for the processing time calculation, too. Then, the time difference between an IDoc’s creation timestamp and the actual timestamp (the point in time of data collection) is used to calculate an IDoc’s (actual) 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):
Example
Example: You like to know how many IDocs are created in error statuses 51 or 56 yesterday. Assuming the numbers from yesterday are as follows:
  • 5 IDocs created running into status 51
  • 80 IDocs created running into status 53
  • 15 IDocs created running into status 56
For metric “Percentage of IDocs in total (Analysis)”, 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 metric “Percentage of Current IDocs (Analysis)” considers only those IDocs whose current status is one of the statuses as provided in parameter “Status Number(s)”.
On metric level you have to provide at least mandatory parameter “Status Number(s)”. Wildcards can be used in all select-option fields.
Parameter
Description
Mandatory
Select-Option
F4 Help
Status Number(s)
Status the IDoc must have to be considered, e.g. 51 for IDoc errors
X
X
X
Status Message Qualifier
This field identifies the origin of the messages which are transmitted in the status.
E.g. SAP messages are identified with SAP.

X

Status Message ID
Status Message ID, e.g. E0

X

Status Message Number
Status Message Number, e.g. 099

X

Minimum Status Age1)       
e.g. 10 minutes. Only IDocs are taken into account whose current status is older
than the time specified in this parameter (to avoid that IDocs are alerted too early).



Status Counter
e.g. 2 (This means, the IDoc has to be at least 2 times in status 51 before being alerted.)



Relevant Status Record
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 a default.


X
Minimum Processing Time (s)
e.g. 180 secs. 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



1) Only available for metric “Percentage of Current IDocs (Analysis)”
Refer to section Set up “IDoc (Analysis)” for Reporting Purposes for a more detailed explanation on how the different metric parameters act together.
Threshold Configuration
As for the real-time monitoring the thresholds are set in the step "Activation". Also here you should stick to the threshold types “Info Only”, “Numeric Threshold (Green/Yellow/Red)” and “Range Threshold”.

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 wiki 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
02Error passing data to port (e.g. port not available, file system not available etc.)
20Error triggering EDI subsystem (e.g. error during OS script processing)
26Syntax error (e.g. too many segments, wrong IDoc structure etc.)
29Error in ALE service (e.g. errors with field conversion etc.)
37IDoc 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
40Application 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
04Error within control information of EDI subsystem
05Error During Translation
07Error during syntax check
09Error during interchange handling
11Error during dispatch
15Interchange Acknowledgement negative
17Functional Acknowledgement negative
Backlog Monitoring
The following intermediate statuses should be considered for backlog monitoring.
For a backlog monitoring the parameter “Status Age” 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
03Data 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.)
30IDoc 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
39IDoc 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
51Application document not posted (application specific error situations)
Monitoring for Technical Errors
Status
Description
65Error in ALE service (e.g. errors with field conversion etc.)
60Syntax error (e.g. too many segments, wrong IDoc structure etc.)
56IDoc with errors added (e.g. Partner not found)
66IDoc 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 parameter “Status Age” needs to be considered.
Status
Description
64IDoc ready to be transferred to application (if immediately the alert should be triggered immediately, otherwise depending on the scheduling of the RBDAPP01)
75IDoc is in inbound queue (if sent via qRFC)

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.
Parameter "Status Counter"
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.
Parameter "Minimum Status Age"
For metrics “Current number of erroneous IDocs (Analysis)”, “Current number of processed IDocs (Analysis)” and “Percentage of current IDocs (Analysis)” 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.
Parameter "Minimum Processing Time"
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 “Minimum Processing Time” = 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 option “First status record with matching status” has been chosen.
In the following you can find some monitoring scenarios which illustrate the data collection logic for the status record search as explained in the section above.
Finding IDocs with certain functional Errors
For example 1 you like to check your delivery IDocs against functional errors for which you are responsible for.
Those failures are identified by the following status message settings:
  • Status Message Qualifier: SAP
  • Status Message ID: ME
  • Status Message Number: 777
Once the IDoc runs into such an error further matching status records are created at the same time which, however, does not reflect the initial error situation.
Thus you set the “Relevant Status Record” = “First status record with matching status”.
So only the first occurrence of all matching status records is checked against the settings in status message parameters, and hence will only find the IDocs relevant for you:
The following example 2 shows a similar use-case. Inbound order IDocs shall be monitored and alerted if they run into a functional error:


  • Status Message Qualifier: SAP 
  • Status Message ID: VG
  • Status Message Number: 204

In this case, each time such a functional error occurs, preceding status records with same status number are written which again are not of interest as they cannot be used to determine the responsible person to be notified about the IDoc failure. Thus, in this case the last matching status record shall be compared with the status message parameters, so parameter “Relevant Status Record” is set to option “Last (current) status record”.
Imagine the IDocs of above example 2 are subject to automatic reprocessing which might create further erroneous status records which are however not usable for identifying the underlying functional error. Thus you are always interested in only the third status message created:
In this case you can use the following settings in monitoring setup:
  • Status Message Qualifer: SAP
  • Status Message ID: VG
  • Status Message Number: 204
  • Status Counter: 3
  • Relevant Status Record: First status record with matching status considering Status Counter
This will always evaluate the third matching status record (which is known to be the relevant one) against the status message parameter settings.

Set up “IDoc (Analysis)” for Reporting Purposes

The monitoring template “IDoc (Analysis)” is able to feed the reporting tools Business Process Analytics and Business Process Operations Dashboards. For details regarding the setup and use of the two applications refer to the Business Process Improvement Wiki -> Technical Information -> Setup Guide - Business Process Analytics 7.1 SP5 + higher.pdf and Setup Guide - BP Operations Dashboards 7.1 SP5 - SP8 respectively.
One of the features these reporting tools offer is the display of data in an aggregated way. To facilitate this display the data collector is able to group the measured values by parameters "Partner Number", "Message Type", “Segment Field Value 1”, “Segment Field Value 2”, "Status", “Status Message ID”, and “Status Message Number”.
In order to activate this aggregation the "Group by" flag has to be set for each of the parameters in scope. You can either provide a set of entries you want the data collection to be restricted to (e.g. you are only interested in a small sub-set of partner numbers), or you can leave the corresponding fields blank which means all possible values found on the managed system will be included into the aggregation (e.g. aggregate all message types found for the specified IDoc interface).
If you want to group parameter "Status No." on metric level, you have to set the "Group by" flag and additionally enter a wildcard character into the select-options field. The aggregation for parameter “Status No.” can only be performed for the count and percentage metrics.

  • Status Message Qualifer: SAP
  • Status Message ID: ME
Status Message Number: 777
Fonte: https://wiki.scn.sap.com/wiki/display/TechOps/IDoc_Configuration