Validation routine for a SAP Fiori Elements APP

SAP Fiori Elements is a framework provided by SAP for simplifying the development of SAP Fiori apps. It offers pre-built templates based on best practices, automating UI and functionality creation. Fiori Elements apps are primarily data-driven, handling data retrieval and reducing the need for manual coding. The framework ensures a consistent user experience across different Fiori apps, promoting standardized design within the SAP ecosystem.

Validation routines in SAP applications are vital for maintaining accurate and consistent data. They enforce business rules, prevent errors, ensure compliance with regulations and contribute to efficient processes. Validation also provides user guidance and enhances data security by supporting a reliable audit trail.

In this example we want to add a symantec validation check for a simple Fiori Elements App use case. In an ABAP RAP (ABAP RESTful Application Programming Model) data model, a database table’s key typically includes the client field and an automatically assigned UUID field. This combination ensures unique record identification. Additionally, there’s can be semantic keys (in this example Carrier_Id and Connection_Id) that should be unique per business logic. To ensure this uniqueness, you need to implement a custom validation check to prevent that the user enter duplicates or false entries.

You can use a OData UI Service (Standard for building and consuming web services) to generate all of the objects that are needed to get a working Fiori Elements App. This can be done in Elipse by using the ADT (ABAP Development Tools for Eclipse) addon.

When you create business objects using RAP, you will have to implement its application-specific behavior. We use EML (Entity Manipulation Language) to access the application data.

To add a validation routine we have to use the RAP Business Object Behavior Definition and Behavior Implementation. The Behavior Definition is like outlining the plan for how something should work. It describes the behavior you want like a blueprint. The behavior definition specifies which of the standard operations, create, update, delete are allowed. It can also contain the definition of validations, determinations, and actions. On the other hand, behavior implementation is the actual construction and coding to make that plan work.

First of all we need to define the validation in the Behavior Definition using the EML statement below:

A warning in eclipse tells us that the corresponding method does not exist yet. We need to add a method into the RAP Business Object behavior implementation.

The validation routine in this example consists of following steps:

Reading the business object by using the READ Entities statement. This statement has two  internal tables (one internal table containing the keys of the data that you want to read and another another internal table containing theresults of the query.

In the next step we check if the entries (carrier_id and connection_id) are already existing in the table zcl_me_01_conn and when they were found we put the field uuid into the check_result table.

When check_result table has an uuid value an error message gets triggered to prevent the user to enter the same combination of CarrierID and ConnectionID that already exists in the table.

The validation routine can be tested by using the eclipse debugger. Here we can track that the UUID value of the table zcl_me_01_conn was filled into check_result. It has a different ID than the uuid that got returned by the READ Entities statement above.

As a result the user will receive the error message in the Fiori Elements App and the entry cant be processed further.

This entry was posted in ABAP.