Defining Business Objects and their Behavior

Objectives

After completing this lesson, you will be able to:

Create a CDS behavior definition.
Generate a behavior implementation class.
Create a CDS behavior projection.

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

Steps to create a new behavior definition

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 view of the business object and choose New Behavior Definition. In this way, the Root Entity field is prefilled by the development tool.

Further steps to create a new behavior definition

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.

The template for a behavior definition includes the implementation type of the business object and the behavior definition for the chosen root entity.

It also contains the strict( 2); statement which affects the strictness of the syntax check. It is possible but not recommended to remove the strict( 2 ) statement or replace it with the strict; statement to slacken the syntax checks. This should only be done in code that has to be compatible with older releases.

Caution

For new developments, you can always keep the syntax version suggested by the template. It ensures the strictest syntax rules and the highest code quality.

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. The template already contains this statement. The persistent table is derived from the definition of the CDS view entity.

For the managed implementation type, it is also mandatory to set a lock type and an authorization type for each entity. The root entity is always used as lock master and authorization 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.

The template also inserts a field ( readonly ) statement for all key fields of the view. To prevent changes to the primary key.

Note

Making the key fields read-only requires a way to set their values during the create operation. We discuss various numbering techniques later in this course.

Field Mapping

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, the table field names begin_date and end_date are replaced by the alias names BeginDate 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 that the RAP framework can determine the table field name in which to store a certain entity element.

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 keyword mapping for, followed by the name of the database table.

In the most complete form, the mapping contains a full list of all field names, with the CDS element names on the left and the database table field names on the right.

Note

The assignment is also required for fields like Description and Status, even though the names are the same, apart from differences in upper/lower case.

Field Mapping with the CORRESPONDING addition

By adding thecorresponding keyword, the framework implicitly maps all fields for which the view element name and the database table name only differ in upper or lower case. Then, only the fields for which this is not the case need explicit mapping.

Note

For the case where all field names are identical (apart from upper or lower case), you can use the following short form to define the field mapping: mapping for <…> corresponding;

The Behavior Pool

Implementation of transactional behavior

The transactional behavior of a business object is implemented in one or more global ABAP classes. These special classes are called behavior pools and they are dedicated only to implementing the business object's behavior and are called behavior pools. You can assign any number of behavior pools to a behavior definition. Within a single global class, you can define multiple local classes that handle the business object's behavior. The global class is just a container and is empty, while the actual behavior logic is implemented in the local classes.

You specify a behavior pool for the RAP business object by adding implementation in class <ClassName> unique to the behavior definition header (statement managed or unmanaged). The mandatory addition unique defines that each operation can be implemented exactly once.

The recommended name for behavior pools starts with BP_ (or<namespace>BP_), followed by the name of the RAP business object.

Note

By adding the preceding syntax to the behavior definition header, you define one behavior pool for the entire RAP BO. In more complex scenarios that is with business objects that consist of many entities, you can define behavior pools for individual entities. You do so by adding the syntax to the define behavior for statement.

If the ABAP class the behavior definition refers to, does not yet exist, the editor displays a warning. You can create the ABAP class using a quick fix.

This quick fix creates the class pool and generates the required local class or local classes. If the behavior definition already contains statements that require implementation, the quick fix also generates the required methods.

Caution

To invoke the quick fix, the behavior definition has to be saved and activated.

Behavior Projection

The business object itself defines and implements the behavior in general, that is, the business logic for the data provided by the data model. The BO Projection defines only the behavior that is relevant for the specific consumer, for example the UI service.

The projection behavior definition delegates to the underlying layer. The implementation of the individual characteristics is only done in the general business object.

Note

Although the behavior projection is built on top of the behavior definition of the business object, it does not refer to it directly. Instead, the behavior projection references the projection views, which are built on top of the data model views, which in turn are referenced by the behavior definition.

Steps to create a new behavior projection

The procedure to create a behavior projection is identical to the creation of a behavior definition. The only difference is that you create the repository object based on the projection view of a root entity rather than the data model view.

When you create a behavior definition based on a projection root view, it is not possible to choose implementation types managed or unmanaged. Instead, you can choose between Projection and Interface. Here you decide whether you want to create a BO Projection for consumption in a business service or a stable BO Interface.

The minimal syntax of a behavior projection consists of the projection keyword and the behavior definition for at least one projection view that is the projection view of the root entity.

If the behavior definition of an entity contains standard operations (create, update, delete), the template for behavior projections adds the standard operations to the projection by default. They are not mandatory and can be commented out or removed, if not required.

Behavior definitions for BO interfaces are identified by the interface keyword at the beginning. The strict( 2 ) addition is missing because in interface views, always the strict syntax rules apply.

Define a Business Object and Its Behavior

In this exercise, you define a Business Object (BO) by extending your CDS-based data model with a CDS behavior definition. You then extend your data model projection with a CDS behavior projection, to make the behavior of the BO visible to your OData UI Service.

Note

In this exercise, replace ## with your group number.

Solution

Repository Object Type	Repository Object ID
CDS Behavior Definition (Model)	/LRN/437B_R_TRAVEL
CDS Behavior Definition (Projection)	/LRN/437B_C_TRAVEL
ABAP Class	/LRN/BP_437B_R_TRAVEL

Task 1: Create a CDS Behavior Definition

Create a CDS behavior definition that defines the behavior of a Business Object (BO) with your data model view entity Z##_R_Travel as the root entity. Define the field mapping and create the behavior implementation class.

Hint

Use the New Behavior Definition wizard from the context menu of the Project Explorer. This creates the behavior definition based on a template.

Steps

Create a CDS behavior definition for your Z##_R_Travel data model view. Assign the new repository object to your own package and use the same transport request as before.
1. In the Project Explorer view on the left, open the context menu for the data definition of your data model view.
2. From the context menu, select New Behavior Definition.
3. Enter a description and confirm the suggested Implementation Type, Managed. Choose Next. Note that you cannot change the suggested name of the new behavior definition.
4. Select the same transport request as before and choose Finish.
Perform a syntax check for the new behavior definition.
1. Press Ctrl + F2 and analyze the Problems tab below the source code editor.
Enable persistence for all elements of your data model by defining the mapping between table field names and CDS view element names.
1. Within the curly brackets of the behavior definition, add the keyword mapping for followed by the name of your database table, addition corresponding, and a pair of curly brackets.
2. Within the curly brackets, list all view elements and table fields that differ in more than just uppercase or lowercase.
3. Add the following code:
  Code Snippet
```
12345678910
mapping for z##_travel corresponding
    {
      AgencyID    = agency_id;
      TravelID    = travel_id;
      CustomerID  = customer_id;
      BeginDate   = begin_date;
      EndDate     = end_date;
      ChangedAt   = changed_at;
      ChangedBy   = changed_by;
    }
```
Use a quick fix to generate the behavior implementation class.
Hint
To use this quick fix, it is mandatory that the behavior definition is saved and active.
1. Press Ctrl + F3 to activate the behavior definition.
2. Right-click the name of the class and select Quick Fix. Alternatively, choose the warning icon next to statement managed.
3. Double-click Create behavior implementation class zbp_##_r_travel.
4. Enter a description and choose Next.
5. Select the same transport request as before and choose Finish.
Activate the behavior implementation class.
1. Press Ctrl + F3 to activate the development object.

Task 2: Create a CDS Behavior Projection

Create a CDS behavior definition that defines the behavior of your projection view Z##_C_Travel and makes the behavior of the Business Object visible for your OData UI service.

Hint

Use the New Behavior Definition wizard from the context menu of the Project Explorer. This creates the behavior definition based on a template.

Steps

Use the context menu in the Project Explorer to create a CDS behavior definition for your projection view Z##_C_Travel. Assign it to your own package and use the same transport request as before.
1. In the Project Explorer view on the left, open the context menu for the data definition of your projection view.
2. From the context menu, select New Behavior Definition.
3. Enter a description, confirm the Implementation TypeProjection and choose Next. Note that you cannot change the suggested name of the new behavior definition.
4. Select the same transport request as before and choose Finish.
Activate the CDS behavior definition.
1. Press Ctrl + F3.
Refresh the preview of the service as SAP Fiori elements app.
Hint
If you want, play around with the new functions a bit, but remember that the behavior definition is still incomplete and that the Business Object does not yet ensure data consistency. For example, the BO does not yet provide a unique primary key when you create a new travel. If needed, execute ABAP class ZCL_##_TRAVEL_FILL again to delete and regenerate the sample data.
1. If the browser window with the preview of the SAP Fiori elements app is still open, reload the page, otherwise open your service binding, choose the name of your projection view and choose Preview....

Next lesson