Get to Know RAP: Enhance Behavior With Action and Validation

[Mamikee]

Welcome back to the series! We're already halfway through it, and I hope you're finding it informative and helpful. In our previous blog post, we walked through the process of creating a CDS behavior definition for a managed travel business object. We covered the steps to define the behavior for the travel entity, as well as creating the behavior definition projection.

In this blog post, we'll dive deeper into enhancing the behavior definition of the business object. We will go over the steps to add determinations, validations, and actions to your business object behavior definition. But before we get into that, we'll go over the Entity Manipulation Language (EML). You'll need to understand EML to be able to add determinations, validations, or actions to your business object behavior definition.

Entity Manipulation Language (EML)

The Entity Manipulation Language (EML) is a key part of the ABAP language that lets you interact with your own and other business objects using SQL-like syntax. The EML also provides API-based access to other RAP business objects.

EML is useful for handling entities, which are the objects defined in the Business Definition (BDEF). It offers several operations to manipulate these entities, including read, create, update, delete, and execute. You can also use EML for data and transaction development scenarios in a type-safe manner, which is the most common use case. If you're developing your frameworks, you can use the generic EML API for generic implementation.

In short, EML provides developers with the flexibility to perform various operations on business objects with ease, making it an essential tool for developing complex business applications.

Let’s go over the operations:

Read Operation: This operation allows you to retrieve data from an entity. This operation allows for the transactional read of business object instances, meaning that the read takes place from the transactional buffer. By default, all EML statements are mass enabled, which means that you can retrieve data for a set of instances with a single EML column. To perform the read operation, you will need to specify a table of keys for which you want to retrieve the data.

METHOD validate_customer.



    READ ENTITY zi_travel_m_708\\travel FROM VALUE #(

        FOR <root_key> IN keys ( %key-mykey     = <root_key>-mykey

                                 %control = VALUE #( customer_id = if_abap_behv=>mk-on ) ) )

        RESULT DATA(lt_travel).

Modify Create Operation: This operation is used to create root instances through the create by association. All EML operations are carried out in the transactional buffer, which means they are only stored in the database when the commit entity is executed. This allows you to create multiple instances of a business object in one go, without any changes being committed until the entire transaction is complete.

Modify Update Operation: This operation allows you to update existing instances of a business object. With this operation, you can even update instances that were created previously but have not yet been saved to the database. To use this feature, you'll need to leverage the Content ID, which uniquely identifies the instance you want to update. By using this ID, you can make sure that the changes you make are applied to the correct instance.

MODIFY ENTITIES OF zi_travel_m_708 IN LOCAL MODE

         ENTITY travel

            UPDATE FROM VALUE #( FOR key IN keys ( mykey = key-mykey

                                                   overall_status = 'A' " Accepted

                                                   %control-overall_status = if_abap_behv=>mk-on ) )

         FAILED   failed

         REPORTED reported.



  " Read changed data for action result

  READ ENTITIES OF zi_travel_m_708 IN LOCAL MODE

       ENTITY travel

       FROM VALUE #( FOR key IN keys (  mykey = key-mykey

                                        %control = VALUE #(

                                          agency_id       = if_abap_behv=>mk-on

                                          customer_id     = if_abap_behv=>mk-on

                                          begin_date      = if_abap_behv=>mk-on

                                          end_date        = if_abap_behv=>mk-on

                                          booking_fee     = if_abap_behv=>mk-on

                                          total_price     = if_abap_behv=>mk-on

                                          currency_code   = if_abap_behv=>mk-on

                                          overall_status  = if_abap_behv=>mk-on

                                          description     = if_abap_behv=>mk-on

                                          created_by      = if_abap_behv=>mk-on

Modify Delete is used to delete instances.

Modify Execute Operation: This EML operation allows you to execute actions on business object instances. You simply need to specify the action to be executed and provide the necessary parameters. This can be useful when you want to trigger a specific action on a business object instance, such as updating a status or sending a notification. Remember that all EML statements are executed on the transactional buffer and only persisted through the database when the commit entity is performed.

MODIFY ENTITIES OF zi_travel_m_708 IN LOCAL MODE

         ENTITY travel

            UPDATE FROM VALUE #( FOR key IN keys ( mykey = key-mykey

                                                   overall_status = 'A' " Accepted

                                                   %control-overall_status = if_abap_behv=>mk-on ) )

Now that we have a basic understanding of EML and its role in developing transactional apps quickly and efficiently, let's go over the steps to enhance the behavior definition of the business object by defining determinations, validations, and actions.

Adding Determinations, Actions, and Validations

Entity Manipulation Language (EML) is a powerful tool in ABAP programming that allows you to customize and control the behavior of business objects. One of the primary ways it does this is through determinations, actions, and validations.

A determination is like a database trigger that automatically changes a business object based on some internal logic. It’s assigned to a node and gets executed by the RAP framework as soon as the trigger condition is met. The condition is checked at different points during the transaction, depending on the pattern of the determination.

Actions, on the other hand,  are entities that refer to specific actions non standard operation, so something other than the standard operations create, update, delete. For example, suppose you have an order object with an attribute for the order status. In this case, you could create an action that sets the order status to “shipped” when the order is fulfilled.

Validation A validation is an optional part of the business object behavior that checks the consistency of business object instances based on trigger conditions.

Note: To learn more about defining determinations, validations, and actions here is a link to SAP documentation: https://help.sap.com/docs/btp/sap-abap-restful-application-programming-model/validations

Enhancing Behavior Definition

In the tutorial, we added more functionality to our business object by defining determinations, validations, and actions.

To get started, we had to switch to our behavior definition ZI_TRAVEL_M_708 and replace our previous code with the new code provided. As always, we'll go over what changes were made in the code.

managed implementation in class ZBP_I_TRAVEL_M_708 unique;



define behavior for ZI_TRAVEL_M_708 alias Travel

persistent table ztravel_000

etag master last_changed_at

lock master

{

  // key that will be automatically generated by the framework

  field ( readonly, numbering : managed ) mykey;



  // semantic key 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;



  // instance action and dynamic action control

  action ( features : instance ) acceptTravel result [1] $self;



  // validations

  validation validateCustomer on save { field customer_id; }

  validation validateDates on save { field begin_date, end_date; }

  validation validateAgency on save

  { field agency_id; }



  // determination

  determination CalculateTravelKey on modify

  { create; }



}

Code Explanation: 

• The fields of the business object are defined by adding static field controls, setting the fields travel_id, mykey, and the administrative fields to readonly.


• The remaining fields are then set as mandatory, meaning that they must be filled in during creation.


• The numbering: managed is used to define the key field that is automatically generated by the framework.


• The standard operations for the business object, namely create, update, and delete, are defined using the respective keywords. 


• The action is an instance action by default. The features: instance specifies that the action can be activated or de-activated based on the status of the instance.


• $self means that the instance of the same type is returned on which the operation is performed – here a travel instance.


• The validation is used to define validations that are executed when the business object is saved. The validateCustomer validation checks the customer_id field, the validateDates validation checks the begin_date and end_date fields, and the validateAgency validation checks the agency_id field.


• The determination is used to define a determination named CalculateTravelKey. This determination is executed when the business object is modified and creates a new key for the travel entity.

Next, we needed to enhance the behavior definition for the projection view. We switched to our behavior definition ZC_TRAVEL_M_000 and replaced the existing code with the following:

projection;



define behavior for ZC_TRAVEL_M_708 alias TravelProcessor

use etag

{

  use create;

  use update;

  use delete;



  use action acceptTravel;

}

The use action acceptTravel  is used to indicate that the behavior definition should support an action named acceptTravel. This is an instance-level action that was defined in the previous behavior definition. By using actions your are able to change the status of your booking status.

Implementing the Business Object Behavior

Now that we have enhanced the business object behavior and projected the relevant enhancement through our projection behavior definition, we will proceed with the implementation. The area we are working on is shown in the development flow below.

RAP Development Flow

To generate the behavior implementation classes for the business object node travel, we will use the ABAP development tools (ADT) support. To do this, simply go into the behavior definition ZI_Travel_M_000 and set the cursor before the implementation class ZBP_I_TRAVEL_M_000. From there, you can create a behavior implementation class by selecting Create Behavior Implementation Class.

You will then need to set the description as "Behavior Implementation for ZI_TRAVEL_M_000" as stated in the tutorial. The description should be automatically filled in for you. This will generate the behavior implementation class that corresponds to the business object node travel.

In the next steps of the tutorial, we will be enhancing the implementation of our code. The first step is to implement a validation to check that each agency ID is valid. Then, we will add two more validation methods - validate_customer and validate_dates. After that, we will implement an action and a determination. Once all of these steps are completed, your code should look like the example given in the tutorial.

Note: It may take some time to get the accept travel button to appear. I highly recommend activating the service binding and making sure to add a space anywhere you want in your data definition ZI_TRAVEL_M_000 and behavior definition ZI_TRAVEL_M_000. Activate both and open your SAP Fiori preview again. It takes 120 seconds to make the buttons visible on the user interface. If these steps do not work, try going over the previous steps again. There might be a grammatical error in the code that needs to be corrected.

Your result should look like this:

The behavior implementation has been created for travel booking, and the managed approach is being used to handle the implementation of create, update, and delete automatically. This approach makes it easier to manage and manipulate data related to travel bookings.

Once the implementation is complete, you will be able to see the "Accept Travel" button, which allows you to create a new travel booking with the booking status "O" for "open". After saving the travel booking, you can then accept it by clicking the "Accept Travel" button. This will update the booking status to "A" for "accepted". This feature allows you to easily keep track of the status of your travel bookings and take appropriate action as needed. 

What’s Next:

In this blog post, we learned about Entity Manipulation Language (EML) and how it can be used to manipulate business objects. We went over the several operations that EML offers to manipulate entities, including read, create, update, delete, and execute, making it an essential tool for developing complex business applications. We then went over the steps to add determinations, actions, and validations to the behavior definition of the business object. 

Finally, we defined determinations, validations, and actions. With these enhancements, we were able to create a new travel booking and accept it, which allowed us to easily keep track of the status of the travel bookings and take appropriate action as needed.

In our next and final blog post of this series, we're going to create a SAP Fiori app for a RAP business object right from the comfort of your SAP BTP, ABAP Environment in SAP Business Application Studio. We're also going to go through the process of deploying it to SAP BTP, ABAP Environment. 

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

Get to Know RAP: CDS Behavior Definition