SAP Useful ALE Transaction Codes

ALE is customised via three main transaction. These are SALE, WEDI and BALE.

This is the core transaction for SALE customizsng. Here you find everything ALE
related which has not already been covered by the other customising transactions.

WEDI - IDoc Administration :

Here you define all the IDoc related parts, which make up most of the work related
to ALE.

BDBG - Automatically generate IDocs From A BAPI :

Good stuff for power developers. It allows you to generate all IDoc definitions
including segments and IDoc types from the DDIC entries for a BAPI definition.

ALE Customizing SALE

All ALE special customiing is done from within the transaction SALE, which links
you to a subset of the SAP IMG.

The scenario defines the IDoc types and the pairs of IDoc partners which participate
in the ALE distribution. The distribution scenario is the reference for all ABAPs and
functionality to determine which data is to be replicated and who could be the
receiving candidates. This step is, of course, mandatory.

The change pointers can be used to trigger the ALE distribution. This is only
necessary if you really want to use that mechanism. You can, however, send out
IDocs every time an application changes data. This does not require the set-up of the
change pointers.

SAP allows the definition of rules, which allow a filtering of data, before they are
stored in the IDoc base. This allows you to selectively accept or decline individual
IDoc segments.

ALE allows the definition of conversion rules. These rules allow the transition of
individual field data according mapping tables. Unfortunately, the use of a function
module to convert the data is not realized in the current R/3 release.

The filter and conversion functionality is only attractive on a first glance. Form
practical experience we can state that they are not really helpful. It takes a long time to set up the rules, and rules usually are not powerful enough to avoid modifications in an individual scenario. Conversion rules tend to remain stable, after they have once been defined. Thus, it is usually easier to call an individual IDoc processing function module, which performs your desired task more flexibly and easily.

Basic settings have to be adjusted before you can start working with ALE.

Before we start, we need to maintain some logical systems. These are names for the
RFC destinations which are used as communication partners. An entry for the
logical system is created in the table TBDLS.

Finally. you will have to assign a logical system to the clients involved in ALE or
IDoc distribution. This is done in table T000, which can be edited via SM31 or via
the respective SALE tree element.

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 distribution model is shared among all participating partners. It can, therefore,
only be maintained in one of the systems, which we shall call the leading system.

Only one system can be the leading system, but you can set the leading system to
any of the partners at any time, even if the scenario is already active.
This will be the name under which you will address the scenario. It serves as a
container in which you put all the from-to relations.

You can have many scenarios for eventual different purposes. You may also want to
put everything in a single scenario. As a rule of thumb, it proved as successful that
you create one scenario per administrator. If you have only one ALE administrator,
there is no use having more than one scenario. If you have several departments with
different requirements, then it might be helpful to create one scenario per
department.

The model view displays graphically the from-to relations between logical systems.
You now have to generate the partner profiles which are used to identify the
physical means of data transportation between the partners.

A very useful utility is the automatic generation of partner profiles out of the ALE scenario.

Even if you do not use ALE in your installation, it could be only helpful to define the EDI partners as ALE scenario partners and generate the partner profiles.
If you define the first profile for a partner, you have to create the profile header first.

The partner class is only a classification value. You can give an arbitrary name in order to group the type of partners, e.g. EDI for external ones, ALE for internal ones, and IBM for connection with IBM OS/390 systems.