(http://www.geocities.com/SiliconValley/Foothills/8207/site.

htm)

Why ALE?

ALE is a business solution to a very real need emerging in the SAP market.
This is the need for businesses to move towards tighter integration
between systems, yet, at the same time, provide independence to the various
business units within the company.

In the past the move was towards centralized systems...

Standardization of business processes accompanied by ever tighter

integration within the central system no longer represents a practicable
approach to this problem. The following are some of the most commonly
encountered difficulties:

technical bottlenecks,
upgrade problems,
the effect of time zones on international corporations,
excessively long response times in large centralized systems.

How do you achieve this "loosely coupled applications" without compromising

data integrity, without committing yourself to a specific technology, without
adding to the technical issues mentioned above, ???

What if you want to link in to external systems as seamlessly as possible?

The SAP Solution - ALE

SAP has provided ALE (Application Link Enabling) as the solution to these
issues. It allows you to:

distribute your applications across several SAP systems, such that

centralized functions, as well as decentralized functions can operate in
the same company arena
 maintain and distribute master data elements from a central system,
thus maintaining unique number ranges across several systems
maintain and distribute control data objects from a central system, thus
synchronizing important configuration data. This is important when trying
to decentralize functions, yet keep them integrated
couple R/2 and R/3 systems, in some instances
couple SAP and external systems, via IDocs (Intermediate documents)
and an external translation mechanism

ALE also provides you with tools that allow you to:

manage the ALE process seamlessly. These tools include the reprocessing
of communication errors, business process and technical error handling
and routing via workflow, archiving of data
keep audit trails of all the ALE communication
configure the ALE solution in many different ways in order to tailor make
a solution for the user

In SAP's words:

"The ALE (Application Link Enabling) concept available in R/3 Release 3.0 supports the
construction and operation of distributed applications. It incorporates the controlled exchange of
business data messages whilst ensuring data consistency across loosely coupled SAP
applications. The integration of various applications is achieved by using synchronous and
asynchronous communication, rather than by means of a central database.
ALE comprises three layers:

the applications services,

the distribution services,
the communications services.

In order both to meet the requirements of today's customers and to be open for future
developments, ALE must meet the following challenges:

Communication between different software releases.

Continued data exchange after a release upgrade without special maintenance.
Independence of the technical format of a message from its contents.
Extensions that can be made easily, even by customers.
Applications that are decoupled from the communication.
Communications interfaces that allow connections to third-party applications.
Support for R/3-R/2 scenarios.
 How It Works

A Summary
ALE allows the user to perform an SAP transaction in the sending system,
after-which the following steps occur:

1 or more communication IDocs (intermediate documents: container for

the application data) are created in the sending system database. An ALE
distribution model, that needs to have been configured, determines which
systems the IDocs are to be sent
These communication IDocs, that contain the relevant application data of
the transaction that was performed, are then passed to the ALE
communication layer
This layer performs an RFC call, using the port definition and an RFC
destination determined through the customer model
The IDocs are then transferred to the respective receiving systems.
These could be SAP R/3, R/2 or external systems
If the receiving system is an SAP system then:

In the case of master data distribution the same transaction that was
performed on the sending system is again performed on the receiving
system with the data contained in the IDoc. This allows the data to go
through the SAP checks before posting occurs
In the case of transaction scenarios the relevant data is passed to the
respective transactions in order to load the required application
document. Eg. A PO is loaded on the sending side, yet a SO is created on
the receiving system
Master data has another difference:
 It can be set up in such a way that any changes made to specific fields
in master data tables can automatically trigger off the ALE distribution
process for that particular master data object
If a master data object is created or changed on a sending system and
distributed to another system the respective transaction is used to
either create or change that respective master data object on the
receiving system

In general, if standard SAP can't perform the task required then neither
can ALE. It doesn't add functionality, it merely decouples it and allows you
to distribute it onto other remote systems.

The Detail as described by SAP

In the output processing one of the function modules of the application
creates an IDoc, the so-called master IDoc. This IDoc is sent to the ALE
layer where the following processing steps are applied:

Outbound processing
Receiver determination

An IDoc is similar to a normal letter in that it has a sender and a receiver.

If the receiver has not been explicitly identified by the application, then
the ALE layer uses the customer distribution model to help determine the
receivers for the message.

The ALE layer can find out from the model whether any distributed systems
should receive the message and, if so, then how many. The result may be
that one, several or no receivers at all are found.

For each of the distributed systems that have been ascertained to be

receiver systems, the data that is specified by the filter objects in the
customer distribution model is selected from the master IDoc. This data is
then used to fill an IDoc, and the appropriate system is entered as receiver.
Data selection

Segment filtering

Individual segments can be deleted from the IDoc before dispatch by

selecting Functions for the IDoc processing -> Settings for filtering in ALE
Customizing. The appropriate setting depends on the sending and receiving
logical R/3 System.

Field conversion

Receiver-specific field conversions are defined under Functions for the

IDoc processing -> Conversions.

General rules can be specified for field conversions; these are important for
converting data fields to exchange information between R/2 and R/3
Systems. For example, the field "plant" can be converted from a 2-character
field to a 4-character field.

The conversion is done using general EIS conversion tools (Executive

Information System).

Version change

SAP ensures that ALE functions between different R/3 System releases. By
changing the IDoc format you can convert message types of different R/3
releases. SAP Development use the following rules when converting existing
message types:

Fields may be appended to a segment type;

Segments can be added;

ALE Customizing keeps a record of which version of each message type is in

use for each receiver. The correct version of the communication IDoc is
created in the ALE output.

The resulting IDocs (it is possible that several IDocs could be created in the
receiver determination) are referred to as communication IDocs and are
stored in the database. The dispatch control then decides which of these
IDocs should be sent immediately. These are passed to the communications
layer and are sent either using the transactional Remote Function Call (RFC)
or via file interfaces (e.g. for EDI).

If an error occurs in the ALE layer, the IDoc containing the error is stored
and a workflow is created. The ALE administrator can use this workflow to
process the error.

Inbound processing
After an IDoc has been successfully transmitted to another system, inbound
processing is carried out in the receiver system, involving the following steps
in the ALE layer:

Segment filtering

Segment filtering functions the same way in inbound processing as in

outbound processing.

Field conversion

Specific field conversions are defined in ALE Customizing.

The conversion itself is performed using general conversion tools from the
EIS area (Executive Information System).

Generalized rules can be defined. The ALE implementation guide describes

how the conversion rules can be specified.

One set of rules is created for each IDoc segment and rules are defined for
each segment field.

The rules for converting data fields from an R/2-specific format to an R/3
format can be defined in this way. An example of this R/2 - R/3 conversion
is the conversion of the plant field from a 2 character field to a 4 character
field.
Data transfer to the application

Input control

When the IDocs have been written to the database, they can be imported by
the receiver application.

IDocs can be passed to the application either immediately on arrival or can

follow in batch.

You can post an inbound IDoc in three ways:

1. by calling a function module directly: A function is called that imports

the IDoc directly. An error workflow will be started only if an error
occurs.
2. by starting a SAP Business Workflow. A workflow is the sequence of
steps to post an IDoc.
3. by starting a work item A single step performs the IDoc posting.

The standard inbound processing setting is that ALE calls a function module
directly. For information about SAP Business Workflow alternatives refer to
the online help for ALE programming.

ALE Project Strategy

[ Up ] [ ALE Project Strategy ] [ Design ] [ Configuration ] [ Development ]
[ Operations ]

" Before commencing with an ALE implementation, certain tasks need to

be undertaken, certain deliverables produced and final decisions made...
Without the support of senior project management ALE implementation
will not succeed..."

A small, full-time, team (1-2 people) needs to be mobilized with the

following skills:
 Technical background;
Detailed ALE knowledge; and
High level functional understanding.

Working together with this team should be a few applicable, part-time

functional experts. This team needs to assess the business needs to see if
ALE is the most feasible solution for the business. They need to conduct the
following tasks before commencing with ALE design:

1. Business requirements assessment - Map out what the business

needs, both present and future, ito:
Distributable functions;
Common master data;
Technical: Up-time, response time; and
Audit & legal requirements.
2. ALE investigation
Research applicable ALE scenarios; and
If need be, Configure and Demo prototype.
3. ALE gap analysis
Map business requirements to standard ALE functionality; and
Document gaps and highlight implications.
4. Confirm business / ALE scope

Obtain sign off for the agreed scope of the ALE implementation project.

Deliverables during this stage

ALE Whitepaper - Business requirements assessment, ALE functionality
mapping, impact assessment (functional and technical). Gap analysis.
ALE Team Approach - Resource & skill requirements, deliverables and
deadlines.
Sign-off of scope - The agreed scope of the ALE Implementation
project must be signed-off.
 " Once it has been decided, by management, to pursue the ALE option
we need to design a potential ALE solution..."

To do this, the ALE team needs to perform the following steps in the
development environment:

1. Develop standards & procedures early:

Naming standards: Logical systems, reduced message types, custom object
types, custom function modules; and
Change management procedures: Determine how you are going to manage
the various clients and their different configurations. Define a process for
configuration changes.
2. Document the various settings, per scenario, that are required to
implement the solution. These include:
 Message types and fields;
Filter objects;
Serialization;
Push Vs Pull;
Immediate Vs background processing;
Conversion rules;
Centrally managed on which system?; and
...
3. Future flexibility must be catered for in the design. This is especially
important when considering the organization structure as certain
scenarios require certain control data to be in synch across the
various clients. This is difficult to change once implemented...

4. Audit requirements for transaction scenarios must be noted and

designed for. Consider archiving, audit message types.

5. Consider the potential technical impact of the proposed ALE solution

ito disk & processor utilization, network usage, dialog & background
processing. Archiving strategy as well as disaster recovery planning

6. Sign-off the design together with the business.

Other considerations
ALE migration to production strategy and timing.

Deliverables during this stage

ALE Naming Standards - Set the standards for all configuration.
ALE Design Document - Details business process, functional impact,
technical impact boundaries, workflow requirements, timing of jobs, ...
ALE Change Management Procedure - Schematic diagram of up to date
client configuration status, configuration change request procedure, ALE
configuration checksheet.
ALE Configuration Sign-Off Procedure - Agree on the process to follow
during QA and Production phases of the project. During production,
transactions cannot be posted to test the correctness of the solution...
ALE Migration Strategy - How are you going to put the various clients
 into production, timing, implications on business processes.

Configuration
[ Up ] [ ALE Project Strategy ] [ Design ] [ Configuration ] [ Development ]
[ Operations ]

Home
Config Detail

"Remember to configure ONLY what is signed off by the business in the

confirm business requirements stage."

The following steps need to be noted when configuring your ALE solution:
 1. Confirm business requirements - Before commencing configuration
ensure that you have the detail of the business requirements for the
whole scope of the implementation.
2. Configure the ALE basis portion to enable ALE in the development
environment. This involves the following steps:

Create Logical System (LS) for each applicable ALE-enabled client;

Link client to Logical System on the respective servers;
Create background user, to be used by ALE, on each client (with
sufficient rights to do the various ALE postings);
Create RFC destination for each destination client; and
Generate partner profiles for sending system. (Can only do this if at least
1 message type exists against the sending system's LS). This
automatically generates the port if the LS and RFC name are the same.
3. Following the basis configuration is the functional configuration:

Create a Customer Distribution Model (CDM);

Add appropriate message types and filters to the CDM;
Generate outbound partner profiles;
Distribute the CDM to the receiving systems; and
Generate inbound partner profiles on each of the clients.

Keep your ALE configuration diagram up to date and follow change

management procedures rigorously, as you begin to configure. Areas you
need to document well include the finer details involved with an ALE
implementation:

Listings / classes;
Object types / Workflow tasks;
Conversion rules;
Filters & Segment filters;
Change pointers / Fields activating change pointers;
Serialization;
Partner profiles: Immediate Vs Background;
Background job definition and scheduling;
Control data required to be in synch; and
...
 4. QA & testing: Demonstrate / workshop this solution with the
business. Document and draw up functional specifications (done by the
business) of any extensions to existing scenarios or additional
scenarios required.
5. Sign-off each client configuration with the business owners.

Additional considerations

Never do client copies. If necessary, remember to redo the configuration

pertaining to logical systems as these will be out of synch. Also remember to
archive irrelevant IDocs, remove useless change pointers and useless
customer distribution models.

Deliverables during this stage

ALE Configuration Procedure - Details how to perform the configuration.
ALE Detailed Configuration Guide - Details what the actual values are
for each of the ALE-configurable areas are for your particular solution.
ALE Basis Configuration Procedure - Details how to perform the basis
configuration for ALE. Used by the Basis team.
ALE Workflow Configuration Procedure - Details how to configure the
workflow error message handling for ALE.

Development
[ Up ] [ ALE Project Strategy ] [ Design ] [ Configuration ] [ Development ]
[ Operations ]

Home

"To do ALE development your scenario designer will need in-depth

knowledge of IDocs, ALE scenario development and ALE configuration. A
handy knowledge of ABAP is also required..."
 1. Functional specifications need to be drawn up, by the business,
describing exactly what is required by them, that is not available in
the standard ALE scenarios.

2. A technical specification can then be drawn up by the ALE team. In

this technical specifications the following needs to be addressed:

New IDocs required;

New fields added to existing IDocs;
Program / user exits / message control for populating the fields;
Inbound functional module details;
ALE configuration set up requirements; and
Error handling.

Once the specification is completed and confirmed by the business,

programming can begin.
 3. Developing an ALE scenario will include the following steps:

OUTBOUND
Create Segments and IDoc type;
Create Message Type and link to IDoc type;
Populate IDoc using message control \ user exit or program (ABAP);
Distribute IDoc using MASTER_IDOC_DISTRIBUTE;
Create object type if required; and
Define CDM with message type and filter object. Distribute model.
Generate outbound partner profiles;

INBOUND
Write inbound function module (FM) to process inbound IDoc (ABAP);
Create process code and link to FM;
Generate inbound partner profiles; and
Link object type to FM for error handling.

4. QA & Testing - Including unit and string testing. Ensure a quality

solution. QA done by the ALE team leader and testing done by the
business owner and ALE scenario developer.
 5. Sign-off by the business - Ensure the development is thoroughly
tested and comprehensively documented prior to sign-off against the
functional specification.

Deliverables during this stage

ALE Functional Specification - For each development a detailed
functional requirement document is produced and confirmed by the
business.
ALE Development Guide - Details what development was done and how to
configure the solution. Needs to be QA'd by someone else in the know.
Test Procedures - Unit and string testing needs to be conducted on the
development together with result logging and sign-off.

Operations
[ Up ] [ ALE Project Strategy ] [ Design ] [ Configuration ] [ Development ]
[ Operations ]

Home

" The operations support area needs to be well skilled in order to handle
the support requirements when going live. The initial period during go live
may be intense, requiring twice or three times the amount of normal
support. This intense support requirement will dwindle a couple of months
after go live..."
Various areas, pertaining to the Operations / Production environment need
to be addressed BEFORE you go live:

1. ALE Administrator role defined and sourced. Responsible for ALE

configuration and issue resolution.
2. Capacity plan including ALE IDoc archiving strategy - Consider the
growth of the ALE solution, procedures the archiving of IDocs while
considering the legal implications.
3. ALE Operations role defined and sourced. Responsible for ALE
archiving, background job scheduling and monitoring.
4. ALE failure recovery procedure - When a soft failure occurs (I.E.
When a system is restored to a previous point in time) a recovery
procedure needs to be implemented... How?
5. Define the ALE support organization structure. The ALE
administrator will receive the ALE problems when in production. Using
a troubleshooting guide the problems can be resolved.
 Other considerations
Never do client copies... If you do, check on:

the change pointer table (BDCP/S);

the IDoc table (EDIDC/S); and
all the logical system references.
Client specific configuration:

Immediate processing on the outbound and inbound side should be

avoided due to the fact that ALE takes every available dialog process,
on the receiving system, when performing the send.
Configuration needs to happen, on-line, in production systems for
versions up to V4
Error handling: Workflow is used to trap error messages. If you have MS
Exchange then consider implementing the integration between MS and
SAP as this will help the ALE administrator with 1 in-box of errors as
apposed to 1 per client that he supports
ALE specific scenarios

The classification master and it's respective master data object

(vendor, material or customer) are not linked, in any way, via ALE
message types up to V4. This implies that the classification master may
end up on systems where it is irrelevant.
OSS notes need to be implemented to improve the speed of the
programs RBDAPP01, RBDMANIN, RBDMIDOC, RBDSTATE.
OSS note needs to be implemented to get the ALE recovery tool. BDRC
and BDRL.

Deliverables before / during this stage

ALE Administrator Troubleshooting Procedure - What to do when the
unexpected happens...
ALE Archiving strategy and procedure - When and how are you going to
archive the IDocs. Remember the legal implications.
ALE Capacity Planning Guide - Check the growth and plan for expansion.
ALE Failure and recovery procedure - In case a system needs to be
restored to a point back in time, how do you recover???
ALE Background Job Scheduling Procedure - Example of how to
configure ALE for use with background jobs as opposed to immediate
processing .
ALE Performance Testing & Tuning Guide - Some tests done to measure
performance, together with the results and recommendations.
ALE Production client cleanup procedure - When a client is created, what
steps do you need to take to clean it up? When a system is brought down
what do you need to check?