A L E A N D I D O C
ALE:
ALE is a SAP Technology to support distributed yet integrated processes across level SAP System.A Distributed process is one in which part of a business process is carried out on one system and part on another.
SAP Introduced ALE as its initiative to support a distributed yet integrated environment. ALE allows for efficient and Reliable communication between distributed processes across physically separate sap systems to achieve a distributed yet integrated logical
SAP system.
- Application link enabling (ALE) is a message-based architecture .The data is transferred between various systems in the form of IDocs (data container). It consists of three layers:
- Application layer
- Distribution (ALE) layer
- Communication layer
ALE processes can be broadly defined in two segments.
- Outbound process: The flow of data from sending system to receiver system is called outbound process. The outbound ALE process in SAP sends data to one or more SAP systems.
- Inbound process :The flow of data into receiver system from sending system is called inbound process
Outbound process has two distinct paths for creating IDoc.
- With message control.
- Directly without message control.
The process involves four steps:
- Identify the need (triggering mechanism for IDoc creation).
- Master IDoc generation.
- Communication IDoc generations.
- Dispatch Control.
Tables Related to ALE & IDOC:
EDIDC: Control Records are stored over here.
EDID4: Data Records are stored over here.
EDIDS: Status Records are stored over here.
EDMSG: Message Types are stored over here.
TBDLS: Logical systems are stored over here.
TBDLST: Text for Logical systems is stored over here.
Logical System:
A Logical System (LS) is the representation of an R/3 or external system in SAP R/3 for the distribution of data to and from the R/3 System. In addition to the sender LS, the receiver LS should be created within that R/3 system for receiving R/3 system.
- An entry for the logical system is created in the table TBDLS.
- The name can have up to 10 alphanumeric characters
- The logical system should be unique company wide and should not be used by any other system in the ALE integrated group.
IDOC type:
- An IDoc type defines the syntax of the IDoc data. It tells which segments are found in an IDoc and what fields the segments is made up of.
- When they are stored to a disk file, the IDocs are simple flat files with lines of text, where the lines are structured into data fields. Their specification is stored in the data dictionary.
- E.g.: ORDERS05.
Message type:
- Message type represents a specific type of document that is transmitted between two partners. The message type defines the semantic context of an IDoc. Message type is a grouping of IDOC types belonging to similar application. The same IDoc data can be sent under different message types.
- A message type characterizes the data sent across systems and relates to the structure of the data called an IDoc type.
- For example, MATMAS is a message type for Material Master, and INVOIC is a message type for an Invoice (Billing Document).
Some Important Message Types are:
APPLICATION MESSAGE TYPES
CUSTOMER DEBMAS
VENDOR CREMAS
MATERIAL MATMAS
SALES ORDER ORDRSP
PURCHASE ORDER ORDERS
SEGMENT:
A Segment defines the format and structure of a data record.
- A segment in SAP system is technically implemented as three physically separate pieces.
- Segment type: Segment type is the version independent name of the segment. The standard segment type defined by SAP starts with E1 and the customer defined segment type starts with Z1.
- Segment definition: Segment Name is the version dependent name. The standard segment name defined by SAP starts with E2 and the customer defined segment type starts with Z2. The last three characters represent the version of the segment. Segment name is automatically assigned by the system from Segment Type.
- Segment documentation: The standard segment name defined by SAP starts with E3 and the customer defined segment type starts with Z3.
IDOC:
- An IDOC is an instance of an IDOC type. An IDOC consists of three types of records:
- Control Record: One control record (Table: EDIDC)
- Data Record: One or many data records, which contain the application dependent data, for example the material, master data (Table: EDID4).
- Status Record: One or many status records (Table: EDIDS).
- We can display information about IDOC types, such as DEBMAS02 and INVOIC01 by executing transaction WE60 or using the following menu path from WEDI: Documentation -> IDoc types.
Process of IDOC Creation:
To Create Idoc we need to follow these steps:
- Create Segment (WE31)
- Create Idoc Type (WE30)
- Create Message Type (WE81)
- Assign Idoc Type to Message Type (WE82)
- Creating a Segment
- Go to transaction code WE31
- Enter the name for your segment type and click on the Create icon
- Type the short text
- Enter the variable names and data elements
- Save it and go back
- Go to Edit -> Set Release
- Follow steps to create more number of segments
- Create IDOC Type
- Go to transaction code WE30
- Enter the Object Name, select Basic type and click Create icon
- Select the create new option and enter a description for your basic IDOC type and press enter
- Select the IDOC Name and click Create icon
- The system prompts us to enter a segment type and its attributes
- Choose the appropriate values and press Enter
- The system transfers the name of the segment type to the IDOC editor.
- Follow these steps to add more number of segments to Parent or as Parent-child relation
- Save it and go back
- Go to Edit -> Set release
3. Create Message Type
- Go to transaction code WE81
- Change the details from Display mode to Change mode
- After selection, the system will give this message “The table is cross-client (see Help for further info)”. Press Enter
- Click New Entries to create new Message Type
- Fill details
- Save it and go back
4. Assign Message Type to IDoc Type
- Go to transaction code WE82
- Change the details from Display mode to Change mode
- After selection, the system will give this message “The table is cross-client (see Help for further info)”. Press Enter.
- Click New Entries to create new Message Type.
- Fill details
- Save it and go back
Customer Distribution Model:
The Distribution model (also referred to as ALE-Scenario) is a more or less graphical approach to define the relationship between the participating senders and receivers.
- The Customer Distribution Model stores data that dictates which message (message types), flow to which Logical Systems. Many messages can flow to one Logical System, and one message can flow to several systems.
- Use transaction BD64 or the following menu path to maintain the model:
- Two models cannot distribute the same message between the same set of senders and receivers
- A customer model is maintained on only one system. It is distributed to other systems for use
Ports:
A port is a logical name for an input/output device. It defines the medium in which documents are transferred to the destination system. There are four types of ports
- tRfc - tRFC port are used for ALE communication. Data is transferred once only.
- File - The data is transferred in a standard text file format. The receiving system processes the transferred files completely.
- R/2 - CPIC - Port type for direct access to an R/2 System via the CPI-C protocol.
- XML - The exchange of IDocs happens via XML files at the operating system level.
ALE can use all port types to distribute IDocs, while EDI typically uses a file-based port. tRfc and File ports can link to RFC destinations connected to R/3-to-R/3 or TCP/IP.
Process codes (WE41):
- Process codes are used in ALE and EDI to identify the function module or API to be invoked for subsequent processing. It is used for filling the IDoc.
- An inbound interface uses a process code to determine the application module that will process the inbound IDoc to an SAP application object such as a sales (Customer) order (process code — ORDE), Material Master record (MATM), or a shipment (SHIP).
- An outbound interface uses process codes only in the case of applications that use message control. In this case, the process code identifies the application module that populates the IDoc with application data.
- Each process code is associated with a message type.
Partner Profile:
- When data is exchanged between partners it is important that sender and receiver agree about the exact syntax and semantics of the data to be exchanged. This agreement is called a partner profile. The information defined with the partner profile is:
- IDoc type and message type as key identifier of the partner profile.
- Names of sender and receiver to exchange the IDoc information for the respective IDoc message type .
- Logical port name via which the sender and receiver, respectively will communicate.
- It also specifies the various components used in an inbound / outbound like process code, the mode in which IDocs are processed (batch versus immediate), and the person to be notified in case of errors.
- A partner profile is created for each SAP system you communicate with, and a record exists for each inbound message received from a remote SAP system.
RFC Destination:
It's a unique name for the RFC destination. Use the logical name defined for the remote system. A basic prerequisite for the RFC destination is that the systems should be accessible to each other via TCP/IP or one of the supported network protocols. Several types of RFC destinations are available. ALE uses type R/3 connections for communicating with a remote SAP system.
- RFC destinations are not transported. It must be maintained on each system manually.
- If the name of the RFC destination is not the same as Logical System name then assign the RFC destination to the logical system by using transaction BD97
Message Control:
Message Control is a cross application component used as a service program in several areas. The biggest application is in pricing.
The basic concept behind Message Control is to generate and manage outputs from an application and control their timing and medium of exchange.
The Benefits of Message Control
- Disconnecting the process of creating an application document from the process of generating outputs.
- Automatically proposing output based on business rules specified in Message Control.
- Overriding the automatic proposal.
- Manually selecting an output.
- Generating multiple outputs.
- Controlling the timing, medium and language of the output messages.
- Retransmitting an output
- Monitoring the results of execution.
- Message control is a cross-application technology used in
– Pricing.
– account determination.
– material determination.
– output determination.
- The output determination technique of message control triggers the ALE and EDI outputs for a business document. Message control separates the logic of generating IDocs from the application logic. Message control is used to determine the timing and the medium of the output at run time. Various business rules can be encapsulated in the message control to meet the business needs.
- Transaction NACE is used to set up message control.
Programs & Tables
NAST: This table stores an entry for each output type created for an application document. It’s a table for storing Message Status.
TNAPR: This table has an entry for the processing program used for an output type.
RSNAST00: This program is used to process entries in the NAST table.
RSNAST00: This processing program exists for each output medium. EDI_PROCESSING is a routine in the RSNASTED program to process EDI outputs. The relationship of the output type, Output medium, and processing program is established in the TNAPR table.
ALE CONFIGURATION
ALE Configuration is divided into 2 sections
- General configuration which describes the basic settings required for ALE model to work
- Process specific configuration which describes the settings required over and above the general settings specific to Outbound / Inbound Process.
To establish ALE communication link between two SAP systems, various configuration links settings need to be done. These settings are as mentioned below:
- Defining Logical System Names for Clients
- Assigning Client to Logical System.
- Maintain RFC destination.
- Maintaining Distribution Model
- Generating Partner Profile
- Model Distribution
• It also involves:
- Filters
- Conversion rules
- Serialization
Step-1
Defining Logical System Names for Clients: (Transaction Code- BD54)
To define the logical system, go to transaction SALE and choose: Application Linking and enabling (ALE) -> Sending and receiving systems -> Logical Systems-> Define Logical Systems.
Step- 2
Assigning Client to logical System: (Transaction Code- SCC4)
To assigning client to logical systems, go to transaction SALE and choose: Application Linking and enabling (ALE) -> Sending and receiving systems-> Logical systems-> Assign client To Logical System. A one-to-one relationship exists between client and logical system. Click on the 'New entries’ button to add a new entry.
Step- 3
Maintain RFC destination : (Transaction Code- SM59)
The RFC destination maintains this communication channel and stores the required information to log onto remote system. Application Linking and enabling (ALE)-> Sending and receiving systems -> Systems in Network -> Define target systems for RFC Calls
Creating RFC destinations: Transaction SM59:
Click on the create button and add the details. Enter the name of the RFC destination (Usually it’s the same name as the logical system). Choose the connection type as 3 for R/3 Connection. Enter the target host name. The IP address or the host name of the receiving system. Enter the Logon details, which consist of the language, client, user and password. The system logs onto the remote system with the help of the details given here.
Step- 4
Maintaining distribution Model: (Transaction Code- BD64)
Maintaining the Distribution model: Click on ‘Create model view’ and fill in the details as shown below the details to be filled in are:
- Description/Text for the Distribution Model, Name of the Distribution Model
- Logical system name (i.e. LS name of Sending system) in which the distribution
- Start date is the date from which the Distribution model will be effective.
- End date is the expiry date from Distribution Model.
Maintaining the distribution model: Once the view is created, add a message type or BAPI.
Add message type: To add message type, click on ‘Add Message Type’. Message type requires details such as:
– Sender system
– Receiver system
– Message type and save the model. (MATMAS)
Generating Partner profile: There are two ways to generate the partner profile:
- Manually from the transaction code BD64 (Environment-> Generate Partner Profile)
- Automatically through transaction BD82.
Model distribution: It is necessary for it to be created in the receiving system to generate the partner profile.
- The distribution is done from the sending system.
- To distribute the model go to edit-> Model view -> Distribute.
Creating Material 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 Logistics -> Materials management -> Material master from the material master maintenance.
• Choose Material -> Create (general) -> immediately.
• Enter the material, industry sector and material type.
Make sure that the industry sector and material type you enter are known in the receiving system. Otherwise, errors will occur when you post the material in the receiving system.
Material: Material001 Industry sector: mechanical engineering Material type: finished product
• Choose Select view and then Basic data.
• Enter the basic data of your material.
To avoid any errors occurring during data transfer, make sure that the receiving system will understand the information you have entered.
Material short text: Material for ALE: First steps Base unit of measure: ST
• Save the material.
You are now going to send the material you have just created to the receiving system.
Choose General -> Material -> Send:
- Enter the material you have created (for example, Material001).
- Use ‘MATMAS’ Message type:
- Enter the receiving logical receiving system
• Execute the program.
You should now be able to display your material 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.
Some Important Transaction Codes:
- SALE Display ALE Customizing
- WE02 Display Idoc
- WE05 Idoc Lists
- WE09 Search for Idoc in Database
- WE19 Test tool
- WE20 Partner profiles
- WE21 Port definition
- WE30 Development Idoc Type
- WE31 Development Idoc Segment
- WE41 Process codes, outbound
- WE42 Process codes, inbound
- WE60 Documentation for Idoc types
- WE81 Logical message types
- WE82 Assignment Messages for Idoc Type
- BD64 Maintenance of Distribution Model
- BD73 Re-posting of Idocs
- BD83 Send IDocs after an ALE error
- BD84 Post IDocs after ALE error
- BD87 Manual Processing of Idocs
In the Sending System (IB):
Transaction Code for IDoc list is: WE05
A list of IDocs grouped by status is displayed:
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
In the Receiving System (OB):
Transaction Code for IDoc list is: WE05
A list of IDocs grouped by status is displayed:
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,
63, 65 Inbound error
Other Not relevant in this context