Subscribe

RSS Feed (xml)

Powered By

Skin Design:
Free Blogger Skins

Powered by Blogger

oracle search

Wednesday, May 7, 2008

JDev 11g new features - ADF BC Entity Object Validation Rules part 1 of 3

JDeveloper 10.1.3 saw the introduction of "Validators," a declarative approach to defining business rules and error messages against Entity Objects (EOs) within ADF Business Components (ADF BC). The declarative approach saves much coding and uses a well tested framework over writing custom validation code.

Documentation on this can be found within the Oracle Application Development Framework Developer’s Guide For Forms/4GL Developers under the section 6.7 Using Declarative Validation Rules.

The JDeveloper 11g Technical Preview (TP) edition introduces extended functionality which can be categorised under the tabs they exist within the Add Validation Rule dialog. This post specifically looks at the Rule Definition tab within the dialog. Refer to the above documentation on how to invoke the dialog.

The following validator types have been introduced in JDev 11g:

Collection Validator - this is a good addition but maybe poorly named validator - possibly Group By Validator or Aggregate Validator would be a better name. What it allows you to do is compute an aggregate value on an attribute in the current EO using an aggregate function such as Sum, Count, Average, Min or Max. The result can then be compared against a Literal, Query Result and so on like the Compare Validator.

How is this useful? Imagine a scenario where you have a business rule that says a training event shall only be stored in the database if there are 4 or more bookings. Creating a Collection Validator we can Count the number of bookings when the event is saved, and raise an appropriate error message if necessary if the bookings is less than 4.

Keys Exist Validator - in 10.1.3, it was possible for the user to change a FK child attribute (or in other words a detail attribute involved as an EO Accessor between two EOs) to an invalid value without the error being picked up until the data change hit the database and the FK constraint was violated. In 11g the declarative Keys Exist Validator allows us to check that the new attribute actually exists in another EO, or even VO, thus allowing us to validate FK values before they hit the database.

Expression Validator - provides validation of the EO against a Groovy expression. For more information read Steve Muench's post on Groovy Scripting Tips for ADF Business Components.

Within the existing validators the following changes and additional functionality have been added in JDev 11g:

Compare Validator - on selecting the Compare With field for a Compare Validator, there are now 3 new options: View Accessor Attribute, Expression and Entity Attribute. I'm unsure what the first option does, but the 2nd allows you to create a compare rule based on a Groovy expression, and the 3rd a comparison of the current attribute to any other attribute of the same datatype within the same EO.

List Validator - the Compare With field also introduces the new option View Accessor Attribute.

Length Validator - now allows the "Between" operator giving a minimum and maximum value constraint on the current attribute's length.

Regular Expression Validator - introduces the ability to select Predefined Expression such as email addresses and US phone numbers, as well as adding your own (this feature doesn't appear to work in the TP release just yet).

Unique Key Validator - has changed somewhat and now allows you to define validation on primary and unique keys defined for the EO (indirectly derived from the underlying table). In addition you may define multiple Unique Key Validators against the one EO where the 10.1.3 release limited this to one.

In summary the 10.1.3 release introduced the basic declarative validators against Entity Objects in ADF Business Components. Within the 11g release this has given the JDeveloper team the opportunity to go beyond the obvious validation requirements and give sophisticated declarative business rule validation still with the advantage of minimal to no coding required.

Part 2 and part 3 of this post will look at the other tabs within the Add Validation Rule dialog, namely Condition Execution and Failure Handling respectively.

Disclaimer: this post is written against the JDeveloper 11g Technical Preview (pre-production) edition. Oracle reserves the rights to remove or change this functionality in the final release so ensure to check your facts if you're using a later version when reading this post.

No comments: