Understanding Application-Based Validation mode
|
|
The Application-Based Validation (ABV) mode of operation provides significant performance advantages over the alternative Ruleset Prerequisite-Based Validation (RSP) approach, which remains available and supported.
ABV mode is used to determine which rules are valid to reference at design time without having to use ruleset prerequisites. ABV is recommended in order to close the gap between design and runtime.
An ABV ruleset can reference all rules in rulesets defined in the same application and rulesets belonging to any built-on application.
In this simple example, all ABV rulesets are assumed. Each shaded or unshaded cell represents an application and each name represents a ruleset. With ABV, you have the ability to call rules both above and below the designated ruleset.
| Ruleset | Mode |
|---|---|
| LoanPricing | Can call all other rulesets listed. |
| LoanUnderwriting | Can call all other rulesets listed. |
| LoanPricingFW | Can call LoanUnderwritingFW but not shaded rulesets. |
| LoanUnderwritingFW | Can call LoanPricingFW but not shaded rulesets. |
The next example uses a mixture of ABV and RSP. Rulesets with brackets indicate RSP rulesets with their respective prerequisite. With RSP, you are unable to call an ABV ruleset not in the prerequisites.
| Name | Mode |
|---|---|
| LoanPricing | Can call all other rulesets listed. |
| LoanUnderwriting | Can call rules in all other rulesets including LoanPricing. |
| MyCoPL [MyCo] | Can call rules in MyCo but not in LoanUnderwriting, LoanPricing, LoanPricingFW, or LoanUnderwritingFW. |
| LoanPricingFW | Cannot call rules in MyCoPL, LoanUnderwriting, or LoanPricing. |
| LoanUnderwritingFW | Cannot call rules in MyCoPL, LoanUnderwriting, or LoanPricing. |
| MyCo[PRPC] | Cannot call rules in MyCoPL, LoanUnderwriting, or LoanPricing. |
As a best practice for design, your unlocked ABV rulesets should belong to one Rule-Application (but can belong to more than one version). This prevents ABV rulesets from referring to rules that may not exist in all applications that the ruleset is contained in.
Alternately, rulesets should be refactored into applications that are included as built-on applications.
New rulesets should always employ ABV, unless refactoring does not workâin which case, the ruleset may be set to RSP.
Versions in ABV works similarly to RSP. Within a given ruleset name, you cannot call rules in a higher ruleset version. For example, rules in App:01-01-01 cannot reference rules in App:01-01-03 (at design time). For versions across different ruleset names, the standard ABV logic is applied.
A branched ruleset is automatically set to the same validation mode as the non-branched ruleset. An ABV-branched ruleset can access all rulesets in the application, including other rulesets in the same branch, as well as any other branches included in the same application definition.
All branches within a given application definition, therefore, can refer to each other. On the other hand, rules in non-branched rulesets cannot reference rules in any branch.
Mobile and local rulesets have their own ruleset validation mode. If set to ABV, a mobile or local ruleset can refer to all rules in the application (or built-ons). An application ruleset cannot explicitly refer to local or mobile rulesets unless they are added to the application.
Note: Adding local or mobile rulesets to the base application ruleset is not recommended since non-local or non-mobile rulesets could call into the local/mobile rulesets.
Production rulesets get placed on top of the stack and can reference the application rulesets, although application rules cannot directly reference a production ruleset. A non-production version of the rule must exist for validation.
These ruleset types cannot be set to ABV.
|
application rule, ruleset |
|
Using the Application Explorer
How the system assembles your RuleSet list |