ADF Methodology Group post OOW08

Now that I'm flying back from OOW08, I've a chance to pen a few words about the ADF Methodology Group at the Unconference.

I was very privileged to be a part of the first live ADF Methodology Group meeting. As blogged by Sten and Avrom, we were very lucky to have 40 odd people turn up to help contribute to the first meeting, including day-to-day expert ADF programmers, Oracle ACEs and ACE Directors, and Oracle staff themselves. Thanks to everyone who attended, beginners and experts alike, and those who contributed directly and indirectly.

The success of any such group is always a sum of the great contributions from the parts, and there was enough active discussion to let us know what we're doing is going to help each other and new people to the group in running successful ADF projects. While the OTN Forums are great for talking about technical facilities, solving bugs and understanding JDev + ADF features, there's far more to discuss in order for an ADF project to succeed, and this is where the ADF Methodology Group fits in. What's the best way to test an ADF app, what infrastructure do you need, what should be part of your estimates, and so on.

I encourage anyone who is interested in JDeveloper and ADF to join the Google Group to discuss these sort of high-level discussions beyond the pure technical that all parties need in adopting new technologies, and to put effort into the Oracle Wiki page for the benefit of all.

We're already talking about holding our next meeting at the ODTUG conference next year, and hopefully we'll see even more attending the OOW session in 2009, including yourself.

Thanks again to all for your great efforts.

Phew, now I'd better go and do some paying work ;-)

Link to my OOW presentation

Thanks to everyone who attended my presentation at OOW08. It can be downloaded here.

OOW08: I think it's end of day 3

After than a less than amusing 3 hours sleep last night, day 3 of OOW08 was on the agenda. Today was some impressive presentations by the JDev PMs. Even though I've been searching the JDev 11g stack carefully for new features, Steve Muench revealed a massive (no over exaggeration) set of new features in ADF BC I hadn't yet found, Frank Nimphius a range of new security features to fit into WLS, and Juan Ruiz demonstrated the new ADF desktop integration (ADFdi) for Excel, a feature that potentially is going to make BI Publisher redundant as a reporting solution for ADF if the JDev team can in combination squeeze out a MS-Word equivalent.

It's so obvious there's a massive Fusion Apps development hiding somewhere behind the scenes at Oracle. The JDev team are pumping a huge amount of new and improved features into the ADF stack, and it's not because of the Enhancement Requests logged on the JDev OTN forum ;-)

I had a chance to sit in on Robert Nocera's Forms to JDev Unconference session, and in fact I bumped into Grant Ronald from Oracle UK who said all his Forms conversion presentations have been full. It seems Forms conversion is on the tip of everyones' tongues at Oracle Develop, given there are a number of solutions at OOW this year. What a shame the Apex crew are overselling theirs. Have you thought about telling people you can't convert the PL/SQL guys?

Tonight was the Oracle ACE Dinner, a relaxing event to talk to a diverse set of "really" qualified and interesting people. It's such a rare chance to meet so many dedicated people from around the world. Once again thanks to Oracle for organising this, it makes for a great OOW experience.

Like yesterday, Oracle Australia cornered more Australians at OOW today, and you can see Marcel Kratochvil interviewed on YouTube.

Today I did hear a rumour that Oracle has committed to Oracle 11g XE in the future, I'll need to confirm the fact though. Could this be Larry's big X announcement on Wednesday? (teehee) The 11g XE release will be a relief for all us presenters who use it to present. I suspect we'll need to wait till OOW09 though.

Wednesday sees the ADF Methodology kick off at the Unconference. We've 30 odd people registered which is great. Afterwards I'll be in the OTN Lounge for the Oracle ACE Office Hours between 12-1pm, and then squeezing in some more JDev sessions, followed by the Appreciation event.

No rest for the wicked (as much as you can call an Oracle "programmer" wicked).

OOW08: Day 1, or is that 2? I forget

Monday blurred. I missed the keynote (not my thing anyway), bumped into a number of Oracle staff and fellow ACEs and had a good chat (blah blah blah Doug ;), presented at 11:30 (I think it went well – no tomatoes), hit some good sessions (the new JDev DVT features are "way-cool", and I learned how SQL Dev is actually going to improve Apex in a way that vanilla-Apex fails), attended a whirl-wind Asia-Pacific (APAC) reception after-hours (um, what's with all the Aussies wearing suits?), and had dinner with user group colleagues to discuss some very interesting issues (SOA what?). Unfortunately I missed the OTN Night. Doh!

Tomorrow is purely tracking sessions I wish to attend, bugging Oracle staff for answers, then the Oracle ACE dinner which will be fun. Somewhere in there some prep for Wednesday's ADF methodology group.

Anyway, mostly a post about nothing, mainly for the people at home, who think this is a lark and I spend most of my time at the pub.

And just to prove I actually am in San Fran at OOW, you can catch me on YouTube or via the Red Room blog. Thanks to Gareth and Chi for organising this.

Usual disclaimer: I'm at OOW08 under the overly generous Oracle ACE Director program.

OOW08: Day -1: Jet Lag = 1, OOW = 1

Oops, forgot to post about Saturday in San Fran at OOW08.

One of the things I like to do when visiting another country is sit down and read some local newspapers to get a feel for what's happening locally. Though American news filters through the syndicated news channels back to Australia, the pure breadth of coverage is not there.

Of course the news in the States right now is all doom-and-gloom about the economy and Wall Street. Both papers I browsed were 75%, if not 95% about the economic crisis, with a large focus on stocks, federal intervention, politics and the blame game. I was surprised by the inclusion of The Wall Street Journal story As Times Turn Tough,New York's Wealthy Economize. "Oh boo hoo poor American rich people, you can't afford a nose job, I feel so sorry for you." It took me most of the day to find a story that considered the impact on the average American thanks to Time publishing Forget Wall Street. What about the rest of us?

Of course it's also a fascinating time with the race for the American Presidency, from both inside the States and out. One thing I've always found odd as an Aussie travelling to other countries is how patriotic other countries are, and in turn how much the general population is willing to visibly show their preference for political parties. Across from the hotel I'm staying at somebody has placed an Obama for President poster 8 stories up on a balcony nobody can see, and yesterday I spotted this poster near China Town. I just can't in living memory remember somebody in Australia putting something similar up, like a "I Love Kevin" poster, or a glowing picture of Little Johnny's glowing mug.

Of course OOW is far away from the local economic and political issues.

Saturday afternoon proved a great day to catch up with fellow Oracle ACEs and bloggers, Doug Burns, Tim Hall, Lucas Jellema, Marcel Kratchovil, with much speculation about the big OOW announcements.

Given that I've just sat in on the Sunday ACE Director meeting where some of the announcements have been either made or hinted at, it's a fun game to think back to our discussions yesterday to see how correct they were. Some of the announcements are completely embargoed until the keynotes so we can't talk about them. And as I have such poor memory of what we can/can't talk about, I'll keep mum till each keynote .

Monday's my Back to Basics Web Services presentation and the start of the Oracle Develop sessions I'll attend. Should be an interesting day as long as the jet lag doesn't kick in.

Disclaimer: I'm at OOW08 as part of the Oracle ACE Director program.

OOW08 Day -2: Jet lag = 1, OOW = 0

14,726 kms later (9,150 miles) I've touched down in San Fran for OOW08. Once again the epic battle between jet lag and OOW rages on. Today jet lag definitely wins with no sign of sleep on the plane. However over the next week the excitement of OOW will throw itself at jet lag, and we'll see who comes out triumphant.

All in all a rather silly post to let others at OOW know I've arrived and keen to catch up, so drop me an email.

Oh, and if anybody would like to recommend a good coffee joint San Fran downtown besides the usual franchises please let me know. Is it even possible to get a "flat white" in the USA?

JDev 11g ADF BC – New feature "Static List View Objects"

Following on from the Property Sets and Declarative View Object posts, another new feature in ADF Business Components in JDeveloper 11g is the "Static List View Object".

To create a Static List View Object, via the View Object Wizard you select the "Rows populated at design time (Static List)" option:


You then define the individual attributes of the VO yourself similar to a programmatic VO:


Then manually create the actual rows and attribute values yourself, hardcoded:


It's even possible to import the data at design time from the Import button on this same screen using a CSV file.

The key advantage of the Static List View Object is it's suitable for small datasets that never change. A great example would be gender values (M = Male, F = Female) or statuses (O = Open, C = Closed), or in Australia where the Australian State values are set at 8 (ACT, NT, NSW, QLD, SA, TAS, VIC, WA) and unlikely to change anytime soon (ignoring the obligatory "come-the-revolution" quotes ;).

Prior to the static list, in 10.1.3 one "hack" way to create a static VO was to create a R/O VO with a SELECT statement similare to following to load in some hard coded values:

SELECT 'a hardcoded value' FROM DUAL
UNION ALL
SELECT 'another hardcoded value' FROM DUAL

This was a kludge and required a database roundtrip to return the values. Simply not ideal.

With the new 11g feature, there's a valid argument that such data should be in fact stored in a database table anyway. Yet it's really upto you as the well-informed-programmer to decide what would be suitable for a Static List VO as separate to a normal R/W or R/O View Object. Note Oracle recommends in their JDev 11g documentation that the Static List is only suitable for 100 rows or less, otherwise use a database derived VO anyway.

I've also found Static List VOs suitable for stub VOs in creating ADF Faces RC web page mockups for demonstration purposes, where the database tables have yet to be designed. We instead create some dummy data Static List VOs, some web pages based on those VOs, and it looks like the pages are showing real data. A key problem with this approach though is if you then need to transform the Static List VOs into real database VOs, it's a pain in the butt, because you need to delete the Static List VO and all its dependencies, create the new database derived VO, and then plug this correctly back into the web page and bindings. Hint hint Oracle, a "transform" VO facility would be neat.

Note that Static List VOs are a great candidate for the new Shared Application Module feature, of which Avrom Roy-Faderman has recently posted about in part 1 and part 2.

10 things we probably wont see at OOW08

As I prepare for my next trip to San Fran under the overly generous Oracle ACE Director program, I thought I'd post 10 things we (probably?) wont see at OOW08:

1. Streakers
2. Sessions on "how to deal with your pain-in-the-butt DBA"
3. Larry's keynote rendition of the great oom-pah Chicken Dance
4. An exhibitor recommending their neighbour's solution over their own
5. Tom finally proposing a Developer-DBA hug-a-thon (awwww, give me a hug Tom!)
6. Oracle running on the EeePC (Oracle XEeePC, or ZeepC)
7. Oracle's 2nd standard presentation disclaimer slide replaced with "Our word is your guarantee – or your money back"
8. Out the door queues to get into the "OCI API in detail" session
9. Oracle announcing in its latest round of acquisitions, it accidentally bought itself (apparently Oracle was a great acquisition opportunity as Oracle had great database market share and now Oracle owns 107% of the database market)
10. Oracle staff wearing the new corporate tartan shirts (black on black doesn't count as tartan)

And just for the record, I started writing this post after last year's OOW. Incredibly trite humour like this takes a long time to prepare.

JDev 11g ADF BC – New feature "Declarative View Objects"

Following on from my Property Sets post, another new feature in ADF Business Components for JDeveloper 11g is the "Declarative View Object".

To create a Declarative View Object, you need a View Object based on an Entity Object, and under the Query page of the View Object Wizard or Editor, you set the SQL Mode to Declarative:


On switching a View Object to the Declarative SQL Mode option you'll notice the Wizard/Editor hides the SQL Query from you, instead providing an interface to modify the Where clause by selecting and/or constructing View Criteria, and selecting View Object attributes to participate in the Order By clause.


The key to Declarative View Object is they calculate the SQL statement to execute at runtime from the underlying Entity Object's database table and attribute database columns. With the previous Normal and Expert modes, the SQL query was effectively defined at design time by the programmer. The Declarative VO approach reminds me of how Oracle Forms works, in the fact that Oracle Forms uses the Block-table and Item-column mappings to construct the SQL statement at runtime; there is no complete SQL query you can look at design time in Forms.

The main advantage of Declarative mode is it removes the need to understand SQL queries, including the Where and Order By clauses. The query is now effectively hidden from the programmer.

I can hear a million Oracle programmers asking "why would we want to do that?" Taking the broad idea that not all programmers are born equal, and not all programmers know SQL, moving to a Declarative approach will assist such non-SQL-savvy programmers, as well as beginners or business users in working with ADF.

Another advantage is this approach uses the new 11g VO View Criteria feature in specifying the filtering Where clause. The View Criteria feature is a powerful one as it allows the programmer to name each Where clause essentially, and reuse that Where clause throughout the program, potentially in combination with other named View Criteria. For an example of this reuse have a look at how the new LOV controls in ADF Faces Rich Client support the defined View Criteria.

Obviously Declarative View Objects aren't for everyone, but they provide an interesting new feature extending the declarative programming concept in JDeveloper. Soon there wont be much programming left to actually do!

One caveat I need to state with this post, and I forgot previously with the Property Sets post, is this feature is currently available in the JDev 11g Drop 6 release (and potentially TP4) that the Oracle ACE Directors have access to. There's the possibility it wont be in the production release, but maybe we'll know for sure in a week or so.

JDev 11g ADF BC – New feature "Property Sets"

"Property Sets" are a new addition to ADF Business Components (ADF BC) in JDeveloper 11g. Property Sets are related to the extensible Custom Properties framework definable on EO & VO attributes, as well as at the EO, VO and & AM levels. If you're not familiar with the power and usage of ADF Business Component extensible Custom Properties look at my previous post I rest my case: Converting ADF BC EO/VO attributes to upper and lower case with custom properties or Avrom Roy-Faderman's post The Power of Properties.

Property Sets allow us to define a set of Custom Properties, essentially key value pairs, and then apply them to the ADF BC objects, without having to manually create each key value pair manually ourselves.

If we take a rather simplistic example, we could define a new Property Set "Alpha", with 2 properties "Beta" and "Charlie" as follows:

Then for example, we can select an attribute out of an EO or VO, and change the Property Set value to our new Property Set:

To prove the Custom Properties apply at runtime, without coding, within the Business Components Browser, we can right click on the attribute in question, and you can see a small information box that shows the runtime properties of the field, including the Property Set key value pairs we created.

This is obviously just a small new feature within JDeveloper 11g, but yet again a declarative productivity booster to stop the programmer having to waste time inputing values.

Is JDev 11g ready to replace Designer's table modeller?

There's been a few announcements recently that the upcoming version of SQL Developer will include database table modelling features. It seems to be a little know fact outside of JDeveloper circles that JDeveloper has had "offline" table modelling for sometime. The 11g release has expanded upon this feature set to include more options, that in turn make it (more of) a viable option to replace Oracle Designer physical database modelling.

(I suspect the upcoming SQL Dev modelling features just come from JDev anyhow, but I can't confirm this).

In particular in the 11g release we now see that offline database objects have support for normal tables, external tables, index organised tables, temp tables and so on through the radio group at the top of the screen:

In addition for normal tables when selecting the Storage Options button under the Table Properties subnode, we now have the full gamut of storage clause options for the table we're creating:


I know of a few Oracle sites that are holding onto Oracle Designer purely for its physical database modelling features only. Through the latest release of JDeveloper we can see there is the potential to drop Designer all together and go for the free JDeveloper. Now only if those sites could drop Oracle Forms too ;-)

Alternative OOW08 show badge Mikons

Justin Kestelyn through Matt Topper had the excellent idea of adding Mikons to the OOW show badges for 2008. I thought I'd propose some of my own, because as Justin says, Mikons negate the need for minor chit-chat when meeting new people at OOW.

Imagine all the minor chit-chat you're going to avoid wearing these beauties! ;-) Maybe you'd like to propose some of your own.

Like last year, it's a rather slow blogging time while I prepare for OOW and the AUSOUG conferences in October.

Splotlight on me about a spotlight on me

A small post to spotlight the fact that the OOW team published a spotlight on my upcoming OOW session.

How to convince others to adopt ADF & JDeveloper

Thanks to efforts on the ADF Methodology Google Group, I'm happy to announce that we've published a page on the Oracle Wiki entitled How to convince others to adopt ADF & JDeveloper.
This page is a colloboration of the group's members of which I'd like to thank for their kind efforts.

For those interested, the following blurb gives you an idea of what's covered in the Wiki page:

In attempting to convince others to adopt ADF, a brief-and-to-the-point discussion on the salient points of ADF are key. However care needs to be given to focusing on the needs, concerns and skillsets of the audience as much as the features to successful sell ADF & JDeveloper. The following [page] expresses bullet-point ideas to convince Oracle Forms Programmers, Java programmers, and management to adopt ADF & JDeveloper at their organisation.

The page then goes on to cover:

• How to convince "Oracle Forms programmers" to adopt ADF & JDeveloper
• How to convince "management" to adopt ADF & JDeveloper
• How to convince "Java programmers" to adopt ADF & JDeveloper

I hope you find the contents interesting and useful in convincing others to adopt ADF & JDeveloper.

A method for adopting OraFormsFaces for JDeveloper

Recently I had the luck of trying out Wilfred van der Deijl's excellent OraFormsFaces, a bridging tool that allows Oracle Forms sites to embed Forms within a JDeveloper JSF application and more importantly allows them to communicate with each other through standard Forms globals & parameters, and JSF EL expressions and events. Overall my client was impressed, especially thanks to Wilfred's kind assistance on sorting out some of the tricky parts of their Oracle Forms implementation.

I highly recommend organisations should look to OraFormsFaces to move beyond the analysis paralysis of where to move next after Oracle Forms. On adopting OraFormsFaces you will instead realise that rather redeveloping your entire legacy Oracle Forms system in JDeveloper or whatever technology, an expensive and risky task because you have many man years and dollars wrapped up in your legacy system, instead you can integrate Oracle Forms with JDeveloper, leaving JDeveloper for new subsystems.

As thanks to Wilfred, we'd like to publish documentation, on a method for adopting OraFormsFaces. We hope this will be useful to others out there looking at adopting OraFormsFaces in the near future.

Please note the following documentation is draft, your mileage may vary, and it should be read hand-in-hand with the OraFormsFaces documentation.

A method for adopting OraFormsFaces

The following describes a prescribed approach to adopting OraFormsFaces at your organisation in achieving the following goals:

• Minimize risk by identifying technical issues early
• Run OraFormsFaces in both an Oracle Forms Builder and OAS environment
• Reduce the learning curve for staff by breaking the adoption into manageable sections
• Identify approaches to integration for your specific legacy Oracle Forms system

The prescribed approach to achieve these goals:

1. Test the basic OraFormsFaces integration between a running JDeveloper JSF page and a compiled Forms Builder fmx.

This step will test you have correctly installed and/or configured:

• The OraFormsFaces Oracle Forms support files
• The OraFormsFaces JDeveloper support files and configured JDeveloper appropriately
• A JDeveloper application workspace with the required web.xml settings
• That the JDeveloper Embedded OC4J can communicate to the Oracle Forms Standalone OC4J
• The local Oracle Forms formsweb.cfg file with the new OraFormsFiles entries
• The local Oracle Forms Standalone OC4J can pick the formsweb.cfg options up
• Your browser to run with the Sun JVM

To achieve this test, as per the OraFormsFaces guide, setup a standalone development PC with Oracle Forms 10gR1/R2, JDeveloper 10g/11g. Create a test JSF page with an embedded OraFormsFaces forms component, calling a test dummy Oracle Form of your devising.

2. Test passing values from a JDeveloper JSF page to a Form's parameters and global constructs, and the Form returning values to a JSF page.

This step will test the data value passing between JSF and Oracle Forms using OraFormsFaces, including:

• JSF can pass values to a Form named parameter and named global (proven by Forms being able to receive and display those values in a text area)
• Forms can pass a value back to JSF bean (proven by JSF showing the bean value in an inputText control)
• Forms can execute a JSF command control

To achieve this test, extend the first step to get the JSF page to pass globals and parameters to the Oracle Form, and the Oracle Form to pass globals and parameters back to the JSF page. Do the following:

a) In your form create a block and 3 text items: p_some_param, g_some_global, p_some_jsf_value.

b) Also in the form add 2 buttons: update_jsf_page, exit_button.

c) In the when-new-form-instance-trigger add the following code:

IF :parameter.p_some_param IS NULL THEN
  :some_block.p_some_param := 'NULL';
ELSE
  :some_block.p_some_param := :parameter.p_some_param;
END IF;

BEGIN
  IF :global.g_some_global IS NULL THEN
    :some_block.g_some_global := 'NULL';
  ELSE
    :some_block.g_some_global :=
      :global.g_some_global;
  END IF;
EXCEPTION
  WHEN OTHERS THEN
    :some_block.g_some_global := 'DOESN''T EXIST';
END;

DECLARE
  v_some_jsf_value VARCHAR2(100);

  tableParams offParams.typeParams;

BEGIN
  tableParams := offParams.getParameters;

  v_some_jsf_value :=
    offParams.getParamValue(
      tableParams, 'someJsfValue');

  IF v_some_jsf_value IS NULL THEN
    :some_block.p_some_jsf_value := 'NULL';
  ELSE
    :some_block.p_some_jsf_value := v_some_jsf_value;
  END IF;
END;

d) On the update_jsf_page button add the following when-button-pressed trigger code:

offParams.setParamValue('someJsfValue',
  :some_block.p_some_jsf_value);
offInterface.execJSFCommand('someCommand');

e) On the exit_button add the following when-button-pressed trigger code:

exit_form;

f) Finally in the Oracle Form create a Form level parameter p_some_param, a String 30 characters in length.

In your JSF page add the following code:

<af:form>
  <off:form clipApplet="false"
            formModuleName="ORAFORMSFACESDEMO"
            height="480" width="640"
            showDevControls="true">
    <off:formParameter
      formParameterName="p_some_param"
      value="A param value"/>
    <off:formParameter
      globalName="g_some_global"
      value="A global value" />
    <off:formParameter id="someJsfValue"
      value="#{someBean.someJsfValue}"
      valueChangeListener="#{someBean.someValueChangeEvent}"/>
    <off:formCommand id="someCommand"
      action="#{someBean.someAction}"/>
  </off:form>
  <af:outputText value="#{someBean.someJsfValue}"/>
  <af:commandButton text="Submit"/>
<</af:form>

g) Add a backing bean to the ViewController (name: someBean, class: view.SomeBean, scope: request) with the following code:

package view;

import javax.faces.event.ValueChangeEvent;

public class SomeBean {
  public SomeBean() { }

  String someJsfValue = "A JSF Value";

  public void setSomeJsfValue(String someJsfValue) {
    this.someJsfValue = someJsfValue;
  }

  public String getSomeJsfValue() {
    return someJsfValue;
  }

  public String someAction() {
    return null;
  }

  public void someValueChangeEvent(ValueChangeEvent event) {
    int fish =1;
  }
}

On running the JSF page, you should see the Forms app embedded with the 3 values populated from the JSF OraFormsFaces parameters (ie. A param value, A global value. You should be able to update the value in the form, press the Update JSF Page button and see the value reflected in the JSF page outputText control, and vice versa.

It would also be good practice for developers to improve their understanding of the interaction of OraFormsFaces with JSF at this point to place breakpoints on each of the bean methods above, run your JDeveloper in debug, and watch the interaction of the above methods.

3. Extend the last step by trying to clip off the Forms menu and borders such that only the data contents of the form page show.

4. Test passing values from a JDeveloper JSF page to an actual Oracle Form from your legacy system, which requires both named parameters and global variables:

This step will help you:

• Understand how to identify parameters and globals in your Oracle Forms that OraFormsFaces will need to pass, as well identifying the actual parameters and globals and what values to pass.
• Run your first real embedded Oracle Form to see if it will work within OraFormsFaces.
• As extension of the last point, this will help you identify any problematic code that may need to be rewritten.

To achieve this test:

a) Identify the legacy system Oracle Form.

b) Embed the OraFormsFaces code into the Oracle Form as per the OraFormsFaces developers' guide.

c) Create a JSF OraFormsFaces page that passes in the relevant parameters and globals.

5. Test passing values from an actual legacy system Oracle Form to your JSF application.

This will step will help you:

• Understand how you will need to generically modify existing code to pass values back to JSF.
• Identify how different Forms programmers have traditionally passed values around your legacy system (though no exhaustively).

To achieve this test:

a) Identify the legacy system Oracle Form.

b) Embed the OraFormsFaces code into the Oracle Form as per the OraFormsFaces developers' guide.

c) Modify the existing Form to return values to the JSF page.

6. Once you are happy with the previous sections all done within Forms Builder, developers should attempt to move to an OAS environment testing their previous successes to ensure that the OAS is configured correctly to run OraFormsFaces.

7. If your legacy Forms applications uses embedded JavaBeans, for each Form embed it in a JSF OraFormsFaces page and test the form both in the Forms Builder and OAS environment, specifically exercising the JavaBean code. This will help identify any issues with the JavaBean called within the OraFormsFaces engine.

8. As an extension of the previous test, potentially the entire legacy Forms systems can be embedded and called from the one JSF OraFormsFaces page both in Forms Builder and the OAS environment. For testing purposes every legacy Form could be embedded with the OraFormsFaces code, then the main menu called form the JSF page, and regression testing undertaken to identify any issues.

9. By now you should have 3 documents you can produce:

a) Detailing how to setup your local Forms Builder environments to run with OraFormsFaces such that new developers and/or network admins know how to configure the development environment correctly.

b) Detailing how to configure your OAS to run with OraFormsFaces as per the developers' guide and any other configurations you need to do to suit your environment.

c) Detailing issues of where your current Forms application will need to be rewritten to work correctly within OraFormsFaces.

10. Finally at this point you're in a position how you wish to use OraFormsFaces for future development. There maybe a new subsystem you wish to implement within JDeveloper that needs to integrate with your existing legacy Forms system. There maybe a part of your existing system that you wish to redevelop in JDeveloper to make it easier for your users to use, but must still fit into your existing legacy Forms system. Considering any part of this last step is immature until you've gone through the previous steps to judge how well your system will integrate with OraFormsFaces.