Preface – This post is part of the SAP ABAP RAP series.

Introduction

A Business Objects in enterprise development represents a real-time artifact such as SalesOrder, Info Record. It contains several nodes such as Item, Bidders and transactional operations like create, update, delete of business data as well as application-specific operations like submit, reject.

Category of Business Objects

Business objects are categorized by:

• Structure
• Behaviour
• Runtime implementations

1.      Structure

A business object is tree-structured, where a top node is represented as root and sub-nodes are represented as child nodes. The nodes are connected with a special kind of associations and compositions. Each node element is modelled with a CDS entity.

Figure 1: Composition tree reflects the Structure of Business Object

2.      Behaviour of Business Objects

The behaviour definition refers to the root entity of the CDS data model. The relationship is [0..1] i.e. one CDS root entity can have at most one behaviour definition, and one behaviour definition can refer to exactly one root entity.

The supported operations of business objects are defined in behaviour definitions. These operations include:

• Standard operations like CREATE, UPDATE, DELETE
• Business Object specific operations with dedicated input/ output structures. These types of operations are called actions. Examples: SUBMIT, REJECT, CANCEL, PUBLISH.

Behaviour definitions also include the information about the lock, numbering type (late numbering/ early numbering), read-only/mandatory fields of CDS entities.

Figure 2: Relationship between CDS Entities and Business Object Behaviour

3.      Business Object runtime implementation

In SAP ABAP RAP, saving the data to the database is performed in two phases: INTERACTION phase and SAVE phase.

In the INTERACTION phase, the consumer calls the supported operations (like CUD) to change the data or to read the data. These changes are stored in internal TRANSACTIONAL buffers which represents the state of instance data. Once the changes are stored in buffers, the SAVE sequence phase is performed to save the changes from the transactional buffer to the database.

The SAVE sequence consists of sequence of methods (finalise(), check_before_save(), adjust_numbers(), save(), cleanup(), cleanup_finalise()) which are executed to persist the changes. In the next section we will dig deep into runtime implementations.

Figure 3: BO’s Runtime Implementation