Behavior Definition

The Behavior Definition

 

To specify the business object's behavior, the behavior definition of the corresponding development object is used. A business object behavior definition (behavior definition for short) is an ABAP Repository object that describes the behavior of a business object in the context of the ABAP RESTful application programming model. A behavior definition is defined using the Behavior Definition Language (BDL).

 

A behavior definition always refers to a CDS data model. It relies directly on the CDS root entity. One behavior definition refers exactly to one root entity and one CDS root entity has at most one behavior definition (which also handles all included child entities that are included in the composition tree).

Create a New Behavior Definition (1)

 

You can create behavior definitions like any other repository object, that is, using the context menu in the project explorer, starting from the package or from its Core Data Services subnode.

 

However, it is easier to open the context menu on the data definition of the Root CDS View of the RAP Business Object. In this way, some of the properties of the behavior definition are preset by the development tools.

Create a New Behavior Definition (2)

 

When creating a behavior definition, you cannot specify a name for the new repository object directly. Instead, the name of the behavior definition is derived from the name of the CDS View that is used to define the root entity of the business object. For this reason, you must specify the CDS root view at this early stage.

 

You must also specify the implementation type of the business object. The possible values depend on the nature of the related CDS view. For data definition views, you can choose between Managed and Unmanaged. In behavior definitions for projection views, only the Projection implementation type is supported.

Minimal Syntax of Behavior Definition

 

The minimal syntax of a behavior definition includes the implementation type of the business object and the behavior definition of at least one entity, namely the BO root entity.

 

If the implementation type is managed, an additional persistent table is required for each entity of the BO to allow write access to the related database table.

 

For the managed implementation type, it is also mandatory to set a lock type for each entity. The root entity has to be set as lock master.

 

The standard operations (create, update, delete) are part of the template for behavior definitions. They are not mandatory and can be commented or removed if not required.

 

Define the Field Mapping

Field Mapping - Motivation

 

When defining data models, developers often choose to introduce more readable element names in CDS, especially when, for example, the table is legacy and has cryptic short field names, maybe even based on German terminology (examples are BUKRS, KUNNR, and so on).

 

In the figure, Field Mapping - Motivation, the table field names stdat and enddat are replaced by the more readable alias names StartDate and EndDate.

 

Because the field names in the RAP business object are derived from the element names in the related CDS view, the field names in RAP no longer match the field names in the database table.

 

There is no way the RAP framework can determine the table field name in which to store a certain attribute.

 

To allow the persisting of such fields, the developer has to provide the information about which RAP BO field belongs to which table field.

 

This mapping between field names in the RAP BO and database table fields is defined in the behavior definition, using an additional mapping, followed by the name of the database table.