Vous êtes sur la page 1sur 8

Declarative processing simplifies your application and reduces the number of activities

you need to create. The declarative processing facilities support operation of six rule
types:
Constraints rules (Rule-Declare-Constraints rule type)
Declare Expression rules (Rule-Declare-Expressions rule type)
Declare Index rules (Rule-Declare-Index rule type)
Declare OnChange rules (Rule-Declare-OnChange rule type)
Declare Trigger rules (Rule-Declare-Trigger rule types)
Declare Pages rules (Rule-Declare-Pages rules type)
On the Application Explorer and Rules Explorer display, four of these rule types belong
to the Decision category. Declare Index rules support reporting and belong to the
SysAdmin category. Declare Pages rules belong to the Technical category.
Additional rule types contain "Rule-Declare-" in the rule type name or but are not
supported by this facility. For example, the Rule-Declare-DecisionTree rule type is
considered a decision rule, not a declarative rule. See Decision rules Concepts and
Terms.
Error:
Reference
source not
foundBasics
A declarative
rule describes a
computational
relationship
among property
values that is
expected to be
valid "always"
or "often" or
"as needed." In
practice,
declarative rules are evaluated automatically when needed to satisfy certain conditions.
These rule types differ in processing to offer you specific meanings of "often" or "as
needed."
The primary benefit of declarative processing is that the system, rather than the
developer, controls when computations are processed. Relationships between property
values can be expressed directly, without the need to create activities and design the
application to run the activities often.

Declare Expression rules


A Declare Expression rule defines a computational relationship among properties, such
as:
Area is computed as Length multiplied by Width
After you save a Declare Expression rule, you can be certain that thereafter the value of
the Area property, when accessed on the clipboard, is equal to the product of the values in
the Length and Width properties. Any change to a Length or Width value, regardless of
how the change occurs, causes immediate recomputation of the value of the Area

property. This works even if the update to Length happens indirectly.

Constraints rules
A Constraints rule records an expected relationship between property values, such as:
ActualExpense("December") is never greater than BudgetExpense("December").
As with expressions, the system monitors whether the constraint is met each time either
value changes. If the constraint becomes false, the system adds a message on the page
containing the left-hand property (ActualExpense(), in this case), marking the page as not
valid. Pages that are not valid cannot be saved to the database.

Declare Trigger rules


A Declare Trigger rule identifies processing to occur automatically when an instance of a
specific class is saved or deleted. (An activity with an Activity Type of Trigger
performs the processing.) For example, you can maintain the total month-to-date dollar
value of new work objects with a Declare Trigger rule. Each time a new object is
resolved, the trigger rule executes; the trigger activity runs and updates the total.
(Because this processing occurs in the current user requestor, make sure that the design
saves the total in a separate object, and that locking ensures that only one user can update
the total at a time.)

Declare OnChange rules


A Declare OnChange rule causes computation to occur when the value of certain
"watched" properties change. This may cause more frequent updating than a Declare
Expression rule. A Declare OnChange rule starts an activity that can perform more
complex or comprehensive computations than can be defined by expressions.

Declare Index rules


A Declare Index rule creates or deletes new objects in concrete classes derived from the
Index- base class. Like other declarative rules, the rule operates automatically and as
needed.
However, index objects support specific data-access needs rather than computation.
Accordingly, Declare Index rules are best designed by database administrators or Process
Commander developers with database experience. Unlike the other rule types described
here, Declare Index rules are part of the SysAdmin category.
Error:
Reference
source not
foundThe
Declarative
Network
display
Error:
Reference
source not
found

You can view a graphical presentation of the relationships among property values defined
through Declare Expression rules.

See About the Declarative Network display.


Error:
Reference
source not
foundDeclarati
ve rules are not
referenced
In general, no
other rules
explicitly
reference
declarative
rules. Your use
of a property
that's
referenced in an
expression or constraint rule causes the expression or constraint rule (and perhaps many
other rules) to run.
Error:
Reference
source not
foundThe
inference
engine and
dependency
network
Internally,
Process
Commander
uses an
inference
engine and an
internal data
structure known as the dependency network to support declarative processing. Two
properties A and B are linked in the network if the value of A depends on the value of B.
Inference engine processing operates invisibly, in the moment between activity step
executions. The step most recently executed may have changed a property value (and

cause forward chaining, defined below), or may have updated the database (and cause
Declare OnChange processing). The next step may need a property value that is not yet
defined, and so start backward chaining.)

Forward chaining
Forward chaining provides the automatic propagation of changes in one property value to
cause recomputations of another property's value.
For those Declare Expression rules with Whenever inputs change in the
Calculate Value field, the system creates an internal dependency network, identifying
which properties have values that may depend on which other properties.
For example, if the Area property depends on the Length and Width property, and the
Volume depends on the Area and Depth property, forward chaining causes the Volume
property to be recomputed each time Length, or Width, or Depth changes value.
Informally, the term forward chaining can apply to other automatic propagation of
changes, such as by Declare Trigger and Declare OnChange rules. When these execute,
they may in turn cause additional automatic processing to occur, 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.
Backward chaining applies to Declare Expression rules with the Calculate Value field set
to one of the following:
When used if no value present
When used, if property is missing
Whenever used
If the formula Area = Length times Width is set up for backward chaining with the
Whenever used option, then each time the system accesses the Area property for a
value the Declare Expression rule recomputes. This recomputation may occur more often,
or less often, than the inputs Length and Width change values.
If the system needs a value for Area through backward chaining, but Length has no value,
the chaining may continue using a Declare Expression rule for Length, and so on.
Alternatively, the application can prompt a user to enter a value.

Example
Standard rules support experimentation with backward chaining. These flow actions try
to find a value for the pyResolutionCost property:
VerifyProperty flow action
VerifyPropertywithListing flow action
PromptGoalSeekProperty HTML rule
VerifyProperty activity
These rules apply to the Work- class. The Property-Seek-Value method is the foundation
of backward-chained processing.

Debugging
Error:
Reference
source not
foundTo
produce
detailed
output from
the
inference
engine, use
the Set
Logging
Level tool
to set
logging for
the
following
class to
DEBUG:

com.pega.pegarules.engine.infengine.InferenceEngine
Error:
Reference
source not
foundLocatable
pages
A capability
called
locatable
pages reduces
the need for
pages to be
explicitly
named in the
rule. Locatable
pages can be
used with Constraints rules and Declare Expression rules.
References to properties on a locatable page use the locate keyword in lowercase as a
prefix or initial portion of the page name, as in:
locateCustomer.OrderAmount
At runtime, the system uses backward chaining and an activity with type Locate to find
and (if necessary) add the proper page to the clipboard. This eliminates the need for the
developer creating the when condition rule to specify the page.

Error:
Reference
source not
foundRule
resolution
When
searching for
declarative
rules, the
system:
Filters

candidate rules based on a requestor's RuleSet list of RuleSets and Versions


Searches through ancestor classes in the class hierarchy for candidates when no
matching rule is found in the starting class
Error:
Reference
source not
foundUsing
time- and
circumstancequalified
declarative
rules
You can use
time-qualified
and
circumstancequalified rule
resolution
features with Declare-OnChange, Declare-Expression, and Declare-Constraints rules.
The tools and utilities associated with declarative rules such as the Declarative Network
display, Rules Inspector, Tracer, and System Management Application are not limited or
altered by the use of declarative rule qualifications.
As with all circumstance-qualified rules, the base and circumstanced instances of
declarative rules have the same keys. Because declarative rules can be executed at any
time as a result of property references and changes, declarative rules run within their own
page context during evaluation and not within the context of a Primary page. Therefore, a
circumstance property reference in a declarative rule is evaluated relative to the rule's
page context and not the current Primary page.
For Declare-Constraints and Declare-OnChange rules, the key parts are Applies-To class
and Purpose. The base and circumstance-qualified instances must all have the same page
context references.
For Declare-Expression, the key parts are Applies-To class and Target Property. Page

Context is also used as a key when using a Page List or Page Group property. The
base and circumstance-qualified instances of a Declare-Expression must have matching
change-tracking and context execution strategies. In other words, the base instance and its
circumstance-qualified instances must all be forward chaining or all backward chaining,
and must all be context-bound or all context-free.
he following examples illustrate how context-bound and context-free expressions work
when using circumstance-qualified expressions.
A context-bound expression with a page context key: The Applies-To class is DataTransaction, the page context is .Item() and the page context class is Data-Item.
The expression is ".Tax = .Cost * .05" and the circumstance is ".State = MA". The
input, output, and circumstance properties are all defined on Data-Item. When the
application runs, the page context is an instance of .Item() embedded on a toplevel page of class Data-Transaction. For instance, setting
MyDataTransaction.item(2).Cost, the expression uses MyDataTransaction.item(2)
as the page context. The relevant circumstance property is MyData
Transaction.item(2).State.
A context-free expression: The Applies-To class is Data-Item, the expression is .Tax
= Cost * .05", and the circumstance is ".State = MA". The input, output, and
circumstance properties are all defined on Data-Item. When the application runs,
the page context is an instance of Data-Item, which can be a top-level page or
embedded in any page structure. For instance, setting
MyDataObject.ADataItem.Cost, the expression uses MyDataObject.ADataItem as
the page context and the relevant circumstance property is MyDataObject.State.
Setting MyDataItem.Cost, the expression uses MyDataItem as the page context
and the relevant circumstance property is MyDataItem.State.

When qualified declare rules are re-evaluated


Declare-Expression rules set to use the "calculate value whenever inputs change" option,
and all Declare-Constraints and Declare-OnChange rules use forward chaining to keep
their output properties current.
In most cases, a declare rule's circumstance properties and input properties are reevaluated in similar fashion. When a circumstance property's value changes, the
declarative network re-evaluates the expression or constraint. However, if a circumstance
property reference uses a top-level page name, changing that property's value does not
cause the declarative network to re-evaluate the expression or constraint.
Circumstance resolution occurs when the rule is evaluated, not when an input property
changes. For example, assume a Property-Set step changes an expression input and the
circumstance property (in that order). During forward chaining, the expression uses the
new circumstance value even though the input property was changed when the
circumstance property had a different value.
Declare-Expression rules invoked by Goal Seek or with any other "calculate value"
options use backward chaining. In this case, the expression is calculated only on demand.
Therefore, changes to input properties and circumstance values do not cause the
expression to be re-evaluated automatically. The circumstance is checked only when the
expression is invoked.
Time-qualified circumstance are only checked during expression evaluation. The passage
of time alone does not cause re-evaluation of declarative rules.

Vous aimerez peut-être aussi