Idoc Wait Monitor Test
Idocs are structured ASCII files (or a virtual equivalent). They are the file format used by SAP ABAP to exchange data with foreign systems. Idocs is the acronym for Interchange Document. This indicates a set of (electronic) information which builds a logical entity. An IDoc is e.g. all the data of a single customer in your customer master data file, or the IDoc is all the data of a single invoice.
An SAP ABAP application creates data and updates the database appropriately. An application can be a transaction, a stand-alone ABAP Report or any tool that can update a database within SAP ABAP. If the application thinks that data needs to be distributed to a foreign system, it triggers the IDoc outbound routine, usually by leaving a descriptive message record in the message table NAST. The application then either directly calls the IDoc engine or a collector job eventually picks up all due IDoc messages and determines what to do with them. If the engine believes that data is ready to be sent to a partner system, then it determines the function module which can collect and wrap the required IDoc data into an IDoc. In IDoc customising, you specify the name of the function module to use. This can either be one which is predefined by ABAP standard or a user-written one. When the IDoc is created it is stored in an SAP ABAP table and from there it is sent to the foreign system.
IDoc inbound routines, on the other hand, are function modules with a standard interface, which will interpret the received IDoc data and prepare it for processing. The received IDoc data is processed record by record and interpreted according to the segment information provided with each record. The prepared data can then be processed by an application, a function module, or a self-written program.
Any slowdown noticed in electronic data exchange between the SAP ABAP system and foreign systems therefore, can be attributed to bottlenecks or errors in the transmission/reception of Idocs. Administrators should hence closely monitor inbound and outbound IDoc traffic to proactively detect probable slowdowns in inter-system communications, and accurately tell where the slowdown occurred and why, so that the communication bottlenecks can be promptly cleared. This is where the IDoc wait monitor test helps.
This test monitors the inbound and outbound Idocs generated during the past hour and reports the rate at which these Idocs were processed at various stages of transmission/reception, thus accurately pointing to processing slowdowns and where exactly the processing was bottlenecked. In addition, the test also reports the number of Idocs that were found to be erroneous every second and the exact stage of transmission/reception at which the rate of errors peaked!
Target of the test : A SAP ABAP Instance
Agent deploying the test : An internal/remote agent
Outputs of the test : One set of results for every SAP ABAP instance being monitored
Parameter | Description |
Test Period |
How often should the test be executed |
Host |
Host name of the server for which the test is to be configured. |
PortNo |
Enter the port to which the specified host listens. |
ClientName |
Specify the ID of the client system as what the eG agent will be connecting to the SAP ABAP instance. To know how to determine the client ID to use, follow the instructions provided in Determining the Client ID/Name for the eG Agent to Connect to the SAP ABAP Instance. |
SAPUser |
Typically, to connect to a SAP ABAP instance and run tests, the eG agent requires the permissions of a SAP user who has been assigned |
Password |
The password of the specified SAPUser. |
Confirm Password |
Confirm the password by retyping it here. |
SysNo |
This parameter appears only if the Use SAPControl flag is set to No – i.e., if the test uses SAPJCO to collect measures. An indicator of the TCP/IP port at which the SAP server listens. For example, for a server that listens at port 3200, the SysNo will be ‘00’. Similarly, if the SAP server port is 3201, the SysNo will have to be specified as ‘01’. Therefore, in the SysNo text box specify the system number of the SAP server with which the specified client communicates. To know the system number for the ABAP server being monitored, follow the procedure detailed in Identifying the SAP Router String and System Number. |
Router |
This parameter appears only if the Use SAPControl flag is set to No – i.e., if the test uses SAPJCO to collect measures. If the SAP client with the specified ClientName exists in a network external to the SAP server, then a router will be used to enable the server-client communication. In such a case, specify the router string of the router in the Router text box. If both the client and the server exist in the same network, then specify ‘none’ against the Router text box. To know what is the SAP Router string for the ABAP server being monitored, follow the procedure detailed in Identifying the SAP Router String and System Number. |
InstanceName |
This parameter appears only if the Use SAPControl flag is set to No – i.e., if the test uses SAPJCO to collect measures. This is set to none by default. This implies that the eG agent automatically discovers the instance name at run time. |
Timeout |
Indicate the duration (in seconds) for which this test should wait for a response from the SAP ABAP instance. By default, this is set to 120 seconds. |
JCO Version |
The eG agent uses the SAP JCO library to connect to the SAP ABAP system and pull out metrics. To enable the eG agent to make this connection and query the metrics, you need to specify the version of the SAP JCO library that the agent needs to use. For instance, to instruct the eG agent to use JCO v2.1.19, it would suffice if you specify the ‘major version number’ alone against JCO Version – in the case of this example, this will be 2.x. Note that if you have downloaded the SAP JCO CONNECTOR files for SAP JCO version 3 from the SAP market place (as instructed by Downloading the SAP JCO Connector files Required for Monitoring ), then the JCO Version configuration should be 3.x. |
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Open change pointers |
Indicates the number of Idocs generated for the change pointers that are still in the Waiting state for the last 1 hour. |
Number |
Change Pointers are log entries to remember all modified records relevant for ALE. Change pointers are log entries to table BDCP, which are written every time a transaction modifies certain fields. |
Outbound ready for dispatch |
Indicates the number of outbound Idocs that were ready for dispatch during the last 1 hour. |
Number |
|
Outbound in external system |
Indicates the number of outbound Idocs that were waiting in the external system during the last 1 hour. |
Number |
|
Outbound errors in Idoc interface |
Indicates the number of outbound Idocs that encountered errors in the interface during the last 1 hour. |
Number |
Ideally, the value of this measure should be zero. |
Outbound errors in external system |
Indicates the number of outbound Idocs that were error prone in the external system during the last 1 hour. |
Number |
Ideally, the value of this measure should be zero. |
Inbound generated |
Indicates the number of Idocs that were in the Waiting state during the last 1 hour. |
Number |
|
Inbound errors in Idoc interface |
Indicates the number of inbound Idocs that encountered errors in the interface during the last 1 hour. |
Number |
|
Inbound errors in application |
Indicates the number of inbound Idocs with application errors during the last 1 hour. |
Number |
|