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!

Forms 11G and DB function with result cache

Result cache… a very cool feature in the 11g database.
If you don’t know it, this is a must read: Pl/SQL function result cache in 11g

But also watch out with it in Forms 11g.
It seems there’s a bug.
When compiling a program unit that calls a function with result cache in forms, you’ll get a compile error, which look likes this:

Error 801 at line 7, column 2: internal error[*** ASSERT at file pdw1.c, line 4061; PSDGON missing. Can’t get object number; XNSPC1PTEST__P[7,2]

This is logged on “My Oracle Support” as a bug.
It’s not a forms bug, but a PL/SQL Client bug.
And this “bad” version of the PL/SQL client is used in forms11g(or in general FMW11g).
It works with older and newer versions of the PL/SQL Client(Forms 10g + function result cache should work).
Hopefully there’s a patch soon, so that everybody can use 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

Oracle Forms 11g and Apex using external events

I remembered an old post of Roel Hartman where he integrated a form into apex.
He used a part of OraFormsFaces by Wilfred van der Deijl: the CommunicatorBean.
Using this CommunicatorBean forms could react on “external messages”.
Now with Forms 11g reacting on external events, this CommunicatorBean isn’t necessary any more(sorry Wilfred).

This is how I did it using external events…
First things first: set up the advanced queueing mechanism.
Check this tutorial which includes setting up advanced queueing.
I created a little form based on emp(nothing fancy)…

The new feature in forms:

With the following properties:

What should forms execute when this event happens?
This has to be specified in the When-event-raised trigger.

In this case we retrieve the payload and extract the empno from it.
The empno is used to set the default where clause on the block.
When there’s an empno on the queue, forms will query that employee.
That’s all for the forms part…
Now I created a little Apex page with two regions:

The Employee details will be our form.
So I put our form in the HTML using an iframe:

Using a “select list” it’s possible to select an employee.

This is the result:

Now the purpose of the select list is to choose an employee and show the detail information in our form.
In order to do this, the select list calls a javascript function.

This javascript function is created in the HTML header

The code behind this:

<script language=”JavaScript” type=”text/javascript”>
function getEmployee (){
var emp = $x(‘P2_EMPNO’);
// send request
var ajaxRequest = new
htmldb_Get(null,&APP_ID.,’APPLICATION_PROCESS=get_emp’,0);
ajaxRequest.add(‘P2_EMPNO’,emp.value);

// get response
ajaxResult = ajaxRequest.get();
ajaxRequest = null;
}
</script>

This javascript function calls an application process and uses the empno as parameter.
The application process put the empno on the queue.

When changing the select list, the form is queried

This is a solution to integrate forms into another application whether it’s Apex, ADF or another web applicaton.
When it can put something on the queue, forms can react on it.
And yes, I could do it using the javascript feature in Forms 11g. I know…
And for Apex it’s probably a better solution, as we can skip the AQ part and make calls to and from forms in Javascript.

Oracle Open World 2010: Forms in the Middle of Middleware

People attending Open World to have a closer look at fusion technologies and how to integrate them in your existing applications, need to check out the following session:

  • ID#: S315945
  • Title: Oracle Forms in the Middle of Middleware with Oracle Product Management
  • Track: Application Servers, Application Grid, and Development
  • Date: 22-SEP-10 Time: 13:00 – 14:00
  • Venue: Marriott Marquis Room: Salon 9

Together with Grant Ronald we will talk you through the possible scenario’s to modernize your existing forms applications. After each scenario we will demo the functionalities and showcase some of the success stories we’ve conducted together with our benelux customers.

The different scenario’s include upgrading to 11g to use the event-driven architecture, integrate with existing applications such as apex, .net, google maps, bpel, …

In other words if you’re using fusion technologies such as BPEL, OSB, ADF, … you can easily integrate these with your existing forms applications using the new features provided in 11g.

Oracle Fusion Middleware 11g support(including Forms 11g)

Since we’re talking about Forms 11g, the first question we get from customers is “Until when is Forms supported?”.
I saw the blog post of Gerd Volberg and thought is was interesting to share this with our readers.
Extended support for Forms 11g(and reports): June 2017.

Complete information on Fusion Middleware support: Lifetime support Middelware

And maybe it will go further as I mentioned in a previous post.

Forms 11g javascript integration: Call others

Forms 11g holds a lot of interesting new features focused on event-driven architecture, one of these is javascript integration. There are two ways of using javascript with Forms 11g: “call others” and “let others call you”.

Javascript can call code in Forms(“Let others call you”) using the new forms trigger “when-custom-javacript-event”.

This post is going to show you the first one: “call others”, in other words call javascript from your Oracle Forms application.

During the Forms Modernization Seminar I showed a google map that could be manipulated from an Oracle Form. It’s an easy implementation with only a few lines of code(most of the javascript is taken from the api examples on the google code site: http://code.google.com/apis/maps/).

  • Build a little form with one (control) block, one text field(to enter an address) and one button(to call the javascript code).
  • Next step is to create an HTML-page to display the form.

This code puts the form(in an iframe) and the map side by side:
(Click to enlarge)

And it will look like this:

  • The javascript that will be called is put in another file google.js:

  • The only thing to do is creating a “when-button-pressed” trigger in forms to call the javascript function showAddress.
    This is done by a new built-in procedure web.javascript_eval_expr:
  • Copy the HTML and javascript file to the following directory:
    <middleware_home>\user_projects\domains\<domain>\servers\WLS_FORMS\tmp\_WL_user\formsapp_11.1.1\e18uoi\war\
  • Create a new configuration using Enterprise Manager:

  • Make sure the parameter EnableJavascriptEvent is set to “true’ in your configuration!

And the working demo…