|
|||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
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 | |
---|---|
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. |
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:
|
|||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |