OBUG Connect, the Oracle Benelux Usergroup conference in Brussels.

Opening ceremony by Wim Coekaerts & Janny Ekelson.
Nothing much to say about this…

First keynote session was brought by Chris Leone about Oracle Fusion applications.
Applications is not my thing, but it was nice to see how everything in Fusion apps is integrated like BI and collaboration.

My first session was “The best way” by Tom Kyte, a session about doing things the “best way” or “best practices”.
Tom quoted Bryn Llewellyn on what brings you to best practices.
It depends on things from “reasoning skills” over “education” to “know oracle inside out” to “know pl/sql inside out”.

An example join two big tables(big… big tables) with little distinct values.
What will be the fastest(best) way to retrieve records for one of those distinct values: hash joins or index scans?
In a batch operation the hash joins will be the fastest, but on a screen that only shows 20 records?

So, when is something the best way?  Well, it depends…

How can you tune using TKPROF?
A best practice…
Get the facts(physical I/O, logical I/O, difference between CPU and elapsed time,…).
Infer more facts.  Know your data, know how oracle works.
Build your context.
Rule things out.
Very interesting session!

Time for lunch!

Next session was one of Lucas Jellema and Patrick Stevens: “Randstad’s modernization of organization, architecture and applications powered by Fusion Middleware”.
They explained how they transformed the IT team to work with the agile approach.
This resulted in a faster develoment(about 4 times) and a team that is more involved.
Randstad also decided to make their applications service based.
So a service layer was build around all core processes using BPEL and OSB.
The only problem is Forms, which still accesses the database directly.
The Forms application will fade away in the future to a web application in ADF…

Last session was another AMIS session by Luc Bors together with Simon Vos of bol.com: “How BOL.COM benefited from ADF”.
Bol.com decided in 2007 to move to ADF.
Some reasons to move:
- Oracle statement of direction:  exit designer
- no authorization/authentication
- forms supported datamodel, not business processes
Where did they want to go to:
- SSO
- new and extended UI
- add reporting
- no direct database access

So they introduced scrum, ADF and trained they’re inhouse (forms)developers to use JDeveloper, ADF and JHeadstart.
Now they could start to rebuild the forms application in ADF.
The pl/sql and built-ins used in forms are put in the database or, if lucky, they could use an ADF alternative.
Others(little percentage) had to be programmed in Java.

This resulted in a new application with the same functionality(allthough some additional functionality was added) as the forms application with a new look and feel.

Some interesting sessions, allthough I like to see some more demos next time.

Oracle Forms hanging problem

A customer had a problem about a forms application(Oracle Forms 10g) hanging on a regular base.
No particular user, no particular form, … just a form in the application at random.

The only solution was killing the browser and the JRE  and start over.

After a long time of searching, a colleague finally ran into a document on My Oracle Support.
It’s a combination of Sun JRE, Windows XP and a multi core CPU that causes the problem.

The solution is to let the Java process run on only 1 CPU.

Since the implementation of the solution(2 days ago) there are no hanging forms, while before there were several users reporting a hang every day.

More information and solution: My Oracle Support [Article ID 1245895.1]

 

 

Upgrading to Forms 11g

Grant Ronald has just published three references for Oracle Forms upgrades to 11g.
Those references can be found on his blog.

As Grant writes, it’s pretty easy to upgrade, just recompile and deploy.

A big advantage of migrating to Forms 11g is that it opens up the integration of the forms application with other technologies(eg. ADF).

Upgrade your Forms application and enter the age of fusion!

Oracle Forms Modernization Webinar on January 20, 2011

Do you want to know about the future of Oracle Forms?
And you want to know the official view of Oracle?

Check the webinar on this topic, hosted by Grant Ronald, Oracle Product Manager responsible for Forms.
More details and registration on Grant Ronald’s blog.

UKOUG: Forms Migration

There were a lot of sessions on forms, most of them handled about migration.
So, here’s a little wrap up of the forms migration sessions I followed on the UKOUG conference.

When thinking about migration, you need to think again before making a decision.
Do it for the right reasons, make a good analysis and plan everything upfront.
The right reason is not because there’s a migration tool that migrates everything.
Such tool does not exist.
This is what most experienced people will tell you, unless they sell a migration tool.
Allthough, this is even told by Steven Davelaar(Oracle The Netherlands), who gave two sessions:
- Guidelines for moving from Forms to ADF and SOA
- JHeadstart Forms2ADF generator: Moving form Oracle Forms to a best practice ADF application
Two very interesting sessions on migration.

The first session was about making the decision, the strategy and the pitfalls.
Before you even want to migrate, ask yourself the proper questions and make an analysis:

  • current situation: forms version, designer, how is it used(standard or “creative forms”),…
  • current functionality: integration with standard functionalities
  • current DB model & future plans
  • current UI: need for a redesign?
  • current documentation: if there is none, what are you going to migrate?
  • current end users:  how are they using the application, are they happy?
  • current IT staff: are they eager to learn? (everything will be new)
  • what direction to you want to move to: richer ui, customization & personalization,…

And start with the beginning: pull out the logic from forms!
Well do this anyway, this will leave all options open, no matter what presentation layer.

Migration has a lot of pitfalls, so watch out!
When migrating, a re-design and re-implementation is probably needed.
Steven ended that session with the following sentence:

Make lasagna (layered approach) and/or ravioli (service oriented approach) instead of spaghetti (like most forms application with code and business logic in forms and on the database)

The second session was about the tool JHeadstart and how it can help you in a best practice migration.
He reminded us on the monday session: define a strategy before you start!
He explained what JHeadstart was (not a migration tool!): an ADF generator and a best practice toolkit.
It generates metadata(XML), not code.
A part of JHeadstart is the Forms2ADF generator, it generates metadata from your forms application.
The demo he gave was pretty impressive, he took an old forms application (that he made in 2002) and generated a new ADF application.
But watch out, it doesn’t migrate everything: not one line PL/SQL is converted, it’s only documented though in JHeadstart.
You have to choose by yourself where to implement that code(business logic on the database, forms logic in the different ADF layers).
What are the JHeadstart benefits: autocreated ADF business components, metadata, best practice architecture.
Steven mentioned also OraFormsFaces, this an integration module to let your forms run in a JSF web application.
Definitly check this tool when you’re thinking about moving/integrating forms to/into ADF.

Another session on migration: “Is Apex the new forms?”
Not a great session, but they started also with the same idea as Steven: analyse before migrating and put all Business logic on the database.
The session was given by an employee of PITTS, so of course the migration tool of the company was shown.
This tool takes a form as input and creates an Apex import script.

It was not as detailed as the demo that Steven did about JHeadstart, but maybe it can be used as best practice.
The tool didn’t convince me…it even didn’t convince the speaker, as his conclusion was simple: “Is Apex the new forms?  No!  Or at least not yet.”
At least he was honest: the tool is no silver bullet and there are limitations.

Conclusion: when doing a migration, think…and think again.
Do you have good reason to migrate?
Then analyse.
Don’t try to find the silver bullet…

Designer and Forms 11g

More and more customers want to upgrade to Forms 11g, but then questions come like:
“There’s no Designer 11g, do we have to say goodbye to Designer?”
“Can we generate 11g Forms from Designer?”
“When we want to keep using Designer, do we have to stay on Forms 10g?”

A lot of questions…

What can we find on this topic?

First there is the  “Statement Of Direction” :

“As stated in earlier versions of this document, since Oracle Designer 10g there have been no
major new features although the product continues to be supported and development effort is
focused on stability and bug fixes. Oracle Designer is not released as a component of Oracle
Fusion Middleware 11g but will remain as a component in the Oracle Developer Suite 10g.
Future releases of Oracle Designer and support timelines will be within the Oracle Developer
Suite 10g release.”

There’s no new development, but Designer is still supported.
That’s some good news, we don’t have to throw away Designer right now ;-)

And of course there’s the Designer page on OTN, where the latest version can be downloaded.
The latest patch version is 10.1.2.6, released in May.
In the Release notes are two features that are very intresting concerning Forms 11g

“The Design Capture tool in Oracle Designer 10.1.2.6 captures Oracle Forms 11g FMBs.”

“Configuring Oracle Designer to Work With Oracle Forms 11g”

So, it’s possible to continue working with Designer 10g and start using Forms 11g.
Implementing or capturing new Forms 11g features(external events, new triggers like when-custom-javascript-event) will be a problem in Designer 11g.

Designer is a good tool to keep everthing centralised from ERD to Form and keep everything well documented.   I would not throw that away right now.

Feel free to add your thoughts on this subject…

Update on “Forms 11G and DB function with result cache”

In my previous post I mentioned the problem with compiling a program unit that calls a database function with result cache.

Like I wrote in that post, the problem exists in the PL/SQL Client version.
There’s a patch available to update the PL/SQL client: Oracle Database Server Version 11.1.0.7 Patch 33.

This is a database patch, but it can also be applied to the middleware home.

After applying the patch, the program unit compiles…Problem solved!

So, go and start using Result cache!

OOW 2010: Moving forms to ADF

When working with Oracle Forms these days and you’re not satisfied with the application anymore, there are some possibilities you can do:

  • upgrade
  • modernize
  • integrate
  • migrate

On our OOW session tomorrow(Oracle Forms in the Middle of Middleware, 1pm, Marriott Marquis Room: Salon 9), we will talk about the first three possibilities, upgrade, modernize and integrate.

But today I went to the session of Grant Ronald: Moving from Oracle Forms to Java and Oracle Application Development Framework
A session about migrating Oracle Forms to ADF.
The strategy of oracle is NOT desupporting Oracle Forms, on the contrary, they’re working on new features for 11g R2.

But when you consider migrating, do it for the right reasons.
Three kinds of reasons: the good, the bad and the ugly

Reasons to choose for migration can be

  • forms doesn’t meet the requirements anymore
  • there’s need for re-development
  • adopt leading edge, modern technologies

Reasons NOT to choose for migration:

  • there’s a heavy forms investment you don’t want to throw away
  • happy with data entry (and to my opinion forms is one of the best choices for data entry applications)

Wrong reasons:

  • forms will be desupported -> A clear answer of Grant Ronald: THIS IS NOT THE CASE!
  • upgrading your forms application will result in big problems
  • rewriting the application will save $$$

So migration is an option for your forms application, but Grant stated it several times in his session: DO IT FOR THE RIGHT REASON.

About migrating forms to ADF…
The technologies look similar…
Grant made a comparison between a dish washer and a washing machine.
Both have the same measurements, do similar things(wash something and dry it), etc.
But who puts his clothing in a dish washer?  Or cups and glasses in a washing machine?
So thechnologies look similar, but are different:

  • Java applet <> HTML/javascript
  • PL/SQL <> Java
  • Stateful <> stateless
  • No separation of UI and data elements <> seperate UI and data elements

Do not ignore those differences when looking at migration!

ADF is a framework and does a lot of things for you(like log on to the database, you don’t have to write the code) which is pretty nice.
But hey, Forms does also things for you, it’s also a framework.

You can build applications in ADF that look like forms application and have the same behaviour, but is that the reason to migrate, to work the same way?

When migrating there are some more challenges, eg reusability of table/views, procedures/functions, PLL, triggers.  What about forms built-in functions?

So, of course migration is an option for your Oracle Forms application, but ask yourself a question: Why migrate?
Take a look at all the options, before going to migrate.  It’s not an easy path to walk…

Check also the paper Grant wrote about migrating: Migrating Oracle Forms to Fusion: myth or magic bullet