BAPI Introduction

General Introduction to BAPIs
Purpose
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.

The Business Application Programming Interfaces allow object-oriented access to the SAP system through methods for the business object types. Together with the business object types, BAPIs define and document the interface standard at the business level.

Integration
BAPIs can be called within the R/3 System from external application systems and other programs. BAPIs are the communication standard for business applications. BAPI interface technology forms the basis for the following developments:
• Connecting:
• New R/3 components, for example, Advanced Planner and Optimizer (APO) and Business Information Warehouse (BW).
• Non-SAP software
• Legacy systems
• Isolating components within the R/3 System in the context of Business Framework
• Distributed R/3 scenarios with asynchronous connections using Application Link Enabling (ALE)
• Connecting R/3 Systems to the Internet using Internet Application Components (IACs)
• PC programs as frontends to the R/3 System, for example, Visual Basic (Microsoft) or Visual Age for Java (IBM).
• Workflow applications that extend beyond system boundaries
• Customers' and partners' own developments

The graphic below shows how BAPI interfaces enable different types of applications to be linked together. BAPIs - Interfaces to the R/3 System

Objectives for Implementing BAPIs

When implementing BAPIs, you should pursue the goal of avoiding the disadvantages of the "postcard effect" associated with conventional interfaces: No separation between contents and transport. In the case of a postcard, the text is written on a card that also serves as the information medium. If the information medium changes, then the receiver has to read the text in a different way. As a result, changes to the interface affect the type of access. BAPIs, in contrast, clearly separate the business contents from the underlying communication technology. This procedure can be compared to a letter in an envelope: It is easy to put a letter in a new envelope, just like it is easy to apply new and/or different communication technologies like COM/DCOM, the CORBA standard, or new Internet standards. The envelope itself is irrelevant to understanding the contents of the letter. In this example, the BAPIs correspond to the letter, meaning they are independent of the programming language and communication mechanisms used.

Using BAPIs results in the following benefits:
• BAPIs represent well-defined, internally consistent units that always represent business facts and leave a consistent database state behind.
• The business contents can be standardized, since BAPIs not only allow the integration of the SAP system and other software components at a technical level, but also at the business level.
• BAPIs have become a communication standard between business systems. Access is possible through object-oriented interface technologies (such as COM/DCOM from Microsoft). The SAP business objects conform to the guidelines of the OAG (Object Application Group), and meet the CORBA standard from the OMG (Object Management Group).
• Stability and compatibility
Once SAP has released a BAPI, its interface definitions and parameters will remain stable in the long term, which means application programs will not be affected by changes to the underlying SAP software or data. If upward-compatible enhancements are made to the BAPIs, the stability of the existing applications is not affected.
• Openness
BAPIs can be accessed from any widespread development platform.

Universal Usability of BAPIs

To allow their use in any scenario, BAPIs must support all forms of communication and be available to all types of participants:
• Support of synchronous and asynchronous communication
BAPIs can be used for both the synchronous and for the asynchronous call to an SAP component. If the call is synchronous, the BAPI is called as a remote function call (RFC).
ALE inbound processing is used to enable asynchronous communication with BAPIs. When the BAPI is called in the sender system, an IDoc is generated and dispatched to the receiver system. When the IDoc reaches the receiver, the parameters of the corresponding BAPI are automatically filled with the IDoc data, and the BAPI is called synchronously.
• Support of machine-to-machine and human-to-machine communication
BAPIs can be used both to integrate application systems and to link up alternative frontends.

• The integration of application systems is characterized by machine-to-machine communication. It is implemented by exchanging large volumes of data and requires high system performance. As a result, the BAPIs used for this type of scenario have a lower level of detail.
• The integration of alternative frontends allows human-to-machine communication. BAPIs used for this purpose have a higher level of detail. They must be designed to allow more flexible communication that is free of errors.

• Communication support for components that are narrowly linked and coupled through the Internet

In addition to the use of BAPIs under communication technologies like CORBA and COM/DCOM, BAPIs can also be accessed via the Internet with the SAP Business Connector. The Business Connector generates an XML document from a BAPI call, or transforms an inbound XML document into a BAPI call. This makes it possible to dispatch BAPI calls as XML documents, enabling communication of components that are linked via the Internet.

All BAPIs are published centrally in the XML-based Interface Repository (IFR) and are stored there as XML schema, which means that they are immediately ready for use with the Business Connector.