[Enterprise Extensions only]
  Previous topic

Rule attributes

Rule Name
Assign a name for the rule that is appropriate to its business context. Two different rules can share the same name as long as they are stored in different rule folders.
Rule Folder
The folder that contains the rule.
Start Date
This is the date and time at which the rule goes into effect. Prior to this time, it will not be found by trigger points. Together with the end date, the start date defines a period of time during which the rule is effective. A rule with no start date specified is not a valid rule and will not be found by trigger points.
End Date
This is the date and time at which the rule is no longer effective. After this date and time the rule is no longer in effect and will not be found by trigger points. Together with the start date, the end date defines a period of time during which the rule is effective. A rule with no end date specified is valid and will never expire.
Ready
Indicates whether or not the rule is ready to be used. Rules which are not marked as ready will not be found by trigger points. This is intended to be an easy way to keep a rule from being used until it is completely defined or to temporarily turn a rule off without having to change the basic rule data such as start and end dates.
Java Rule Implementor Name
This is the fully package-qualified name of a Java class that implements the BRBeans RuleImplementor interface. The fire method of the class performs the function of the rule. BRBeans provides several pre-defined rule implementors or you can write your own. Refer to the Rule Implementor Interface for more information on both of these choices.
Initialization Parameters
This is an array of parameters that are passed to the rule implementor to initialize it. Each element in the array can be any Object. This can also be referred to as the rule data, which is the external data that may change over time. The initialization parameters defined for a rule are passed directly to the init method of the rule implementor when it is instantiated. Refer to the Rule Implementor Interface for more information on how rule implementors can use initialization parameters.
Firing Parameters
Normally firing parameters are simply the parameters passed on the trigger point when a rule is triggered. However, it is allowed to override these parameters by specifying parameters on the rule itself. This is where these overriding parameters are specified.
Firing Location
This specifies where the rule implementor for this rule will be instantiated and run. Three values are allowed:
  1. Local: This option instantiates the rule implementor and runs it local to the trigger point (in the same JVM as the trigger point call). This would be on the client machine if the trigger point call is done there, or the server if the server part of an application makes a trigger point call. Use this option for the best performance since, once a rule is cached on the client, the entire triggering process can be performed locally without going to the server at all. The main disadvantage of this option is that the class files for the rule implementors need to be available on every client that can trigger rules.

  2. Remote: This will instantiate the rule implementor and run it on the application server where the BRBeans EJBs are installed. When using this option at least one remote method call will always be required to trigger a rule since the trigger takes place on the server. The advantage is that the rule implementor class files only need to be available on the server.

  3. Anywhere: This option will try to instantiate and run the rule implementor locally, and, if the class cannot be found, it will try to trigger it remotely.

Classification
For classified rules, this is the classification to which the rule applies. This is used when performing a situational trigger. Once a classification is computed for the situational trigger point, rules that apply to that classification are found and triggered. For more details see Situational Trigger Point - an example.
Classifier
Indicates whether or not this rule computes a classification. This is used where performing a situational trigger. A classifier rule is used to perform the first step of a situational trigger which is to compute a classification that will be used to find rules to deal with the situation. For more details see Situational Trigger Point - an example.
Dependent Rules
This is an array containing the fully-qualified names of the dependent rules of this rule. Dependent rules are rules that this rule can use when it is triggered. For more details see Dependent Rules.
Business Intent
This is a text description of the intent of this rule from the point of view of the business analyst. Any text string can be stored here.
Description
This is a text description of the rule at the programmer's level. Any text string can be stored here.
Original Requirement
This is a text description of the initial business analyst requirement of this rule. It can be used to keep track of why this rule was originally created, for example to keep auditing records. Any text string can be stored here.
User-Defined Data
A user-defined text string can be stored here. The format and use of this data is completely determined by the user.
Primary Key
Every rule has a primary key to uniquely identify it in the database where the EJBs are stored. Normally a unique primary key is generated automatically when you create a new rule. However, you can use the rule management APIs to specify your own primary key, if desired.
Precedence
This is the relative priority of this rule. The default finding strategy uses this value to order the rules found in the database, from lowest to highest, when more than one rule is found for a particular trigger point. Rules are sorted numerically by precedence with the numerically lowest precedence first and the numerically highest precedence last.

  Previous topic