Sap Business Framework

 1998 Springer-Verlag

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: [email protected], 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 (distributed business processes) can be mapped and implemented. The spectrum of distributed applications extends from the simple integration of two components using a few interfaces to the integration of many components 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 System from SAP AG offers standard software for individual solutions in virtually all branches of commerce and industry. 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 simultaneous upgrading of other Components. – Business processes are structured and encapsulated in business objects and are accessed via BAPIs (Business

Application Programming Interfaces) – precisely defined interfaces for these business objects. – SAP partners and third party vendors can integrate the Business Components using standardized interfaces that support the open R/3 System. – New applications can easily be implemented in various development environments, and front-end development 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 system. 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 business functions and consist of business objects. For example, the Business Component Human Resources contains the business objects Employee, Applicant, Payroll, etc. Business processes are implemented either within one Business Component or across several Business Components (distributed business processes).

30

A. Deimel: The SAP R/3 Business Framework

SAP R/3

Business Component BAPI Business Object

(Distributed) Business Processes

BAPI BAPI

Application Link Enabling (ALE) SAP Remote Function Call (RFC)

(D)COM

CORBA

Services for integrating Business Process and distributing Business Objects Communication Services

Fig. 1. SAP Business Framework architecture

The object-oriented structure of R/3 is based on business objects that encapsulate business data and functions. All the business objects are managed in the Business Object Repository (BOR). BAPIs are interfaces for business objects that can be called from external programs. Together with the business 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 executed 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 • Web • Desktop

R/3 Application Server R/3 Application Server Business Component

Non R/3-Systems

• MS Visual Basic, C++ • IBM VisualAge/Java • MS NT, Unix, OS/2 ...

BAPI BAPI

Business Object

BAPI

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

R/3 Database Server

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 CORBA/Java is based on the object-oriented structure of R/3 functions (business objects and their BAPIs). The interface metadata (Interface Definition Language) enables object-oriented access to business objects in the Business Object Repository via DCOM and CORBA connections. With DCOM and CORBA connections the use of BAPIs on different platforms is especially straightforward. SAP’s internal communication technology is SAP Remote Function Call (SAP RFC). The RFC handles the system-dependent data conversion and the physical transfer of the data. RFC calls may be synchronous or transactionally asynchronous. With synchronous 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 architecture (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 permit the development of business transactions for various front-ends, such as Internet Application Components (IAC), MS Visual Basic/ActiveX, Java, and various 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 instances. You can visualize the SAP Business Objects as black boxes that encapsulate R/3 data and business processes, thus hiding the details of the structure and implementation of the underlying data. To achieve this encapsulation, the SAP Business Objects 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

Inherent Data

Access Attributes Business Rules, Methods Constraints

BAPIs

COM/DCOM, RFC, JAVA, 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 object. 3. The third layer, the interface layer, describes the implementation and structure of the SAP Business Object 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 object class, depending on the nature and general characteristics 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 individual SAP Business Object is a representation, or instance, 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 instances 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:

volved: defining the interface in the BOR and implementing the BAPI in the Function Builder (Fig. 4). Business object types are assigned to Components in the Business Object Repository. For instance, all the Human Resources (HR) objects are assigned to the HR Component. The BOR manages versions and the release status of BAPIs and business objects. A BAPI is defined by its import and export parameters. BAPI methods relating 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 customer 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 systems. Function modules are executable programs with defined interfaces; they are stored in the SAP Function Builder. These function modules are assigned to business 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 concept 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 function module correspond to the parameters in the BAPI. Both mandatory and optional parameters can be defined. The caller must define the mandatory parameters. Parameters 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

– Object type The object type describes the features common to all instances of that object type. This includes information 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 identifying 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 object 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 example, Employee.Name is an attribute of the Employee 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-

BAPI A

Business Object Type

„Object Layer“ BAPI B BAPI C

Function Module impl. BAPI A Function Module impl. BAPI B Function Module impl. BAPI C

Business Object Repository (BOR)

Definition of Object Types and BAPIs

Function Builder Implementation of Object Types and BAPIs

Fig. 4. Defining and implementing business object types and BAPIs

A. Deimel: The SAP R/3 Business Framework

BAPIs are called, the RFC (remote function call) converts the data between the different system platforms. BAPI documentation is an essential part of the implementation. The documentation describes the functions of the BAPI and the functions of all the parameters. If parameters 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 implemented 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 environment.

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 control 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 System 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 receiver of the employee master data. The interface type is defined as a method in the Business Object Repository 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 interface 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 Human Resources

Non-SAP System Inbound

Outbound Interface Type

33

BAPI (Outbound) “Receiver of Employee MasterData”

EmployeeMasterData Receiver Method of Interface Type: ReceiveMasterData

The Object Class of the non-SAP System Implements the Interface

Inbound Object Type ManagerExternal PersonalTimeEvents

Outbound

BAPI (Inbound) 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 precise definition of the component boundary of SAP Business Components.

7 Standardized interfaces and BAPI Change Management BAPIs aim to provide a standardized interface. The granularity 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 modifications made to the interface. Standardizing fields, for example, mapping personnel and material numbers are based on SAP’s and SAP partners’ long-standing experience in developing business applications. Interface parameters and fields are standardized 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 higherlevel functionality, such as methods and business objects. Domain standardization is the most important type of interface 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 standardized. 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 standardized BAPIs for business objects. The BAPIs CreateMultiple and ChangeMultiple are used to request mass data. The BAPIs Replicate, SaveReplica and SaveReplicaMultiple are used to clone data. Standardization at the business object level occurs because business objects map important general data, such as Employee, Equipment, PurchaseRequisition and SalesOrder, from a business environment. Business objects have precisely defined names and they map business functions 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 central sales and distribution are described in integration scenarios. Stable interfaces are essential for BAPI standardization. If incompatible enhancements are made to inter-

faces, the programs and Components that call these interfaces 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. Compatible 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 incompatible enhancement is made, an additional BAPI has to be created. The BAPI is given the same name with a number 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 “expiring” 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 supported and is deleted. A freezing procedure ensures that the BAPI is downward compatible to the interfaces used in the Business Framework. BAPIs are frozen when they are released; this procedure requires syntax-compatible interface enhancements. 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 implemented 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 processing steps so that no inconsistent datasets are created for a business object. In the transaction model, a transaction 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 interface. 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 address 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 resets the database to its status in the last commit call. Users can execute several transactions in the same terminal 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 assigned. 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. Customers 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 standardized 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, headers and explanations for the help function, proves of great benefit when using the interfaces (for example, for desktop development). These texts are supplied in several languages and can be retrieved from the information provided 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 together under one name in structures. Structures are used in the interfaces as one-line or multiple-line tables. Semantic dependencies between fields in these structures can be defined in foreign keys. For example, if one structure 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 applications to validate input values. The entire metadata are managed in the ABAP Dictionary and can be fetched using the BAPIs of the business 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 systems. 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 Framework integrates the distributed functions and data into the global system. Organization structures in companies may also require 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 objects may be distributed according to organization unit, such as company codes and plants, or they may be distributed much more specifically according to individual instances, for example, material numbers. Before a BAPI can be called, the instance of the business object in which the method is to be implemented must first be determined. The ALE receiver determination does this and, using the ALE distribution model and the filter criteria, returns the logical system of the instance. 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 disadvantages are that the integrated systems must be available 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 function 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 target system, even if a connection cannot be established immediately. Loose coupling also occurs if access to a remote system is avoided by replicating business objects. For this type of distribution the standardized methods Replicate and 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 business object and initiates the replication and the associated distribution. SaveReplica stores the replicated business object in the receiving system. The replication can be initiated by the system containing the original business object with a push operation or by the receiving system with a pull operation. When business objects are distributed with replication, all the logical systems involved are specified in the ALE distribution model. These are the 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.

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

Sales, Shipping, Invoicing

Finance

APO

HR

ManufactManufactManufact uring uring uring 3 2 1

Business Information Warehouse

WM for shipping

Fig. 6. Integration scenario with decentral production and shared sales and distribution

The individual components and systems involved in the business processes are integrated through the distribution 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 Components. 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 (distributed business processes) can be mapped and implemented. The spectrum of distributed applications extends from the simple integration of two components using a few interfaces to the integration of many components distributed across the globe.