Sei sulla pagina 1di 9

General Introduction to BAPIs (CA-BFA)

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.

Integration
BAPIs can be used for the following types of integration: Connecting SAP Systems to the Internet using the SAP Business Connector or Internet Application Components (IACs)

The standard SAP interfaces and all BAPIs are published centrally in the XML-based Interface Repository (IFR). They are stored as XML schema, which means that they are directly available for use in integration scenarios where multiple components communicate with one another using the Internet. You can access the Interface Repository in the Internet using the following address: http://ifr.sap.com. 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 below shows how BAPI interfaces enable different types of applications to be linked with the SAP system.

Object-oriented technologies have become standard for communication between different software products. For this reason SAP has introduced business object types that structure the data and processes according to business criteria. Business object types are used to break the SAP system down into smaller, disjunctive units, improving its structure and reducing its complexity. BAPIs are defined as methods for the business object types. As a result, both the object-oriented structures in SAP Systems and the opportunity for object-oriented access are offered. These objectoriented interfaces allow other components to directly access the application layer of an SAP system without having to know the specific implementation details. The introduction of business object types and their BAPIs enable object orientation to be used in central information processing in companies. For example, you can reuse existing functions and data, achieve trouble-free technical interoperability, and implement non-SAP components. The resulting architecture is illustrated in the graphic below. The main parts are:

Business components SAP business components provide autonomous business functions and consist of business objects. For example, the business object types Employee and Applicant are assigned to business component Human Resources. Business processes are either implemented within a business component or across several components (distributed business processes). Business object types The object-oriented structure of the SAP system is based on business object types. A single business object type represents one business entity. It encompasses the functions and the data of this entity. BAPIs 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. Application Link Enabling (ALE) The ALE integration service enables the technical integration of business processes that are carried out in different SAP and non-SAP systems. It involves distributing business object types across the systems using the ALE distribution model. Integration scenarios The design of all relevant situations in the Business Framework is based on concrete scenarios. Integration scenarios describe how components, business object types, and BAPIs interact, and integrate the systems by synchronizing business

processes at a semantic level.

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). For details about how to use the BAPI with the RFC, see the BAPI User Guide in the SAP Library under CA-BFA.

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. For details on the asynchronous use of BAPIs, please refer to Using ALE Services. 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. o 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. BAPI Development.

Developing BAPIs that meet your specific requirements is discussed in

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. For more information, see the documentation about the Interface Repository: http://ifr.sap.com.

Business Object Types


Definition
A business object type is the representation of a business entity, like an employee or a sales order, in an SAP System. It encompasses both the functions (in the form of methods) and the data (in the form of attributes) of this entity. In the process, the implementation details of the business object type are hidden from the end user, and the business object type itself is accessed through defined functions (methods/BAPIs). This is referred to as encapsulation.

Use
Business object types are used to break a SAP system down into smaller, disjunctive units. As a result, the systems structure is improved while its complexity is reduced. Business object types form the point of entry to the data and the functions of an SAP System. At business object type level, non-SAP systems can communicate with an SAP System, and the various SAP business components can communicate with each other.

Structure
To encapsulate the SAP data and business processes, SAP business objects are defined as entities with multiple layers, as illustrated in the following graphic:

The innermost layer of the SAP business object is the kernel, and represents the objects inherent data. It contains attributes like the name, age, or address of an employee. The second layer, the integrity layer, contains the business logic of the object. It comprises the business rules for consistent embedding in the environment and the constraints regarding the values and domains that apply to the business object types. A sales organization can only sell to a customer for whom they have information about their business relationship. The third layer, the interface layer, supplies the valid options for accessing the business object type, defining the objects interface to the outside world. The methods/BAPIs for accessing the objects are housed here. Instead of limiting itself to BAPIs, the information below refers to the somewhat broader methods. The fourth and outermost layer of a business object is the access layer. It defines the technologies that allow external access to the object data.

Integration
Accessing Business Object Types As above diagram shows, the interface layer separates a business object types data from the applications and technologies that are used to access it. To the outside, business object types reveal only their interface, which consists of a set of clearly defined methods. Applications can only access the business object type data through the methods of that type.

An application program wanting to access an SAP business object type and its data only needs the information required to execute the methods. Therefore, application programmers can work with SAP business object types and call their methods without having to know anything about SAP-specific implementation details of the object. The set of methods associated with a business object type represents the objects behavior. When a method is executed on a business object type, the method can change the objects internal state, that is, the objects data. For example, one method that you can use on business object Employee is to check for the employees existence. Object Types and Object Instances The term business object type corresponds to the term class in object-oriented programming languages. It defines a template for concrete objects that all have the same structure and the same behavior. For example, the individual employees working in an organization are all part of the Employee object type. The object types are descriptions of actual SAP business objects that can exist in the SAP System; that is, each individual SAP business object is a representation, or instance, of its object type. For example, the employee with the name Charlie Jones and the employee number 1234 is an instance of the Employee object type. When writing object-oriented application programs, developers identify the object types that are to be used in their programs. At runtime, the application program accesses the specific instances of the defined object types. For more information, see the ALE Programmer Guide under Business Object Types.

The Business Object Repository


Definition
The Business Object Repository (BOR) is the central access point for the SAP business object types and their BAPIs. The BOR was originally developed for SAP Business Workflow. Today, in addition to storing SAP business object types and their BAPIs, the BOR is used for ArchiveLink, output control, and other generic object services.

Use
The BOR provides the following services in the BAPI context: Allows an object-oriented view of all data and processes in an SAP System Arranging the various business object types according to the component hierarchy This enables you to find the required functions quickly and easily. Storage of all relevant information The BOR contains all the relevant information on the SAP business object types, their key fields, and their BAPI methods that is needed to integrate the correct object type definitions and BAPI calls in an application program. This enables the integration of middleware (such as the DCOM Connector, ActiveX Controls, CORBA Gateway, and so on).

It ensures BAPI interface stability Any interface changes carried out in the BOR are automatically checked for syntax compatibility against the associated development objects in the ABAP Dictionary It manages BAPIs in release updates BAPI interface enhancements made by adding parameters are recorded in the BOR. Previous interface versions can thus be reconstructed at any time. When a BAPI is created, the release version of the new BAPI is recorded in the BOR. The same applies when any interface parameter is created. It creates instances of SAP business objects The runtime environment of the BOR receives requests to create runtime objects from client applications and creates the appropriate object instances SAP Business

For more information on the Business Object Repository, see the documentation on Workflow.

BAPI Information Landscape


The available BAPI documentation covers the following three areas: Developing new BAPIs Further Aspects of BAPI Development Using BAPIs in Clients

BAPI Development
The BAPI Programming Guide explains the procedure model for developing your own BAPIs. Specifically, it will deal with the restrictions and guidelines associated with the development of BAPIs, discuss the requirements that BAPIs have to meet, and introduce support tools that can be used for development. The BAPI Explorer plays a central role in the BAPI development process. The BAPI Explorer enables easy access to all the relevant information in the BAPI environment (including general documentation as well details about special business object types and BAPIs). The Explorer integrates all the tools required for BAPI development and uses project forms to manage all the phases of the development process. This document deals exclusively with the development of new BAPIs. In contrast, instructions for enhancing, extending, and modifying existing BAPIs are described in Further Aspects of BAPI Development.

Further Aspects of BAPI Development


The documents located at this level contain topics that start with the standard case for new development described in the kernel and expand it with practical requirements. The following individual subjects are covered: The document SAP Enhancements to Released BAPIs describes how SAP developers can enhance BAPIs that have already been released, and which procedure you have to use.

The document Customer Enhancement and Modification of BAPIs explains how IBUs, partners, and customers can enhance and modify BAPIs supplied by SAP to meet their own specific needs. In detail, the document explains when the enhancement concept can be applied and when changes to BAPIs can only be implemented through the modification concept. The document Using ALE Services describes how ALE inbound processing can be used to implement both synchronous and asynchronous BAPI calls, enabling distributed scenarios. In particular, this document describes in detail the process flow during asynchronous communication with BAPIs and explains which steps you have to perform when generating the BAPI-ALE interface to enable ALE inbound processing for BAPI use. Mass data transfer using BAPIs is described in the document BAPIs for Mass Data Transfer. In addition, the programming model is introduced for designing BAPIs that are capable of processing mass data.

Using BAPIs in Clients


This area explains how to use and access BAPIs. The BAPI User Guide describes how to retrieve all the meta data required for a call, how to use search help, and so on.

All the documents are available in the SAP Library under CA-BFA.

Potrebbero piacerti anche