ALE (Application
Link and Enabling) &
IDOC(Intermediate Documents)
What is ALE?
ALE Overview
From a Database or Configuration view, the SAP system
consists of:
ALE allows the implementation of loosely coupled SAP
systems; each of the SAP systems has its own database and is essentially
independent from the other systems. ALE allows us to distribute data between
different systems and different business processes.
SAP supports a number of distribution scenarios, which
define how different SAP systems can interact. The scenarios define what
messages are sent back and forth between the systems (for example, Contract
information needs to be exchanged between systems that run central purchasing
and systems that run decentral purchasing).
The “data container” that carries the message is the
Intermediate Document, or IDoc. SAP delivers over 100 IDoc types to support its
distribution scenarios; along with the IDocs come the associated programs to
generate (on the outbound side) or to process (on the inbound side) IDocs.
Part of ALE is a communication infrastructure;
specifically ALE uses the “transactional RFC” technology to ensure the
transaction consistency across system boundaries. ALE also ties into SAP
workflow to handle errors in the data transfer process. ALE scenarios fall into three
categories: master data, transactional data, and control data distribution.
Although the underlying principles are the same for the different categories,
there are differences in their functions and configurations. SAP delivers over
200 ALE scenarios; and by extension there are approximately 200 application
areas that can leverage ALE technology for data distribution or communication.
A subset of these scenarios is supported by R/3 for Electronic Data Interchange
(EDI). There are several advantages to
using ALE technology:
ALE Building Blocks and Concepts
The following building blocks are
fundamental to ALE functionality:
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. Every R/3 client used for ALE or EDI has to have a base LS
associated with the client. This LS becomes the “sender” for outbound messages
and a “receiver” for inbound messages. In addition to the base LS, a second LS
should be created within that R/3 system for each R/3 or external system used
for ALE interfaces. In an inbound ALE interface, this second LS represents the
sender (another R/3 or external system) with respect to the base LS (receiver).
In an outbound ALE interface, this second LS is the receiver on behalf of the
R/3 or external system with respect to the base LS (sender).
Message type: A message type represents the application message
exchanged between R/3 systems and R/3 and an external system. A message type
characterizes the data sent across systems and relates to the structure of the
data called an IDOC type (see below). For example, MATMAS is a message type for
Material Master, and INVOIC is a message type for an Invoice (Billing Document).
ALE supports over 200 message types in R/3 and about 200 application areas.
IDOC type and IDOC: An Intermediate Document (IDOC) type represents
the structure of the data associated with a message type (DEBMAS02 for message
type DEBMAS — Customer Master, and WMMBID02 for message type WMMBXY— Goods
Movements), while an IDOC is an object containing the data of a particular
message type. IDOCs are data containers with intelligence built in. Each IDOC
contains one and only one business object. For example, an IDOC of type
SHPMNT01, message type SHPMNT, will contain data only of one Shipment Document.
Generally, the architecture of an IDOC is independent of the message type by
virtue of ALE’s ability to redefine it for any message type. Customer Distribution Model: In an R/3 system, the Customer
Distribution Model is a tool that stores information about the flow of messages
across various systems. The Customer Distribution Model uses an SAP-delivered
Distribution Reference Model as its basis (the Customer Distribution Model can
have distribution scenarios other than ones stored in the Distribution
Reference Model.) The Customer Distribution Model stores data that dictates
which messages (message types) flow to which Logical Systems. Many messages can
flow to one Logical System, and one message can flow to several systems. With
the use of filter objects and listings (which I’ll describe shortly), it is
also possible to specify in a model the criteria for filtering information for
a specific system. A Customer Distribution Model can be created in an R/3
system with that client’s base Logical System as the “sender” Logical System. ALE provides powerful
capabilities to capture changes occurring to master data and to distribute them
via the IDOC interface. This feature can be used to keep two or more systems
synchronized with respect to master data. Ports: A port is a logical representation of a communication
channel in SAP, with the data communicated being IDOCs. There are four types of
ports that can be defined in R/3: tRFC, File, R/2, and Internet. 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. By linking ports to RFC destinations, the port can also trigger scripts
to invoke EDI subsystems, IDOC mapping software, and FTP. Partner profile: A partner profile is an identifier for a system used
for communicating messages. There are four types of partner profiles: KU for
Customer, LI for Vendor, B for Bank, and LS for Logical System. KU, LI, and B
are used for EDI partners, while LS is used for ALE communications. Every
partner profile used for ALE must be based on an existing LS. A partner profile brings together
several ALE and EDI elements to define the parameters of communication between
two or more systems. Other than general information, you have to maintain
inbound parameters, outbound parameters, and message control. The main
parameters are message types, IDOC types, process codes, partner functions,
application identifiers, message functions, output types, and ports. Other
parameters also determine the mode of processing and error handling.
The process can be divided into
the following sub-processes: ALE provides for the integration of distributed
applications, but why would we distribute What can we
distribute with ALE? We can distribute all types of data with ALE:
The Intermediate
Document (IDoc) The Intermediate Document, or IDoc, is the main component
of all interface functionality in SAP. Each interface message type has an associated IDoc
type. The IDoc, in turn, defines the structure and formatting of the data contained
within the message type.
IDoc Structure
SAP originally developed IDocs for EDI, and then adopted
the IDoc concept and structure for its ALE interface.
The IDoc Control
Record The IDoc Data Records
The Data Records contain the actual application data. Some
of the more important fields are:
Data Record Hierarchy
Example – Material
Master
Distribution Models
Before building a distribution model, we must define the
logical systems that we will be using. The Logical System Definition transaction will
access the list of logical system names. Click on New entries to
create new logical systems.
Steps to create ALE and IDOC’s:
ALE (Application Link and Enabling) is SAP proprietary
technology that enables data communications between two or more SAP R/3 systems
and/or R/3 and external systems.
ALE is the set of tools, programs, and data definitions
that Provides the mechanism for distributing SAP functionality and data across
multiple systems. ALE enables the
construction and operation of distributed applications.
From a System Infrastructure view, an SAP system consists
of three layers:
- The Database Layer stores and retrieves all data. The database contains all of the data related to the SAP system, including the ABAP programs, the Configuration data, the master data, and the transaction data.
- Application
layer: This layer provides ALE with an interface to R/3 to originate or
receive messages containing data to or from external (or other R/3)
systems and executes the SAP programs and processes requests from users.
- The Presentation Layer contains the SAP Graphical User Interface (GUI), and handles all user input and output.
Together, the three layers make up the three-tiered
client-server architecture of SAP.
We can distribute the three layers over any number of
physical computers. However, there may only be one database server.
- Client-Independent
data, such as ABAP programs, client-independent tables, etc.
- One or more Clients. Each client contains its own client-dependent configuration
(Company
hierarchy, process configurations, etc.), master data (customer,
Material, vendor, etc.), and
transaction data.
The Basic Ideas of ALE
ALE is a technology introduced by SAP with its 3.0
release. Its purpose was to overcome the limitations of a single SAP system. A single SAP
system that runs on top of one database often does not fulfill the needs of larger
corporations, either from a business or a technical perspective.
The distribution of data happens at the application server
level (Hence, Application Link Enabling).
You can maintain ports by
executing transaction WE21 or WEDI, or selecting IDOC -> Port Definition.
RFC destinations can be maintained using transaction SM59.
A partner profile plays a major
role and can be viewed as a gateway for ALE and EDI communications. It routes
the specified messages through defined IDOC types to a given port after
invoking the appropriate function modules for outbound processing. It receives
IDOCs of a specific type, and it identifies modules to post data to the
application databases in the case of inbound interfaces.
RFC Destination:Used to define the characteristics of communication links
to a remote system on which a functions needs to be executed.
Process: The processes in the application layer and the ALE layer are completed on both the inbound and outbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface.
Process: The processes in the application layer and the ALE layer are completed on both the inbound and outbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface.
1. Outbound Processing
2. Inbound Processing
Why use ALE?
applications in the first place? There are several
technical and business reasons:
- System Performance: The transaction load is too heavy for a single SAP system.
- High Availability Requirements: The company cannot afford downtime due to backups, maintenance, upgrades, etc.
- SAP Release Coordination: Different units of the organization may require different releases of the SAP software.
- Very
Large Database: Companies with very large databases may need to distribute
the data across multiple SAP systems.
- Business
Structure: Business units may require independence and autonomy for day-to-day
operations, and yet still need to share some data and functionality with other
units in the enterprise.
- Interfacing
with non-SAP systems: The company may wish to maintain certain applications
on non-SAP systems, while at the same time integrate these applications
and their data with the SAP system.
- Keep
development system data in sync with production data: An organization
may wish to keep the data on a development system the same as on a
production system.
- Maintain
configuration and master data across clients: Organizations using multiple clients may wish to
maintain certain data on a client-independent basis.
- Control or Customizing Data: Control data includes all configuration objects that define how the SAP system is organized. This includes the enterprise structure configurations, global settings, etc.
- Master
Data: Master data objects that can ALE can distribute include:
Ø Material
Master
Ø Customer
Master
Ø Vendor
Master
Ø Cost
Centers
Ø Activity
Types
Ø G/L
Accounts
Ø Characteristics/Classes/Classifications and many
others
- Transaction
Data: Transaction data is data related to specific business transactions
or processes (e.g. sales orders, credit memos, invoices).
SAP delivers several hundred predefined distribution
scenarios. If a standard solution is not provided, then we can develop a custom
scenario to distribute any data required by the business. The number of
supported business scenarios increases with each SAP release.
Example distribution scenario: Sales and Distribution
The sales system provides only the logistics data that the
warehouse requires to fill an order. Summary information is reported into the central
sales information system. All of the data sent references a single
order document.
IDocs provide support for customized development:
Ø API
for development
Ø Easy
to use and apply
Ø Real-time
or asynchronous interface connection
Ø Independent
of external system data requirements
Ø Independent
of type of external system
The data interface standard is standardized according to
the following
key rules:
Ø The
documentation of the interface is published.
Ø SAP
takes responsibility for compatibility of the interface standard for its own applications.
Ø Field
lengths and types are defined according to the data element definitions of the EDIFACT
EDI standard and SAP’s data repository.
Ø Codes
for coded fields are taken from international standards where the standard
applies.
An IDoc consists of
three record types:
Ø Control Record: Contains the data that
uniquely identifies the IDoc.
Ø Data Records: Contain the application
data related to the message type. An IDoc may have
multiple data records, called segments. A data segment is made up of a key
section and a data section. The key section uniquely identifies its respective data
segment.
Ø Status Records: Contain the information
relative to the various statuses that the IDoc
encounters, such as IDoc created, document posted, etc.The IDoc is data stored
in a structured format. It is a medium for data transfer. An IDoc is not a
process nor executable code.
The Control Record stores the characteristics of the IDoc.
Some of the more important fields are:
- IDoc
ID Number (DOCNUM)
- IDoc
type (DOCTYP)
- Direction
(In or Out) (DIRECT)
- Name
of Sender (SNDPRN)
- Name
of Receiver (RCVPRN)
- Processing
Status (STATUS)
- EDI
Message Type (if EDI) (STDMES)
Control Records are stored in the R/3 transparent table
EDIDC, keyed by IDoc ID number. This ID number is assigned by SAP for all
IDocs.
Ø IDoc
ID Number (DOCNUM)
Ø Segment
Name (SEGNAM)
Ø IDoc
Data (SDATA) (structure differs with each IDoc type)
The Data Records are stored in table EDID4 (EDID2 in prior
versions), keyed by IDoc number and segment number. The table structure is 71 bytes
of administration data (IDoc number, segment identifier, etc.) Followed by 1000 bytes
of free-form application data.
Each segment type uses a different format for the 1000
bytes of application data.
Information that relates to the object as a whole is
stored in the main segment.
Hierarchical information is stored in separate segments.
Each segment typically
corresponds to a different database table.
Ø Attributes
of a segment:
Ø The
fields of the segment. Each field is assigned a length and a data element from
the ABAP
dictionary.
Ø Whether
the segment is required or optional in a valid IDoc.
Ø
The minimum and maximum number of instances of
the segment.
As an example, consider the Material Master IDoc Type
(MATMAS01). Each material has information that is common throughout an SAP
implementation. This data is stored in the main segment. Each material has some
information that is different for each plant, which is stored in a separate
plant segment. Within a plant, the material can be stored in multiple storage locations, each of which requires a
storage location segment for its information. We can store several different descriptions
of the material (for different languages, for example).
The distribution model describes the flow of data between
logical systems:
Ø What
systems are there?
Ø What
applications will run on which systems?
Ø What
systems will SEND data?
Ø What
systems will RECEIVE the data?
Ø Other
rules for data distribution?
ALE uses the model to control data distribution. The ALE
system will not distribute any data unless you specify the data
flow in a distribution model.
Ø Create the Logical System using SALE Tcode.
Ø Assign Clients to logical System using SALE Tcode.
Ø Create RFC Destinations using SM59 Tcode.
Ø Create Ports using WE21 Tcode.
Ø Create Distribution Model using BD64 Tcode.
Ø Create Partner profile using BD64 Tcode.
Ø Outbound Process using WE05 Tcode.
Ø Inbound Process using WE05 Tcode.
