ALE

[Former Member]

Hi all,

I am a beginner in ABAP. i would like to know from the basic steps( from creating clients, logical systems rfc, etc..) in data transfer using ALE.So that i can follow those steps and practise on my own.

[gopi_narendra]

Check this blog

/people/kevin.wilson2/blog/2006/11/13/ale-scenario-development-guide

Regards

Gopi

[Former Member]

Hi,

better to study Aravind Nagapaal book of part 2 which it clearly discuss about ALE

Regards,

Vijay

[Former Member]

ALE is Application Link Enabling (ALE)

It is the set of tools, programs, and data definitions that provides the mechanism for distributing SAP functionality and data across multiple systems. ALE enables the construction and operation of distributed applications.

Its purpose was to overcome the limitations of a single SAP system. A single SAP system that runs on top of one database often does not fulfill the needs of larger corporations, either from a business or a technical perspective.ALE allows the implementation of loosely coupled SAP systems; each of the SAP systems has its own database and is essentially independent from the other systems. ALE allows us to distribute data between different systems and different business processes.

Some Helpful Links

ALE/ IDOC

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/index.htm

http://www.sappoint.com/abap/ale.pdf

http://www.sappoint.com/abap/ale2.pdf

http://www.sapgenie.com/sapedi/idoc_abap.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm

http://www.allsaplinks.com/idoc_sample.html

http://www.sappoint.com/abap.html

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/index.htm

http://www.allsaplinks.com/idoc_sample.html

ALE/ IDOC/ XML

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://www.thespot4sap.com/Articles/SAP_XML_Business_Integration.asp

http://help.sap.com/saphelp_srm30/helpdata/en/72/0fe1385bed2815e10000000a114084/content.htm

IDOC Convertion

/people/kevin.wilson2/blog/2005/12/07/changing-fields-in-an-idoc-segment

http://www.sappoint.com/abap/ale.pdf

http://www.sappoint.com/abap/ale2.pdf

http://www.sapgenie.com/ale/configuration.htm

http://www.sappoint.com/abap/ale.pdf

http://www.sappoint.com/abap/ale2.pdf

http://www.sapdevelopment.co.uk/training

http://www.sapgenie.com/ale/why_ale.htm

http://www.sapdevelopment.co.uk/training

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

[Former Member]

Hi

1 Overview

With the advent of ERP (Enterprise Resource Planning), it

is important to realise that when ERP solutions such as

SAP are implemented, companies have to interface the ERP

system with legacy systems, other ERP systems, customers’

system, vendors’ system, or banks’ system. Customers

often use several R/3 systems. This could be due to

organisational or business reasons (if a customer has

several plants all around the world, for example) or

technical reasons (the data volume or system load is too

large for single R/3 system). In many cases, data has to

be exchanged between these systems. There has been an

increasing and critical need for powerful interfacing

technology.

Decentralized business applications ensuring data

consistency are used because:

• The increasing globalisation of markets has led to the

physical division of organizational units.

• Business processes are not restricted to one

organization only and more and more customers and

vendors are becoming involved.

• R/3 System performance can be improved by distributing

the business applications.

Application Link Enabling and Electronic Data Interchange

(EDI) technologies play a key role in the extension of

enterprise processes across multiple R/3 and non-R/3

systems.

Application Link Enabling (ALE) is SAP’s proprietary

technology that enables data communications between two

or more SAP R/3 systems, and/or SAP R/3 and external

systems. ALE provides intelligent mechanisms whereby

clients can achieve integration as well as distribution

of applications and data.

Application Link Enabling

2 Introduction

SAP System

SAP System

Non-SAP System

IDocs

SAP Transaction

SAP Transaction

Translating

System

ALE supports configuration and operation of distributed

applications. It allows controlled exchange of business

messages between distributed applications with consistent

data retention. The application integration is not

achieved through a centralized database. Instead, the

applications access a local database. Data retention is

redundant. ALE ensures the distribution and

synchronization of master, control, and transaction data

through asynchronous communications. ALE uses synchronous

connections to read data. The coupling between the

distributed systems can either be narrow or loose.

A loose coupling is implemented with asynchronous

communications and is used for write accesses. A narrow

coupling, in contrast, is implemented with synchronous

calls, and should only be used for reading data.

In a distributed environment, it is especially important

that the systems be loosely coupled and independent of

one another. If the called system is down, or a

communication error occurs, the calling system can

continue working normally. Loose coupling means that the

individual systems for the most part communicate

asynchronously with each other.

In contrast to loose coupling, narrow coupling requires

the called system to be available. Narrow coupling is

generally implemented using a synchronous call of a

remote-capable function module. In contrast to

asynchronous communications, the export parameters of the

function module can be evaluated. Synchronous calls are

suitable for verifying or reading data in other systems.

ALE supports synchronous BAPI calls starting in release

4.0. Synchronous dialog calls are supported starting in

release 4.5A. Usually, synchronous writing between two

databases is not allowed, to ensure that any transmission

error that may occur do not result in database

inconsistencies.

SAP delivers ALE technology not only with application

distribution/integration scenarios, but also with a set

of tools, programs, data definitions, and methodology

that can be configured with in a few quick steps to get

the interface up and running. ALE supplies various

services and tools for communication between distributed

application systems:

• Options for maintaining a distribution model

• Consistency checks

• Monitoring data transmission

• Error handling

• Synchronization tools

• Tools for defining new ALE business processes

ALE has many benefits:

• Application data can be distributed between different

releases of R/3 systems.

• Data can continue to be exchanged after a release

upgrade without requiring special maintenance.

• Customers can add their own enhancements.

• Communication interfaces enable connections to non-SAP

systems.

• R/3 and R/2 systems can communicate with each other.

• Due to structured approach and minimum number of

development objects, an ALE interface is easier to

maintain.

• Facility for monitoring message flows and handling

communication problems.

3 ALE Concepts

This section introduces the building blocks and

associated concepts of ALE/EDI. These building blocks are

fundamental to ALE/EDI functionality.

3.1 Logical System

A logical system (LS) is the representation of an R/3 or

external system for distribution of data to and from the

R/3 system. Every R/3 client used for ALE or EDI has to

have a base logical system associated with the client.

This LS becomes the ‘sender’ for outbound messages, and a

‘receiver’ for inbound messages.

3.2 Message Type

A Message type represents the application message being

exchanged between SAP systems or between SAP and non-SAP

system. A message type characterizes the data being sent

across systems, and relates to the structure of the data,

an IDOC type.

3.3 IDOC Type and IDOC

An IDOC (Intermediate Document) type represents the

structure of the data associated with the message type,

while an IDOC is an object with data of a particular

message type in it. IDOCs contain administrative

information for technical processing, as well as the

actual application data, which is stored in segments.

3.4 Customer Distribution Model

ALE distribution model describes the message flow between

logical systems. The distribution model defines which

messages are exchanged between systems and which BAPIs

(starting in release 4.0) are called.

3.5 Filter Object Types and Filter Objects

A filter object type is used in the distribution model to

impose a selection criterion on the message (type)

flowing to a logical system. A filter object type with a

value associated with it is called a filter object.

3.6 Ports

A port is a logical representation of a communication

channel in SAP, with the data communicated being IDOCs.

The process flow depends on the port type (e.g. file,

trfc, CPI-C, Internet, Programming Interface, XML).

3.7 Process Codes

Process codes are used to identify the function module or

API to be invoked for subsequent processing. An inbound

interface uses a process code to determine the

application module that will process the inbound IDOC to

an SAP application object. An outbound interface uses

process codes only in the case of applications that use

message control. In this case, the process code

identifies the application module that populates the IDOC

with the application data.

3.8 Partner Profile

A partner profile is an identifier for a system used for

communicating messages. You must maintain partners with

whom you communicate via IDOCs in the partner profile.

<b>

REWARDS POINTS IF USEFUL</b>

rgrds

shazia

[Former Member]

ALE Setup:

o Document ALE-EDI Documentation talks about setup for both EDI and ALE. This document covers the setups specific to ALE.

o ALE is mainly used for transfer of Master or Transaction data within organization onto distributed servers. Hence the partner in most practical cases is Logical System.

o In case of ALE, 2 types of IDOCs are generated:

&#61607; Master IDOC: This IDOC is in memory and is not stored in the system. You cannot view a Master IDOC.

&#61607; Communication IDOC: From Master IDOC communication IDOCs are generated, one each for all the recipient system, considering the filters. If there are 3 recipient systems which can receive this IDOC, there would be one Master IDOC generated and 3 communication IDOCs.

o Steps in ALE Setup:

&#61607; Maintain Logical system

&#61607; Assign Logical system to Client

&#61607; Setup an RFC destination (SM59) (Name same as Logical System Name)

&#61607; Port Definition

&#61607; Maintain Customer Model (BD64)

&#61607; Generate Partner Profile (BD82)

&#61607; Distribute Customer Model (BD64)

o In ALE you partner is always a Logical system.

Let us look at each setup in detail:

Maintain Logical system: Logical system is the name of your system and the target system. You can decide any name for your system.

o Transaction: SALE

o Execute “Define Logical System”

o Add new entry to define your own Logical System. If ALE is already setup then you can use the existing Logical system definition.

o You also need to define Logical System for your Target System.

Assign Logical system to Client: You need to assign Logical System to Client. You can have only one Logical system per client.

o Transaction Code: SALE

o Execute “Assign Client to Logical System”

o Add a new entry to assign Logical System to a Client.

Setup RFC Destination: Refer to RFC Destination setup on Page 12 of ALE-EDI Documentation.

Setup Port: Refer to Port setup on Page 16 of ALE-EDI Documentation.

Maintain Customer Model: Customer Model defines what message types can be communicated with your Partner and who all will be the recipient of particular message type.

o Transaction: BD64

o Customer model is used only in ALE as it uses Logical system as its Partners.

o If you are creating the customer model for the first time, you will have to create a Customer Model View. This is a logical definition where you can store all your recipient partners and message types.

o Once Model View is created, you can add Message types for a sender and receiver partner.

o Click on “Add Message Type”

o This means Logical System “ID1CLNT800” can send MATMAS message type to Logical System “TRNG300”

o You can add any number of message types for this sender/receiver combination or you can add any number of sender/receivers.

o Since Sender in this case is a Logical system and Logical system can be assigned only to one client, logically you’ll have same sender sending data to multiple recipients.

o Once you have defined the sender/receiver and message types, you need to create Partner profile. You cannot send or receive IDOC without Partner profile. To create a Partner profile follow path: Environment->Generate Partner Profiles.

o Now you have defined what you are going to send to your Partner, but even your partner needs to know what should he be receiving. To avoid any mismatch, BD64 provides you a facility to share your Model View definition with your Partner. Use following Menu Path: Edit->Model View->Distribute. This will create this Model View at the recipient system, in our case Logical System “TRNG300”.

o System will popup a window with a list of recipients, you have to choose the recipient to whom you want to distribute this model view to. By default it will highlight all the recipient for the model view you have selected.

o This creates a Model view at destination Logical System: Lets logon to client 300 and confirm this.

Change Pointers: Change pointers are used to identify the changes done to Masters. With change pointers you can distribute the master data that has been changed. You also have an option of distributing master data irrespective of changes. Decision is based on the business requirement.

o Transactions:

&#61607; BD61: Enable Global Change Pointers

&#61607; BD50: Enable Change Pointers for Message Type

&#61607; BD52: Specify fields for which Change pointers are to be written

&#61607; RBDMIDOC: to distribute master data based on change pointers.

o In the distributed server scenario, you would maintain the master data on central server.

o Whenever the master data is changed you would want the remote server’s master data to be updated with the latest changes.

o You have 2 options:

1. Distribute all the master data again.

2. Distribute the changed master data.

o Option 2 is a better option as you avoid sending unchanged data again. This can be achieved through change pointers.

o Steps to setup change pointers:

&#61607; Enable Global Change Pointer (BD61). Unless Global change pointer is enabled change pointers will not work.

&#61607; Enable Change pointer for message type (BD50). After Global change pointer is enabled, you have to enable the change pointer for a message type. E.g. If you want to capture change pointers for material master, enable the change pointer for MATMAS

&#61607; Define field list (BD52). Every message type has default field list, you can add or delete fields from this list. Whenever you change the value in the field which is included in this field list, only then you change pointer will get captured. Fields values changed for fields not included in this list, change pointers will not get captured. E.g. Say for MATMAS I define only field in field list, MATKL (Material group). In material master whenever I change Material Group value, change pointer will be captured. If I change any other field change pointer is not captured.

&#61607; Run program RBDMIDOC for a specific message type to distribute the master data based on change pointer.

&#61607; Or run specific master data transaction to distribute master data irrespective of change pointer. E.g. For material master transaction is BD10.

Filters: If you want to restrict the data content sent to distributed servers you can use filters.

o There are 3 types of filters:

&#61607; Filtering at IDOC level: You can drop the entire IDOC at sender for specific recipient.

&#61607; Segment Filtering: You can drop certain segments at sender for specific recipient.

&#61607; Reduced IDOC type: You can design you own IDOC type, which will be a subset of original IDOC type, at sender.

o Lets look at these 3 filter options in detail. Let take a example of a company “X” which has a Sales office “S”, 2 plants “P1” and “P2” with plant codes for P1 = 01 and for P2 = 02. All these locations, sales office and plants, have a local server at their location and are connected to central server in head office “X”.

o First lets take “Filtering at IDOC Level”:

&#61607; You have a Material master which is already distributed to all the systems.

&#61607; If the business user changes some data in material master for plant P1, this needs to be communicated to plant P1. So using change pointer you would capture this change and using RBDMIDOC you’ll create IDOCs to distribute this material master. But since all the local servers are set to receive message type MATMAS, this IDOC would be sent to all the recipients S, P1 and P2. But you requirement is since data was changed only for plant P1, IDOC should go to only Plant P1. This is where your IDOC filtering is used.

&#61607; In the Filter, you define that a particular IDOC should be created and distributed for the values maintained in customer model. So for P1 you would setup in such a way that IDOC will be created for Plant P1 only if Plant code (WERKS) = “01”, for Plant P2 only if Plant code (WERKS) = “02”. Hence in the above scenario since data for Plant P1 was changed, Master IDOC would be created for Plant P1 with WERKS = “01” and as per filter condition, Communication IDOC would be created only for Plant P1.

&#61607; Lets look at the steps to setup this Filter.

o Go to transaction BD64:

o Select the model view, Sender - receiver combination and Message type where you want to add the filter.

o Double click on “No Filter Set”

o Click on “Create Filter Group”

o Double Click on Plant (Or which ever field where you want to set the Filter)

o Enter the Plant numbers for which you want the communication IDOC to be created for this sender, receiver and Message Type.

o Now it will show “Data Filter Active”.

o Now Lets look at Segment Filter:

- Now, Business user changes a sales view and Plant view in Material Master.

- System will create 3 communication IDOCs for 3 local servers S, P1 and P2. All 3 IDOCs will contain Sales view and Plant view (Certain segments in MATMAS have been identified for Sales view and Plant view. Whenever you change data for plant or sales view these segments get populated with data.). Why would a Plant need Sales View? Or why would sales office need a Plant view? Let consider our business requirement is Plant should not get sales view and Sales office should not get plant view.

- In this case IDOC filtering cannot be used, because we want the IDOC to reach all 3 locations. This is where you would use Segment filtering. You’ll drop the segments which contains Sales view data for the IDOC sent to Plants P1 and P2, and you would drop the segments that contain Plant view data for the IDOC sent to Sales Office.

- But you cannot drop mandatory segments

- This is how you setup segment filtering: Go to transaction BD56

o Enter the message type for which you want to set the segment filtering

o Press “Enter”

o You can select the segments that you want to drop for a specific sender, receiver and message type.

o Typ: Enter Partner Type

o Sender: Enter sender Logical System

o Func/Role: You can specify the Partner type of sender e.g. AG/WE/LF….

o Receiver: Enter recipient Logical System

o Segment Type: Enter the segment that you want to drop for this sender receiver.

o Then save the entries. Your Segment filter is set.

o Now, Lets look at reduced IDOC type:

- This filtering is used to reduce the data content in IDOC. You can decide on which fields or segments you want to communicate to the Recipient.

- For this you have to create a reduced message type, which will be a sub-set of original message type.

- Go to transaction BD53

o Give the reduced message type name and click on create.

o Segments in green are Mandatory segments and are active by default.

o Segments in Red are inactive (i.e. Not selected for this reduced message type)

o You can activate the segments that you want to use and the select the fields that you want to use.

o To activate a segment click on the segment and then click on “Select”.

o The color of the segment changes to White. That means this segment is selected.

o To select the fields double click on the segment:

o Select the fields and click on “Select”.

o The fields which have been selected will contain the values while the segments which were not selected will carry “/” in the IDOC. By sending “/” in the IDOC the recipient system understands that these fields have to be ignored.

[Former Member]

3.0 Configuring ALE:

The essential entities involved in the ALE framework have been discussed above. We will now proceed with the configuration methodology for ALE implementation. The configuration is a multi-step approach. The steps can be categorized as follows (as depicted in figure 5):

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.

4.0 Other Useful ALE Concepts and Conclusion:

Here are few additional concepts which are broadly applicable to ALE and will help readers understand SAP’s integration services.

Listings are special filter object types, which are used to specify a selection criterion for distributing master data. Listings are based on the SAP Classification system. Lists are allocated to an LS using transaction SALE (from the ALE customizing guide) or Distribution Scenarios > Master Data Distribution > Distribution via Listings

Note: Listings are applicable only to Material, Customer, and Vendor master data.

Ports are a logical representation of the communication channels in SAP. R/3 defines four types of ports viz. tRFC (transactional Remote Function Calls), File, R/2, and Internet. ALE can use all port types to distribute Idocs.

Process Codes are used in both ALE and EDI framework to identify the function module or API (Application Programming Interface) to be invoked for subsequent processing. Inbound as well as outbound interfaces use process code but for different purposes. Outbound process codes are stored in table TEDE1, while inbound process codes are stored in TEDE2.

Message control is a mechanism by which documents are output based on a selection criteria and requirements. This concept is applicable not only to EDI and ALE, but also to other output mediums (for example: print, fax). Message control determines the type of document, its timing, number, and the medium. NAST table stores output records.

The conditions (selection criteria and requirements) for creating an output message are stored in condition tables. Search mechanisms are used through access sequences, output processes, and requirements to determine whether an application document qualifies for output.

ALE provides powerful capabilities to capture changes occurring to master data using Change pointers. These R/3 objects mark changes to SAP master data. ALE configuration facilitates the relation between Change Document objects and change pointers. This feature can be used to keep two or more systems synchronized with respect to master data.

In conclusion, ALE is a simple add-on application that relies heavily on the customizable distribution scenario. Every time a data object (described in an ALE scenario) changes, an IDoc is triggered. Application Link and Enabling (ALE) is one of the most common and effective technologies available for distributed SAP systems.

In this 7 article tutorial we have covered subjects such as:

• Data Distribution Model

• ALE process

• IDOCS

• Converters

• Configuring ALE

• Other concepts

<b>

see this

http://www.iryx.co.uk/ALE%20Overview_files/frame.htm#slide0022.htm</b>

also check these links

ALE/ IDOC

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/index.htm

http://www.sappoint.com/abap/ale.pdf

http://www.sappoint.com/abap/ale2.pdf

http://www.sapgenie.com/sapedi/idoc_abap.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm

http://www.allsaplinks.com/idoc_sample.html

http://www.sappoint.com/abap.html

http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm

http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc

http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419

http://www.netweaverguru.com/EDI/HTML/IDocBook.htm

http://www.sapgenie.com/sapedi/index.htm

http://www.allsaplinks.com/idoc_sample.html

Check these step-by-step links

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/uuid/ccab6730-0501...

https://sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/uuid/8fd773b3-0301-001...

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/uuid/3c5d9ae3-0501...

regards,

srinivas

<b>*reward for useful answers*</b>