Declarative, decision, and validation rules help automate non-procedural calculations, decision making, and data validation. Automating these steps helps to reduce the amount of required human interaction and error correction in a business process, improving efficiency and accuracy in an application.
| | Terminology |
What are Declarative, Decision, and Validation rules?
Declarative rules offer the ability to perform processing whenever the value of a specified property changes, or on other conditions.
Declarative rules perform their actions or calculations declaratively rather than procedurally. Unlike declarative processing, procedural calculation occurs only when the logical flow specifically calls upon it. In contrast, a declarative calculation occurs any time that its trigger condition is met, potentially occurring in the middle of other processing.
In the example shown, the value of the FloorArea property is recomputed automatically, every time the value of RoomLength or RoomWidth changes.
The results of the processing triggered by the declarative rule can trigger other declarative rules, in a "ripple" process known as chaining.
Certain declarative rules are executed only when an object is saved to the database, not every time a property value changes. This ensures that the data on the database is up-to-date, and can result in fewer recomputations than truly real-time declarative changes.
Decision rules compare the values of properties involved in the current work item to a list of conditions defined in the decision rule. Each defined condition is associated with a possible branch or action in the path of the process, which is followed if the condition is met. Decision rules often capture "if-then-else" style logical decisions.
For example, a decision table can determine which region of the country a customer is in (based on area code or zip code), in order to route them to the correct regional sales office.
Validation rules examine data values, ensuring that they meet the requirements of your application. When data fails to meet the requirements of your application, an error is reported, which can be used to take further action on the input, or reject the incoming data entirely.
Comprehensive validation of user inputs improves the quality of your application and increases application security, catching missing data or incorrect data as early as possible.
back to top
Key Features & Attributes
Four types of declarative rules belong to the Decision category.
- Constraints — Constraints rules provide data validation for properties after they are already inside your application. Any time the specified property changes, the constraints rule checks to confirm that the value still falls within the expected range.
- Declare Expression — Declare expressions establish functional relationships between properties, and compute the result any time one of the inputs are changed. Declare expressions ensure that any time an input is changed by any source, the result is always up-to-date.
- Declare OnChange — Declare OnChange rules run an activity any time that the value of a specified property changes.
- Declare Trigger — Declare Trigger rules perform an activity any time data of a specific type is changed in the application. For example, a declare trigger could be defined to flag a customer's account for review any time their address changed.
(Two additional rule types — Declare Page and Declare Index — have specialized functions, and are not part of the Decision category.)
Five types of decision rules are commonly used. While all perform the same essential function, each type is more natural to use in certain settings.
- Case Match — Case match rules give each option a score, according to a defined set of criteria. After the rule scores the criteria, the scores are compared to a defined cutoff score, and either the first option that meets the score, or all options that meet the score are returned.
- Decision Table — Decision tables compare property values against a list of conditions, and choose one or more actions from that list if the conditions are met. In the example, a decision table rule named RiskLevelTest is referenced in a flow.
- Decision Tree — Decision trees are functionally similar to decision tables, with the additional ability to create nested IF statements.
- Map Value — Map values convert input values in defined ranges into calculated results. For example, a map value could take a latitude and a longitude value as inputs, and convert them into the name of a city.
- When — When rules evaluate a statement, determine if it is true or false, and return that result. The true or false result can then be used as an input to other rules.
Validation rules not only have the ability to ensure that incoming data is valid, but also provide an additional layer of security. You can configure validation to occur either client side (if the data is being entered by a user), or server side (if data is coming from an external system).
- Client-side validation — Client-side validation occurs as a user is entering data into a browser. If a user enters data that is invalid or outside acceptable ranges, an error is raised than can be acted upon before the data enters the system.
- Server-side validation — Server-side validation occurs when data has entered the system from any external source, and cannot be validated beforehand. In this case, when invalid data is detected by a validation rule, an error is raised which marks the data as being invalid. This can be detected and acted upon by other rule types in order to correct or notify someone about the error.
These terms are important in the Declaratives, Decisions, and Validation category:
Server-side — Any operation performed on an application server, the server that supports Process Commander.
Forward chaining — Forward chaining is a type of declarative processing that automatically propagates changes in one property value to changes in other property values. For example, whenever the value of property BedroomFloorLength changes, the value of BedroomArea is recomputed; whenever BedroomArea changes, the TotalFloorArea property value is also recomputed, and so on.
Backward chaining — Backward chaining executes Declare Expression rules when a value is needed for a property, rather than when inputs change. For example, a value may be needed because the property appears as a source in a Property-Set method or as an input to a computation.
Decision task — A decision task is a shape on a flow rule that references a rule of one of three types:
- A map value rule
- decision tree rule
- decision table rule
At runtime, the system evaluates the decision rule to determine how a work object progresses through the flow. The work object progresses along one of the connectors leading from this shape, depending on the outcome of the decision rule.
Completeness — In a decision rule, completeness is defined as having every possible combination of decision criteria covered by an outcome.
Conflicts — A conflict in a decision rule arises when two elements of the rule form define identical input tests but distinct results. This situation indicates that the rule is 'self-contradictory' and needs to be corrected.
back to top
How to evaluate a decision tree rule and handle errors | September, 2004
How to configure a flow that prompts users to provide values needed for a calculation (backward chaining through goal seek) | October, 2007
How to qualify Declare-Expression, Declare-Constraints, and Declare OnChange rules | March, 2008
Using a Declare OnChange Rule | May, 2008
back to top