| Oracle® Business Rules Language Reference 10g (10.1.3.1.0) Part Number B28964-01 |
|
|
View PDF |
| Oracle® Business Rules Language Reference 10g (10.1.3.1.0) Part Number B28964-01 |
|
|
View PDF |
Oracle Rules Engine runs as a library that an application or application component uses to work with rules. The application or component can include an application name in the configuration passed to a RuleSession constructor. With a name present, the name becomes the top level in a DMS hierarchy. This facilitates analysis of Oracle Rules Engine runtime.
In order to keep metrics for a RuleSession instance, the instance must have a name. A name for the RuleSession may be included in the configuration that is passed to the RuleSession constructor. If no name is specified and DMS is configured, then the Oracle Rules Engine generates a name.
This appendix includes the following sections:
Support for DMS instrumentation is encapsulated so that the Oracle Rules Engine uses a set of interfaces defined in oracle.rules.rl.dms. If a RuleSession is created with DMS enabled, then rl_dms.jar must be in the classpath otherwise RuleSession construction fails.
Oracle Business Rules DMS metrics are organized in a hierarchy that reflects the key components in a RuleSession. The path in the hierarchy to the metrics for a RuleSession is (application specified portions are in italics):
/appName/rules/rl/rule_session_name/
Under each RuleSession, there is:workingMemoryruleset/ruleset_name/rule/rule_name
where there are 1 or more rule sets. The ruleset named main is always present and 0 or more rules are shown for each ruleset. DMS Nouns are defined for rules, rule sets, working memory, rule sessions, and rl. DMS Noun Types contain DMS Sensors which contain the metrics.
Table B-1 shows the Oracle Business Rules Rule metrics.
Table B-1 Oracle Business RulesRule Metrics (RLRuleType)
| Metric | Description | Unit |
|---|---|---|
|
|
the number of activations of this rule that were added to the agenda |
ops |
|
|
the number of activations of this rule that were removed from the agenda. |
ops |
|
|
The number of activations removed by reset() or clearRule() |
ops |
|
|
The number of activations of this rule currently on the agenda |
ops |
|
|
The number of activations of this rule that fired |
ops |
The behavior of adding and removing activations from the agenda is that when a fact is updated, re-asserted, and the activation remains a valid match, the activation is removed and then added back. Thus, each sensor is incremented. This occurs because an update of fact results in two tokens flowing through the Rete network, a remove token and an add token.
If a rule is removed using the clearRule built in function, the RLRuleType instance for that rule is destroyed and any data is lost.
Table B-2 shows the Oracle Business Rules Ruleset metrics.
Table B-3 shows the Oracle Business Rules Working Memory metrics.
Table B-3 Oracle Business Rules Working Memory Metrics (RLWorkingMemoryType)
| Metric | Description | Unit |
|---|---|---|
|
|
The number of facts in working memory |
ops |
|
|
The number of new fact asserts |
ops |
|
|
The number of asserts of modified facts |
ops |
|
|
The number of fact retract |
ops |
|
|
The number of facts retracted by reset invocations |
ops |
Table B-4 shows the Oracle Business Rules RuleSession metrics.
Table B-4 Oracle Business Rules RuleSession Metrics (RLRuleSessionType)
| Metric | Description | Unit |
|---|---|---|
|
|
the number of rulesets that are defined in this rule session |
ops |
|
|
the number of reset invocations |
ops |
During initialization of a RuleSession, a reset is invoked so the number of reset invocations will always be one more than invoked by the RuleSession client.
The metrics from the RLRulesetTypes and the RLRuleTypes will be aggregated at the rule session level through the DMS roll up feature. Unlike RLRuleType, instances of RLRuleSessionType are never destroyed.
