Name: Understanding Additional Topics of Validation Framework in SAP Commerce Cloud
Uploaded: 2024-8-15
Duration: 595 s
Description: In this video, you will learn about Validation Framework in SAP Commerce Cloud and how to define constraints, in order to receive user-friendly messages in case of invalid data entries.

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div><div><div><div><div>In this video, you will learn about Validation Framework in SAP Commerce Cloud and how to define constraints, in order to receive user-friendly messages in case of invalid data entries.</div></div></div></div></div></div></div></div>

Understanding Additional Topics of Validation Framework in SAP Commerce Cloud

Hello! It’s common sense that systems that receive input from users should have some sort of mechanism to ensure that only sensible data is entered. SAP Commerce Cloud contains an out-of-the-box Validation Framework. It is based on Java’s own Validation Framework, defined in Java Specification Request 303. The Validation Framework allows the definition of constraints that will give operators a user-friendly message if they try to input invalid data. Further, it will enforce that only valid data is persisted. Moreover, unlike Java’s Validation Framework, SAP Commerce’s own implementation allows constraints to be created and modified at runtime. The SAP Commerce Validation Framework consists of a Validation Service, and a Validation Engine. The Validation Service contains operations that allow you to control the Validation Engine, create new constraint definitions, manage existing ones, and invoke the defined validation rules. It works like this: The Validation Service loads the validation engine with the registered constraints. These constraints can then be used to validate data. In fact, all model-saving operations are intercepted, and applicable validation rules are enforced, even interrupting the operation if any violation is found. Besides that, you can also explicitly call the validation methods of the Validation Service. And if any constraint is modified, or if any new one is created, you can also use the Validation Service to reload the validation engine, without needing to restart the server. There are two types of constraints out-of-the-box: attribute constraints, which validate a single attribute; and composed-type constraints, which validate an entire object involving multiple attributes. Examples of out-of-the-box attribute constraints include: Pattern Constraint, that validates an attribute against a regular expression. Past Constraint and Future Constraint, for time-related validations. Min Constraint, Max Constraint, Decimal Min Constraint and Decimal Max Constraint, for validating integer and decimal numbers. Size Constraint, for validating collections. AssertTrue Constraint and AssertFalse Constraint, for validation of Boolean attributes. IsNull Constraint and IsNotNull Constraint, for checking null values. And NotEmpty and NotBlank, for validating the existence of values in a String attribute. On the other hand, some of the composed-type constraints are: Xor Constraint, for ensuring that exactly one attribute value (of a group) in a given object is present and Dynamic constraint, that allows you to define a validation rule via a scripting-language. Each constraint can be assigned a severity level of Error, Warning, or Info. Error constraints cause a save operation to be interrupted. Warning constraints give the user a choice to either interrupt or to continue and save anyway. Info constraints will only show the constraint’s message and not affect the calling operation.  Constraints can optionally be assigned to one or more groups, or to no group at all. You can use the validation service to tell the validation engine which constraint groups should be used for validation. SAP Commerce Cloud contains the following out-of-the-box validation groups: A group that, by default, will validate all ModelService save operations. A default Backoffice validation group that will only be used in Backoffice. And two Product-Content-Management-related groups, used for the data-quality coverage dashboard in the Product Cockpit. Let me quickly create another constraint here. I’ll type in an appropriate ID. If you notice, I am creating a constraint to not allow a Product to have blank summary attribute. I’ll specify Product as the type to validate, and the summary attribute as the Attribute descriptor to validate. I’ll keep the severity level as error, and type-in an error message. Now, instead of assigning the constraint to no group at all, I’ll assign it to the default Backoffice validation group. This group makes sure that this constraint is only used in Backoffice. I’ll save the constraint and reload the validation engine.  I’ll switch to the Product Cockpit and select a product for edit, then clear the summary attribute value. You can see that the constraint is working. Please note, since the constraint is assigned to the Backoffice validation group, it’s only used in Backoffice, but not, for example, in ImpEx, or anywhere else outside of Backoffice.  Please also note the Data Quality section in the product editor here. There are 2 data-quality metrics of completeness regarding Product attributes: the Core Attributes group and the Marketing Attributes group. Currently, Core Attributes indicates 73% completeness for this product, and 3 attribute-constraint violations. Let me also assign the summary constraint to this group. I’ll go back to the administration cockpit and edit the constraint I created. I’ll now assign the constraint to pcmCoreAttributesCoverageGroup. Then I’ll save the constraint and reload the validation engine.  When I come back to the product cockpit and try to violate the summary constraint again, it’s now OK for me to save the product. However, the completeness percentage value is now lower and an additional constraint violation is displayed.  Similarly, you can also use the pcmMarketingAttributesCoverageGroup to check the completeness of a Product’s marketing attributes. Furthermore, SAP Commerce Cloud allows you to define your own custom constraint types. You just need to follow the steps below: Step 1: you need to define the new constraint type in a custom extension’s items.xml file. If you are creating an Attribute Constraint, make sure the commerce type definition extends AttributeConstraint, whereas a Type Constraint, must extend TypeConstraint. You can provide a description for the new constraint type. Always specify the annotation attribute as it is required in the constraint type implementation. Be sure to specify the modifiers just as in this example here. The most important part is the default value – it needs to refer to the fully-qualified name of the Java constraint interface you are going to define in the next step. Step 2: define a corresponding Java annotation interface in the custom extension. Here is an example. Remember to specify FIELD for an attribute constraint, or TYPE for a type constraint. Keep Retention as RUNTIME, as is required. For the Constraint annotation, specify the fully qualified name of the JSR-303 validator class that is going to contain the validation logic. We are going to talk about its implementation in the next step. You can define the default message as a simple string – use the key of the localizable default error-constraint-violation message property we will define in step 4. Leave the groups default value empty as it will be assigned a concrete validation group in the constraint instances later. And also leave payload empty, as it will be set via the severity level of the constraint instances. Step 3: implement the validator class. Remember, it was referenced in the annotation definition in step 2. It needs to implement the ConstraintValidator interface, with the interface name defined earlier as the first Java-Generics type parameter, and the type of the value to be validated in the implementation as the second type parameter. You can implement the initialize() method to prepare any context information necessary for the validation logic. Then, in the isValid() method, implement the actual logic to check the passed value, perhaps making use of the validator context. Step 4 is an optional step. If you specified any localization keys in step 2 for localized default constraint-violation messages, you can use the validationMessages.properties file, or one for a specific locale, such as validationMessages_de.properties for German, to specify key-value pairs for the violation messages. Write the message in the corresponding language, and use the curly braces to refer to the type or attribute name placeholders within the message. Step 5: define the type-group mapping in the validation framework via the project.properties file of the custom extension to indicate for what types of data the new constraint type can be used. Please note the naming convention here, use the custom extension name and the Java annotation interface name here within the key. Furthermore, the mapping should only be defined for an attribute constraint, but not needed for a type constraint. Also, depending on what data the validation constraint is checking, the type group value should be specified. The predefined type group values can be checked in the project.properties file of the validation extension in platform. Those are the 5 steps for creating a custom validation constraint. As a simple reference, you can use the Custom Validation Constraints trail in the commerce 123 trail to try out the 5 steps. Thank you for watching!