Understanding Data Validation in SAP Commerce Cloud UIs

Objective

After completing this lesson, you will be able to explain the data validation mechanism available within SAP Commerce Cloud user interfaces and describe how it ensures data accuracy and integrity.

Introduction

​An essential business requirement of any data-rich application is that data be validated before it is persisted. This can be front-end validation as you type, or validation when you try to save. The validation process should result in user-friendly notifications that identify problem data and provide guidance on how to fix flagged issues. ​

SAP Commerce Cloud offers an easy to configure and extensible validation framework that ensures persistence only happens when the data conforms to certain validation constraints. As a Backoffice administrator, you can add your own validation constraints to help ensure that your site’s data is robustly checked before it is accepted in the persistence layer (the database).

Key Features of the Validation Framework

​A service (ValidationService) intercepts the service layer’s attempt to store data to the database and evaluates validation constraints. These constraints are integrated with Backoffice cockpits and perspectives, which provide relevant feedback to the user. ​Constraints can be managed in the Backoffice Administration Cockpit. New or changed constraints can take effect immediately upon clicking the Reload validation engine button, as shown in the diagram below.

Diagram showing the Validation Service, containing the Validation Engine, linked to a screenshot of the Administration cockpit, used to manage it, and two screenshots showing warning and error feedback. The button to reload the validation engine is highlighted on a screenshot of the button bar.

ValidationService

​The validation service loads the validation engine with constraints and invokes its logic. ​Constraints:

  • are evaluated on every save attempt by the ModelService, returning a list of violations that are displayed in Backoffice.
  • can abort the save operation if necessary.
  • may also be called explicitly (by developers).

After creating or modifying a constraint, you can use the Administration Cockpit to reload it into the validation service.

​Defining Constraints

​Based on the open source Hibernate Validator, the validation service allows you to create:

Attribute constraints
For example: The value of Object X’s field A must be between 10 and 20.
Type Constraints
For example: Object X is only valid if its fields A and B are set.
Dynamic Constraints
A Java BeanShell script that returns true or false (useful to developers).

In addition to dynamic constraints, developers can also create constraints by annotating Java classes or encoding them into XML Files. It can be useful knowing that’s possible, but we won’t cover those here.

​Constraints are defined with one of the following severity thresholds: Error, Warning, and Info. ​

Backoffice treats each severity level as follows:

  • Error: Critical error that aborts the save operation. The system will only allow saving the modified item once the error is resolved. Feedback is presented in red.
  • Warning: An indication there is something seriously wrong with the data, inviting the user to modify the item before saving. However, unlike Error-level violations, the user may override the warning and save anyway. Feedback is presented in yellow & orange.
  • Info: Does not affect the save operation. Feedback is informative in nature and displayed in blue.

Note

A developer manually processing constraint violations in the code must decide how to respond to the severity level of these violations.

Constraints can be assigned to Constraint Groups, which can be invoked in certain situations. For instance, the Product Cockpit uses a constraint group of Info-level constraints to display item coverage.

Available out-of-the-box Validation Constraint Types

​​Constraints are divided into two main groups:

  • Attribute-related constraints contain information about a constrained attribute. Use it when you want to validate a single field in a type.
  • Type-related constraints contain information about a constrained type, and they are used when you want to validate more than one field in an item.
The Constraints page in Backoffice allows the creation of the many subtypes of Constraint, organized as Attribute constraints and Type constraints. The chevron beside the + button shows these subtype groups, inviting you to expand the one you want to select the desired constraint type..

​Here are some out-of-the-box constraint templates you might find useful, and the use case each addresses:

​Attribute Constraints

  • AssertTrue / AssertFalse – ensure that value is true or false
  • Min / Max – test whether number is above minimum / below maximum
  • DecimalMin / DecimalMax – as above, but handles larger numbers
  • String notBlank / String notEmpty
  • isNull / isNotNull – as above, but for item references
  • Digits - ensures that value is at most x.y digits long, where you specify the values of x and y
  • Past / Future – validate values in comparison to current date
  • Pattern – validate using regular expressions
  • Size– validate size of strings and collections

Type Constraints

  • XorNotNull – checks that one, and only one, of two values is null.
  • Dynamic – similar to Pattern constraint, but intended for developers, as it evaluates BeanShell code at runtime.

Summary

  • SAP Commerce Cloud provides a robust validation framework to ensure data accuracy and integrity.

  • The ValidationService intercepts data save attempts and evaluates constraints defined in the Backoffice Administration Cockpit.

  • Constraints can be attribute-related, type-related, or dynamic, with varying severity levels (Error, Warning, and Info).

Learning

SAP FacebookSAP YoutubeSAP LinkedIn