Software – Concepts & Tools (1998) 19: 29–36
The SAP R/3 Business Framework
Anton Deimel
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
Business Framework. The architecture is based on an
object-orientated approach using business objects and
Business Components. Using this architecture together
with a distribution model, distributed applications (dis-
tributed business processes) can be mapped and imple-
mented. The spectrum of distributed applications ex-
tends from the simple integration of two components
using a few interfaces to the integration of many compo-
nents distributed across the globe.
Key words: Software architecture – Component – BAPI
– Business Framework – Distributed computing – Object
orientation – SAP R/3
1 Introduction
With over 15 000 installations world wide, the R/3 Sys-
tem from SAP AG offers standard software for individual
solutions in virtually all branches of commerce and in-
dustry. The R/3 System currently consists of more than
a dozen Business Components. The SAP R/3 Business
Framework enables these individual Components to be
integrated and business data to be exchanged between
them.
The SAP R/3 Business Framework offers the following
benefits:
– Short implementation times and therefore lower costs
for customers.
– Individual Components from different releases can be
integrated. Components that are upgraded frequently,
for instance, Human Resources, do not require simul-
taneous upgrading of other Components.
– Business processes are structured and encapsulated in
business objects and are accessed via BAPIs (Business
 1998 Springer-Verlag
Application Programming Interfaces) – precisely de-
fined interfaces for these business objects.
– SAP partners and third party vendors can integrate
the Business Components using standardized inter-
faces that support the open R/3 System.
– New applications can easily be implemented in vari-
ous development environments, and front-end devel-
opment is also straightforward.
– DCOM and CORBA connections interoperability.
2 Business Framework architecture – basis of the
SAP component structure
The SAP R/3 Business Framework provides a structure
for R/3 functionality based on Business Components and
object models. The use of object-oriented technology and
object models reduces the complexity of the overall sys-
tem. The greater the scope of functionality in the system,
the more important it is that complexity be reduced.
Business Framework architecture provides the basis
for developing SAP Business Components (Fig. 1). The
basic components of SAP R/3 Business Framework are:
– Business Components consisting of business objects
– Business objects
– BAPIs (Business APIs)
– ALE (Application Link Enabling) integration service
– communication services
– the R/3 three-level client/server architecture
SAP Business Components provide autonomous busi-
ness functions and consist of business objects. For ex-
ample, the Business Component Human Resources con-
tains the business objects Employee, Applicant, Payroll,
etc. Business processes are implemented either within one
Business Component or across several Business Compo-
nents (distributed business processes).
30 A. Deimel: The SAP R/3 Business Framework

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)

Fig. 1. SAP Business Framework architecture

The object-oriented structure of R/3 is based on busi-
ness objects that encapsulate business data and func-
tions. All the business objects are managed in the Busi-
ness Object Repository (BOR).
BAPIs are interfaces for business objects that can be
called from external programs. Together with the busi-
ness objects, BAPIs define and document the interface
standard at the business level. SAP’s strictly regulated
BAPI Change Management guarantees the stability of
BAPI interfaces.
The integration service, Application Link Enabling
(ALE), enables the integration of business processes ex-
ecuted in different R/3 or non-SAP systems and require
one or more interfaces to be called. The ALE distribution
model distributes the business objects involved across the
system.

R/3 Presentation

• SAP R/3 GUI R/3 Application Server

R/3 Database Server
• Web
• Desktop R/3 Application Server

Business Component
Non R/3-Systems
BAPI
• MS Visual Basic,
Business
C++ BAPI Object
• IBM VisualAge/Java
• MS NT, Unix, OS/2 ... BAPI

Fig. 2. R/3 Three-level client/server architecture

 A. Deimel: The SAP R/3 Business Framework
The openness of the R/3 System to object-oriented
communication models such as COM/DCOM or COR-
BA/Java is based on the object-oriented structure of R/3
functions (business objects and their BAPIs). The in-
terface metadata (Interface Definition Language) enables
object-oriented access to business objects in the Busi-
ness Object Repository via DCOM and CORBA con-
nections. With DCOM and CORBA connections the use
of BAPIs on different platforms is especially straight-
forward.
SAP’s internal communication technology is SAP
Remote Function Call (SAP RFC). The RFC han-
dles the system-dependent data conversion and the
physical transfer of the data. RFC calls may be syn-
chronous or transactionally asynchronous. With syn-
chronous calls, for example, with read BAPIs, such as
Equipment.GetDetail, the caller waits for the current
data. Change BAPIs are often called in asynchronous
transactions where no parameter data is returned to the
caller (messaging).
SAP R/3 is based on a three-level client/server ar-
chitecture (Fig. 2). The Business Components and their
business objects are stored on the application servers,
that is, on the second level of the architecture.
The R/3 three-level client/server architecture enables
the following features:
– A range of standard communication technologies can
be used to access data in SAP Business Objects. These
technologies are used to connect applications and per-
mit the development of business transactions for var-
ious front-ends, such as Internet Application Compo-
nents (IAC), MS Visual Basic/ActiveX, Java, and var-
ious Web interfaces.
– A large number of users can be supported by adding
more application servers (scalable architecture).
– The load can be distributed across application servers
(load balancing).
– A Transaction Processing Monitor can be used.
3 SAP’s way of providing classes and objects
At the center of the R/3 Business Framework concept
is the structuring of application functions based on an
object model consisting of business objects. In SAP’s
object-oriented programming model, business objects are
mapped to classes and business objects correspond to in-
stances. You can visualize the SAP Business Objects as
black boxes that encapsulate R/3 data and business pro-
cesses, thus hiding the details of the structure and imple-
mentation of the underlying data.
To achieve this encapsulation, the SAP Business Ob-
jects are constructed as entities with multiple layers
(Fig. 3):
1. At the core of an SAP Business Object is the kernel,
which represents the object’s inherent data.
31
Integrity Interface
Kernel Access
Attributes
Business
Rules, Methods COM/DCOM,
Inherent RFC,
Data Con- BAPIs JAVA,
straints CORBA
Events
Fig. 3. Architecture of business objects
2. The second layer, the integrity layer, represents the
business logic of the object. It comprises the business
rules and constraints that apply to the business ob-
ject.
3. The third layer, the interface layer, describes the im-
plementation and structure of the SAP Business Ob-
ject and defines the object’s interface to the outside
world.
4. The fourth and outermost layer of a business object
is the access layer, which defines the technologies that
can be used to obtain external access to the object’s
data, for example, COM/DCOM (Component Object
Model/Distributed Component Object Model).
4 Object types and object instances
Each individual business object belongs to a specific ob-
ject class, depending on the nature and general character-
istics of the object. These object classes are called object
types. For example, the individual employees working in
an organization are all part of the employee object type.
The object types are descriptions of the actual SAP
Business Objects that can exist in R/3; that is, each in-
dividual SAP Business Object is a representation, or in-
stance, of its object type. For example, the employee with
the name Charles Jones and the employee number 1234 is
an instance of the employee object type.
When writing object-oriented application programs,
application developers identify the object types that are
to be used and operated on by their programs. At run
time, the application program accesses the specific in-
stances of the defined object types.
When an instance of a business object is used by an
application program, the object instance responds only to
the set of characteristics and methods defined for its own
32 A. Deimel: The SAP R/3 Business Framework
object type. The SAP Business Object types are defined
by the following:
– Object type
The object type describes the features common to all
instances of that object type. This includes informa-
tion such as the unique name of the object type, its
classification, and the data model.
– Key fields
The key fields determine the structure of an identify-
ing key, which allows an application to access a specific
instance of the object type. The object type Employee
and the key field Employee.Number are examples of
an object type and a corresponding key field.
– Methods
A method is an operation that can be performed on
a business object and that provides access to the ob-
ject data. A method is defined by a name and a set
of parameters and exceptions that can or must be
provided by the calling program in order to use the
method.
– Attributes
An attribute contains data about a business object,
thus describing a particular object property. For ex-
ample, Employee.Name is an attribute of the Em-
ployee object type.
– Events
An event indicates the occurrence of a status change of
a business object.
5 Implementing business object types
Business object types are defined and implemented in
the Business Object Repository (BOR). However, the
SAP Function Builder is used to actually implement the
methods (BAPIs). This means that two processes are in-
Business
Object Type
BAPI C
Function Module
impl. BAPI A
Function Module
impl. BAPI B
Function Module
impl. BAPI C
Fig. 4. Defining and implementing business object types and BAPIs
volved: defining the interface in the BOR and implement-
ing the BAPI in the Function Builder (Fig. 4).
Business object types are assigned to Components in
the Business Object Repository. For instance, all the Hu-
man Resources (HR) objects are assigned to the HR Com-
ponent. The BOR manages versions and the release sta-
tus of BAPIs and business objects. A BAPI is defined by
its import and export parameters. BAPI methods relat-
ing to classes can be distinguished from BAPI methods
relating to instances. Typical methods relating to a class
are the standardized methods such as GetList or Create.
The method GetList can retrieve, for example, all the cus-
tomer orders made by a specific customer and then return
all these instances in a table. GetDetail is an example
of a method relating to one instance; it returns all the
fields (attributes) in a specific object or instance to the
caller.
BAPIs are implemented in the SAP Function Builder
as function modules that can be called from remote sys-
tems. Function modules are executable programs with
defined interfaces; they are stored in the SAP Function
Builder. These function modules are assigned to busi-
ness object types in the BOR as object methods (BAPIs).
BAPIs must first be defined in the BOR before they can
be called as methods. An additional advantage of the con-
cept is, that BAPIs can also be called directly as functions
(remote function calls), if a development environment
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.
Both mandatory and optional parameters can be defined.
The caller must define the mandatory parameters. Pa-
rameters for structures and tables can also be defined,
as well as simple parameters for one field. BAPIs are
standardized interfaces; that is, all the data types in the
R/3 Workbench can be used to define parameters. When
BAPI A
Business Object
Repository (BOR)
„Object Layer“
BAPI B
Definition of
Object Types and BAPIs
Function Builder
Implementation of
Object Types and BAPIs
 A. Deimel: The SAP R/3 Business Framework 33

BAPIs are called, the RFC (remote function call) con-
verts the data between the different system platforms.
BAPI documentation is an essential part of the imple-
mentation. The documentation describes the functions of
the BAPI and the functions of all the parameters. If pa-
rameters contain more than one field, for instance, tables,
the parameter description provides an overview of all the
fields and describes the dependencies between the fields.
The function of each field is documented in the individual
fields using data elements from the ABAP Dictionary (see
Metadata Available in the Interface). The documentation
is available in all the release languages.
Business object types are also used by SAP Business
Workflow and for archiving purposes (ArchiveLink) as
well as for structuring SAP Components.
In the near future business objects will be imple-
mented in the Class Library for ABAP Objects. The SAP
object-oriented programming language, ABAP Objects,
is the successor to the ABAP programming language and
implements a full-blown object-oriented development en-
vironment.
6 SAP Business Components
SAP Business Components contain the business object
types required by a Component to carry out specified
business processes. Figure 5 describes the integration of
the HR Component with a non-SAP system, a so-called
time-recording subsystem to record employees’ working
hours. Combined possibly with an entry and exit con-
trol system, the starting and finishing times of employees
are recorded in a time-recording terminal and forwarded
to the SAP System, where working hours are calculated.
The results can be input into, for example, HR payroll
accounting. So that necessary checks can be carried out
when working hours are being recorded, the SAP HR Sys-
tem passes relevant data from the employee master data
to the non-SAP system, for instance, time-recording ID
numbers.
The HR Component first calls the functionality from
the non-SAP system to transfer the necessary data to it
(outbound). The non-SAP System then becomes the re-
ceiver of the employee master data. The interface type
is defined as a method in the Business Object Reposi-
tory and records the outbound process. The system that
was called implements this interface. This means that
non-SAP functionality can also be defined in the BOR as
a standardized interface and made available as a BAPI. In
the outbound process the same rules apply to the inter-
face stability and to BAPI Change Management as apply
to BAPIs in inbound processing.
The purpose of Application Link Enabling (ALE) is to
determine the target system or the class that the BAPI
has implemented in the outbound process. Information
specified in the ALE distribution model is used for this.
The definition of inbound and outbound interfaces as
methods of business object types and business interface

SAP Business Component Non-SAP System

Human Resources

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

Application Link Enabling (ALE)

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-
cise definition of the component boundary of SAP Busi-
ness Components.
7 Standardized interfaces and BAPI Change
Management
BAPIs aim to provide a standardized interface. The gran-
ularity of the standardization starts at the field or domain
level and extends across several granularity levels such
as method and business object levels through to business
processes. The functional standardization is accompanied
by organizational changes, BAPI Change Management,
which ensures the stability of the interfaces and of mod-
ifications made to the interface.
Standardizing fields, for example, mapping person-
nel and material numbers are based on SAP’s and SAP
partners’ long-standing experience in developing business
applications. Interface parameters and fields are stan-
dardized by domains. Domains define data types and
field lengths among other attributes and are stored in
the ABAP Dictionary. The standardization at domain
level forms the basis for the standardization of higher-
level functionality, such as methods and business objects.
Domain standardization is the most important type of in-
terface standardization. The interface supports the ISO
standard by using additional fields containing the ISO
standard for displaying values, such as unit of measure,
language and currency fields. Parameters and fields with
the same business function are named the same, even if
they are used in different BAPIs.
The BAPI Return parameter has also been standard-
ized. Each BAPI has to implement an export parameter
named Return which itself consists of standardized fields.
This means that error handling in BAPIs has also been
standardized.
The BAPIs GetList, GetDetail, Create, Change,
Delete and ExistenceCheck, among others, are standard-
ized BAPIs for business objects. The BAPIs CreateMul-
tiple and ChangeMultiple are used to request mass data.
The BAPIs Replicate, SaveReplica and SaveReplicaMul-
tiple are used to clone data.
Standardization at the business object level occurs be-
cause business objects map important general data, such
as Employee, Equipment, PurchaseRequisition and Sale-
sOrder, from a business environment. Business objects
have precisely defined names and they map business func-
tions essentially into attributes and methods.
Business processes have been standardized with the
most rudimentary granularity. For example, production
in several locations (local R/3 installations) linked to cen-
tral sales and distribution are described in integration
scenarios.
Stable interfaces are essential for BAPI standardiza-
tion. If incompatible enhancements are made to inter-
faces, the programs and Components that call these inter-
faces must also be modified.
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
compatible enhancements are made to the interface, such
as adding more optional parameters and functions. Com-
patible enhancements do not necessitate a new interface,
so the number of required interface versions is kept to
a minimum.
Incompatible enhancements include domain changes,
such as lengthening fields, semantic changes, and the
changes required when an existing function is no longer to
be supported. Such incompatible enhancements are made
significantly less often than compatible enhancements.
The ABAP Dictionary checks incompatible changes when
enhancements are made to BAPIs. When an incompati-
ble enhancement is made, an additional BAPI has to be
created. The BAPI is given the same name with a num-
ber added at the end. For example, if the existing BAPI
is named FixedAsset.Create, the new BAPI is named
FixedAsset.Create1. The existing BAPI is flagged as “ex-
piring” and continues to be supported for at least two
subsequent SAP releases (roughly two years). During this
time BAPI users can adapt their programs to the new
interfaces. Afterwards the expired BAPI is no longer sup-
ported and is deleted.
A freezing procedure ensures that the BAPI is down-
ward compatible to the interfaces used in the Business
Framework. BAPIs are frozen when they are released;
this procedure requires syntax-compatible interface en-
hancements. This should then ensure, for example, that
parameters cannot be deleted or types and lengths cannot
be changed.
8 The BAPI programming model
The programming model determines how BAPIs are im-
plemented and how they are used. This is based on the
transaction model for the transaction programming
BAPIs are able to read or modify data. BAPIs that
modify data must make such changes in consistent pro-
cessing steps so that no inconsistent datasets are created
for a business object. In the transaction model, a trans-
action represents one processing step or Logical Unit of
Work (LUW). As a BAPI can only generate consistent
datasets, all the relevant parameters must exist in the in-
terface. For example, if you create a purchase order, the
purchase order items have to be transferred as well as the
purchase order header. This brings an improvement in
communication security.
BAPIs must also be programmed to be stateless. This
means that there must not be any undesired functional
dependencies between BAPIs calls. For example, the ad-
dress data of the first BAPI call must not be able to cor-
 A. Deimel: The SAP R/3 Business Framework
rupt the address data of the second BAPI call. The caller
controls the transaction; for example, callers can bundle
several BAPIs together in one transaction and complete
the process by calling a BAPI for commit or rollback.
A commit writes all the data to the database in the R/3
System. A rollback does not execute any changes and re-
sets the database to its status in the last commit call.
Users can execute several transactions in the same termi-
nal session, that is, between logging onto and logging off
the R/3 System.
The R/3 user authorization system checks who is
using a BAPI. BAPIs can only be called after the user
has logged onto R/3. The caller must have an R/3 user
account, to which various authorization profiles can be as-
signed. BAPIs carry out authorization checks if required
by the application context.
If customers make their own modifications to the R/3
System, the interfaces often need to be modified too. Cus-
tomers can include their own parameters in the interface
and specify values for them using function exits. When
the system is upgraded, the parameters in the standard-
ized BAPI are merged with the parameters in the BAPI
modified by the customer.
9 Metadata available in the interface
The parameters and fields in BAPI interfaces contain
a lot of metadata to make the interfaces easier to use.
Metadata in individual fields include, for example, data
type and length specifications or a list of allowed value
ranges. The data types provided are integer (byte, short,
long), float, character, numeric character, date, time, hex
and packed. The value ranges allowed in fields are defined
in check tables, value tables and domain fixed values.
Values for search help are also defined in tables in the data
elements.
The availability of descriptive text, for example, head-
ers and explanations for the help function, proves of great
benefit when using the interfaces (for example, for desk-
top development). These texts are supplied in several
languages and can be retrieved from the information pro-
vided for the interface.
To enable the display of field contents in output fields
on the screen, the data sometimes have to be converted
into the output format. To do this, conversion routines
have to be defined in the data elements. If required, these
domain conversions can be made by calling the associated
BAPI.
Fields that are logically related can be grouped to-
gether under one name in structures. Structures are used
in the interfaces as one-line or multiple-line tables. Se-
mantic dependencies between fields in these structures
can be defined in foreign keys. For example, if one struc-
ture contains two fields (plant and company code), then,
depending on the company code specified, the valid
values for plants assigned to that specific company code
35
in the SAP organization model are supplied. The foreign
key dependencies of fields can be used in the interface to
determine which values are valid for dependent fields. The
foreign key checks are frequently used in online applica-
tions to validate input values.
The entire metadata are managed in the ABAP Dic-
tionary and can be fetched using the BAPIs of the busi-
ness objects BAPIService and Helpvalues.
10 Integrated distributed applications through
distributed business objects
An important feature of the R/3 Business Framework is
the distribution of business objects across different sys-
tems. For example, a local production department with
its own R/3 Systems in each plant can be connected to
a central purchasing department. The Business Frame-
work integrates the distributed functions and data into
the global system.
Organization structures in companies may also re-
quire that business processes and tasks are distributed.
Distribution in the SAP Business Framework is based
on Business Components, business objects and the ALE
distribution model. The Components describe which
business functions and processes are related to each other,
for example, all the functions and processes involved in
purchasing. Business objects are distributed in the ALE
Distribution model for the whole system. Business ob-
jects may be distributed according to organization unit,
such as company codes and plants, or they may be dis-
tributed much more specifically according to individual
instances, for example, material numbers.
Before a BAPI can be called, the instance of the busi-
ness object in which the method is to be implemented
must first be determined. The ALE receiver determin-
ation does this and, using the ALE distribution model
and the filter criteria, returns the logical system of the in-
stance. Filter criteria are, for example, organization units
such as company code, and plants. Larger global systems
consist of several systems with their own databases. An
R/3 application system is subdivided into several clients,
whereby each client represents one logical system.
Distributed components can be integrated using loose
coupling or narrow coupling. Narrow coupling is used
for synchronous BAPI calls. Synchronous BAPIs are
narrowly coupled, for example, read BAPIs and check
BAPIs. The advantages of narrow coupling are that data
are current and do not need to be replicated. The disad-
vantages are that the integrated systems must be avail-
able and that access to large datasets involves callers
having to wait. Loose coupling avoids these problems; it
is used for asynchronous BAPI calls and data replication.
ALE technology uses a transactional RFC (remote func-
tion call) to make asynchronous BAPI calls, where the
caller can continue working and does not have to wait
for a response from the system called. ALE technology
36 A. Deimel: The SAP R/3 Business Framework

ensures that the data are transferred securely to the tar-

get system, even if a connection cannot be established Sales,
immediately. Shipping, Finance

Loose coupling also occurs if access to a remote system Invoicing

is avoided by replicating business objects. For this type
APO
of distribution the standardized methods Replicate and
HR
SaveReplica are used. The methods are implemented as
BAPIs of the business objects that are to be distributed.
The method Replicate is executed for the original busi-
ness object and initiates the replication and the associ- Business
Information
ated distribution. SaveReplica stores the replicated busi- ManufactManufactManufact Warehouse

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.

The individual components and systems involved in

11 Example of a distributed application with
several manufacturing plants and central sales
and distribution (“One face to the customer”)
Distributed applications (Fig. 6) can be used in large
companies, such as the chemical industry, high-tech
(semiconductor industry), Consumer packaged goods
(CPG). The company in the example has several manu-
facturing sites, each with their own R/3 installations. The
autonomous Business Component, Advanced Planning
and Optimization (APO) supplies material and product
availability information to the manufacturing plants and
to the central sales and distribution center. The functions
sales, shipping and invoicing handle all customer needs.
Shipping is linked to warehouse management. Invoicing
data is transferred to Finance and to payroll accounting
(HR). Data is continuously transferred to the Business
Component, Business Data Warehousing, where business
reports and trend analyses are produced.
the business processes are integrated through the distri-
bution of business objects. The distribution of business
objects is specified in the ALE distribution model. The
Business Components exchange data via BAPIs, mostly
using asynchronous messaging (loose coupling).
12 Summary
The architecture of the SAP Business Framework is the
basis for the development of SAP R/3 Business Compo-
nents. The architecture is based on an object-orientated
approach using business objects and Business Compo-
nents. Using this architecture together with a distribution
model, distributed applications (distributed business pro-
cesses) can be mapped and implemented. The spectrum
of distributed applications extends from the simple inte-
gration of two components using a few interfaces to the
integration of many components distributed across the
globe.