ALE Technology/Business Processes 

Description

ALE Technology has been enhanced in Release 4.5A. New developments for asynchronous data transfer include serialization using object types, new functions for generating ALE interfaces, managing data replication through filtering BAPI parameters and enhanced receiver determination for BAPIs.

For synchronous data transfer the authorization concept has been enhanced to enable multiple RFC destinations to be specified for one logical system.

Methods can now be called in non-SAP Systems.

In 4.5A the Visio Viewer for maintaining models is provided as part of the standard system.

You can also select and delete (or delete for test purposes) change pointers for message types according to the date and time created. (Transaction BD22).

New standard ALE Business Processes have been added and existing processes have been enhanced.

These developments along with others are summarized below. For further information on ALE Business Processes and ALE Technology refer to the:

• Implementation Guide (IMG):
  Cross Application Components, Distribution (ALE)

• R/3 Library:
  CA - Cross-Application Components
  Business Framework Architecture
  Application Link Enabling (ALE)

STAND-ALONE COMPONENTS

HR

From Release 4.0A the majority of interfaces between Human Resources, Logistics and Accounting used within an R/3 System can also be supported in a distributed environment.

In 4.5A the Accounting interfaces have been enhanced with the filter objects - company code and controlling area.

PDM

The PDM (Product Data Management) scenario allows different R/3 Systems to be used for Product Development and for Production. Additional master data interfaces were provided in 4.0A for this purpose.

In 4.5A original documents can be distributed.

New ALE Business Processes

The following ALE Business Processes are provided in 4.5A:

• Basis (BC)
  Central User Administration
  User master records can now be maintained in one central system. The user data is assigned to logical systems and then distributed from the central system to all the relevant systems.
  You can choose to maintain individual fields in local systems or in the central system.

• Logistics (LO)
  Purchasing: distributed service contracts
  Master data purchase contracts
  Separate component WM for finished products
  PDM: distributable original documents
  Project System: distribution of WBS elements

• Accounting (AC)
  Asset Accounting: Transferring assets between systems
  Controlling: distributing CO orders (internal orders)
  Controlling: Central cost center planning, decentralized system owners of postings
  Controlling: Decentralized system owners of profit centers
  Distribution of exchange rates

• Human Resources (HR)
  The decoupled HR system supports several Accounting systems (filter objects - company code and controlling area)
  Distribution of trip accounting results between Accounting systems.

ALE TECHNOLOGY

Compare Tool for Data Inconsistencies Following Database Recovery

If a sender system is restarted with an earlier status, data inconsistencies may occur in the receiver system. The compare tool can eliminate any inconsistencies by canceling any data received from the sender after it was restarted.

Unique Names for Logical Systems

In view of the increasing componentization and openness of R/3, logical systems must be able to communicate with each other, even beyond the boundaries of ALE integrated systems, for example, for central user administration. Logical systems including those beyond the boundaries of an ALE integrated system should therefore have unique names.

Tools are available to convert customizing, application and master data if logical systems are changed. Please refer to Note no. 103228.

ALE Distribution Model

• Filter Type Dependencies
  4.0A: Only dependencies between message types can be mapped.
  4.5A: Dependencies between BAPIs or between BAPIs and message types can be mapped.

• Copying Model Views
  You can copy model views to other environments. If you follow the above recommendation and use unique names for logical systems in different environments, you have to create a local copy and change the names of the logical systems so that they match those in the target system.
  Finally, you can transfer the copy of the model view to the target environment.

• Visio Viewer
  The Visio Viewer which displays the distribution model graphically is provided in the standard system as of 4.5A.
  In SAPnet you can download the Visio add-on for use with R/3 Releases from 3.0D.

Method Calls to Non-R/3 Systems via Outbound BAPIs

In 4.5A you can define BAPIs for calling non-R/3 systems in the BOR, that is, you can call methods that are not implemented in R/3.

The method calls are created as interface types in the BOR.

Asynchronous Data Transfer:

• BAPI Integration: Generating ALE Interfaces from BAPIs
  From 4.0A BAPIs can be used for both synchronous and asynchronous communication between systems. With asynchronus communication, a tool can be used to generate the following ALE interface objects from BAPIs:

• Message type

• IDoc structure

• Segments of the IDoc structure

• Outbound function module (IDoc data structure and dispatch)

• Inbound function module (BAPI call with IDoc data)

Until now you could only recreate, regenerate, and delete these objects.
In Release 4.5A you can also display, check and release objects and cancel released objects. Documentation is provided on the function modules generated.

For further information on the generated ALE interface refer to "ALE Programming" in the R/3 Library.

• Filtering Parameters
  By filtering parameters you can manage the replication of BAPI interface datasets in the ALE distribution model using filter objects.

• Dependencies Between BAPI Table Parameters
  You can define hierarchical dependencies between BAPI table parameters, for example, between plant and warehouse data.
  If you have defined such dependencies, IDocs are generated in a heirarchy.
  

• Serialization of Dependent Objects
  If there are dependencies between objects, new objects must be created in the correct order in the target system. For example, material must be created before classification.
  In Release 4.0A you could serialize objects using message types.
  In 4.5A serialization using object types is supported.

• Displaying Application Log from IDoc Error Handling
  You can branch from error handling into the application log.
  

Synchronous Data Transfer:

• Authorization Concept
  In 4.5A you can specify multiple RFC destinations for one logical system:

• Standard Destination for BAPIs
  For BAPIs a user of type CPIC can be used in the server system.
  

• Standard Destination for Dialog Methods
  For dialog methods a user of type DIALOG must be used in the server system.

• Standard Destination for Special Methods
  Such a destination is required for methods that need to be secure, for example, for objects in Human Resources.