ALE AND IDOCS OVERVIEW

. 1
 ALE
ALE is a business solution to a very real need emerging in the SAP
market. This is the need for businesses to move towards tighter
integration between systems, yet, at the same time, provide
independence to the various business units within the company.
In the past the move was towards centralized systems

Standardization of business processes accompanied by ever tighter

integration within the central system no longer represents a practicable
approach to this problem. The following are some of the most commonly
encountered difficulties:

technical bottlenecks
upgrade problems
the effect of time zones on international
Corporations
excessively long response times in large centralized systems

. 2
 The SAP Solution - ALE

SAP has provided ALE (Application Link Enabling) as the solution to these
issues. It allows you to:

Distribute your applications across several SAP systems,

such that centralized functions, as well as decentralized
functions can operate in the same company arena

Maintain and distribute master data elements from a central

system, thus maintaining unique number ranges across
several systems

Couple R/2 and R/3 systems, in some instances

Couple SAP and external systems, via IDOCs

(Intermediate documents) and an external translation
mechanism

. 3
 How ALE Works?

ALE allows the user to perform an SAP transaction in the sending system,
after which the following steps occur:
One or more communication IDOCS (intermediate documents: container
for the application data) are created in the sending system database. An
ALE distribution model, that needs to have been configured, determines
which systems the IDOCS are to be sent
These communication IDOCS, that contain the relevant application data of
the transaction that was performed, are then passed to the ALE
communication layer
This layer performs an RFC call using the port definition and RFC destination
determined through the customer model
The IDOCS are then transferred to the respective receiving systems.
These could be SAP R/3, R/2 or external systems

. 4
 IDOC INTERFACE

Business data is exchanged with an external system using the IDOC

Interface. The IDOC Interface consists of the definition of a data structure
and a processing logic for this.

The data structure is the IDOC. It is the exchange format that unites the
communicating systems. Using IDOCS you can define an exception
handling within the R/3 System using SAP Business Workflow, without the
need for the data to already be an SAP application document.
You require the IDOC Interface in the following
scenarios: Electronic Data Exchange (EDI)
Application Link Enabling (ALE)
Linking to any other business application systems (for example, PC
Applications, external workflow tools) using IDOC.
What is an IDOC ?
The term IDOC stands for Intermediate Document. Its
not a process. An IDOC is simply a data container that is
used to exchange information between any two
processes that can understand the syntax and
semantics of the data.

An IDOC is created as a result of execution of an outbound

ALE or EDI process. In an inbound ALE or EDI process, an
IDOC serves as an input to create application document.

IDOCS are independent of sending and receiving system.

They can be used for SAP to SAP and SAP to non-SAP
process communications as long as the participating
processes can understand the syntax and semantics of
the data.

IDOCS are independent of the direction of data exchange. An IDOC

can be used by an inbound as well as an outbound process.
For e.g the ORDERS01 IDOC is used by the purchasing module to
send a purchase order and is also used by the sales and distribution
module to accept a sales order. This avoids creating redundant
IDOC types for the same information.
ID O C C o n c e p t

A s y n c h ro n o u s
D o c u m e n t - r e la t e d

S ys t e m 1 S y ste m 2

SAP D ocum ent

Docum ent
iD o c T r a n s a c t io n
M essag e

1 R 13 S y s te m 1 EDi s u b s y s te m
1 R 13 S y s te m
1 R 12 S y s te m
1 3 rd p a rty s o ftw a re

S A P A G 1999 ID o c E n jo y ( T h . B e c k e r ) / 5

. 8
The business data is saved in IDOC format in the IDOC interface and is
forwarded as IDOCs. If an error occurs, exception handling is triggered
via workflow tasks. The agents who are responsible for these tasks and
have the relevant authorizations are defined in the IDOC interface.
The IDOC interface supports three types of data flow with the
external system:
Outbound Processing
IDOCs are transferred to a receiving system from your SAP System

Inbound Processing
IDOCs are transferred to your SAP System from an upstream system.
Status Processing
The receiving system confirms the processing status of outbound
IDOCs to your SAP System.

. 9
IDOC Data Flow

Outbound Data Inbound

Application MM Application
SD
...

Message Control Workflow

IDOC interface & IDO IDOC interface &

ALE Servi ces C ALE Servi ces

System 2 File System 2

e.g. EDi subsy stem tRFC e.g. EDi subsy stem
XML
...

. 10
Outbound Data Flow

SAP Applicatio n

Document

Message Contr ol (NAST)

Document
NAST
Record

iDo c interface & ALE Services

IDO
C

System 2, e.g. EDi subsystem

. 11
inbound Data Flow

System 2, e.g. EDi subsystem

IDO
C

iDo c interface & ALE Services

IDOC +
Process

SAP Business Workflow IDOC +

Fun ction Modu le

Docu me nt

SAP application
 ADVANTAGES OF USING IDOCs
For Eg. Standard IDOC MATMAS01 is used to exchange material master information
with the legacy system in version 3.1G. Now the company decides to go in for a
version upgrade to 3.1H in which MATMAS01 has been enhanced .You can continue
to use the older version and then decide to switch to the enhanced IDOC later.

Ability to create and enhance IDOCs

Using the standard tools ( IDOC editor and segment editor ) you can either enhance
standard SAP IDOCs or create new IDOCs in the system to support custom
interface.

The newly developed IDOCs integrate seamlessly into the standard ALE/ EDI
interface because they are developed using standard tools provided by the system.
They also become available in the standard list of SAP IDOCs and can take
advantage of all the tools are designed like IDOC monitoring, error handling and
archiving.
Following are the benefits of IDOCs over Flat files.

Independence from Applications

The biggest advantage of using the IDOC interface is that its an open
interface i.e independent of the internal structure used by SAP to store
data and independent of sending and receiving applications.

Communication with Back-Level IDOCs

The standard IDOCs and the segments within the IDOC have a version
associated with them.Each time a standard IDOC or a segment is
enhanced,
the system assigns it a newer version. Partner applications that were developed
using a previous version of the IDOCs are fully supported.
SAP can generate and process back-level IDOCs. This version management
technology offers backward compatibility.
Custom IDOCs are distinguished from SAP IDOCs by their names, as they start with
Z.

Standard Monitoring Tools

Several tools are available to monitor the state of the system. They range from simple
IDOC display to IDOC statistics.

IDOC type Documentation

Each IDOC in the system is thoroughly documented .The usage is detailed down to the
field level with possible values for each field and how it affects the process.

The documentation of any IDOC can be obtained using transaction

WE60.
Archiving Tools
Tools are available for miscellaneous tasks such as archiving , data cleanup and
restoring information back into SAP.

15
 USE OF
IDOCs
EDI integration

EDI is electronic exchange of business documents between SAP and non-SAP systems.
Several applications (purchasing, sales or shipping) in SAP are enabled for EDI.

To use EDI first the application document viz.. Purchase order is created. EDI interface
layer converts the application document into an IDOC which is transferred to an EDI
subsystem. The EDI subsystem translates the IDOC into an industry-standard format
and then transfers it to a business partner over a network.

ALE Integration

ALE (Application Link Enabling) enables the exchange of data between two SAP
systems. This system allows SAP business processes and applications to be
distributed across multiple SAP systems.ALE ensure integration in a distributed SAP
environment.
OCR Application integration

OCR (Optical Character Recognition) is a technology that scans and interprets printed
matter using pattern recognition. You can integrate an OCR application with SAP via
IDOCs. Documents in a standard format can be scanned to generate IDOCs, which
Then can be transferred to the SAP system for processing.

ICR Application integration

Bar-code system is an example ICR (Intelligent Character Recognition) technology.

Data encoded using bar-codes can be captured and stored as an IDOC, which then
can be passed to SAP for further processing.

. 17
Comparing Flat File Structure
to
IDOC Structure
The best way to explain the IDOC architecture is to compare your legacy world to how
SAP implements the same concept in IDOC.

Lname(10) Fname(10) SSN(11) DOB(8) Employee header occurs once mandatory

Week no(1) Hrs worked(3) Hrly rate(3) Client site(20) Work des.(50) Weekly details multiple
Total hrs(3) Total amount(10) Summary once

Assume that you have an application that records an employees weekly hours .
At the end of the month, a file containing the monthly report data for each is
sent to external system. This application has been replaced by the SAP system ,
and a standard IDOC has been developed to support the process.

. 19
Following are some properties of the file:

It has three types of records: employee header information,

weekly details and monthly summaries.

Each record type has certain properties, such as whether its

optional or mandatory, number of times it can be repeated,
field names, data type for each field, and length of each field.

The client site and work description in the weekly details is

not always available.

. 20
IDOC version of the flat file

ZMREPT01 Segments
Lname Fname SS N Dob
Z1EMHDR
(M,1,1)

Z1WKDET
We ek n o Hrly Rate Tot Hrs
(O,1,99999)

Z1CLDET
(O,1,1)
Clsi te W or k de sc.

Z1SUMRY
(O,1,1)
Tot hrs Tot amount

21
Comparison

Smith John 123-45-6789 102668

1 30 40 Houston Brewery Beer Testing
2 30 40 Network Computers High Level Consulting
3 30 50 Network Computers Programming
4 50 60 DSP Sys tems EDI Programming

140 6900

An example of the mon thly report file fo r o ne par ticular emp loyee

. 22
IDOC DEFINITION COMPONENTS

Name:

A basic IDOC type can be assigned up to a thirty-character name in release 4.0

onwards. To encompass all releases we have used an 8 character name ZMREPT01.

Custom IDOC types always start with Z the last two character represents the version
number.After a basic IDOC type is released and you move to a newer version of the
SAP system, any changes to the structure of the basic IDOC type will create a new
basic IDOC type i.e the version number is incremented by 1.

Thus ZMREPT02 represents an enhanced version of this IDOC. Segments of a

previous version are never deleted. This is necessary to maintain backward
compatibility.

. 23
List of permitted segments:

These segments make up the IDOC structure. The current example has four segments:
Z1EMHDR, Z1WKDET , Z1CLDET and Z1SUMRY.

Arrangement of segments:

Arrangement specifies the physical sequence and any parent-child relationship in the
segments. A parent-child relationship signifies that the child segment cannot exist
without the parent and is commonly used for text segments. It gives an IDOC type a
hierarchical structure.

. 24
Mandatory versus Optional segments:

When used in an IDOC type, each segment has an attribute that defines whether
the segment is optional or mandatory.

In the example given, Z1EMHDR is a mandatory segment because the monthly report
will not make sense without the employees basic information.

Minimum / Maximum range for each segment:

Each segment has an attribute that defines the minimum and the maximum number
of times a data record corresponding to a segment can exist in an IDOC.

In the example given, data records corresponding to the Z1WKDET segment can
occur multiple times.

. 25
SEGMENTS

A segment defines the format and structure of a data record. Segments are a
reusable component, which means they can be used in more than one IDOC type. A
segment consists of various fields that represent data in a data record.

Segment Components

A segment in the SAP system is technically implemented as three physically separate

pieces.

1) Segment type
This is version independent name of the segment. SAP provided segment types begin
with E1, whereas custom-defined segment types begin with Z1.

In the example Z1EMPHDR and Z1WKDET are segment types.

. 26
2) Segment definition

This is version dependent definition of a segment where you specify the fields that
belong to the segment. SAP segment definitions start with E2, whereas customer
segment definitions start with Z2.

The name of a segment definition is 10 characters long and is automatically assigned

by the system from the name of the segment type.

For e.g for the segment type E1EDKA1, the segment definition is
E2EDKA1.

The last three characters represent the version of the segment. The first
segment definition has spaces in last three characters. The last three characters
are incremented by 1 to reflect the new definition.

. 27
IDOC Definition Components

Seg ment definitions

Z2TEST Z2T EST 001 Z2T EST002

Field 1 Field 1 Field 1

Field 2 Field 2 Field 2

Field 3 Field 3 Field 3

Field 4 Field 4 Field 4

Field 5 Field 5

Field 6

. 28
3) Segment Documentation

This represents the data dictionary documentation for each field in the segment
definition. Segment documentation of SAP-provided segments begins with E3,
whereas the segment documentation of customer-defined segment types with Z3.

There is only one segment documentation per segment.

. 29
IDOC RUN TIME COMPONENTS:

Although there are several records in an IDOC, they are still classified as
one of the three record types.

Control Record
Data Record
Status Record

At run time the following events occur:-

A unique IDOC number is allocated.

One control record is attached to the IDOC.
Segments translate into data records.
Status records are attached.
Syntax rules are checked.

. 30
Structure of a IDOC type

IDOC are nothing but container of data for ALE and EDI process
It is basically a structured format for carrying data.
IDOC type is a IDOC structure without the data, at run time it
is called as IDOC.
Message type is mapped to a IDOC type.
Each IDOC type will have a inbound program and a
Outbound program. The program will create the particular
IDOC.

Name
Segments (no. of segments will be present in IDOC, Segment
definition, Segment documentation,)
Segments are stored separately
Segments can be mandatory or optional
Segment definition is 10 char Auto generated + 3 char for SAP
Version (hence backward compatibility)
ID OC R eco rd Types

Control Record ID oc-ID

Sender-ID
Receiver-ID
ID oc type and logical m essage
External structure

Data Record ID oc-ID

Sequence/Hierarchy
Segm ent Form at definition for
header data
item data

Status Record ID oc-ID

Status inform ation

. 32
Transaction WE02 0r WE05 (IDOC Display)

. 33
Control Record

As the name suggests contains all of the control information about an IDOC, this
basically includes IDOC number, sender and receiver information such as the
message type it represents and the IDOC type.

A control record can be compared to an envelope of a letter, by looking at the

envelope; you can identify the sender and the recipient.

It has following characteristics

There is one and only one control record per IDOC.

The structure of the control record is the same for all IDOCs and
is defined by SAP.
It is stored in EDIDC table

. 34
Control Record as viewed by IDOC display tool

. 35
Data Records

In an IDOC, data records contain the application data. The employee

header information, weekly details, client details and summary information
reside in data records.

A data record has two parts: an administrative section and a data section.

Administrative section contains the segment name, segment

number and hierarchy level.
Data section is where the actual data resides. This is mapped to
a segment type.

Data records are stored in the EDIDD table.

The complete documentation of the data record can be viewed by

using transaction WE61.

. 36
Status Record

These are attached to an IDOC throughout the process as the IDOC achieves different
milestones.
At every milestone a status code, date and time are assigned. The latest status code is
also maintained in the control record.

Status records have following characteristics:-

Multiple status records are usually attached to an IDOC.

In outbound processes, after the IDOC is passed from SAP to the subsystem, the
subsystem generates the status records and passes them to SAP.
For inbound processes, SAP generates the status records.

List of status code and there details can be seen by executing transaction WE47.

. 37
Details of a status code WE47

. 38
ID O C T y p e s

C o n t ro l R e c o rd

D a ta R e c o rd s

E 1H D D O C E1TLSUM

M 1 C 1

E 1H D AD R E 1 iT D O C

C 5 M 1

E 1 iT S C H

T r e e o f S e g m e n ts C 99 C 5

S ta tu s R e c o rd s

. 39
IDOC View Concept

z An IDOC v iew is a selection of segmen ts of a g iven IDOC ty

pe and is c ompatib le wit h the IDOC types sy nta x.
z iDo c views are applied in out bound pr oce ssing of
selected ap plications.
z Adva nta ges o f views:

Enh an cing the performance by restricting th e number of

tables read
Red ucing the data volume in internal tabl es at run time

. 40
ALE Configuration :-

1. Setting Up Clients
2. Defining Logical System Names for Clients
3. Defining Communication Parameters
4. Modeling the Distribution
5. Generating Partner Profiles in the Sending System
6. Distributing the Distribution Model
7. Generating Partner Profiles in the Receiving System
8. Creating Vendor Master Data
9. Sending Vendor Master Data
10. Checking Processing Status

. 41
Setting up Clients
Set up two clients to enable communication between logical systems.
The two clients may be located in the same R/3 System or in
separate systems.
To set up a new client, from the SAP standard menu choose Tools ->
Administration -> Administration -> Client administration -> Client
maintenance.

Defining Logical System Names for Clients

The name of the logical system is used as the unique ID. This name
is assigned explicitly to one client in an R/3 System.
You can find the functions required for this in the R/3
Implementation Guide(SPRO) under Basis Components -> Application
Link Enabling (ALE) under Sending and Receiving Systems -> Logical
Systems.

42
SETTING UP CLIENTS

. 43
DEFINING LOGICAL SYSTEMS FOR CLIENT

. 44
ASSIGNING LOGICAL SYSTEMS TO CLIENT

. 45
. 46
Defining the Communication Parameters

For the two logical systems to be able to communicate with one another, they
must know how to connect to each other. The RFC destination provides this
information.
In each of the two clients, you must assign the RFC destination for the other
logical system. In Customizing for ALE choose Sending and Receiving Systems
-> Configure Systems in Network -> Define RFC Destination.
Execute the function.
Choose Create.
Enter the RFC destination:
Use the name of the logical system that is to be the destination
(use UPPERCASE letters).

. 47
DEFINING THE COMMUNICATION PARAMETERS

. 48
49
Modeling the Distribution

Logon to the logical system from which you want to send materials to
another system (sending system LOGSYS010) .

From the R/3 Implementation Guide screen, choose Basis ->

Application Link Enabling (ALE) -> Modeling and Implementing
Business Processes -> Maintain Distribution Model.

Create the model view. Select Create model view. Enter the technical
name VENDMODEL and a description for it.

Define the sending and receiving systems and the message type.
Position the cursor on VENDMODEL and select Add message type.

A dialog box appears.

Enter the logical system name of the sender LOGSY010 and the
receiver LOGSY500 and the message type CREMAS.

Save the distribution model.

. 50
CREATING A MODEL VIEW

. 51
Generating Partner Profiles in the Sending
System

First, generate the partner profiles in the sending system (LOGSY010). To do

this, log on to the relevant logical system.
In the R/3 Implementation Guide under Basis, choose:
Application Link Enabling (ALE)
-> Modeling and Implementing Business Processes
-> Partner Profiles and Processing Time
-> Generate Partner Profiles
Enter VENDMODEL as the name of your distribution model.
Without changing the parameters proposed by the system, execute the
program.
The partner profiles required have now been generated on the sending
system.

. 52
GENARATING PARTNER PROFILES IN SENDING SYSTEM

. 53
Distributing the Distribution Model
Transport the distribution model views from the sending system to the
receiving system.
Carry out the following steps in the sending system:
In the R/3 Implementation Guide under Basis Components, choose:
Application Link Enabling (ALE)
-> Modeling and Implementing Business Processes
-> Maintain Distribution Model
Edit -> Model View -> Distribute.
Enter the model view VENDMODEL .
Select LOGSY500 , the name of the receiving logical system.
Execute the program.
Your distribution model view will be copied to the receiving system.

. 54
DISTRIBUTING THE MODEL VIEW

. 55
Generating Partner Profiles in the Receiving
System
you have copied the distribution model to the receiving system, you can also
generate the partner profiles here. To do this, log on to the receiving logical
system (for example, LOGSY500 ).
In the R/3 Implementation Guide under Basis Components, choose:
Application Link Enabling (ALE)
-> Modeling and Implementing Business Processes
-> Partner Profiles and Processing Time
-> Generate Partner Profiles
Enter the name of your distribution model view, in this case,
VENDMODEL.
Without changing the parameters proposed by the system, execute the
program.
The required partner profiles will be generated in the receiving system.

. 56
GENARATING PARTNER PROFILES IN RECIEVING SYSTEM

. 57
Creating Vendor Master Data

Once you have made all the settings required to distribute materials, you can
create a material and then distribute it.
Log on again to the sending system and follow these steps:
Choose the transaction XK01 for entering vendor details

. 58
Sending Vendor Master Data
You are now going to send the vendor you have just created to the receiving
system.
Choose TOOLS-> ALE -> MASTERDATADISTRIBUTION ->
-> CROSS APPLICATION-> VENDOR -> SEND
Enter the vendorl you have created (for example, Vendor001).
Use CREMAS Message type:
Enter LOGSY500, the logical receiving system
Execute the program.
You should now be able to display your vendor in the receiving system. If the
material is not available here, either the transmission has not yet finished or an
error has occurred. The next step shows you how to check the communication
and detect any errors.

. 59
SENDING VENDOR MASTER DATA

. 60
Checking Processing Status

The system provides functions for monitoring communication. These

functions enable you to confirm whether ALE messages have been
processed and transferred correctly or whether errors occurred. If an error
did occur, the type of error is indicated.
You can monitor the processing status in both the sending system and the
receiving system. Choose Tools -> ALE -> Administration -> Monitoring ->
Status monitor for ALE messages.
Execute the function, and select the IDOCs of the logical message type
MATMAS which you created today.
A list of inbound and outbound IDOCs grouped by status is
displayed:
A list of inbound and outbound IDOCs grouped by status is displayed:
OUTBOUND IDOCs

Status Description of Status

03, 12, 38 IDOC successfully transferred
02, 04, 05, 25, 26, 29 processing error
30 Waiting status (still processing...)
>=50 Inbound IDOC (not relevant in this context)
Other Not relevant in this context

. 62
. 63
INBOUND IDOCs

Status Description of Status

53 IDOC successfully updated by application
64 Waiting status (still processing...)
<50 Outbound IDOC (not relevant in this context)
51, 56, 60, 61, Inbound error
63, 65
Other Not relevant in this context

. 64
. 65
To display a list of IDOCs with a particular status, double-click on a
line. For detailed information on one of these IDOCs, double-click on it.
If an error occurs, you can display information about the cause of it by
choosing Process -> Incorrect segments.
Error Handling
If an error has occurred, use the monitoring function to resolve it. The
cause of the error is likely to be a value in your material that the
receiving system does not know and therefore cannot process it. Try to
eliminate the cause of the error and send your material again.
If your IDOC in the sending system was successfully transferred (status
03) but does not appear in the receiving system, a technical
communication error is the likely cause. You can use the status monitor
in the sending system to check this. Choose Goto -> Transactional RFC
-> Display calls.
If an error occurs you should consult your system administrator.

. 66
Transaction codes for ALE and IDOC:-

SALE for defining and assign logical systems

SM59 RFC destination
BD64 Customer distribution
model. BD82 Generating Partner
Profile
BD10 Sending Material
BD11 Getting the material
WE31 Segment creation
WE30 IDOC Type creation
WE41 Process code for Outbound
WE40 Process code for Inbound
WE81 Creating Message types
. 68