Business Objects.doc

Introduction 

Use

SAP has introduced object-oriented technology by making SAP processes and data available in the form of SAP business objects.

External applications can access SAP business objects through standardized, platform-independent interfaces - die Business Application Programming Interfaces (BAPIs). The SAP Business Objects and their BAPIs provide an open, object-oriented view of the business processes and data in an SAP System.

This guide provides an overview of the SAP business objects, SAP interface types, and their BAPIs as well as the Business Object Repository where business objects and BAPIs are defined and stored.

Terminology 

Definition

The table below contains definitions of the terms used in this document:

Business Object Types 

Definition

A business object type is the representation of a business entity in the SAP System. It encompasses both the functionality (in the form of methods) and the data (in the form of attributes) of this entity. The implementation details of the business object type are hidden from the user. The business object type is accessed through defined functions (methods). This is referred to as encapsulation.

Business object types are used to break a SAP system down into smaller, disjunctive units. As a result, the system’s 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, both non-SAP systems and the various SAP business components can communication with each other.

Example for a Business Object Type

The business object type FlightBooking represents a legally binding seat reservation for a flight. A special flight booking is identifiable by a booking number and the airline.

You can access the business object type FlightBooking by various methods. These include:

·         FlightBooking.GetList( ) returns a list of all flight bookings stored in the system (optionally restricted according to particular search criteria).

·         FlightBooking.CreateFromData( ) creates a new flight booking in the system.

·         FlightBooking.Cancel() cancels a flight booking that has already been created.

·         FlightBooking.Confirm() converts a flight reservation into a legally binding flight booking.

A business object type therefore comprises a business concept and how to realize it in an SAP System. The term "business object type" corresponds to the term "class" in object-oriented programming languages.
A specific occurrence of a business object type, for example, a flight booking that is actually stored in the system, must be distinguished from the business object type itself. We term this occurrence an instance or a business object (the usual term in object-oriented programming languages).

Example of an Instance:

The flight booking LH 4711 is an instance of the business object type FlightBooking. This flight booking is identified by the airline LH and the booking number 4711.

Note: Airlines maintain their booking numbers in their corresponding airline system. That is why the airline ID is required to uniquely identify a flight booking in any system. The object is described according to its attributes, for example the flight date or the customer number.

Structure of a Business Object Type 

The concept of a business object type is best illustrated by the graphic below:

·          The innermost layer of the SAP business object is the kernel, and represents the object’s 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 object’s 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.

The kernel of a business object type describes the object‘s inner structure, that is its data, and the structure of this data.

A constraint is a rule that ensures the consistency of an object (for example, different pricing conditions are assigned as of a stipulated minimum sales quantity).

Business rules are rules that an object must comply with to ensure it remains consistently embedded in its environment (for example, a sales organization can only sell to a customer for whom business relationship information exists).

The interface provides the pre-defined means of accessing business object types. These can be public attributes, methods/BAPIs and events.

An object can be accessed using COM/DCOM or CORBA. Within ABAP applications, a business object can be accessed by Remote Function Call (RFC).

Integration

Accessing Business Object Types

As above diagram shows, the interface layer separates a business object type’s 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 object’s behavior. When a method is executed on a business object type, the method can change the object’s internal state, that is, the object’s data.

For example, one method that you can use on business object Employee is to "check for the employee’s 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 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 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.

If an application program uses an instance of a business object, the object instance responds only to the set of characteristics and methods defined for its own object type. 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 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 activity 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. BAPIs are examples of such methods.

·         Attributes

An attribute describes a specific property of a business object. For example, Employee.Name is an attribute of the Employee object type.

·         Events

An event signals that the status of a business object has changed.

Inheritance and Polymorphism

One objective and the main benefit of object-oriented technology is software reusability.

The reuse of software code is achieved by deriving new object types from existing ones. When an object type is generated from an existing object type, the new object type is called the subtype and the existing object type is called the supertype. For example, the object type Employee is a subtype which has been derived from the supertype Person. The synonyms subclass and superclass are sometimes used for subtype and supertype.

A subtype inherits all the properties and methods defined for the supertype from which it descends, but can also have additional properties and methods. A subtype may also implement a different behavior for the methods inherited from the supertype. Polymorphism is the term used to describe when the same method triggers different types of behavior in different business object types.

For more information about creating business objects refer to the documentation on SAP Business Workflow.

Defining and Implementing an Object Type

Business objects (object types) are defined and described in the BOR by the following characteristics:

·         Basic data

Comprises the mnemonic object name, the technical name of the object type, its name (meaningful description), its short description, release status, default method, default attribute and the name of the program containing the implementation.

·         Interfaces

Provide a pre-defined interface (attributes, methods, events) for an object. Interface types generally do not contain an implementation.

·         Key fields

Uniquely identify an object.

·         Attributes

(data)
Represent object properties and characteristics.

·         Methods

(functions)
Encapsulate R/3 functionality either by synchronous or asynchronous methods.

·         Events

Indicate the occurrence of a status change of a business object.

Business Object Types and their Key Fields 

Each business object type has one or more key fields. Each instance has a unique combination of values in the key fields and is identified by the specific values in the key fields. This makes it possible to access a specific instance of a business object type via the values in the key fields. The key fields are an important design consideration for a business object.

Example of Key Fields:

In object-oriented programming languages, an object (instance) is normally identified by a technical ID. In the BOR, the concept of key fields permits the SAP business objects to be linked with the underlying relational database.

In most cases, the key fields of an object type are also the key fields in the table containing the header data of the business object type. Since BOR runtime objects are client-independent, the client should not be used as a key field.

Object-Oriented Method Call

Class methods are distinguished from instance methods as concerns a method call in object-oriented programming languages. Class methods do not require an actual instance to exist, and implement functionality across all instances (for example, GetList). An instance method always refers to only one specific instance, and is executed in this instance (GetDetail for instance: AirlineID=LH, ConnectionID= 400, FlightDate= 01.01.2001 from Flight, for example). In this case, first a runtime instance is generated in the system. Any number of instance methods can then be executed for this instance.

This call model is also used by an external client, for example, to access the SAP business object types with Java or Visual Basic via appropriate middleware. In the first step, an actual runtime instance is created that is identified by its key combination (for example, AirlineID=LH, ConnectionID= 400, FlightDate= 01.01.2000 from Flight). Since the call of an instance method relates to precisely this instance, the parameters (key fields) that identify the instance need not be transferred anew. For this reason, the key fields are not explicitly listed as parameters for instance methods in the BOR.

Consequences for the BAPI Interface

The function module implementing the BAPI is functional and cannot make this distinction. Consequently, in the case of instance-dependent BAPIs the key fields must be listed as import parameters in the BAPI function modules.

"Create" methods (for example, create a new FlightBooking) play an additional special role. Since create methods always relate to entities that do not yet exist in the system, they are class methods. After the create BAPI has executed, a runtime instance of this entity is supplied to the calling program. The calling program then continues processing with this instance. For this reason, in the case of create BAPIs, the key is contained in the Export parameters of the function module, but is not listed as a parameter in the BAPI itself (in the BOR).

In general, you need only adhere to the guidelines for key fields in the function module interface, since the other rules are automatically complied with when you use the BOR/BAPI wizard for defining methods in the BOR. The table below recapitulates the conventions applicable to key fields: