Apply validations to ensure data integrity
Apply validations to ensure data integrity
|Description||Learn how to apply various types of validations in an application|
|Version as of||8.4|
While collecting input from users in Pega, validation helps ensure proper data is entered by users. This is critical for successfully processing cases. Validation is one of the most important parts of application development, because it helps the end user understand where they went wrong and how they should correct it.
Pega provides various types of validations which can be used based on the need. Below are the different types of rules associated in Pega:
- Validate rule
- Edit validate rule
- Constraint rule
- Through the property rule
- At section rule
Most important rule of Validations: Keep validation out of the UI layers
One of important best practices related to validation is to keep it out of the UI layers. It may seem easier to keep the validation at the control level but it makes it harder in the future. Validations that are embedded in UI layer don't work when a case is processed through other channels such as APIs, conversational channels etc. Avoid this mis-step by keeping validations out of the UI layer.
Determine the type of validation to use
It is important to determine the correct type of validation to use for a particular context. While defining validations for your Pega application ask the following questions to determine what type of validation to use:
- Is this validation needed for a field at every place its used? - use Field validation
- Do you want to apply a validation for a field which is calculated from other fields? - use Constraint Rule
- If a particular validation is needed only in a form while entering data? - use Form validation
- Do you want the user to stop entering a stage when few fields are not captured? - use Stage Validation
- Do you want to validate same conditions each time while saving a case? - use Validate on Case Save
- Is it needed to apply some validation before creating a case? - use Validate on Case Creation
Field validationIf a validation for a field is applicable at each and every place where the field is used in the application, use field level validation. The most common field level validations are taken care of automatically when fields are created from App Studio. When user creates a field of below types, field level validations are automatically added.
For an email type field, if the input value is not in proper email format, an error is shown. Similarly, for URL and phone type fields, unless a value with proper format is entered, error is shown at run time. User doesn’t need to do anything explicitly for this.
If user wants to add restrictions like max length for text fields, it can be added at the property rule. With this user won’t be able to add more characters than what’s defined while entering value for that field in the form.
If user need to add some other field level validations, user can create, or reuse Edit validate rule and associate with the field rule. Edit validate should be used only for format limitations or value range limitations. It should not be used for comparisons of one field against another, because edit validate rules are client-side validation and the other inputs may not be available at the time the edit validate rule executes.
All the field level validations we saw so far, are useful where we want to put some validation for a field, where an end user enters a value. But there could be a scenario where value of a field can be calculated from other fields which might be entered by user. There is another way to validate a field declaratively, whenever its value changes. It can be done by creating a constraint rule. Any time the specified field value changes, the constraints rule checks to confirm that the value still falls within the expected range. This validation should not be used for field which are simply entered by the user, rather getting computed from different fields which might be input by the end user.
When designing a case type, it's critical that a form meets all the required conditions before the form is submitted and the case moves to the next step. By validating the values of various fields in the form, app developers can ensure that at run time correct data is entered by the end user.For example, in a leave application form the leave start date should be always before the leave end date.
When a user configures a form in App Studio, they define the validation that will apply to the form which will include defining a set of conditions and an error message. When the set of conditions returns true, the defined error message is shown for the corresponding field after user submits the form (assignment).
When user creates validation from configure view for an assignment, internally it creates a validate rule. The auto generated validate rule is referred from the flow action of the assignment. For advanced validation configurations which are not supported from App Studio, user can open the corresponding validate rule and update the rule form.
Remember: Keep validations out of the UI Layer:
This form validation is applicable for the case through any channel including web, mobile or API and therefore is the best way to define validation for forms because it provides the most flexibility. If instead you use the option to mark a field as mandatory from the configure view in App Studio, the validation is restricted to UI layer. When the case is processed through an API or other channels which don't use this UI, the mandatory option won’t be applicable and will cause problems.
Moving from one stage to the next relies on capturing data or receiving required approvals or when a specific event happens. It is important to have validations defined which would let the user know when some required conditions are not met before transitioning to a stage.
Users achieve stage validation with simple configuration from the data model in case type. In App Studio, the validations tab can be found at in the data model of the case type. In the Validations tab user can view the fields and stages in a matrix format. Based on the stage and field for which user would need to define the condition, user can click on the corresponding cell. At run time whenever the defined condition would be true, the configured error message would be shown on top and beside the selected field. The condition would be evaluated before transitioning to the given stage and error would be shown when the condition returns true.
Internally this model driven stage validation creates a Validate rule pyOnStageEntry for the case type. For advanced stage validation configurations which are not supported from App Studio, user can open the pyOnStageEntry validate rule and update the rule accordingly.
For attachments, a user can define the validation condition to check if there is any file attached for a given attachment type field. If user doesn’t use attachment field and got only attachment categories, they can use "Attachments required for stage entry option" in case designer in Dev Studio to make sure attachment from the required categories are attached before transitioning to the next stage.
Validation on case creation
If you want to make sure few of the fields must be entered or want to mandate some relationships between few of the fields for a case being created, then case creation validation needs to be defined. To define case creation validation user can go to case settings and click on Configure for When case is created. This would guide the user to create a validate rule with ID OnAdd in the case type class. User can configure the validate rule to define the conditions and error messages. This OnAdd validate rule would be invoked automatically by case run time before creating a case. Like other validation scenarios when the condition would be met, it would show error and case won’t be created.
Validation on case save
If you have some condition which you would like to be validated whenever the case is saved, then validation on case save is the suggested way. To define validation on case save, user can go to case settings and click on configure for When case is saved. On click of that it would guide the user to create a Validate rule with ID Validate at the case type class. User can configure the validate rule to define the conditions and error messages as per their business needs. This Validate rule will get invoked automatically by case run time before the case is saved.
Please note, the difference between this validation on case save and form validation. If there is a validation condition which should be checked in all the assignments across the case type, then it makes sense to define it as case validation, otherwise form (assignment) level validations should be configured. Both can co-exist as well where the common validation conditions can be defined in the case save validation and the form specific validation can be defined at the form validation.