APPLICATION LINK ENABLING

ALE
Distributed Scenario Reason for distributed scenario Inbound Ale process Configuring Ale Process

Saps solution for distributed processes (ale) Advantage of Ale Ale Architecture Outbound Ale process
Cybertech Systems and Software Ltd.

Configuring Ale Interfaces Distributing Master Data Quiz

Cybertech Systems and Software Ltd.

Distributed Scenario

A distributed process is one in which part of a business process is carried out on one system and part on another . The sales process that performs all sales related activities such as storing a sales order ,calculating delivery dates ,checking the availability ,performing credit checks and calculating price could be carried out on one sap system . The shipping process that performs shipping point ,creating deliveries ,picking goods ,calculating the shrtest route ,determining the cheapest mode of transportation ,and performing good issue could be carried out on another SAP systems . Two system exchanged the data with each other at appropriate points to stay synchronized .
Previous Next

Cybertech Systems and Software Ltd.

Reason for distributed processes

Geographical

Location Consolidation System Capacity Mission Critical Application Upgrading Module Separately
Data

Security Political and Business Reason

Previous

Next

Cybertech Systems and Software Ltd.

Saps Solution For Distributed Scenario

Sap introduce Ale as its initiative to support a distributed yet integrated environment. Ale allows for efficient and reliable communication between distributed processes physically separated SAP systems to achieve a distributed , yet integrated logical SAP system . Ale is not based on any database replication techniques .It is based upon application to application integration using messaging architecture ; a message defines data that is exchanged between two processes . Idocs are container that hold the data exchanged between the two systems .

Previous

Next

Cybertech Systems and Software Ltd.

Advantage of Ale Distributed Environment

Integration With Sap-Sap/Non-Sap to Sap Reliable Distribution(ale supports guaranteed delivery,which means an

application sending a message does not have to worry about network problem .The application generates a message and a correct receiver information .If the network is not proper message is buffered and when network is restored,buffered message are delivered.)

Release Upgrade (Any of the distributed systems can be upgraded to a

newer release of sap system without affecting the existing functionality .The ale Layer ensure backward compatibility of message exchanged between systems .for example sales system can be upgraded without requiring an upgrade of shipping system .

Autonomy(SAP systems connected via ale are loosely coupled,but they provide
a high level of business integration .The systems can operate independently if network problems or maintenance on one systems disrupts the connection.Each system maintain maintains its own data and application s. The systems are administered separately,and various maintenance task can be carried out on an independent basis without affecting the partner system. Previous Next

Cybertech Systems and Software Ltd.

How ale works

SAP System

SAP T nsaction ra

IDocs
SAP T nsaction ra Translating Syste m No n-SAP System

SAP System

Previous

Next

Cybertech Systems and Software Ltd.

Ale Architecture
Process

flow i.Out bound Process ii. Inbound process iii.Exception handling process(via work flow) Layers in Ale processes i. Application layer ii.Ale service layer iii.Communication Layer
Previous Next

Cybertech Systems and Software Ltd.

Ale architecture

Previous

Next

Cybertech Systems and Software Ltd.

Outbound process
Identify

the need for sending an idoc Generate the master idoc Generate the communication idoc Deliver the communication idoc

Previous

Next

Cybertech Systems and Software Ltd.

Outbound process

Previous

Next

Inbound process
Store

the idoc in the database Invoke the posting module Create the document

Previous

Next

Inbound process

Previous

Next

Configuring Ale Infrastructure

Setting up Clients First of all, you have to set up two clients to enable communication between logical systems. The two clients may be located in the same R/3 System or in separate systems. You can either use existing clients or you can create new clients by making copies of existing ones (for example, a copy of client 000 or a client of the International Demo and Education System (IDES)). To set up a new client, from the SAP standard menu choose Tools Administration Administration Client administration Client maintenance.
Previous Next

Defining Logical System Names for Clients

To avoid any confusion, participating systems in a distributed environment must have an unique ID. The name of the logical system is used as the unique ID. This name is assigned explicitly to one client in an R/3 system.

Logical system Csslsap100 Csslsap200

Previous

Next

Previous

Next

Assign Logical System to client

Assign

logical system to client Client Logical System 100 CSSLSAP100 200 CSSLSAP200

Previous

Next

Previous

Next

Previous

Next

Defining the Communication Parameters

Defining RFC Destination For the two logical systems to be able to communicate with one another, they must know how to connect to each other. The RFC destination provides this information. Target System : The target system indicates which receiving system application server is to handle the communication. Connection type r/3

Previous

Next

Previous

Next

Previous

Next

Assign RFC destination for logical system

Previous

Next

Modeling the Distribution

Maintain Distribution Model

The systems involved in the distribution must know which messages are to be distributed. They must know where the messages are coming from and where they are going to. This information is specified in the distribution model. The distribution is based on the distribution model and is directly controlled by it. Create distribution model Assign sender client(logical system name CSSLSAP100) Assign receiver client(Logical system CSSLSAP200) Assign message type (ex. for material mater MATMAS)
Previous Next

Previous

Next

Previous

Next

Previous

Next

Previous

Next

Generating Partner Profiles in the Sending System When you have created the distribution model, you must tell the participating systems how ALE is to execute the transfer the data. This is done in the partner profiles. First, generate the partner profiles in the sending system (CSSLSAP100). To do this, log on to the relevant logical system. Enter the distribution model logical system version(Idocs record type from version 4.0b) packet size
Previous Next

Previous

Next

Previous

Next

Previous

Next

Distributing the Distribution Model

To be able to generate the partner profiles in the receiving system, this system must be informed of all the messages flows in the distributed environment. This is achieved when you transport the distribution model views from the sending system to the receiving system. Carry out the following steps in the sending system

Previous

Next

Generating Partner Profiles in the Receiving System

When you have copied the distribution model to the receiving system, you can also generate the partner profiles here. To do this, log on to the receiving logical system (for example, CSSLSAP200 ).

Previous

Next

Creating Material Master Data

Choose Logistics Materials management Material master from the material master maintenance. Choose Material Create (general) Immediately Base unit of measure: ST Language: E Material short text: Material for ALE: First steps Save the material.

Previous

Next

Sending Material Master Data BD10

send the material you have just created to the receiving system. Choose General Material Send: Enter the material you have created (for example, Material001). Use MATMAS Message type: Enter CSSLSAP200, the logical receiving system Execute the program. Now you should now be able to display your material in the receiving system. If the material is not available here, either the transmission has not yet finished or an error has occurred. The next step shows you how to check the communication and detect any errors.
Previous Next

Distributing Master Data

Let as assume that we want to distribute three types of master data objects material master creditor master debtor master Let us also assume that we have four offices . Any of these offices operates an own stand alone R/3 system. Data is exchanged as IDocs which are sent from the sending office and received from the receiving office.

Previous

Next

The following table shows the same distribution channels as the graphic.
Data Object MATMAS MATMAS MATMAS MATMAS MATMAS DEBMAS DEBMAS CREMAS CREMAS CREMAS Material Master Material Master Material Master Material Master Material Master Debitor Master Debitor Master Creditor Master Creditor Master Creditor Master Sender R3NYX R3NYX R3NYX R3PAR New York Office New York Office New York Office Paris Office Receiver R3VEN R3PAR R3LAX R3VEN R3VEN R3VEN Venice Office Paris Office Los Angeles Venice Office Venice Office Venice Office

csslsap100 India R3PAR R3PAR R3NYX R3PAR Paris Office Paris Office New York Office Paris Office

Csslsap200 India R3VEN R3VEN R3VEN Venice Office Venice Office Venice Office

Csslsap100 India

Previous

Next

Sending Master Data

Previous

Next

Monitoring Communication
The system provides functions for monitoring communication. These functions enable you to check whether the communication was successful or whether errors occurred. If an error did occur, the type of error is indicated . In the Sending System:
Status 03, 12, 38 02, 04, 05, 25 26, 29 30 >=50 Description of Status IDoc successfully transferred Processing error Waiting status (still processing...) Inbound IDoc (not relevant in this context)

Previous

Next

Monitoring Communication
In the Receiving System Status 53 Description of Status IDoc successfully updated by application

64 Waiting status (still processing...) <50 Outbound IDoc 51, 56, 60, 61,63, 65 Inbound error

Previous

Next