Standard SAP Fiori apps are a portfolio of applications where we receive a set of basic functionalities from the start. Very often, there are specific code fragments or configuring options that make customization possible in order to meet the business requirements. These places are called enhancements, and that is what this article is going to cover.
When our requirement is to enhance the functionality of the standard SAP Fiori application, there are a couple of aspects that are worth examining before. If we need to add a new field, it is possible that it is already possible that the option to add it at the ODATA level already exists and is in the documentation. Let’s try to systemize the places worth examining to ensure that the approach we have chosen is the most optimal. As an example, we will use the “Revise Payment Proposals” application and attempt to add a new field, “item text”, based on Roger Sainsbury’s analysis.
Sometimes, it is possible that the new field we are about to add is already available in the personalization options (view setting). It is enough to remember to verify it in the application’s settings.
Some Fiori apps are easy to customize in SPRO (enabling/disabling fields) but how to enter the SPRO screen when we are in the Fiori Launchpad? There is a simple way to navigate there. To enter the ‘ok_code’ in the Fiori Launchpad app, it is enough to go to ‘GUI Actions and Settings’.
From there, we can enable the “show OK Code Field” option.
This is how we can access SPRO without installing native SAPGUI frontend, without downloading new files, and without being limited by authorizations according to the corporation rules.
Run-time adaption (RTA)
RT adaptation is a functionality that enables the assignment of a super-user who can make basic changes to the Fiori app. These changes will apply to all users, unlike personalization where only one user is able to see the changes. To use RTA, the user must be assigned to the ‘SAP_UI_FLEX_KEY_USER’ role at the frontend Gateway.
At the same time, the ‘Adapt UI” option will become available in the Fiori Launchpad. Unfortunately, this option is currently only available in apps that use ‘SmartForms’ and ‘ObjectPage’ controls, such as the ‘Purchase Requisition Item Factsheet’.
In the example above, we can use the Adapt IU mode to add or remove new fields without looking into the code.
If none of the aforementioned solutions enable the necessary changes in the standard Fiori app, we still have one of the two more advanced methods – SAP WEB IDE for the front-end changes and ODATA service for the back-end changes.
Fiori Enhancements using SAP WEB IDE
To begin with, we should examine the documentation of the standard Fiori to find ‘extension points’ or ‘hooks’.
If we decide to implement such changes, we can carry them out at the SAP WEB IDE level through view replacement.
If we decide to replace the original view (for instance ‘S3’), it will create a new project with an ‘Extension’ ending, containing the copy of the standard view.
In the new project, within the ‘manifest.json’ file, a new fragment of code will appear, linking the old version of the app with the new version.
If we decide to delete this enhancement in the future, all we need to do is delete this code fragment and the app will revert to its original state.
With the help of SAP WEB IDE we can also modify the translations of texts, including the newly created field. During the extension selection, there is an ‘i18n Resource Text Customization’ option.
If we choose this option, the ‘i18n’ file from the standard version of the app will be copied to the app with the extension:
In this file, we can add additional field for the newly added column.
After making those changes, remember to make a demployment (‘deploy as new app’). This will ensure that the modified application will be displayed as a new BSP application.
To run the enhanced application, we also have to configure the tile and target mapping in the Fiori catalogue.
We should also remember that the name in the semantic object field must be different from the standard app:
For the target mapping, the URL address contains the name of the new BSP application (which can also be found using the SICF transaction), and the component name can be found in the ‘Component.js’ file of the enhanced project:
To test the enhanced application, we should naturally remember about to launch the proper tile with the new app (not the original).
Enhancing standard ODATA services
According to Sebastian Gaer’s methodology, adding a new field in the ODATA service consists of three steps:
- First, we extend the appropriate ABAP Data Dictionary (DDIC) structure using the command APPEND STRUCTURE.
- Secondly, we extend the ODATA entity in the Gateway Model Provider.
- Finally, we populate the data of the newly added field in the Gateway Data Provider.
In the ‘Revise Payment Proposals’ application, there is an option to add custom fields:
First we create and activate the new field in the ABAP dictionary – ZZSGTXT.
Then, we add the new field to the standard application’s structure:
In the second step, the package ‘ODATA_REVISE_PAYMENT_PROPOSAL’ contains both the Model Provider class and the Data Provider class for the specified ODATA service.
In the next step, we add a new field for the ‘PaytProposalInvoice’ entity.
Re-generate the runtime objects by clicking the following button:
As a result, a few new lines of code appear in the MPC class named CL_FAP_REVISE_PAYMENT.
Then, if we want to populate the new field with data, we need to locate the method: CL_FAP_REVISE_PAYMENT_DPC_EXT->PAYTPROPOSALINVO_GET_ENTITYSET.
This method is already redefined and has an enhancement at the end, where we can add the code to retrieve data from the field BSEG-SGTXT and pass it to ‘et_entityset’ table (which holds the data for the entire entity set).
Finally, we should also remember to add a new column in the front-end view so that the data from newly created field displays correctly.
The ODATA service can also be enhanced with BAdI (Business add-ins). However, these add-ins are not available for all of the standard SAP FIORI applications. Fiori views can also be created at the back-end level with help of ‘CDS Views’. Modifying them involves using SAP annotations on both the front and back-end levels, but this will be discussed in more detail in the next article.
In summary, there are numerous ways to enhance standard Fiori apps and they are limited by the options which were given by the SAP company. In the worst-case scenario, it is possible to enhance the entire application and rewrite the pieces that need improvement.
If you are interested in SAP topics, also take a look at other articles by our experts.