skip to main content
Corticon Studio: Rule Modeling Guide : Recognizing and modeling parameterized rules : Populating an AccountRestriction table from a sample user interface

Try Corticon Now

Populating an AccountRestriction table from a sample user interface

Parameterizing rules can improve reuse and simplify maintenance. In fact, maintenance of some well-defined rule patterns can be further simplified by enabling users to modify them external to Corticon Studio altogether. A user may define and maintain specific rules that follow the generic rule pattern (analogous to an instance of a generic rule class) using a graphical interface or database table built for this purpose.
The following is a sample user interface that could be constructed to manage parameterized rules that share similar patterns. Note, this sample interface is discussed here only as an example of a parameterized rule maintenance application. It is not provided as part of the Corticon Studio installation.
Figure 203. Sample GUI Window for Populating a Rule's Parameter Table
1. The user selects an Account for which the Account Restriction will be created. Referring back to our example, the user would select Airbus from the list box.
2. The user enters a specific business rule that provides the motivation for the Account Restriction. The prior example used no competitor securities and no tobacco securities.
3. The user selects the type of restriction being created. Our example used and
4. Once all components of the Account Restriction are entered and selected, clicking Add Restriction creates the restriction by populating the AccountRestriction table in an external database.
AccountRestriction table
Business Rule
No competitor securities
No tobacco securities
5. After adding a restriction, it appears in the lower scrolling text box. Selecting the Business Rule in the scrolling text box and clicking Delete Restriction will remove it from the box and from the table.
6. The checkbox indicates an active or inactive Business Rule. This allows the user to deactivate a rule without deleting it. In practice, another attribute could be added to the AccountRestriction entity called active. A Precondition might filter out inactive rules to prevent them from firing during runtime.
Whenever you decide to maintain rule parameters outside of Corticon Studio, you run the risk of introducing ambiguities or conflicts into your Rulesheet. The Conflict Checker may not help you discover these problems since some of the rule data isn't shown in Corticon Studio. So always try to design your parameter maintenance forms and interfaces to prevent ambiguities from being introduced.