Explaining the Integration Technology Based on BAPIs and IDocs, Basics

Objective

After completing this lesson, you will be able to Explain the ALE, RFC/BAPI and IDoc concepts.

Application Link Enabling (ALE)

Application Link Enabling in the SAP environment means the possibility to exchange data within a company between different SAP and non SAP systems.

Application Link Enabling (ALE) is an integration service, which enables business processes developed across several SAP systems or non SAP systems to be integrated.

The following graphic provides an overview of the ALE integration scenarios. For each integration scenario, there is a multitude of possible ALE business processes.

SAP supports a range of ALE business processes.

These predefined ALE business processes have been developed for Application Link Enabling and they include important application cases for distributing business functions and processes. They are supplied with the standard system

If you exchange data with other companies, this is referred to as EDI (Electronic Data Interchange). EDI communication is message-based and therefore always asynchronous.

Business Application Programming Interfaces (BAPI)

BAPIs (Business Application Programming Interfaces) are the standard SAP interfaces. They play an important role in the technical integration and in the exchange of business data between SAP components, and between SAP and non SAP components. BAPIs enable you to integrate these components and are therefore an important part of developing integration scenarios where multiple components are connected to each other, either on a local network or on the Internet.

BAPIs allow integration at the business level, not the technical level. This provides for greater stability of the linkage and independence from the underlying communication technology

Facts about Integration:

  • Connecting SAP Systems to the Internet using the SAP Business Connector or Internet Application Components (IACs).
  • Creating true component software, by enabling standardized communication between SAP components. The aim is to encapsulate the functions of the SAP system in independent business components that are integrated through a common interface (the BAPIs).
  • Connections to third-party software and legacy systems.
  • Implementing distributed scenarios with asynchronous connections using Application Link Enabling (ALE).
  • Using PC programs as frontends to SAP Systems. These can be developed with Visual Basic (Microsoft), for example, or with Visual Age for Java (IBM).
  • Workflow applications that extend beyond system boundaries.
  • Workflow applications that communicate with one another using the Internet.
  • Customers' and partners' own developments.

The diagram above shows how BAPI interfaces enable different types of applications to be linked with the SAP system.

In the SAP system, BAPIs are stored as RFC-capable function modules in the ABAP Workbench Function Builder. BAPIs have standard business interfaces that enable external applications (with the help of SAP business objects) to access SAP processes, functions and data.

Client programs that use BAPIs to access SAP business objects can be part of the same SAP system, part of an external system (for example, a .Net application), part of an HTTP Gateway, or part of another SAP system.

If you want to use a BAPI to trigger a business process in another system, you usually use the synchronous communication method sRFC, because in most cases, you want the data to be returned to the sending system.

For asynchronous communication using BAPIs, ALE is used, with additional IDoc interfaces being generated for the BAPIs.

Remote Function Call (RFC)

Communication between applications of different systems in the SAP environment includes connections between SAP systems as well as between SAP systems and non SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. RFC calls a function to be executed in a remote system.

There is now a whole series of different RFC variants, each of which has different properties and is used for a specific purpose.

RFC Variants are:

  • Synchronous RFC (sRFC)

  • Asynchronous RFC (aRFC)

  • Transactional RFC (tRFC)

  • Queued RFC (qRFC)

  • Background RFC (bgRFC)

Synchronous RFC (sRFC)

The first version of RFC is synchronous RFC (sRFC). This type of RFC executes the function call based on synchronous communication, meaning that the systems involved must both be available at the time the call is made.

Asynchronous RFC (aRFC)

Despite its name, aRFC is not really an asynchronous type of communication, as it does not meet the conditions for this. With sRFC, for example, the called system must be available during the call.

The main characteristics of aRFC are as follows:

  • Function control returns to the calling program directly after the call.

  • The parameters of asynchronous RFCs are not logged to the database, but sent directly to the server.

  • Asynchronous RFCs allow the user to carry on an interactive dialog with the remote system.

  • When the caller starts an aRFC, the called server must be available to accept the request.

  • The calling program can receive results from the asynchronous RFC.

Using aRFC is always a good idea when real-time communication is established with a remote system, where processing in the calling program should not be interrupted until the results of the called function module have been obtained (the term asynchronous is used in this sense here).

Transactional RFC (sRFC)

Transactional RFC (tRFC, previously known as asynchronous RFC) is a genuine asynchronous communication method that - unlike aRFC - executes the called function module just once in the RFC server. The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID).

If a call is sent, and the receiving system is down, the call remains in the local queue until a later time. The calling dialog program can proceed without waiting to see whether or not the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch.

tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls are:

  • Executed in the order in which they are called.

  • Executed in the same program context in the target system.

  • Are executed in a single transaction: they are either committed or rolled back as a unit.

Implementation of tRFC is recommended if you want to maintain the transactional sequence of the calls.

Disadvantages of tRFC

  • tRFC processes all LUWs independently of one another. Due to the amount of activated tRFC processes, this procedure can reduce performance significantly in both the send and the target systems.

  • In addition, the sequence of LUWs defined in the application cannot be kept. It is therefore impossible to guarantee that the transactions will be executed in the sequence dictated by the application. The only thing that can be guaranteed is that all LUWs are transferred sooner or later.

Queued RFC (qRFC)

To guarantee that multiple LUWs are processed in the order specified by the application, tRFC can be serialized using queues (inbound and outbound queues). This type of RFC is called queued RFC (qRFC).

qRFC is therefore an extension of tRFC. It transfers an LUW (transaction) only if it has no predecessors (based on the sequence defined in different application programs) in the participating queues.

Implementation of qRFC is recommended if you want to guarantee that several transactions are processed in a predefined order.

Background RFC (bgRFC)

bgRFC is the successor to tRFC and qRFC, with significant improvements in terms of performance and functionality.

The bgRFC allows applications to record data that is received later by a called application. When the data is received, you must ensure that the data was transferred to the receiver either once only in any order (transactional) or once only in the order of creation (queued).

With the bgRFC, therefore, the asynchronicities between the caller and the called application can result in the following advantages:

Within an SAP system (same system ID, same client)
Decoupling and (potentially) parallelization are possible. The load is spread across the available application servers for this system. This bgRFC scenario is known as an inbound procedure.
Between two remote SAP Systems
Decoupling and therefore the physical segmentation of an application or a business scenario are possible. As a result of the asynchronicities, differences in the key features of the application servers for the called and calling applications can be balanced out. The recording is done in the calling system. This scenario is an outbound procedure.
Both procedures can be combined in an out-in procedure
Here you can take advantage of all the optimization options. However, if you chose to do this, the data is recorded twice, once for the caller (outbound processing) and once for the called application (special type of the inbound procedure). This results in additional load for the database, and for the application server as well due to the scheduler.

The bgRFC organizes the different calls using queues. A call that is placed in several queues at the same time creates a dependency between these queues. This leads to a synchronization point, which is similar to a lock.

The dependent queues can be processed until the entry for processing is at the head of the queue that defines the dependency. This entry can only then be processed if it is at the head of all the queues.

Intermediate Document (IDoc)

Intermediate Document (IDoc) is the standard SAP format for Electronic Data Interchange (EDI) between systems. Different message types (such as delivery confirmations or purchase orders) normally represent different specific formats, the IDoc types. However, multiple message types with related content can be assigned to one IDoc type: For example, the IDoc type ORDERS01 transfers the "logical" message types ORDERS (purchase order) and ORDRSP (order confirmation).

The IDoc interface exchanges business data with an external system.

The IDoc interface consists of the definition of a data structure, along with processing logic for this data structure.

The data structure is the IDoc. The IDoc is the exchange format common to all the communicating systems. You can specify exception handling in the SAP Business Workflow, with IDocs, without the data already having to exist as SAP application documents.

You need the IDoc interface in the following scenarios:

  • Electronic Data Exchange (EDI).
  • Connect other business application systems (such as PC applications, external workflow tools) by IDoc.

  • Application Link Enabling (ALE).

Structure of an IDoc

All IDocs are structured according to specific rules: This is the general structure (the record types) of an IDoc. Special rules affect the different IDoc types.

IDocs contain administration information for technical processing, as well as the actual application data, which is stored in segments. A segment comprises segment fields as the smallest unit of the IDoc - comparable with the data elements from the EDIFACT standard.

In the SAP System, the processing status ("what has happened to the IDoc before now?") is stored in the IDoc status information. The status information also contains details about errors and indicates the data in which the error occurred. This status information is not forwarded as part of the IDoc but separately using status processing.

The figure below shows the basic structure of an IDoc and which parts are transferred to and from the external system. The parent-child segment hierarchy is shown here as a tree structure. A total of 3 hierarchy levels can be seen.

The IDoc Interface can check for each IDoc whether the segments contained are compatible with the definition of its type. This syntax check is activated or deactivated in the partner profiles (separately for inbound and outbound processing).

IDoc Structure: Technical Implementation

IDocs are stored in the SAP system in three database tables: One table contains the control record, one contains the data records and one contains the status records:

  • The control record is identical for all IDocs and contains the administration information, for example, sender, recipient and message. Note that the control record also contains the last processing status (STATUS field).
  • The data records contain the segments and administration information for the segments (for example, a parent segment to which it is attached).
  • The status records contain all of the previous processing statuses, as well as the corresponding administration information. This information is not sent between systems as part of the IDoc but rather as a separate data packet.

Viewed externally in the IDoc interface (that is to say, as they are sent to the subsystem), the IDocs are located in three structures which correspond to the three database tables: The control records, data records and status records are also used there. A description of the individual fields can be accessed using the documentation tools in the system.

The figure below shows the basic structure of the IDocs in the SAP System (IDoc Interface viewed externally, that is, the "external structures") with some sample fields.

The figure illustrates the structure of an IDoc.

Connect SAP NWDS to Your Process Orchestration System

Log in to track your progress & complete quizzes