ALE (Application Link Enabling)

&

IDOC (Intermediate Document)

Author: Harish Kollipara

ALE Introduction

Application Linking Enabling(ALE)

Is an R/3 technology that enables 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.

ALE Benefits

 Application data can be distributed between different releases of SAP systems  Data can continue to be exchanged after a release upgrade without requiring special maintenance  Customers can add their own enhancements  Communication interfaces enable connections to non-SAP systems  SAP R/3 and R/2 Systems can communicate with each other

ALE Services
 Applications services: this layer provides ALE with an interface (for instance: BAPI) to R/3 to facilitate data exchange to or from external R/3 systems.  Distribution services: the onus of filtering and converting messages exchanged between SAP and non-SAP systems is on the distribution layer of ALE. This service is the core service and acts as a sandwich layer between application and communication layers.  Communications services: ALE supports synchronous as well asynchronous communication. Synchronous messaging is used for the direct reading of control data, while asynchronous messaging is used for transmitting or receiving application data.

ALE vs EDI
Differences between ALE and EDI ALE (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 transferred between an SAP system and another system. The latter one can be a non-SAP system too.

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

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

     

Idoc overview
An IDoc type consists of three parts: Control Record: This section contains control information regarding the Idoc. Its constituents are Senders name, Receiver name, Message type and 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 segment 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.

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.

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

ALE Process
Outbound Process  Sends data to one or more SAP systems Inbound Process  Receives an IDoc from the remote system and creates a document in the SAP system

Process flow for an outbound ALE process

Process flow for an Inbound ALE process

10

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

 Transactional data Ex: Sales orders, purchase orders, contracts, invoices, G/L postings  Master data Ex: Material master, customer master, vendor master, employee 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 System Ex: D11CLNT400  Customer Model Ex: Z15TEG1  Idoc Type Ex: MATMAS03  Selection Program  Filter Object  Conversion Rule

 Port Definition Ex: tRFC Port  RFC Destination Ex: LSIDES800  Partner Profile Ex: Partner Type LS(Logical System)  Service Program Ex:RSEOUT00  Configuration Tables

12

Outbound Components contd.

Logical System The systems involved in distributed processing are assigned logical 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 essentially a sequence of several processes that work together. SAP provides service programs and configuration tables to link these programs and provide customizing options for an outbound process.
15

Configuring ALE Infrastructure

 Basic settings for Idocs  Communication Settings  Advanced Settings

16

Basic Settings of Idocs

Number Range of Idocs Transaction: OYSN

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: WE21

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 techniques 1. Standalone programs 2. Change pointers

23

Outbound Process- Master Data Distribution contd.

Outbound Process via StandAlone 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 specify the objects to be transferred and the receiving system. These when executed calls 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 automatically 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: BD82 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 execute program RBDSEMAT

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

31

Outbound Idoc View

You can view the Idoc using Transaction WE02/WE05 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 Standalone 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 determined 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
Ver:3.0x Idocs -INBOUND_IDOC_PROCESS

Technical Flow

Note:Ver:4.0x Idocs: IDOC_INBOUND_ASYNCHRONOUS

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/EDI 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 WE02/WE05 and by giving the necessary details.

45

Transaction Codes
Main menus WEDI BALE SWLD SALE NACE Main menu for EDIrelated activities Main menu for ALErelated activities Main menu for workflowrelated activities Main area for ALE configuration Main menu for Message control configuration

IDoc Definition SE11 WE31 WE30 BD53 WE60 WE61 Data dictionary Segment editor IDoc editor to create and extend IDoc type Reduce IDoc types for master data IDoc documentation (IDoc structure and segment definition) IDoc documentation (control record, data record, and status record)

IDoc Monitoring WE02 WE05 WE07 AL11 IDoc display IDoc list IDoc statistics SAP Directories
46

Transaction Codes contd.

Configuration (Basic Infrastructure for ALE and EDI) WE20 BD82 WE21 SM59 BD64 BD54 SCC4 Testing WE19 WE12 WE16 WE17 Test tool for IDocs Convert an outbound IDoc to an inbound IDoc Process an incoming IDoc file Process an incoming status file Maintain partner profile manually Generate partner profiles automatically Port definitions RFC destination Maintain customer model Define a Logical System Assign a client to the Logical system

Reprocessing IDocs BD88 BD87 Process outbound IDocs (before 4.6A) Manual processing of Idocs

Miscellaneous XD02 Maintain customer master

47

Transaction Codes contd.

Miscellaneous contd. XK02 MM02 VA01 ME21 ME11 BD10 BD12 BD14 Maintain vendor master Maintain material master Create sales order Create purchase order Create purchasing information records Material Master Data Distribution Customer Master Data Distribution Vendor Master Data Distribution

Configuring New Components WE81 WE82 WE41 WE42 WE57 BD51 BD67 Create new message type Link IDoc type and message type Create outbound process code Create inbound process code Allocate inbound function module to message type Define settings for inbound function module 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

Thank You!