Introduction to ale, IDOC, and bapi

Analysis of mainstream system EAI interface technology: SAP

From -- http://www.sapsky.com/html/2007-10/819.htm

 

As one of the most advanced application systems in the ERP market, sap r/3 has always been ahead of other ERP vendors in providing API application programming interfaces and interface tools. Ale/idocs is an interface mechanism provided by SAP for sap r/3 r4.6c. It is currently the most widely used. In Versions later than r4.0, an advanced bapi is added. As one of the series, this article introduces ale/idocs, bapi, and other available integration methods.

 

1. What is ale/idocs?

 

Ale is short for application link and enabling. It is an integrated middleware specially designed by SAP for SAP and sap. Idocs is the abbreviation of intermediate document. It is a dedicated data/Message format provided by SAP for system integration. At the beginning of SAP 3.0, ALE was part of the entire SAP application system, providing a reliable and secure communication mechanism for distributed data exchange. Designed as a messaging service between two sap processes, Ale enables effective exchange of enterprise data between SAP and SAP Business Processes, it provides system integration services between two independent SAP systems. However, with the development of applications, the ale/idocs interface mechanism has become a standard integration method with other non-SAP systems.

 

The design structure of ale can be divided into three layers: application layer, data/message distribution layer and communication layer. The communication layer is the basis of the SAP integration mechanism. It uses remote functions to call RFC (remote function call) to call the function modules of the SAP system.

 

 

 

The data/message distribution layer provides three key services:

 

The data receiver is determined by the data allocation model.

 

Filter and convert messages.

 

Data/message compression to improve transmission efficiency.

 

The Application Layer directly interfaces with the SAP system to generate or receive the message text idocs containing routing information from other systems, including the name of the message receiver, the type of message to be sent, and the rules for processing the message.

 

The ale mechanism replaces the Batch Data Communication (BDC) method provided by the original sap. As the name suggests, BDC provides simple data batch processing services between systems, and cannot be used as a middleware technology, it does not provide error correction, system management, and other security measures required for seamless integration between systems. In general, the application of SAP's Ale mechanism to integrate sap with SAP or non-SAP systems has the following benefits:

 

The ale technology is not affected by the sap version upgrade. It provides version backward compatibility. Ale is defined at the SAP application layer and is relatively independent from the sap logic layer. The entire ale middleware is independent of the sending and receiving systems.

 

The ale message design logic ensures "one and only one" message transmission. Ale uses the "Storage-Send" technology to ensure that the message can reach its destination even if the system fails or the receiver is not prepared to receive the message. In this way, the receiver will not receive repeated messages.

 

Ale also provides the idocs management function. Mainly include text reduction, text version control, and text data filtering. The three control mechanisms enable sap developers to dynamically process the idocs text at runtime as needed.

 

Ale provides a system management function that allows developers to start, reset, recover, and perform other system operations on the ALE system.

 

IDOC can transmit almost any SAP application data. It is a "peripheral" Definition Format and is not directly related to the SAP application data definition. Idocs has been widely used in the early SAP-EDI of data exchange, so its design is somewhat similar to the EDI standard, namely the EDIFACT standard.

 

Idocs is character-based and therefore readable. It has three types of records:

 

Control record-containing text information, such as the IDOC type, sending/receiving information, and text identification.

 

Data Records-including management and actual data.

 

Status record-used to track the status of each point transmitted by text, such as status code, system time, and error identification.

 

 

 

 

2. Ale/idocs message sending and receiving process

 

The following describes the actual transmission of messages in the system integration process of ale/idocs.

 

Let's first look at the sending process.

 

A sending process consists of four steps: event triggering, text generation, data packaging, and transfer to the transmission media:

 

Application System event triggering

 

The state change of the system target (objects), the user's own activity, or other database-specific changes, can start the trigger program of the data table to initialize the data transmission, such as data preparation.

 

Generate master IDOC text (master)

 

Generate a master IDOC file in standard format, including all data that can be transferred (regardless of recipient)

 

Generate communication IDOC

 

Generate text only related to a specific receiver from the primary IDOC. The communication text is a subset of the primary text)

 

IDOC send

 

Use asynchronous communication to pass certain versions of IDOC to the receiver.

 

 

 

Next, let's look at the receiving process.

 

The receiving process starts when the SAP system receives the IDOC text from outside. The advantage of the receiving process is that the receiver can be either an SAP system or a third-party system, which is also the basis for effective integration between SAP and a third party. The receiving process consists of the following three steps:

 

Storage IDOC-stores text in the database and performs syntax Validation

 

IDOC reading by the mail handler-a specially designed IDOC handler reads IDOC and generates system messages required by SAP or other systems. Multiple programs can run simultaneously.

 

Generate System text-the handler further generates System text for the system to use and stores the result information in the idoc d status record.

 

 

 

3. bapi Introduction

 

Bapi is short for business application programming interface. It is an interface application interface provided by SAP for Business Object Technology Versions later than 3.0. SAP versions 3.0 and later use the object-oriented technology. The logic defines all functional objectives of the sap r/3 system and converts all objectives (objects) and bapis are stored in the enterprise target library Bor (Business Objects repository ). sap r/3 the object type of an enterprise target is equivalent to the class concept in the target design language. Its definition structure consists of the following parts:

 

Basic data-common attributes of all target classes, such as the target ID and default method ).

 

Interface interface: method, event, and attributes ).

 

Key (key fields) -- used for target search in Bor

 

Methods-perform the required operations on the target.

 

Attibutes: Describes the Target Feature.

 

Event-triggered to change the target status.

 

With bapi, developers can access Bor in real time, so as to effectively integrate application systems (SAP-SAP) on the data/logic layer.

 

4. Application of SAP-DCOM Interface

 

SAP provided SAP-DCOM interfaces in 1998 for the first time to meet the requirements of various desktop application development. Using the DCOM connection port, developers can use VB, C ++ to access SAP data in the DCOM target mode. For Web applications, you can use VBScript and JavaScript to access pages in DHTML mode or ASP to access data.

 

In addition, DCOM can also be used to indirectly access sap's enterprise target database Bor. The bapi mentioned above is dedicated to the SAP system and is not as widely used as DCOM in practice. The DCOM port consists of two technical modules: one is the management module and the other is the DCOM Proxy component generated by SAP Bo. The generated DCOM component is stored in C ++. The proxy component has the following attributes:

 

Client-R/3 customer system to be accessed

 

Userid-R/3 user

 

Password-User Password

 

Language-System Language

 

Destination-predefined target name

 

In addition, each component has the following methods:

 

Putseesioninfo ()-sets the target parameter for one system call.

 

Advicerfcguisink ()-used when sapgui or dubugging is required.

 

Commitwork ()-used for data updates without implicit commit.

 

Initkeys ()-DCOM target key initialization

 

Dimas ()-returns the Microsoft ADO (Advanced Data Object) record set (supports cursor control ).

 

Other methods inherited from the R/3 BO definition.

 

In general, as a relatively flexible ERP system, sap r/3 can integrate data/processes between SAP systems and other systems using the above integration technologies. Of course, the high degree of customization of an application system makes System Integration difficult. With the increase of system functions, it is necessary to use a variety of integrated technologies. For sap r/3 users, correct selection of applicable integration technologies is the key to successful system integration.