Data validation in SAP Commerce Cloud as a nightclub bouncer

In SAP Commerce Cloud, like many customer-facing web applications, data validation can be implemented on different and multiple levels. Where to implement a certain validation, whether to have redundancy or not, and what the result of validation should be, can be overwhelming for the developer just starting out. To explain data validation concepts to junior developers, I often use the example of the nightclub bouncer.

Validation at the door

Although my bouncer example may suggest this, validation is not synonymous with security. In the analogy of the nightclub, having an entrance ticket (authorization) and showing ID to prove it’s you on the ticket (authentication) is done at the gate. Before entering the venue though, a check will be done if you’re ‘fit’ to actually enter the club. Are you the appropriate age? Are you intoxicated? Are you wearing the right clothes according to the dress code? Are you wearing clothes at all? These can be grounds for refusal. A nice bouncer will tell you the reason for not letting you in and how to fix it, but this is not guaranteed.

In a Java Spring application like SAP Commerce Cloud, this would be a Spring validator checking if the request (object) is valid to enter the application. It’s simple to integrate into the controller logic, and to either reject a specific value or a combination of values (you need at least one glittery piece of clothing, sir!)

An example:

Preparing for entry: frontend validation

The frontend itself can validate data input as well, before posting it to the server. In the club example, this would be the party organizer warning guests waiting in line of the dress code, age limit and other club rules in order not to get rejected at the door. Making sure to be fit to enter beforehand saves a lot of awkward situations at the door, but the bouncer cannot just rely on enforcement of (the most recent) club rules by the party organizer. The bouncer is employed by the club itself! Redundancy between frontend and backend validation is perfectly acceptable and in fact, desirable.

Maintaining internal rules

While the bouncer can protect the atmosphere of the club by refusing guests that obviously would not fit in or cause trouble, they can’t foresee all situations that could arise inside the club. Guests that originally ticked all the boxes to be allowed entry may lose their cool inside: they get intoxicated, rowdy and into an inappropriate state of (un)dress. Also, they may try to do certain things that are not allowed according to club rules. It may not even be guests causing trouble, but perhaps the bartender, the DJ or any other backstage actor! There is a need for internal validation as well. This may check for things that couldn’t be known at the door or check the same thing (redundancy). It’s important that inside of the application, we aren’t checking requests anymore, but the ‘state’ of objects. In SAP Commerce the club rules are ‘constraints’, which are enforced by a constraint validation engine. They can be inserted and activated at runtime but rely on either existing constraints & validators from the Java Bean Validation standard, or custom-built ones. The constraints can be configured with different severities: from a gentle suggestion to change or update a state (INFO), to a stern warning that the current state is undesirable (WARN) to an all-out intervention (ERROR) that will prevent the save operation from being completed. In the context of SAP Commerce Cloud backoffice, there’s the option to just return ‘false’ on a validation, but also to provide detailed messages and highlight fields in a Backoffice context, to show the user exactly what’s going wrong. The below example however is just a simple one:

The last line of defense

The deepest level of validation, let’s call this the backstage area, is on the datamodel itself. Here, there’s no runtime constraints and severity levels, there’s just a validation against the definition of the datamodel itself as defined in items.xml. By the time this validation is triggered, other validations have been bypassed, data has been corrupted and needs to be repaired. The police get involved! While certain states are undesired or not allowed at specific times during operation as they may undermine the business logic of the application, some states should never really occur, as they make operation itself impossible. For example, the identifying ‘ID’ field of some object might be mandatory on a database level as it can’t be found or modified without one.

For example: corrupted data, like a missing ‘ID’ will throw a validation exception during the model saving process.

ERROR [hybrisHTTP9] [DefaultWidgetInstanceManager] Error during send output
de.hybris.platform.servicelayer.exceptions.ModelSavingException: [de.hybris.platform.validation.interceptors.ValidationInterceptor@4087989d]:The attribute “ID” cannot be blank.

Summary

In summary, we’ve seen that different levels of validation check different things: pre-validating input data to prevent rejections, incoming requests adhering to a certain format or content, the state of objects on a business logic level and the state of objects on a technical level. Redundancy is often warranted here, as inner layers of the application cannot simply trust outer layers to have validated against all situations that may cause a corrupted state. In the example of the club, bouncers that are stern but informative and operate on every level ensure a good experience for the club as well as its guests.