ALE Monitoring

ALE Monitoring

Version Date: March 30, 2004

Contents Applicability, Goals, and Requirements............................................................................................ 3

Goal of Using this Service........................................................................................ 3 Staff and Skills Requirements .................................................................................. 3 Duration and Timing ................................................................................................ 3 How to Use this Best Practice.................................................................................. 3

Introduction ........................................................................................................................ 4 General overview of ALE/EDI .............................................................................................. 4

ALE........................................................................................................................ 4 EDI (Electronic Data Interchange) ............................................................................ 4 IDoc (Intermediate Document) ................................................................................. 4 tRFC ...................................................................................................................... 5

Data flow ...................................................................................................................... 6 Outbound Flow ....................................................................................................... 7 Status for IDocs in the outbound flow........................................................................ 7 Inbound Flow.......................................................................................................... 9 Status for IDocs in the inbound flow.......................................................................... 9

Error Monitoring ALE/EDI...................................................................................................11 Purpose ......................................................................................................................11

Monitoring Agents ..................................................................................................11 Monitoring Responsibilities & Regular Tasks .......................................................... 13

Monitoring Tools for ALE/EDI ....................................................................................... 14 Automatic monitoring .................................................................................................. 15

SAP Solution Manager .......................................................................................... 15 Computer Center Management System (CCMS).................................................... 16

Transaction BDMO .................................................................................................. 18 Reporting via RSEIDOCM or RSEIDOCA ............................................................... 20 Monitoring the Status of Inbound IDocs Using ALE Audit.......................................... 21

Manual monitoring ...................................................................................................... 22 Status Monitor for ALE Messages (BD87) ............................................................... 22 ALE Admininistration (BALE) ................................................................................. 24

ALE/EDI Interface Management

2004 SAP AG

2

IDoc Lists (WE02) ................................................................................................. 25 Change Pointer Administration (BD22) ................................................................... 26

Error Handling .................................................................................................................. 28 Error Handling in ALE Outbound Processing................................................................. 28 Error Handling in ALE Inbound Processing ................................................................... 29 Reposting of Idocs in Status Error .............................................................................. 30

Workflow .............................................................................................................. 33 Finding related objects .......................................................................................... 34 Finding the IDoc via the tID.................................................................................... 35

Performance Monitoring .................................................................................................... 36 Settings and Issues in configuring ALE (RFC)............................................................... 36 Performance measuring for ALE .................................................................................. 37

System Monitor ST03N ........................................................................................ 38 How to find ALE/EDI tRFC issues with Application Statistics....................................... 42

Transaction STAD ................................................................................................. 44 QRFC Monitor (SMQS) ......................................................................................... 45 RFC Server resources (SARFC) ............................................................................ 46

Tips and tricks with ALE/EDI........................................................................................ 47 Archiving IDocs .......................................................................................................... 48


2004 SAP AG

3

Applicability, Goals, and Requirements To ensure that this Best Practice is the one you need, consider the following goals and requirements.

Goal of Using this Service Use this service to obtain procedures for the monitoring of ALE or EDI Interfaces. This paper will show you how to setup the monitoring to find errors in the IDoc processing, performance problems and the tasks for this.

Staff and Skills Requirements The staffing for this monitoring depends on the requirements of your monitoring. Usually at least one person from each department is needed to help set up the monitoring. And at least one person per department will be on the workflow lists for solving automatically deteced problems in ALE/EDI.

The skills for this depend on the departments requirements; the agents need to have the approproate skills to deal with the errors in their zone of responsibility.

Duration and Timing Setting up the monitoring processes depends on the volume of IDocs sent and the level of monitoring you wish for the interfaces The monitoring procedures described should be performed at least once per day. The exact frequency depends on the business requirements.

How to Use this Best Practice We make a number of suggestions in this paper in regards to the monitoring of the ALE/EDI and its interfaces. Therefore you should consider this paper as a whole and implement those items to ensure a safe ad secure transfer of IDocs.


2004 SAP AG

4

Introduction In this paper the ALE monitoring will be explained and you are given examples as to how to configure the monitoring landscape.

This paper is spilt into three basic sections.

The first section covers the basics of ALE/EDI. We address the basic concepts in ALE/EDI, what sort of data flows exist, etc

The next section talks about the monitoring process and tools. Also included are the basic error procedures for ALE/EDI.

The last section covers the performance issues.

General overview of ALE/EDI

ALE Application Link Enabling (ALE ) is the technology used by SAP ERP within one company to support distributed business processes across seperated application components within the companys landscape. ALE uses the business scenarios and function modules that allow to transfer data to or from an SAP ERP System without developing customer-specific programs. ALE is linked closely with Workflow Management within SAP ERP.The data is not only transferred between the systems; in addition it can also trigger follow-up actions in the SAP ERP System. From the SAP ERP viewpoint, the following data can be exchanged via ALE:

Transaction data which is data from applications

Master data, such as customer or material master data

Customizing data used for an overall ALE view

Data can be exchanged between SAP ERP Systems, SAP ERP and R/2 Systems, and SAP ERP and external (non SAP) systems.

The following functions and interfaces form the basis of communication:

ALE with all its components such as monitoring, archiving, usage of the data container called Intermediate Document (IDoc)

Transactional RFC (tRFC)

EDI (Electronic Data Interchange) EDI is a standard format for exchanging business data. It describes the document exchange with business partners on a technical level. With EDI the technical structure of the document is retained. EDI describes the mapping of the application data structure from the sender into the EDI standard, and from the EDI standard into the application data structure of the recipient. This enables the recipient to automatically process the document by his business software. The standard is ANSI X12 and it was developed by the Data Interchange Standards Association. ANSI X12 is either closely coordinated with or is being merged with an international standard, EDIFACT.

IDoc (Intermediate Document) IDoc is a data structure of SAP applications at the interface level. IDoc types form the container for the data to be exchanged. Each application has a special set of IDoc types that provides data to be exchanged. This results in a unified interface for any EDI subsystem regardless of the SAP module,


2004 SAP AG

5

which creates or receives the messages. The ALE approach is to link SAP systems directly. IDocs need to go through converter software and then be transmitted without a mapping into EDI. IDoc can be generated by three methods:

Generated directly from within the application

Generated from a change pointer

SAP ERP message control (the application creates a message entry (type ALE) in Table NAST)

The structure of an IDoc is always the same and follows the pattern below. Record Contense Stored in Table

Control Record Technical information about the IDoc as a container IDoc number, IDoc type, Partner, Port, )

EDIDC

Status Records Information about the IDoc processing flow (IDoc status, date, time, error message, etc)

EDIDS

Data Records IDoc contents: application data (business information) EDID4 EDID3 EDID2

IDcos can be distributed by various means

Flat File

tRFC

tRFC The advantage of transactional Remote Function Calls (tRFC) over synchronous and asynchronous RFCs is that the calls are buffered, even if the recipient partner is not active. When the partner is available again, a new attempt can be made to transfer the data. If an SAP ERP System receives the data, the requests are handled as transactions. This means that all functions called in one tRFC are either processed together or not at all. Each tRFC is sent exactly once, so that there are no accidental double postings of application data. All errorineous attempts to post data are displayed in the tRFC monitor.


2004 SAP AG

6

Data flow

Figure 1

In general the data flow is.

1. An application creates an IDoc.

2. The ALE layer does all the outbound processing of the IDoc.

3. The IDoc is sent on its way to the receiver systems port and its ALE layer.

4. Once it has reached its destination the inbound ALE layer does its work and passes the IDoc to the receiving application.

At most steps of the process, a status record is generated. The sender generates a status record until the IDoc has left the system. The receiving side also generates status records, but they are limited to only the receiving side. There is no communication of status information active between the two parties unless the ALE Audit is explicitly activated.

A port is a logical description of the channel used by the SAP system for communicating with the receiving system during electronic data interchange. There are various technical methods for implementing this type of communication (port types). Therefore you have following IDoc ports for transfering:

tRFC: For SAP ERP- to SAP ERP-system communication and SAP ERP to ALE converter or ALE message handler subsystems the transactional RFC interface is used.

Flat file: Most common for SAP ERP system and EDI subsystem is a flat file interface.

The selection of the port type depends on the technical configuration of the target system.


2004 SAP AG

7

Outbound Flow

Figure 2 Outbound Data Flow

SAP applications create IDocs using the message control or of their own accord.

An IDoc flows from the application through the Message Control into the IDoc interface. The IDoc interface is invoked by either form-routine EDI_PROCESSING or ALE_PROCESSING in program RSNASTED. In the IDoc interface the IDoc is passed to the ALE services (conditional) and later on transferred to the target system according to its port definition.

Applications that do not use Message Control will create IDocs directly. They invoke function module MASTERIDOC_DISTRIBUTE and pass the IDocs to the ALE services, where the IDocs will be preprocessed according to ALE customizing. The star with the number denotes where the status of the IDoc is set, more on this later in the document

Also change pointers can be creatted directly out of the application. They are stored in tables RBDMIDOC and RBDMIDOCS

Status for IDocs in the outbound flow To track the flow of the IDoc SAP has devised a method using status records. Each step in the processing of an IDoc has a different status number. Therefore you can track the IDoc by its current status. All Idocs start with status 01 (as seen in the Figure below & above), then the processing begins. As not every processing step is needed for an IDoc you will notice that the status will jump sometimes, bypassing steps. In principle it will work itself down the path to status 12, also 03 is considered a final status. With this step the IDoc leaves the sending system and the IDoc was succesfully past on to the receiving system. In the figure below the green status are successful and the red ones indicat e a problem or error.


2004 SAP AG

8

Figure 3 Outbound Status Transitions

The status values 41 in ALE scenarios (only if ALE Audit is enabled), 12 in EDI scenarios are considered as the final status in most implementations. For the sending systems 03 is considered by most to be a final status.

Status by the SAP system:

Code Meaning

01 IDoc created

03 Data passed to port OK ()

12 Dispatch OK

18 Triggering port OK

25 Processing despite syntax error (outbound)

26 Error during syntax check of IDoc (outbound)

29 Error in ALE services

30 IDoc ready for dispatch (ALE service)

31 Error - no further processing

37 IDoc created with errors

39 IDoc received in target system

40 Error - application document not created in target system

41 Application document created in target system

42 IDoc created by test transaction

Status by the EDI subsystem:

Code Meaning

06 Translation OK

08 Syntax check OK

10 Interchange handling OK

12 Dispatch OK

14 Interchange Acknowledgement positive

16 Functional Acknowledgement positive

22 Dispatch OK, acknowledgement still due

24 Control information of subsystem OK


2004 SAP AG

9

Inbound Flow

Figure 4 Inbound Flow

Various function modules or reports can process received IDocs, depending on the inbound partnerprofile. For example the function IDOC_INBOUND_ASYNCHRONOUS is called for SAP ERP to SAP ERP ALE scenarios. This in turn triggers a number of other function calls, depending on the sending system, receiving system, and information transferred.

Status for IDocs in the inbound flow

Figure 5 Inbound Status Transitions

The status value 53 in all scenarios is considered as the final status in any implementation.


2004 SAP AG

10

Status by the SAP system (IDoc Basis):

Code Meaning

50 IDoc added

56 IDoc with errors added

60 Error during syntax check of IDoc (inbound)

61 Processing despite syntax error (inbound)

62 IDoc passed to application

63 Error passing IDoc to application

64 IDoc ready to be passed to application

65 Error in ALE service

66 IDoc waits for predecessor (Serialization)

68 Error - no further processing

74 IDoc added by test transaction

Status by the SAP system (Applications):

Code Meaning

51 Error - Application document not posted

52 Application document incomplete posted

53 Application document posted


2004 SAP AG

11

Error Monitoring ALE/EDI

Purpose Due to the exchange of information in todays SAP ERP landscapes, it is of importance to monitor the overall landscape and make sure that no information is lost or stuck somewhere in transit. If the monitoring fails or is non-existent, it can result in a major impact on the business of a company. It is of prime importance to monitor the ALE interfaces for the following:

Transfer errors in the sending system

Application or technical errors when processing the data in the receiving system

Response times and throughput

Serialization errors (if serialization is required and used)

Data growth

These tasks require a number of people who are able to handle problems at each step/level of the data exchange. It is advisable to distribute the monitoring load amongst a number of people and automate the monitoring as much as possible. Every interface needs to have a responsible team (or person), who keeps track of all processing in the respective systems. The responsibility includes dispatching, tracking and error resolution. It also can include monitoring the performance for the interface. Your organizational units should be assigned to handle these cases. The workitems for the responsible person(s) are posted in the SAP-workflow and are used to assgin, track and process errors.

Monitoring Agents

Figure 6 Determination of selected agents

The Agents are persons in your organisation, whose task it is to monitor and repair the IDocs that have problems in the ALE/EDI. Agents are users (accounts) or organizational units defined in the organizational plan. By using organizational units, you address a group of people instead of just one person. This assures distribution list functionality and error messages are not lost due to vacation or other activities. The agents are usually triggered via the workflow functionality in SAP ERP.

We have three kinds of agents:

Possible agents are assigned to tasks, defined in the SAP Business Workflow. The assignment is defined in the organizational plan of the enterprise.

Permitted agents are assigned in the IDoc interface to partner profiles. They know the partner and how he/she does business and what procedures there are for the communication between both parties.

Selected agents are defined as the intersection of the group of permitted agents with the group of possible agents. The agents see tasks (as work items) in their workflow inbox. Using the intersection to determine selected agents guarantees that they are selected dynamically.


2004 SAP AG

12

This means, whenever a position is changed in the organization, work items (from the previous organization) may disappear and be replaced automatically by new ones .

General Procedure

Follow these steps to set up the monitoring of the ALE/EDI interfaces:

1. Create one or more organizational unit(s) for error processing.

2. Create one or more position(s) for the organizational unit(s).

3. Assign a user or distribution group to the position

4. After the positions are defined, they must be linked to the standard tasks. The following standard tasks must be considered:

Standard tasks for errors at ALE level.

Standard tasks for application errors.

You do this in transaction SPRO IMG: Distribution (ALE) -> Error processing -> Create organizational units and assign standard tasks

Sometimes it is unclear who is responsible. If the IDoc is not sent due to a transfer error or other technical issues then it is a technical issue. On the other hand, if the IDoc cant be processed by the receiving system then the application needs to take charge. If there are borderline cases, then you can always define a special group that takes care of these. Either they solve the issues by themselves or delegate it to another team.

For further information we refer you to SAP Note 116610 - IDoc: Notifications from IDoc processing and the Installation Guides .


2004 SAP AG

13

Monitoring Responsibilities & Regular Tasks In the table below we have described a number of tasks for the ALE/EDI monitoring. Depending on the complexity of the interfaces you may need to define additional tasks/procedure. Also the monitoring frequencies are dependent on your scenarios, the more critical scenarios need to be monitored more closely and more frequent. We suggest at least a regular daily monitoring, but shorter timeframes are always possible. In the following pages we are going to cover these transactions in more detail.

IDoc Monitoring

Task Responsible Transactions

Check IDoc processing System administration, Functional department

WE02, WE05, WE07 or BD87

Process IDocs with errors Functional department BD87 Process IDocs with application errors Functional department BD87 Display erroneous

IDoc Status long text Proceed to view application log

Check performance of IDoc processing System administration SM37 / ST03N / STAD Free Dialogs processes in server System administration SM50, SM51, SM66 Performance of IDocs System administration STAD, ST03N Recorded tRFCs in error status System administration SM58 Workprocess usage and RFC capable processes

System administration SMQS goto qRFC resources

Monitor the resource usage for aRFC System administration SARFC Resource management for aRFC System administration RZ12 Create and Monitor Background job for reprocessable errors

System administration SM36 / SM37

When reading this text you may wonder why there are four different transactions (WE02, WE05, WE07 and BD87) to display IDoc lists. These transactions grew with time and have slighty different ways to display the information and what you can do with it.

Here is a small list of the transactions and what basic functions they provide:

WE02 The initial output is sorted by IDoc type.

WE05 The initial output is sorted by Status.

WE07 The IDoc statistics are displayed independent of the type and partner..

BD87 The output is sorted by status with the possibility to (re)proceess failed IDocs.


2004 SAP AG

14

Monitoring Tools for ALE/EDI In this paper we differentiate between two monitoring methods.

Automatic monitoring: This includes the Solution Manager, CCMS.

Manual monitoring: A number of standard SAP transactions for ALE monitoring.

The difference between the two-monitoring methods is in the sequence of the taken steps.

In automatic monitoring you use the Solution Manager, CCMS and other tools to keep track of the ALE activity. These monitors automatically collect their respective data and display it according to your needs. You are able to quickly see and analyse the situation. Once you have found an issue, you can use the tools mentioned in the manual monitoring to find and repair the issues.

The manual monitoring approach is to look at specific transactions to find problems. This approach is more along the lines of an on call monitoring. It is the expert technique, as you are looking at specific data to find problems. An expert will drill down into the system quickly to find the problem. You can also see this as the intense analysis method when the active monitoring has given you the indication that problems might exist.

SAP suggests to always use the automatic monitoring, as it assures a save dataflow with optimal performance.

Every company needs to define what procedures are best for it. One aspect you need to consider is the impact on business when an ALE/EDI interface does not work correctly. This can be used for a gauge for defining an indicator of the importance of this particular interface. Every interface therefore will have a certain level of monitoring procedure (intensity) and required response time when errors appear.

In the next section we will show you a few of the possible methods of monitoring the ALE/EDI interface. This is by no ways complete and depending on your scenario it needs to be configured to your needs.


2004 SAP AG

15

Automatic monitoring

SAP Solution Manager

Figure 7 Solution Landscape Graph

The SAP Solution Manager should serve as the primary tool for your overall monitoring. It summarizes and displays performance indicators and alerts in graphical form. As it combines the data from the business process with the information gathered from the technical monitoring, the actions triggered by the SAP Solution Manager are quite specific. In comparison to the CCMS, the information in the Solution Manager is easier to read, especially when monitoring a complex solution landscape. In the figure above you can see two systems and that two interfaces have an error. You can now take a closer look at those particular interfaces. If a problem has been detected in a specific component, then the more detailed analysis methods the next step. The CCMS can give you more information (like history values) for all monitored components. For a more indepth analysis the ALE monitoring tools are more helpful. They will help you to determine the specific problem and evaluate its importance. These tools are component dependent and support you in finding the problem. In order to make use of the Solution Manager, one needs to configure it appropriately. This is beyond the scope of the current document to outline these steps in detail. We refer you to the document Interface Monitoring in SAP Solution Manager: Customizing in the Media Library.

In the figure above you can see that two if the interfaces PO APO X48 and RQ X48 AP have some sort of a problem, this is indicated by the red rating. You then can use the other monitoring tools to analyse the issue further.


2004 SAP AG

16

Computer Center Management System (CCMS)

Beside the SAP Solution Manager the Alert Monitor in the CCMS is the second central administration and monitor tool for SAP solutions. As it stands it is more a techncal monitoring tool. It should be used on the same system where the Solution Manager is installed (the monitoring system). The data displayed in the CCMS is the basis for most of the information displayed in the Solution Manager.

Directly after the installation of the monitoring system, this tool only provides monitoring information belonging to the monitoring system itself. To monitor additional components of a landscape, it needs to be configured appropriately. After this configuration is done, the monitoring data of all components is available.

For ALE/EDI you need to use the transaction BDMO to configure the monitoring. The following section describes this in detail. Also SAPNote 441269 will give you more information.

Figure 8 CCMS

If the SAP Solution Manager reports a problem in one of the components, the corresponding component should be checked in the Alert Monitor. When you click on the respective item you get the monitoring window to appear. At this stage you can decide what to inspect more closely.

Figure 9 a monitoring set

After that step a list of monitoring elements (e.g. ALE, database , ) and the corresponding alerts are displayed. Alerts in the CCMS Alert Monitor are the central elements that report problems. To give a better overview, alerts are assigned certain colors:

Green: Everything is ok according to you threshold configuration.

Yellow: A warning has been issued.


2004 SAP AG

17

Red: A problem or critical condition has been reported.

Gray: No data is being supplied for a node.

You can display and maintain the thresholds directly in RZ20. For this purpose select the corresponding node and choose Properties. Then choose Display Change and make the necessary changes.

In the standard SAP monitoring set, SAPs CCMS Monitors for Optional Components you can find an ALE monitor template for ALE/EDI. This template shows outbound and inbound IDocs, change pointers and the transactional RFC queue. It also contains an ALE monitor display that serves as an example monitor branch for MATMAS IDocs.

For the ALE monitor, the data collection runs in batch mode. Prerequisite for this is that the CCMS alert monitor batch tool dispatcher (SAP_CCMS_MONI_BATCH_DP) is activated. Otherwise all monitoring elements of the ALE monitor are grey (inactive/deactivated). You can activate batch tool dispatching starting transaction RZ21. Choose Technical infrastructure Method execution Activate background dispatching.


2004 SAP AG

18

Transaction BDMO

Initially there are no ALE monitoring objects except the basic set and no objects are active in the monitoring tree. The first step is to start transaction BDMO or SPRO (Basis Components Distribution (ALE) Monitoring Systems Central Monitoring of All Systems). This will open following window.

Figure 10 Initial BDMO

Then choose Create/Activate Monitoring Objects. This will lead into the following screen.

Figure 11 pressing create/activate

Here you can choose from four monitors. They represent a basic level of monitoring for the ALE/EDI interfaces. The first three entries give you a view into your general ALE/EDI flow. The last one is the test/example monitor for you to see what you can do in ALE monitoring.

The three predefined monitors give you the same information; only their time range is varied. The top one is for the last seven days, the next one covers the last hour. The third is an example of a monitoring of a specific object Material Master. Figure 14 shows you what they look like, just in more detail.

If you like to monitor individual IDoc types, you can create your own ALE monitoring objects. Enter transaction BDMO and click at Create/active monitoring objects. Click New entries. You can enter the monitoring object name. Check the Active item and save your settings. Make sure to activate your new object.

Figure 12 Activating the monitoring objects


2004 SAP AG

19

The next step is to define which IDoc type is monitored. We make the example by defining a new object for the EBP IDoc monitoring, in this case the IDocs of the outbound type BBPCO. You can also specify the partner system and the wait time for status changes. The wait time is the time setting between updates for a message. The item Period defines how many days worth of information is displayed. We suggest a value 180 days. You should not delete the entry here (ie. leave a blank space) as this will never return any information! When you have made your choice, save your settings.

Figure 13 On the entrance screen of BDMO, choose Monitoring object Start all (or press F9). A new monitoring object is created that can be used in rule based monitors. If you do not have the CCMS alert monitor batch tool dispatcher (SAP_CCMS_MONI_BATCH_DP) activated by now, do so. You can activate batch tool dispatching starting transaction RZ21. Choose Technical infrastructure Method execution Activate background dispatching. Otherwise all MTEs of the ALE monitor are inactive. Keep in mind that it might take some time for the monitoring tree to appear, as there is a delay until the batchjob runs and data is displayed. To set up a rule based monitor for your ALE monitoring object. Select the rule CCMS_GET_MTE_BY_CLASS with parameter ALEPfGr: for the MTEClass. As a result only information concerning your IDoc selection is displayed. In our example we created the ALE object EBP and this served as the parameter ALEPf.

Figure 14

You should monitor all systems that are involved in ALE process. Afterwards you can create a central ALE monitor in your monitoring system displaying all ALE information in one screen using the rule


2004 SAP AG

20

CCMS_GET_MTE_BY_CLASS. For the parameters R3System and MTEClass, choose a proper combination for each remote system. In the figure below we are showing you what possibilities you have to set up the monitoring. In a complex landscape with many systems and interfaces it can be helpful to activate as much information as you can into the CCMS. This way you can get the big picture of the whole landscape.

Figure 15

As a rule, try to do as much as you can with the active monitoring. This has the advantage that you can be active in reducing the impact of errors before they happen. Otherwise you are always trying to fix problems after the fact and have more work than necessary.

Reporting via RSEIDOCM or RSEIDOCA

This report is used to see to monitor specific IDocs and their status. You can filter specific IDoc and/or status types. This active monitoring job is usually scheduled as a periodic background job. The interval depends on the volume (or importance) of the IDocs being sent. It ascertains whether the number of IDocs in a status group (defined by a range value) exceeds a specified threshold. If it does, a message is sent to the specified workflow receiver. An example: Your buisness process need to process 100 IDocs of a certain type every hour. If suddenly the number of processed IDocs drops to 80, an alert in form of an e-mail, or Workitem is created for the person(group) specified in the report variant. They can then use the appropriate tools to analyse the situation.

If you are on WebAS smaller 6.10 then it is RSEIDOCM, on WebAS 6.10 and greater the report is called RSEIDOCA. See SAPNote 361570 for more details.


2004 SAP AG

21

Monitoring the Status of Inbound IDocs Using ALE Audit Usually in ALE/EDI the receiving side does not inform the sending as to what document (and its ID) was generated. Using ALE audit you can monitor the processing status of dispatched IDocs in the receiving system from the sending SAP ERP System. The receiving SAP ERP System periodically sends confirmation messages to the sending system. These confirmations are logged in IDoc status records and in separate audit tables in the sending system. A link is also created between IDocs in the sending system and IDocs in the receiving system. A report program running on the sending system analyzes the audit database.

0815

Figure 16

Confirmations can only be dispatched, if you have defined a message flow for message type ALEAUD in the distribution model. To do this choose the following activity in the SAP ERP Implementation Guide:

SPRO:Basis Application Link Enabling (ALE) System Monitoring IDoc Confirmation in Receiver System (ALE Audit) Distribution Model for ALE Audit.

To improve performance, consider dispatching the confirmations in IDocs packets (rather than indivi dual IDocs ) periodically and schedule the sending of the packets in lowload times. Confirmations have a special ALEAUD01 IDoc type with message type ALEAUD.

The filter object message type (MESTYP) provides a more detailed specification. You can use this filter object type to set the message types for generating audit confirmations. As a rule, you do not have to send confirmations for all message types. For example, it is quite likely that confirmations will not be necessary for master data initial transfers. If the MESTYP filter object type is not used all IDocs are confirmed by ALEAUD in the receiver system.


2004 SAP AG

22

Manual monitoring

Status Monitor for ALE Messages (BD87) Depending on your monitoring procedures, you start of by choosing a timeframe,IDoc number, () you wish to analyze closer.

You can limit the display according to your needs, e.g. display only certain messagetypes or partners.

Figure 17

Then start the tool with F8 (Execute).

Figure 18


2004 SAP AG

23

The result of the query is seen above.

Code Meaning

12 Transfer was OK The IDoc was sent to receiving system and was verified. This means the data was sent and received correctly. It does not make a statement about the processing on the other side. For more information consult the receiving system

30 IDoc is ready to be transmitted. (ALE service) The IDoc was created by the application and is waiting for a sending job so that it can be sent to the tRFC layer. If the number of IDocs with status 30 keeps increasing, make sure to take a look at the sending job.

50 IDoc added IDoc has been transferred to partner system and was written onto the database in the SAP ERP

64 IDoc is ready to be transferred to the application IDoc is in line to be processed directly or per batch job

62 IDoc has been passed to application The application processing was called and is processing the data

53 Receipt is booked The application has succesfully booked the IDoc. You could archive the IDoc if desired.

If codes below are present then the application department needs to be contacted.

62 Error with the passover of the IDoc to application Check to see if there are issues with the starting of the programs.

37 IDoc added with error

26 Syntaxerror in IDoc (outbound) IDOC configuration is not correct, this should not happen in a productive system.

27 Error in the sending layer (ALE -Service) IDOC processing towa rds tRFC layer has problems.

28 Error in ALE- Service IDOC Partner profile and distribution model needs to be checked, this should not happen in a productive system.

31 Error, no further processing possible no further details available

63 Syntaxerror in IDsoc (outbound) IDOC configuration is not correct this should not happen in a productive system.

51 Receipt not booked, error.

52 Receipt booking is incomplete The application department needs to check what the problem is.

Tips: For the switching of the IDoc-status from 03 to 12 a batchjob is needed. It should be scheduled regularly (SAP Report RBDMOIND).


2004 SAP AG

24

ALE Admininistration (BALE)

Figure 19

From this central transaction you can do most admin work for the ALE. For example, you can jump to BD87 Status Monitor. This way you can check to see if the IDoc processing is working well. By checking the IDoc status reports you can see if the application and processing is working.


2004 SAP AG

25

IDoc Lists (WE02) In this transaction you can generate a list of the IDocs

Figure 20

The output is below. On the left hand side you see the tree view of the IDocs statuses. Sorted by IDoc type then status.

Figure 21

When you click on an IDoc line on the right hand side you can get the details. And if there are errors you can find out what the problem is. You can then for example use the BD87 to repair the IDoc.


2004 SAP AG

26

Change Pointer Administration (BD22) Change pointers are stored in the database as either Processed or not. If they are successfully processed they are not automatically deleted from the database. To prevent them from taking up too much disk space, you must periodically call report RBDCPCLR to delete them. Depending on the volume of change pointers you may need to schedule the batch job hourly, daily or weekly.

Transaction BD22 (Tools -> Business framework -> ALE -> Administration -> Period. work ->

Reorganization -> Change pointers) can also be used to do this manually.

It deletes change pointer entries from the database. If you run it in test mode, only a list of the selected entries is generated. You can select either obsolete or processed change pointers or both. Additionally, you can search according to date and time.

Obsolete change pointers have been created up to the specified date and time. If this checkbox is marked, obsolete change pointers will be reorganized regardless of whether they have yet been processed. You should then deactivate the change pointers for these IDocs. You can do this with transaction SALE

Figure 22 SALE where you can configure the change pointers

Figure 23 activating a change pointer

Processed change pointers have been processed in the specified period (date and time). If this checkbox is marked, the processed change pointers are reorganized.


2004 SAP AG

27

Figure 24 Startscreen BD22

Figure 25 BD22, result of a test run

SAPNote 513454 covers the topic of change pointers, administration and performance.


2004 SAP AG

28

Error Handling In this section we will cover the basics of error handling in regards to ALE/EDI. How you are alerted to an error arising depends on what tools you wish to use. You need to implement a monitoring procedure for in- and outbound processing. The following procedure assumes that you have been alerted. For the monitoring purposes you are either using the CCMS concept, or dedicated ALE/IDOC monitoring transactions BD87 and specific WE02/WE05.

Error Handling in ALE Outbound Processing 1 You need to use your specific monitoring tool to find out which IDocs are not being transferred or

processed correctly anymore.

2 Open the respective IDoc in the monitor and see what its status is:

File: Status 02 and you have a File based interface see if the file is corrupted, or the application is writing a correct file. See the solution for the error message EA 084.

The most probable reason for the error is that there is no such directory or the user doesn't have enough authorizations on the operating system level to write a file in the directory. In order to be able to write an IDoc to file the user should at least be assigned to the authorization object S_DATASET. See also the notes 334097 and 90111.

RFC Status 30 indicates the IDoc is not being passed to the ALE layer.

a) Option Collect IDocs is switched on in the partner profile (WE20) instead of Send immediately IDoc transfer has to be done by regular scheduled background jobs (report RSEOUT00).

b) IDoc can be locked during execution of RSEOUT00, which ignores locked IDocs. Current locks can be seen from the transaction SM12. Locks are set by the application responsible for creation of the IDocs.

File: This occurs because the locks are released too late or never. IDocs are still locked when the COMMIT WORK occurs and wants to write an IDoc into the file (see the SAPNote 150202).

There are some solutions avaiable for particular IDoc types.

RFC The locks are released with COMMIT WORK statement in the application. In some applications this happens only when the user leaves the corresponding application screen.

3 A status 03 means the IDoc has been transferred to the tRFC, but not transmitted to the receiving system. The report RBDMOIND is responsible for the status change. If an IDoc has been passed to tRFC (IDoc status "03"), but has not yet been transferred to the receiving system.

If the report is running, but you still see a large number of IDocs in status 03 then procced as follows call SM58 and test the RFC connection. Maybe the network is down, or the receiving system does not have any dialog workprocesses available or there are other resource issues. To check the status of tRFC calls select Tools ALE Administration Services Communication Transactional RFC Display incorrect calls. tRFC calls that transfer IDocs use the function module IDOC_INBOUND_ASYNCHRONOUS (for releases before 4.0 INBOUND_IDOC_PROCESS) in the receiving system. The program RSARFCEX restarts unsuccessful tRFC calls. We recommend sheduling the report RBDMOIND on a hourly basis, as this report is needed for the CCMS monitoring.

4 If the tRFC call was created but no data was received in the target system, it is possible that something in the transfer is not working. To check that particular case, you can do a RFC trace in both sending and receiving system to see if any data is being sent between both parties. To do so use the transaction SM59 (see the note 532918 for more details.


2004 SAP AG

29

Error Handling in ALE Inbound Processing The monitoring of the inbound processing depends on how you wish to setup your monitoring. There are two basic approaches to the inbound monitoring:

SAP Workflow

Monitoring via the CCMS or the BD87.

The first option is of course the best for larger organisations. The SAP-Workflow triggers the responsible persons to take care of the error in the IDoc.

The other is to use the CCMS or the BD87 to monitor the incoming IDocs.

1 In your monitoring tool of your choice, check to see which IDoc is having problems.

2 If you see one of the following status codes you have following means to react.

Status 64

IDoc ready to be sent to application. As a temporary solution, IDoc can be posted using BD87 or RBDAPP01. If IDocs stay in status 64 despite of the option 'Trigger immediately' chosen in the partner profile for inbound messages. Consider applying SAP Notes 166278 and 168276. It is also possible that there are no free RFC resources, in this case you should reajust your parameter settings (more on this in the following chapter)

Status 51 or 63

If the processing of the inbound IDoc resulted in IDoc status 51 - "Application document not posted", or 63 - "Error passing IDoc to application")

You can use the report RBDMANI2 to resubmit the IDoc. The program can also be scheduled as a periodic job to collect IDocs that could not be posted because of a lock problem. But this does not relieve you of monitoring the IDocs to make sure that no other errors are present.

If the error persists then you need to check what type of error occurred during processing of the document. There are two possibilities. Keep in mind that this is an either or activity, you cant do both!

Resending Check if the error can be resolved by changes in the business-related objects so that the IDoc can be reprocessed correctly. If the error cannot be corrected, then a new IDoc has to be created and the old IDoc has to marked for deletion.

Manually edit IDoc

You can manually correct the IDoc. Keep in mind that some IDocs must not be changed according to local laws. When this is done you can reprocess the IDoc. More information in the following chapter.


2004 SAP AG

30

Reposting of Idocs in Status Error If IDocs are in status 51 you can try to just reprocess the IDocs again.

Figure 26

In the status monitor you can choose a particular IDoc to try to reproccess it. By using the right mouse button, you have the choice between Process or Restrict and process. With process you restart the processing of the IDoc(s). Restrict and process you have to make a few more choices, as we see in the following window

Figure 27

You can futher restrict the IDocs you wish to process in this screen. The execute button on top will then start the processing.

If the Bkgd processing is unchecked, you can see the window below. This choice gives you more options to process the IDoc.

Process starts the processing of the choosen IDoc(s). Delete fag sets the IDoc status to 68. Meaning the IDoc has a error and does not need to be processed again, but can be archived/deleted. IDoc display shows you the payload of the IDoc.


2004 SAP AG

31

Figure 28

Pressing IDoc display shows you the current information on the IDoc. To display the errors in the IDoc you press the Segments with errors button. The next figure shows you a sample error.

Figure 29

Figure 30

Analyze the error situation. Check if the error can be resolved by changes in the business-related objects so that the IDoc can be reprocessed correctly. If this is not possible, then you need to decide what the next steps are:

Either resend corrected data from the sending system, then mark the IDoc for deletion.


2004 SAP AG

32

Manually process the IDoc by entering the corrected IDoc data directly into the appropriate SAP application transaction, then mark the IDoc for deletion.

Please keep in mind that this is an either or activity, you cant do both! Also the appropriate agent probably needs to decide what steps need to be taken.

Figure 31

By pushing the Delete flag button you mark the IDoc for archiving/deletion. The status for this is 68, this denotes the fact that the document had an error, was deleted and does not need any further processing.

The other option is to modify the IDoc.

Figure 32

If the IDoc does not contain data that is legally binding, i.e must not be changed according to the local countries law; you have the option to change the data so that it will be processed the next time. You can edit the IDoc content manually by clicking on the notepad icon in front of the segment. Then you switch to change mode by hitting in the menu Data record Display Change.

Once the changes have been made you can reprocess the IDoc again.

To give you a litte more understanding on the procedure we would like to shed a little light on what happens in SAP ERP. When you reprocess a IDoc following things happen in the system:

A copy is created of the org. IDoc. (this is done for documentation pruposes). This copy has either status 33 (sender) or 70 (receiver). In addition to this the copy can not be processed! The orginal copy gets status 32 (sender) or 69 (receiver). In addition a status record is created with 32 (sender) or 69 (receiver) and its long text contains the IDoc number of the IDoc copy..


2004 SAP AG

33

Workflow The workflow interface looks like the following figure.

Figure 33

Once you have chosen an item to look into further you will notice that the next steps are very much like the steps/methods described in the BD87. So then we would like to refer you to that part of the document.

Figure 34


2004 SAP AG

34

Finding related objects Every RFC has a unique identifier called the transaction ID (of a tRFC) or tID. When a IDoc is sent between two systems the tId is used to identfy it.

You can use this identifier when you have external connections to systems to find out which IDocs made it to the receiver system. For example, the (non SAP-)partner system has a incorrectly implemeted tRFC interface. The IDocs are not received correctly in either the partner system or the SAP-system. This tID is the link between the two systems, as you can use it to find out which IDocs made it to the receiver.

To find tId and its corresponding IDoc number call WE05 choose the appropriate IDoc you wish to analyse. Pick the IDoc you wish to analyse and then click on its controll record.

Figure 35 the IDoc and its controll record

Then you need to choose System --> Services for Object. This opens a popup window. And here you choose the button display relationships.

Figure 36 the display relationships button

Figure 37 Outbound service relationship

In the figure above the red box is the Tid of the sent IDoc.

Figure 38 Inbound service relationship

In the inbound IDoc you get the tId from the sending system and the IDoc number.


2004 SAP AG

35

Finding the IDoc via the tID Another way to find the tId is the relationship IDC8: (Inbound IDoc and transaction ID).

With this relationship you can find out if a particular RFC was called and the IDoc was created within the target system.

Find out the IDoc index for a tRFC in both sending and receiving system.

SAP Note 317864 gives you further details. If you wish to find out if an IDoc was created via tRFC following steps are nessecary:

1. You have the tID (from the sending system). With this information you go to the target system into SE16 ad look up table SRRELROLES.

2. In SRRELROLES there is the entry OBJKEY and ROLEID, the OBJKEY is the tID and the resulting role-id-a is to be found under ROLEID.

3. With that role-id-a you need to go to table IDOCREL enter the role id as a search value for RoleA. The result is in RoleB (well call it role-id-b)

Finally we need to go back to SRRELROLES, copy the role-id-b into the filed for ROLEID the result is then the inbound IDoc number.


2004 SAP AG

36

Performance Monitoring This chapter shall give you some suggestions how to monitor your systems performance for ALE/EDI. The first step is to understand that we actually need to look at at least two systems, depending on the landscape and solution. So optimization steps may need to be done in two systems.

The performance of ALE depends on many factors (type of business process, number of messages, activities running on the distributed systems, hardware, and so on). So we are not able to give you exact statements about performance indicators.

It is advisable that the persons who do the performance monitoring of the ALE/EDI have attended the SAP course: BC315 Workload Analysis. As the technical knowledge for the monitoring is much more complex we can only give an overview of the performance monitoring in this paper.

Settings and Issues in configuring ALE (RFC) In this section we are going to give an overview of the settings that apply to RFC communication. It has been our experience that if the system parameters are not properly set, the system may have massive problems. This could even go as far as disrupting normal user operations.

This does not in any sort of way replace any suggestions given in Notes or Early Watch / Going Live Reports. It should enable you to understand the settings better and give you an understanding why some of the settings are made.

The graphic below shows the SAP application server resources relevant for parallel RFC.

Keep in mind that, sender and receiver need special parameter settings for RFC communication. Many companies configure special RFC application servers so that the normal dialog user is not impaired by the RFC communication/workload.

Figure 39

An important note is the fact that incoming RFC from a remote system is handeled by the SAP ERP system similarly to an online user. This implies that both normal SAP users and RFCs concur for the same resources within the system. So it is possible that these RFCs can use all the resources of an


2004 SAP AG

37

application server therefore locking out the SAP users.

We are not going to list actual parameter suggestions, as the Notes are kept up-to-date. Following SAP Notes are going to help you in finding your individual settings.

74141 Resource Management for tRFC and aRFC

527481 tRFC or qRFC calls are not processed

384971 Gateway parameters for a high interface load

555229 IDocs hang in status 64 for tRFC

Performance measuring for ALE The first step in Performance measuring is to have a baseline to measure against. As every customer has their own way to use IDocs there is really no simple way to define what is a good performance or what is bad. Therefore the first step is in defining KPIs (Key performance indicators) for the ALE/EDI interfaces. By doing so you define what minimum performance you require. This depends on a number of factors and is based on your business needs. All parties in the process need to agree to these KPIs and the actions to be taken when these limits are exceeded.

One way to find these KPIs is to use your QA -system (or the future productive system) and measure it. These numbers might be useful in defining the KPIs. Another method is to analyse your busines process. For example, if you need to send 3600 IDocs per hour (each containing the business data for one VA01) so you need to be able to process one IDoc per second.

In the following sections we are going to show you some tools in SAP ERP and how you can use them to measure the performance of the RFCs. There is also a SAP course called BC315 Workload Analysis which covers this and many more topics of performance monitoring in greater detail.


2004 SAP AG

38

System Monitor ST03N This transaction is used to find performance issues within the SAP ERP.

1 Call transaction ST03N in the SAP ERP system.

2 You have the option to use the ALE monitoring. The following two sections describe how to do this.

Activting the statistical collectors

It is possible that no RFC-statisctics are stored, as it is possible to turn them off in the system. The steps to reactivate the monitoring are differnt for 4.x and 6.x versions of SAP-ERP. So we shall give you both versions. For both you need to enter transaction ST03N.

For SAP ERP 4.x: In ST03N, you need to go into the collector branch workload collector Collector and reorg.

Figure 40

Push button: Modify parameters.

Figure 41

In this screen SAP suggests that you activate all the check boxes and options. At least the "Cumulate RFC profiles"-entry under "Statistical data to be cumulate & Controls for the collector" has to active. Then save the choices.


2004 SAP AG

39

For SAP ERP 6.x:

In all the mentioned subscreens you have the choice to use the SAP Defaults button. This option will set the parameters to values which are suggested by SAP. Make sure to note which parameters you modifed in the system. As everything you have set manually will be erased by the defaults.

In ST03N, then Collector and Performance DB

Figure 42 collector sub tree

There you need to modfiy all the sesstings which are divided amongst 3 different subscreens. From top to bottom

Performance Database Reorganisation

Figure 43 Reorganisation screen


2004 SAP AG

40

In the Workload Collector pick the Controll Data branch. In the following screen you can choose how much data is stored on the local file system. Understand that there is no exact information how large the files can get, so please make sure that you have enough diskspace avialble for these logs.

Figure 44

In the next selcation screen you can choose what data is stored in the system. SAP suggests to activate all the checks, but the RFC statistics is the minimum to have actived.

Figure 45


2004 SAP AG

41

Activating the RFC Monitoring

You can activate the RFC specific monitoring by activating the Expert Mode, then choosing the RFC-server. Depending on your needs you may want to pick a larger timeframe to find issues. In our example we choose today as the analysis timeframe.

Figure 46

Then in the lower window you choose Analysis views RFC profiles Choose one of the RFC profiles

Figure 47


2004 SAP AG

42

You can now sort the information according to function modules. They are called in a specifc sequence:

1) RFC_PING (from sender to receiver)

2) RFC_RUN_NOWAIT (sender internally)

3) RFC_DEST_SHIP (from sender to receiver)

4) RFC_DEST_CONFIRM (from receiver to sender)

The system function module ARFC_DEST_SHIP transports the data to the target system. If a LUW runs successfully in the target system, the function module ARFC_DEST_CONFIRM is triggered and confirms the successful execution in the target system.

When you click on a specific entry, another window opens displaying more detailed information. This way you can see wether certain tRFCs have problems or if there is a general issue to deal with.

Figure 48

How to find ALE/EDI tRFC issues with Application Statistics

The first step is to set the ST03N to expert mode. Do this by clicking on the button labeled Administrator and choosing Expert Mode. This changes the layout of the monitor.

Figure 49

ALE-Application monitoring

The ST03N has a special feature build in for ALE monitoring, to use it you need to activate it by going to: Collector and performance DB Statistics records and file Online parameters Application statistics

The reason to use this particular tool is that you can detect if there are performance problems. If you can find a high database time then you proceed with a SQL trace and a high CPU time proceed with the ABAP runtime analysis SE30.


2004 SAP AG

43

Then another window is opened where you can choose AL ALE/IDoc statistics . Then save the setting. This actives the monitoring for the RFC functions: IDOC_INBOUND*, INBOUND_IDOC* and EDI_DATA_INCOMING. When these particular calls are made their statistics are summed up.

Figure 50

Also you need to make sure that in the corresponding instance profile the profile parameter stat/as_level is set to 1(meaning the application tracing is active, 0=not active). If there is ALE activity you can see if application statistics are being measured by checking the file called astat. Goto AL11 , choose the directory data.

Figure 51

If the application statistics collection works properly, you will notice that the file called astat will grow. It will grow according to how much data is processed. If there is no traffic then the file remains small. What happens, is that the Kernel writes the statistics into a file called STAT. The application statistics are written into the file called astat. In addition the Job RSSTAT87 is activated, and it writes the application statistics in the table MONI. From which the ST03N can display the data.

To see the ALE application statistics, you need to go to the appropriate application server. When you choose the sever another window will appear in the lower right hand side and then you choose the application statistics. Then you get to see following figure.


2004 SAP AG

44

Figure 52

Transaction STAD The STAT (until 4.5) or STAD (as of 4.6D) show you statistical record information. When you call the STAD you have to choose a time frame for the analysis. On the next screen you see a listing off all the statistical records for the choosen timeframe. You can then choose a RFC to analyse it further.

Figure 53

For example we have found a long running RFC. We are going to pursue it some more and see what details we can find out. When you double-click the appropriate line you get the following figure. Click on the RFC button, it will give more information on the RFC. As this was a server call, we can find out more information in the server colume.

For furhter information we would like to refer you to the SAP Course BC 315.


2004 SAP AG

45

Transactional RFC (SM58)

In this transaction you can find out if any tRFCs had problems. You choose the timeframe for which you want to see the information.

Figure 54

If you had problems with the tRFCs youll get a list, as seen below. You may decide to get more details for each tRFC by double clicking on the particular one.

Figure 55

If tRFC errors occur use program RSARFCEX to restart the tRFCs.

QRFC Monitor (SMQS) You can use the Outbound Queue Scheduler to register, deregister, and exclude destinations.

Figure 56

The setting Max Conn sets how many connections can be made to the destination system. Do not set this parameter too high, as it is possible that you can use up all the Dialog workprocesses on the destination machine. Thereby causing a performance problem.

In the figure below you can see the ratio of Dialog workprocesses to Dia WPs for RFC. In this case all the DIAs (except one) are useable by the RFCs.

Figure 57


2004 SAP AG

46

RFC Server resources (SARFC) In this transaction you can to see which application servers are able to handle RFCs and what level of resources are availbe for the RFC processing.

Figure 58

When you press the Select Group button then you get to choose which group you wish to have displayed. You maintain these groups in the RZ12. What you can see then is a listing of all servers in a group and their current workload.

Figure 59

When you click on a particular server you get its RFC settings. You have a option to change the settings of the server. These settings are only used untill you reset the server, at that time the profile parameters are used again. So if you change any parameters make sure to also change the profiles accordingly. We would like to refer you to SAPNote: 74141 for this.

Figure 60


2004 SAP AG

47

Tips and tricks with ALE/EDI In this section we wish to give a number of useful tips and tricks to help you optimize the IDoc processing. These suggestions are of course very general; a there is no way to cover all possible customer constellations.

Bundle Idocs where possible when sending and updating

This avoids problems with many little IDocs flooding the system

Avoid peak User times. Make the Idocs runnable as Batch jobs at low resource times. Avoid processing mode immediately whenever possible (sender and receiver)

It is always better to plan the IDocs at times when there are little to no users on the system. This avoids system resource contension. Schedule mass transfer/updates when there is low dialog activity. If that is not possible spread out the work load evenly over a larger time frame and limit the resources for IDoc processing.

Archive/delete IDocs and work items (error notifications and container linkage items) on a regular bas is

Reduced the overall database size.

Reorganize change pointers, audit database, serialization data and tRFC queue (if used)

Adjust the number of dialog work processes (sender and receiver). Use RFC server groups for parallel update and post IDocs in parallel

In systems with a high of IDocs processing, it has been shown to use special RFC application serves avoids the problem of overloading a User-applcation server. This can be done via defining a limited resources for the IDoc processing during the users working houres.

Set RFC resource parameters to avoid that all dialog work processes are occupied by tRFCs or aRFCs

This avoids the issue of users and IDocs contending for the same workporcesses.


2004 SAP AG

48

Archiving IDocs

Figure 61

IDocs, like most other SAP objects, need to be regularly archived. Otherwise they will unnecessarily use up diskspace. Setting up an archiving plan early in the implentation phase assures you of a well running system. This will reduce the size of the database consideralbly once the archvied objects are removed. It is always advisable to archive the IDocs that are not needed anymore out of the system to reduce the size of the database. Archiving is managed in transaction SARA, for the archiving object "IDOC". All archiving has two steps:

Archiving the objects (in this case the IDocs) into an archive file

Deleting the archived Objects out of the database

Up to SAP ERP version 4.5 links between an IDoc and the corresponding application document are stored as work items of type "C, which have to be deleted manually.

Starting with 4.6 the links are stored in table IDOCREL and can be deleted using report RSRLDREL. As of this release the links between IDoc and application log can be deleted with transaction SLG2.

Archiving has to be set up for all participating logical systems. Transaction SARA with object IDOC is used for archiving of tables:

EDI30C Intermediate document cluster (data records) from 3.0C

EDIDC Control record (EDI Intermediate Document)

EDIDOC EDIDOC EDI intermediate document cluster

EDIDS Status record (EDI IDoc)

The archiving program is called RSEXARCA. Program RSEXARCR can retrieve the archived IDOCs out of the archvie files. For SAP ERP release


2004 SAP AG

49

direct link to the IDOCs in the archiving program for the Workitems, you need to limit the range by using the creation date. If you are sure that you do not need the workitems any more you can delete them from the database with the reports RSWWWIDE and RSWWHIDE (see SAP Note 49545). Archiving of workitems is only supported since SAP ERP release 3.0D.

Especially when workflow is used you should reorganize the workflow tables and indices on the database level from time to time. This depends on the database used we refer yot to SAPnote 72873.

Change pointers in table BDCP have to be reorganized separately by program RBDCPCLR.

The TRFC queue should be reorganized from time to time as well using program RSARFC01.

ALE Monitoring

Documents

Transcript of ALE Monitoring