Professional Documents
Culture Documents
Ale and Idocs Overview
Ale and Idocs Overview
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
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.
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 te d
S y s te m 2
S y s te m 1
SAP
Docum ent
R /3 S y s te m
ID o c
EDI
R /3
R /2
3 rd
D ocum ent
T ra n s a c tio n
M essage
s u b s y s te m
S y s te m
S y s te m
p a rty s o ftw a re
S A P A G 1 9 9 9 I D o c E n jo y ( T h . B e c k e r ) / 5
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.
Outbound
Application
Data
MM
SD
...
Message Control
System 2
e.g. EDI subsy stem
Inbound
Application
Workflow
IDoc
File
tRFC
XML
...
System 2
e.g. EDI subsy stem
10
SAP Applicatio n
Document
NAST
Record
11
IDoc +
Function Module
Document
SAP application
12
13
14
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 businessprocesses and applications to be distributed
across multiple SAP systems.ALE ensures integration in a distributed SAP
environment.
16
17
18
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)
Hrly rate(3)
Client site(20)
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
20
ZMREPT01
Segments
Z1EMHDR
(M,1,1)
Z1WKDET
(O,1,99999)
Z1CLDET
(O,1,1)
Lname
We ek n o
Clsite
Fname
Hrly Rate
SS N
Dob
Tot Hrs
W or k de sc.
Z1SUMRY
(O,1,1)
Tot hrs
Tot amount
21
Comparison
Smith
1
2
3
John
30
30
30
123-45-6789
102668
40
Houston Brewery
40
Network Computers
50
Network Computers
Beer Testing
High Level Consulting
Programming
50
60
EDI Programming
140
6900
DSP Systems
22
23
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
25
SEGMENTS
A segment defines the format and structure of a data record. Segments are reusable
components, 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
Z2TEST001
Z2TEST002
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
30
31
Control Record
IDoc-ID
Sender-ID
Receiver-ID
IDoc type and logical message
External structure
Data Record
IDoc-ID
Sequence/Hierarchy
Segment
Format definition for
header data
item data
Status Record
IDoc-ID
Status information
32
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
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
38
ID o c T y p e s
C o n tro l R e c o rd
D a ta R e c o rd s
E1H D D O C
M
E1TLSUM
C
E1H D A D R
C
E 1 IT D O C
1
E 1 IT S C H
T re e o f S e g m e n ts
99
S ta tu s R e c o rd s
S A P A G 1 9 9 9 ID o c E n jo y (T h . B e c k e r) / 7
39
Advantages o f views:
40
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.
42
SETTING UP CLIENTS
43
44
45
46
47
48
49
50
51
52
53
54
55
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
57
58
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
60
61
OUTBOUND IDocs
Status
03, 12, 38
Description of Status
IDoc successfully transferred
Processing error
30
>=50
Other
62
63
INBOUND IDocs
Status
53
Description of Status
IDoc successfully updated by application
64
<50
Inbound error
63, 65
Other
64
65
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
WE31
WE30
WE41
WE40
WE81
Segment creation
Idoc Type creation
Process code for Outbound
Process code for Inbound
Creating Message types
67
Thanks
68