Enhance the Business Object Behavior With Validations
- How to define validations
- How to implement validations
- How to preview and test enhanced travel app
Prerequisites
- You need to have access to an SAP BTP, ABAP environment, or SAP S/4HANA Cloud, ABAP environment or SAP S/4HANA (release 2021 or higher) system.
For example, you can create free trial user on SAP BTP, ABAP environment. - You have downloaded and installed the latest ABAP Development Tools (ADT) on the latest Eclipse© platform.
In the previous exercise, you’ve defined and implemented a determination for setting the initial value of the field OverallStatus
to Open (O) during the creation of new instances of business object entity Travel.
In the present exercise, you’re going to define and implement two back-end validations, validateCustomer
and validateDates
, to respectively check if the customer ID
that is entered by the consumer is valid and if the begin date is in the future and if the value of the end date is after the begin date. These validations are only performed in the back-end (not on the UI) and are triggered independently of the caller, i.e. Fiori UIs or EML APIs.
Hint: Frontend validation & Backend validations
Validations are used to ensure the data consistency. As the name suggests, frontend validations are performed on the UI. They are used to improve the user experience by providing faster feedback and avoiding unnecessary roundtrip. In the RAP context, front-end validations are defined using CDS annotation or UI logic. On the other hand, backend validations are performed on the back-end. They are defined in the business object behavior definition and implemented in the respective behavior pools. Frontend validations can be easily bypassed - e.g. by using EML APIs in the RAP context. Therefore, backend validations are a MUST to ensure the data consistency.
Reminder: Do not forget to replace the suffix placeholder ### with your chosen or assigned group ID in the exercise steps below.
About: Validations
A validation is an optional part of the business object behavior that checks the consistency of business object instances based on trigger conditions.
A validation is implicitly invoked by the business object’s framework if the trigger condition of the validation is fulfilled. Trigger conditions can be
MODIFY
operations and modified fields. The trigger condition is evaluated at the trigger time, a predefined point during the BO runtime. An invoked validation can reject inconsistent instance data from being saved by passing the keys of failed instances to the corresponding table in theFAILED
structure. Additionally, a validation can return messages to the consumer by passing them to the corresponding table in theREPORTED
structure.Further reading: Validations