034: Recycling-Heroes - Object and RAP Generator (Document)

Introduction

In the last episode, we laid the foundations for today's app and created business configurations for document types and tags. Now we want to create our new application for uploading and creating documents, and as a first step, we'll only use various generators to create the data model.

Object Generator

We already introduced the Object Generator in a blog post. It generates various DDIC artifacts for us, so we don't need to specify any further settings besides the configuration. This saves us from creating tables, data elements, and domains, yet we always have a complete data model available. Therefore, as a first step, let's create a new class that will read the configuration and then generate the objects from it. In this case, we'll use the executable XCO class, as it handles XCO objects better and has built-in error handling. Unlike with an interface, we inherit from the class and must first redefine the abstract MAIN method locally.

First, we create a GitHub configuration, since we've stored the configuration as JSON in our GitHub repository. We pass the configuration to the test container and then retrieve the data as JSON. Since we need a structure for the data here, we define the generator configuration as a local variable. Next, we can create an instance of the Object Generator. Passing the variable SY-REPID is important because we want to derive the transport from the current class without having to pass it manually. Now we pass the configuration to the generator and let it generate the DDIC artifacts. We then pass the result of the generation to the output of the MAIN method. The resulting object has the interface NEWS in its Findings, which allows for easy output with this executable class.

If we now go to the GitHub repository, you will find the appropriate file for the generator in the Data folder. This file contains the configuration and information such as the domains with their data types, the corresponding data elements that the domains also use, and the table definitions. For the tables, it's important that the client field is present, as are the RAP administration fields in the lower part of the table. We'll generate two tables right away. The RAW button gives you the link to the JSON file, which we'll also pass to the container configuration in the source code.

That completes the code so far. We activate the class and start the generation with F9. After a short moment, the generation should be complete without any error messages, and we can update the package. We should now find 12 new objects that were created by the generator and activated immediately. Let's take a look at one domain. The stream type was correctly inherited. Our table for the documents is now complete and active, and we can look at the next generator.

RAP Generator

Last time, we created the app's objects manually. This is a very cumbersome step, but worthwhile for beginners who are working with RAP for the first time and want to learn the concepts. In this step, we'll use a RAP generator to generate the objects and the stack. This saves us a lot of time, as does the Object Generator. We can start the generator directly on the table and will find three different generators. We've already used the Business Configuration to generate objects; in this case, we want to create an "OData UI Service". For the generator, we still need to specify a package where the objects will be generated. We would generally expect the package of the table to be used.

The next step involves configuring the various objects that will be created. You could generally accept most of the generator's suggestions, but we want to use our own conventions. At the first level, we provide general information for the generator, the project name, and we would like to use a prefix. You don't need to specify the Z for the customer namespace, as it will be added automatically. At the next level, we adjust the name of the ROOT entity and leave the ALIAS empty, as we don't need one. At this level, we define the behavior; here, we need to adjust the name of the class, which usually begins with BP, such as "Behavior Pool". We also adjust the name of the Draft Table. Next, we address the projection level of our RAP object. Here, we adjust the Core Data Service to match the Root entity, as well as the class for behavior implementation. We want to create the service definition without the suffix and leave the service binding as is. Clicking "Next" generates a preview of the created objects and confirms the generation, which then takes a few minutes.

Once the generation is complete, we receive a notification and can switch to the service binding. There, we press the "Publish" button and start publishing the service. This step may also take a little while.

Summary

Let's take a first look at the application. The structures are defined, the services are activated, but unfortunately, there's still far too much information displayed in the UI. Using the generators saved us a lot of time generating the data model and the various artifacts. Manual work would have been time-consuming and could also lead to errors that we would have to correct later.

We'll take care of the other entity, the annotations, next time. Until then, thanks for watching, and see you next time.

YouTube
Video