Configuring ALE:

Source from : http://www.thespot4sap.com/Articles/SAP_ALE_Configuring.asp

3.1 Understand and verify the need of business processes

The need of implementing ALE must be clear to you. For that you need to have all the details of the business requirements. These requirements will facilitate the implementation process and also ensuring its success.

3.2 Configure SAP user administration module (BASIS)

This step involves BASIS configuration of SAP system. The concept of the Logical System described above is applicable here. BASIS administration involves creation of logical systems (LS) for every prospective ALE-enabled client, followed by linking prospective clients to the Logical System using the respective servers.

Once the Logical Systems have been created, you create background users on the prospective clients – to be used by ALE. After this, choose Tools > Administration > Administration > Network > RFC destinations or enter transaction code SM59 to create RFC (Remote Function Call) destination for each client.

As a final step, create partner profiles for the sending system. A partner profile is an identifier for the sending system that is used for communicating messages. You will be using LS as it is used for ALE communications. Every partner profile used for ALE must be based on existing LS (created above).

3.3 ALE Functional Configuring in SAP

This configuration step allows the installation of core ALE features on which data transfer activity will be based. You need to create a Customer Distribution Model (CDM) first. The Customer Distribution Model acts as a repository of data that decides the flow of message types to Logical Systems (LS). There can be one to many messages flow to a Logical System and it can also happen vice-versa. You also need to enforce a selection criterion on the message (type) flowing to a Logical System. This is achieved by adding appropriate message types and filters to the CDM.

Now that the path of the message flows have been set, we can generate outbound partner profiles (similarly as we done for inbound profiles in step 2). Finally, you can distribute the CDM to the receiving systems followed by generating inbound partner profiles on each of the clients.

3.4 Testing and Implementing the ALE Configuration

After completing the setup of the ALE environment it needs to be thoroughly checked and tested with real time business processes and situations. The performance should be measured with varying degree of business transaction volumes. It is advisable to include negative and ‘unusual’ test scenarios as well.

Once testing is completed it can be implemented once it is signed off with the respective business owners.

Configuring your ALE solution

Source from : http://www.erpgenie.com/ale/configuration.htm

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;
• 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.

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 decentralise 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.

Source : http://www.erpgenie.com

ALE. What is ALE?

ALE is Application Linking and Enabling. ALE is a mechanism for the exchange of business data between loosely-coupled r/3 applications built by customers of SAP, the enterprise resource management program. ALE provides SAP customers with a program distribution model and technology that enables them to interconnect programs across various platforms and systems.

There are three layers in the ALE system:

1. Application services.

2. Distribution services.

3.Communication services.

IDoc (intermediate document), which is a container for the application data to be transmitted. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model.

IDoc Transactions

* WE09 / WE02 IDoc lists according to content. View IDocs via specific IDoc number or business application detail contained within the contents of a segment.
* WE05 View IDocs
* WE19 EDI test tool. Use to test inbound Function module changes.
* WE20 Partner profile configuration. Add partner detail together with inbound and outbound relationships. We also incorporate message control on the outbound IDocs. Utilize the organizational units to trap functional errors for further processing
* WE30 Create IDoc extension type
* WE31 Segment create
* WE57 Assign function module to logical message and IDoc type
* WE60 IDoc type documentation tool
* WE82 Link Release detail to Extension IDoc Type
* BD55 Conversion rule user exit. Link conversion rule user exit to the different system \ partner combinations
* BD87 Reprocess IDocs in error or waiting for action. (Both inbound and outbound in 4.6. Use BD88 in prior versions)
* BALA ALE Application Distribution
* BALM ALE Master Data Distribution