Server side and Client side validation in Pega

Introduction

In this post we will learn about the server side and client side validation in Pega

We all may be aware of the Server-Client Architecture.

  • Here Client sends a request to Server.
  • Server responds with a response.

In Pega, we have 2 types of Servers:

  1. Application Server (Websphere, weblogic, etc,.)
  2. Web Server (Tomcat)

Clients can be of any browser session from which the user has logged in.

Imagine you logged into Pega though browser. When you start creating a case, browser sends request to Server and Server using Rule engine executes the rule and processes the request.

Testing Server – Client architecture

Step 1: Login Pega with valid credentials.

Step 2: Press F12 and move to networks tab. Start the network tracing button.

Step 3: Launch manager portal.

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 manager portal.

Now correlate this with Server side and Client side validation. Yeah you can answer it correctly.

Server side validation:

Browser sends the request to server to perform validation.

Client side validation:

Browser itself performs the validation.

You will see how to implement the server side and client side validation in this post 🙂

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 on the browser.

What are the different examples implementing Client side validation?

Throughout this post we will using a login screen as sample UI to implement different validation.

1. Enabling Required condition for a field.

Here in the Login section, enable required condition for Username and password fields.

Now you can see an Orange asterisk in the User portal.

When the user brings focus to the User name field and leaves without entering any value, we get an error message.

Remember in that section, we configured a condition like Required – Always.

So when the section is loaded in User portal, the HTML content gets loaded in the browser.

You can check out those in F12 developer tools.

Now you may want to ask me, “But, how come the validation gets triggered when the user changes the focus from the field?”

I will reveal at the end 😀

2. Configuration in property & control form

We can configure some fields in property & control form like data type, Max length, edit validate etc.,.

For example, for user name the data type is text & mac length is 8.

Now we can check the user portal.

We are not able to enter characters more than 8.

When you set the property type as “integer” and enter the text value, you get the error message as shown below:

Check F12.

Still you didn’t get clue how the validation fire after the focus left from that field. Coool…

3. Using Edit validate rule

  • Validate rules use only java code.
  • You should get a question, how come this can be used to validate at browser side.

Normally Edit validate is a server side validation rule.

Imagine in the login screen we need to provide only valid email address in Username field.

If they provide invalid address we should throw the error.

Now check at the user screen. Type any name without @ or .com and focus out, you will get an error.

4. Custom JavaScript validation

I am going to implement the same email address validation using custom javascript text files.

Follow these steps:

Step 1: Create a new js file with the validation function.

Step 2: Include the js file in the harness.

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

Now you may get 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 into 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.

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.

2) Explanation for Integer Data type property form:

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 “numeric_isInteger”.

3) 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”.

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

What do you mean by Server side validation?

  • In this type of validation, browser sends the request to server to validate.
  • Mostly used when the validation depends on another property with complex logics.
  • When the form is submitted, server validation fires. Depends on java code.

What are the different examples implementing Server side validation?

  1. Validate rule

We have analyzed thoroughly about validate rule in “Validate Rules” lesson.

  1. Edit Validate
  • As already mentioned Edit validate contains java code and it is a server side validation type.
  • It is added in the property rule advanced tab.
  • As seen in example 3 of client side validation, this can be invoked on browser side too.
  1. Constraints rule

We have analyzed thoroughly about Constraints rule in “Validate Rules” lesson.

  1. 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.

  1. Local List – When the acceptable values are very less. Ex: Gender – Male, Female.
  2. 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.
  3. Field value.

We can restrict the acceptable values within the field name.

4. Class Key value – Validates the key against 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 unique key. All states for each country comes with a page property ‘States’. You can allow the property to show the states as a dropdown for a particular country.

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.

What is the other difference between server side and client validation?

The key difference between server side and client side validation are listed below

  • Server side validation is mainly used to validate and display form level errors, while client side validation is used for field level errors.
  • Client side validation depends on javascript and may be turned off in some browser, which can lead to invalid data saved, while server side validation is very secure.
  • 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 🙂

10 thoughts on “Server side and Client side validation in Pega

  1. Hi Prem,
    I have a scenario where i need to validate a form with multiple feilds. I have been configured validate rule on each feild in a refresh section on change event, Now on change of feild 1 , validation error will be thrown and will be displayed in UI, on change of feild 2 validation error will be triggered in feild 2 but clearing the error message in feild 1 due to the refresh, how can I handle this (I want to retain all error messages)?
    Constraints
    1. Client side validation should not be used
    2.All the feilds should be kept in the same section

    1. Hi Jay,
      Based on your scenario, You need a validation a single field on OnChange.
      I will definitely go with client validation. (But it is a constraint fine :))
      You are refreshing on every field OnChange? It means you are hitting server on every field Onchange. that is a poor design actually.

      Anyways let me give a solution. I hope this is just for your learning. I dont recommend refresh the whole screen on every field on change in live environment.

      Assume you have 3 fields in a form – Name, Age, DOB
      Create single validate rule and validate all 3 fields individually with one of the condition as field value is not null.
      Include the rule in OnChange event.

      Now you are entering the form.
      Entire DOB as future date. Validate rule fires and throw error in the screen.
      Now Enter age as negative value. Validate rule fires. Here both DOB & Age are not null, So it validated both fields and throw error on the screen.

      There is not always a single solution in Pega. People think different.
      Other solutions are welcome 🙂

  2. Hi Prem,

    I have one question.How to validate Page Group Property ?
    Below is my scenario.
    In Clipboard i am having “ABC” page which is of type PageList.
    Inside “ABC(1)” i am having “XYZ” Page which is again PageList Property. Inside “XYZ(1)” i am having “PQR” page this is a pagegroup property , one of the property in “PQR” page is pySelected so my requirement is, on each page in Page group i have to check for pySelected property is true or false if all the property is false under the “PQR” page then i have to populate an error message.

    Can please help me how to validate page group property.

    Regards,
    Sowmya

    1. Since the structure looks very complex, In activity, I think you need to iterate the two page list and page group ‘PQR’ and check the values in each page in PQR pagegroup. You can then set the error message using page-set-message method.

      I really expect some alternative choices.

    1. Hi Ronali,
      When you choose run on client option, pega builds a javascript validation within the browser. You can check using F12 developer settings. So the javascript runs on client (browser). No need of any server trip!!

  3. Thank you for your post on Validations.

    So, whenever we create our own new Edit Validate rule, we can use it only for Server Side Validation, if we want to use it for Client Side Validation as well, we need to include the javascript code which works similar to java code that we have written in our Edit Validate rule and then include the java script code in pega_validators text file rule.

    Is my understanding correct ?

Leave a Reply

Your email address will not be published. Required fields are marked *