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

Migrate Existing ODI from DEV to TEST to Production

In the previous posts on this Blog you’ve read about my experiences with Oracle Data Integrator and now a new important milestone was reached … import and export the ODI interfaces, datastores, … from DEV-environment to TST-environment.

I’ve asked on OTN what the best way was to accomplish this and different views were given on how to solve this.

You could use import/export functionality from ODI itself, e.g. if you want to partially export a certain interface or datastore, you could export a specific object.
If you want to migrate from DEV-environment to TEST, you could use the import/export functionality from the Oracle Database because my master- and work-repository are stored in an Oracle 10g Database.

I needed to move my development environment onto the test-environment to be able to run the ODI functionality against real-time test data to be able to test the performance more accuratly. Another important raison also was that my development environment, my notebook, had crashed a couple of times already so I needed to back-up all the important data.

What did I do to accomplish this import/export:
- I exported the master- and work repository used by ODI (snpw and snpm-schema’s)
- I copied over the ODI-folder from my program-files folder, just to make sure

After backing-up all other stuff on my laptop, I needed to format my laptop and have a closer look at the problems I was facing concerning my hard-drive etc.

Alea iacta est

A new laptop, a new environment … let’s start installing all needed software and then the time had come to get back up and running with my ODI environment.

First I tried to import the existing Master Repository but the wizard didn’t really guide me a lot during this process so another approach was needed.

At last, the successfull steps to import/export from environment 1 to environment B such as DEV to TEST are the following:

  • Export existing master- and work-repository in a dump-file using Oracle db export feature
  • Import the master- and work-repository into your new schema
  • Create a new connection to the imported master-repository when you connect to the Topology Manager in ODI
  • Create a new connection to the imported work-repository when you connect to the Designer manager in ODI

Now your work is done … if you check out the model- and projects-tab in your Designer-view you will notice all interfaces, datastores, models, etc. are imported successfully.