Fiori Development – Table maintenance with SAPUI5 application
1. Introduction
As a contrast to the last blog where we utilized Fiori Elements for an app creation, I would like to demonstrate in this one, how to create a freestyle SAPUI5 app for the maintenance of a custom parameter table, located in the backend system. The topic stems from the idea of how to move recurring tasks from the S/4 system to Fiori, in order to have them closely integrated in the same space with other related tasks, both analytical and transactional.
2. Initial Situation and Objective
We have a custom table ZPARAM_DVU which is maintainable and contains central parameters serving diverse purposes and applications. These parameters are changed periodically:
The aim is to build a Fiori app which allows the update of the maintained values. For the sake of clarity and simplicity, only an update option will be implemented for now.
The OData protocol enables four different access types: CREATE, UPDATE, READ, and DELETE (CRUD). Unlike examples from previous blogs, where only read operations have been necessary, we will also need to utilize the update operation to not only read but also modify the existing data.
3. Data Model
To achieve our goals, we created a CDS view entity which contains a select on the mentioned dictionary table:
We generated an OData Service and ObjectModel via specific annotations. Both are obligatory for our use case as we want to read and update data. We enabled only updates to the object, but if needed later, you could of course enhance the definition by the necessary annotations for other operations like the creation of new entries or deletions.
To keep it simple, we still used OData V2 in this short example. However, OData V4 and RAP (RESTful Application Programming Model) represent the future standard in this area.
4. SAPUI5 application
After the generated OData service was activated, we switch to the Business Application Studio to create our SAPUI5 app. We choose the basic template which will generate the needed file structure for our freestyle app:
During the creation of the project, we choose the created OData Service to define the data model for the app. After the project is added to the workspace, we can start with the needed coding for the app. We will edit the following files and fill them with the needed coding:
View1.view.xml -> here we define our UI layout and create needed controls like a Save Button and text as well as input fields.
View1.controller.js-> here we create the coding for the app logic. To understand how the data model, the view and the app logic are related to each other it is necessary to get familiar with the MVC (Model-View-Controller) concept.
manifest.json -> in this central configuration file of the app, we will make sure that two-way binding is considered
- View adjustment:
We use a sap.m.Table for visualizing our data and bind our root entity via aggregation binding to the items aggregation:
After the columns have been defined, we create the controls for the data fields, whereby one must be of type input, as we want to be able to maintain the value of the parameter. We bind the relevant properties from the text and input controls to the corresponding ones from the OData model:
Finally, we create a Save Button which will trigger the function onSave, which we create later in the Controller for submitting the changes in the table:
We embedded the Button in an HBox to position it as desired.
- Controller adjustment:
The provided controller logic consists of two main functions: onInit and onSave. The onInit function is automatically triggered during the initialization of the view, but it currently contains no logic, as no specific tasks are required during initialization. The onSave function is executed when the user clicks the save button in the UI. Within onSave, the OData model associated with the view is retrieved using this.getView().getModel(). The submitChanges method of the model is then called to send all pending changes to the backend. Based on the outcome of the operation, the user is informed about the success or an error by using the MessageToast control:
- Add setting in manifest.json file:
The last step is to ensure two-way binding as we don’t want to just read but also update data. Therefore, we enhance the manifest.json file at the right position by this line:
5. Application Preview
After the necessary code adjustments have been done, we test the application in the preview:
The application opens with the expected layout. Now let’s see whether the update of the parameter values works. We change the parameter PLANVERS from “BUD” to “FC” and DEFCURR from “EUR” to “USD”. After the adjustments we click the Save button.
We received the message, which was implemented in the controller, indicating a successful data update. Now let’s check the values in the backend:
The value update worked! The tested app can be deployed to the target system now.
6. Conclusion and Outlook
Instead of continuing the blog series on Fiori Elements, we introduced a freestyle approach for a change and created an SAPUI5 app that allows us to move regularly performed tasks into Fiori. This way, related content of both analytical and transactional nature as well as maintenance tasks, can be closely integrated within the same space, positioning Fiori more and more as a central work platform.