ALE- IDOC

ALE (Application Link Enabling) &

IDOC (Intermediate Document)

 Author: Harish Kollipara

ALE Introduction

Application Application Linking Enabling(ALE)

Is an R/3 technology that enables enabl es you to construct and operate distributed applications, sometimes in different countries.

 Allows efficient and reliable communication between distributed processes.

Guarantees the distribution and synchronization of master data, Customizing data and transaction data through asynchronous communication.

Synchronous connection is used in ALE to read data only.

2

ALE Introduction

Application Application Linking Enabling(ALE)

Is an R/3 technology that enables enabl es you to construct and operate distributed applications, sometimes in different countries.

 Allows efficient and reliable communication between distributed processes.

Guarantees the distribution and synchronization of master data, Customizing data and transaction data through asynchronous communication.

Synchronous connection is used in ALE to read data only.

2

ALE Benefits

      Application      Data

data can be distributed between different dif ferent releases of SAP systems

can continue to be exchanged after a release upgrade without requiring

special maintenance      Customers

can add their own enhancements enhancemen ts

     Communication      SAP

interfaces enable connections to non-SAP systems

R/3 and R/2 Systems can communicate with each other 

3

ALE Services Applications      Applications

services: services: this layer provides ALE with an interface (for instance:

BAPI) BAPI) to R/3 to facilitate facili tate data exchange to or from external R/3 systems. services:      Distribution services:

the onus of filtering and converting messages

exchanged between SAP and non-SAP systems is on the distribution l ayer of   ALE. This service is the core service and acts as a san dwich layer between application and communication layers. services:      Communications services:

ALE supports synchronous as well asynchronous

communication. Synchronous messaging is used for the direct readi ng of control data, while asynchronous messaging is used for transmitting or receiving application data.

4

ALE vs EDI Differences

between ALE and E DI

ALE (Application (Application Link Enabling) is a way of transferring data between systems i.e SAP to SAP. EDI or Electronic

Data Interchange

is a process in which data is i s transferred

between an SAP system and another system. The latter one can be a non-SAP system too.

The main difference between EDI EDI and ALE is in the transfer of data. For EDI EDI, the transfer of data(I data( Idocs) docs) is through a flat file. Where as in ALE, it is from Memory to memory m emory transfer.

5

Idoc      

Intermediate document

     

It is not a process

     

It is a data container used to exchange information between any two processes(SAP to SAP or SAP to non-SAP) that can understand the syntax and semantics of the data

     

In the SAP system, these are stored in database tables

     

Every Idoc has an unique number 

     

Independent of the sending and receiving systems

     

IDocs are based on EDI standards, ANSI ASC X12 and EDIFACT, but are closer to the EDIFACT standards

     

Independent of the direction of data exchange

     

Can be viewed in a text editor and do not contain any binary data

6

Idoc overview  An IDoc type consists of three parts: 

Control

Record: This section contains control information regarding the Idoc. Its

constituents are Sender¶s name, Receiver name, Message type an d Idoc type. The format of the control record is similar for all IDoc types. The values are stored in table EDIDC. 

Data

Record: It consists of a header that contains the identity of the Idoc. Its

constituents include, a sequential segment number, a segme nt type description and field containing the actual data of the segment. The values are stored in table EDID4 or EDID3. 

Status record: This shows the information regarding the already processed stages and remaining processing stages of the Idoc. It has an identical format for  each IDoc type. The values are stored in table EDIDS.

Every Idoc contain one control record ,one or many data records and one or many status records.

7

Idoc Structure Idocs support a hierarchical structure. The end of the Idoc is represented with the help of ACCUM (means accumulate) segment. IDoc can only contain character fields.

8

Idoc Status Refer Table TEDS1 for all status codes. Successful Transmission: 03 - Successful outbound transmission 12 ± Dispatch OK IDoc being processed: 01 - IDoc created 30 - IDoc ready for dispatch IDoc Processed Successfully: 50 - IDoc added 53 - Successful posting IDoc ready for processing: 64 - IDoc ready to be passed to application. Errors in IDoc Processing: 51 - Error - application document not posted 56 - IDoc with errors added (You should never see this error code) 60 - Error during syntax check of IDoc (inbound) 61 - Processing despite syntax error (inbound) 63 - Error passing IDoc to application 65 - Error in ALE service - indicates partner profiles are incorrect 69 - IDoc was edited

9

ALE Process Outbound      Sends

Process

data to one or more SAP systems

Process flow for an outbound ALE process

Inbound

Process

     Receives

an IDoc from the remote system and creates a document in the SAP system

Process flow for an Inbound ALE process

10

ALE Outbound Distributed SAP systems exchange three types of data for a chieving a distributed yet integrated environment.

     Transactional

data

Ex: Sales orders, purchase orders, contracts, invoi ces, G/L postings      Master

data

Ex: Material master, customer master, vendor master, em ployee master       Control

data

Ex: Company codes, business areas, plants, sales organizations, distribution channels, divisions.

Transactional and Master data are distributed using the ALE interface layer. Control data is transferred using the regular CTS (Correction and Transport  System) process.

11

Outbound Components

     Logical

Ex:

System

D11CLNT400 

     Customer

Ex:      Idoc

Ex:

Model

Z15T EG1 Type

     Filter

Ex:

Program

Object

     Conversion

Definition tRFC Port 

      RFC

Ex:

Destination

LSIDE S800 

      Partner

Ex:

MATMAS03

     Selection

      Port

Profile

Partner Type LS(Logical System)

      Service

Program

Ex:RS EOU T00        Configuration

Tables

Rule

12

Outbound Components contd.

Logical System The systems involved in distributed processing are assigned lo gical names, which uniquely identify systems in a distributed environment.

Customer Model

Identifies the systems involved in a distribution scenario and the messages exchanged between the systems.

Idoc

Types

 An IDoc type defines the structure and format of the data being exchanged. For example, the IDoc type MATMAS03 defines the format of an Material Master  for the message Type MATMAS. IDoc data can be seen as an instance of an IDoc type.

13

Outbound Components contd. Selection Programs These are implemented as those which extract application data and create a master IDoc. A selection program exists for each message type. A selection program's design depends on the triggering mechanism used in the process.

Filter Objects In a distributed environment, each recipient of data can have different requirements for the data being distributed. Filter objects remove unwanted data for each recipient of data.

Port Definition  A port is used in an outbound process to define the medium in which documents are transferred to the destination system. ALE uses a tRFC ( Transactional  Remote Function Call ) port, which transfers data in memory buffers.

14

Outbound Components contd. RFC Destination The RFC (Remote Function Call) destination is a logical name used to define the characteristics of a communication link to a remote system on which a function needs to be executed. In ALE, the RFC specifies information required to log on to the remote SAP system to which an IDoc is being sent.

Partner Profile  A partner profile specifies the components used in an outbound process (the logical name of the remote SAP system, IDoc type, message type, and tRFC port), an IDocs packet size, the mode in which the process sends an IDoc (batch versus immediate), and the person to be notified in case of errors.

Service Programs and Configuration Tables The outbound process, being asynchronous, is essentiall y a sequence of several processes that work together. SAP provides service programs and con figuration tables to link these programs and provide customizing options for an outbound process. 15

Configuring ALE Infrastructure

     Basic

settings for Idocs

     Communication       Advanced

Settings

Settings

16

Basic Settings of Idocs Number

Range of Idocs Transaction: OY SN 

Number Range for Idoc(Inbound/ Outbound):16 digit.

17

Communication Setting ² Logical System Maintaining

a Logical System

Transaction : BD54

Note:

Make an entry for both sending and receiver systems in all the systems in the distributed network. 18

Communication Setting ² Logical System Allocating Logical Systems to the

Client

Transaction: SCC4  Allocate the client to the logical system in all the systems in the distributed network.

19

Communication Setting ² RFC Destination RFC Destination Transaction: SM59 Technical settings tab

IP address of the receiver system

System Number   20

Communication Setting ² RFC Destination RFC Destination contd. Logon and security tab.

Receiver system logon details

21

Port Definition Port Definition Transaction: W E2 1

RFC Destination 22

Outbound Process- Master Data Distribution

Master data can be distributed in the following cases 1. Transferring data from Dev, Quality .. systems to production systems 2. Transferring master data from production systems to test systems 3. Transferring configuration data

Ways of exchanging master data between systems 1. Push Original Copy 2. Push Changes 3. Pull master data

Master data between SAP systems is distributed using two techniqu es 1. Standíalone programs 2. Change pointers

23

Outbound Process- Master Data Distribution Outbound

contd.

Process via StandíAlone Programs

Stand-alone programs are started explicitly by a user to transmit data from one SAP system to another. These provide a selection screen to spe cify the objects to be transferred and the receiving system. These when executed call s the Idoc selection program which is hard-coded in the program. Ex: Material master data can be transferred using the RBDSEMAT program or  transaction BD10.

Outbound

Process via

Change

Pointers

This technique is used to initiate the outbound process a utomatically when master  data is created or changed. A standard program, RBDMIDOC, is scheduled to run on a periodic basis to evaluate the change pointers for a message type and start the  ALE process for distributing the master data to the appropriate destination. Ex: If a user changes the basic description of a material master or creates a new material, the system automatically generates an IDoc for the material and sends it to the destination system.

24

Configuring the Distribution Data

To distribute any data between the systems via ALE, the following configuration should be done. 1. Configuring ALE Infrastructure 2. Maintain a distribution model. 3. Generate a partner profile 4. Distribute the distribution model

25

Distribution Model Maintaining

the

Distribution Model

Transaction: BD64 Used to model a distributed environment in which you specify messages exchanged between sending and receiving systems. Create a model view 

26

Distribution Model contd. Then add a message type to transfer between two systems.

Note: A distribution model is maintained on only one system. It is distributed to other systems for  use. Two models cannot distribute the same message between the same set of senders and receivers. 27

Partner Profile Transaction: BD8 2  Partner profiles can be generated automatically for your partner systems. The distribution model and settings in the ALE tables TBD52 and EDIFCT are read to generate partner profiles and port definitions.

Note: The process code and function module is taken from tables EDIFCT and TBD52.

28

Partner Profile contd. The partner profile can be viewed with Transaction WE20.

MATMAS Message type 29

Distributing the Model Transaction:BD64  After all the necessary configurations for Model(message type, port, partner profile, logical systems) distribute the model to the systems in the distributed network.

Note: After selecting the Distribute, select the target Logical system to proceed.

30

Push Approach In this data is transferred explicitly from one system to another. Transaction : BD10 or e x ecute program RBDS E MAT 

If kept blank, the system assumes that you want t o send all the materials.

31

Outbound Idoc View You can view the Idoc using Transaction W E 02   /W    E 05 and by giving the necessary details. The Idoc contains the material master data to be transferred to the receiving system.

Current Idoc status

32

Outbound Process- Push Approach Outbound Process with Push Approach by Stand-Alone Program Standíalone programs are started explicitly by a user to transmit data from one SAP system to another. Standard programs for several master data objects exist in SAP. Ex: For Material master data ,the program is RBDSEMAT or transaction BD10.

Process flow for an outbound process for master data 33

Outbound Process- Push Approach contd.

Processing in the Application Layer  Based on the receiver and the message type to be transmitted, the distribution model is read.

If at least one receiver exists, then the IDoc selection program reads the master  data object from the database and creates a master IDoc from it.

The master IDoc is stored in memory.

The program then calls the ALE service layer by using function module MASTER_ IDOC_DISTRIBUTE, passing it the master IDoc and the receiver  information.

34

Outbound Process- Push Approach contd. Processing in the ALE Layer  

If the receivers are not known, they are determin ed from the customer distribution model. If a receiver is not found, processing ends.



For each receiver, these steps occur.



IDoc filtering



Segment filtering



Field conversion



Version change for segments



Version change for Idocs



Communication IDocs generated Based on filter operations and no. of receivers one master Idoc can have multiple communication Idocs and are saved in SAP database . The IDoc gets a status record with a status code of 01 (IDoc Created).



Syntax check performed If errors are found, Idoc gets a status code 26 (Error during Syntax Check of Idoc Outbound). if no errors are found, the IDoc gets a status code of 30 (IDoc Ready for  Dispatch ALE Service). 35

Outbound Process- Push Approach contd. Processing in the ALE Layer contd. 

IDocs dispatched to the communication layer  The timing of dispatch is read from the output mode in partner profile. If the mode is set to Transfer IDoc Immed., IDocs are immediately transferred to the communication layer; if not, they are buffered until the next run of dispatch program RSEOUT00. If transferred to the communication layer, Idocs get a status code of 03 (Data Passed to Port OK).

Processing in the

Communication

Layer 

Then the system reads the port definition from the partner profile and from it the RFC destination is known.

The sending system calls the INBOUND_ IDOC_PROCESS function module asynchronously on the destination system and passes the IDoc data via the memory buffers. Then the Idoc gets a status code of 12(Dispatch OK).

36

ALE Inbound

The inbound process must handle three types of data. 1. Transactional data 2. Master data 3. Control data

Transactional and master data are received via the ALE interface layer. Control data is received via the CTS process.

Ways of posting the transactional and master data 

Via a function module



Via workflow

37

Inbound Components



IDoc structure Ex: MATMAS03



Posting programs Ex: IDOC_ INPUT_MATMAS01 for MATMAS message.



Filter objects



Conversion rules



Partner profile Ex: Partner Type KU(customer ), Partner Type LS(Logical System)



Service programs Ex: RBDAPP01



Configuration tables Ex: TBD51

38

Inbound Components contd. Posting Programs These are implemented as function modules, read data from an IDoc and create an application document from it.  A posting program exists for each message. Each posting program is assigned a process code.  A process code can point to a function module or a workflow. Ex: For MATMAS message type ,the posting program is IDOC_ INPUT_MATMAS01 and the process code is MATM.

Partner profile This specifies the partner number, message type, process code, the mode in which IDocs are processed (batch versus immediate), and the person to be notified in case of errors.  An inbound record exists to receive an inbound message from remote SAP system.

39

Partner Profile Partner profile This specifies the partner number, message type, process code, the mode in which IDocs are processed (batch versus immediate), and the person to be notified in case of errors.  An inbound record exists to receive an inbound message from remote SAP system.

Trigger immediately  40

Inbound Process via Function Module

Process flow

Technical Flow

Note:V er :4.0  x  Idocs: IDOC_INBOU ND_AS Y NCHR ON OU S  V er :3.0   x  Idocs

-INBOU ND_IDOC_PR OC E SS  41

Inbound Process via Function Module contd.

Processing in the

Communication

Layer 

The IDOC_ INBOUND_ASYCHRONOUS program, triggered as a result of an RFC from the sending system, acts as the entry point for all inbound ALE processes. The IDoc to be processed is passed as an input parameter.

42

Inbound Process via Function Module contd. Processing in the ALE/E DI Interface Layer  Basic integrity check: On control record, direction, message type, and IDoc type is checked. Segment filtering and conversion. Application

IDoc

is created

The application IDoc is stored in the database, and a syntax check is performed on it. The IDoc gets a status code of 50 (IDoc Added).If the IDoc fails the syntax check, it gets a status code of 60 (Error during Syntax Check of Idoc Inbound). IDoc

is marked ready for dispatch: Idoc gets a status code of 64 (IDoc Ready to

Be Passed to Application). IDoc

is passed to the posting program

The partner profile table is read. If the value of the Processing field is set to Process Immediately, the IDoc is passed to the posting program immediately, using the program RBDAPP01. If the field is set to Background processing, the IDoc is buffered in the system until RBDAPP01 is executed explicitly. 43

Inbound Process via Function Module contd.

Processing in the Posting Module The process code in the partner profile points to a posting module for the specific message in the IDoc. If the posting is successful, an application document is created. The IDoc gets a status code of 53 (Application Document Posted). If the IDoc contains errors, it gets a status of 51 (Error: Application Document Not Posted).

44

Inbound ALE Idoc View You can view the Idoc using Transaction W E 02   /W    E 05 and by giving the necessary details.

45

Transaction Main

Codes

menus

WEDI

Main menu for EDIírelated activities

BALE

Main menu for ALEírelated activities

SWLD

Main menu for workflowírelated activities

SALE

Main area for ALE configuration

NACE

Main menu for Message control configuration

IDoc Definition

SE11

Data dictionary

WE31

Segment editor  

WE30

IDoc editor to create and extend IDoc type

BD53

Reduce IDoc types for master data

WE60

IDoc documentation (IDoc structure and segment definition)

WE61

IDoc documentation (control record, data record, and status record)

IDoc Monitoring

WE02

IDoc display

WE05

IDoc list

WE07

IDoc statistics

AL11

SAP Directories 46

Transaction

Codes contd.

Configuration (Basic Infrastructure

for ALE and EDI)

WE20

Maintain partner profile manually

BD82

Generate partner profiles automatically

WE21

Port definitions

SM59

RFC destination

BD64

Maintain customer model

BD54

Define a Logical System

SCC4

Assign a client to the Logical system

Testing WE19

Test tool for  IDocs

WE12

Convert an outbound IDoc to an inbound IDoc

WE16

Process an incoming IDoc file

WE17

Process an incoming status file

Reprocessing IDocs BD88

Process outbound IDocs (before 4.6A)

BD87

Manual processing of  Idocs

Miscellaneous

XD02

Maintain customer master   47

Transaction

Codes contd.

Miscellaneous contd.

XK02

Maintain vendor master  

MM02

Maintain material master  

VA01

Create sales order  

ME21

Create purchase order  

ME11

Create purchasing information records

BD10

Material Master Data Distribution

BD12

Customer Master Data Distribution

BD14

Vendor Master Data Distribution

Configuring New Components

WE81

Create new message type

WE82

Link IDoc type and message type

W E41

Create outbound process code

W E42

Create inbound process code

WE57

Allocate inbound function module to message type

BD51

Define settings for inbound function module

BD67

Assign input methods for a process code (inbound) 48

Programs The following programs are scheduled to run on a periodic basis for processing at different layers of ALE and EDI processes. 1.

RSNAST00: Processes buffered entries in the NAST table

2. RBDMIDOC: Generates IDocs by processing change pointers that have been logged for changes made to master data objects 3.

RSEOUT00: Processes outbound IDocs (status 30) that have been buffered to

support mass processing 4.

RBDAPP01: Processes inbound IDocs (status 64) that have been buffered to

support mass processing 5.

RBDMANIN: Reprocesses inbound IDocs that failed because of application

errors (status 51) 6.

RBDMOIND: Updates the status of IDocs that have been successfully

dispatched to a receiving SAP system 7.

RSEIDOCM: Can be scheduled to run as a monitoring program

49