The CA Rule Engine inference engine invokes an Initialization Callback Method for resolving unresolved pre-condition field values.
Some situations where the callback method may be particularly useful are:
For example, in a large corporation, the rules may need to reference the management hierarchy for a given employee. There may be thousands of employees but for any given session, the rules only need to reference the managers associated with the given employee. In this scenario, it would be impractical for a client to initialize pre-condition values for all possible employees - on the chance that the rules might need to reference those employees.
Initialization callback is tied to a particular precondition field. To use the initialization callback feature, client needs to define the “onInit” method. The exact name of the method depends on the name of the field. For example, for a field named xYZ, the signature of the “onInit” method should be defined as the following:
public void onInitXYZ()
The CA Rule Engine inference engine invokes an initialization callback method only as necessary - as it actually needs values in order to make a decision. As such, the initialization callback is supportive of "first-chance" processing.
Any initialization callback handling logic implemented in the "onInit" method must not carry out any actions that modify the status of any of the rules. In a stateful rule session, the client method may optionally get any other objects from the rule session for inspection only. However, the client wrapper class may need to separately retain a reference to the stateful rule session object for that purpose in order to use the “getObject” calls of the stateful rule session.
Note: Adding new objects to the session does not modify the status of any of the rules. It is fine for the initialization callback method to add one or more new objects which serve as a value to an instance reference field that is being initialized. In fact, adding new objects that correspond to dynamic instances in initialization callback is more preferable to adding all needed dynamic instances upfront especially when the number of potentially needed dynamic instances is large.
The “onInit” method normally sets a value to the field for which it is defined. If the handling logic decides not to initialize the field, it can simply leave the field untouched.
The engine will invoke an initialization callback method at most once for each object and will cache the returned value for subsequent use. Client can avoid the invocation of a defined initialization callback method on a particular object by setting a non-null value to the concerned field of that object.
Even though in principle callbacks and rulebase design are not dependent on each other, there is a subtle effect on the use of initialization callback and application created dynamic instances related to rulebase design. This is due to the fact that initialization callback is only available at the field level.
If an application created dynamic instance is referred in rules through an instance reference field, that dynamic instance may be created and added to the session in the initialization callback method of that instance reference field. If such a dynamic instance is referred in rules only through class iteration, the dynamic instance must be added to the session prior to inference for the rule engine to be aware of its existence. Therefore, writing rules that refer to dynamic instances through instance reference variables may allow better flexibility on using initialization callback to create objects for dynamic instances.
For the case of class iteration, one can instead use an instance reference field in a container class that refers to a collection of that particular class. This instance reference field iterates over the collection so as to allow objects for client created dynamic instances to be instantiated in the initialization callback of that instance reference field.
| Copyright © 2009 CA. All rights reserved. | Email CA Technologies about this topic |