Repository-Based Application Development

Dr. Paul Dorsey, Dulcian, Inc.

 

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. Paul Dorsey is the founder and president of Dulcian, Inc. an Oracle consulting firm specializing in business rules and web based application development. He is the chief architect of Dulcian's Business Rules Information Manager (BRIM®) tool. Paul is the co-author of seven Oracle Press books on Designer, Database Design, Developer, and JDeveloper, which have been translated into nine languages.  He is on the Board of Directors of ODTUG, President of the New York Oracle Users Group and a Contributing Editor of IOUG's SELECT Journal.  In 2003, Dr. Dorsey was honored by ODTUG as volunteer of the year, in 2001 by IOUG as volunteer of the year and by Oracle as one of the six initial honorary Oracle 9i Certified Masters.  Paul is also the founder and Chairperson of the ODTUG Business Rules Symposium, now in its fifth year.