Beruflich Dokumente
Kultur Dokumente
SAP AG, Neurottstr. 16, D-69190 Walldorf, Germany; E-mail: Anton.Deimel@sap-ag.de, http://www.sap-ag.de/
Abstract. This paper gives a synopsis of the SAP R/3 Application Programming Interfaces) – precisely de-
Business Framework. The architecture is based on an fined interfaces for these business objects.
object-orientated approach using business objects and – SAP partners and third party vendors can integrate
Business Components. Using this architecture together the Business Components using standardized inter-
with a distribution model, distributed applications (dis- faces that support the open R/3 System.
tributed business processes) can be mapped and imple- – New applications can easily be implemented in vari-
mented. The spectrum of distributed applications ex- ous development environments, and front-end devel-
tends from the simple integration of two components opment is also straightforward.
using a few interfaces to the integration of many compo- – DCOM and CORBA connections interoperability.
nents distributed across the globe.
SAP R/3
Business Component
BAPI
Business
BAPI (Distributed) Business
Object Processes
BAPI
Services for
integrating Business
Process and
Application Link Enabling (ALE) distributing Business
Objects
SAP Remote
Function Call (D)COM CORBA Communication Services
(RFC)
The object-oriented structure of R/3 is based on busi- BAPI Change Management guarantees the stability of
ness objects that encapsulate business data and func- BAPI interfaces.
tions. All the business objects are managed in the Busi- The integration service, Application Link Enabling
ness Object Repository (BOR). (ALE), enables the integration of business processes ex-
BAPIs are interfaces for business objects that can be ecuted in different R/3 or non-SAP systems and require
called from external programs. Together with the busi- one or more interfaces to be called. The ALE distribution
ness objects, BAPIs define and document the interface model distributes the business objects involved across the
standard at the business level. SAP’s strictly regulated system.
R/3 Presentation
Business Component
Non R/3-Systems
BAPI
• MS Visual Basic,
Business
C++ BAPI Object
• IBM VisualAge/Java
• MS NT, Unix, OS/2 ... BAPI
object type. The SAP Business Object types are defined volved: defining the interface in the BOR and implement-
by the following: ing the BAPI in the Function Builder (Fig. 4).
– Object type Business object types are assigned to Components in
The object type describes the features common to all the Business Object Repository. For instance, all the Hu-
instances of that object type. This includes informa- man Resources (HR) objects are assigned to the HR Com-
tion such as the unique name of the object type, its ponent. The BOR manages versions and the release sta-
classification, and the data model. tus of BAPIs and business objects. A BAPI is defined by
– Key fields its import and export parameters. BAPI methods relat-
The key fields determine the structure of an identify- ing to classes can be distinguished from BAPI methods
ing key, which allows an application to access a specific relating to instances. Typical methods relating to a class
instance of the object type. The object type Employee are the standardized methods such as GetList or Create.
and the key field Employee.Number are examples of The method GetList can retrieve, for example, all the cus-
an object type and a corresponding key field. tomer orders made by a specific customer and then return
– Methods all these instances in a table. GetDetail is an example
A method is an operation that can be performed on of a method relating to one instance; it returns all the
a business object and that provides access to the ob- fields (attributes) in a specific object or instance to the
ject data. A method is defined by a name and a set caller.
of parameters and exceptions that can or must be BAPIs are implemented in the SAP Function Builder
provided by the calling program in order to use the as function modules that can be called from remote sys-
method. tems. Function modules are executable programs with
– Attributes defined interfaces; they are stored in the SAP Function
An attribute contains data about a business object, Builder. These function modules are assigned to busi-
thus describing a particular object property. For ex- ness object types in the BOR as object methods (BAPIs).
ample, Employee.Name is an attribute of the Em- BAPIs must first be defined in the BOR before they can
ployee object type. be called as methods. An additional advantage of the con-
– Events cept is, that BAPIs can also be called directly as functions
An event indicates the occurrence of a status change of (remote function calls), if a development environment
a business object. does not yet support method calls (“time to market”).
The function module maps the characteristics of
a BAPI. The import and export parameters in the func-
tion module correspond to the parameters in the BAPI.
5 Implementing business object types Both mandatory and optional parameters can be defined.
The caller must define the mandatory parameters. Pa-
Business object types are defined and implemented in rameters for structures and tables can also be defined,
the Business Object Repository (BOR). However, the as well as simple parameters for one field. BAPIs are
SAP Function Builder is used to actually implement the standardized interfaces; that is, all the data types in the
methods (BAPIs). This means that two processes are in- R/3 Workbench can be used to define parameters. When
BAPI A
Business Object
Repository (BOR)
Business „Object Layer“
Object Type BAPI B
Definition of
BAPI C
Object Types and BAPIs
Function Module
impl. BAPI A Function Builder
Function Module
impl. BAPI B Implementation of
Function Module Object Types and BAPIs
impl. BAPI C
BAPIs are called, the RFC (remote function call) con- time-recording subsystem to record employees’ working
verts the data between the different system platforms. hours. Combined possibly with an entry and exit con-
BAPI documentation is an essential part of the imple- trol system, the starting and finishing times of employees
mentation. The documentation describes the functions of are recorded in a time-recording terminal and forwarded
the BAPI and the functions of all the parameters. If pa- to the SAP System, where working hours are calculated.
rameters contain more than one field, for instance, tables, The results can be input into, for example, HR payroll
the parameter description provides an overview of all the accounting. So that necessary checks can be carried out
fields and describes the dependencies between the fields. when working hours are being recorded, the SAP HR Sys-
The function of each field is documented in the individual tem passes relevant data from the employee master data
fields using data elements from the ABAP Dictionary (see to the non-SAP system, for instance, time-recording ID
Metadata Available in the Interface). The documentation numbers.
is available in all the release languages. The HR Component first calls the functionality from
Business object types are also used by SAP Business the non-SAP system to transfer the necessary data to it
Workflow and for archiving purposes (ArchiveLink) as (outbound). The non-SAP System then becomes the re-
well as for structuring SAP Components. ceiver of the employee master data. The interface type
In the near future business objects will be imple- is defined as a method in the Business Object Reposi-
mented in the Class Library for ABAP Objects. The SAP tory and records the outbound process. The system that
object-oriented programming language, ABAP Objects, was called implements this interface. This means that
is the successor to the ABAP programming language and non-SAP functionality can also be defined in the BOR as
implements a full-blown object-oriented development en- a standardized interface and made available as a BAPI. In
vironment. the outbound process the same rules apply to the inter-
face stability and to BAPI Change Management as apply
to BAPIs in inbound processing.
6 SAP Business Components The purpose of Application Link Enabling (ALE) is to
determine the target system or the class that the BAPI
SAP Business Components contain the business object has implemented in the outbound process. Information
types required by a Component to carry out specified specified in the ALE distribution model is used for this.
business processes. Figure 5 describes the integration of The definition of inbound and outbound interfaces as
the HR Component with a non-SAP system, a so-called methods of business object types and business interface
Inbound
Outbound
Interface Type
BAPI (Outbound)
“Receiver of
EmployeeMasterData Employee
Receiver MasterData”
Method of Interface Type:
ReceiveMasterData
The Object Class of the
non-SAP System
Implements the Interface
Inbound
Outbound
Object Type
BAPI (Inbound)
ManagerExternal
PersonalTimeEvents
Method of Object Type:
SavePersonalTimeEvents
Fig. 5. Example of integration of the SAP Business Component Human Resources and a non-SAP System
34 A. Deimel: The SAP R/3 Business Framework
types in the Business Object Repository provides a pre- faces, the programs and Components that call these inter-
cise definition of the component boundary of SAP Busi- faces must also be modified.
ness Components. In BAPI Change Management a distinction is made
between compatible and incompatible enhancements.
The biggest advantage in making this distinction is that
existing client programs do not have to be modified if
7 Standardized interfaces and BAPI Change compatible enhancements are made to the interface, such
Management as adding more optional parameters and functions. Com-
patible enhancements do not necessitate a new interface,
BAPIs aim to provide a standardized interface. The gran- so the number of required interface versions is kept to
ularity of the standardization starts at the field or domain a minimum.
level and extends across several granularity levels such Incompatible enhancements include domain changes,
as method and business object levels through to business such as lengthening fields, semantic changes, and the
processes. The functional standardization is accompanied changes required when an existing function is no longer to
by organizational changes, BAPI Change Management, be supported. Such incompatible enhancements are made
which ensures the stability of the interfaces and of mod- significantly less often than compatible enhancements.
ifications made to the interface. The ABAP Dictionary checks incompatible changes when
Standardizing fields, for example, mapping person- enhancements are made to BAPIs. When an incompati-
nel and material numbers are based on SAP’s and SAP ble enhancement is made, an additional BAPI has to be
partners’ long-standing experience in developing business created. The BAPI is given the same name with a num-
applications. Interface parameters and fields are stan- ber added at the end. For example, if the existing BAPI
dardized by domains. Domains define data types and is named FixedAsset.Create, the new BAPI is named
field lengths among other attributes and are stored in FixedAsset.Create1. The existing BAPI is flagged as “ex-
the ABAP Dictionary. The standardization at domain piring” and continues to be supported for at least two
level forms the basis for the standardization of higher- subsequent SAP releases (roughly two years). During this
level functionality, such as methods and business objects. time BAPI users can adapt their programs to the new
Domain standardization is the most important type of in- interfaces. Afterwards the expired BAPI is no longer sup-
terface standardization. The interface supports the ISO ported and is deleted.
standard by using additional fields containing the ISO A freezing procedure ensures that the BAPI is down-
standard for displaying values, such as unit of measure, ward compatible to the interfaces used in the Business
language and currency fields. Parameters and fields with Framework. BAPIs are frozen when they are released;
the same business function are named the same, even if this procedure requires syntax-compatible interface en-
they are used in different BAPIs. hancements. This should then ensure, for example, that
The BAPI Return parameter has also been standard- parameters cannot be deleted or types and lengths cannot
ized. Each BAPI has to implement an export parameter be changed.
named Return which itself consists of standardized fields.
This means that error handling in BAPIs has also been
standardized. 8 The BAPI programming model
The BAPIs GetList, GetDetail, Create, Change,
Delete and ExistenceCheck, among others, are standard- The programming model determines how BAPIs are im-
ized BAPIs for business objects. The BAPIs CreateMul- plemented and how they are used. This is based on the
tiple and ChangeMultiple are used to request mass data. transaction model for the transaction programming
The BAPIs Replicate, SaveReplica and SaveReplicaMul- BAPIs are able to read or modify data. BAPIs that
tiple are used to clone data. modify data must make such changes in consistent pro-
Standardization at the business object level occurs be- cessing steps so that no inconsistent datasets are created
cause business objects map important general data, such for a business object. In the transaction model, a trans-
as Employee, Equipment, PurchaseRequisition and Sale- action represents one processing step or Logical Unit of
sOrder, from a business environment. Business objects Work (LUW). As a BAPI can only generate consistent
have precisely defined names and they map business func- datasets, all the relevant parameters must exist in the in-
tions essentially into attributes and methods. terface. For example, if you create a purchase order, the
Business processes have been standardized with the purchase order items have to be transferred as well as the
most rudimentary granularity. For example, production purchase order header. This brings an improvement in
in several locations (local R/3 installations) linked to cen- communication security.
tral sales and distribution are described in integration BAPIs must also be programmed to be stateless. This
scenarios. means that there must not be any undesired functional
Stable interfaces are essential for BAPI standardiza- dependencies between BAPIs calls. For example, the ad-
tion. If incompatible enhancements are made to inter- dress data of the first BAPI call must not be able to cor-
A. Deimel: The SAP R/3 Business Framework 35
rupt the address data of the second BAPI call. The caller in the SAP organization model are supplied. The foreign
controls the transaction; for example, callers can bundle key dependencies of fields can be used in the interface to
several BAPIs together in one transaction and complete determine which values are valid for dependent fields. The
the process by calling a BAPI for commit or rollback. foreign key checks are frequently used in online applica-
A commit writes all the data to the database in the R/3 tions to validate input values.
System. A rollback does not execute any changes and re- The entire metadata are managed in the ABAP Dic-
sets the database to its status in the last commit call. tionary and can be fetched using the BAPIs of the busi-
Users can execute several transactions in the same termi- ness objects BAPIService and Helpvalues.
nal session, that is, between logging onto and logging off
the R/3 System.
The R/3 user authorization system checks who is 10 Integrated distributed applications through
using a BAPI. BAPIs can only be called after the user distributed business objects
has logged onto R/3. The caller must have an R/3 user
account, to which various authorization profiles can be as- An important feature of the R/3 Business Framework is
signed. BAPIs carry out authorization checks if required the distribution of business objects across different sys-
by the application context. tems. For example, a local production department with
If customers make their own modifications to the R/3 its own R/3 Systems in each plant can be connected to
System, the interfaces often need to be modified too. Cus- a central purchasing department. The Business Frame-
tomers can include their own parameters in the interface work integrates the distributed functions and data into
and specify values for them using function exits. When the global system.
the system is upgraded, the parameters in the standard- Organization structures in companies may also re-
ized BAPI are merged with the parameters in the BAPI quire that business processes and tasks are distributed.
modified by the customer. Distribution in the SAP Business Framework is based
on Business Components, business objects and the ALE
distribution model. The Components describe which
9 Metadata available in the interface business functions and processes are related to each other,
for example, all the functions and processes involved in
The parameters and fields in BAPI interfaces contain purchasing. Business objects are distributed in the ALE
a lot of metadata to make the interfaces easier to use. Distribution model for the whole system. Business ob-
Metadata in individual fields include, for example, data jects may be distributed according to organization unit,
type and length specifications or a list of allowed value such as company codes and plants, or they may be dis-
ranges. The data types provided are integer (byte, short, tributed much more specifically according to individual
long), float, character, numeric character, date, time, hex instances, for example, material numbers.
and packed. The value ranges allowed in fields are defined Before a BAPI can be called, the instance of the busi-
in check tables, value tables and domain fixed values. ness object in which the method is to be implemented
Values for search help are also defined in tables in the data must first be determined. The ALE receiver determin-
elements. ation does this and, using the ALE distribution model
The availability of descriptive text, for example, head- and the filter criteria, returns the logical system of the in-
ers and explanations for the help function, proves of great stance. Filter criteria are, for example, organization units
benefit when using the interfaces (for example, for desk- such as company code, and plants. Larger global systems
top development). These texts are supplied in several consist of several systems with their own databases. An
languages and can be retrieved from the information pro- R/3 application system is subdivided into several clients,
vided for the interface. whereby each client represents one logical system.
To enable the display of field contents in output fields Distributed components can be integrated using loose
on the screen, the data sometimes have to be converted coupling or narrow coupling. Narrow coupling is used
into the output format. To do this, conversion routines for synchronous BAPI calls. Synchronous BAPIs are
have to be defined in the data elements. If required, these narrowly coupled, for example, read BAPIs and check
domain conversions can be made by calling the associated BAPIs. The advantages of narrow coupling are that data
BAPI. are current and do not need to be replicated. The disad-
Fields that are logically related can be grouped to- vantages are that the integrated systems must be avail-
gether under one name in structures. Structures are used able and that access to large datasets involves callers
in the interfaces as one-line or multiple-line tables. Se- having to wait. Loose coupling avoids these problems; it
mantic dependencies between fields in these structures is used for asynchronous BAPI calls and data replication.
can be defined in foreign keys. For example, if one struc- ALE technology uses a transactional RFC (remote func-
ture contains two fields (plant and company code), then, tion call) to make asynchronous BAPI calls, where the
depending on the company code specified, the valid caller can continue working and does not have to wait
values for plants assigned to that specific company code for a response from the system called. ALE technology
36 A. Deimel: The SAP R/3 Business Framework
ness object in the receiving system. The replication can uring uring uring
WM
3 2 1
be initiated by the system containing the original busi- for
shipping
ness object with a push operation or by the receiving sys-
tem with a pull operation. When business objects are dis-
tributed with replication, all the logical systems involved Fig. 6. Integration scenario with decentral production and shared
are specified in the ALE distribution model. These are the sales and distribution
logical system containing the original business object and
all the receiving systems that are to receive a replica (the
subscribing systems). Data filters can also be defined for
each receiver, so that the data in the business object are
replicated specifically for each receiver.