IBM Global Services © 2005 IBM Corporation SAP Legacy System Migration Workbench| March-2005 ALE (Application Link Enabling)

IBM Global Services © 2005 IBM Corporation 2March-2005SAP Legacy System Migration Workbench| Objectives  The participants will be able to:  Describe the Purpose of ALE.  Architecture of ALE.  Describe the Definition of different Component of ALE.  Standard message type used in SAP.

IBM Global Services © 2005 IBM Corporation 3March-2005SAP Legacy System Migration Workbench| An ALE Definition  ALE (Application Link Enabling) supports the construction and operation of distributed applications. ALE handles the exchange of business data messages across loosely coupled SAP applications, ensuring that data is consistent. Applications are integrated by using synchronous and asynchronous communication, rather than by means of a central database."

IBM Global Services © 2005 IBM Corporation 4March-2005SAP Legacy System Migration Workbench| What is ALE?  ALE is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems.  ALE provides intelligent mechanisms whereby clients can achieve integration as well as distribution of applications and data. ALE technology facilitates rapid application prototyping and application interface development, thus reducing implementation time.  ALE comes with application distribution/integration scenarios as well as a set of tools, programs, data definitions, and methodologies that you can easily configure to get an interface up and running.

IBM Global Services © 2005 IBM Corporation 5March-2005SAP Legacy System Migration Workbench| Architecture of ALE  Application layer :  This layer provides ALE with an interface to R/3 to originate or receive messages containing data to or from external (or other R/3) systems.  Distribution layer :  The distribution layer filters and converts messages containing data based on predefined or custom-defined rule sets. These conversions may occur to ensure compatibility between different releases of R/3 and R/2.  Communications layer :  ALE communications are carried out both synchronously and asynchronously

IBM Global Services © 2005 IBM Corporation 6March-2005SAP Legacy System Migration Workbench| Advantages of ALE  ALE offers better inbound interface performance compared to traditional techniques such as Batch Data Communications (BDC) or Call Transactions. ALE does not use screen-based batch input.  ALE is the strategic architecture for R/3 “loose coupling” with legacy and third-party applications and is a Business Framework key element. It provides a message-based architecture for asynchronous integration of Business Framework components, including Business Components, Business Objects, and BAPIs.

IBM Global Services © 2005 IBM Corporation 7March-2005SAP Legacy System Migration Workbench| Components of ALE  Legacy System.  Message type  IDOC type  Customer Distribution Model  Filter object type and filter objects  Change pointers  Ports  Process codes.  Partner profile.  Message Control

IBM Global Services © 2005 IBM Corporation 8March-2005SAP Legacy System Migration Workbench|  The Customer Distribution Model is a tool that stores information about the flow of messages across various systems.  A filter object type is used in the Customer 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  Change pointers are R/3 objects that mark changes to SAP master data. Change pointers are managed by mechanisms in a Shared Master Data (SMD) tool and are based on Change Document (CD) objects. CD objects record the changes occurring to master data at a field level. These changes are stored in tables CDHDR (header table) and CDPOS (detail table). Main Design Steps

IBM Global Services © 2005 IBM Corporation 9March-2005SAP Legacy System Migration Workbench| Maintain Object Attributes  A port is a logical representation of a communication channel in SAP. There are four types of ports that can be defined in R/3: tRFC, File, R/2, and Internet.  Process codes are used in ALE and EDI to identify the function module or API. Each process code is associated with a message type. Outbound process codes are stored in table TEDE1, while inbound process codes are stored in TEDE2.  Use transaction WE41 to display outbound process codes and WE42 to display inbound codes  Message control is a mechanism by which documents are output based on certain selection criteria, requirements, and sequences. Message control determines the type of document, its timing, number, and medium (print, fax, ALE, or EDI.)

IBM Global Services © 2005 IBM Corporation 10March-2005SAP Legacy System Migration Workbench| A partner profile :  is an identifier for a system used for communicating messages. There are four types of partner profiles: KU for Customer, LI for Vendor, B for Bank, and LS for Logical System. KU, LI, and B are used for EDI partners, while LS is used for ALE communications

IBM Global Services © 2005 IBM Corporation 11March-2005SAP Legacy System Migration Workbench| Idoc Definition  An intermediate document (IDOC) is a container for distributing R/3 application data among between R/3, R/2 and non-SAP systems  Use  ALE uses IDocs to exchange data between logical systems. Non SAP- systems can use IDocs as the standard interface for data transfer. IDocs are created by message types and (object) methods when data is to be distributed. The message type is the format in which the data for a specific business process is transmitted electronically.

IBM Global Services © 2005 IBM Corporation 12March-2005SAP Legacy System Migration Workbench| Maintain Structure  An IDoc represents a configuration of an Idoc Type that determines the IDoc structure. An IDoc consists of a header, several data segments and status records. The functions of the individual elements of an IDoc are as follows:  The contents, structure, sender, receiver and current status of the IDoc are defined in the IDoc header.  Each data segment contains a standard header consisting of a sequential segment number, a description of the segment type and a 1000 character long string field containing the actual data of the segment.  The status records show the history of the processing steps applied to the IDoc.

IBM Global Services © 2005 IBM Corporation 13March-2005SAP Legacy System Migration Workbench| Structure of an IDoc *

IBM Global Services © 2005 IBM Corporation 14March-2005SAP Legacy System Migration Workbench| In the Sending System:  Transaction Code for IDoc list is : WE05  A list of IDocs grouped by status is displayed:  StatusDescription of Status 03, 12, 38IDoc successfully transferred  02, 04, 05, 25  26, 29Processing error  30Waiting status

IBM Global Services © 2005 IBM Corporation 15March-2005SAP Legacy System Migration Workbench| In the Receiving System  Transaction Code for IDoc list is : WE05  A list of IDocs grouped by status is displayed:  StatusDescription of Status  53IDoc successfully updated  64Waiting status (still processing...)  63, 65Inbound error

IBM Global Services © 2005 IBM Corporation 16March-2005SAP Legacy System Migration Workbench| Message Types :  The flow of message across Distributed environment is done through Message Types.  APPLICATION MESSAGE TYPES  CUSTOMER-DEBMAS  VENDOR-CREMAS  MATERIAL-MATMAS  SALES ORDER- ORDRSP  PURCHASE ORDER-ORDERS  T-Code to view the Message Types is : WE81.

IBM Global Services © 2005 IBM Corporation 17March-2005SAP Legacy System Migration Workbench| TRANSACTION CODES FOR ALE  /N SALE : To Define and Assign Logical Systems.  /N SM59 : To Establish RFC Connection.  /N BD64 : To Create Customer Distribution Model.  /N BD82 : To Generate Partner Profiles.  /N WE05: To View IDoc Lists. /N BD10: To Send the Material Data.  /N BD11: To Receive the Material Data.  /N WE19: To Debug the IDoc.