Validation

Question 1

Validation rules?

Answer 1

• Property rules are part of the Data Model category and are instances of the “Rule-Obj-Property” rule type.
  
  • Control rules are part of the User Interface category and are instances of the “Rule-HTML-Property” rule type.
  • Validate rules are part of the Process category and are instances of the “Rule-Obj-Validate” rule type.
  • Edit Validate rules are part of the Data Model category and are instances of the “Rule-Edit-Validate” rule type.
  • Constraints rules are part of the Decision category and are instances of the “Rule-Declare-Constraints” rule type.

Question 2

Levels of validation?

Answer 2

• Mode validation
• Dictionary
• Object
• Constraint
• Case
• Stage entry

Question 3

Features of Object Validation?

Answer 3

Object validation:

• occurs only when explicitly designed into the application
  a) a flow action rule calls a “Validate” rule
  b) called by a correspondence rule to validate user responses to prompts
  c) when the “Obj-Validate” method is called in an activity. This method executes a validation rule to test a set of property values.
• The validation error message invalidates the page, preventing it to be persisted.
• The display of the validation error message can be configured or customized.

Question 4

Features of Constraint Validation?

Answer 4

• based on declarative constraint rules
• evaluated automatically by the system each time a property identified in a constraint rule changes
• the system automatically adds a message to any property that is present on the clipboard and fails a constraint.
• No other rules explicitly reference constraints rules.
• When we save a constraints rule, Process Commander enforces it immediately and thereafter.
• We can create the constraints rule using any explorer.
• In the Constraints rule, use the “Constraints” tab to record the configurations that constrain the property values.
• can checks for a When condition
• “Else add message” allows us to add a specific additional message to become associated with that property or another property when the property fails the constraint.
• can use or build our own expressions for the when and constraint conditions.
• we may add more constraints by using the “Add new Constraint before this one” or “Add new Constraint after this one” icons.
• At runtime, when the system detects that a constraint fails, it adds a message to the page of the property identified in the left portion of the “Require That” field, if any.
• Because constraint validation is enforced automatically by the system anytime the property’s value changes, it might cause a performance impact. Therefore, it is critical to evaluate the potential impact before choosing this type of validation.

Question 5

Features of Case level validation?

Answer 5

• Configured on the Details tab of the Case Designer
• run when a case is instantiated and/or whenever the case is saved in the database.
• whenever we need to validate certain data for every saving of the case instances, we can configure it in the case designer once instead of needing to call the validate rule in multiple flow actions. (e.g When a purchase request is made, we can validate whether the parent case has enough funds to process this request before adding the case to the Program Fund parent case.)
• uses Work-Cover-.OnAdd (upon instantiation) and Work-Cover-.Validate rules (upon saving)

Question 6

Features of Dictionary Validation?

Answer 6

• can occurs automatically or when it is built into the application or at specific times during the process execution
• examines a property value in the context of the corresponding property rule.
• It includes multiple validation tests:
  1. ensure that the property value is compatible with its type.
  2. maximum length assigned to the property (available for Password, Text or Identifier)
  (clipboard keeps the longer value, but the dictionary validation adds an associated error message)
  3. “Edit Validate” rule which defines a Java routine that tests the validity of an input value. (available for “Single Value”, “Value List”, or “Value Group.”) Any architect who has java knowledge can build new edit-validate rules. Or we can use any of the standard rules that are available to us. (e.g. USZipCode)
  4. Control validation (data control)
  5. Table validations (only for Single Value, Value List, or Value Group) Table values can come from Local List, Field Value, Class Key Value, Remote List or Prompt List.
• Test is performed:
  • User input entered on an HTML form is placed on the clipboard.
  • The Page-Validate method (in an activity rule) is applied to a page containing the property, or to the property if it has mode Page.
  • An Edit Input rule and Property-Validate method (in an activity rule) is applied to the property. [An edit input rule provides a conversion facility. We can use edit input rules to convert data entered by a user (or received from an external system) from a format that our application doesn’t use into another format. We can reference an edit input rule in the Edit Input Value field on the advanced tab of Property rule.]

This type of control and display validation can be enabled in a user interface rule as well, under the “Presentation” tab of the cell, where the property is included. We can configure “required” fields validation in the “General” tab.

Question 7

Features of Mode Validation?

Answer 7

• enforces the property mode when a value is being assigned to a property
• combined with property type
• always in force and done automatically by the system

Question 8

Features of Stage Entry Validation?

Answer 8

• configured in the Case Designer.
• can be a validate rule or
• required attachments
  (e. g. validate whether all the data entry for the vendor information either filled by the requestor himself/herself or the acquisition department, before final approval by the VP).