Explaining the Integration Technology Based on BAPIs and IDocs, Basics

• 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.

• Synchronous RFC (sRFC)

• Asynchronous RFC (aRFC)

• Transactional RFC (tRFC)

• Queued RFC (qRFC)

• Background RFC (bgRFC)

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.

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.

• 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.

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.

• 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.

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.

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).

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.

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.

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.