Script: Recycling-Heroes - RAP Modeling Contact [010]

Table of contents

• Data Model
• RAP Object
• Draft and Service
• Troubleshooting
• Test data
• Summary

Introduction 

In today's episode, we'll build the RAP object manually and explain the Classic Pattern in detail. This means that the initial construction of the object is aimed at new developers in the area of ABAP RESTful Application Programming Model. We'll build the individual layers piece by piece.

 

Data Model

So let's start with the data model of the actual database table. We can create a new repository object using the context menu. Here we can search for "Database Table". We assign a name and a description to the object, and assign it to a transport. In the next step, we define all the fields that we have already defined in the data model. You can basically start by creating the table and write down all fields and data types, even if they don't yet exist. Once we have finished creating the fields, we begin creating the various types. If we save the table, it will be automatically formatted for us.

To create the first data element, we use the quick fix in the ABAP Development Tools. We can create a new data element via the context. The name and package are already suggested from the context, and we also define a description. If we want to create our own domain, we copy the same name into the "Type" field. We also assign appropriate labels, which we will see later in our application. By clicking on the link, we can create the domain and navigate to it. There, we enter the appropriate data type and length and activate the element. After activation, we can go back and activate the data element as well. If we then click the Check button, there will be one less error, and we can continue with the next data element. In this case, we create the "Contact type." This also receives an additional domain. The reason for this is that we want to define various fixed values that we will make available later. Here, we have the values "CU" for Customer, "EM" for Employee, and "AD" for Address. Here, too, activate the corresponding elements and then close them to return to the table. Now let's define the other important elements. We also define data types that we use across all fields, such as the Text100 character field, which has a length of 100 characters and is case-sensitive. This allows us to use it later for other fields and avoids having to create a separate domain. Another special feature of the data model is that we use the data element LAND1 for the Country, which comes from the standard and is released for ABAP Cloud.

Once we've finished creating the table, we can activate it to create it in the database. We then open the table in the Project Explorer and can create a new Core Data Service for it via the context menu. This Core Data Service is a Base View and propagates our table externally. The CDS view has the type "View Entity," which is now considered standard in CDS development. The system suggests appropriate names, which we accept, format once, and finally activate the view.

 

RAP Object

We do have to make one change, however. Since we want to have a RAP object with draft functionality later, we still need to add the typical draft fields to the table. To do this, we can get the code snippet from the code snippet area on the website. From the Git repository, we can copy the snippet using a simple copy button and paste it into the table. We now need to do this at the Core Data Service level; for this, there is a second code snippet with the appropriate annotations and the prepared names. Finally, activate both objects.

Once we have made this change, we can add the Core Data Service to our RAP object. To do this, we go to the existing Base View and create our new Root View using the context menu. The TP at the end stands for Transactional Provider because we will be implementing transactional behavior. We select the "define root view entity" template and generate the view. Finally, we need to remove some information and then format the view again. This completes the root view in the system. Next, we can create our consumption view on this view. To do this, go to the context menu again, create the consumption view, assign it a name, and enter a description. Finally, we select the template for the projection view. Here, we also need to add the provider contract; you can find this via the quick fix. Here, we select "Transactional Query." Finally, don't forget to add the word "root," as this part belongs to the root view. Finally, we add the tag "metadata allow extension" so that we can later create a metadata extension on the CDS view.

In the next step, we can create the behavior. To do this, go to the context menu of our root view and create a new behavior definition. Here, we'll use the "managed" approach. Once the behavior definition has been created, we can begin customizing it. To do this, we define the alias, for example, and give the behavior class a suitable name. In the next step, we define a mapping for the table. The mapping goes from the Core Data Service to the actual table; here we need to map the various fields to each other. Once we're done, we generate the class in the system, format it once, and activate it. This creates the basis for the behavior definition, and we can look at the next part.

 

Draft and Service

Now we want to activate the draft in the behavior definition. To do this, we add the suffix "with draft" to the header. At the entity level, we add the draft table and give the table a new name. We generate the table using the Quick Fix functionality. This requires almost no effort, other than creating and activating the table. Once the draft table is activated, we can close it and return to the behavior definition. If we now click the "Check" button, further error messages will appear that we need to resolve. To do this, we need to, for example, add the lock master and the e-tag. Here, we use the "Last changed" field. We also need to implement the e-tag master and store the "local last changed date" field there. Since we are in the draft, we need to add additional actions that are necessary for the draft. For example, there's the draft action for "Edit," which we can then copy and change the corresponding names. We'll therefore add an "Activate" action and a "Discard" action for activating and undoing, just like for Resume. For "Activate," we'll add the "Optimized" suffix so that the warning message disappears. If we now want to activate the whole thing, an error message appears stating that the corresponding "Prepare" action must be added. This is a "Determine Action." Once we're done, we can activate the behavior definition.

Now we can begin creating the projection for it on the Consumption View. After creating the projection, we add the alias. Otherwise, we don't need to make any further changes. Once the behavior definition is activated, we can begin creating the actual service. To do this, we create a new service definition and give it a name or description. Since we created the new service via the context menu, our entity is already exposed. For this purpose, we assign an alias through which the entity can be accessed in the service. We also search for the annotation for the leading entity, copy the name, and then paste it. The annotation causes the entity to be highlighted in the service binding at the end. Finally, we define the new service binding. We can do this again via the context menu of the service definition. There, we assign an appropriate name and select the corresponding binding type. Since we want to create a UI service and are working with Draft, we select OData Version 4 for UI. Finally, we activate the service binding and publish the service using the "Publish" button. This process can take a few minutes. Once activated, we can use the "Preview" button to preview the service. Button to start the application.

 

Troubleshooting

We currently have an error loading the application. To do this, we can access the browser's developer console using F12. If we look at the console there, we find an error message telling us that the app could not be loaded because the ContactType field is defined multiple times. This indicates that our field from the Core Data Service cannot have the same name as the entity type that was automatically generated. Therefore, we go to the Core Data Service and change the field to "ContactTypeInt". We repeat this process through the entire hierarchy up to the consumption view. We also need to adjust the mapping in the behavior definition. We can now attempt to activate the objects. This will still result in an error within the behavior definition. The problem here is that we have to generate the draft table again. Using the quick fix, we can easily generate the draft table again and then activate it. To check for further errors, we open the service binding and click the "Check" button to obtain further information about whether there are any more errors in the entity. If there are no more errors, we can refresh the application again and this time we will receive an empty list. Using the various settings, we can view the list of fields, display filters, and display the fields in the list. Since we don't have any data yet, we don't currently see any records in the list.

 

Test data

To do this, we first create a new class to generate test data in our table. We create the class in the "Test" package within the software component. We give the class a name, a description, and add the interface for executable classes. After the class has been generated in the system, we can begin creating an internal table that we can fill with data. We can then transfer data to the table using the VALUE statement. Finally, we always want to delete all data from the table before inserting the new data from our internal table. From a clean ABAP perspective, we should, of course, name our table after its contents.

Then we open the table. To have all fields available, we copy them once and paste them between the parentheses. We can then edit the entire block using the block function of the ABAP Development Tools. This deletes the type definition and adds the empty literals. We then deactivate the block function, delete the client field, and remove the key addition. Now we can begin entering the first content into the various fields. We'll first add some content so that we have something available in the display later. Once we're done with that, we'll create a second data set to validate the filter later. However, we'll only change a few pieces of data, as that should be enough to start with. Once we're done with that, we'll run the class once and generate the data in the table. To check the data, we'll open the table and run the data preview with F8. We see the two data sets in the table and have thus generated all the test data.

 

Summary

In this episode, we looked at how to manually create the various layers of the RAP stack and implement the draft functionality. We looked at an error case that can occur during modeling, and finally, we generated test data for our RAP object. In the next episode we will look at the UI modeling.

Thanks for watching and see you next time.

 

YouTube
Video