032: Recycling-Heroes - Tags and Types
In this episode, we'll create additional business configurations that we'll need later in our data model. Some of the properties have changed, and we'll examine these changes in detail.
Table of contents
Introduction
Welcome to a new episode of Recycling Heroes. Today we want to create the missing business configurations that we need for our next major application. We'll also revisit the mistakes from last time and take a detailed look at the customization options in the business configuration.
Reuse Layer
In the first step, we'll take care of the structure of our data elements and domains. Currently, we have the process created in our configuration. The process is also needed elsewhere, so we'll move it to the package for reuse first. We can assign the object to a different package using the "Change Package Assignment" function. Once the data element and domain have been moved, we can create a new, overarching element. We need a description for each of the two new objects; here, we'll use the same element in both entities. Don't forget to activate case sensitivity on the domain, as we allow free text here and don't work with technical keys.
Tags
In the next step, we define a new table for the tags. We do this via the corresponding package, which we created in a previous episode. There, we search for "Database" to find the table and start the creation wizard. After assigning the name and description, we create the new table in the system. We need two fields: the TAG_ID and the description. For the description, we use our new data element, but we have to create a new element for the TAG_ID. Using the forward navigation, we create the new data element and assign a description. Don't forget to include the corresponding tags, which will later appear in the Fiori app. To complete the setup, we also create the domain, as this is required for the business configuration and as a key field. Since we are using UUIDs in this configuration and a descriptive ID isn't crucial, we define the data type as RAW with a length of 16. To run the wizard on the table, we need to set the delivery class to C, for Customizing, and allow maintenance. Finally, activate the table.
In the next step, we can now start the wizard on the table to generate the business configuration in the system. After starting, we need to specify the package for generation; the flow hasn't changed so far. We set the object to no transport and want to disable all transport functionalities, just as we did last time. Now we can give the different objects the correct names. First, let's rename the Transport object and the Maintenance object. Next, we configure the service being generated and then adjust all the names for the entities, the Singleton, and the Core Data Services. Finally, we change the name of the implementing class. We don't need to adjust the Consumption View since we're only generating the interface layer. The generation of the objects will now take a while.
After generation, we receive a corresponding popup and can navigate to the Maintenance object. This takes us to the Binding service, which we also need to activate. To do this, trigger the release via "Publish" and wait a moment. Once the service is activated, we need permissions to perform maintenance in the app. To do this, we switch to the Fiori package and create a new IAM app. After creating it, we assign the new service under the "Service" tab and add the necessary permissions under "Authorizations". We need S_TABU_NAM for the table and for the Core Data Service. The permissions are important so that we can perform maintenance in the app; without permissions, the display remains empty and the button is inactive.
Document Type
Before we start testing, we'll create our second business configuration for the document types. For this, we need to create a new package, which we forgot during the initial setup. We'll then create our new table within this package. The table will have the document type as a key field, a description for the type, and the process to which the different types are assigned. In this case, we also need to create the new key field and populate it with the necessary information. This time, we'll use a descriptive key as the domain, since we'll need to access it later. Then we activate all objects and can begin with the business configuration.
When generating the business configuration, we'll leave the transport configuration at the default setting. Then, as in the first version, we'll customize the following objects before generating them. Basically, you can follow your own naming conventions and name the objects clearly. Finally, we'll perform the same steps as before: after all objects have been generated, we'll activate the service and create a new IAM app to define the permissions.
Business Catalog
Currently, however, we don't yet have any permissions for the new business configuration. We have created the IAM apps, but haven't yet assigned them to a Business Catalog or Business User. To do this, we open our Business Catalog for the administrator and add the two IAM apps on the "Apps" tab to grant ourselves the necessary permissions. Finally, remember to publish the settings to the current system using "Publish Locally". Since the Business Catalog is already assigned to us, we will automatically receive the new permissions.
Test
Let's go to the "Custom Business Configuration" app in the Launchpad and look for our table maintenance. If we have completed the previous step correctly, we will see the two new objects. Let's first go to the Tags and create some new tags. Adding the new data records works smoothly; the UUID keys are automatically assigned by the system. When we open the document type, a customizing transport is already displayed in the draft, onto which the objects are written. This means that transport is deactivated in our first view, while transport handling is still active in this view. Generation via the wizard thus appears to be working correctly again.
Transport
In the next step, let's deactivate the transports for our document type. To do this, we first go to the Behavior Definition to find and remove the various checks and functions. Wherever we find the word "transport," we can remove the corresponding objects. Then activate the definition so we can directly see the errors in the implementation and remove the components from the code. As a first step, let's remove all methods with an error, since we've already removed them from the definition. After generation, we can remove the UI annotations in the root view that still contain navigation to the transport.
If we then run a test in the Business Configuration, we initially receive no error message, but saving also fails. Here, we forgot an adjustment in the Behavior Implementation that is responsible for recording the transport. We also remove this from the code and reactivate the object. Another adjustment we need to make is to the Transport object. To do this, we can navigate to the Maintenance object and adjust the two points "Recording" and "Adaptable". This deactivates the transport and allows maintenance in a production system. Now we receive an error message in the object and must remove the Transport Selection Strip. This is a configuration in the Object Page area that is somewhat hidden.
Now we can test the maintenance again and create a new record. Currently, we have no value help for the process, so we enter a value and save the record. No error occurs now, and the record is saved.
Value Help
Now let's define the value help for the process. We have already defined this in the system and can easily reuse it in the Business Configuration. We again use our IDE action and define the value help on the field. Using the search function, we can map the appropriate field from the Core Data Service to the help. After activation, we also transfer the search help to the service so that it is available there as well, and then we can run a test on it. The dropdown is now available in the application, and we can select a new process when creating one.
Test data
To ensure we have the appropriate data for our tests, we extend our test class to be able to load additional data via GitHub. We need a new method for loading the tags. First, we'll deactivate the existing function to avoid having to reset the number ranges. We'll copy most of the existing logic and adapt a few parts to suit our needs. In the Business Configuration, we need to access the Business object via the Singleton. We'll use the Singleton as the entity and, in the Create By field, use the association to our actual data. Since the key is managed and created automatically, we only need to update the description. Make sure you provide the correct table for the creation. Because we're creating the data via an association, we also need to define our table accordingly. Next, we need to insert a record into the table. The actual data is located under %TARGET, which we need to map.
Now we delete the actual tables to always start with a fresh version. Once we have specified the two tables, we create a new method for the document type. Here, we can also copy the logic and only adjust the necessary components.
One important point we've forgotten so far needs to be defined in the table. Specifically, we need a key for the root entity to create the dependent records below it. The Singleton ID is hard-coded to 1 in the view in both cases. Once we have formatted the code, we can execute the class, load the new entries from GitHub, and insert them into the two tables.
Summary
We have now created various tags for the documents in the Business Configuration, which we can use to label the documents later. We have also defined different document types that should be available in the various processes in our framework. This creates additional Business Configurations that we will need next time in the new application. You can find the data in the GitHub repository as a JSON file.
That brings us to the end of this episode. Thanks for watching and see you next time.
YouTube
Video