Server-side Validation Vs Client-side Validation in Pega

In the last blog article, we talked a lot about different validation rules.

In this blog article we will understand about the different types of validation that is generic across applications (even non-pega).

This article was created using Pega '24 version.

There are two types of Validation

1. Server-side Validation
2. Client-side Validation

Look carefully at the below picture, you will see two types of validation.

First let’s understand the  Client-Server Architecture.

Imagine you logged into Pega application through a browser. When you start perform any user action, the browser sends HTTP requests to Server and Server using Rule engine executes the rules and processes the requests which the browser receive as HTTP response.

You can quickly validate this by performing the below steps.

Step 1: Login Pega with valid credentials from any browser.

Step 2: From your browser, start the developer console, network tab. Start the network tracing button.

Step 3: Launch any user portal from your Pega application.

Step 4: Check F12 again.

You can see a lot of HTTP requests. Why do you see this?

The browser sends the request to Server to build the user portal.

Okay it is clear that Pega is a web application that sends multiple HTTP requests to the server for its functioning.

Using the Desktop app, web app example, just think what can be the difference between server side validation and client side validation?! You can also use the introduction picture 😉

Server side validation:

Browser sends the HTTP request to server to perform the validation.

Client side validation:

Browser never sends any HTTP requests and the browser by itself performs the validation.

You may get a question, how come the browser knows about the application validation logic?!!!

Okay, lets start with the Client side validation first 😊

What do you mean by Client side validation?

In this type of validation browser never send any requests to server to validate. It means the code for validation is already pre-loaded in browser.

Now you may get a question. What do you mean by pre-loading? It means that the Client side validation depends on HTML or JavaScript code loaded  on the browser from the server side.

You see still there is a server call, but it is more like one-time when the page or screen is loaded. We will see more about it shortly!

What are the different examples implementing Client side validation?

Throughout this article, we will use simple Mortgage screen which we used in the previous article.

1. Enabling Required condition for a field.

You might have seen an orange asterisk for some mandatory fields in multiple web forms (pega & non-pega)

This is one of the client-side validation examples, where the validation fires at the browser side without any server call.

To quickly implement this, you can do it in case designer low-code way or from section designer cell properties.

In the App-studio, create field you can mark any field as ‘Required’

From the section rule, cell properties, you can mark the same.

Just use any one of the ways to mark FirstName as required field and make sure to save the rules.

Now let’s create a new case and test the Required field.

You see the First Name field is a required field now with the orange asterik.

If you just keep your curser in and tab out of the field, you will see the validation fires at the client side (very quick) and will see a default error message as “value cannot be blank”

How does this work like that?!!

A short hint, when the section is loaded in the browser, you will also see the right HTML markups attribute mentioning the field as required.

But this is just HTML right?! How does the validation fire?

I will reveal a little later after walking through a few more examples. Don’t scroll faster to the end, just continue!! 😉

2 . Using Edit validate rule

We already saw about this edit validate rule in the previous blog article, where you can configure the edit validate rule in the property rule form.

For the email field, we had the ValidEmailAddress added.

and we also noted that email validation fires as the client-side validation as soon as we tab out!!

Note: Normally Edit validate is a server-side validation rule but it can also act as a client-side validation! Wait for some more time to know the reason 😊

3. Configuration in property configuration

In addition, to edit validate configuration in the property rule form, there are other configurations as well that can serve as client-side validation.

Configurations like Property data type, max length can also act as validations.

The mortgage amount property is configured as Decimal data type.

Now if you navigate to the user portal and check the form, you can only enter decimal value in the Mortgage Amount field.

For other values like text input, it never accepts the input!!

There is another configuration Max length in the advanced tab. You can also control the length of the value and validate if the value exceeds the max length.

Just update the Firstname field max length as 8 and then try to see if you can enter maximum value to the field.

You will never be allowed to enter more fields.

Note: These act as client side only when these fields are used from the user portal. The validation will also work when these property values are updated from back-end processing.

Now we will look through the final client-side validation and this will answer some of your previous questions 😉

4. Custom JavaScript validation

At a very rare situation, you may need to use custom Javascript validation.

Just for the tutorial purpose, let’s take the example of ValidEmailAddress edit validate rule.

How to implement the same email address validation using custom javascript text files.

Follow these steps:

Step 1: Create a new JS text file rule with the validation function.

Step 2: Include the js file in the harness (specific to the form)  or your skin (specific to your application)

Step 3: In the Email property form, add an action-set for onchange/blur event that calls the validation function using runscript action.

Once you implement these steps, the validation can fire at the client side.

Reason is, that when the harness is loaded all the JS files included as part of the harness is already loaded in the browser and so the javascript on change function can trigger and execute the validation of everything on the client side.

Now you might have some idea regarding how all the above 3 client-side validation is configured.

Here is the Magic,

There is a text file called “pega-validators.js”

What this file mean?

This is a Pega OOTB final rule. This is referenced in a HTML fragment rule called ‘csvalid’.

This csvalid HTML fragment will be included in streams (Harness/Flowaction) that define client-side validation on field level.

So simply when client side validation is enabled on user form the script pega-validators.js is included in the browser.

Note: If you client-side validation doesn’t work on user form, this configuration can be the reason.

1) Explanation for Required condition validation:

If you see in the pega-validators.js file, you can see separate lines of code for required condition.

Here we are registering event listener kind for the events “onblur” and “onchange”.

Whenever we leave the focus from User name function “required_isFilled” gets invoked.

This function is responsible for invoking validation and sets error message if validation fails.

You can also explore the text file to understand about the data type validation.

2) Explanation for Email address edit validate

In the same pega-validators.js file, you can see separate lines of code for Integer data type.

Here we have a single event for Onchange.

So whenever we input any text value in User name the Onchange event triggers and executes the function “runEditValidate_isValidEmailAddress”.

You see it uses the regex function to validate if the input is a valid email address.

Remember to enable Client validation in Harness & flow action rule form.

Now you know how these client-side validation fires, all the code is loaded in the browser from the JS files.

What do you mean by Server-side validation?

This is the opposite of the client-side validation, where the browser always sends the request to server to perform the validation,

Mostly used when the validation depends on another property with complex logics.

What are the different examples of implementing Server-side validation?

1. Validate rule – we saw this in detail in the previous blog article

2. Edit Validate

Remember we also saw that the edit validate rule is a client-side validation as well! How come Edit validate rule acts as both server side and client side.

If you look at edit validate as a rule contains Java code and as a rule execution it can be executed only on the server side.

But as we saw in the ValidEmailAddress edit validate, Pega OOTB loaded or coded some of the edit validate rule to fire from the client side by loading the JS code in the browser via pega_validator.js file.

You can just search on the text file rule, you can find more details.

3. Constraints rule

We have analyzed thoroughly about Constraints rule in the previous article

4. Table type validation.

In property rule form, you can see an option called table type.

We can configure what are the acceptable values for the property.

For example, for Gender property we already configured the table type as ‘’male and female’ as local list.

In this way what you control is, you kind of restrict the applicable values for the Gender property as either ‘Male’ or ‘Female’. You can never set any other value to this property.

From the user portal, you can control it using UI control – For example as a dropdown, so that there is no chance that the user can enter any other value.

When this value is set from activity or backend processing, the validation can fire.

There are other values as well for the table type

a) Local List – When the acceptable values are very less. Ex: Gender – Male, Female.

b) Prompt List – Same as Local list, but here we can have Standard value & Prompt value. Ex: Country – IND as standard value and INDIA as display value.

c) Field value –

We can restrict the acceptable values within the field name.

Field value is a rule name in Pega. For example, you can use pyStatusWork fieldname and then the value will be restricted to use only the status work values.

There is an important field in property rule form.

If the Display alone is unchecked, then validation error appears if the value violates the acceptable values from the table type.

4. Class Key value – Validates the key against a particular class. Ex: To allow only valid operator ID in the drop-down. Add Data-Admin-Operator-ID as class key value.

5. Remote List – Validates against a particular instance of a class. Ex: Imagine there is class for countries and each country is represented by a unique key. All states for each country come with a page property ‘States’. You can allow the property to show the states as a dropdown for a particular country.

6. data page – You can also restrict the applicable values, you use the data loaded from the data page.

A final summary

What are the key differences between server-side and client-side validation?

The key differences between server-side and client-side validation are listed below

1. Server-side validation is mainly used to validate and display form-level errors (the entire screen validation), while client-side validation is used for field-level errors.

2. Client-side validation depends on javascript and may be turned off in some browsers, which can lead to invalid data saved, while server-side validation is very secure.

3. Client side is best when looking at performance, whereas server-side validation is best at security.

You can never avoid both. Know the difference between server-side and client-side validation and use it wisely.

Hope you are clear with the server side and client side validation.