Configuring Data Validation in SAP Commerce Cloud Backoffice

Objective

After completing this lesson, you will be able to configure basic data validation rules within the SAP Commerce Cloud Backoffice, enforcing specific data entry requirements for various fields and attributes.

Introduction

​Imagine you're managing product data in SAP Commerce Cloud. Inconsistent or invalid data entry can lead to errors, inaccurate reporting, and frustrated users. This lesson shows you how to implement data validation rules in Backoffice to ensure data accuracy and consistency. ​We'll focus on using Backoffice configuration tools to define and modify these rules, preventing invalid data from ever entering your system.

Let’s have a look at three areas within Backoffice where the validation framework is working at different stages:

Introducing Three Major Backoffice Areas, Where the Validation Framework is Applied

Editor Area

​The Editor Area allows you to view and modify a business object, such as a product, by displaying attributes and columns via different tabs, sections, and panels, as you can see in the following screenshot:

In the Editor Area of the Administration cockpit, you can change the properties of a selected product via various tabs – in this case, the product is a digital camera..

​Validation in the Editor Area occurs at three stages:

Initial validation (on object load):
Whenever you load an object in the Editor Area, the system performs validation of all its values against their declared constraints. If there are any violations, it colors the respective editors and adds a proper violation icon nearby the attribute name.
After-typing validation (after each input):
If the validation engine finds any violation after you type in a value, it marks the current editor with the incorrect value with an icon and color respective to the severity
On-save validation (before saving):

The engine runs it when you click the Save button. The system validates all the editor values against the constraint rules and marks the erroneous ones with a relevant status. Additionally, when there is at least one validation violation, the result window appears. Violations are marked with color-coded icons (red for Error, yellow for Warning, blue for Info). Clicking the severity icon displays detailed information.

Let’s have a look at the results:

If there is no violation, the system successfully saves the object.

If all violations are either Warnings or Info (but there is at least one Warning), you can still save the object, but only after you approve the error. Alternatively, you could of course also correct the problematic input to get rid of the warning.

If there is at least one Error violation, you cannot save the object. Instead, the errors stay highlighted until you correct the wrong values.

You will see examples of Warning and Error popups in the next screenshots:

Two typical Administration cockpit validation pop-ups : The first is a warning offering the option to ignore and save”. The second is an error indicating the issue preventing the save operation.​

Extended Multi-Reference Editor

​The Default Extended Multi Reference Editor allows you to select multiple references of another type. For instance, it can be used to assign multiple price rows to a product, as you can see in the next screenshot.

Sample: Extended Multi-Reference Editor

The Extended Multi-Reference Editor manages the price rows assigned to a product and allows you to remove or edit each one.

​You can find similar validation functionality here, just as you have seen in the Editor Area. If any violation occurs, the validation engine highlights each row containing a violation with the color corresponding to the highest severity and a proper icon in the row header. On-save validation (before saving) is executed in two cases:

  1. On-row-save happens when you click the Save button in the row pop-up menu. It validates the whole edited row. If it finds any violation, it marks the row with a relevant status and shows the validation result window.
  2. On-global-save when you choose to save all your changes with the global Save. The system validates all changed rows. If it finds any violations, it shows a summary popup. The popup contains all violations for all rows.

Wizards

The Configurable Flow Wizard widget displays a step-by-step wizard. It is normally used in situations where different kinds of information are required from the end-user to accomplish a task. For instance, it can be used to create a new product, as you can see on the next screenshot.

Configurable Flow Wizard

A Configurable Flow Wizard is presented when creating a new product. It contains four steps, different entry fields for each step, and controls to navigate back and forth between steps and/or end the creation process and terminate the wizard.

Validation happens during initial load, after each input, and before navigation between wizard steps. The engine runs the initial validation against the current, not yet persisted object (For example, when you want to create a Product, the creation wizard might already show you initial validation errors of fields that should not be empty).

On-navigation validation: The engine triggers the validation when you click a navigation button in the wizard. When you click a particular validation error in the result popup, the mechanism takes you to the editor that contains the reported violation, even when the editor is in a different step.

When you click the Next button, the system runs validation against the qualifiers only defined for the current step. But when you click the Finish button, the system runs validation against all the defined qualifiers in all of the steps.

The system displays a popup summarizing violations. As always, Errors and Warnings prevent saving or navigation until resolved.

Creation of a Validation Constraint from Scratch

Let's create a simple example from scratch. Let’s assume we don’t want to allow a negative product price, as you can see in the following screenshot.

The Prices tab shows three assigned prices for a product in different currencies. The highlighted price, in Euros, has a negative value.

To avoid negative prices in the system, we need to create a new Attribute Constraint to ensure a product's price is always positive. We'll create a "Min Constraint" to enforce this:

  1. Navigate: In the Backoffice, go to System→Validation→Constraints.
  2. Then, we click on the chevron next to the "+" button to create a new constraint.
  3. We select "Attribute constraint", scroll down, and click on "Min Constraint".
On the Backoffice Constraints page, the caret next to the create new constraint button displays attribute constraint template the user may choose from. The Min constraint is highlighted.

In the configuration wizard, we set the constraint ID to "PositivePriceRow", and set the "Minimal value" to 0.

Then, we specify the "Composed type" as PriceRow and the "Attribute descriptor" as Price.

It should look like this:

The Backoffice creation wizard for the Min Constraint showing 8 properties in the first of two steps. The properties mentioned in the course material are highlighted. At the bottom, three buttons allow the user to move to the next step or end the wizard by saving or cancelling.

We click "Next", and on the 2nd screen of the wizard, enter the error message "Price must be non-negative".

The 2nd step of the creation wizard for the Min Constraint displays the properties “Severity” and “Error message” set to Error and Price must be non-negative respectively. Buttons to Finish the creation process or cancel appear displayed at the bottom.

After entering all these details, we click on "Finish" to save the new constraint.

After searching for our new constraint of via refreshing the list of validation constraints, it shows up.

As you can see, it is enabled but needs the validation engine to be reloaded to become actively enforced by the system.

The newly created Min constraint named PositivePriceRow appears in the list of Constraints, and the column showing the item seeds reloading is highlighted. Also highlighted is the button in the header to manually reload the validation engine.

Thus, we reload the validation engine to apply the changes to the active system.

Let’s switch back to the product.

Now, any attempt to save a product with a negative price will trigger the validation error message and force the user to enter a positive value, as shown in the following screenshot.

Note

As you can see, already negative-defined prices remain in the system, and assigned products also do not change. But as soon as you try to edit that price, you are only allowed to save it with a positive value.
The editor page for a product shows that a negative price has been entered. An an error pop-up is visible with the message: “Price must be non-negative.” The editor's “Save” button is disabled.

Let‘s have a look at another example of creating a validation constraint in the following video.

Good to Know

  • Attribute validation constraints are applied to items like Products, PriceRows or even Users. They are enforced by the validation engine and remain independent of any synchronization status.
  • Validation is only enforced on the Server side, and not applicable to client side entries (For example, end user website entries during shopping and checkout).

Summary

  • Configure validation rules based on out-of-the-box constraint templates in the SAP Commerce Cloud Backoffice to maintain data integrity.

  • Reload the validation engine to enforce new or updated constraints.

  • Three severity levels of validation violations (Error, Warning, Info) are supported with different impact on saving data.

  • Validation is enforced in 3 different Backoffice areas (Editor Area, Extended Multi-Reference Editor, Wizards).

Learning

SAP FacebookSAP YoutubeSAP LinkedIn