A practical guide to ABAP RAP: Part 4

Hello Technophiles!!

Welcome to the fourth part of our blog series on ABAP RAP. In the first three parts, we discussed various programming models of ABAP, learned about ABAP RAP, divided the scenario into eight steps, and implemented the first four steps of our solution. If you haven’t gone through our previous blog, we recommend you to first go through the same, understand the scenario and implement those steps mentioned here.

In this post, we are going to discuss the fifth step:

1. Creation of a package for storing project resources.
2. Creation of three tables along with a data element which will be used across these tables..
   1. Employee information: to store basic information about an employee.
   2. Employment information: to store employment components like date of joining and salary.
   3. Position information: to store position related information (this will be used as Value help/Check Table).
3. Creation of a CDS interface view for creating a basic view without any extensive information which can be used by various services.
4. Creation of a CDS Projection view exposing a subset element of CDS interface view. It is service agnostic.
5. Creation of metadata extension for UI elements and Creation of Behavior definition and projection for defining the action possible on the service. Example- Create, Update, Delete, determination etc.
6. Creation of Behavior implementation for writing the business logic related to action such as validation, action and determination.
7. Creation of Binding service for defining the protocol used by the service. Example- OData V2 – UI, OData V2 – WebAPI etc.
8. Expose the service.

Metadata Extension

Most of you might already know what metadata is, but for those who don’t know, here is a quick overview:

Metadata helps to organize and find data by containing a description of the same. In short, metadata is data about data.

For example, when you save a document, it contains title, created by, creation time, last modified, etc. This tells us about all the details of the document created and keeps a check as to when changes were made, by whom, and when.

So basically, metadata extension is a way of extending a CDS entity with CDS annotations that are not defined in the CDS source code.

In the context of ABAP RAP, metadata extension helps in defining the UI-related CDS annotations in a separate CDS source code which can be transported and activated independently of the CDS entity for which it is being defined. This support of separation of concerns(SoC) concepts allows better readability of the CDS source code.

What if I don’t add metadata extension?

If you don’t add metadata extension, then when the UI appears, you’ll have to manually select the columns you want to display. This extra step is avoided if the metadata is present. The UI will automatically pick the data and the fields which are to be shown.

Behavior Definition

Let’s first see what ‘behavior’ means according to Google –

noun: behavior

the way in which one acts or conducts oneself, especially towards others.

Now let’s say you are at a party and the organizers seem very happy and pleased by you joining them. How would you describe their behavior towards you? You may say that they are showing very pleasant and polite behavior. As humans, we all show behaviors at all times. ABAP RAP is no different. It displays behaviors too and for displaying that, it requires a behavior definition.

A behavior definition is an ABAP repository object which represents the behavior of business objects in the context of ABAP RAP. It always refers to a CDS data model and relies directly on the CDS root entity. Behavior definitions for a given composition model are created for the root CDS view and contain the definition of all the entities.

---

Since we now know what metadata extension and behavior definition is, it is safe to proceed with the creation of both of these.

Step 5: Creation of metadata extension for UI elements and Creation of Behavior definition and projection for defining the action possible on the service. Example- Create, Update, Delete, determination, etc.

5.1 Metadata Extension for ZC_RAP_E2E_AEMP

💡 A prerequisite for extending a CDS entity with metadata extensions is that the annotation Metadata.allowExtensions with the default value true is specified in the DDL source code of the CDS entity

Right-click on the package created by you in the first step and go to New → Other repository objects. Search and select ‘Metadata Extension’.

Give a suitable name and description for it and click on Next, choose the Transport Request and click on Finish.

💡 Important: The names of metadata extensions are the same as their related CDS entities.

Once you get the layout, add the below code to it.

📢 Metadata extension tells the about the layout, positioning, and more UI related information for the fields to be displayed.

5.2 Metadata Extension for ZC_RAP_E2E_AEMPL

5.3 Metadata Extension for ZC_RAP_E2E_AEMP_M

5.4 Metadata Extension for ZC_RAP_E2E_AEMPL_M

---

---

5.5 Creation of behavior definition

💡 Behavior definition will be created for the root CDS interface view and behavior projection will be created for the root CDS projection view.

As always, the first part of this step is to go to New → Other repository objects. After this, search for ‘Behavior Definition’ and give an appropriate description for it. Then, click on browse to look for the ‘Root Entity’.

💡 After selecting the root CDS interface view, the implementation type will automatically become Managed.

Since the type of implementation is managed, we have to mention it in the first line. This will allow RAP to take care of the create, update and delete operation. Here class zbp_i_rap_e2e_aemp is the class in which we will be defining the business logic of all the behavior we are implementing ourselves such as action, determination, validation.

🗒️ This class ZBP_I_RAP_E2E_AEMP will be created in the next part of our blog series.

For the Employee interface view, we are defining two actions, one validation, and one determination behavior.

Action

1. hireEmployee – to set the status of an employee as active
2. retireEmployee – to set the status of an employee as inactive

Validation

1. validateAge – to check the age of an employee using the field DateOfBirth during the save sequence of the create operation.

Determination

1. assignIDs – to generate EmployeeID during the create operation for an employee.

💡 Determination on save – The determination is executed during the save sequence at the end of a transaction, when changes from the transactional buffer are persistent on the database.

For the employment interface view, we are defining two determination.

Determination

1. checkPositonAssigned – to check if any position is assigned to the employee already during create operation and if a position is already assigned then creation new employment for the same employee will throw an error.

💡 Determination on modify

The determination is executed immediately after data changes take place in the transactional buffer so that the result is available during the transaction.

2. assignAdditionalInfo – to automatically assign the salary to the employee depending on the PositionID.

5.6 Creation of behavior projection

Once the behavior definition for the root interface view of the composition model is defined, we can move forward with the creation of behavior projection.

💡 Behavior projection will be created using the root CDS projection view of the composition model. In our case we have two root CDS projection views, so we will be creating two behavior projections.

💡 After selecting the root CDS projection view, the implementation type will automatically become Projection.

💡 Create behavior projection for the Manager consumption by following the same steps as mentioned above or check out the GitHub repository for looking at the complete end-to-end steps.

With this, we come to the end of this blog part. We have completed the fifth step of our solution. In this blog post, we implemented one more step for our hands-on scenario on hiring. We also understood the use and application of behavior definition and projection and metadata extension.

In the next and last part of our blog series, we are going to learn about the implementation of business logic for the behavior definition followed by service binding and exposing the service. Till then, stay connected and keep learning with us, and don’t forget to check the GitHub repository.

That’s it for now, we’ll continue on our journey of learning ABAP RAP soon. Goodbye and happy learning!!