Standard SAP Fiori Application enhancements

Sii
BlogerSii
Standard Fiori Apps enhancements

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.

Enhancement types

Personalization

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.

Fig. 1 Settings button of the SAP Fiori app

Fig. 2 List of available fields to show in the settings

Customization

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’.

Fig. 3 Options available from the “more” tab

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’.

Fig. 6 RTA options available for the SAP Fiori app

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’.

Sekcja rozszerzeń dokumentacji aplikacji „Revise Payment Proposals” — Fig. 7 The extensibility section of the ‘Revise Payment Proposals’ application’s documentation

If we decide to implement such changes, we can carry them out at the SAP WEB IDE level through view replacement.

Widok opcji rozszerzeń dla zastąpienia oryginalnego widoku w SAP WEB IDE — Fig. 8 Extension selection screen for replacing the original view in SAP WEB IDE

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.

List of file of the extension version of the app — Fig. 9 List of files of the extension version of the app

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.

Fig. 10 Code fragment inside the ‘manifest.json’ file in the extended app

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.

Fig. 11 Extension selection screen for making changes in the ‘i18n’ file

If we choose this option, the ‘i18n’ file from the standard version of the app will be copied to the app with the extension:

Fig. 12 A list of files with text translations within the SAP WEB IDE app

In this file, we can add additional field for the newly added column.

Fig. 13 Code fragment from ‘i18n’ file responsible for the text translation of newly added field

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.

Fig. 14 BSP application view after locating it in the SAP system

To run the enhanced application, we also have to configure the tile and target mapping in the Fiori catalogue.

Fig. 15 A screen showing tile configuration in SAP Fiori Launchpad

We should also remember that the name in the semantic object field must be different from the standard app:

Miejce konfiguracji obiektu semantycznego rozszerzonej wersji aplikacji — Fig. 16 The place of semantic object’s configuration in the enhanced version of the 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:

Fragment kodu z pliku component.js wskazujący nazwę rozszerzonej aplikacji — Fig. 17 Code fragment from the ‘Component.js’ file pointing to the name of the enhanced application

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:

Fragment dokumentacji aplikacji „Revise Payment Proposals” dotyczący „customer fields” — Fig. 18 ‘Revise Payment Proposals’ app’s documentation fragment describing customer fields

First we create and activate the new field in the ABAP dictionary – ZZSGTXT.

Okienko wyboru „Data element” w systemie SAP — Fig. 19 Selection screen of data element in the SAP system

Then, we add the new field to the standard application’s structure:

Widok struktury ze wskazaniem na nowo dodane pole — Fig. 20 View of the structure pointing to the newly added field

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.

Widok dostępnych klas w aplikacji „Revise Payment Proposal” — Fig. 21 Screen of the available classes in the ‘Revise Payment Proposal’ app

In the next step, we add a new field for the ‘PaytProposalInvoice’ entity.

Fig. 22 Screen of the available entity sets in the app

Fig. 23 Screen of the newly added property for the given Entity Set ‘PaytProposalInvoice’

Re-generate the runtime objects by clicking the following button:

Fragment Interfejsu transakcji SEGW ze wskazaniem na przycisk regenerującego serwis — Fig. 24 SEGW button for regenerating the ODATA service

As a result, a few new lines of code appear in the MPC class named CL_FAP_REVISE_PAYMENT.

Fig. 25 Code fragment from the method ‘DEFINE_PAYTPROSOALINVOICE’ displaying new property

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.

Fragment kodu z widoku wskazujący nowododaną kolumnę do tabeli z rozszerzonym polem — Fig. 26 Code fragment from the view presenting newly added column to the table with enhanced field

Summary

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.

5/5 ( votes: 3)

Rating:

5/5 ( votes: 3)

Author