Workflow Administration

Administration
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_dimp50/helpdata/en/06/c0d3d0456bb54ca61c1021bb81afe0/content.htm
Created on October 06, 2016
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help
Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
2016 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP
SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are
provided by SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP
Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set
forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional
warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in
Germany and other countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 1 of 51
Table of content
1 Administration
1.1 IDoc Administration
1.1.1 IDoc Monitoring
1.1.1.1 IDoc Display
1.1.1.1.1 Edit Status Values
1.1.1.1.2 Edit Status Groups
1.1.1.2 IDoc Search
1.1.1.3 IDoc Statistics
1.1.1.4 Monitor IDoc Inbound Queue
1.1.1.5 Monitor IDoc Outbound Queue
1.1.1.6 Error and Status Processing
1.1.1.7 Active Monitoring
1.1.1.7.1 Schedule Monitoring Job (Example)
1.1.2 Archiving IDocs
1.1.2.1 Displaying or Changing Archivable Statuses
1.1.2.2 Archiving Functions for IDocs
1.1.2.2.1 Archiving and Deleting IDocs
1.1.2.2.2 Listing IDoc Numbers in Archive
1.1.2.2.3 IDoc Search
1.1.2.3 Archiving: Technical Background
1.1.2.3.1 Authorizations for Idoc Archiving
1.1.2.3.2 Archiving: Describing Standard Reports
1.1.2.3.3 Database Tables
1.1.2.4 Deleting Links with IDocs
1.1.3 Additional Settings
1.1.3.1 IDoc Administration: Global Parameters
1.1.3.2 Deactivate Links
1.1.3.3 Forward Inbound
1.1.3.4 Generating File Names
1.1.3.5 Checking Partners by Partner Type
1.1.3.6 Displaying an IDoc Using an XSL Stylesheet
1.1.3.7 IDoc Views
1.1.3.8 Queue Name Rules
1.2 Administration of ALE Functions
1.2.1 Monitoring Message Exchange
1.2.1.1 Central Monitoring Using the ALE CCMS Monitor
1.2.1.2 Status Monitor for ALE Messages
1.2.1.2.1 ALE Audit and ALE Tracing
1.2.1.2.1.1 Monitoring the Status of Inbound IDocs Using ALE Audit
1.2.1.2.1.1.1 Evaluating the Audit Database
1.2.1.2.1.2 Tracing IDocs System-Wide
1.2.1.3 Workflow Connection for ALE Functions
1.2.1.3.1 Error and Status Processing
1.2.2 ALE Customizing Data
1.2.2.1 Synchronizing Application Customizing Data Between Systems
1.2.2.2 ALE Basis Customizing Data
1.2.2.2.1 Converting ALE Basis Customizing Data
1.2.2.2.1.1 Specify Conversion Matrix
1.2.2.2.1.2 Conversion
1.2.2.2.2 ALE Basis Customizing Data Check Center
1.2.2.2.2.1 Technical Data of User System
1.2.2.2.2.2 Conversion of ALE Basis Customizing Data
1.2.2.2.2.3 Check Distribution Model
1.2.2.2.2.4 Check/Generate Partner Profiles
1.2.2.2.2.5 Check Communication Partner
1.2.2.2.2.6 Enhance Checks
1.2.3 Optimizing ALE Performance
1.2.3.1 Controlling IDoc Events
1.2.3.1.1 Scheduling IDoc Creation
1.2.3.1.2 Scheduling IDoc Transfer to Communication Layer
PUBLIC
Page 2 of 51
1.2.3.1.3 Scheduling IDoc Posting

1.2.3.2 Processing IDocs in Parallel
1.2.3.2.1 Creating IDocs in Parallel
1.2.3.2.2 Sending IDocs in Parallel
1.2.3.2.3 Posting IDocs in Parallel
1.2.3.3 Processing IDoc Packets
1.2.3.3.1 Creating IDoc Packets
1.2.3.3.2 Sending IDoc Packets
1.2.3.3.3 Posting IDoc Packets
1.2.3.4 Administration of IDoc Communication
1.2.3.4.1 Suppressing Background Processing
1.2.3.4.2 Setting Dispatch Status to Dispatch OK
1.2.3.4.3 Check the tRFC Status
1.2.3.5 Archiving and Reorganization
1.2.4 Serialization of Messages
1.2.4.1 Serialization by Object Type
1.2.4.2 Serialization by Message Type
1.2.4.3 Serialization at IDoc Level
1.2.5 Periodic Tasks
1.2.5.1 Change Pointer (Master Data Distribution)
1.2.5.1.1 Analyze Change Pointers
1.2.5.1.2 Reorganizing Change Pointers
1.2.6 Conversion of Logical Systems
1.2.6.1 Conversion of Logical Systems (as of SAP Web AS 6.20)
1.2.7 Converting Data between Sender and Recipient
1.2.8 ALE Recovery for Data Consistency
PUBLIC
Page 3 of 51
!--a11y-->
1 Administration
This section describes:
IDoc Administration
and
Administration of ALE Functions
!--a11y-->
1.1 IDoc Administration
The IDoc Administration comprises the following functional areas:
IDoc Monitoring
Archiving IDocs
Additional Settings (Customizing)
!--a11y-->
1.1.1 IDoc Monitoring

Use
You can easily and effectively monitor inbound and outbound processing of IDocs using special reports and graphic displays. An agent can also be notified
automatically using a workflow if an emergency occurs (active monitoring).
Features
The following tools are available for monitoring:
IDoc Display
All the other fields of the control record are available as selection criteria as well as partners and messages
- IDoc numbers
- Ports
- IDoc types
You can display a tree structure of the IDoc directly using the IDoc number. The IDoc list is displayed again if several IDocs are selected.
IDoc Statistics
The IDocs are sorted and represented graphically according to predefined status groups. Lists and individual IDocs can be displayed using mouse clicks.
IDoc Search
You can select IDocs according to their business content, that is, according to the data contained in the segments.
Error and Status Processing
Error and status codes are defined for the IDoc transfer. These codes can be assigned to a workflow task, which informs the agent automatically in a
procedure.
The final section explains Active Monitoring.
!--a11y-->
1.1.1.1 IDoc Display

PUBLIC
Page 4 of 51
Use
This report generates a list of individual IDocs or, if you have restricted your selection to one IDoc using the available selection criteria, the report displays the
relevant IDoc (for example, if you select only one IDoc number as a selection criterion).
Activities
The IDoc display is under SAP Menu Tools IDoc Interface/ALE Administration Monitoring IDoc Display Display.
Multiple IDocs
If a list of IDocs is displayed, double-click on the corresponding entry to access an individual IDoc.
A traffic light shows whether the current status is success or error, or a decision has not yet been made and further processing is required (yellow). You can
change the assignment of traffic lights to the Status groups in the transaction WELI. See also: Edit Status Groups
Individual IDocs
General information
The individual IDoc is displayed as a tree structure. The initial node is the IDoc number. The control record, data and status records are displayed as
subnodes. You can expand nodes and display individual records. You only have to click on data records.
By choosing
Displaying Relationships from the
Object Services you can display the objects that are already linked with the IDoc, for example, application
documents or the corresponding IDoc in the partner system in ALE distribution.
Control record
The control record displays, for example, the letter header (sender and recipient), direction and IDoc type. You can edit the control record in
Handling ( Control record Control/Change , see also the corresponding paragraph in the data records).
Exception
Data records
In the case of the data records, the segment name (E1 structures for SAP segments), segment number and short text are displayed. In the case of qualified
segments, the qualifier is displayed (the value which determines the significance of the segment).
In the case of segment E1EDKA1 (document header partner information), the qualifier PARVW = SH means that the partner specified in the
segment has the function of the goods recipient, while the partner function of the sold-to party is defined as PARVW = SP. The qualifier is the
first field in a qualified segment.
If you want to edit an incorrect IDoc in
Exception Handling, choose Data record Display/Change in the detail screen (double-click on
symbol for the
corresponding data record). You can now change all the fields. When saving, your IDoc assumes the new status 69 (IDoc edited) and you can then send it for
inbound processing again. The original is saved as a new IDoc with the status 70 (original of an IDoc, which was edited) in the database.
Status records
In the case of status records, the individual status values (status) are displayed with a short text. In the case of
Port type "tRFC" and status 03 the unique
transaction ID which is assigned to the tRFC is displayed. If the application writes an error log, the ID of the log is also displayed and can be used to access
the log (Goto Application log ). This allows you to display more detailed error information than the data in the status records.
!--a11y-->
1.1.1.1.1 Edit Status Values

Use
A processing status is assigned to an IDoc during processing (e.g. Status03: Data Transfer to Port OK ). These status values are in turn assigned to a higher
level status group (e.g. Output: IDoc Transfer Successful ). This assignment to a status group is referred to as Qualification . You can change the
assignment of status values to status groups in the Edit Status Values transaction.
Procedure
1. To edit the status groups, choose the ALE customizing transaction SALE Set-Up System Monitoring Set-Up IDoc Status Display Edit
IDoc Status Values (WE47).
A list of statuses which have been defined is displayed.
2. If necessary, choose
.
By double-clicking on the status that you wish to assign a different status group, the detail screen is displayed.
3. The status group is displayed in the Qualification field.
Use the F4 input help for an explanation of the numbers.
4. Select Save .
PUBLIC
Page 5 of 51
Status 25 (processing despite syntax error (outbound)) is assigned status group 1 = Outbound: IDoc generated". Replace 1 with 5 for
Outbound: IDoc Interface error".
!--a11y-->
1.1.1.1.2 Edit Status Groups

Use
IDocs are assigned to a Status Group , depending on their processing status (e.g. status group 2 = Outgoing: IDoc Ready to Send ).
In the IDoc display, these status groups are divided into 3 categories ( successful , error or not yet processed ), represented by green, red and yellow traffic
lights respectively. You can change the assignment of status groups to traffic light colors in the transaction Edit Status Groups .
Procedure
1. To edit status groups, choose the ALE Customizing transaction SALE Set-Up System Monitoring Set-Up IDoc Status Display Edit
Status Groups (WELI).
2.
3.
4.
Choose
or Table View Display/Change.
You can change
the group status ( successful / error/not yet processed ) in the Traffic Light Code column.
Save your entries.
Example
The traffic light color green (code 2) is assigned to the status group 3 (O utgoing: Sending IDoc ). You want to change the traffic light code for this status group
to 1 (yellow).
!--a11y-->

Use
Users should be able to find IDocs not only via the address information or control information in the control record but also according to the business data they
contain. You also want to be able to answer questions such as: Which IDocs contain purchase orders for my material XY?
The IDoc search function can be used to answer such questions. You can search for IDocs both in the database and in archive files.
Features
The function searches for character strings, that is, you must enter the value of a segment field as it appears in the field itself (avoiding full stops and commas
whenever possible).
You can enter a maximum of two values in two segment fields as selection criteria. If two values are entered, both must exist in the IDoc in the corresponding
segment fields for the IDoc to be included in the list of results (normal AND link in selection fields).
You can also choose to only give the value instead of the segment field. This means that all data records (more precisely: the field SDATA in the data
records) are searched for the character string, that is, the character string which is found may span several segment fields.
If you select Quick search mode , the search can be limited to a maximum of one hit in each IDoc, that is, the system terminates the search in the current
IDoc after one hit.
The search can and should also be restricted by entering additional search criteria which require values from the control record (in the same way as the other
monitoring programs): Creation time, partner and message, direction, and so on.
PUBLIC
Page 6 of 51
Activities
1. Choose the transaction WE09 ( SAP Menu Tools IDoc Interface/ALE Administration Services IDoc Search by Contents WE09).
2. Choose the Data Source button to specify whether you want to search for IDocs from the database or the archive (or both) .
3. If you have set the Archive flag, you can select files in the archive information system, or manually.
To be able to search in the archive information system, you must have

Deleted the IDocs from the database (complete archiving session)
Created an archive info structure in the central transaction SARA
4. Specify all available selection parameters, to restrict the IDoc search as far as possible.
!--a11y-->
1.1.1.3 IDoc Statistics

Use
The IDocs are sorted for statistical purposes by processing status. The categories shown in the table below are used here. Only those IDocs whose status
has change within a defined period are selected.
IDoc statistics error categories
Outbound
Inbound
Error
Error
Error resolved
Error resolved
Flagged for deletion
Flagged for deletion
By double-clicking on individual groups you can see more details: When you double-click on an error category, for example, the list of relevant IDocs is
displayed and when you double-click on an individual IDoc, a tree structure of the IDoc is displayed.
Features
The following selection criteria are available on the tab pages for statistics:
Standard offer
Here you can define a time interval for the status changes and set the following indicators:
Error history
If this indicator is set, the IDocs with an error status and when this was is given. The status records are also evaluated.
Test IDoc evaluation
If this indicator is set, the system outputs which IDocs were generated with a test tool. This test status was written for all IDocs that were generated
in an SAP Release from 4.6A using the transactions WE19, WE12 or WE16.
Detail selection
Here you can determine additional restrictions such as the message type.
Activities
Start the statistics with SAP Menu Tools IDoc Interface/ALE Administration Monitoring IDoc Display Statistics . From here you can
branch to the individual analyses.
!--a11y-->
1.1.1.4 Monitor IDoc Inbound Queue
PUBLIC
Page 7 of 51
Use
If you receive IDocs by qRFC, this function can monitor the inbound queue and react to any errors which occur.
Prerequisites
You post inbound IDocs with qRFC.
Features
This monitoring function displays the elements in the inbound queue:
Display sender
Selected queues
IDoc number
IDoc status
Link to IDoc display
You can make the following changes to a queue:
Flag IDocs for deletion
Delete IDocs from the queue
Start a queue
Activities
1. Choose Tools IDoc Interface/ALE Administration Monitoring Troubleshooting Monitor IDoc Inbound Queue (transaction
WEINQUEUE), to go to the inbound queue monitoring.
2. Select the IDocs or queues which you want to monitor, using the specified selection parameters.
3. If an IDoc in a queue has an error status, select it and go to its detail view with the Display IDoc button, to determine the cause of the error, and
resolve it.
4. If you cannot correct an IDoc with error status, you can delete it from the queue with the Delete IDoc from Queue button.
5. To edit a queue, select the queue name and choose Start Queue .
!--a11y-->
1.1.1.5 Monitor IDoc Outbound Queue

Use
If you send IDocs by qRFC, this function can monitor the outbound queue and react to any errors which occur.
Prerequisites
You send IDocs with qRFC.
Features
This monitoring function displays the elements in the outbound queue:
Recipient port
Selected queues
IDoc number
Link to IDoc display
You can make the following changes to a queue:
Flag IDocs for deletion
Delete IDocs from the queue
Start a queue
PUBLIC
Page 8 of 51
Activities
1. Choose Tools IDoc Interface/ALE Administration Monitoring Troubleshooting Monitor IDoc Outbound Queue (transaction
WEOUTQUEUE), to go to the outbound queue monitoring.
2. Select the IDocs or queues which you want to monitor, using the specified selection parameters.
3. If queue problems occurred in transmission, you can select IDocs and go to their detail view with the Display IDoc button, to determine their status.
4. You can remove IDocs from the queue with the Delete IDoc from Queue button.
5. To send a queue, select the queue name and choose Start Queue .
!--a11y-->

Use
In the IDoc Administration, you can assign a procedure to a workflow task error or status code.
With the Error and Status Processing function, you can check the assignment of the error procedure codes tothe standardtasks, if you have used EDI
communication in an earlierversion.
You must also maintain this assignment for your user developments.
Example
Code Type ID Description
EDIX 2 TS0008070 ALE/EDI: Syntax error (Outgoing)
Activities
Check whether the assignment matches the table listed below.
1. Choose SAP Menu -> Tools -> IDoc Interface/ALE -> Administration -> Runtime Settings -> Error and Status Processing ( transaction WE46).
2. Perform the function. The table must contain the ALE error handling entries listed below:
Code
Task
Description
Type
EDII
TS00008068
ErrorProcInb
EDIO
TS00007989
ErrorMessage
EDIP
TS60001307
idocpaket
EDIX
TS00008070
SynErrorOut
EDIY
TS00008074
SynErrorInb
EDIM
TS00007988
ErrorMessage
The table contains the assignment of the error procedure codes (e.g. EDII) forstandardtasks (e.g. TS00008068).
The procedure type is 2 (work item).
Notes
If you used EDI in an earlier version, standard tasks ofthe old versions are still assigned here for the procedure codes EDII and EDIO. If the new tasks are not
entered here, there may be ALE Processing problems.
See also:
Exception handling
Status processing
Procedure codes
Troubleshooting
!--a11y-->
PUBLIC
Page 9 of 51
1.1.1.7 Active Monitoring

Use
This report automatically informs the agents responsible if too many incorrect IDocs are found.
Integration
Active monitoring is not used for processing or reimporting of an incorrect IDoc. Exception handling of every incorrect IDoc is responsible for this.
Activities
You plan the report to run regularly with a variant. The variant also informs the report of the status values to be selected: If the critical status contains more
IDocs than specified in the critical number of IDocs, a message is sent to a predefined recipient.
The recipient receives the notification in the form of a work item displayed in their Business Workplace. If they execute the work item, the IDoc statistics are
displayed with the values determined at the time of evaluation. The agent can display the current status of these IDocs using the Refresh function. The
selection criteria which led to the notification are also used for this evaluation.
An important customer orders goods using EDI on working days, between 8am and 6pm. These goods are to be delivered at 4pm the next day.
To ensure that the delivery is made on time, the ordered quantity must be recorded by midday on the day of delivery. The active monitoring
function is to be used at 8am every morning to determine whether there are any orders which could not be processed automatically. The report,
therefore, is started at the same time every day and 0 is selected as the critical number of IDocs. The agent responsible is notified if any
incorrect IDocs are found and can then manually process the outstanding orders by midday.
For more information see
Schedule Monitoring Job (example)
!--a11y-->
1.1.1.7.1 Schedule Monitoring Job (Example)

Prerequisites
The following refers to the example in the section
Active monitoring . The active monitoring report is to be started as a background job every morning at 8am, to evaluate the IDocs which were received
between 8am and 6pm on the previous day.
Procedure
Enter the
RSEIDOCA report in the BAP Editor, select Variants , and choose
Give your variant a name and choose
Enter the following parameters:
Display .
Create .
Recipient type
:
US (user)
Recipient of notification,
for example
SMITH
Start time
or End time before batch run : 1 Day and 0 Days 14:00:00h
Critical
number of IDocs : 0
Status
: 51 , 56 and 64
Logical
message type : ORDERS
Partner parameter (here sender): <corresponding values from the partner profiles of the customer>
1. Choose
Continue to enter a short text for your variant. Save your entries.
2. To schedule your job as a background job, choose System Services Jobs
PUBLIC
Page 10 of 51
Job Definition and enter B (medium priority for periodic jobs) as the job class.
Select
Start condition and enter a date and
08:00 as the start time.
Choose Execute job periodically .
Choose Period values
Daily and save your entries.
Enter the scheduled report again when saving (RSEIDOCA) and the variant that you maintained.
Result
IDocs selected during the daily run of the background job will now be:
Those which were received between 8 am and 6 pm on the previous day
Those which have the logical message type
ORDERS
Those received from the relevant customer
An IDoc from status
51 , 56 or 64 must be assigned now to ensure that a notification is sent to the user SMITH.
!--a11y-->
1.1.2 Archiving IDocs

Use
IDocs are stored in several database tables. To keep these tables (and access times) small (to reduce the database load), without losing any IDocs, you can
archive the IDocs at operating system level. These archives can then be moved to external storage media, such as disks (using ArchiveLink) or magnetic
tape.
Prerequisites
In Customizing, you specify where the archive files are located physically (that is, which storage media are used). For more information, see
Application Components (CA) Archiving Application Data Introduction to Data Archiving Customizing .
Cross-
Activities
Displaying or changing the archivable status
When can I archive IDocs?
Archiving functions for IDocs
How are IDocs written to and read from archive files?
Make sure that you do not archive IDocs that may still be needed by the application.
Deleting Links with IDocs
When do I delete IDoc links (for example, with application documents?
Archiving: Technical Realization
How does archiving work from a technical perspective?
See also:
Archiving Application Data
General archiving information
!--a11y-->
Displaying or Changing Archivable Statuses

Certain IDoc statuses are classified as archivable in the standard system, while others are not. You can display or change this classification.
The current status of an IDoc must be archivable before the IDoc can be archived.
Procedure
1. Choose the ALE customizing transaction SALE Set-Up System Monitoring IDoc Status Display Edit IDoc Status Values (WE47).
2. To change entries, choose
.
3. Select the required status.
By double-clicking you can call a detail screen, in which you can display or change the archivability.
PUBLIC
Page 11 of 51
4. By using
or
you can display or change all statuses one after another.
!--a11y-->
1.1.2.2 Archiving Functions for IDocs

Use
Data is usually archived via the central transaction SARA. In the case of IDocs, the corresponding tables are addressed via the archiving object IDOC.
Features
Various processing methods are assigned to the archiving class IDOC: In the standard system, therefore, IDocs can be
Archived
Deleted from the database
Retrieved from an archive: From the initial screen choose Goto Retrieve
All of the IDocs generated by sales orders (message type ORDERS, IDoc inbound processing) in the month of January are to be archived and
subsequently deleted from the database tables. To do this, choose the "Archive" processing method in the standard system and enter a time period and
message type as report variants.
In addition, you can display the following:
Archive
Several IDocs are usually archived in one archive or archiving session, that is, the IDocs are grouped together in one session. An archiving
session is complete when the IDocs have been deleted from the database tables and exist only as archive files.
The IDoc numbers of one or several archives or archive files
The IDocs (that is, control record, data- and status records) of one or several archives
IDocs from archives, that contain certain character strings (IDoc search)
This function is not an archiving object IDOC method, but rather an IDoc interface monitoring tool and hence only available from the initial node.
Activities
You can also access the central transaction SARA by choosing Tools Administration Administration Data Archiving . Here you enter the
archiving object IDOC. When you select 'enter' the methods entered above are displayed for selection.
You can determine the
Maximum size of the archive files in
Object specific Customizing , and the table entries should be deleted immediately after generation of archive
files from the database. With large datasets this can improve the performance.
In the standard system, the IDocs are selected for archiving according to certain criteria, for example the time at which the IDocs were last changed (new
status record). You can also define your own selection criteria. For more information, refer to the section
Archiving: Technical Implementation
!--a11y-->
1.1.2.2.1 Archiving and Deleting IDocs

Prerequisite
The IDocs to be archived have an archivable status.
Procedure
1. Go to the central archiving transaction with SAP Menu Administration System Administration Administration
Data Archiving
( transaction code SARA) .

If necessary, check the
object specific Customizing:
Here, for example, you can set the indicator "detailed statement in the variant to the deletion program: This can be entered in the archiving log of each
individual IDoc which is archived. However, this can lead to very large logs which do not necessarily contain useful information.
2. Enter the archiving object IDOC and choose the required action, here
Write (= Archive) .
A warning will be displayed if some of the archiving sessions for the archiving object IDoc are still incomplete.
run the risk of possibly archiving some IDocs twice.
You can ignore the warning but you then
3. Define the
start date of the archiving session and the
spool parameters (print output).
The traffic lights should now be green, indicating that these parameters have been maintained. Please note that you can set the archiving mode for the
print output to Store Only and therefore avoid printing every individual archiving log. Enter the object type IDOC as the attachment parameter and use the
F4 Help to select a suitable document type for the object type. Also enter a free text as Additional information for the archiving report.
4. Choose
Maintain to create a report variant. As selection parameters, enter the message type and a time period within which the IDocs received their
last, current status.
PUBLIC
Page 12 of 51
5.
You can specify whether you want to perform this variant as Test or Production , in the Process Flow segment of the selection parameter screen.
If you choose Test, you get statistics of the processed IDocs . For a detailed log, select Detailed Log .
6. Choose
Continue and save your variant.
7. Return to the archiving screen and choose

.
If you selected immediately in step 3, the message New archiving job was generated is displayed in the message bar at the bottom of the screen.
8. You can check whether your archiving session is complete by selecting Job overview . If you choose Administration , an overview of the completed and
incomplete archiving runs is then displayed. If IDocs which match your selection parameters were found in the database tables, your archiving session is
displayed as a folder full of archive files.
9. If not
defined differently in object specific Customizing, your IDocs are still located in the database after archiving, that is, your archiving session is not
yet complete. To delete the IDocs, you must schedule a deletion job with the appropriate variant. Choose the archive file from which the IDocs are to be
deleted from the database.
!--a11y-->
1.1.2.2.2 Listing IDoc Numbers in Archive

Choose Evaluate in the initial screen of the central archiving transaction .
Choose Execute.
The system displays the complete archiving sessions.
Select one or several sessions or files contained within and confirm your selection.
A list of IDocs from the archive files selected is displayed. As well as the IDoc number, the "logical" message, for example, is output (output fields of
report
RSXARCR)
!--a11y-->

Use
Users should be able to find IDocs not only via the address information or control information in the control record but also according to the business data they
contain. You also want to be able to answer questions such as: Which IDocs contain purchase orders for my material XY?
The IDoc search function can be used to answer such questions. You can search for IDocs both in the database and in archive files.
Features
The function searches for character strings, that is, you must enter the value of a segment field as it appears in the field itself (avoiding full stops and commas
whenever possible).
You can enter a maximum of two values in two segment fields as selection criteria. If two values are entered, both must exist in the IDoc in the corresponding
segment fields for the IDoc to be included in the list of results (normal AND link in selection fields).
You can also choose to only give the value instead of the segment field. This means that all data records (more precisely: the field SDATA in the data
records) are searched for the character string, that is, the character string which is found may span several segment fields.
If you select Quick search mode , the search can be limited to a maximum of one hit in each IDoc, that is, the system terminates the search in the current
IDoc after one hit.
The search can and should also be restricted by entering additional search criteria which require values from the control record (in the same way as the other
monitoring programs): Creation time, partner and message, direction, and so on.
Activities
1. Choose the transaction WE09 ( SAP Menu Tools IDoc Interface/ALE Administration Services IDoc Search by Contents WE09).
2. Choose the Data Source button to specify whether you want to search for IDocs from the database or the archive (or both) .
3. If you have set the Archive flag, you can select files in the archive information system, or manually.
PUBLIC
Page 13 of 51
To be able to search in the archive information system, you must have

Deleted the IDocs from the database (complete archiving session)
Created an archive info structure in the central transaction SARA
4. Specify all available selection parameters, to restrict the IDoc search as far as possible.
!--a11y-->
1.1.2.3 Archiving: Technical Background

The IDoc archiving tools were developed with the
Archive Development Kit (ADK), which supports object-oriented programming methods. This has led to the use of archiving object IDOC, which contains
the necessary database tables and the archiving class IDOC, which has the function modules required for processing.
The archiving object IDOC is accessed "from outside" using reports which (indirectly) call the ADK function modules. The selection parameters for these
reports are configured in the variant maintenance function for the central archiving transaction. The ADK function modules, in turn, use the function modules
from archiving class IDOC to access the database tables. The figure below illustrates this object-oriented structure.
All the function modules in the archiving class "IDOC" belong to the function group "EDIA". This group also includes the function modules which the archiving
programs use to call the ADK functions.
In computer literature, data and the corresponding functions are sometimes combined in "classes" (for example, in C++). Here this would refer to
the "archiving object" which contains the data (the lines in the database table), as well as the "archiving class" IDOC, which contains the
corresponding functions.
The reports supplied with the standard system can be used as sample reports to write your own reports with selection parameters which meet your
requirements. For more information on Standard Reports see
Archiving: Description of Standard Reports
!--a11y-->
Authorizations for Idoc Archiving
Use
You need only the
general archiving authorization.
PUBLIC
Page 14 of 51
!--a11y-->
1.1.2.3.2 Archiving: Describing Standard Reports

The following section contains information about the "initial reports" and the function module which they call from the function group EDIA. This function
module, in turn, calls the ADK standard class function modules. The reports are addressed by the central archiving transaction SARA.
In order to address programs through the central archiving transaction SARA, you must replace the Standard Reports through the programs in transaction
AOBJ.
Name
Description
Selection parameters
RSEXARCA
Writes IDocs to the archive. Calls

EDI_ARCHIVE_IDOCS. Uses the subroutine
INITIALIZE_STATUS_QUALITY (function group
EDIA) to check whether the IDocs can be archived.
RSEXARCD
Deletes archived IDocs from the database. Calls

EDI_DELETE_ARCHIVED_IDOCS.
Archive files from incomplete archiving sessions
RSEXARCR
Reads IDocs from an archive. Calls

EDI_READ_IDOC _ARCHIVE. Displays the
following control record fields for each IDoc:
Archive files from complete archiving sessions
Time at which the control record was last

changed
Time of IDoc creation
Current status
Logical message
Direction
IDoc number
Partner
Logical message
Status
Date and time at which the control record for
the IDoc was last changed
Direction
IDoc number
RSEXARCL
Retrieves IDocs from the archive into the database. Archive files from complete archiving sessions
Calls EDI_RELOAD_IDOC _ARCHIVE. Checks for
client or IDoc number conflicts via
IS_RELOADING_POSSIBLE (subroutine for
function group EDIA). Writes the new status "35"
for outbound IDocs, "71" for inbound IDocs
("reloaded"). "Detailed statement" indicator as for
RSEXARCA.
RSEXARCI
Creates index in table EDIDOCINDX. Calls ADK

function module directly.
None: Reads the archive files of the IDOC object

class.
RSEXARCJ
Removes index in table EDIDOCINDX. Calls ADK

function module directly.
Date, up to which the indexes should be deleted.

Number of records, after which a database commit
should be transmitted.
!--a11y-->
1.1.2.3.3 Database Tables
Definition
The IDOC archiving object consists of the following IDoc database tables:
Table
Description
EDIDC
Contains the IDoc control record
EDID4
Contains the IDoc data records
EDIDS
Contains the IDoc status records
!--a11y-->
1.1.2.4 Deleting Links with IDocs
PUBLIC
Page 15 of 51
Use
As the IDoc number increases, only the data records table gets bigger. The tables which contain links with application documents, for example, also get bigger
and from time to time should be emptied of obsolete entries.
IDocs links are always archived with them.
Procedure
1. Start the RSRLDREL program.
2. Enter a suitable end date .
The end date is suitable if all links that were generated before are no longer needed. For example, if you have already archived and deleted all IDocs before
this date and the application documents are also archived, you no longer need the corresponding links (exception: Application documents and IDocs are to be
retrieved from the archive into the SAP System).
3. Select Selection using link type and enter a link type. Also refer to the table below.
Alternatively, you can execute the selection by choosing Object/Function . If, for example, you want to delete all links with standard orders, then you should
make your selections according to object type BUS2032 (standard order) in the function APPLOBJ.
If you want to trigger the following links...
Then you must choose the link type...
Application document with outbound IDoc
IDC0
Inbound IDoc with application document
IDC1
Outbound IDoc with application document in the target system
IDC9
Inbound IDoc with application document from the front-end system
IDCB
Inbound IDoc with communication IDocs in distributed systems
IDC2
Copy of an IDoc with its original
IDC3 (inbound), IDC7(outbound)
Inbound IDoc with outbound IDoc from the front-end system
IDC4
IDoc with TID ( port type tRFC, ALE audit). Does not work with deletion
criterion Both objects not available !
IDC8 (inbound), IDCA (outbound)
Outbound IDoc with reference IDoc (type IDCREF01)
IDRF
You want to delete links last. Choose Both objects not available . If now, for example, only the application document is available, you can actually
display the numbers of the linked IDocs from the document, but no longer the IDocs themselves.
This option does not work for links with TIDs (for ALE audit) although they appear to be there.
You want to delete the links if at least one of the two objects is no longer there (option one object not available ). Then, for example, you can no
longer display the numbers of IDocs that have already been deleted from an application document.
You generally want to delete all links that meet the other selection criteria. Select Without Existence Check .
You can perform a Test run . Then the system only notifies you of the number of links that meet the selection criteria, but does not delete these.
!--a11y-->
1.1.3 Additional Settings

Use
The following functions contain presettings, which are usually made in customizing. These settings are not usually changed during daily business.
Features
IDoc Administration in Customizing
Deactivate Link
Forward Inbound
Generating File Names
Editing Partner Types
Displaying an IDoc Using an XSL Stylesheet
IDoc Views
PUBLIC
Page 16 of 51
!--a11y-->
IDoc Administration: Global Parameters

Use
The global system parameters are important IDoc administration default values. They are set in Customizing.
Features
System parameters for example are:
The IDoc administrator , which is notified in exception handling. If necessary it is overwritten with special entries in the partner profiles. For more
information, see
Rule resolution in exception handling.
The system environment : It describes the functions with which the IDoc Interface can operate: The applications or the Message Control.
The maximum number of logged errors before exception handling is started after the syntax check. You can assign the syntax check in the partner
profiles of
Outbound processing or
Inbound Processing.
Whether errors when importing status files should lead to work items ( "warnings ).
Activities
The system parameters are displayed or maintained in customizing or in the ALE customizing transaction SALE Basic Settings IDoc
Administration (transaction OYEA)
. You can choose
!--a11y-->
Deactivate Links
Use
Incoming and outgoing IDocs are usually linked to other relevant documents, so that you can easily identify all documents for a process if an error occurs. If
you do not need these links in some cases, you can deactivate them. This minimizes the amount of data saved in the IDoc processing.
Features
You can deactivate the following types of link:
IDC0
Outgoing document linked to outgoing IDoc
IDC1
Incoming IDoc linked to incoming document
IDC2
Incoming IDoc linked to Communication IDoc
IDC3
Incoming IDoc linked to Original IDoc after editing
IDC4
Incoming IDoc linked to outgoing IDoc in source system
IDC7
Outgoing IDoc linked to Original IDoc after editing
IDCB
Incoming IDoc linked to outgoing document in source system
IDC9
Outgoing IDoc linked to incoming document in the target system
You can deactivate the writing of link types for all message types, or only for selected message types.
Restrictions
You can not deactivate links if you need them later to reconstruct a document flow. If, for example, you want perform an ALE Audit for a message type,
you cannot deactivate the link (link type IDC4) for this message type.
You cannot deactivate links below the message type level. For example, you cannot deactivate a link for the message type ORDERS only for some sender
systems. You can only deactivate this link for all IDocs of message type ORDERS.
Example
Deactivating links can be useful in the following cases:
PUBLIC
Page 17 of 51
IDocs from external systems without IDoc management

If the sending system has no IDoc management, the number assignment to outgoing IDocs of this system is ambiguous. Links to the incoming IDoc
would therefore be meaningless.
Bulk processing of master data
If an error occurs during bulk processing of master data, the entire process, not individual IDocs with errors, is repeated. You do not need to link individual
IDocs in this case.
Activities
Choose SAP menu Tools IDoc Interface/ALE Administration Runtime Settings
WENOLINKS).
1.1.3.2 Deactivate Links (transaction code
1. If you want to completely exclude a link type, select the type under Not Excluded Link Types , and choose
2. If you want to no longer exclude a link type, select the type under Excluded Link Types , and choose
Move Link Types.
Move Link Types.
3. If you want exclude a link type only for some message types, select the type and choose
Exclude Message Type . Enter the name of the message
type in the following dialog box. Repeat this procedure for all message types for which you want to exclude the link type.
4. To reverse step 3, select the message type and choose
No Longer Exclude Message Type.
!--a11y-->
1.1.3.3 Forward Inbound

Use
Specify a job as a logical address for forwarding the data from an inbound IDoc or from a status confirmation.
Integration
At present, inbound forwarding is only used for internal invoices (application V3 = billing, SD module - Sales and Distribution ).
Activities
Maintain the addresses in th e transaction WE45 (Forward Inbound Processing) .
The logical address must correspond to the address in the IDoc control record (field SNDLAD = logical address of sender or field RCVLAD = logical address of
recipient).
Processing in internal clearing is identified using
forwarded to the logical address.
Outbound Process Code SD08. In processing, an inbound IDoc is created from the outbound IDoc which is
!--a11y-->
1.1.3.4 Generating File Names

Use
The function modules which generate a file name when IDocs are exchanged using a file port are stored here. These function modules are displayed as a
list of possible entries (F4) when you create a file port. The standard system already contains some examples of such function modules. You can store your
own function modules here.
Activities
You maintain the function modules in the ALE customizing transaction SALE Communication File Name
Generation Function Modules (WE55) .
The function module must return directory and file as a character string. It can transfer the directory from the port definition (as the standard
modules do), but does not have to.
PUBLIC
Page 18 of 51
!--a11y-->
1.1.3.5 Checking Partners by Partner Type

Use
While you are editing the partner profiles, the system checks whether master data exists for the specified partner or whether the specified partner is of one of
the following types
SAP user (partner type US)
Bank
Logical system
The check programs and access programs for the individual partner types are stored in this table. Check routines for all partner types are supplied with the
standard system.
Activities
You maintain the programs in the ALE customizing transaction SALE Model and Implement Business Processes Partner Profiles Edit Partner
Types (WE44).
Enter the following parameters if you wish to change the default check routines or create new partner types:
Partner type (for example KU for customer, LI for vendor, US for SAP user)
Report (for example RSETESTP)
Form routine (for example READ_KNA1 - customer master record is read)
!--a11y-->
Displaying an IDoc Using an XSL Stylesheet

Use
You can represent IDocs in XML format individually (how you generate the Business Connector, for example) by means of a stylesheet. You can test the
stylesheets by performing the steps specified below. The ED00_XML process code displays a generic, manual inbound processing.
Prerequisites
You have put your stylesheet together with the graphics on the presentation server or in the Web Repository (transaction SMW0). In the Web Repository,
graphics are identified as binary objects and stylesheets are identified as HTML templates.
Activities
1. Choose SAP Menu Tools IDoc Interface/ALE Development IDoc Generate ALE Interface IDoc Styles (WE34) .
2. Identify your stylesheet and the graphics using a Style ID . See the F1 Help for the fields. Assign the style ID to the required message type.
3. Maintain an Inbound Partner Profile for the required message type. For the process code select ED00_XML. Assign yourself as the permitted agent .
4. Generate a test IDoc of the required message type, for example with the
Test Tool and start processing.
5. You receive a work item in the Business Workplace - when you execute it you receive the XML display of the IDoc.
You can select other stylesheets by using View .
6. Exit the work item by selecting Edit . Here you can also set the Deletion indicator with which the IDoc receives an
Status.
Archivable (and thus deletable)
!--a11y-->
1.1.3.7 IDoc Views

Use
PUBLIC
Page 19 of 51
IDoc types can be used for more than one message, that is, for more than one business process. As a result, the IDoc types usually contain more segments
than necessary for the individual application cases. To improve performance when generating IDocs, you can use views to ensure that only the segments
relevant to the current business process are filled with data. Views are therefore only important for IDoc outbound processing.
Integration
The application must support this function: The program which writes the application data in the IDocs must carry out the following tasks:
Determine from the partner profiles whether a view exists. To determine this, the function module EDI_PARTNER_READ_OUTGOING is called.
Query, which segments belong to the view. The function module EDI_VIEW_READ is called once, which returns the segments in a table.
Query, whether the current segment should be maintained in the current view. The table returned by EDI_VIEW_READ is used.
For a list of IDoc Interfaces that support IDoc views, see SAPNet Note 185445.
Prerequisites
You must have IDoc development authorization (authorization object S_IDOCDEFT, for example in the role SAP_BC_SRV_EDI_DEVELOPER) before you can
define a view.
Activities
1. To define a view, choose the ALE customizing transaction SALE Model and Implement Business Process Configure Master Data Distribution
Specify Scope of Data to be Distributed IDoc Views (WE32) . Enter a name for the view and choose
.
2. When the next screen appears, assign a message type (logical message) and a basic type to the view (the assignment of an extension to the view is
optional). This assignment is checked in the partner profiles.
3. Position the cursor on a segment, which is to be included in the view. Choose
a. Qualified segments
b. Mandatory segments
4. Save your entries.
5. In the partner profiles (
. The following segments must be included in the view:
General outbound processing), enter the view for the corresponding combination of partner and message.
!--a11y-->
1.1.3.8 Queue Name Rules

Purpose
If you want to ensure that IDocs sent are posted in the same sequence in the recipient system as they were sent, you can specify that a particular message
type is sent, with qRFC (queued RFC), in the partner profile (transaction WE 20). When you send by qRFC, the IDocs are first put in an outbound queue in the
sending system, and then in an inbound queue in the recipient system. You can assign IDocs to various queues and specify queue name rules.
Prerequisites
You have a function module which creates queue names.
Process Flow
To specify queue name rules:
1.
2.
3.
4.
5.
Choose Tools IDoc Interface/ALE Services Sequence Sequence by qRFC qRFC Rules (transaction WE85).
Switch to change mode ( Display -> Change button).
Choose New Entries .
Specify a name and the associated function module for each rule.
Save your entries.
Example
The function modules IDOC_QUEUE_CONST_EDIQUEUE and IDOC_QUEUE_NAME_MESTYP, which are delivered by SAP with the transaction WE85,
are simplified examples of queue names:
IDOC_QUEUE_CONST_EDIQUEUE is a specified queue name constant.
IDOC_QUEUE_NAME_MESTYP creates the queue names from part of the logical message type name.
These examples are deliberately simple, and are a template for creating your own function modules.
PUBLIC
Page 20 of 51
!--a11y-->
Administration of ALE Functions
Purpose
Application Link Enabling provides a range of administration tools:
Monitoring IDoc Processing and tRFC Communication
Transport Customizing Data from Maintenance Systems into Recipient Systems
Optimize ALE Performance
Serialize Messages
Periodic Master Data Distribution (Change Pointer)
Convert Logical Systems (Assign Unique System Names)
Convert Data between Sender and Recipient
Recover Data (Point-In-Time Recovery) in ALE Systems
The ALE administration functions are under SAP Menu Tools IDoc Interface/ALE Administration
There are some references to customizing (IMG) settings. The ALE-specific part is under transaction SPRO SAP Reference IMG
SAP Web Application Server IDoc Interface/Application Link Enabling (ALE) .
In the sections below you will find general information, step-by-step procedures and information about the settings required in Customizing for ALE. ) Here you
will also find information on the settings required in Customizing.
!--a11y-->
Monitoring Message Exchange

In ALE Administration you can use various tools to monitor Messaging.
You can display an overview of the communication and the processing status of IDocs.
You have to make the settings required for monitoring in the ALE IMG (transaction SALE).
The sections below contain details of the procedure:
Central Monitoring with the ALE CCMS Monitor

Status Monitor for ALE Messages
Workflow Connection for ALE Functions
!--a11y-->
Central Monitoring Using the ALE CCMS Monitor

Use
The CCMS Alert Monitor enables you to monitor several R/3 Systems in an ALE integrated system.
The alert monitor gives you an overview of the following SAP System performance attributes which are important for ALE:
IDoc change pointers

Processing of outbound IDocs
tRFC queue
Processing of inbound IDocs
PUBLIC
Page 21 of 51
You can monitor any number of SAP systems from one system. The number of systems that can be monitored is, however, restricted by technical factors,
such as the speed of the network and the level of traffic in the network. From our experience such restrictions only present a problem in very large integrated
systems.
Integration
The ALE monitor sets up a connection to the CCMS monitoring. Data suppliers provide the CCMS identification numbers. These data suppliers are integrated
in the CCMS (by Customizing).
ALE monitoring objects are defined in the ALE Customizing.
Prerequisites
You have defined ALE monitoring objects in the IMG (transaction SALE Set-Up System Monitoring Central Monitoring of all Systems ALE
Monitor Objects (BDMO) ).
For analysis purposes, ALE monitoring objects form a group of associated selection options based on IDoc attributes.
Individual objects are assigned values based on the current system status and the assignment of selection options from IDoc attributes.
When the status of the current system is determined, one of the following cases applies:
The monitoring object is located in the same client A function module is called locally In this case no further Customizing settings are required
The monitoring object is located in the same physical system but in a different logical system (client):
In this case you have to assign an RFC destination with a dialog user to the message type SYNCH in the current client for the client to be monitored.
The monitoring object is located in a different physical system.
The RFC destination defined in the configuration for the alert monitor is called internally through CCMS. (CCMS, Configuration Alert Monitor, Technical
Infrastructure Create Entry for Remote Monitoring).
If the client started there is the same as the client to be monitored, a function module of the appropriate detail monitor is called locally.
- If a different client in this physical system is involved, an outbound partner profile for the other client with the appropriate RFC destination and dialog user for
the message type SYNCH must be available in the current client.
Activities
Check the current status and the open alerts of your SAP system:
In ALE Administration choose: Monitoring IDoc Display Monitor in CCMS (BDMONIC3) .
You can identify the current status by the performance values and status messages recently forwarded to the alert monitor. Older alerts that are still open (not
yet processed) are not included in the color coding.
Follow these steps:
1. Check the color coding in the monitoring tree.
The color of nodes or MTEs (monitoring tree elements) mean:
Green: The component is running normally. All is OK.
Yellow: A warning message has been issued - a yellow alert.
Red: A problem or critical status message has been issued - a red alert.
Gray: No data available for this node. (Check in the CCMS in the Self-monitoring monitor why the Collection tool is not available for this node).
Note: To display the legend of colors and symbols used in the alert monitor, choose Extras Legend.
The alert monitor passes the highest alert level in the monitoring tree to the highest node. For example, if the node with the name of your SAP System is
green, this means that all the components in the monitoring tree of this system have a green status. All is OK.
To start the analysis method, select a node. The analysis method displays details of the current status of the node.
You can select the display option, automatic refresh. Choose Extras Display options. Select the General register. In the group box, Refresh
display, select the option Yes and enter an updating interval. Recommended value: 300 seconds or longer
If the automatic refresh is switched off, the alert monitor displays the data available when it was started.
2. Check what has been going on in your system.
In the standard toolbar select Open alerts.
Instead of the current system status, the color marking shows where there are open alerts in the system. Open alerts are alerts that have not yet been
analyzed and set to Completed.
When you start your work in the morning or return to your workplace after the lunch break, you can check in the Open Alerts view, whether any problems
occurred in the system during your absence. The monitor records all alerts, even if the status of the alert has been corrected in the meantime.
3. Respond to an alert.
In the monitoring tree, yellow entries mean warnings and red entries mean errors:
To deal with them:
a) Select Open alerts to switch to the alert display, provided it is still active.
The monitor now displays the number of alerts for each monitoring tree element (MTE). The most important alert messages that still need to be
resolved are also displayed.
b) Select a yellow or red monitoring tree element and select Display alerts .
The system opens the alert browser and displays the open alerts. The browser contains all the alerts in the tree node you selected. Move the cursor
further up the monitoring tree to display a wider range of alerts. Select an MTE on the lowest level of the display to display only those alerts that
affect this MTE.
c) Analyze an alert.
Each line in the alert browser displays an alert message (far right) as well as details of the alert.
The browser provides two further sources of information. Select an alert checkbox and the functions (using icons) below:
Start analysis method
This starts the problem analysis transaction or similar tool associated with the alert.
Display details
PUBLIC
Page 22 of 51
The system shows details of the monitoring tree element. This includes the latest values or status messages, alert threshold values and performance data for
the last entry time (only for performance monitoring tree elements). You can display the data graphically by selecting the relevant line and selecting Display
performance values graphically.
4) When you have dealt with the alert, you can change its processing status.
Once you have analyzed the problem and either corrected it or are sure that it is safe to ignore it, select the alert and select Alerts completed .
The alert monitor deletes the alert from the list of open alerts.
Further Functions
The topics below describe how you can configure the alert monitor to your requirements and how you can use more of its functions:
Monitoring: Monitoring: How-To Instructions:

Instructions for tasks you may have to carry out in the alert monitor.
Creating Your Own Monitors:

Instead of working with a predefined monitor, you can create your own special monitors. You can include only those monitoring tree elements that you
really have to display.
Customizing the Alert Monitor:

All monitoring tree elements have approved standard threshold values for deleting alerts and standard assignments for analysis methods.
You can change the threshold values and the assigned analyze methods, if required.
!--a11y-->
1.2.1.2 Status Monitor for ALE Messages

Use
You use the status monitor to monitor the processing status of IDocs in ALE inbound and outbound processing, and to process IDocs manually.
Features
Go to the status monitor selection screen with Tools
IDoc Interface/ALE Administration Monitoring IDoc Display Status Monitor (BD87) .
Use the selection options to restrict and display the IDoc selection.
The IDocs are arranged by status in the hierarchy. You can rearrange them by message type, object type, or by partner system. You can display a selection
of IDocs, process IDocs directly, or first restrict their number and then process them.
From the hierarchy display you can select an IDoc in the list and from here branch to the IDoc individual display.
Restricting IDoc Selection

In the selection screen, you can use the following options to display the status of IDocs:
IDoc number
Date created *
Time created
Date changed *
Time changed
IDoc status
Partner system
Message type
Business object type and object key (selection takes longer than with message type)
* The arrow keys are used to scroll week by week.
Effects of selection on performance:

The following selection is best for performance:
- Date changed
- Status
- Message type
Selection of business object types has a negative effect on performance.
Note that it can take a long time to display IDoc entries in tRFC queue . You should therefore only expand this node if you really need to.
Expanding the subtree to the level of the error can also be very time-consuming.
Based on your selection, IDocs in inbound and outbound processing are displayed in a hierarchy grouped by their status.
Status
(Text with or without status numbers, number of IDocs)
Me sage type
(Object method: via Settings Display business object )
Message text
In the tree display, you can right click to call up context-specific menus.
To display a legend of the symbols used in the hierarchy choose Goto Display legend .
You can also restrict the number of IDocs to display from the hierarchy screen by choosing Select IDocs.
PUBLIC
Page 23 of 51
Changing the Hierarchy Display

Using the Settings menu, and partly by using the symbols, you can change the hierarchy as follows:
Message type/object type highlighted
IDoc status highlighted
Display partner systems (highlighted message type or IDoc status)
This setting has a negative effect on the performance of the activities.
You can assign status information in groups and hide/show status numbers (using the Settings menu).
Displaying the IDoc List

You can choose Display IDocs to display a list of the associated IDocs for each main entry or sub-entry that contains the following information:
IDoc number
Status
Message type
Object type (only for business objects)
Object type (only for business objects)
Status text
Partner number of receiving system
Date created
Time created
IDoc basis type
Number of segments
Displaying individual IDocs

You can display the IDocs belonging to the IDoc numbers individually. Select an IDoc and choose Display IDocs or double click on the IDoc . The IDoc
display contains the control record, data records and status records.
Displaying links to objects
To display links select an IDoc number and choose Display links.
A list of objects linked directly to the IDoc appears.
Displaying Status Long Text
In the IDoc selection you can display the associated status long text of an IDoc number by selecting the button of the same name.
Displaying object keys
For each IDoc number in the IDoc selection you can also display the columns Object type and Object key by choosing the button Object key.
Determining Status in Receiving System

You can determine the status of the IDocs in the receiving system (inbound processing) using ALE Audit and IDoc Tracing:
Asynchronous Status Confirmation
Provided that you Monitor the Status of Inbound IDocs Using ALE Audit and confirmations are returned from the receiving system periodically,
confirmations are displayed in the status monitor hierarchy. Such IDocs have status 39, 40 or 41. The confirmations contain status information from the
receiving system. In the appropriate IDoc selection for each IDoc you can find the partner number and the status of the assigned IDoc in the receiving
system (50, 51...).
Alternatively, you can display an aggregated overview of all periodic confirmations. To do this you have to Evaluate the Audit Database in the sending
system (outbound processing). Choose Goto ALE Audit Evaluate Audit Statistics
Synchronous status determination
For inbound IDocs (in the receiving system) and for outbound IDocs with status 3 and 12 you can synchronously call up the status of the IDoc in the
partner system. Choose Trace IDocs in the status monitor hierarchy. For more information see System-Wide IDoc Tracing.
You can print the hierarchy of the status monitor ( IDoc selection Print ).
Processing IDocs
If incomplete IDocs or IDocs with errors exist, you can determine the cause and correct the problem using the status long text (click right mouse button or
choose IDoc selection ).
You can then process the IDocs, or first restrict the number of IDocs and then process them.
A list of processed IDocs with their previous and current status appears.
In inbound processing, you can subsequently post non-posted IDocs (status 51) (for more information, see Error Handling.
You can not process communication errors.
!--a11y-->
PUBLIC
Page 24 of 51
1.2.1.2.1 ALE Audit and ALE Tracing

The differences between ALE Audit and cross-system IDoc tracing are:
As a rule, audit reporting is usually more efficient than IDoc tracing because the confirmations from the receiving system are already in the outbound
system.
The audit database is only updated periodically. Although this time interval is variable, newly created IDocs only appear in the audit report after a time
delay.
With system-wide IDoc tracing information is obtained from the receiving system synchronously.
Unlike ALE audit, you can only use IDoc tracing with logical systems and not with EDI communication partners such as customers and vendors.
With ALE audit you can easily monitor the IDoc transfer from the sending system provided that time is not an essential criterion for the transfer.
!--a11y-->
Monitoring the Status of Inbound IDocs Using ALE Audit

Use
Using ALE audit you can monitor the processing status of dispatched IDocs in the receiving system (inbound) from the sending SAP system. The receiving
SAP 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.
Connections are also created between IDocs in the sending system and IDocs in the receiving system.
A report program on the sending system analyzes the audit database.
Prerequisite
Confirmations can only be dispatched, if you have defined a message flow for message type ALEAUD in the distribution model.
Choose the following activity in ALE Customizing :
Transaction SALE
Audit (BD64) .
Set-Up System Monitoring Set-Up IDoc Confirmation in Receiver System (ALE Audit) Configure Distribution Model for ALE
To improve performance, confirmations are dispatched periodically for packets of IDocs rather than for individual IDocs. Confirmations have a special
ALEAUD01 IDoc 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. If the MESTYP filter object type is not used all IDocs are confirmed by ALEAUD in the receiver system.
Activities
In the receiver system you have to make the settings for periodic confirmations. You can also send confirmations directly.
When confirmations are sent (program RBDSTATE), IDocs of message type ALEAUD are generated containing information about the processing state of
inbound IDocs. An audit IDoc contains confirmations for up to 500 IDocs. If there are more IDocs to be confirmed, several audit IDocs are generated. A list of
the generated IDocs is displayed. If an IDoc cannot be generated or an error occurs, a message is displayed.
IDocs whose statuses have recently changed are selected. Because almost every IDoc activity (e.g. creation, successful posting/ unsuccessful posting in an
application) alters the status of the IDoc, it is precisely these IDocs which have in some way or other been processed.
PUBLIC
Page 25 of 51
Setting Periodic Confirmations

So that audit data can be confirmed periodically back to the sending system, you have to use the program RBDSTATE to specify a variant and schedule a
background job in the receiving system.
Choose the following activity in ALE Customizing :
Set-Up System Monitoring Set-Up IDoc Confirmation in Recipient System (ALE Audit) Confirm Audit Data Specify Variant.
Schedule this variant as a background job:

Choose SAP menu Tools
System.
IDoc Interface/ALE Administration Services Periodic Jobs Inbound Set-Up IDoc Confirmation in Recipient
You can schedule confirmations at hourly or daily intervals.

To display an aggregated overview of all periodic confirmations you can Analyze the Audit Database in the sending system.
Sending Confirmations Directly

To send confirmations directly to the sending system, in the status monitor choose Goto ALE Audit Send confirmations .
The selection parameters allow you to regulate in which systems and for which message types, confirmations should be generated.
You have to enter a start and end date for the change period.
!--a11y-->
Evaluating the Audit Database

Use
You can display an overview of all status confirmations over a specified time period by evaluating the audit database.
Activities
Displaying Overview of All Statistics
You can evaluate the audit database using the IDoc status monitor: Goto ALE Audit Statistical evaluation .
The overview screen contains all the selected audit statistics. Each receiver system, message type, and IDoc creation date are recorded.
The columns are:
Last IDoc
Time until when IDocs are included
If the entry is 24:00:00, all IDocs created in one day are included. If an earlier time is displayed, only those IDocs created up until this time are included in
the statistics.
Total IDocs
Number of IDocs in this statistic
Outbound Queue
The number of IDocs still being processed in your own system (not yet dispatched).
Inbound Queue
The number of IDocs received by the target system but still being processed at the time of the last confirmation. If you double-click on a statistic, a
status overview is displayed.
Displaying Status Overview of Individual Statistics

If you double-click on a statistic, the status overview is displayed.
The overview contains all the messages sent and details of any IDocs containing errors. The details consist of the current status, the number of IDocs and the
error message.
The status records, based on the confirmation messages, may have the following values:
39 IDoc is in receiving system (ALE service) and is still being processed.
40 Application document not created in receiving system.
Processing could not be completed in the receiving system.
41 Application document created in receiving system.
(Processing has been completed.) The message in the status record is the same as the corresponding message in the IDoc status record in the
receiving system.
All IDocs for the selected statistic are grouped by status and listed separately for outbound and inbound IDocs.
PUBLIC
Page 26 of 51
Displaying List of IDocs with Specific Status Value

If you select a status value, an IDoc list for this status value is displayed. The IDoc list only shows status values which are not yet finalized. It does not show,
for example, status 53 - "application document posted". ALE audit only has information about IDocs that are still being processed.
Any linked application objects are also displayed. If the IDocs are already in the receiver system, the IDoc number in the receiver system is also displayed.
Displaying Individual IDocs

To display the associated local IDoc, double click on a line.
In the individual display you can view all the information that exists in your own system for this IDoc.
Status values 39 and 40 indicate error messages in the receiving system.
!--a11y-->
1.2.1.2.1.2 Tracing IDocs System-Wide

Use
In the status monitor you can trace IDocs system-wide to determine the processing status in the receiving system of IDocs with status 3 and 12.
Activities
In addition to the status overview you can also display links between IDocs and objects and between individual IDocs.
Displaying Status Overview
Select a status text or a message type / object method and select Trace IDocs.
A status overview of IDoc pairs in the sending and receiving systems appears.
The IDoc selection contains the following columns:
IDoc number
Status in sending system
IDoc number in receiving system
Status in receiving system
Message type
Status text from receiving system
Partner number of receiving system
Date created
Time created
IDoc basis type
Number of segments
Displaying Links to Objects
To display links select an IDoc number and choose Display links.
A list of objects linked directly to the IDoc appears.
Displaying IDocs
You can display the IDocs individually in the sending and receiving systems . Select an IDoc and choose Display IDocs or double click on the IDoc . The
IDoc display contains the control record, data records and status records. For more information choose Help Application help .
!--a11y-->
1.2.1.3 Workflow Connection for ALE Functions

Purpose
If an ALE send error occurs, the staff responsible is informed. The staff must be assigned to an organizational unit , and it must be specified which
organizational unit, position or member of staff responsible for processing which errors.
Organizational units are components of the company organizational structure. The organizational structure comprises organizational units and their interrelationships. It also contains positions, which can be linked to the organizational units and their owners (persons, members of staff, users). For further
information, see the documentation of the Business Management (SAP Business Workflow and organizational management).
In this section, you specify the organizational structure of your company (if you have not already done so), and link elements to tasks.
SAP delivers default error handling tasks. The link causes a message to be sent to the persons responsible if an error occurs. Link default tasks for the
following error cases:
Technical errors,
PUBLIC
Page 27 of 51
Syntax errors,
Application posting errors (for all message types).
Prerequisites
Before you can use the ALE function workflow connection, you must make the workflow settings in ALE customizing (transaction SALE).
Example
Assign the default task "ALE/EDI: Error Handling (Incoming)" to the organizational unit "Sales".
Specify, for example, Mr. Miller from "Sales" for communication with the logical system "K11CLNT005" (dec. Sales "South"), in the partner profile.
If an error occurs when posting a Sales "South" IDoc, Mr. Miller receives a task (work item) in his inbox.
Default Settings
SAP delivers default error handling tasks without links.
The ALE business process library tells you which default tasks you must link for each ALE business process.
You must link these default tasks according to your ALE business process. (For example you must link the tasks for "ORDERS incoming error" and
"ORDCHG incoming error" for the customer order, for the SD business process in Sales.)
Activities
1. Perform the function Create/Change Organizational Structure in the SAP Business Workflow, and create a new organizational unit or change an existing
one.
2. Position the cursor on an organizational unit and choose Staff Assignments.
3. Position the cursor on the organizational unit and choose Create Position, to create a new position for the organizational unit. Repeat the action until you
have assigned all positions to the organizational unit.
4. Position the cursor on a position and choose Assign Occupant, to assign a new user as occupant of the position. Repeat the action until you have
assigned all occupants to the position.
5. To assign default tasks to an organizational unit or position, position the cursor on the entity and choose Task Profile.
6. Position the cursor at the position to which you want to assign the default task, and choose Assign Task. Specify the default task.
Always link the following default tasks:
- ErrorProcOut ALE/EDI: Error Handling (Outgoing) TS00007989
- ErrorProcInb ALE/EDI: Error Handling (Incoming) TS00008086
- SynErrorOut ALE/EDI: Syntax Error (Outgoing) TS00008070
- SynErrorInb ALE/EDI: Syntax Error (Incoming) TS00008074
- ErrorMessage Send Error Messages TS30000020
- IDocpaket IDoc package outgoing error TS60001307
The automatic consistency check triggers error events for the following default task if it finds Inconsistencies. If you use the automatic consistency check,
you must also link this default task:
- AleLinkTech ALELINK: Technical consistency check TS40007916
The default tasks for application posting error which are delivered by SAP usually have the message-specific name '<message type>_error'.
For IDocs generated from BAPIs, the following default task, for which a link is also required, is triggered if an error occurs:
- BAPI_IDOC_ER BAPI-IDoc incoming error TS20000051
The default task ALEResendErr is used for errors which occur when forwarding IDocs to an R/2 system.
Repeat the steps 5 and 6 until you have assigned all required default tasks.
Notes
For further information about the ALE workflow connection, see:
Error and status processing
!--a11y-->

Use
PUBLIC
Page 28 of 51
In the IDoc Administration, you can assign a procedure to a workflow task error or status code.
With the Error and Status Processing function, you can check the assignment of the error procedure codes tothe standardtasks, if you have used EDI
communication in an earlierversion.
You must also maintain this assignment for your user developments.
Example
Code Type ID Description
EDIX 2 TS0008070 ALE/EDI: Syntax error (Outgoing)
Activities
Check whether the assignment matches the table listed below.
1. Choose SAP Menu -> Tools -> IDoc Interface/ALE -> Administration -> Runtime Settings -> Error and Status Processing ( transaction WE46).
2. Perform the function. The table must contain the ALE error handling entries listed below:
Code
Task
Description
Type
EDII
TS00008068
ErrorProcInb
EDIO
TS00007989
ErrorMessage
EDIP
TS60001307
idocpaket
EDIX
TS00008070
SynErrorOut
EDIY
TS00008074
SynErrorInb
EDIM
TS00007988
ErrorMessage
The table contains the assignment of the error procedure codes (e.g. EDII) forstandardtasks (e.g. TS00008068).
The procedure type is 2 (work item).
Notes
If you used EDI in an earlier version, standard tasks ofthe old versions are still assigned here for the procedure codes EDII and EDIO. If the new tasks are not
entered here, there may be ALE Processing problems.
See also:
Exception handling
Status processing
Procedure codes
Troubleshooting
!--a11y-->
1.2.2 ALE Customizing Data

There are two kinds of ALE customizing data: Application customizing data which configures the application processes.
Basis customizing data: This data is the technical configuration of the distribution (distribution model, logical systems, partner relationship definitions, etc.).
You may have to make consistency checks corrections for both types of customizing data, if, for example, customizing data is to be distributed into other
systems.
You can also use Business Configuration Sets to organize your ALE customizing data by process. Business Configuration Sets make your customizing
data more transparent and easier to analyze, and simplify roll-out to other systems. For more information, see:
Business Configuration Sets
Further Information
Adjust ALE Application Customizing Data Between Systems
ALE Basis Customizing Data
!--a11y-->
PUBLIC
Page 29 of 51
Synchronizing Application Customizing Data Between Systems

Use
In ALE Administration you can synchronize Customizing data of Customizing objects between systems.
Customizing objects are assigned to distribution groups and transported to the participating systems in transport requests. You have to define distribution
groups in Customizing for ALE.
For more information about this topic, see Synchronizing Customizing Data Between Systems.
Prerequisites
You have created distribution groups and performed modeling in Customizing for ALE (SALE).
Model and Implement Business Processes
Configure Customizing Data Synchronization
Procedure
To synchronize Customizing data you have to execute the functions below in both the sending and the receiving systems: Choose the functions under Tools
IDoc Interface/ALE Administration Services ALE Customizing Data ALE Requests .
In the sending system:

- Display outbound ALE Requests (BDXM)
Under Display outbound requests you can display the status details of ALE transport requests for a specified time period for each distribution
group and target system.
- Generate ALE requests (BDXE)
Under Generate using the selection options and parameters you can generate ALE transport requests and IDocs that notify the receiving
systems.
Note on field CTS dummy system
The CTS requires information on the target system, even though in this ALE case, this information is not used because ALE controls the
distribution through the info-IDoc itself. Enter an "empty pseudo system" to which usually no transports are made.
Notes on the objects:
Customizing data is assigned to Customizing objects and types are assigned to Customizing objects. Depending on this type, problems could
arise when transport requests are generated:
Object Type
Notes
L Logical transport object
No problems
S Table (with text table)
No problems
T Single transaction object
Works with restrictions

(no standard type of request generation defined, no line selection)
V View
Usually no problems
but no line selection possible with objects that are not linked (e.g.
SADR* tables).
The objects selected in the system from the Customizing requests which were included in the ALE request and recorded in the request
documentation.
In the receiving system:

- Display inbound ALE Requests (BDXN)
In Display inbound requests you can display the ALE requests and their import status for a specified time period for each distribution group and
source system.
- Import ALE requests (BDXD)
Under Import you can transport source requests for a specified time period for each distribution group.
- Consolidate and forward ALE requests (BDXL)
Under Consolidate you can create a consolidation request from several ALE requests. The consolidation request is used to transport
Customizing data imported by ALE requests into quality and production systems.
You can only execute this function in Customizing Systems in which Customizing data has been imported by ALE transports.
The function generates a standard Customizing request that has not been released. The user of the function is also the owner of the
consolidation request.
Result
The Customizing objects are identical in all individual systems in your ALE integrated system.
PUBLIC
Page 30 of 51
!--a11y-->
1.2.2.2 ALE Basis Customizing Data

The ALE basis customizing data configures the distribution technically:
Distribution model (logical level), in which the sender-recipient relationships for messages are defined
Partner profiles (physical communication level)
RFC destination for synchronous BAPI calls, and
ALE tools, for example to send IDocs to specified recipients (listing), or to change IDoc data from one value to another (data conversion).
SAP provides two tools to ensure the consistency of this data:
Converting ALE Basis Customizing data
This tool adjusts the data in distributed system landscapes.
ALE basis customizing data check center
The Check Center checks the consistency of your ALE basis customizing data.
Further Information
Conversion of ALE Basis Customizing Data
ALE Basis Customizing Data Check Center
!--a11y-->
1.2.2.2.1 Converting ALE Basis Customizing Data
Use
If you want to maintain and test ALE basis customizing data in a system landscape, and then be transported or distributed into other systems, the
consistency of this data must also be checked in the new system landscape. The ALE Basis Customizing Data Conversion tool automatically adjusts this
data. It does not transport the ALE basis customizing data; it converts the data for the new system landscape using a conversion matrix.
The target groups for the tools are system administrators who administer a distributed system landscape, in which integrated scenarios are implemented by
ALE.
Prerequisites
You have several system landscapes for distributed scenarios, e.g. one system landscape for development, one for quality assurance and one for production,
in which each client has a unique logical system name. You want to transport or distribute the ALE basis customizing data from one system landscape to
another.
Features
The tool comprises two transactions:
Specification of the conversion matrix . A conversion matrix is specified in a system A, for a new (or user) system landscape, and then transported or
distributed to it.
Conversion . The ALE basis customizing data is converted in the system using the conversion matrix.
Further Information
Specify Conversion Matrix
Convert
!--a11y-->
PUBLIC
Page 31 of 51
1.2.2.2.1.1 Specify Conversion Matrix

Use
This transaction specifies a matrix which converts the logical system names into new logical system names for a system.
Prerequisites
This step is required when a distributed system landscape contains inconsistent logical system names.
Procedure
1.
Choose SAP Menu Tools IDoc Interface/ALE Administration Services Customizing Data
Data Convert ALE Basis Customizing Data Specify Conversion Matrix (transaction code BDLSM)
ALE Basis Customizing
2. Specify the name of the logical systems in which the conversion is to be made
3. Specify the conversion matrix by specifying the name change from the previous system name ( From System column) to the new system name ( To
System column).
4. If you want to change several system names which are maintained in a layer of the ALE distribution model, you can get possible entries help with the
Model Views button. When you select a distribution model from the possible entries help, all its system names appear in the From System column.
5. Specify the new system name for each system
!--a11y-->
1.2.2.2.1.2 Conversion
Use
This transaction converts the logical system names. It is a two-step procedure: Test and Live , processing is synchronous.
Both steps are logged.
Prerequisites
You have transported or distributed the conversion matrix into the system in which the conversion is to be made.
You can only start the live conversion when the test has been completed successfully.
This step only converts tables which belong to the software component basis (SAP_BASIS).
Procedure
1. Choose SAP Menu Tools IDoc Interface/ALE Administration
Convert ALE Basis Customizing Data Convert (transaction code BDLST)
Services
Customizing Data
2. The conversion matrix which you specified for this system appears.
Choose Start Test Run .
3. Examine the conversion log and resolve any errors
4. Start the live conversion.
5. If errors occur in the live conversion, you must resolve them.
6. Restart the conversion procedure.
Result
PUBLIC
Page 32 of 51
When all conversion procedures have been performed without errors, the conversion is finished.
!--a11y-->
ALE Basis Customizing Data Check Center

Use
The 1.2.2.2.2 ALE Basis Customizing Data Check Center checks the ALE basis customizing data, displays the results and goes to the transactions in
which you can adjust or correct the data. This simplifies the system administration for distributed systems and integrated scenarios.
Features
The standard contains the following checks:
Technical Data of User System
Conversion of ALE Basis Customizing Data
Check Distribution Model
Check/Generate Partner Profile
Check Communication Partner
You can also put further checks in the Check Center:
Enhance Checks
Activities
Choose SAP Menu Tools
IDoc Interface/ALE Administration
ALE Basis Customizing Data Check Center (transaction code BDCCC)
Services
Customizing Data
This transaction lists all items to be checked. You can perform the checks from the list.
!--a11y-->
1.2.2.2.2.1 Technical Data of User System

Use
This check report gets the technical data of the current user system. The following data is output: System ID, client and assigned logical system name with
description.
You can go to the transactions Maintain Logical Systems (transaction code BD54) and Client Administration (transaction code SCC4), to display or create
other logical systems in this system landscape.
Procedure
1. Choose SAP Menu Tools IDoc Interface/ALE Administration Services Customizing Data
Basis Customizing Data Check Center (transaction code BDCCC)
2. Choose User System Technical Data from the list of checks.
3. Choose
ALE Basis Customizing Data ALE
in the Execute column, to perform the check.
!--a11y-->
1.2.2.2.2.2 Conversion of ALE Basis Customizing Data
PUBLIC
Page 33 of 51
Use
This check tests transaction Conversion of ALE Basis Customizing Data (transaction code BDLST).
You can go to the transaction Convert Logical System Name (transaction code BDLS), to make any additional conversions. You can also go to the
transaction Maintain Distribution Model (transaction code BD64), to check, change or distribute the ALE Distribution Model.
Procedure
2. Choose Convert ALE Basis Customizing Data from the list of checks.
3. Choose
in the Execute column, to go to the transaction BDLST.
4. Perform the test.
!--a11y-->
1.2.2.2.2.3 Check Distribution Model

Use
This check determines whether the message flow from and to the specified partners is unambiguous. It also checks whether the partner profiles have been
maintained for each message flow.
The message types and BAPIs in the partner profiles are output (or which BAPIs have been specified for synchronous calls, but are not in the distribution
model).
You can go to transactions Maintain Distribution Model (transaction code BD64), Assign RFC Dest. to Log. Systems (BD97) and Partner Profiles (WE20).
Procedure
2. Choose Check Distribution Model from the list of checks
3. Choose
Result
You get a list of all relevant messages.
!--a11y-->
1.2.2.2.2.4 Check/Generate Partner Profiles

Use
This check tests the transaction BD82 ( Generate Partner Profiles ) and can also start the generation.
You can go to the manual maintenance of the Partner Profiles (transaction code WE20).
Prerequisites
The distribution model must have been maintained.
The distribution model must have been distributed.
RFC destinations must have been maintained.
You must make settings under Troubleshooting so that the staff responsible is informed about processing errors.
Procedure
PUBLIC
Page 34 of 51
2. Choose Check/Generate Partner Profiles from the list of checks
3. Choose
Result
You get a detailed log of the partner profile generation.
!--a11y-->
1.2.2.2.2.5 Check Communication Partner

Use
This check tests all RFC destinations of type 3 (SAP system) which have been defined in this system. The following system data is fetched from the partner
system and displayed: System ID, client and logical system name (if connection and data exist). You can see whether the logical system name in the partner
system matches the name in your system.
You can go to the transaction Maintain RFC Destinations (transaction code SM59).
Procedure
Services
Customizing Data
Services
Customizing Data
2. Choose Check Communication Partner Profiles from the list of checks

3. Choose
Result
You get a detailed log of the check result.
!--a11y-->
1.2.2.2.2.6 Enhance Checks

Use
This transaction puts user checks in the ALE Basis Customizing Data Check Center.
Prerequisites
You have implemented a program or form routine for the check.
Procedure
2. Choose Goto Maintain Other Checks.

3. Go to change mode and choose New Entries
4. Maintain the field Item , Name and Program to be Checked for each additional check. You can also specify the sequence in the check list, in the
Follows column. Enter the check code which the new check is to follow.
PUBLIC
Page 35 of 51
Result
You can now start the new check(s) from the Check Center.
!--a11y-->
1.2.3 Optimizing ALE Performance

IDocs are fundamental to Application Link Enabling. Optimal system performance in ALE processing is synonymous with optimal performance of IDocs.
In ALE processing IDocs are:
Created in the SAP sending system

Transferred to the communication layer in the SAP sending system
Used when SAP sending and receiving systems communicate
Processed in the receiver system
You can optimize IDoc processing in one or more of the following ways:
Controlling IDoc Events

Processing IDocs in Parallel
Processing IDocs in Packets
Administration of IDoc Communication
Archiving and Reorganization
!--a11y-->
1.2.3.1 Controlling IDoc Events

You can specify the times IDocs are created, transferred to the communication layer, and posted in the receiving system in ALE Customizing .
It is best to process time consuming ALE tasks in the background at times when the load on the system is minimal.
See also:
Scheduling IDoc Creation
Scheduling IDoc Transfer to the Communication Layer
Scheduling IDoc Posting
!--a11y-->
1.2.3.1.1 Scheduling IDoc Creation

You can specify the time an IDoc is created for distributing master data only. When transaction data is distributed, IDocs are created at the same time as the
data is saved in the application.
Master data IDocs can be created in two ways:
By processing change pointers created when master data is created or changed.
To do this, in ALE Customizing (Transaction SALE) choose:
Configure and Implement Business Processes
Configure Master Data Distribution
Set-up Replication of Modified Data
Create IDocs from Change Pointers
Schedule Job (SM36)
By directly sending or requesting master data in the ALE master data menu area or by calling an appropriate program.
You should create change pointers to log master data changes. This avoids having to keep an external list of master data changes for
synchronizing data later by sending it directly.
If the same data is changed several times, only the last change pointer is used to create the master data IDoc. This minimizes the number of
IDocs dispatched.
To create change pointers, in ALE Customizing you have to activate change pointers generally as well as for individual message types:
Modeling and Implementing ALE Business Processes
PUBLIC
Page 36 of 51
Master Data Distribution

Replication of Modified Data
Activate Change Pointers - Generally
Activate Change Pointers for Message Types
It is useful to send or request master data directly, if an SAP system is to be initialized or synchronized. In ALE Administration choose the
required master data and function under Master Data Distribution .
!--a11y-->
Scheduling IDoc Transfer to Communication Layer

When an IDoc is transferred to the communication layer, a transactional RFC (tRFC) forwards it to an external system. The ALE layer transfers the IDoc.
The ALE layer processes the outbound IDoc and controls its dispatch. Depending on the partner profile settings in Customizing for ALE, IDocs can be
transferred in the following ways:
IDocs assigned to the same partner and message type are collected and the RSEOUT00 program later forwards them to the communication layer.
To do this, in ALE Customizing (Transaction SALE) choose:
Set-Up System Monitoring
IDoc Processing
Schedule Collected IDoc Transmission (SM36)
You can also send the collected IDocs to the communication level manually, in the ALE Administration under Monitoring IDoc Display Status
Monitor .
The IDoc is forwarded to the communication layer immediately.
You should use the outbound processing mode Collect IDocs, especially if you are distributing master data. System performance is better.
You can also Process IDocs in Packets in the "collect" processing mode.
To go to the ALE administration functions, from the SAP menu choose
Implement and Configure Business Processes
Partner Profiles
Generate Partner Profile
Under outbound parameters choose the output mode Collect IDocs and transfer .
!--a11y-->
1.2.3.1.3 Scheduling IDoc Posting

There are two ways of posting IDocs in ALE inbound processing:
Immediate processing:
Upon receipt inbound IDocs are immediately released for posting. ALE inbound processing splits the IDoc packets into individual IDocs.
Background processing
Inbound IDocs and IDoc packets are first saved in the database. IDoc packets are split into single IDocs beforehand.
The program RBDAPP01 later releases the saved IDocs for processing. Single IDocs can be put into packets and then processed.
Perform the following steps:
1. Set-up background processing (IDoc/ALE area menu):
IDoc Interface/ALE Administration Runtime Settings Partner Profiles (WE20)
Then the required setting is: In the detail screen Inbound Parameters select the option Trigger by background program.
2. Schedule posting (ALE customizing):
Transaction SALE
Posting IDocs in Recipient System Schedule
You can also process the IDocs manually by passing them to the posting function module. In ALE Administration choose Monitoring
Status Monitor (BD87) , select the IDocs and then select Process .
You should choose background processing, especially if large data volumes are to be distributed. System performance is better.
Packet Processing can be used to process individual inbound IDocs in the background. A function module capable of mass processing is
required for this. Processing IDocs in Parallel has further advantages for inbound processing.
!--a11y-->
PUBLIC
Page 37 of 51
Processing IDocs in Parallel

Several IDocs can be processed at the same time in different dialog processes. This is particularly advantageous for sending mass data.
See also:
Creating IDocs in Parallel
Sending IDocs in Parallel
Posting IDocs in Parallel
!--a11y-->
1.2.3.2.1 Creating IDocs in Parallel

IDocs can only be created in parallel in different dialog processes, if master data is sent directly. In contrast, the program RBDMIDOC to process change
pointers uses only one dialog process.
There are no benefits of creating IDocs in parallel for distributing transaction data in ALE, because this mainly involves single events which cannot be
accelerated by running dialog processes at the same time.
You must specify a server group for creating IDocs in parallel. The server group comprises the application servers, whose available dialog processes are used
to create IDocs. Two dialog processes remain unused on every application server in a server group.
There might be only one application server in a server group. Local dialog processes create the IDocs in parallel.
To define the server group in ALE Customizing choose:
Communication
Create RFC Connections (SM59)
Then to create groups, choose RFC RFC Groups
It is better to create IDocs in parallel when sending large quantities of master data.
Choose Tools ALE Master data distribution Cross-application Material Send, then the required master data and function.
You can only create IDocs in parallel, if the name of the required server group is entered on the Send material screen .
Because two dialog processes remain unused on every application server in a server group, make sure there are enough dialog processes
available on the application servers.
!--a11y-->
1.2.3.2.2 Sending IDocs in Parallel

IDoc communication with transactional RFC (tRFC) uses all available dialog processes on the application server that transfers the IDocs to the communication
layer. With tRFC parallel communication, it does not matter whether IDocs are first collected or transferred immediately.
IDocs should be transferred to the communication layer on an application server with a sufficient number of dialog processes.
Make sure you specify a sufficient number of dialog processes on the receiving SAP system. The number of dialog processes should not be
less than the number on the sending application server.
!--a11y-->
1.2.3.2.3 Posting IDocs in Parallel

This is used for:
Immediate processing
When IDocs are processed immediately, all dialog processes on the receiving application system are used for posting. This could block the application
server. You cannot distribute inbound IDoc packets among one server group.
An IDoc packet may consist of one or more IDocs. A dialog process to execute the posting function module is started on the application server for every
PUBLIC
Page 38 of 51
IDoc packet. If the IDoc packet consists of several IDocs, and if the posting function module is not capable of mass processing, the ALE layer calls the
function module several times in the same dialog process and each time transfers a single IDoc for processing.
Background processing
Inbound IDoc packets are split into individual IDocs and are stored in the database.
You can process IDocs that are ready for transfer (status 64) manually in ALE Administration ( Monitoring IDoc Display Status Monitor- BD87 ).
Alternatively, IDocs can be processed in the background.
To do this, in ALE Customizing choose:
Post IDocs
Post IDocs in Recipient System
All application servers in a server group can be used in parallel for updating IDocs in the background. There might be only one application server in a
server group. If you do not specify a server group, all dialog processes in the local server are used in parallel. This could block the application server.
For mass data it is better to process IDocs in parallel.

You must select the option Parallel posting on the screen Inbound processing of IDocs ready for transfer in the program RBDAPP01.
Specify a server group for parallel updating on several applications.
Because two dialog processes remain unused on every application server in a server group, make sure there are enough dialog processes
available on the application servers.
!--a11y-->
1.2.3.3 Processing IDoc Packets

Packet processing enables one program or one function module to process batches of data of the same type. This reduces the number of dialog processes
called and improves system performance.
You can use packet processing in ALE for:
Creating IDoc Packets
Sending IDoc Packets
Posting IDoc Packets
!--a11y-->
1.2.3.3.1 Creating IDoc Packets

If you send master data directly, a function module creates an IDoc for each master data object, for example, material. In most cases more than one master
data object can be passed to the function modules for IDoc creation.
If you send master data directly, you can send more master data objects in each process. As a guide you can send between 20 and 100
objects. This reduces the number of dialog processes used and the administrative load on the SAP system.
Packet processing and parallelism complement one another. Packet processing and parallelism complement each other, although in some
situations they may compete with each other. If there are too many master data objects in each process, possibly not all available dialog
processes will be used.
!--a11y-->
1.2.3.3.2 Sending IDoc Packets

Several IDocs can be grouped into a packet and sent in one transactional Remote Function Call (tRFC). This has the following benefits:
The fewer administrative tasks reduce the load on the system
tRFC uses less dialog processes in the sending SAP system
tRFC uses less dialog processes in the receiving SAP system
You can specify the packet size of message types in customizing for ALE (transaction SALE):
Partner Profiles
Generate Partner Profile
As a guide, packet size should be between 10 and 200 IDocs. The smaller the IDocs are, the larger the packet size can be. For message
PUBLIC
Page 39 of 51
types which contain large volumes of data, for example, GLROLL or ALEAUD, the packet size should be between 1 and 10 IDocs.
If the IDocs are not going to be posted immediately in the receiving R/3 System, an IDoc packet can contain up to about 10000 data records.
For example, if each IDoc contains 10 data records, a packet can contain up to 1000 IDocs.
!--a11y-->
1.2.3.3.3 Posting IDoc Packets

Two groups of function modules are used to post IDocs:
Function modules which process IDocs in mass. These transfer packets of IDocs for which individual IDocs are updated in the same Logical Unit of Work
(LUW).
Function modules which process one IDoc per call.
INPUTTYP contains the code for posting function modules.
To display the function module's INPUTTYP on the ALE Development screen, choose IDoc Inbound Processing Function Module Maintain
A ttributes (BD51) .
INPUTTYP can contain the following values:
"0", for function modules which process IDocs in packets.
"1" and "2" for function modules which process one IDoc per call:
If you post the IDocs immediately, the SAP sending system determines the packet size. ALE inbound processing can recognize if the posting function
module allows packet processing and if so, passes the IDoc packet to it. If not, the IDoc packet is split into individual IDocs.
If IDocs are posted in the background, you can specify the size of the IDocs to be generated in the program RBDAPP01.
If you use function modules that can process IDocs in mass, the database load is reduced.
If you group IDocs into packets, this may also be practical for function modules that post inbound IDocs one at a time, because the ALE layer
calls the function module several times in the same dialog process, thereby reducing the administrative load on the SAP system.
If program RBDAPP01 carries out the background processing, as a guide, you should use a packet size of between 20 and 100 IDocs.
Packet processing and parallelism complement one another. Packet processing and parallelism complement each other, although in some
situations they may compete with each other. If the size of the packet is too big, this may mean that not all the available dialog processes are
being used.
!--a11y-->
1.2.3.4 Administration of IDoc Communication

IDoc communication is based on transactional Remote Function Call (tRFC).
You can optimize the performance of ALE processing by using the following settings and procedures.
Suppressing Background Processing
Setting Dispatch Status to OK
Checking the tRFC Status
!--a11y-->
Suppressing Background Processing

In the standard SAP system, if tRFC errors occur, a background job is generated to re-establish the connection. In certain circumstances this could result in a
large number of background jobs being started that completely block background processing.
To cancel a background job if tRFC errors occur use program RSARFCEX to restart tRFC.
In ALE Customizing (transaction SALE ), select a connection to change:
Communication
Create RFC Connections (SM59)
Choose Destination tRFC Options and select the option Suppress Background Job at Comm. Error .
PUBLIC
Page 40 of 51
!--a11y-->
Setting Dispatch Status to Dispatch OK

When an IDoc is passed to the communication layer, it is assigned a globally unique transaction identifier (TID). If the IDoc has been successfully dispatched,
this information is not automatically passed to the ALE communication layer. So that ALE processing sets the IDoc status to Dispatch OK, you should
compare the TID numbers in the communication layer and the ALE layer.
The program RBDMOIND checks that the IDocs passed to the transactional RFC have already been sent to the receiving SAP system. If they have been
sent, the IDoc status is changed to "12" - Dispatch OK .
To set the IDoc dispatch status, run the program RBDOIND after the IDocs have been passed to the communication layer.
!--a11y-->
1.2.3.4.3 Check the tRFC Status
Use
tRFC calls which transfer IDocs use the function module IDOC_INBOUND_ASYNCHRONOUS at reception (before release 4.0: INBOUND_IDOC_PROCESS).
If an IDoc in the sending system has been passed to tRFC (IDoc status "03"), but has not yet been input in the receiving system, this means that the tRFC
call has not yet been executed.
Activities
To check the status of the tRFC calls, choose Tools IDoc Interface/ALE Administration Monitoring Troubleshooting RFC Queue (SM58)
and specify any additional selection criteria.
The program RSARFCEX restarts unsuccessful tRFC calls.
You cannot choose the option is being executed in background processing.
!--a11y-->
1.2.3.5 Archiving and Reorganization

Archiving and Deleting IDocs
IDocs are stored in several database tables. To keep these tables small, you have to archive older data at regular intervals.
Data archiving is used to transfer application data, which is no longer needed in the system but which must still be stored, from the database into archive files.
The data is stored in archives in business systems and can then be stored in external storage media.
PUBLIC
Page 41 of 51
For more information on archiving see the documentation on the IDoc interface under Archiving IDocs.
Reorganizing IDoc Links to Application Objects

IDoc links to application documents are stored in tables. You should delete table entries that are no longer required at regular intervals.
Unlike IDocs, links are not archived before they are deleted.
For details about organizing these links, see the documentation on the IDoc interface in the section Deleting Links with IDocs
Reorganizing Time Stamps of Serialized IDocs

Time stamps for serialization at IDoc level are stored in table BDSER.
You should delete table entries that are no longer required at regular intervals.
Schedule regular background processing with program RBDSRCLR.
For details of this type of serialization, see Serialization at IDoc Level.
Reorganizing the Audit Database

You should delete table entries in the audit database that are no longer required at regular intervals (using transaction code BDM9).
You can also schedule the reorganization in background processing, Use the program RBDAUD02.
Reorganizing Change Pointers

You should delete table entries for change pointers that are no longer required, at regular intervals (transaction BD22).
You can also schedule the reorganization in background processing, using the program RBDCPCLR.
You can use the program RBDCPCLR to delete change pointer entries from the database tables.
!--a11y-->
1.2.4 Serialization of Messages

Use
Serialization plays an important role in distributing interdependent objects, especially when master data is being distributed.
IDocs can be created, sent and posted in a specified order by distributing message types serially.
Errors can then be avoided when processing inbound IDocs.
Features
Interdependent messages can be serially distributed in the following ways:
Serialization by Object Type
Serialization by Message Type
Serialization at IDoc Level
(not for IDocs from generated BAPI-ALE interfaces)
!--a11y-->
Serialization by Object Type

Use
Serialized messages can be of different types (for example, create, change or cancel messages). All messages here relate to one special application object.
PUBLIC
Page 42 of 51
The messages can contain both master data and transaction data.
With object serialization the messages of a given object are always processed in the correct order on the receiver system. Messages are posted in the
receiver system in the same order they were created in the sender system.
Features
The message (IDoc) to be transferred is assigned a consecutive number. This is managed in the sending and receiving system for each object type and object
channel. An object channel contains a number of ordered IDocs and is defined by an object type (BOR) and precisely one channel number which is a message
attribute. All messages are processed in an object channel in the target system in the same order they were sent from the source system. A channel number
is a message attribute. It is generated in the function module ALE_SERIAL_KEY2CHANNEL or assigned in the application program.
This number identifies the following:
RFC transmission error
The application document of a message is not yet posted (status code 53), although the next message has already been received
In both cases the IDoc is waiting in inbound processing for its predecessor IDoc and is accordingly assigned status code 66. Once the predecessor IDoc has
been posted, you have to then post the IDoc with status 66 using program RBDAPP01.
All messages with the same channel number and object type are serialized when the messages are processed.
The current number of each object channel is recorded. This process is takes place in what is known as the registry. There is an outbound registry and an
inbound registry. Serialization must be activated in both registries (see prerequisites).
Outbound Processing (Source System)
When outbound IDocs are processed, for each object channel (field CHNUM) a unique serial number is assigned to each IDoc created (field CHCOU). This
number and the object channel are transferred with the IDoc in the SERIAL field.
A unique serial number is assigned to each message for the application object in question.
Inbound Processing (Target System)
When inbound IDocs are processed, a unique serial number is generated for each object channel (field CHNUM) and communication link. The ALE layer
determines whether a given IDoc can now be posted or whether other IDocs have to be posted first. The serial number for each received IDoc is exactly one
whole number lower. Any gaps in the sequence will mean that IDocs are missing, either because the transfer did not work, or because earlier IDocs were not
posted successfully.
In this case the IDoc is assigned status 66 and must be posted again with the program RBDAPP01.
Objects are assigned to messages and channels by the application.
Transfer errors (IDoc sequence mixed up) and inbound posting errors (IDoc cannot be posted due to Customizing errors) no longer affect the sequential order,
because serialization corrects these errors.
Further Information
Serialization by Object Type: Procedure
!--a11y-->
1.2.4.2 Serialization by Message Type

Use
IDocs can be created, sent and posted in a specified order by distributing message types serially.
Object interdependency is important at the message type level.
Consider a purchasing info record with a vendor and a material. To avoid any processing errors, the vendor and material must be created in
the receiving system before the purchasing info record.
Prerequisites
You have to activate serialized distribution of message types in both systems in ALE Customizing.
ALE IMG (transaction SALE )
Set-Up Data for Sending and Receiving Serialization
Serialization by Message Type
PUBLIC
Page 43 of 51
Features
Serialized distribution is only used to transfer changes to master data. IDoc message types are assigned to serialization groups according to the order
specified for their transfer. Master data is distributed in exactly the same order. If all the IDocs belonging to the same serialization group are dispatched
successfully, the sending system sends a special control message to the receiving system. This control message contains the order IDocs are to be
processed in and starts inbound processing in the receiving systems.
Serialized distribution of message types is not a completely new way of distributing master data; it uses existing ALE distribution mechanisms whilst adhering
to a specified order of message type. This distribution could also be carried out manually using existing ALE programs. However, serialized distribution
automates the single steps and can schedule them in a batch job.
In the serialization menu selection criteria determine how certain parts of the serialized distribution will be processed, for example, control message dispatch
and inbound processing. This includes sending the control message and the inbound processing of the IDoc.
!--a11y-->
1.2.4.3 Serialization at IDoc Level

Use
Delays in transferring IDocs may result in an IDoc containing data belonging to a specific object arriving at its destination before an "older" IDoc that contains
different data belonging to the same object. Applications can use the ALE Serialization API to specify the order IDocs of the same message type are
processed in and to prevent old IDocs from being posted if processing is repeated.
SAP recommends that you regularly schedule program RBDSRCLR to clean up table BDSER (old time stamp).
Prerequisites
IDocs generated by BAPI interfaces cannot be serialized at IDoc level because the function module for inbound processing does not use the ALE Serialization
API.
Features
ALE provides two function modules to serialize IDocs which the posting function module has to invoke:
IDOC_SERIALIZATION_CHECK
checks the time stamps in the serialization field of the IDoc header.
IDOC_SERIAL_POST
updates the serialization table.
!--a11y-->
1.2.5 Periodic Tasks

Use
Some IDoc Administration functions are performed periodically, and should therefore be scheduled in background jobs. These are:
Outgoing IDoc
Create IDoc from Change pointers (1)

Reorganize change pointers (2)
Serial distribution by message type (3)
Send collected IDocs (4)
Communication check (tRFC) and IDoc status conversion (5)
Repeat RFCs (6)
IDoc Inbox
Post IDocs in recipient system (7)
Post IDocs with errors (8)
IDoc confirmation in recipient system (9)
PUBLIC
Page 44 of 51
Active IDoc monitoring with workflow connection (10)
Prerequisites
You have maintained at least one variant for the function in the IMG.
Procedure
1. Maintain at least one variant for the function(s) in the IMG (Implementation Guide), if you have not already done so:
SAP Web Application Server
IDoc Interface/ALE
Modeling and Implementing Business Processes
Set-up replication of changed data (1,2)
Set-up serialization of sent and received data Serialization
by Message Type Serialized Distribution by Message Type (3)
IDoc processing (4,7,8)
Set-Up IDoc Confirmation in Recipient System (ALE Audit) Confirm
Audit Data (9)
Communication check (tRFC) and IDoc status conversion (5)
Repeat RFCs (6)
IDoc monitoring with workflow connection (10)
2. Schedule the variant(s) as background job.
Choose SAP menu Tools IDoc Interface/ALE Administration Services Periodic Outgoing/Incoming , and the function, to schedule the
variant.
!--a11y-->
Change Pointer (Master Data Distribution)

Purpose
If you want to distribute master data changes with the SMD tool (Shared Master Data), changes to the master data objects are flagged for distribution by
change pointers ( Master Data Distribution).
The SMD tool is connected to the change document interface. If the master data changes are to be distributed, the application writes a change document. The
contents of this are passed to the SMD tool. The tool writes change pointers, reads the application data and creates the master IDoc.
The master IDoc is then passed to the ALE layer, which sends it to all interested systems.
The change pointer tables (BDCP und BDCPS) should be as small as possible. Use as few change pointers as possible and delete change pointers which you
no longer need.
You can increase the rate of processing by using the Analyze Change Pointer and Reorganize Change Pointer functions.
Prerequisites
You have created change pointers.
Activities
Checklist to keep the change pointer tables as small as possible:
1. Do you really need change pointers?
You need change pointers to distribute changes with the ALE SMD tool. If you do not use this tool, you do not need to write change pointers.
You can deactivate change pointers and activate them again with the transaction BD61 .
2. Do you really need to activate change pointers for this messages type?
If some messages types are no longer to be distributed by change pointers, you can deactivate change pointers for this messages type.
You can deactivate change pointers for the message type
and reactivate them again.
For reduced message types, deactivate the change pointer with the
PUBLIC
Page 45 of 51
Reduction tool (transaction BD53).

From Basis Release 6.10, you can restrict the creation of change pointers in customer exits. This functionality is provided in advance in
the Note 'Reducing the amount of data for change pointers' (0420562).
3. Are there still too many change pointers to be processed?
The change pointers are analyzed with the transaction BD21 or the report RBDMIDOC in ALE and flagged as processed. If the change
pointers are created periodically, this report should also run periodically.
See also: Analyze change pointers.
4. Are no longer required change pointers reorganized in time?
The report RBDCPCLR (transaction BD22) to reorganize the change pointer should run periodically. Depending on how many change pointers
are created or processed, you can schedule the background job hourly, daily or weekly. You should delete all obsolete and processed change
pointers. You can also use this report for specified message types.
See also: Reorganize change pointers.
Notes
If you are in a Basis Release 6.X system, use the table BDCP2 for the change pointer, if possible. See the note 'Migrating change pointers to table BDCP2'
(0305462).
!--a11y-->
1.2.5.1.1 Analyze Change Pointers

Use
You can create IDocs from change pointers with the report RBDMIDOC .
Features
The report creates IDocs for the specified message type from the change pointers, sends them to the recipient systems, and flags the change pointers for this
message type as processed.
The recipient systems are determined from the distribution model for this message type.
The report tells you how many master andcommunication IDocs have been created.
Activities
1. Choose SAP Menu Tools
IDoc Interface/ALE Administration Services Change Pointers Analyze (BD21).
2. Specify a message type and run the report.

If you die create change pointers periodically, schedule the report periodically (see: Periodic tasks).
!--a11y-->
1.2.5.1.2 Reorganizing Change Pointers

Use
The report RBDCPCLR deletes processed and/or obsolete change pointers.
PUBLIC
Page 46 of 51
Features
This report deletes change pointer entries from the database tables. In Test mode, only a list of the selected entries is output. Entries are only physically
deleted from the database when the test flag is not set.
You can select obsolete and/or processed change pointers, or select by date and time.
Obsolete change pointers are those created before a specified date and time. If this flag is set, the obsolete change pointers are reorganized, whether or not
they have already been processed.
Processed change pointers are those which were processed within a specified period (date and time). If this flag is set, the processed change pointers are
reorganized.
The report outputs the number of change pointers deleted, or, in test mode, selected.
Activities
1. Choose SAP Menu Tools
IDoc Interface/ALE Administration Services Change Pointers Reorganize (BD22).
2. Select Test if you only want to display the selection result.

3. Specify a message type.
4. Specify whether you want to reorganize obsolete and/or processed change pointers, and run the report.
5. As this report should run periodically, schedule a job (see Periodic Tasks).
!--a11y-->
Conversion of Logical Systems

Purpose
Due to the increasing componentization and openness of SAP, logical systems must be able to communicate with each other beyond the boundaries of ALEintegrated systems, for example, in central user administration. Logical systems must therefore have unique names, even outside the ALE system group.
As of Release 4.5A SAP provides a tool to automatically convert the names of logical systems in all application tables, master data tables, and control data
tables.
As of R/3 Release 4.6C this tool is integrated in the client copy.
This includes both client-specific and cross-client tables.
You must not under any circumstances convert logical system names in a production system.
Conversion of logical system names can result in inconsistencies in the dataset and should only be carried out in exceptional cases and
after data has been saved to the database.
Never change the logical system name manually in the relevant tables.
IDocs that have not yet been processed must be processed before you start the conversion because these IDocs may contain names of
logical systems.
No other activities can be carried out in the system while the conversion program is running.
The conversion must be carried out in all partner systems. Conversion is carried out in the current client, that is, for all client-specific and
cross-client table entries.
Prerequisites
Users of this program must have the authorization object B_ALE_SYS in their user profile.
SAP recommends that only the ALE system administrator is given this authorization.
Process Flow
To carry out the conversion, start Transaction BDLS.
The default name displayed is the old logical system name.
Enter the new name of the logical system.
You can simulate the conversion in the report test mode. Here only the affected tables and the number of table entries to be converted are displayed. The
table entries in the database are not converted. You can evaluate the results and assess the runtime.
The report performs the following steps:
1. Determines all the active, transparent database tables whose fields have references to the following domains:
LOGSYS
PUBLIC
Page 47 of 51
EDI_PARTNUM
2. Converts the field values to the new logical system names
3. Updates the database
Transporting Changes
The changed table contents are not transported.
Conversion of EDI Tables

When EDI tables are converted, the report also determines the table fields containing the value LS (logical system).for the partner type. The corresponding
logical system names are converted.
Exceptions
If the new logical system name is maintained in table TBDLS on the local R/3 System (where the names are being converted), no conversion takes place. You
must assume that the new logical system name is already being used (for example in the ALE distribution model).
Further Information
For more details on extended functions with SAP Web Application Server 6.20 and later releases, see:
Conversion of Logical Systems (as of SAP Web AS 6.20)
!--a11y-->
Conversion of Logical Systems (as of SAP Web AS 6.20)

Use
As of SAP Web Application Server 6.20, SAP provides the option to convert logical systems using a new transaction that is more transparent and easier to
use. Transaction BDLS has been used for this purpose until now. This transaction remains unchanged, and is enhanced by the new transaction BDLSS. In
contrast to BDLS, in BDLSS logical systems can also be converted remotely in all partner systems.
Before you begin the processing, note the following points:
It is not possible to convert logical system names in a productive system.
While the conversion program is running, no other activities can be executed in the affected systems, including communication with other systems.
All IDocs in the system must be processed, because the logical system name could be contained in the IDoc data record. Logical system names in IDoc
data records are not taken into account in conversion.
First perform the conversion in the current logical system (current client). Normally, the logical system name is then also converted in all partner systems.
The tables for the definition of logical system names (TBDLS, TBDLST) receive special treatment in the current system. After you have entered the system
names, the system checks whether they have already been defined. The old system name is not changed in conversion. Instead, you add the new system
name, and when the conversion process is complete, including in all partner systems, manually delete the old system name from the tables. For the current
system, SAP recommends that you carry out conversion for client-specific tables as well as cross-client tables. For all other systems, only the conversion for
client-specific tables is recommended.
Do not manually change the logical system names in the relevant tables. If you do, the application documents will not be found, or will only partially be
found.
Prerequisites
Users of this program have the authorization object B_ALE_SYS in their user profile. SAP recommends that only the ALE system administrator is given this
authorization.
Before starting the conversion in the partner systems, you have converted the logical system in the current client.
Procedure
1. Enter the transaction code BDLSS
2. The initial screen of the transaction provides an overview. This overview displays all communication partners for the current system, who are defined in
the ALE distribution models, and for whom the partner type 'LS' (logical system) is maintained in the partner profiles.
3. If the RFC destination determined for this system can be accessed, the Technical Info column displays the system ID and the client. You can also start
conversion in the partner system remotely from here.
4. In the dialog box for the Set Parameters function, enter the logical system name that you want to convert in the Old Logical System Name field. Enter
the new name in the New Logical System Name field. If a conversion has been carried out for the current system and the log is still available, the
appropriate values are entered for these two parameters.
5. To set further parameters, choose the relevant tab page, for example, the parameter Number of Entries per Commit Work . The default value is 1.000.000
for Oracle databases and 100.000 for other databases. This value is only relevant for conversion. To improve performance, this value should be as large
PUBLIC
Page 48 of 51
as possible, as long as the database roll area is sufficient. If necessary, you can also adjust this value to suit the relevant system.
6. After you have set the parameters, you can start the conversion process remotely for each system. The following options are available for converting
logical system names:
Convert Client-Specific and Cross-Client Tables
Typical applications:
Renaming the logical system name, therefore changing the logical system name in all application tables of all partner systems.
Creating a new system by database copy. In this case, call the new system a different name to the original system.
Convert Client-Specific Tables
A typical application is the conversion of the logical system name after client copy:
1. Choose the appropriate option for your application.
2. The conversion process can be carried out online or in background processing (default). In background processing, a batch job is planned in the
corresponding system and started immediately.
3. You first need to start the conversion in the test run. If the radio button Test Run is selected, the system first analyzes all relevant tables, and then
determines the number of entries to be converted. The result of the test run is saved in the database and recorded in a log, which can be displayed as a
list. If the parameter Check Existence of New Names in Tables in Test Run is activated during the test run, the system checks whether the new logical
system name already exists in the application tables. If it does, a warning is displayed in the log for these tables. Check the tables that contain this
logical system name, and determine whether these entries need to be converted. If you do not want to convert these entries, do not start the actual
conversion.
4. The conversion also affects tables for communication partners, which are identified by partner number and partner type. If the partner number and the
logical system name are the same, these table entries are also converted.
5. In some applications, you may only want to select and convert specific data from the database table. To do this, you can select or exclude the tables to
be converted by entering the objects in the Tables for Conversion selection screen in Set Parameters . Table T000, for assigning the client to the logical
system, receives special treatment and cannot be excluded. This table is checked and converted at the start of the conversion process. Note that if only
one table is converted, the definition of the client for the logical system is also converted, if this assignment is defined in the current client. This means
that the application documents in converted tables are found, because they refer to the new system names, while application documents in tables that
have not yet been converted are not found, because they still refer to the old logical system names. It is therefore advisable to convert all tables in one
step.
6. Check the conversion logs to see whether the conversion process was successful. Check the results of the conversion. For example, a * character at
the end of the table name indicates a cross-client table. If you use Convert Client-Dependent and Cross-Client Tables , the existing entries in these tables
are replaced by the new logical system names. If you do not want to replace these entries, choose Convert Client-Specific Tables , so the old entries in
cross-client tables are retained.
7. After the conversion process has been successfully completed, the system generates a conversion log. This shows which tables and fields have been
determined for the conversion and how many entries are relevant or have been converted.
Performance
The value in the Number of Entries per Commit Work field is only relevant for the actual conversion (not for the test run). To improve performance, this
value should be as large as possible, as long as the database roll area is sufficient.
Depending on the size of the dataset in the system, the conversion process can last a long time.
The test run for certain parameters is executed once, and the result of the test run is used for the actual conversion. To improve performance, you can
execute the program for the actual conversion at the same time. This parallel processing can take place in different clients, or in the same client for different
tables.
If you are sure that the new logical system name has not already been used, you can deactivate the parameter Check Existence of New Names in Tables
in Test Run .
If you definitely do not want to convert same tables, or you want to handle some objects individually, use transaction BDLSC to exclude these tables or
include the objects. Note that defining objects in this way affects all clients. Also note the order in which the objects are to be handled. There is a predefined
programming interface for this.
Restart Capability
If the conversion process is terminated for any reason, it can be restarted, because the converted data is committed as a table or in sections within a
table.
Checking and Changing the Communication Settings

Asynchronous communication: Partner profile
When a logical system name is converted, the partner name is also converted in the corresponding partner profile, and the partner status in the partner
profile is set to inactive .
After conversion, check the partner profile (port and RFC destination). Change these if necessary, and activate the changed partner profile.
Synchronous communication: RFC destination
After the logical system name has been converted, check the RFC destination for synchronous communication, and change it if necessary.
!--a11y-->
Converting Data between Sender and Recipient

Use
The Data Conversion between Sender and Recipient Set-Up tool maps field contents from a sender to a recipient field. You can then distribute organizational
units, measurement units or customer-specific field contents from one system to another.
PUBLIC
Page 49 of 51
units, measurement units or customer-specific field contents from one system to another.
It is a general tool for defining and maintaining rules in ALE.
Prerequisites
You can only use this tool if you use the Web Application Server (SAP_BASIS) with SAP application components.
Procedure
In the ALE implementation guide (IMG) choose:
Transaction SALE IDoc Interface/Application Link Enabling (ALE )
Sender and Recipient
Model and I mplement Business Processes Set-Up Conversion between
Proceed as follows:
1. Create rule: The rules are defined per segment.
2. Maintain rule: Rule maintenance specifies conversion rules at field level.
3. Assign rule to a message type: The assignment specifies when the rule is to be applied. This is sender/recipient and message type specific.
Further Information
See also the documentation of the individual work steps in the IMG.
!--a11y-->
1.2.8 ALE Recovery for Data Consistency

Use
In distributed environments you can also recover an SAP system following a system failure caused by a database error. Using backup and point-in-time
recovery, you can reset the database to the status at the time the system failed and continue working with it.
In this case, transactions may still have taken place after the time the system is reset to, which are subsequently lost and have to be carried out again.
External interactions (for example, ALE, EDI, mail, fax, telex), possibly carried out under a different key, are duplicated and require special processing.
For example, if, a process sent a message to another system and started another process here during the time between when the error occurred and when it
was discovered on the recovered system, the data related to this process will no longer exist on the recovered system. The results of the second process
carried out on the receiving system still exist in this system. The inconsistent data in the two systems can be put right by canceling the data resulting from the
communication in the receiving system.
In point-in-time recoveries, certain documents and messages must be canceled in the communication partners systems and messages sent earlier from the
receiving system must be sent again. You have to determine all the actions that need to be carried out in the recovery process.
The ALE Recovery tools help you to do this.
Prerequisites
To recover a system, the following is required:
Database that allows a point-in-time recovery
Continuous database backup
The database of the recovered system has already been restarted at the status before the error occurred
Features
ALE Recovery tools perform the required analyses and help you carry out the necessary tasks.
1. The recovered system prompts its communication partners to provide details of the IDocs exchanged between the systems during the time affected.
2. The communication partners of the recovered system report back this information.
3. The information reported back is compared to the information in the recovered system. This process determines what further activities are required to
recover a consistent status in the entire distributed environment. The status of IDocs is updated in the recovered system.
4. A list of documents to be canceled in the communication partner systems is created. If necessary, IDocs are sent again automatically.
The recovery tools show the inconsistencies found. You must resolve inconsistencies in application objects manually. You can resolve some inconsistencies
in the IDoc messages (depending on the IDoc processing status), directly with the recovery tools.
Activities
Use the following transactions to find and resolve inconsistencies:
Determine recovery objects: Transaction code BDRC
Process recovery objects: Transaction code BDRL
PUBLIC
Page 50 of 51
For more information, see the program documentation.

The following functions are also available:
Application log for ALE recovery procedure: Transaction code BDR1
The relevant parameters specified in the transactions Determine recovery objects and Process recovery objects, are recorded in a log. You can display the
log in Transaction BDR1.
Reorganization of the data for recovery objects: Transaction code BDR2
The data generated in the transactions Determine recovery objects and Process recovery objects, is used to identify the status of the recovered objects.
This data is deleted when it is reorganized if the following conditions apply:
The recovered objects do not need to be processed further.
The recovered objects have already been processed.
PUBLIC
Page 51 of 51

Workflow Administration

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

Workflow Administration

Uploaded by

Copyright:

Available Formats

Administration

PDF download from SAP Help Portal:

1.2.3.1.3 Scheduling IDoc Posting

1.1 IDoc Administration

The IDoc Administration comprises the following functional areas:

Additional Settings (Customizing)

1.1.1 IDoc Monitoring

1.1.1.1 IDoc Display

1.1.1.1.1 Edit Status Values

1.1.1.1.2 Edit Status Groups

1.1.2.2.3 IDoc Search

To be able to search in the archive information system, you must have

1.1.1.3 IDoc Statistics

Flagged for deletion

Flagged for deletion

1.1.1.4 Monitor IDoc Inbound Queue

1.1.1.5 Monitor IDoc Outbound Queue

1.2.1.3.1 Error and Status Processing

1.1.1.7 Active Monitoring

1.1.1.7.1 Schedule Monitoring Job (Example)

1.1.2 Archiving IDocs

Archiving Application Data

General archiving information

Displaying or Changing Archivable Statuses

you can display or change all statuses one after another.

1.1.2.2 Archiving Functions for IDocs

1.1.2.2.1 Archiving and Deleting IDocs

( transaction code SARA) .

You can ignore the warning but you then

Continue and save your variant.

7. Return to the archiving screen and choose

1.1.2.2.2 Listing IDoc Numbers in Archive

1.1.2.2.3 IDoc Search

To be able to search in the archive information system, you must have

1.1.2.3 Archiving: Technical Background

general archiving authorization.

1.1.2.3.2 Archiving: Describing Standard Reports

Writes IDocs to the archive. Calls

Deletes archived IDocs from the database. Calls

Archive files from incomplete archiving sessions

Reads IDocs from an archive. Calls

Archive files from complete archiving sessions

Time at which the control record was last

Creates index in table EDIDOCINDX. Calls ADK

None: Reads the archive files of the IDOC object

Removes index in table EDIDOCINDX. Calls ADK

Date, up to which the indexes should be deleted.

Contains the IDoc control record

Contains the IDoc data records

Contains the IDoc status records

1.1.2.4 Deleting Links with IDocs

If you want to trigger the following links...

Then you must choose the link type...

Application document with outbound IDoc

Inbound IDoc with application document

Outbound IDoc with application document in the target system

Inbound IDoc with application document from the front-end system

Inbound IDoc with communication IDocs in distributed systems

Copy of an IDoc with its original

IDC3 (inbound), IDC7(outbound)

Inbound IDoc with outbound IDoc from the front-end system

IDC8 (inbound), IDCA (outbound)

Outbound IDoc with reference IDoc (type IDCREF01)

1.1.3 Additional Settings