Skip to Content
Technical Articles
Author's profile photo Ramjee Korada

ABAP Restful Application Programming : Real Time validation on field input in transactional Fiori Application


      Main aim of any application is to keep the transactional document error free. That says how important is error handling and validations in the application process.
In this blogpost, I will explain how we can implement real time validations on field input in a transactional fiori application with ABAP RAP framework. Instead of executing the validations at the save in the end.

Problem statement :

         In the traditional approach ( link ), the validations can only be executed at SAVE in the end. The disadvantage in this approach is that inconsistent values have already been entered and the document becomes inconsistent. if it is a draft enabled application, then these inconsistent values have already been stored in draft tables and transactional buffers. This is additional work for the user to clear all those errors at the end. As a user, he/she always expects to display the error on field input.
define behavior for ZBP_xxxx alias PurCon
{ ...
validation ValidateHeaderFields on save { field Supplier , CompCode ; }

… }
       If it is a simple dependency, then it might be useful to use parameterized CDS value help. So that dependent field ( field #2 – Ex. Supplier contact person ) value help can restrict the possible values based on parameter ( field #1 – Supplier).

  @UI:{ lineItem: [{ position: 50 }] , identification: [{ position: 50 ,qualifier: 'General'}]}
  @Consumption.valueHelpDefinition: [{ entity: {
      name: 'ZRK_I_SUP_CON',
      element: 'SupConId'
      } ,
      additionalBinding: [{
          localElement: 'Supplier',
          localConstant: '',
          element: 'SupNo',
          usage: #FILTER_AND_RESULT
      }] ,
            useForValidation: true

But the challenge in this approach is that if multiple large tables need to join to give the value help result then it might slow down the application. In those cases, evaluating errors is quicker than restricting the values from huge joins.

However this approach does not help if the user changes values vice versa( Ex. value of the supplier to something else).

Even this approach does not work, if we use custom entities for value help.

In both cases, we must implement validation at the SAVE interaction phase to ensure the document is consistent . But it is already too late to inform the user.


Answer is YES and let us look at probable solutions to this problem statement. The solution is to trigger real time validation on field input and that can be implemented using PRECHECK in the RAP framework.

        With a precheck implementation you can deny incoming requests before data reaches the transactional buffer. You can prevent illegal changes from reaching the transactional buffer by prechecking modify operations.

During PRECHECK implementation, we can keep validation logic and generate FAILED and REPORTED parameters so that error messages can be displayed on FIORI screen. This error will be cleared only after the user gives correct input to the field.

Implementation and business example:

Let us take a business case in which we have a complex logic to validate the usage of supplier and company code for the logged in user’s department and some customizing. So the validation needs to be executed whenever there is input either on supplier or company code.


  1. Enable PRECHECK for standard operation UPDATE using below syntax in the Behavior Body
    update ( precheck );​
  2. Implement the respective method in the behavior pool class using quick fix.
        METHODS precheck_update FOR PRECHECK
          IMPORTING entities FOR UPDATE PurCon.​
  3. Check if the required fields have been modified using control structure ( 01 -> modified , 00 -> untouched in this interaction ).
    CHECK <fs_entity>-%control-Supplier EQ '01'  OR <fs_entity>-%control-CompCode EQ '01' .​
  4. If yes, then proceed with validation using wrapper business logic.
                 iv_supplier  = <fs_db_con>-Supplier
                 iv_comp_code = <fs_db_con>-CompCode
               ) .​
  5. If the validation fails, then fill the return structures FAILED and REPORTED ( refer the example ) .
     METHOD precheck_update.
        LOOP AT entities ASSIGNING FIELD-SYMBOL(<fs_entity>).
          CHECK <fs_entity>-%control-Supplier EQ '01'  OR <fs_entity>-%control-CompCode EQ '01' .
          READ ENTITIES OF zrk_i_pur_con_ud IN LOCAL MODE
            ENTITY PurCon
            FIELDS ( Supplier CompCode )
            WITH VALUE #( ( %key = <fs_entity>-%key ) )
            RESULT DATA(lt_con).
          READ TABLE lt_con ASSIGNING FIELD-SYMBOL(<fs_db_con>) INDEX 1.
          IF sy-subrc EQ 0.
            <fs_db_con>-Supplier = COND #( WHEN <fs_entity>-%control-Supplier EQ '01' THEN <fs_entity>-Supplier ELSE <fs_db_con>-Supplier ) .
            <fs_db_con>-CompCode = COND #( WHEN <fs_entity>-%control-CompCode EQ '01' THEN <fs_entity>-CompCode ELSE <fs_db_con>-compcode ) .
            IF NOT zrk_cl_mng_pur_con=>validate_supp_le(
                 iv_supplier  = <fs_db_con>-Supplier
                 iv_comp_code = <fs_db_con>-CompCode
               ) .
              APPEND VALUE #( %tky = <fs_entity>-%tky ) TO failed-purcon.
              APPEND VALUE #( %tky = <fs_entity>-%tky
                              %state_Area = 'VALIDATE_SUP_LE'
                              TO reported-purcon.
              APPEND VALUE #( %tky = <fs_entity>-%tky
                             %state_Area = 'VALIDATE_SUP_LE'
                             %msg = NEW zrk_cx_msg(
                                        severity  = if_abap_behv_message=>severity-error
                                        textid    = zrk_cx_msg=>c_sup_le_match
                                        supplier  = <fs_db_con>-Supplier
                                        comp_code = <fs_db_con>-CompCode  )
                             %element-supplier = if_abap_behv=>mk-on
                             %element-compcode = if_abap_behv=>mk-on
                              )  TO reported-purcon.
              APPEND VALUE #( %tky = <fs_entity>-%tky
                      %state_Area = 'VALIDATE_SUP_LE'
                      TO reported-purcon.
  6. Now you can see the error on FIORI UI without reaching the transaction buffer to the database.

Conclusion :

With this blogpost, we understood and learnt the importance of validations, how to generate the error message on field input in RAP framework using PRECHECKs.

Please leave your suggestions and feedback or alternative proposals in the comment section.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Aman Garg
      Aman Garg

      This is helpful. Thanks for sharing!

      - Aman Garg

      Author's profile photo Prasenjit Bist
      Prasenjit Bist

      All these details are explained very minutely in multiple SAP videos by RAP experts in TechEd and are available on You tube or the SAP developers site the RAP PDF. I do not see anything new except for an own rendition of the same on SCN.


      Author's profile photo Ramjee Korada
      Ramjee Korada
      Blog Post Author

      Can you please share links here that talks about

      1. Realtime validation BUT NOT about validation at SAVE
      2. Without reaching to transactional buffer
      3. Usage of PRECHECK
      Author's profile photo Prasenjit Bist
      Prasenjit Bist

      Yes sure on YouTube search for videos by Andre Fischer and any last 2 years Tech Ed videos and the free RAP PDF from SAP - you get all the ideas now just aborting save come on don't shout Eureka for that

      Author's profile photo Ramjee Korada
      Ramjee Korada
      Blog Post Author

      Please share 2 links discussing those 3 points for the audience.

      Author's profile photo Ramjee Korada
      Ramjee Korada
      Blog Post Author

      Prasenjit Bist Haven't you got the links that talks about this agenda?

      1. Realtime validation BUT NOT about validation at SAVE
      2. Without reaching to transactional buffer
      3. Usage of PRECHECK
      Author's profile photo Prasenjit Bist
      Prasenjit Bist [Page 94]

     [ non SAP but may be even better]

      Will add more references once I get back to work as they are bookmarked on my work machine.

      Author's profile photo Ramjee Korada
      Ramjee Korada
      Blog Post Author

      Thanks .. None of the youtube links don't talk about the blog post agenda.

      No more duplicated information here. No need to respond. I am closing the thread from my end.

      Author's profile photo P B
      P B

      Read the PDF page 94 onwards you will get all the details. Thanks

      Author's profile photo Diego Valentino Valdivia Zaragoza
      Diego Valentino Valdivia Zaragoza

      This post is fantastic. Thanks for the great detail. I was not aware of the PRECHECK functionality

      Author's profile photo Florian Halder
      Florian Halder

      Hi Ramjee Korada,

      thanks for your blog. Very useful as always. 🙂

      Do you know if it is possible to display the message as its done by the framework, when the length etc. is checked. Instead of the big pop up.


      Field validation


      Thanks Florian

      Author's profile photo Ramjee Korada
      Ramjee Korada
      Blog Post Author

      Hi Florian Halder

      In fact, I have already mentioned the fields to be highlighted in the code.

      It works in OData V4 same as your expectation with same ABAP Logic.

      I am clueless how to do it in OData V2.


      Best wishes,

      Ramjee Korada

      Author's profile photo Florian Halder
      Florian Halder

      Hi Ramjee Korada

      thanks for the tip. Actually, I was aware of how to mark fields, but neither implemented it nor read your blog closely enough. 🙂

      Thanks Florian

      Author's profile photo Sunkara Naga Rao
      Sunkara Naga Rao

      Hello Ramjee Korada,


      Quite an informational blog..

      I have a query, is there any way, that we can capture the error that was raised in the precheck method,in the method again?


      Consider the scenario, where we create a validation in precheck during creation.

      1. If user clicks on create, check if the entry already present in the database table,
      2. If yes, give error 'Entry already exists, do you want to continue'?
      3. If user clicks on continue again, then check if the error message was already populated and then delete the old entry and create a new entry.

      I was unable to do the step 3. as I am unable to find whether error was raised earlier or not.

      Is there any way to achieve this? Can you please share your thoughts on this

      Author's profile photo Sunkara Naga Rao
      Sunkara Naga Rao

      I have tried read entities and check for the report and failed entries, but unable to get any values in reported/failed tables.