Welcome back to our ongoing series on getting to know RAP!

In the previous blog post, we went over the steps on how to create a CDS data model and how to project this data into an OData service. Additionally, we also showed how to consume this data model using the SAP Fiori elements app preview.

In this blog post, we will dive into creating a behavior definition and implementation for a managed scenario. The behavior definition is a crucial aspect of any CDS data model as it defines the actions that can be performed on the data, such as creating, updating, and deleting records.

To create the behavior definition, we will utilize the context menu in the root CDS interface view that was created in the previous blog post. This allows us to quickly and easily define the desired behaviors for our travel booking data. We will also go over the steps to implement these behaviors and how they can be used in the SAP Fiori elements app preview.

RAP Development Flow

Behavior Definition

Behavior definitions are a crucial part of our CDS data models because they determine what we can do with our data. The tutorial walks you through the process of creating a behavior definition for the root CDS view, which will apply to all the entities within it.

To create a behavior definition, simply right-click on the data definition ZI_TRAVEL_M_000 and choose “New Behavior Definition.” It’s worth mentioning that in this case, we’re working with a managed implementation, so make sure the implementation type is set to “Managed” and that the name of the behavior definition is exactly the same as the root CDS view.

Once you’ve created the behavior definition, you’ll see that it is automatically generated based on the implementation type you selected. Now, let’s take a look at the code that we’re asked to replace.

managed implementation in class zbp_i_travel_m_000 unique;

define behavior for ZI_TRAVEL_M_000 alias Travel
persistent table ztravel_000
etag master last_changed_at
lock master
{

  // semantic key is calculated in a determination
  field ( readonly ) travel_id;

  // administrative fields (read only)
  field ( readonly ) last_changed_at, last_changed_by, created_at, created_by;

  // mandatory fields that are required to create a travel
  field ( mandatory ) agency_id, overall_status, booking_fee, currency_code;

  // mandatory fields that are required to create a travel
  field ( mandatory ) Begin_Date, End_Date, Customer_ID;

  // standard operations for travel entity
  create;
  update;
  delete;
}  

Code Explanation 

1. First we assign an alias to the travel entity and specify the persistency by indicating the corresponding database table. This allows the managed runtime to perform create, update, and delete operations directly on the database table.
2. The etag master last_changed_at is used to manage versioning of the data stored in the table. It records the time and date when a change was made to the data, enabling us to track changes over time. We then specified the lock master for the root entity. The lock master is used to ensure data consistency by locking the data while it is being updated. This prevents other processes from accessing or modifying the data until the update is complete.
3. The semantic key TRAVEL_ID is calculated in a determination and is read-only, meaning that its value cannot be changed by the user. You can think of it like a serial number – you can’t change it once it’s assigned.
4. The administrative fields last_changed_at, last_changed_by, created_at, and created_by are also read-only and provide information about when the data was last changed and by whom.
5. The fields agency_id, overall_status, booking_fee, and currency_code are mandatory fields that are required to create a travel booking. Additionally, Begin_Date, End_Date, and Customer_ID are also mandatory fields that must be provided in order to create a travel booking. These fields help ensure that the necessary information is provided for each travel booking, making it easier to manage and keep track of the data.

After making the necessary additions to the code, it is important to save and activate the changes to take effect.You may encounter a warning message during this process, but it should be resolved once the behavior implementation has been successfully created. This step is key to making sure the changes we made take effect and are ready for use.

Behavior Definition For Projection View 

So, we’ve set up the behavior definition for our managed travel business object and given it the behaviors we want for the travel entity. Now, it’s time to move on to the next step: the behavior projection. This is just a fancy way of mapping the transactional abilities from the base behavior definition. All we gotta do is create another behavior definition based on the root CDS projection view we made earlier. This view is a representation of the base behavior definition, and it’s where we can get even more specific with the transactional abilities we want for our travel entity.

RAP Development Flow

Projections are a way to simplify data access and manipulation in RAP. They allow you to present data in a specific format that makes it easier for users to understand and work with. Just like we did before, we’ll right-click on the data definition ZC_TRAVEL_M_000 and select “New Behavior Definition”.

Once you have assigned a transport request and clicked finish, you’ll notice that the behavior definition is set based on the implementation type you selected earlier. Now, it’s time to replace the code with the following:

projection;

define behavior for ZC_TRAVEL_M_000 alias TravelProcessor
use etag
{
  use create;
  use update;
  use delete;
}

Code Explanation:

1. We start by defining an alias for the travel entity.
2. The next step is to enable ETag handling. The use of ETags helps ensure that the user is always working with the latest version of the data. This is because whenever the user performs create, update, or delete operations on the projection, the data in the underlying entity will also be updated. The ETags also help prevent conflicts in case multiple users are working with the same data simultaneously.

Projections in ABAP RAP are a convenient way to access and manipulate data. They guarantee that the data you’re working with is always accurate and up-to-date.

After you’ve added the code, saved and activated it, you should switch to the service binding, activate the service for ZUIC_C_TRAVEL_M_000, and double-click on TravelProcessor to start the preview. Be sure to refresh the application and click “GO”. Note that in the trial environment, it may take a while for the changes to be reflected.

Once the changes are reflected, you will see that the create, update, and delete operations are now enabled, allowing you to play around with the application.

What’s Next:

In this blog post, I have guided you through the process of creating a behavior definition for a managed travel business object. We went over the steps to define the behavior for the travel entity, followed by creating the behavior definition projection. In the next blog post, we will dive deeper into enhancing the behavior definition and implementation by adding actions and validations.

Previous Blog Post:

Get to Know RAP: Introduction

Get to Know RAP: Define Data Model – Part 1

Get to Know RAP: Define CDS-based data model