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