ALE
ALE
(Application Link Enabling)
(Application Link Enabling)
&
&
IDOC
Applicati
Application on Linking Enabling(ALE)Linking Enabling(ALE)
IIs an R/3 technology that enabls an R/3 technology that enables you to construct and operate distributedes you to construct and operate distributed applications, sometimes in different countries.
applications, sometimes in different countries.
Allows efficient and reliable communication between distributed processes. Allows efficient and reliable communication between distributed processes.
Guarantees the distribution and synchronization of master data,
Guarantees the distribution and synchronization of master data, Customizing dataCustomizing data and transaction data through asynchronous communication.
and transaction data through asynchronous communication.
Synchronous connection is used in ALE to read data
Synchronous connection is used in ALE to read data only.only.
ALE Introduction
ALE Introduction
Applicati
Application on Linking Enabling(ALE)Linking Enabling(ALE)
IIs an R/3 technology that enabls an R/3 technology that enables you to construct and operate distributedes you to construct and operate distributed applications, sometimes in different countries.
applications, sometimes in different countries.
Allows efficient and reliable communication between distributed processes. Allows efficient and reliable communication between distributed processes.
Guarantees the distribution and synchronization of master data,
Guarantees the distribution and synchronization of master data, Customizing dataCustomizing data and transaction data through asynchronous communication.
and transaction data through asynchronous communication.
Synchronous connection is used in ALE to read data
Synchronous connection is used in ALE to read data only.only.
ALE Introduction
ALE Introduction
Application data can be distributed between dif Application data can be distributed between different releases of SAP systemsferent releases of SAP systems
Data can continue to be exchanged after a Data can continue to be exchanged after a release upgrade without requiringrelease upgrade without requiring special maintenance
special maintenance
Customers can add their own enhancemenCustomers can add their own enhancementsts
Communication interfaces enable connections to non-SAP systemsCommunication interfaces enable connections to non-SAP systems
SAP R/3 and R/2 Systems can communicate with each other SAP R/3 and R/2 Systems can communicate with each other
ALE Benefits
ALE Benefits
ApplicatiApplications ons servicesservices: this layer provides ALE with an interface (for instance:: this layer provides ALE with an interface (for instance: BAP
BAPI)I) to R/3 to facilito R/3 to facilitate data exchange to or from external R/3 systems.tate data exchange to or from external R/3 systems.
DDistribution servicesistribution services: the onus of filtering and converting messages: the onus of filtering and converting messages exchanged between SAP and non-SAP systems is on the distribution l
exchanged between SAP and non-SAP systems is on the distribution l ayer of ayer of ALE. This service is the core service and acts as a san
ALE. This service is the core service and acts as a sandwich layer betweendwich layer between application and communication layers.
application and communication layers.
CCommunications servicesommunications services: ALE supports synchronous : ALE supports synchronous as well asynchronousas well asynchronous communication. Synchronous messaging is used for the direct readi
communication. Synchronous messaging is used for the direct readi ng of controlng of control data, while asynchronous messaging is used for transmitting or
data, while asynchronous messaging is used for transmitting or receivingreceiving application data.
application data.
ALE Services
ALE Services
D
Differences between ALE and Eifferences between ALE and EDIDI
ALE (Applicatio
ALE (Application n Link Enabling)Link Enabling) is a way of transferring data between systems is a way of transferring data between systems i.ei.e SAP to SAP.
SAP to SAP. E
EDIDI or Electronicor Electronic DDataata IInterchangenterchange is a process in which data iis a process in which data is transferreds transferred between an SAP system and another system. The latter one can
between an SAP system and another system. The latter one can be a non-SAPbe a non-SAP system too.
system too.
The main difference between ED
The main difference between EDII and ALE is in the transfer of data.and ALE is in the transfer of data. For ED
For EDII, the transfer of data(, the transfer of data(IIdocsdocs)) is through a flat file.is through a flat file. Where as in ALE, it is from Memory to m
Where as in ALE, it is from Memory to memory transfer.emory transfer.
ALE vs EDI
ALE vs EDI
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
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.
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.
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
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
Distributed SAP systems exchange three types of data for a chieving 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, 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.
Logical System Ex: D11CLNT400 Customer Model Ex: Z15T EG1 Idoc Type Ex: MATMAS03 Selection Program Filter Object Conversion Rule Port Definition Ex: tRFC Port RFC Destination
Ex: LSIDE S800 Partner Profile
Ex: Partner Type LS(Logical System) Service Program
Ex:RS EOU T00 Configuration Tables
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.
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.
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
Basic settings for Idocs Communication Settings Advanced Settings
Number Range of Idocs
Transaction: OY SN
Number Range for Idoc(Inbound/ Outbound):16 digit.
Maintaining a Logical System Transaction : BD54
Allocating Logical Systems to the Client Transaction: SCC4
Allocate the client to the logical system in all the systems in the distributed network.
RFC Destination
Transaction: SM59 Technical settings tab
RFC Destination contd. Logon and security tab.
Port Definition
Transaction: W E2 1
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
Outbound 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
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
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
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
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.
The partner profile can be viewed with Transaction WE20.
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.
In this data is transferred explicitly from one system to another. Transaction : BD10 or e x ecute program RBDS E MAT
You can view the Idoc using Transaction W E 0 2 /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
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.
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.
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
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
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
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
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.
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.
Process flow Technical Flow
Note:V er :4.0 x Idocs:IDOC_INBOU ND_AS Y NCHR ON OU S
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.
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
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).
You can view the Idoc using Transaction W E 0 2 /W E 05 and by giving the necessary details.
Main 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
IDocDefinition
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)
IDocMonitoring
WE02 IDoc display
Configuration (BasicInfrastructure 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 ReprocessingIDocs
BD88 Process outbound IDocs (before 4.6A) BD87 Manual processing of Idocs
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
ConfiguringNew Components
WE81 Create new message type
WE82 Link IDoc type and message type WE41 Create outbound process code WE42 Create inbound process code
WE57 Allocate inbound function module to message type
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
