AB2003 -- ALE-IDoc OVERVIEW

ALE - IDOC
Introduction

Procedure

Demonstration

Exercises
HelpMe

Introduction

Pre-requisites:AB0001 - ABAP overview, R / 3 OVERVIEW & ARCHITECTURE.

Course Objectives To get an overview of ALE, IDOC & EDI.

After this Course, you will be able to :

Get familiarized with the jargons used in ALE, IDOC & EDI.
Know the concept of ALE and Idocs.
Know more about IDoc structure and its role in Data communication
Learn basic Outbound Processing of IDoc.
Learn basic Inbound Processing of IDoc.
Have a Quick Introduction to EDI.
Get your hands dirty on Demo Scenario

Q & A section

ALE - IDOC
Introduction

Procedure

Demonstration

Exercises
HelpMe

Procedure - contents

Business Utilization

IDoc

ALE

Inbound / Outbound Processing

Quick Introduction to EDI

Industry Examples

Business Utilization

A normal business structure comprises of an organization with multiple offices

spread across different countries. They do business with customers and vendors
spread across different locations.
The organization sends business data to its different offices as well as to its
customers and vendors.

Business data
d
ss
ine
s
Bu

ata

Head Quarters
Suppliers
Business data

Business data

Business data

Customer
Sales Office

Production

Business Utilization -ALE

SAP Business units (Sales Unit & production Unit) can use ALE for internal data
exchange.
ALE is SAP Technology to send and receive business data in SAP Systems.
Container for the data is Idoc.
When communicating with Business Partners (customers/suppliers on non-SAP
platforms) SAP business units can exchange data through EDI using idocs.

Idoc
Supplier

Idoc
Production (SAP)
Idoc
Idoc

Customer

Idoc

Head Quarters (SAP)

Sales Office (SAP)

IDoc Intermediate Document

IDoc is an Intermediate document that holds application data.

A container used to exchange data
It is independent of the complex SAP structure to store data.
It serves as the vehicle for data transfer.

IDoc Type defines the structure and format in which the data is exchanged.
It is similar to a structure in SAP
IDoc data is an instance of IDoc Type

IDoc acts as a standard SAP interface to exchange business data through ALE.
From an SAP system, an IDoc can be sent to and received from
An SAP R/3 system
An SAP R/2 system
An EDI subsystem
Any third-party application software

Segments . Idoc data is arranged in Rows, The rows make up segments of an

idoc. Each segment consists of fields/segments. Fields can contain data.

Message

Message type is a name given , that tells us what type of business data is being
exchanged.
Eg: MATMAS (material master data) , DESADV (delivery Data)
Message type is always linked to an IDoc type .
Where the IDoc Type represents the data format. While the message tells us the
purpose of data being sent
Ex: In an organization. Employee details are needed for different purposes.
Like Payroll as well as Security department may need different details about the
same employee. A standard format for employee details is created (Idoc type
:EMPINFO01). Different messages , 1 for payroll (EMPSAL) and 1 for security
(EMPSEC) so that same employee details can be sent for different purposes.

IDoc Type & Segments

An idoc Type defines the syntax of the data permitted segments and their arrangements
mandatory/optional segments.

IDoc Intermediate Document

IDoc is an instance of idoc type.
It contains actual data .

IDoc Components
Control Record

IDoc#
Sending business system
Receiving business system
IDoc type and logical message
Creation date and time

Data Record

IDoc#
Sequence/Hierarchy
Segment
Format definition for
header data
item data

Status Record

IDoc# .Status information like

success/failure

**IDoc # the unique identifier for each idoc.

IDoc
Data Records constitute of segments with a sequential segment number, a
segment type description and field containing the actual data of the segment
(to a max of 1000 bytes)

**Control and Status records are filled by the ALE services and is discussed later in the presentation

ALE Application Link Enabling

Application link enabling is SAPs terminology, used to integrate business

processes between R/3 Systems and non-R/3 systems.

ALE is the technology used to transfer business data between different systems
using IDocs / BAPIs.

*IDoc is the container for the business data and ALE is the technology which builds
the road for data transfer.

For example to send Employee Data to Payroll department from HO, HO will
populate Employee detail into the EMPINFO01 format(IDoc). ALE settings will
determine who is the receiver, how to connect to the receiver and transmits the
data.

OutboundDetermine
IDoc

Head Quarters

Receiving system Inbound IDoc

Payroll Department

SAP Business Processes

The business process shown above depicts an SAP cycle that involves ALE model
to exchange business data like
Purchase Order / Order

- Message Type ORDERS

Order Confirmation

- Message Type ORDRSP

Order change

- Message type ORDCHG

Advantages of ALE

ALE business process is used for following distribution of tasks:

1. Synchronizing customizing data between systems.
2. Master data distribution
3. R/2 Connection
4. External system connection

ALE Model is independent of the participating application systems.

Technology supports guaranteed delivery.
Ensures backward compatibility of messages exchanged between
systems.
E.g. Version Compatibility.
Reduced Processing Cycle time
Reduced Paperwork
Reduced Cost
Standard means of communication

Basic components Involved in ALE Model Setup

The below are the basic configuration steps involved in exchanging the
business data between two systems in distribution service layer.
Logical Systems

( TCode SALE )

R/3 Clients involved in data exchange

( TCode SALE )

RFC Connections

( TCode SM59 )

Distribution Model

( TCode BD64 )

IDoc + Message Type

( TCode WE82 )

Partner Type / Partner Profiles

( TCode WE20 )

Ports

( TCode WE21 )

Logical Systems Partner Types

Logical System is a name given to uniquely identify, the systems invloved in

data exchange.
Logical Systems (LS) represent R/3 or external systems in the SAP R/3
environment for the distribution of data.

A client of an SAP instance is represented by a logical system in the ALE

context. This logical system will act as sender or receiver of Idocs.

Partner Type - Partner type are used to classify the business system.
Ex: Logical System (LS) for other SAP clients,
Customer (KU), Vendor (LI) etc..

Ports

Ports are a logical representation of the communication channels in SAP

R/3 defines four types of ports viz. tRFC (transactional Remote Function
Calls), File, R/2, and Internet.

tRFC ports once created are assigned to RFC destination.

ALE can use all port types to distribute IDocs.

Distribution Model
Distribution Model A model that describes the ALE message flow between logical
systems.
Applications and the ALE distribution service layer use the model to determine
receivers and to control the data distribution. The relationships between logical
systems, message types, BAPIs and filters are defined in the distribution model.
Ex: The screen shot depicts customer distribution mode ALE_TRNG_Mar07.

Sender Logical System EC1CLNT800

Receiver Logical System SALES
Message Type
CREMAS
No filter conditions defined.

Process Codes

Process Codes are used to identify the function module or API (Application
Programming Interface) to be invoked for subsequent processing (Outbound
or Inbound) of the business application.

Outbound process code - Outbound process code under Message Control,

generated the IDoc in the IDoc Interface. The process code determines the
relevant function module. (TCode WE41)

Inbound process Code - names the function module or workflow which reads
the IDoc data and transfers the data to the application document. (TCode
WE42)

Outbound process codes are stored in table TEDE1, while inbound process
codes are stored in TEDE2.

Services Involved in Decentralized Data Exchange

Applications services: This layer provides ALE with an interface (for

instance: IDocs/BAPI) to facilitate data exchange to or from external R/3
systems.
Ex: A program that collects Master / Transactional data to send to its
partner system.

Distribution services: This service is the core in ALE model. Distribution

model is used to identify the receivers (partners) to which the data is to be
exchanged. It acts as a sandwich layer between application and
communication layer.
* The onus of filtering and converting messages exchanged between
SAP and non-SAP systems is on the distribution layer of ALE.

Communications services: ALE supports synchronous as well

asynchronous communication. Asynchronous messaging is used for
transmitting or receiving application data through IDocs.
The communication layer performs a remote function call using the
port definition and RFC destination specified by the customer model.

IDoc Processing

The IDoc Interface supports three types of data flow with the external system.
Outbound processing - IDocs are transferred to a receiving system from the
SAP System.
Inbound processing - IDocs are transferred to the SAP System from a
sender system.
Status processing - The follow-on system confirms the processing status of
outbound IDocs to the SAP System.

Outbound
Processing

Inbound
Processing

Outbound Process Flow

Each layer in ALE model has its own functionality starting from application layer ->
distribution layer -> communication layer in processing outbound IDocs when message
types are used to transfer data asynchronously.
Application Layer - An application FM creates
a master IDoc in outbound processing. This layer
fills the data record of IDOC.
ALE service Layer The Master-IDoc will travel
through ALE layer for Receiver Determination
Data Selection, Segment Filtering, Data Conversion,
Version Control and dispatch control. This layer
fills the control record of the IDoc and generates
a communication IDoc.

Communication Layer - The formatted IDoc is passed

to the communication layer from where it is sent to the
system (server) that was called via a tRFC
(for SAP systems) or file interfaces (for example, EDI).

IDoc - Control Record

The format of the control record is similar for all IDoc types.

IDoc Status Records

The status record shows the information regarding the processed stages and
processing stages of the IDoc. It attains appropriate statuses during its journey from
one system to another and it has identical format for each IDoc type.

Distribution service layer and Communication service layer add these statuses on
the status record, describing various phases of processing.
Status record in screen shot shows
the status of IDoc through its journey
from IDoc generation (status -42) ->
IDoc Passing through ALE layer
(status - 30) -> IDoc Sent out of R/3
system (Status - 03).

Outbound ALE Process

Prerequisites for outbound interface:

Distribution model (BD64)
Only for ALE
Between sending and receiving LS
Trigger
Message Control & Process code
Extraction program / Change Pointers
Application
Port (WE21)
RFC port for ALE
File port for EDI
Others

Partner Profile - Outbound

Partner Profile - Defines the partner type with whom you communicate
asynchronously via IDocs. This has to be maintained in the partner profiles
configuration TCode WE20.

To configure the partner profiles

Master data must be available in the system for partners.
A port is created to assign in the outbound partner profiles. This port must be
configured already.

Inbound processing

List of process are carried on inbound IDocs in the ALE layer.

Segment filtering
Field conversion
Transfer control
Serialization

Inbound Process uses:

IDoc Structure
Service Programs
Partner Profile (derives from control record)
Posting Programs
Configuration Tables

Process Flow
Function Module
Workflow (used mainly in EDI)

Inbound Process Flow

Each layer in ALE model has its own functionality starting from application layer ->
distribution layer -> communication layer in processing inbound IDocs to post the application
data.
Communication Layer This layer receives the
communication IDoc structure from the remote
system to post the application data.
ALE service Layer This layer can perform
Segment Filtering, Field Conversion,
Serialization and Transfer Control on the communication
IDoc structure.
Application Layer The posting program or process
code calls the FM to finally post the document to the
database.

Partner Profile - Inbound

The below screen shot depicts the message type, inbound process code and
posting function module for vendor master data.

Typical EDI Scenario

What does EDI mean ?
EDI (Electronic Data Interchange) means exchange of business documents among
companies using electronic communication systems.
Trading partners - The parties who exchange EDI transmissions.

EDI (Electronic Data Interchange)

IDoc

EDI Subsystem
Translate IDoc to EDI Standard.

File
(Vendor
Format)

Translated EDI standard to vendor format

EDI (Electronic Data Interchange)

EDI is a standard format for exchanging business data between any 2 systems on different
networks .

Any two systems that use different data formats , and need to communicate with each other can
use EDI.
In case of EDI , EDI being a standard format .Any data format can be converted to universal EDI
format.

In case of SAP , Idocs from SAP can be converted to EDI format. This is useful and is widely used
for communication with customers and vendors (non-SAP ) who do not understand Idoc format .

EDI subsystem is needed for communication between 2 systems. This translates the data into
standard EDI format that is understood by receiver / sender system.

EDI uses either ANSI X12 or EDIFACT as standard formats in the data exchange.

In SAP communicating partners are not defined as logical systems for EDI. They have partner
types like KU-Customer, LI-Vendor etc...which uses a file port.

To use EDI -IDoc (intermediate document) a standard data structure is generated by an

application program / transaction in SAP system, it uses file port (to hold application data in file
format) as a technical channel for communication and sends the data to EDI (Electronic Data
Interchange) subsystem.

Scenario: Message flow in Manufacturing Industry

Customer

REQOTE

Vendor

QUOTES
PRICAT
ORDERS/ORDCHG
ORDRSP
IMPINV

TXTRAW

DESADV
STPPOD

TXTRAW

INVOIC

EXPINV

REMADV

The diagram depicts the business

process flow between a customer
and a vendor in common
manufacturing industries.
To automate the process
in exchanging the business data
between these partners we can
configure the ALE model with
standard messages defined by SAP
as shown like
Ex: QUOTES Quotation
ORDERS Purchase Order

PAYEXT Bank CREADV

DEBADV

LOCKBX

FINSTA

FINSTA

ORDRSP Order Confirmation

Scenario: Message flow in Automotive Industry

Manufacturer
OEM

Supplier

DELINS
DELORD
DESADV

ACCSTA

TRXSTA

ACCSTA

GSVERF/SBINV
INVOIC
REMADV

To automate the process in

exchanging the business data
between the manufacturer and
supplier standard message type
provided by SAP can be used in
message exchange such as:
Ex: DELINS Delivery / JIT schedule
DELORD Delivery request
ORDRSP Order Confirmation

Bank
PAYEXT
DEBADV

The diagram depicts the business

process flow between a
manufacturer and a supplier in an
automotive industry.

CREADV

Scenario: Message flow in Retail & Consumer Products

Distribution Center PRICAT
Retailer

PROACT

ORDRSP

The diagram depicts the business

CP Manufacturer process flow between a Retailer and
a consumer in a Retail Industry.
To automate the process in
exchanging the business data
between the manufacturer and
distribution center standard
messages types provided by SAP can
be used in message exchange such
as:

ORDCHG
ORDRSP
DESADV
INVOIC
REMADV

PAYEXT
DEBADV

Bank
CREADV

Ex:
PRICAT Price List / Catalogue
PROACT Stock & Sales Data
ORDRSP Order Confirmation

ALE - IDOC
Introduction

Procedure

Demonstration

Exercises
HelpMe

Demo Scenario
Demo showing distribution of master data.
E.g. Synchronization of master data like customer / vendor / material
between 2 SAP systems.
Configuration Steps:
1. Creation of logical systems
2. Assign client to logical systems
3. Creating RFC destinations
4. Creating Distribution model & distributing the view.
5. Generating partner profiles.
6. Check partner profiles & ports generated.
7. Trigger master data and check the status of Idoc in sender and receiver
systems.

ALE - IDOC
Introduction

Procedure

Demonstration

Exercises
HelpMe

Exercise
Trigger distribution of master data.
E.g. Synchronization of master data like customer / vendor / material
between 2 SAP systems (Tcode BD10/ BD12/ BD14)
Assumptions:
All ALE configurations are already in place.
(ALE course 2 covers configurations in greater details)
Trigger master data and check the status of IDoc in sender and receiver
systems.

ALE - IDOC
Introduction

Procedure

Demonstration

Exercises
HelpMe

Jargons used in ALE Model

SALE (Building Road)

Logical Systems
( TCode SALE)
Clients (Appln.Systems) involved in data exchange ( TCode SALE)
RFC Connections
( TCode SM59)
Distribution Model
( TCode BD64)
Message Type
(TCode WE81)
Partners & Partner Profiles
(TCode WE20)
Ports
(TCode WE21)
IDOC Type
(TCode WE30)
IDOC Segment
(TCode WE30)
Messages / Message Type
(TCode WE81)
IDOC + Message Type
(TCode WE82)
IDOC Monitoring
(TCode WE02)
ALE Monitoring
(TCode BD87)