Package com.ibm.websphere.brb.mgmt

Provides a framework to create, modify, and delete rules and rule folders.

See:
          Description

Interface Summary
IParameter Defines the interface for a parameter in BRBeans, either for use as an initialization parameter or a firing parameter.
IRule A business rule; an object that encapsulates the highly time and context-dependent behavior needed to ensure that work done with the application conforms to current business practices.
IRuleCopy An IRuleCopy is a copy of a Rule that does not persist changes to the persistent Rule until the method updatePersistentRule is called.
IRuleFolder A folder in which rules are contained.
 

Class Summary
_IRule_Stub  
_IRuleFolder_Stub  
ConstantParameter A constant parameter.
ErrorMessage This class represents an error message intended to be displayed to the user.
MethodCallParameter A parameter whose value is determined by calling a method the target object.
RuleMgmtHelper This class provides useful methods for managing BRBeans rules and folders.
TriggerPointParameter A parameter which is retrieved from one of the trigger point firing parameters.
 

Exception Summary
BRBeansIllegalArgumentException This exception is thrown when an illegal argument is passed to a BRBeans method on an IRule or IRuleFolder.
RuleChangedException This exception is thrown by IRuleCopy.updatePersistentRule() when the RULE_CHANGED_THROW_EXCEPTION option is specified and the persistent rule has changed since it was originally retrieved.
 

Package com.ibm.websphere.brb.mgmt Description

Provides a framework to create, modify, and delete rules and rule folders. To begin working with rules, the root  IRuleFolder must be retrieved. The root  IRuleFolder is retrieved by calling the method  RuleMgmtHelper.getRootFolder(). From the root rule folder you can add, delete, and retrieve folders and rules using methods on the  IRuleFolder  interface.

A rule folder contains instances of  IRules, which are also referred to as "rules". The BRBeans framework has two options for working with rules. The first option is to get a reference to the rule. The main advantage to using a reference is that you do not need to be concerned with the rule changing while working with the rule. This option is desirable if the intention is to make smaller updates to rules, such as changing a single attribute. Each change to an attribute results in a remote method call. So this option is not desirable if many changes are being made.

The second option is to get a local copy of the rule. Any changes made to the local copy will not be persisted until the user calls method IRuleCopy.updatePersistentRule()  on the local copy. When getting a local copy, an instance of  IRuleCopy is returned. A local copy of a rule is desireable in GUIs where the data is used mostly for display. Having a local copy prevents the user from having to make remote method calls to get each value out of the rule. This option is also desirable when changing a large number of attributes of the rule because the changes can be made to the real bean in a single remote method call (made during an  updatePersistentRule() ) rather than calling each set method on the remote object individually. Keep in mind that the local copy of the rule is just a copy; it may become inconsistent with the values in the persistent rule if changes are being made by users elsewhere on the system. The overloaded method  updatePersistentRule(IRuleCopy originalRule, int changeOption)  is used to handle this situation.

The ability to initialize a new rule with values from an existing rule is an important concept in BRBeans. This concept is useful when an existing rule is to be replaced by a new rule. Typically, the existing rule is first copied. Next, the expiration date of the copied rule and the start date of the new rule are set to the same value. Finally, changes are made to the new rule to exhibit the new desired behavior. The  IRuleFolder.createRule()  methods which take an IRule as a parameter are used to create a new rule with values from an existing rule.

Users of rules and rule folders are not required to start a transaction. However, if the intention is to wrap many changes into a single transaction the user may need to start a transaction. To discuss how transactions are handled we must break rules and folders into the following two categories: