ALE Monitoring

ALE Monitoring
Best Practice for Solution Management
Version Date: July 2004

The newest version of this Best Practice can always be
obtained through the SAP Solution Manager
Contents
Applicability, Goals, and Requirements ....................................................................................................2
Introduction.........................................................................................................................................3
General overview of ALE/EDI.......................................................................................................3
Error Monitoring ALE/EDI...........................................................................................................10
Error Handling ............................................................................................................................27
Performance Monitoring.............................................................................................................35
ALE/EDI Interface Management 2
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. At least one person per
department will also be on the workflow lists for solving automatically detected problems in ALE/EDI.
The skills for this depend on the departments requirements; the agents need to have the appropriate
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 with regard 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 and secure transfer of IDocs.
2004 SAP AG
Introduction
In this paper 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 separated 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 which provides data to be
exchanged. This results in a unified interface for any EDI subsystem regardless of the SAP module,
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. IDocs can
2004 SAP AG
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 Contents Stored in Table
Control Record Technical information about the IDoc as a container EDIDC
IDoc number, IDoc type, Partner, Port, )
Status Records Information about the IDoc processing flow (IDoc status, date, EDIDS
time, error message, etc)
Data Records IDoc contents: application data (business information) EDID4
EDID3
EDID2
IDocs 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
erroneous attempts to post data are displayed in the tRFC monitor.
2004 SAP AG
Data flow
Figure 1
In general the data flow is.

1. An application creates an IDoc.
2. The ALE layer carries out 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
transferring:
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
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 information on this is available later in this document
Change pointers can also be created directly out of the application. They are stored in the 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 has successfully been
transferred on to the receiving system. In the figure below the green status indicates success and the
red ones indicate a problem or error.
2004 SAP AG
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
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
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
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 work items for the responsible person(s) are posted in the SAP-workflow
and are used to assign, track and process errors.
Monitoring Agents
Figure 6 Determination of selected agents
The Agents are persons in your organization, 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
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 carry this out 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.
If, on the other hand, the IDoc cannot 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 please refer to SAP Note 116610 - IDoc: Notifications from IDoc processing
and the Installation Guides.
2004 SAP AG
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, WE02, WE05, WE07 or BD87
Functional department
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 System administration SMQS goto qRFC
processes resources
Monitor the resource usage for aRFC System administration SARFC
Resource management for aRFC System administration RZ12
Create and Monitor Background job for System administration SM36 / SM37
reprocessable errors
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 slightly 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
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 analyze 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 that automatic monitoring always be used, 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
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.
The ALE monitoring tools are more helpful for a more in-depth analysis. 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
analyze the issue further.
2004 SAP AG
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 technical 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
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
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
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 (i.e. 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 batch job 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: <object name> 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
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 business process needs 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 Work item is
created for the person(group) specified in the report variant. They can then use the appropriate tools
to analyze the situation.
If you are using a WebAS version lower than 6.10 the report is RSEIDOCM, in WebAS 6.10 and
higher, the report is called RSEIDOCA. See SAP Note 361570 for more details.
2004 SAP AG
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
A confirmation 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 confirmation in an IDocs packet (rather than
individual IDocs ) periodically and schedule the sending of the packets in lowload times. A
confirmation has a special ALEAUD01 IDoc type with the 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
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 message types or partners.
Figure 17
Then start the tool with F8 (Execute).
Figure 18
2004 SAP AG
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 successfully 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 Syntax error 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 towards 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 Syntax error in IDoc (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 batch job is needed. It should be scheduled
regularly (SAP Report RBDMOIND).
2004 SAP AG
ALE Administration (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
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
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
Figure 24 Start screen BD22
Figure 25 BD22, result of a test run
SAPNote 513454 covers the topic of change pointers, administration and performance.
2004 SAP AG
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 available 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 proceed as
follows call SM58 and test the RFC connection. Maybe the network is down, or the receiving
system does not have any dialog work processes 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 scheduling 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
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 organizations. The SAP-Workflow triggers the
responsible persons to correct 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 IDoc ready to be sent to application.
64 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 readjust
your parameter settings (more on this in the following chapter)
Status If the processing of the inbound IDoc resulted in IDoc status
51 or 51 - "Application document not posted", or
63 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 You can manually correct the IDoc. Keep in mind that some IDocs must
edit IDoc 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
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 reprocess 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 further restrict the IDocs you wish to process in this screen. The execute button on top will
then start the processing.
If 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 chosen 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
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
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 little 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 purposes). This copy has either
status 33 (sender) or 70 (receiver). In addition to this the copy can not be processed!
The original 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
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
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 identify 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 implemented 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 and choose the appropriate IDoc you wish to
analyze. Pick the IDoc you wish to analyze and then click on its control record.
Figure 35 the IDoc and its control 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
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 necessary:
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
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 handled 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
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 analyze your business 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
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.
Activating the statistical collectors

It is possible that no RFC-statistics are stored, as it is possible to turn them off in the system. The
steps to reactivate the monitoring are different for 4.x and 6.x versions of SAP-ERP. Here we will
describe 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
For SAP ERP 6.x:

In all the mentioned sub screens 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
modified 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 modify all the settings which are divided amongst 3 different sub screens. From top
to bottom
Performance Database Reorganisation
Figure 43 Reorganisation screen
2004 SAP AG
In the Workload Collector pick the Control Data branch. In the following screen you can choose how
much data is stored on the local file system. Be aware that there is no exact information on how large
the files can get, so please make sure that you have enough disk space available for these logs.
Figure 44
In the next selection screen you can choose what data is stored in the system. SAP suggests
activating all the checks, but the RFC statistics is the minimum which should be activated.
Figure 45
2004 SAP AG
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
You can now sort the information according to function modules. They are called in a specific
sequence which is:
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 whether 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
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 see following figure.
2004 SAP AG
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 chosen timeframe. You can then choose a RFC to analyze it further.
Figure 53
For example we have found a long running RFC. We are going to examine it 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 column.
For further information we would like to refer you to the SAP Course BC 315.
2004 SAP AG
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
QRFC Monitor (SMQS)

In this monitor you can see how many dialog work processes are defined as RFC capable. This gives
you an indication of the possible load from RFCs on this system. If you have too many RFC capable
dialog work processes defined you might experience a resources bottleneck, as the users can not
connect to the application servers.
Figure 56
In the figure below you can see the ratio of Dialog work processes to Dia WPs for RFC. In this case all
the DIAs (except one) are useable by the RFCs.
Figure 57
2004 SAP AG
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 available for the RFC processing.
Figure 58
When you press the Select Group button then you get to choose which Logon group you wish to use
for RFC connections. You maintain these groups in the RZ12.
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 until 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. Please refer to SAPNote: 74141 for this.
Figure 60
2004 SAP AG
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 This avoids problems with many little IDocs flooding the system
when sending and updating
Avoid peak User times. Make the It is always better to plan the IDocs at times when there are little or no users
IDocs run as Batch jobs at low on the system. This avoids system resource contention.
resource times. Schedule mass transfer/updates when there is low dialog activity. If that is
Avoid processing mode not possible spread out the work load evenly over a larger time frame and
immediately whenever possible limit the resources for IDoc processing.
(sender and receiver)
Archive/delete IDocs and work Reduced the overall database size.
items (error notifications and
container linkage items) on a
regular basis
Reorganize change pointers, audit
database, serialization data and
tRFC queue (if used)
Adjust the number of dialog work In systems with a high of IDocs processing, it has been shown to use
processes (sender and receiver). special RFC application serves avoids the problem of overloading a User-
Use RFC server groups for application server.
parallel update and post IDocs in This can be done via defining a limited resources for the IDoc processing
parallel during the users working hours.
Set RFC resource parameters to This avoids the issue of users and IDocs contending for the same work
avoid that all dialog work processes.
processes are occupied by tRFCs
or aRFCs
2004 SAP AG
Archiving IDocs
Figure 61
IDocs, like most other SAP objects, need to be regularly archived. Otherwise they will unnecessarily
use up disk space. Setting up an archiving plan early in the implantation phase assures you of a well
running system. This will reduce the size of the database considerably once the archived 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 archive files.
For SAP ERP release <=3.1G see note 75756, for 3.1G note 104160 and for <=3.1H note 80485. In
general see SAP Note 40088 (How to delete without archiving).
The archiving frequency depends on the number of IDocs sent/received, usually once per month is
reasonable.
Even if you are not explicitly using workflow for the IDocs, ALE/EDI can create work items. Therefore
you have to archive or reorganize the work items. The archiving object is WORKITEM. As there is no
2004 SAP AG
direct link to the IDocs in the archiving program for the Work items, you need to limit the range by
using the creation date.
If you are sure that you do not need the work items any more you can delete them from the database
with the reports RSWWWIDE and RSWWHIDE (see SAP Note 49545).
Archiving of work items is only supported since SAP ERP release 3.0D.
You should reorganize the workflow tables and indices on the database level from time to time
especially when workflow is used. This depends on the database used. Please refer 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.
2004 SAP AG

ALE Monitoring

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ALE Monitoring

Uploaded by

Copyright:

Available Formats

ALE Monitoring

Best Practice for Solution Management

Version Date: July 2004

Applicability, Goals, and Requirements

Goal of Using this Service

Staff and Skills Requirements

Duration and Timing

How to Use this Best Practice

This paper is spilt into three basic sections.

The last section covers the performance issues.

General overview of ALE/EDI

The following functions and interfaces form the basis of communication:

EDI (Electronic Data Interchange)

IDoc (Intermediate Document)

be generated by three methods:

IDocs can be distributed by various means

In general the data flow is.

Figure 2 Outbound Data Flow

Status for IDocs in the outbound flow

Figure 3 Outbound Status Transitions

Status by the EDI subsystem:

Figure 4 Inbound Flow

Status for IDocs in the inbound flow

Figure 5 Inbound Status Transitions

Status by the SAP system (IDoc Basis):

Status by the SAP system (Applications):

Error Monitoring ALE/EDI

Figure 6 Determination of selected agents

Standard tasks for errors at ALE level.

Standard tasks for application errors.

You carry this out in transaction SPRO

Monitoring Responsibilities & Regular Tasks

Monitoring Tools for ALE/EDI

Figure 7 Solution Landscape Graph

Computer Center Management System (CCMS)

Figure 9 a monitoring set

Red: A problem or critical condition has been reported.

Figure 10 Initial BDMO

Figure 11 pressing create/activate

Figure 12 Activating the monitoring objects

CCMS_GET_MTE_BY_CLASS. For the parameters R3System and MTEClass, choose a proper

Reporting via RSEIDOCM or RSEIDOCA

Monitoring the Status of Inbound IDocs Using ALE Audit

Then start the tool with F8 (Execute).

The result of the query is seen above.

28 Error in ALE- Service

ALE Administration (BALE)

IDoc Lists (WE02)

Change Pointer Administration (BD22)

Figure 22 SALE where you can configure the change pointers

Figure 23 activating a change pointer

Figure 24 Start screen BD22

Figure 25 BD22, result of a test run

Error Handling in ALE Outbound Processing

Error Handling in ALE Inbound Processing

Reposting of IDocs in Status Error

Analyze the error situation.

Finding related objects

Figure 35 the IDoc and its control record

Figure 36 the display relationships button

Figure 37 Outbound service relationship

Figure 38 Inbound service relationship

Finding the IDoc via the tID

Settings and Issues in configuring ALE (RFC)