Basic Concepts of ALE Technology

Purpose
ALE supports the configuration and operation of distributed applications. It allows the controlled exchange of business messages between distributed applications with consistent data retention. The coupling between the distributed systems can be either narrow or loose. 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 use of ALE offers a number of advantages: Distribution of application data between R/3 Systems with different releases Data exchange can continues after an upgrade without any further adjustment Customer-specific enhancements The integration of non-SAP systems through communication interfaces Coupling R/3 and R/2 Systems

ALE supplies various services and tools for the 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

Integration
Types of Coupling
As mentioned above, the coupling between distributed application systems can be either loose or narrow. 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. Both types of coupling can be implemented by calling BAPIs.

Loose Coupling 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. One example in which a loose coupling is essential is inventory management: When an inventory management component is combined with an accounting component, it must be possible to post goods movements even when the accounting component is unavailable. Loose coupling means that the individual systems for the most part communicate asynchronously with each other. In this type of communication, messages are exchanged between the systems. The data format used for these messages is called the Intermediate Document (IDoc). IDocs are structured data containers in which the data can be stored hierarchically. For more information on IDocs, refer to the document "ALE Introduction and Administration" under IDoc. Different communication technologies can be used to send the IDocs: For asynchronous communication between two R/3 Systems, the underlying communication technology is the transactional remote function call (tRFC). The transactional call is not executed immediately; instead, the data to send is first written to a database table. When a COMMIT WORK is triggered in the calling program, the remote call to the receiver system is executed. If the receiver system is currently unavailable, a periodically scheduled background process tries to send the data to the receiver system again later. The tRFC guarantees that the data is only transmitted once. If you want to establish asynchronous communications between R/3 Systems and non-R/3 systems, you can also use CPI/C, MPSeries, or other communication techniques to transmit the IDocs.

If an error occurs while the IDoc is processed, the invalid IDoc is saved and a workflow is generated that enables the ALE administrator to correct the error. These ALE error handling routines ensure that the data is updated consistently. As a result, data replication, updates, and inserts of data in other systems should always take place asynchronously. The disadvantage of asynchronous communications via ALE is that only a single return parameter from the called system is available.

Please note that asynchronous communication does not always mean a large time delay between call and execution. If the target system is available, an asynchronous call can be performed immediately after the COMMIT WORK in the called system. During asynchronous communication via BAPIs, the calling system (client) generates an IDoc with data from the BAPI call (instead of the BAPI call itself) and sends it to the called system (server). The BAPI is then called with the data from this IDoc in the called system. For more information, please refer to Implementing Loose Coupling via BAPIs. Narrow Coupling 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. In this case, the caller of the BAPI function module is automatically logged on to the other system (remote login to the "destination"). The user sees the transaction in the same window, and can navigate through the called system using menus and so on. Synchronous dialog methods are visible in the BOR and are modeled in the ALE distribution model.

Usually, synchronous writing between two databases is not allowed, to ensure that any transmission errors that may occur do not result in database inconsistencies! For more information, please refer to Implementing Narrow Coupling via BAPIs.

Using the ALE Distribution Model

The 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. Filtering The transmission can be controlled data-specifically through filters. Filters are conditions that message types and BAPIs have to meet in order to be distributed by ALE outbound processing.

A customer uses a centralized inventory management system and several accounting systems. If stocks change in company code 0001, accounting data is sent to accounting system 01; if they change in company code 0002, accounting data is sent to accounting system 02. You can differentiate between the following types of filters for BAPIs: 1. Receiver Filtering You can use receiver filters to define dependencies that affect the permitted recipients between BAPIs or between a BAPI and a message type. For more information on receiver filtering, please refer to the ALE Programming Guide under Determining Receivers for a BAPI. 2. Data Filtering Data filtering offers two filter services: interface reduction and parameter filtering: o Interface reduction allows field suppression by the BAPI interface, which means these fields will be ignored by the receiver. This can be used to prevent certain fields from being overwritten, for example. Parameter filtering allows you to control the scope of the dataset for transmission in the BAPI, by filtering out BAPI table parameters that fail to meet the defined conditions. If

hierarchical dependencies exist between two table parameters of the BAPI, then additional parameter hierarchies will have to be defined. For further information see the ALE Programming Guide under Defining Hierarchies between BAPI Parameters. For more information on data filtering, see the ALE Programming Guide under Filtering Data. To perform receiver determination and parameter filtering, you must create filter objects before you maintain the distribution model. Filter objects consist of a filter object type and an object value. Filter object types for BAPIs correspond to a parameter name during the BAPI call. They check whether a parameter is set to the required object value. The BAPI is only distributed when this condition is met. Interface reduction, in contrast, does not require any filter objects. However, it can only be used for certain types of BAPIs whose interface explicitly supports this type of filtering. Maintaining the Distribution Model The ALE distribution model is used to determine the target system for the remote call in both the synchronous and asynchronous cases. The ALE distribution model, which is a component of general IMG customizing, can be reached in the R/3 Implementation Guide through path Basis Application Link Enabling (ALE) Model and Implement Business Processes Maintain Distribution Model. To create the required filter object types, first select path Tools ALE ALE Development BAPI in the SAP menu. Then you can create filter object types for filtering data using the path Data filtering Maintain filter object type, or you can create filter object types for receiver filtering using the path Receiver determination Maintain filter object type. If you want to test the connection between two systems, you will have to make the following settings while maintaining the distribution model: 1. Determine the unique client ID and the logical system 2. Determine the technical communication partner 3. Generate the partner agreements in the sending system 4. Distribute the customer model to the receiving systems 5. Generate the partner agreement in the receiving systems

R/3 Release 99A will include an ALE customizing tool that will help customers to maintain the ALE distribution model. This support takes the form of templates that are available in the SAP menu under path Tools ALE ALE development Business processes Maintain template. A template contains a description of an ALE standard scenario based on message types/BAPIs and filter objects. Customers can use the templates, which are designed by the developer of the respective ALE standard scenario, to generate basic entries in the ALE distribution model based on their customer-specific data.

ALE Introduction and Administration ALE Integration Technology

Purpose
The integration technology Application Link Enabling (ALE) is an important middleware tool in SAP's Business Framework Architecture (BFA). BFA is a component-based architecture enabling software components from SAP and from other software vendors to communicate and be integrated with each other. ALE can integrate business processes between R/3 Systems and non-R/3 systems as well as between R/3 Systems. Data is exchanged between applications and remains consistent in all applications.

Company-wide applications such as accounting, human resource management and sales planning may be carried out in the companys headquarters, whereas production and materials management may be carried out in decentralized plants. Application systems are loosely coupled in an ALE integrated system. Data is exchanged asynchronously, whereby the data arrives in the receiver system, even if the receiver system cannot be connected to at the time the data is sent. ALE uses synchronous communication for reading data only. ALE provides administration, development and testing tools. To use the ALE tools choose Tools ALE. ALE business processes are part of the standard R/3 delivery. They are documented in the ALE Business Processes. For more information about the required system settings see the R/3 Implementation Guide. Tools AcceleratedSAP Customizing Project Management SAP Reference IMG Basis Application Link Enabling (ALE). For information on programming see the ALE Programming Guide. Library of

To make it easier to assign ALE functions to specific user types, the following user roles have been defined: ALE Administration SAP_BC_MID_ALE_ADMIN ALE Development SAP_BC_MID_ALE_DEVELOPER

Logistics - Master Data Distribution SAP_BC_MID_ALE_MD_LO Accounting - Master Data Distribution SAP_BC_MID_ALE_MD_FI Human Resources - Master Data Distribution SAP_BC_MID_ALE_MD_HR

Implementation Considerations
Decentralized business applications ensuring data consistency are used because: The increasing globalization 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.

Features
ALE supports the configuration and operation of distributed applications. ALE controls Messaging across loosely coupled R/3 Systems, ensuring that data is always consistent. Applications are integrated using a local database rather than a central one. There is no data retention. ALE guarantees the distribution and synchronization of master data, Customizing data and transaction data through asynchronous communication. Synchronous communication is used in ALE to read data only. 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.

ALE has functions for monitoring messages flows and handling communication problems.

Modeling Distribution
Purpose
To implement the distribution of business application processes and functions using ALE you need to construct a logical Distribution Model of the whole system. Within the framework of this configuration, customers can specify which applications are to run on which systems and which messages are to be exchanged between the applications.

Prerequisites

You should consider the following important questions when formulating a distribution concept: Where exactly are the distributed R/3 Systems to be installed? What applications are to run on what systems? What master data and transaction data are to be exchanged between the applications? What Customizing data must be known to the distributed systems?

Process Flow
You should model the logical system as though only one single R/3 instance is involved. Applications are then distributed across several physical systems in accordance with this model. Most of the organizational units, such as PLANT or SALES ORGANIZATION must be given unique names. Company codes and business areas are the only exceptions to this.

Setting Up the Communication

To set up the communication, a series of steps are required that you have to carry out in Customizing for ALE (Transaction SALE). More information about ALE communication can be found in the R/3 Implementation Guide (IMG) under Basis Components Distribution (ALE). Define the RFC destinations The remote function call is controlled in the parameters of the RFC destination. For further information see Maintaining Remote Destinations. You can also specify which RFC destinations are to be used for synchronous method calls. These calls may either be BAPIs or Dialog Methods. For further information see RFC Destinations for Synchronous Method Calls. In the ALE IMG choose: Sending and Receiving Systems Systems in Network Generate partner profiles The partner profiles are based on the distribution model. In the ALE IMG choose: Modeling and Implementing Business Processes Partner Profiles and Time of Processing Partner profiles and model settings are checked for consistency.

In addition to checking the consistency of the partner profiles and model settings you can also check the consistency of all the systems and the distribution of the Customizing data. In the ALE IMG choose: Modeling and Implementing Business Processes Partner Profiles and Time of Processing Check connections When the system is running, you can check whether the messages sent have been received in the receiver system and you can monitor the processing status of the messages. In the ALE IMG choose: System Monitoring IDoc Confirmation in Receiver System (ALE Audit)

Technology of ALE Business Processes

Definition
ALE business processes are application scenarios that use Application Link Enabling.

Use
The ALE business processes in the standard system cover important application areas in which business functions and processes are distributed. They are preconfigured and are easy to use once the appropriate settings have been made in Customizing for ALE and for the individual applications. ALE business processes are used for the following distribution tasks: Synchronizing Customizing Data Between Systems Master Data Distribution

ALE also supports R/2 Connections and Connections to Non-SAP Systems. Automatic tests in the CATT environment can check the quality of the ALE layer and ALE business processes. For further information see Automatic Tests. For more information about the processes see Library of ALE Business Processes.

Administration of ALE Functions

Purpose
Application Link Enabling provides a range of administration tools: Monitoring of IDoc processing and tRFC communication Transport of Customizing data from maintenance systems to receiving systems Optimization of ALE performance Serialization of messages

You can find the administration functions under ALE Administration. Information about optimizing the performance of ALE often refers to settings in R/3 Customizing. You can find ALE Customizing under Basis Distribution (ALE) In the sections below you will find general information, step-by-step procedures and information about the settings required in Customizing for ALE.

DATA EXCHANGE VIA IDOC WITH ALE OR EDI

IDoc or Intermediate Document is a standard SAP document exchange format. IDocs allow different application systems to be linked via a message-based interface. The IDoc interface consists of the definition of a data structure (where the data structure is the IDoc) and a processing logic for this data structure. There are three main aims behind the use of IDocs:

The structured exchange of business documents so that they can be processed automatically. The various degrees of structural complexity as displayed by different application systems can be reduced to a structure which is as simple as possible. Example: The structure of an SAP application document and the structure of the corresponding EDI message under the UN/EDIFACT standard. IDocs allow for extensive exception handling before the data is posted to the application.

The following techniques use the IDoc interface to exchange business data between different systems:

Electronic Data Interchange (EDI) was the first form of data transfer to use IDocs. In EDI application scenarios, the processes, by definition, involve two partners: The sender and the recipient of an EDI message. EDI is a bilateral, document-oriented form of data transfer. Application Link Enabling (ALE) enables integration of business processes that are developed across several SAP systems or non-SAP systems. Thus, ALE is oriented to connect different applications on different systems. System-wide ALE message flows are modeled in a so called 'distribution model'. A typical scenario is the system data administration, where material master records have to be distributed

from one central to several satellite systems. Nowadays, pure EDI scenarios are more and more executed on the basis of ALE technology, only that the system connection is 'just' bilateral. You find detailed information on ALE under the following links:

Literature Presentations Frequently Asked Questions Certifiable Interfaces Important Links

LITERATURE
IDoc Interface (ALE/EDI) (Online Help; SMP login necessary!) This link leads you to the online help for IDoc/ALE/EDI. Configuring Ports (Online Help; SMP login necessary!) Before data exchange with external systems can take place, the corresponding ports must be configured. You find information on the different ports (file interface, tRFC, XML etc), when following this link to the online help. Sample IDocs for Port Type XML (zip archive 571 KB) This archive contains a short summary (ReadMe.htm) of the XML interface and example scenarios. Links out of the summary point to IDoc type definitions as well as to example scenario data. The "classic" IDoc interface is compared with the XML/IDoc interface on the same business documents and data. Extract all files into a folder on your PC disk and start with the ReadMe.htm file. If you prefer reading German, choose LiesMich.htm for the same information. IDoc and International Standards (PDF 35KB) This list contains overviews of EANCOM/EDIFACT/ODETTE/VDA standards and their corresponding IDoc counterparts. Distribution of Master Data Objects You find information on master data IDocs that are included in the SAP system by going to transaction WE60 in the SAP system. Enter the IDoc name in the field Basic Type (for example DEMAS06 to see how an IDoc for a debitor looks like) and press the Enter button. Delta 4.6C in the IDoc Interface (PDF 85 KB) This document shows the changes to the IDoc for SAP Basis Release 4.6C in comparison to Release 4.6B. Delta 6.20 in the IDoc Interface (PDF 280 KB) This document summarizes the changes to ALE and IDoc for SAP Web AS 6.20 (SP 11) in comparison with SAP Basis Release 4.6C.

PRESENTATIONS

IDoc Notification by Workflow and Monitoring (PDF 296 KB) The IDoc interface offers two different approaches for tracking data load and data flow: Workflow for notifications and reports for monitoring. This presentation gives an overview of these two approaches. Extension of IDoc Types and their Processing (PDF 66 KB) If the requested IDoc type is available, but does not match in all the requirements, a customer extension" needs to be created. This presentation describes how to extend an IDoc and gives a detailed example. The IDoc Interface in SAP Basis Rel. 4.6 (PDF 798 KB) This presentation describes the IDoc Interface for SAP Basis Release 4.6 in detail and contains exercises. Delta of IDoc Interface Release SAP Web AS 6.20 vs. SAP Basis 4.6C (PDF 225 KB) This presentation shows in detail the changes to IDoc and IDoc Processing for SAP Web AS Release 6.20 in comparison with SAP Basis Release 4.6 C.

FREQUENTLY ASKED QUESTIONS

FAQs This link leads you to the most important questions and answers concerning ALE.

CERTIFIABLE INTERFACES
SAP provides a certification program that enables third-party vendors to integrate their software with SAP solutions. To support integration and to ensure quality and customer satisfaction, SAP offers an interface certification program administered through the Integration & Certification Center (ICC). In the EDI/ALE area, there are two certifiable interfaces available: CA-EDI With CA-EDI, SAP provides an open, common interface to EDI subsystems. The following data can be transferred using the EDI interface:

Outbound IDocs: IDocs are transferred from the SAP system to the EDI subsystem. Inbound IDocs: IDocs are transferred from the EDI subsystem to the SAP system. Status report: The EDI subsystem sends a status report to the SAP system on the progress of the processing of the outbound IDoc.

CA-ALE The ALE concept involves using external converters to connect non-SAP systems to an SAP system. External converters are generic format conversion programs. The following converter functions are covered by SAP CA-ALE certification:

The transfer of IDoc formats straight into their own repository so that these data descriptions can be used as source or target structures when assigning data fields.

Adoption and conversion of IDocs from SAP systems via the ALE interface - an RFC that can be called up using a normal transaction. Conversion of any data format into IDoc structures and import into an SAP system via RFC in the ALE interface.

IMPORTANT LINKS
Links related to EDI issues:

UN/EDIFACT DISA - Data Interchange Standards Association ANSI - American National Standards Institute

Links related to XML:

OASIS - Organization for the Advancement of Structured Information Standards W3C - World Wide Web Consortium ebXML

This article will help you understand the basics of ALE and IDocs via a simple do-it-yourself example. We will create a custom IDoc in one SAP system and then post some business data through it to another SAP system. Business data will be picked up from custom data dictionary tables. ALE Application Link Enabling is a mechanism by which SAP systems communicate with each other and with non-SAP EDI subsystems. Thus it helps integration of distributed systems. It supports fail-safe delivery which implies that sender system does not have to worry about message not reaching the source due to unavoidable situations. ALE can be used for migration and maintenance of master data as well as for exchanging transactional data. The messages that are exchanged are in the form of IDocs or Intermediate Documents. IDocs act like a container or envelope for the application data. An IDOC is created as a result of execution of an Outbound ALE. In an Inbound ALE an IDOC serves as an input to create application document. In the SAP system IDocs are stored in the database tables. They can be used for SAP to SAP and SAP to non-SAP process communication as long as the participating processes can understand the syntax and semantics of the data. Complete documentation on IDOC is obtained by using transaction WE60. Every IDoc has exactly one control record along with a number of data records and status records. Control record has the details of sender/receiver and other control information. Data records contain the actual business data to be exchanged while the status records are attached to IDoc throughout the process as the IDoc moves from one step to other. Now, let us understand the ALE Configuration by means of an example scenario below:

The Scenario Data from custom tables (created in customer namespace) is to be formatted into an IDoc and sent from one SAP R/3 system to another using ALE service. We need to have two instances of SAP R/3 systems or we can simulate this on two clients of the same SAP R/3 system. Create three tables as shown below.

Creating Custom IDoc type and Message type All the objects created should be present on both source as well as target system(s). 1. Create segments Transaction WE31

Create a segment ZRZSEG1 Add all fields of table ZCUSTOMERS to it Save the segment and go back Release it using the menu path Edit -> Set Release Similarly create two more segments given below Seg. ZRZSEG2 to hold all fields of table ZSOHEADERS Seg. ZRZSEG3 to hold all fields of table ZSOITEMS

2. Create Basic IDoc type Transaction WE30

Create a Basic type ZRZORDER Add the created segments in the hierarchy shown Maintain attributes for each of the segments Save the object and go back Release the object using the menu path Edit -> Set Release

3. Create/Assign Message type Transactions WE81/WE82

Go to WE81 Create a new Message type ZRZSO_MT Save the object Go to WE82 and create new entry Assign the message type ZRZSO_MT to the basic type ZRZORDER Also specify the Release Version Save the object

Thus we have defined the IDoc structure which will hold the data to be transferred. In the next part of the article we will understand the outbound settings, i.e. the settings to be done in the source system In the previous part we created an IDoc structure which can carry our data from source system to target system(s). In this part we will understand how to setup the source system to be able to generate and send an outbound IDoc. Outbound Settings Define Logical Systems and Assign Client to Logical System Transaction SALE

Go to Define Logical System (See the

figure)
Define a new logical system to identify the local system and save it Now, go to Assign Client to Logical System (See the figure)

Add a new entry Specify the client, previously created logical system and other attributes Save the entry Define a new logical system to identify the partner system and save it

Maintain RFC Destinations Transaction SM59

Create a new RFC destination for R/3 type connection Specify the target host on Technical settings tab Provide the Logon credentials on the Logon/Security tab Save the settings To verify the settings, Click on Test connection or Remote logon

Define Ports Transaction WE21

We need to define a tRFC port for the partner system Click on Transactional RFC node Create a new port Provide a description Specify the name of the target RFC destination Save the object

Maintain Distribution Model Transaction BD64

Click on Change Create a new model view Provide a Short text and Technical name to the model view Add message type Specify sender and receiver systems Also, specify the message type that we created previously Save the Distribution model

Generate/Create Partner Profile Transactions BD82/WE20

To generate Partner profiles automatically you may use BD82 or go to BD64 and use the menu path Environment -> Generate partner profiles o Otherwise, you may use transaction WE20 to create a partner profile On selection screen, specify the model view, target system and execute The result log will be displayed on the next screen To verify the partner profile go to WE20 Check the partner profile for the target system

Distribute Model View Transaction BD64

Select the Model View Go to menu path Edit -> Model View -> Distribute Result log will be displayed on the next screen

Outbound IDoc Generation Program Create an executable program ZRZ_ORDER_IDOC in SE38. Below, I have described the program logic:

Fetch the data from the DDic tables ZCUSTOMERS, ZSOHEADERS and ZSOITEMS as per the selection criteria Fill the control record structure of type EDIDC o Specify message type, Basic IDoc type, tRFC Port, Partner number and Partner type of the receiver Fill the data records o Define structures like the IDoc segments o Fill the structures with fetched data

Pass the segment name and the above structure to the appropriate fields of EDIDD type structure o Append the EDIDD structure to the EDIDD type internal table Now, call the function module MASTER_IDOC_DISTRIBUTE and pass the IDoc control record structure and data record table Commit work if return code is zero Function module returns a table of type EDIDC to provide the details about generated IDoc Display appropriate log

You can download sample code for the above program here. Thus we have completed sender side configuration required for ALE. In the next part we will see how to configure the receiving system to be able to receive and post the inbound IDoc. In the previous parts we learned how to create a custom IDoc and set up the source system to send an outbound IDoc. In this part we will learn how to configure the receiving SAP R/3 system to be able to receive and post the inbound IDoc. Inbound IDoc Posting Function Module In the receiving system, create a function module Z_IDOC_INPUT_ZRZSO_MT using SE37. Below, I have described the logic for the same. Add Include MBDCONWF. This include contains predefined ALE constants. Loop at EDIDC table

Check if the message type is ZRZORDER. Otherwise raise WRONG_FUNCTION_CALLED exception Loop at EDIDD table o Append data from the segments to appropriate internal tables o For example: append data from ZRZSEG1 segment to the internal table of type ZCUSTOMERS Update the DDic tables from internal tables Depending on the result of the update, fill the IDoc status record (type BDIDOCSTAT) and append it to the corresponding table. o Status 53 => Success o Status 51 => Error

You can download the sample ABAP code for the above function module here. Inbound Settings

Define Logical Systems Transaction SALE (Please refer to Outbound Settings discussed in previous part) Assign Client to Logical System Transaction SALE (Please refer to Outbound Settings discussed in previous part) Maintain RFC Destinations Transaction SM59 (Please refer to Outbound Settings discussed in previous part)

Define Ports Transaction WE21 (Please refer to Outbound Settings discussed in previous part) Generate/Create Partner Profile Transactions BD82/WE20 (Please refer to Outbound Settings discussed in previous part) Assign Function Module to Logical message Transaction WE57 o Create a new entry o Specify name of the Function Module as Z_IDOC_INPUT_ZRZSO_MT o Also, specify Type as F, Basic IDoc type as ZRZORDER, Message type as ZRZSO_MT and Direction as 2 (Inbound) o Save the entry Define Input method for Inbound Function Module Transaction BD51 o Create a new entry o Provide Function Module name as Z_IDOC_INPUT_ZRZSO_MT o Specify the Input method as 2 o Save the entry Create a Process Code Transaction WE42 o Create a new Process Code ZPCRZ o Select Processing with ALE Service o Choose Processing type as Processing by function module o Save the entry o On the next screen, select your function module from the list o Save the changes o Now you will be taken to the next screen o Double-click on Logical message o In the Assignment to logical message, specify the message type ZRZSO_MT o Save the changes

Send and receive data On the sender system, execute the IDoc Generation Program. Check the status of IDoc using transaction WE02.

Check the status of the IDoc in the receiver system using transaction WE02. You can also check the contents of DDic tables to make sure that the records have been created in the receiver system.

Thus to summarize we have learned how to:

Create a custom IDoc Write an Outbound IDoc Generation Program Write Inbound Function Module to post Inbound IDoc Configure and test ALE scenario to transmit data between systems distributed across the network