027: Recycling-Heroes - Business Configuration (Settings)

Table of contents

• Introduction
• Table
• Generator
• Authorization
• Transport
• Value Helps
• Summary

Introduction

In this episode, we'll look at the Business Configuration, generate the table and various helper views to maintain the configuration via a Fiori UI.

 

Table

First, we'll create the actual table, which we'll create according to the data model. You can find the data model on the Recycling Heroes overview page in the video description. Let's create the table using the context menu of the Project Explorer. We'll define the "Configuration ID" as a key, assign a process to each configuration, and have one value and one high value for each. This allows us to maintain various settings in the system that we will later use in our processes.

Once we have defined all the fields in the table, we create the corresponding data elements and domains in the system. We can easily create the elements using the forward navigation. In the case of configuration, we want to define some values directly that we will also use later in the process. Here we define values for whether APIs are active in the system, various default values, and modifiers for default values. Once we have finished defining them, we activate the elements.

In the next step, we define the process and also create data elements and domains here, since we want to create fixed values in the domain. There, we define the various modules of our solution. For the value, we need the domain because we want to support uppercase and lowercase letters. In the case of the value, we use the same data element for both fields and adjust the text later via the UI.

Before activation, we adjust the delivery class and the data maintenance of the table. For the Business Configuration Generator, the table must be set to Customizing and maintenance must be enabled. With this, we can activate the table and proceed to the next step.

 

Generator

For generating the maintenance stack, we use the generator for the "Business Configuration Maintenance Object". This makes the complete RAP stack available to us in the Singleton pattern. First, we select the same package as the table where all objects will later be generated. In the next step, we need to configure all the settings in the generator. To do this, we deactivate the transport settings and adjust the names for the various objects. Further information on the business configuration, its creation, and customization can be found in the video description.

Once we have finished configuring the settings, we receive an overview of the objects that will be generated in the system. Clicking "Next" creates all the objects; this may take a while. As soon as the generation process is complete, we receive a popup and can navigate to the maintenance object. Then we must activate the service so that the entity appears in the app and can be maintained.

 

Authorization

Let's test the maintenance and go to the Launchpad to start the "Custom Business Configurations" application. In the development environment, we see all created maintenance objects and can search for our new maintenance object. If we select the entry and load it, we will find that we do not have permissions to enter edit mode. Therefore, we must create the permissions as a first step.

To do this, we create a new IAM app in the Fiori package to assign the permissions. We need to specify a Business Configuration as the type. To do this, we go to the Service tab and enter the new OData Service in the development object. To assign the appropriate permissions, we switch to the "Authorizations" tab and add the object S_TABU_NAM there, so that we can grant permissions to tables and Core Data Service.

For the table, we first need read permissions for the change documents and then a second permission for modifying and reading the table and the Core Data Service. With this, we should have all the necessary permissions to perform the maintenance. Once we're finished, don't forget to use "Publish Locally" to publish the permissions. As a final step, we go to the Business Catalog and add the IAM app so that the admin will also receive the permissions later. Publish the permissions here as well so that we can test them in the Launchpad in the next step.

Now let's switch back to the app and refresh the browser to reload the application and the permissions. The Edit button is now active, and we can maintain our first entry. When saving, we currently receive an error message stating that we need to specify a transport. We actually generated the entry without a transport; there seems to be a small bug here at the moment. Therefore, in the next step, we adjust the maintenance.

 

Transport

After generating the RAP object, we can freely customize and extend it. Therefore, we now delete all connections to the transport record from the object. Let's start with the behavior definition and remove the various components of the configuration in the form of side effects, validations, and actions. After activation, we can go into the implementation to remove the methods there. We can remove any piece of code where we now receive an error message, as these are the deleted objects. If we no longer receive any error messages, then we can activate the class.

Finally, we remove the buttons from the UI. To do this, we go to the Core Data Service, since at the Singleton level the UI annotations are located directly in the View. There, we remove all annotations on the transport field, as we no longer need them.

Once we're finished with that, we can go back to the Fiori application and reload it. All transport-specific elements should now be removed. Therefore, we create a first data record and save it, which now works without any problems.

 

Value Helps

Let's now define the new value helps that we want to use as dropdowns during maintenance. As a first step, we define the help for the configuration and use a View Entity for this. After that, we can clean up the view, since we'll use our IDE action to generate the join. We want to create a value help based on a data element and specify the field name, which will be generated as an alias in the view. After generation, we want to activate the dropdown for the field.

We define the second value help based on the process as well, using the same steps as for the configuration. With the IDE action, we can also use the search help to select the appropriate data element.

Once we have created and formatted the two views, we can adjust the business configuration. To do this, we add one or two additional associations to the configuration view to make the text available in the view. To do this, we connect the ID and the process in the view. Then, we define the value help for the field using annotations. We use the two view descriptions to display the text in the UI instead of the key. Through the arrangement, we ultimately only see the text. Once we're finished with that, we can adjust the heading of the second value field to visually differentiate the fields.

After that, we need to add the two Core Data Services to the service definition so we can use them later. Before we can test the UI, let's take another look at the service binding; there's still an error here because we modified the field structure at the interface level. Here we should recreate the draft table.

 

Summary

This completes the table maintenance, and we can now manage the values in the app. However, there seems to be a minor issue with the text display, at least while the values are still new. It generally works after saving the values. This allows us to manage the entries later without having to deploy a custom UI, which saves us complexity. That brings us to the end of the episode, and we'll be taking care of the API next time.

Thanks for watching, and see you next time.

 

YouTube
Video