The Oracle: ADF Business Components

Showing posts with label ADF Business Components. Show all posts

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.

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

This is the 2nd post in a 3 part series on the new Entity Object (EO) Validation Rule facilities in ADF Business Components (ADF BC) within the JDeveloper 11g Technical Preview edition. The previous post can be found here, and part 3 here.

The Validation Execution tab is an entirely new tab since the 10.1.3 release and provides the following new functionality:

Validation Level - under the 10.1.3 release validation was always fired at entity level and immediately. This was an issue if the user had yet to complete work in order to satisfy the business rule. Under 11g, if creating the validation rule at the EO level the Validation Option is available, and validation can be set to fire at entity level or when the transaction is committed. This provides the same sort of functionality and advantages as transactional deferred constraints in the Oracle RDBMS.

Conditional Execution - a Groovy expression may be added to the validation rule that when true enforces the validation rule. As mentioned in the previous post Steve Muench has posted on this under his article Groovy Scripting Tips for ADF Business Components.

Triggering Attributes - if the validation rule is defined at the EO level, one or more attributes can be selected, and if any of the selected attributes' values are changed the validation rule will fire. If the validation rule is created at an attribute level rather than EO level, this option does not appear but rather only the single selected attribute is assumed to be defined against the rule.

Available for Real Time Client Execution - this option is only available for validation rules that are defined against an EO attribute, not for validation rules at the EO level. At this stage I'm sketchy on what this feature does, but I'm guessing it indicates to ADF Faces Rich Client components that it is fine to implement and fire this validation within Javascript on the client side. This will have the advantage of saving a round trip to the mid-tier, with the disadvantage of performance loss on the client.

In summary the 10.1.3 release provided little declarative control over when a validation rule should fire. Within the 11g release the developer now has the ability to be very specific under which conditions a validation rule should enforce its business rules, giving a sophisticated declarative approach to business rule programming with little to no coding required.

Part 3 of this post will look at the final tab within the Add Validation Rule dialog, namely Failure Handling.

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

This is the 3rd and final post in a 3 part series on the new Entity Object (EO) Validation Rule facilities in ADF Business Components (ADF BC) within the JDeveloper 11g Technical Preview edition. Follow these links for the previous posts part 1 and part 2.

The Failure Handling tab is an entirely new tab in the 11g TP release and provides the following functionality:

Validation Failure Severity - errors are now categorised into errors and warnings. An "error" based validation rule if invalidated will display the corresponding error message and will not save the changes until the issue is fixed. Alternatively "warning" based validation rules will fire on exactly the same conditions, but if the validation rule condition is true, while an error message is still displayed, the transaction will not be halted. This provides a nice mechanism to give users informational messages about problems in the data they entered, but not stopping them from saving their work just in case the user knows more than the business rule assumes.

Message Text - this field allows the entering of an error message including positional message expressions (see below). This is similar to the 10.1.3 functionality of entering an error message to display when the validation rule is invalidated. However in the 11g release via the new Select Message button, you may in the associated dialog select an error message out of an existing message bundle file, or even create a new message bundle file. Of particular use this allows you to reuse existing messages defined once in a single message bundle, unlike the 10.1.3 release where error messages where stored in separate MsgBundle class files for each EO.

Error Message Expressions - error messages may include positional fields to be substituted when the error messages is displayed at runtime to make the message more meaningful to the user. The positional fields take the form {n} within the error message where n is a sequential unique number within the error message. The Error Message Expressions option is populated with rows as you enter new substitution variables in your message. The value for the message to be displayed at runtime is defined by a Groovy expression.

Note: the use of positional fields in error messages was supported in 10.1.3, but the dialog did not include this level of sophistication for specifying the fields nor adding Groovy expressions.

In summary within the 10.1.3 release the error messages associated with validation rules was a simple text message. In the 11g release the developer now has the declarative ability to easily parameterise error messages from a single standard message bundle with no coding required.

In summary to the 3 part post, the declarative approach adopted in the EO validators in JDeveloper 10.1.3 and expanded upon in the JDeveloper 11g Technical Preview release, within software development saves much complex coding and uses a tested framework over writing custom validation code that may be error prone (no pun intended). However if necessary the programmer still has the flexibility to drop back to code and write whatever functionality if deemed necessary.

JDeveloper documented "Recommendations"

Wednesday, August 29

JDeveloper documented "Recommendations"

I've been sitting on this post for a long time, 4 months in fact, as a back up post in case I'm too busy to write anything new. The next few weeks are such a time and it's about time I published this post before the imminent release of JDeveloper 11g Gold! (not that I know anything, but I'd be placing my bets on a November release date)

Oracle's JDeveloper team has to be commended for the large leap in the quality and breadth of documentation from the 10.1.2 to 10.1.3 releases, with the introduction of the ADF Developers' guides. In my opinion the effect of this has been noticeable on the JDev OTN forum where beginner questions have become thinner on the ground, possibly thanks to RTFM.

Of course now with so much documentation -- one such guide is over 1000 pages -- there is an awful lot to digest. Unfortunately within such a large set of documentation, Oracle's "JDeveloper Recommendations" and best practices can be lost or forgotten.

I recently took time out to search within Oracle's JDeveloper 10g provided documentation for any JDeveloper and ADF BC/Faces recommendations that they thought necessary to document. I provide a summary of the recommendations below to assist your JDeveloper experience, may it be a good one ;)

The mileage you experience from each recommendation may vary. Some are trivial, others encompass the whole development cycle.

Disclaimer: please note this is not a definitive list of recommendations, just my own summary. You should persist in regularly reading white papers, blogs and attending Oracle related conferences to keep up with the latest recommendations. If I've missed any of the recommendations you think crucial in the JDev documentation, let me know via a comment with appropriate links, and I'll update this blog. Also take time out to read the original quote in context of the actual JDev documentation by following the links.

Copyright disclaimer: the following quotes are all sourced from Oracle's own documentation and as such please respect their copyright if you source this page and acknowledge their efforts appropriately if you reference a section.

Final comment and appreciation: Thanks to Victoria Lira for her assistance in getting this post finally published.

JDeveloper recommendations
....(from the Oracle documentation set)

JDeveloper migration

Migrating Projects from Pre-Oracle9i Releases - Direct migration from pre-Oracle9i releases to Oracle JDeveloper 10g is not certified. We recommend that you first migrate to release 9.0.x (see the 9.0.x documentation), and then proceed from there.

Migrating System Settings to Oracle JDeveloper 10g - Select the settings and customizations you want to migrate. We recommend selecting all available options.

Projects

Working with Large Projects - It is strongly recommend to use ANT for such tasks as building and deploying.

ADF Business Components

Introducing Oracle ADF Business Components - In addition, if you are an Oracle Forms user, we recommend reading the following topic: About Oracle ADF Business Components: An Oracle Forms Developer's Perspective

Working with ADF Business Components in the Model Project - If you are comfortable with UML modelling, we recommend selecting Business Components Diagram, which provides a graphical interface for designing your business components. You can drag tables onto this diagram to create business domain components. For more information, see the Related Topics list.

ADF BC Application Modules

Accessing a Root - Level Application Module From an Entity Object - You can access a root-level application module directly from an entity object if the entity object is hosted by the application module. Generally speaking, this is not the recommend approach, as your entity object will only work with that particular application module. You might want to do this, for example, if you need to create rows of a view and insert new records in an entity object's doDML() method.

Creating a Package of Data Model Components - We recommend using packages to separate your data model components (view objects, view links, and application modules) from your business domain components (entity objects, associations, and domains). This allows you to reuse your business domain components with multiple sets of data model components. For more information, see the related topics list.

About Oracle ADF Business Components Packages - We recommend putting business domain components (entity objects and associations) in a separate package from data model components (view objects, view links, and application modules). This allows you to reuse your business domain components with multiple sets of data model components.

ADF BC View Objects

Understanding the Default View Link Consistency Setting and How to Change It - Conversely, you could globally enable this feature by setting jbo.viewlink.consistent to the value true, but Oracle does not recommend doing this. Doing so would force view link consistency to be set on for view objects with secondary entity usages that are not marked as a reference which presently do not support the view link consistency feature well.

Efficiently Scrolling Through Large Result Sets Using Range Paging - As a general rule, for highest performance, Oracle recommends building your application in a way that avoids giving the end-user the opportunity to scroll through very large query results. To enforce this recommendation, call the getEstimatedRowCount() method on a view object to determine how many rows would be returned the user's query before actually executing the query and allowing the user to proceed. If the estimated row count is unreasonably large, your application can demand that the end-user provide additional search criteria.

Consider Whether Fetching One Row at a Time is Appropriate - Caution - Unless your query really fetches just one row, leaving the default fetch size of one (1) in the in Batches of field on the Tuning panel is a recipe for bad performance due to many unnecessary round trips between the application server and the database. Oracle strongly recommends considering the appropriate value for each view object's fetch size.

How a RowMatch Affects Rows Fetched from the Database - Oracle recommends using database-level filtering to retrieve the smallest-possible rowset first, and then using RowMatch as appropriate to subset that list in memory

Creating a Calculated Attribute at the View Object Level - Ensure View Row Class > Generate Java File and Generate Accessors are selected. We recommend selecting Ex pose Accessors to the Client as well.

Adding a View Link Instance with a New View Object Attribute - Based Definition at Runtime - Note: This is the most flexible, but the most complex, way to create view link instances dynamically. If you have a view link definition or association that might be appropriate, we recommend that you use another method. For more information, see the related topics list.

Using Parameterized WHERE Clauses - In the Where field, enter a WHERE clause using parameters. Do not include the word "WHERE". Unless you are running against a non-Oracle database, we suggest you use Oracle-style parameters: ORDER_TOTAL > :1 + :2

ADF BC Runtime Properties

Oracle ADF Business Components System Properties # 1 - jbo.locking.mode - Note: In the case of session-oriented programs, such as web applications, it is recommended that the Oracle ADF Business Components property jbo.locking.mode should be set to optimistic unless you also set the RELEASE_MODE property to Reserved. Pessimistic locking is not compatible with Stateful or Stateless modes because the database transaction is always rolled back to allow the connection to be reused by another user. This results in the lock being released and makes pessimistic locking unusable. If you want to use pessimistic locking, you must set RELEASE_MODE to Reserved.

* and *

jbo.maxpoolcookieage - The maximum age of the browser cookies used to help clients retrieve stateful application modules. If these cookies do not time out, the value is -1. It is recommended that the max cookie age is always set less than or equal to the session cookie age. It is set that way by default (both are -1). If you change the the max cookie age then you must also change the session cookie age to the same value.

ADF BC Java stack

oracle.jbo.server.EntityCacheOverRowSet jdoc - getRow - use instead findByKey() for larger datasets

Note this discussion is repeated in:

oracle.jbo.common.ws.WSObject
oracle.jbo.client.remote.ViewUsageImpl
oracle.jbo.RowIterator
oracle.adf.model.generic.DCRowSetIteratorImpl

oracle.jbo.CSMessageBundle - In general, we recommend using EXC_INVALID_PARAMETER instead of EXC_INVALID_PARAM_NO_EXPL_GIVEN.

ADF Faces

The ADF Faces Dialog Framework - Note that we've also set "partialSubmit" on the commandButton to "true"; we highly recommend using this option on buttons that launch dialogs, as it avoids an otherwise unnecessary flash of the main page as the dialog is launched.

Configuring ADF Faces for Performance - In adf-faces-config.xml.....

When configuring ADF Faces for deployment, it is most critical that debug options have been turned off. Specifically: <> should be removed or set to false. oracle.adf.view.faces.CHECK_FILE_MODIFICATION should be removed or set to false. oracle.adf.view.faces.DEBUG_JAVASCRIPT should be removed or set to false.

* and *

The <> will show "You're in an English locale" if the locale's language is English. This means that in English, a user's version of the page will have an extra component over users who aren't using English; the state will vary accordingly. This sort of problem can cleanly be resolved by using "rendered" instead of <> , which is always a recommended JSF best-practice:

ADF Faces Page Definitions

What You May Need to Know About Binding to Values in Other Pages - While Oracle does not recommend this approach, you can access the bound values in another page's binding container from the current page using the data binding variable in an EL expression. The data binding variable references the binding context itself, which provides access to all the binding containers that are available. Use this variable when you want to bind to an object in the binding container of another page. The data variable must be immediately followed by the name of a page definition file that defines the binding container being referenced. For example: #{data.mypagePageDef.BindingObject.propertyName}

*and*

You may find cases, where you need to use the data variable to bind to values across binding containers. However, Oracle recommends that instead you use a backing bean to store page values and make them available to other pages. For more information about storing values in backing beans, see Using a Managed Bean to Store Information.

ADF Faces Components

+ oracle.adf.view.faces.component.core.CoreSubForm

We strongly recommend the use of a single <> per page, and using <> where you might otherwise be tempted to use multiple forms. Multiple forms require multiple copies of page state, and user edits in forms that aren't submitted are always lost. When a page using subforms is submitted, page state is only written once, and all user edits are preserved

ADF Faces Support Platforms

About ADF Faces Supported Platforms - Tip: On a UNIX server box, button images may not render as expected. Assuming you're using JDK 1.4 or later, we strongly recommend using -Djava.awt.headless=true as a command-line option with UNIX boxes.

CVS

About CVS and JDeveloper - We strongly recommend that you read the CVS Manual ("Version Management with CVS" by Per Cederqvist et al), which is freely available from www.cvshome.org

Note. Even if you know how to use existing checked out modules with JDeveloper CVS version control, you should not do so. We strongly recommend that you instead perform fresh checkouts from within JDeveloper.

Configuring JDeveloper for CVS - If you wish to use an external CVS client, we recommend the following: CVSNT 2.0.58a for Windows platforms - http://www.cvsnt.org/archive cvshome's CVS 1.11.9 for other platforms

New OTN article: Integrating JDeveloper and Designer's Table API

I'll tag this post under "another 23 + 6.2 seconds of fame".

Thanks to OTN, my article Integrating the Oracle Designer Legacy Table API with Oracle JDeveloper 11g ADF Business Components has been published, and even indexed on their front page.... be quick! I'm sure it'll be gone soon.

Without attempting to sound like a complete amateur, but indeed sounding like a complete amateur, it's pretty neat to be published at this international level. Up till now most of my articles and white papers have been published in the Australian Oracle User Group's (AUSOUG) magazine Foresight. Suddenly I've an article up in lights on the OTN front page, and for the record, a big cheesy grin to match.

My Mum will be so proud..... except she doesn't understand anything I do and listens with a blank look most of the time. I think I lost her way back in 1998 when I mentioned the acronym RDBMS.

Thanks to Justin Kestelyn and the Oracle team for accepting and editing the article, and putting up with my poor grammar, spelling mistakes, and outrages demands.

This of course makes me excited that hopefully Oracle will accept my next article, a romance-crime-mystery Oracle-Forms crossover.

The Oracle

Subscribe

Powered By

oracle search

Wednesday, May 7, 2008

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

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

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

JDeveloper documented "Recommendations"

JDeveloper Links

Labels

Blog Archive

Wednesday, August 29

JDeveloper documented "Recommendations"

New OTN article: Integrating JDeveloper and Designer's Table API

Labels

Archives