Understanding the APIs

Application integration using exposed APIs and interfaces may sound simple, but the process is actually relatively complex. To use APIs effectively for integration, it is essential that EAI architects, developers, and administrators understand the application well enough to determine the appropriate interfaces to be used. The interface methods and parameters must be well understood so that the appropriate values are passed on input and retrieved on output.

SAP R/3 provides support for a variety of well-defined interfaces that can be used for application integration. The interfaces exposed by SAP R/3 are complex and lack consistency in architecture and calling sequence. In many cases, several interfaces are exposed that provide very similar capabilities, making it more difficult to choose the approach to use in solving a business problem.

For use in EAI solutions, SAP reflects some problems common with many packaged and custom applications. SAP also has some issues unique to the product. Early versions of the SAP suite of applications were constructed as a monolithic stovepipe application lacking options for communication with external applications. Later versions of SAP (the R/3 release) adopted the classic client-server design using three layers:

Presentation (user interface provided by SAPgui on client systems)
Application (business logic layer provided by SAP runtime and SAP modules)
Data (database layer provided by external RDBMS).

Newer SAP releases exposed interfaces for external communication targeted originally for exchanging information between SAP systems. Over time, these interfaces have been extended and enhanced for communication with external applications aside from other SAP systems.

SAP includes its own fourth-generation language (4GL), Advanced Business Application Programming (ABAP/4) language for internal development. All of the SAP application modules are written in ABAP and the SAP runtime consists of a runtime and interpreter for these ABAP applications. SAP R/3 also includes a collection of development tools (the ABAP Workbench) for developing applications or exposing custom external interfaces using the ABAP/4 language.

Some options available for accessing SAP R/3 from external applications include the following:

Common Programming Interface for Communications (CPI-C)
Remote Function Call (RFC)
Business Application Programming Interface (BAPI)
Intermediate Document (IDoc)

Traditionally, SAP used CPI-C for internal communications between function modules. CPI-C is one of the older programming APIs developed by IBM as part of its System Network Architecture (SNA). Industry standards were adopted for CPI-C interfaces as part of work done by the X/Open group. CPI-C applications are supported by Microsoft technology using Microsoft Host Integration Server 2000 and Visual C/C++. Although SAP still supports communication using CPI-C sessions, this method of external communication has been supplanted by other methods.

Remote Function Call interfaces were originally added to support communication between SAP systems. RFCs provide a synchronous remote procedure call (RPC) mechanism for external communication with other SAP systems and external applications. SAP exposes a number of external interfaces as remote function calls. SAP makes available an RFC SDK that can be used to call SAP Remote Function Calls from Visual C++, Visual Basic and Visual Basic for Applications (VBA), Java, Active Server Pages, VBScript, and JavaScript.

Business Application Programming Interfaces were added later to support object-oriented access to SAP business objects. BAPIs supply methods that encapsulate SAP business processes (business logic) and data, providing access to SAP business objects. BAPIs offer a layer of abstraction over the simpler RFC mechanism upon which they depend. SAP stores the BAPI objects including BAPI metadata in a Business Object Repository on the RDBMS system (data tier). Recent versions of SAP R/3 define almost 1,800 BAPI function methods for the entire SAP R/3 suite and include these BAPIs in the Business Object Repository on the SAP system. SAP supplies tools to access BAPI methods using Visual C++, Visual Basic and Visual Basic for Applications (VBA), Java, Active Server Pages, VBScript, and JavaScript. BAPIs have become a popular technique for integrating SAP with other applications.

RFCs and BAPIs are supported by development tools provided with the SAP R/3 system as part of the RFC SDK. The SAP R/3 DCOM Connector supplied as part of the RFC SDK includes tools to create proxy COM components exposing BAPIs and RFCs for use with external applications. The Object Builder tool included with the R/3 DCOM Connector allows the user to browse the Business Object Repository and select BAPI methods or RFC calls to add to a COM component. Once the BAPI methods are selected, the Object Builder can generate the source code for the COM components and build the COM proxy using Visual C++. The Object Builder also generates the interface definition language (IDL), include, and typelib (TLB) files to use the generated COM components with Visual Studio for developing external applications.

Conceptually, a SAP Intermediate Document (IDoc) is similar to the Electronic Data Interchange (EDI) standard. An Intermediate Document is a data container that is used to interchange information between any two processes that can understand the syntax and semantics of the data. It is the standard format adopted by SAP format for electronic data interchange between systems.

SAP includes almost 700 IDoc types in its repository. Each IDoc type represents a specific SAP format that is to be used to transfer the data for a business transaction. An IDoc type can transfer several message types, the "logical messages" that correspond to different business processes. An IDoc type is described using the following components:

A control record that includes the source, destination, the IDoc type, and other control information (identical format for all IDocs types)
One or more data records consisting of a fixed administration part and a data part or segment (the number and format of the segments can be different for each IDoc type)
Status records which describe the processing stages that an IDoc can pass through (identical format for each IDoc type).

Several external RFC methods can be called that will retrieve an IDoc from a SAP system or send an IDoc to a SAP System. An IDoc is essentially passed as a large blob of data that must be parsed by the external application.

The IDoc types defined by SAP support a number of SAP business transactions, but IDocs provide access to only a subset of the SAP R/3 suite. RFCs provide a set of low-level methods for accessing SAP information. BAPIs provide an object-oriented abstraction to SAP business objects using RFCs under the covers. Currently, BAPIs provide the most extensive access to SAP for application developers looking to integrate with SAP R/3.

Previous Next