Repository-Based Application Development
I. Background
The Generalized Application Rule Processor (GARP) was built in
response to a specific need. At a client there were many different order types.
In addition, there were several different states (aspects) for each of these
orders (such as New or Existing). For each different order, substantively
different business rules applied, to which the application needed to adhere.
Using traditional development methods to support this set of requirements would
result in the creation of many separate applications which would be difficult
to build and maintain. In addition, changes to the business rules would create
an ongoing maintenance nightmare.
For this particular project, there was already an in-place
database integrated with Oracle Applications that was declared “fixed” for the
purposes of the project. There was no possibility for reengineering or making
any significant modifications to the underlying database. All business rules need
to be enforced exclusively through the applications. The only exception to this
was that the existing architecture did allow for the creation of server-side
code objects and views that could interact with existing database objects
without requiring them to be modified.
Other factors influencing the direction taken included the fact
that the current Oracle Forms development platform will be deprecated some time
in the near future. Within a year, any work done in Forms would have to be
rewritten in another J2EE or .Net-compliant environment.
For all of the reasons stated above, there is great motivation to
use an application development method that would allow for flexibility,
user-friendly maintenance of business rules, and support rapid migration from one
product architecture to another. To this end, it was decided to use a
repository based approach to the business problem.
II. GARP Underlying
Principles
There are several important underlying principles to understand
relative to the GARP system.
A. Logical Applications vs. Physical Applications
For this system, the client product was called a “logical
application” because when physical applications are constructed, there is no
requirement that there must be a physical application for each logical application.
In the current Oracle Forms environment, each logical application
and its aspects (for example Product A/New Order state) are passed as
parameters to the Oracle form. The Forms environment has limitations since it
is not possible to create or delete objects at runtime or directly move
boilerplate items (lines and labels). These limitations effectively mean that
the only things that can be conveniently manipulated at runtime are
Enable/Disable functionality or making objects already created on the form
Visible or Invisible. This means that an individual application is likely to be
necessary for each product type although separate applications may be desirable
for quotes since they involve co few fields. When the project is able to adopt
a more robust development environment (J2EE or .Net), it is likely that the
entire system can be supported with a single application, or a small set of
applications.
1. Repository-based Approach
Within the repository, the logical application and aspect defines
the collection of business rules that will be used in the execution of the
physical application.
Since virtually the entire system will be specified in the
business rules, in principle, it should be possible to run a single application
for all products and aspects that dynamically changes to support the entire
order entry process. In particular, the physical applications can be built in
such a way that they support one or more logical applications and their
associated aspects. If a very high-quality user interface is desired, there is
nothing to prevent the development of all possible applications independently.
One advantage of using this underlying architecture is the independence of the
logical and physical applications.
NOTE: The physical applications do not appear in the repository.
The repository only stores the logical application business rules. The physical
applications declare which logical application and aspect they are supporting.
B. Forms, Blocks and Items (Form, Form Block, Form Block
Item)
The terms “forms,” “blocks,” and “items” borrowed from Oracle
Forms represent the structure of the items impacted by the business rules. They
represent the overall list of items to be used on all forms. The existence of
these three tables, independent of the logical applications indicates that each
physical application will use a subset of the exact same collection of items.
This will not only enforce consistency across applications, but also provide
easy business rule reuse across logical applications and aspects.
In order to indicate which fields are used in which logical
application, it is possible to attach one or more forms to the application and
then exclude unnecessary blocks and/or items. This restriction of field
availability in specific applications makes rule specification easier since
developers do not have to sort through long lists of attributes to find the
appropriate ones.
Items that can be supported are text items, buttons and poplists.
C. Domains
Items and poplists can have domains assigned to them. These
domains can enforce datatypes, min/max value, format masks (although not all
features may be implemented in Version 1). It can also indicate whether or not
a numeric field needs to be converted from Metric to Imperial units depending
upon the unit of measure used for storing the object as opposed to simply
viewing the object. For example, a number indicating an actual number of items
or parts needs no conversion but measurements would need to be converted in
some cases. The domain of a field or poplist can be
changed dynamically at runtime by a business rule.
D. Rules
Rules are divided into two types: Event-based and Validation
1. Event-driven Rules
Event rules have two parts: an event triggering an action and the
action itself. These rules are created and stored separately so that actions
can be used with different events. Events can be triggered at the application,
block or item levels with different triggering events available for each level
and item type (field, poplist, button).
The triggering events for various types of events are shown in
Table 1.
|
|
Event |
|
Level |
|
|
Application-level |
Open Close Save |
|
Block-level |
Pre-query Post-query-each row Post-query-last row Mouse double-click |
|
Item-level |
Fields and Poplists: When-validate-item,
mouse-double-click Buttons: When-button-pressed |
Table 1: Possible Events
by Level
2. Validation Rules
Validation rules apply to fields and buttons. These rules are
triggered by the changing of a value in a field or clicking a button. Validation
rules have two properties: RULE_TX and ERROR_TX.
RULE_TX: May be a Boolean expression accompanied by an ERROR_TX.
If RULE_TX = False, an error is triggered and ERROR_TX is delivered.
Alternatively, RULE_TX can be a character expression. If the RULE_TX returns
“Null” , the rule succeeded; otherwise, RULE_TX fails and returns an error
message. This allows for complex handling of error messages.
a) Rule enforcement types
Validation rules are associated with one of three possible
enforcement types: Hard, Soft, Information. Both hard and soft validation
failures prevent execution of event-based rules. In the rules engine, there is
no difference between hard and soft enforcement rules other than the indicator
flag. However, there are function commands that can be used to find out whether
hard or soft validation errors exist in order to programmatically treat them
differently through rules. For example, users may want to ignore soft rule
violations when saving an order in process.
Both Hard and soft validation is handled by inserting a record
into a GLOBAL_TEMP_ERROR table and making a red button appear on the firm when
errors are present. The red button disappears when the last error is resolved.
Information rule validation is handled differently. Information
rule violations generate alert messages but have no other effect on further
processing.
Validation rules are only applied to text fields, poplists and
buttons. They do not apply at the application or block levels.
Validation may be placed on buttons to check various conditions
prior to the execution of the WHEN-BUTTON-PRESSED code. For example, it is
possible to check any number of validation rules on an order prior to saving
it.
Validation rules exist as independent objects and can be shared or
reused by different fields within different logical applications.
E. Actions
Actions can similarly be performed at the application, block or
item levels as shown in Table 2. Actions may be associated with Validation
Rules exactly as they are with Event Rules
|
|
Event |
|
Level |
|
|
Application-level |
Save Close Enable all fields Disable all fields Fire all when validate item rules Fire all validation rules |
|
Block-level |
Go-block Execute query Enable all fields in block Disable all fields in block Fire all validation rules Fire all when validate item
rules Display all fields Hide all fields |
|
Item-level |
Fields: Enable, Disable, Display, Hide, Set value (parse
an expression to set value), Make required, Make not required, New domain code
(sets new domain for field) Poplists: Enable, Disable, Display, Hide, Set value
(parse an expression to set value), Make required, Make not required, New
domain code (sets new domain for poplist, Set poplist query (parse query text to poplist) Buttons: Enable, Disable, Display, Hide |
Table 2: Possible Actions
by Level
III. GARP Data Model
Class and Attribute Descriptions
The following descriptions apply to the classes and attributes
contained in the GARP data model.
|
Class Name |
Description |
|
RO_LogicalApp |
A logical application being supported by this repository |
|
RO_Form |
A logical collection of blocks Not necessarily a physical Oracle form. Used to identify which
blocks and items are being used by which logical application. |
|
RO_FormUsage |
A declaration that some or all of the blocks and items
associated with a particular form will be used in a particular application. This table drives form, block and item selection in the user
interface as well as telling the engine which blocks and items should be
manipulated with actions such as “FireAllValid,”
which fires all validations in the application. |
|
RO_Block |
A physical group of items (buttons, fields, poplists) in an
application Corresponds to a block in Oracle Forms. |
|
RO_BlockUsage |
A declaration of the inclusion/exclusion of a particular block
in a particular logical application. In the user interface, when a RO_FormUsage
is created, all of its associated blocks automatically have RO_BlockUsage records created. When the Include_YN attribute = Y, this indicates that the block
appears in the logical application. If this is not the case, Include_YN should be set to “N.” |
|
RO_Item |
A physical item in an application (field, button, poplist) Note: RO_Item is abstract and is
therefore only a view and does not support Insert, Update or Delete actions. |
|
RO_ItemUsage |
A declaration that a particular item is used in a particular
logical application In the user interface, when an RO_FormUsage
is created, block and item usages for all blocks in that form are also
created with Include_YN = Y. If a particular item
is not used in a particular application, the user can set Include_YN
to “N.” This table drives the user interface item selection as well as engine
code that loops through blocks, forms and
applications, performing something on each action. Note: Exclusion of an item here does not necessarily mean that
no engine code will impact it. For example, if a BlockAction
attribute Display_YN is set to “N,” the underlying
code loops through all items so that the exclusion of an item here will
prevent that action from hiding the excluded item. However the BlockAction “Clear” is handled with a simple command
CLEAR_BLOCK, which will clear all items independent of their inclusion or
exclusion here. |
|
RO_Field |
A field in an application |
|
RO_Button |
A button in an application |
|
RO_Poplist |
A poplist in an application |
|
RO_Domain |
A specification of a format mask for a field |
|
RO_Rule |
A rule that governs the behavior of a portion of the
application. Rules are divided into two parts: a triggering event and
actions triggered by that event. A rule always has a single triggering event
so rules are typed by the event that triggers them. |
|
RO_RuleEvent |
A triggering event that causes actions to be executed. |
|
RO_EventApplic |
An Application-level event such as Open, Close, Save |
|
RO_EventPoplist |
An event triggered by something being done to a poplist such as WhenValidateItem |
|
RO_EventButton |
An event triggered by something being done to a button such as WhenButtonClicked. |
|
RO_EventField |
An event triggered by something being done to a field such as WhenValidateItem, MouseDoubleclick |
|
RO_EventBlock |
An event triggered by something being done to a block such as Prequery, PostqueryEachRow, PostqueryAllRows, MouseDoubleclick
on all items in the block. |
|
RO_RuleValid |
A validation rule which can be applied to any item or block Block-level validations are fired on WhenValidateRecord Item –level validations are fired on WhenValidateItem The rule in a validation is either a Boolean expression , in
which case, the Error_TX is the message associated
with rule failure or the Rule_TX is a text
expression in which case Rule_TX returns an error
when the rule fails and the Error_TX is null. It
returns Null when the rule succeeds. |
|
RO_Action |
An action that can impact one or more blocks and items in the
application Attributes: Display_YN ·
If Y, will unhide and enable indicated item or
all items in the block, form or entire application if the Usage tables
indicated Inclusion = Y. ·
If N, either hides individual items or groups
of items in the block, form or entire application if the Usage tables
indicated Inclusion = Y. Edit_YN ·
If Y, enables the item or collection of items
in the block, form or application. ·
If N, disables the item or collection of items
in the block, form or application. |
|
RO_ActionApplic |
Either an action applied to the entire application (e.g. Save)
or one that applies to all items or blocks in the application The only blocks and items impacted are those specified in the
usage tables as Include_YN = Y Attributes: Close_YN ·
If Y, closes the application ·
If N, nothing is done. FireAllValid_YN ·
If Y, fires all validation rules for all
blocks ·
If N, nothing is done. FireAllValidWVI_YN ·
If Y, fires all WHEN-VALIDATE-ITEM triggers at
both the class and block levels for the entire application for blocks and
items ·
If N, nothing is done. Procedure_TX ·
Executes the PL/SQL code using Execute
Immediate ·
Required_YN ·
If Y, makes all items specified in the Usage
tables as Included=Y required ·
If N, makes all items specified in the Usage
tables as Included =Y optional Save_CD ·
Executes either a Save (Commit) or a Rollback
as indicated |
|
RO_ActionForm |
An action that will be performed on all attributes in all
blocks of this form. The only blocks and items impacted are those specified in the
usage tables as Include_YN = Y Attributes: FireAllValid_YN ·
If Y, fires validation rules for all items in
the form ·
If N, nothing is done. FireAllWVI_YN ·
If Y, fires all WHEN-VALIDATE-ITEM triggers
for all blocks and items in the form ·
If N, nothing is done. Required_YN ·
If Y, sets all attributes to be required. ·
If N, makes all attributes optional. |
|
RO_ActionBlock |
An action that applies either to specified block or all items
within the block except where specified. The only items impacted are those specified in the usage tables
as Include_YN = Y Attributes: Clear_YN ·
If Y, clears the block and sets value of all
attributes in the block to “Null using a Forms CLEAR
BLOCK command. This applies to attributes not specified in the item
usage tables. ·
If N, nothing is done. ExecuteQuery_YN ·
If Y, executes a GO BLOCK followed by EXECUTE
QUERY ·
If N, nothing is done FireAllValid_YN ·
If Y, fires validation rules that block and
all of its items. ·
If N, nothing is done. FireAllWVI_YN ·
If Y, fires all WHEN-VALIDATE-ITEM triggers
for the block and all of its items. ·
If N, nothing is done. GoTo_YN ·
If Y, executes a GO BLOCK ·
If N, nothing is done Required_YN ·
If Y, sets all items in block to be required. ·
If N, makes all items in block optional. |
|
RO_ActionField |
An action applied to the specified field. Attributes: Assign_TX ·
Assigns the value of this expression to the
attribute FireAllWVI_YN ·
If Y, fires all WHEN-VALIDATE-ITEM triggers on
the field ·
If N, nothing is done. GoTo_YN ·
If Y, executes a GO ITEM to the indicated field. ·
If N, nothing is done Required_YN ·
If Y, makes the field required. ·
If N, makes the field optional. |
|
RO_ActionButton |
Performs an action on a button Attributes: FireWBP_YN ·
If Y, fires the WHEN-BUTTON-CLICKED trigger ·
If N, nothing is done. |
|
RO_ActionPoplist |
Performs an action on a poplist Attributes: GoTo_YN ·
If Y, executes a GO ITEM ·
If N, nothing is done Required_YN ·
If Y, makes poplist
required. ·
If N, makes poplist
optional. SetQuery_TX ·
Writes a valid 2-column query for the poplist and changes the list of values for the poplist at runtime |
|
RO_RuleGroup |
A group of rules and/or actions Because there is a many-to-many relationship between actions
and rules, and rules and the logical application, this class provides an
independent way of grouping rules and actions to make building applications
easier. For example, all Test rules are placed into a rule group called
“Test.” All rules associated with production applications will be placed in a
different rule group to avoid confusion. |
|
RO_ActionUsage |
A usage of a particular action in a particular rule. (Useful for debugging) Attributes: Active_YN ·
If Y, the associated action will execute ·
If N, the associated action will not execute ExecuteIfRuleTrue_YN ·
If Y or Null, action will execute rule only if
the rule in the triggering rule is True. ·
If N, executes only if the rule in the
triggering event is False. Order_NR ·
Actions will be executed in ascending order of
value in this field |
|
RO_RuleUsage |
Declaration that a particular rule will be used in a particular
application. This is where it can be indicated which permutation (aspect) of
the logical application the rule will apply to (e.g. Booked Order, Existing
Order). Attributes: Order_YN ·
If there are multiple rules of the same
triggering type for the same object, this specifies the order in which they
would be executed (rarely used) |
About the Author
Dr.