025: Recycling-Heroes - New Data (Contact)

Table of contents

• Introduction
• Test Data Container
• Implementation
• Number Range
• UI
• Summary

Introduction

In this episode, we finalize the contact app and populate the application with proper data. We'll look at an open-source project, load the data into our application using EML, and finally adjust the UI to display the correct data.

 

Test Data Container

To load the data, we use an open-source project that can also be used to provide test data containers via GitHub. We utilize the central repository and the JSON editor on GitHub to load a large data package and populate the data in our application. In the repository and the README file, you will find further information on using the project, as well as additional examples. Link to the project in the video description.

 

Implementation

Let's take a look at the data in the repository. In the new folder "DATA", you will find a JSON file where we have already stored employees, customers, and addresses. If you want to access the actual data without the website, you can view the file path and the JSON file using the "RAW" button. We will also need this path to load the information into ABAP.

For development, we will use our old test class, where we have already created an initial data set. Except for deleting the data in the table, we can remove the old logic. In the next step, we create a new method for loading the data and have it created using Content Assist. We want to create the new contacts using an EML statement, since we want to reuse the automatic numbering and the validation of the data records. Now let's define the path to the GitHub file as a constant in the class.

To use the Test Data Framework, we need a configuration. We pass the GitHub path and the file name to this configuration to create a new configuration. We can then pass the configuration to the factory to generate a new instance of the framework, which we return to the caller using RETURNING. Since the structure created in the JSON already matches our target structure, we can load the data directly into the internal table. Now we only need to write the EML statement and pass the data to the RAP framework. During the CREATE statement, we specify which fields we want to insert. This eliminates the need to populate the CONTROL structure of the table, saving us several intermediate steps. Because we also need to populate the CID for the framework, we use AUTO FILL, which uses generic IDs. Since we have no dependencies within the hierarchy, this is sufficient for our purposes.

To detect any potential errors, we create the return types FAILED, MAPPED, and REPORTED and output them to the console. You shouldn't forget the commit either, so that the changes are persisted after the EML statement.

If we then run the class, we should receive the new data records and their references as output. If we look at the data in the Data Preview, we find it with the new numbering.

 

Number Range

Currently, we have gaps in the numbering that resulted from our experiments with the data records and features. In the next step, we want to reset the number ranges and regenerate the data to have complete information. To do this, we open the "Manage Number Range Intervals" app in the Launchpad and go to the maintenance section for our number range. There, we open the first interval and can adjust the current value using the "Change Number Range Status" button. We then reset this to zero and must confirm the warnings. Generally, you should consider this, especially in a test and production system. Since we are in development and will be discarding all the data afterward, this isn't a problem for us. Now, let's execute the logic again and populate our RAP object with the data.

After execution, we go to the Data Preview and check the data. Now the numbers should start at 1, and we no longer have any gaps in the data. The data has been successfully loaded, and a first set of data is available to us.

 

UI

Let's go back to the UI and look at the data in the system. We currently have 26 data records from the various areas. However, in the List Report, it's noticeable that the text for the addresses doesn't look very good. Since FirstName and LastName are not required fields for the address, we have a lot of empty fields here. Similarly, we have several companies among the customers, and here too, we have empty spaces in the second field. If we navigate to the Object Page, we get an "Unnamed Object" for the address; we'd like to correct this.

To do this, we go to our application where the actual text is generated. Currently, the FullName in the value help is only composed of the FirstName and LastName. Therefore, we are adjusting the field generation. We can easily do this using functions in CDS. If it's an address, we want to use different logic than before. We take the street name, add a comma, and append the city name to the end. In the Data Preview, the FullName is now populated with all the information.

Now we can use the FullName in the appropriate places. To do this, we go to the Metadata Extension and remove the LineItem from FirstName and LastName to hide the fields in the List Report. In their place, we now display the FullName. If we check the UI, we now see no more gaps in the list report; only the heading isn't quite right. We add the EndUserText label to the field, and with that, our application is complete.

 

Summary

The application is now in the state we want. A proper title is now displayed on the object page, including for the address. In principle, minor adjustments could still be made, such as hiding the contact ID or the name for the address. In the first step, we'll leave the app as it is and begin the configuration in the next episode.

Until then, thanks for watching and see you next time.

 

YouTube
Video