RAP painless mandatory field validation

The RAP utility with many other RAP scenario is available on GitHub, you can pull via abapGit.

There are two branches: onPrem-2023 and cloud with different samples.

https://github.com/attilaberencsi/zsapdev_agit

Introduction

Bolierplate and repetitive coding is a killer. Until SAP provides a solution for that in RAP context, you have to do mandatory field validations manually . Will it ever happen ? We cannot be sure. It could be a design decision behind that, not to provide such. It is more complex to troubleshoot issues, due whether a field is mandatory can be dynamically calculated in get_instance_features method of the behavior implementation. That is your own code implicitly invoked, and tells if a field is mandatory based on other criteria.

But still, I am really missing this feature in RAP, because in CAP this is a built-in functionality, and I had to do zero coding, just use an annotation. In ABAP we need to perform many manual steps and do manual coding to raise a message.

But of course the missing functionality can be done within a ABAP utility class and applied in the managed scenario. Why not . We’ll go through step by step in the implementation process to make mandatory field validation. At the end You can take the utility class with You and relax for the rest of your projects.

Development process

1. Define the field mandatory in behavior definition (BDEF)
   • statically (mandatory)
   • with dynamically field control ( features: instance )
2. Additional step: implement get_instance_features method in case of dynamic field control
3. Define a validation for mandatory value check in BDEF
4. Implement mandatory field validation method in Behavior Implementation class
   We use the managed RAP Utility handler class for that purpose to save the efforts of the painful and repetitive coding of mandatory field validations.

Let’s look at each step one by one.

Set fields as mandatory

As explained earlier, You have 2 options to make a field mandatory. You can exclusively use only one of them.

Define the field as mandatory in BDEF statically

  field ( mandatory ) Name;

Calculate mandatory property dynamically

Another option is to decide whether the field is mandatory is based on other criteria in the Behavior Implementation class

This is a two step approach. First configure the field control in BDEF as dynamic

  field ( features : instance ) Manufacturer;

Second calculate the field control values in method get_instance_features based on some criteria

    result = VALUE #( FOR k IN keys
                      ( %tky                = k-%tky
                        %field-Manufacturer = SWITCH #( 1
                                                        WHEN 1
                                                        THEN if_abap_behv=>fc-f-mandatory
                                                        ELSE if_abap_behv=>fc-f-unrestricted ) ) ).

We reached the step, that we have the little red star next to the field label on the Fiori Elements UI, but nothing else. The validation is not done out of the box in RAP.

Define mandatory field validation

We need a validation in the BDEF to hook in the ABAP method that validates the value of mandatory fields.

  validation validate_mandatory_fields on save { create; update; }

Implement mandatory field validation

This is the repetitive painful implementation step costing many efforts during development. Here is where the utility class comes into the picture.

Simply invoke it passing the BDEF name and the corresponding component of the failed / reported structures .

In the background the method goes through all the fields which are set mandatory, and implicitly invokes get_instance_features to decide whether a field is mandatory.
The later is done with a dynamic EML statement GET PERMISSIONS ONLY INSTANCE FEATURES OPERATIONS. This is a really good statement to obtain field control programmatically in a dynamic format, in case you want to build your own utilities too.

    NEW zcl_sapdev_rap_managed_base( i_bdef_name = co_bdef_name )->validate_mandatory_fields(
                                                                  EXPORTING keys            = keys
                                                                  CHANGING  failed_entity   = failed-nozzle
                                                                            reported_entity = reported-nozzle ).

Results on the Fiori Elements UI

The validation message is displayed attached to the field

Clicking on a message hosted by the bottom message container navigates the end user to the page where the error is to be fixed, and the focus goes to the field to correct the error.

In case of deeper level navigation like 3 and more – which is not automatic by FE List report template – the erroneous list records on the object pages are marked red to see from which item the problem is coming from (OData v4).

The dirty details about the utility class

At this point I am sure You’re curios about the utility class. So here are the details

You can clone this repository including the RAP BO samples as well https://github.com/attilaberencsi/zsapdev_agit, or browse it to take over the utility class and related objects in part or whole into your system.

In the sample managed RAP BOs ( draft/ non-draft ) You’ll find how to invoke the utility class.

In case You publish the sample services, You can do a live Preview of the Fiori Elements application from ADT without the need of touching BAS for testing.

Public methods of class zcl_sapdev_rap_managed_base

• zif_sapdev_rap_managed_base~validate_mandatory_fields
  • does the painful mandatory field validation
  • made with dynamic EML READ and PERMISSION OPERATIONS
  • metadata, annotation and DDIC access to retrieve field labels for the messages
• zif_sapdev_rap_managed_base~fill_message_path
  • you can use this in your custom validations to fill in the message %path which costs lot of efforts on deep BO hierarchies otherwise. As result the erroneous field is highlighted with the error message and Fiori Elements list report template provides navigation capabilities to the erroneous field, and error highlights in tables
  • it realizes this with a recursive path traversal and dynamic EML READ operation starting from from the current entity the until the root to fill in the message %path keys

At the moment the utility class supports only onPremise systems, due the used APIs are not released on the cloud language version. SAP does not provide yet the required xco libraries for the same purpose. It is a demanding port and workaround, but the feasibility of that is on way, partly done. Stay tuned! I hope we can get a Cloud ready version of the utility class soon.