OraTransplant

OraFormsFaces at Oracle OpenWorld 2008 (including slides)

I finally have time to write about my own session last Tuesday. I presented on OraFormsFaces, a technology (or toolkit) we developed to integrate Oracle Forms into JSF, ADF, or any other web technology. A simple example can be seen below:

This technology allows you to take an existing Oracle Forms module and just embed it in your web application with little or no changes to the Form. We feel this is a revolutionary technology for Forms customers. It allows you to reuse existing Forms as fully functional web application components. You can fully interact with the forms, pass data from your web application to Forms PL/SQL and back and it’s even possible for other UI components to trigger PL/SQL command and vice versa. This is really something you would have to see to believe it.

The room was almost full and people were very enthusiastic. I got some very good questions during the presentation, which is always nice. It gives me the feeling that people are really listening and interested. At the end of the presentation about 10-15 people approached me at the front and asked even more questions sometimes very specific to their situation. This again proved to me that they’re really interested in the concept and apparently the concept came across.

I also did a couple of slides on Oracle JHeadstart, a toolkit from Oracle in the Netherlands. This started out as a toolkit to help you in building new ADF web applications according to the best practices as learned by Oracle Consulting. But recently they added the Forms2ADF Generator to their toolkit. That’s something I wanted to mention in my presentation as that’s probably interesting to the same target audience. Forms2ADF helps you in moving away from Oracle Forms and reuse the data structures and other metadata in your Oracle Forms modules to get you started with building ADF web pages with JHeadstart.

I feel that the combination of JHeadstart Forms2ADF and OraFormsFaces might be ideal for many Forms users out there. They can use OraFormsFaces to embed their existing Forms in a ADF web application. In fact, if this ADF web application is built using JHeadstart you can have OraFormsFaces integration out-of-the-box as JHeadstart has built-in support for it. Then, over time people might want to replace individual OraFormsFaces/ADF pages with newly built ADF pages that no longer reuse Forms and its business logic. Then they can use the Forms2ADF Generator to extract as much metadata as possible from the Forms module to get a real head start in rebuilding similar functionality in ADF.

During the rest of the week I’ve been approached by quite a number of people interested in the product. I’ve spoken to a number of Forms users, sometimes together with Steven Davelaar from the Oracle JHeadstart team. The concept seems to catch on. Last year at OpenWorld I presented on the same technology which was brand new back then. Since then it’s evolved even further and it has gotten quite some attention in the Forms community. It seems concepts like this need some time and “buzz” to catch on. This OpenWorld there was much more interest in it. I heard that quite a number of people stopped by at the Oracle Forms demo grounds pod to ask about the OraFormsFaces solution. That a good thing, especially since I know the Oracle Forms product managers also see the benefit of this solution for some clients. Having them endorse the solution is always a good thing. So even if it did get quite some attention, I feel that there should be even more Forms customers that should be interested in the product. But it’s still hard to reach as much of them as possible, especially at OpenWorld in the middle of 1700 other sessions.

For people interested in OraFormsFaces that could not attend the session; you can still download the slides and have a look for yourselves. If you are interested in the technology, feel free to contact me for more information.

Oracle OpenWorld Continued…

There’s so much to see and attend at OpenWorld that it’s hard to make choices. I managed to attend a few other sessions. Out of personal and technical interest I attended a session on “Oracle Continues Query Language for Complex Event Processing”. This is something that’s not likely to be used in my day-to-day job, but I was interested to see all this new stuff.

Another session I attended was on creating a custom look and feel and skinning for the new ADF 11 Rich Client Components. This was a very very interesting presentation. Users aren’t always happy with the out-of-the-box look and feel of an ADF application. This was particularly true for 10.1.3 apps. Now with version 11 the default look and feel is so much better but it’s still good to learn how you can customize even that. In the end it wasn’t near as hard as I thought it was and as it definitely was in previous versions. One of the best things is that they finally documented all the skinning stuff thoroughly. There’s even a demo site with all components and some example customizations to their skinning. This gives you a quick and easy way into what it possible.

After that presentation I had my own presentation on OraFormsFaces, a toolkit to integrate Oracle Forms into a JSF/ADF application (or whatever other web technology for that matter). I won’t go into that for now as I’ll use a separate blog post for it.

Right after my own session I attended one from Oracle about the new ADF Desktop Integration feature. This allows you to build an “application” right in MS Excel 2007 with the same familiar JSF components one uses for building ADF web applications. You can just setup the “page” bindings manually in JDeveloper and then go into design mode in MS Excel 2007. It will show the bindings you’ve setup and allow you to insert a number of JSF components in your Excel sheet based on these bindings. Now you can have things like buttons and even fully functional ADF tables right there in your Excel sheet. When someone runs this they see live data from the data controls (which could be a database query, a web service, or any other ADF data control). A user can change data and submit it back to the server. Very much like a typical ADF web application but this time straight from the familiar Excel interface. For some (mainly bulk) data operations Excel could be the preferred choice for some users. It’s good to know a developer can offer this with the same JSF skills he already has for building ADF web applications.

In case you wonder; the Excel sheet can also be used without a live database connection. It will detect local changes and it’s up to the user when the data is synchronized back to the ADF server. This means it even allows for (simple) offline working with synchronization and conflict resolution later on. Lucas Jellema from AMIS told me that Duncan Mills previously stated that ADF will have full support for disconnected applications. Lucas blogged about that back in June. This would be so great as we have a heave Swing desktop application at Eurotransplant that is used by transplantation coordinators that are dispatched to hospitals. This application has to be disconnected in nature since mobile network access is not guaranteed at each site. Building and maintaining this application has proven to be quite complex and not far as productive as building ADF web applications. Hopefully this new ADF disconnected feature can make our lives much easier.

I finished the day with a presentation by Frank Nimphius on ADF security. I was expecting a sort of rehash of the same story Frank had for ADF 10g. However he explained that security architecture changed quite a bit with the integration of Oracle WebLogic in the technology stack. So he adopted his presentation to explain how things fir together with the new Oracle WebLogic. I must be honest that it wasn’t all 100% clear. To me it felt like it’s much more fragmented and requires stuff in even more metadata files. There was even stuff in some files that wasn’t actually used which adds to the confusion. There’s user definitions in multiple places and you’ll have to know which one is relevant. It all looked a little rough around the edges and it wouldn’t surprise me if this was one of the main reasons for not making the deadline of releasing JDeveloper 11g when OpenWorld started. They plan on having it out there next week, but I guess they did everything they could to have it there last Monday when OpenWorld opened.

Monday at OpenWorld 2008

It’s time to do some blogging. The week has been so extremely busy that I didn’t have a spare minute to do the blogging thing. In fact it’s been quite busy the last few weeks. Finishing up the next version of OraFormsFaces was very time consuming. Luckily enough I did manage to get the next production version out there before my presentation at OpenWorld.

Let’s go over my personal highlights this week. The weekend wasn’t that exciting. I basically spend each day from 7pm till 2pm at the little desk in my hotel room working on OraFormsFaces. I started my Monday with a very interesting session on Oracle MDS (MetaData Services Framework). This is the cool stuff Oracle needs to personalize their own applications and is making available in the Fusion Middleware stack. Simply put it’s a service that can customize (XML) metadata at runtime. Since most of your Fusion Middleware application is metadata, this means you can customize virtually anything. It holds the delta between the original XML file and the desired end result. This allows developers, customers, or users to modify an application after it has shipped from the “factory”. Oracle Fusion Applications is using this for things like customizing modules per vertical and later on customizing it during implementation at a specific client.

To create the needed “delta” you can start JDeveloper in customization mode. Once you are in customization mode you can select to see all files in their base version or switch to the different customization levels you’ve specified. All the changes you make while in customization mode are stored in the delta for your currently selected level. This is a very easy and productive way of specifying your changes/delta since you’re still in the normal JDeveloper environment with all its visual and enhanced editors. We just asked afterwards why all the customized properties wouldn’t show up with their own little icon or color. Currently, JDeveloper already indicates which property is in its non-default value. I guess it shouldn’t be that hard to also add a visual indication if the property is changed in the customization mode. Peter Ebell from AMIS even came with the brilliant idea to re-use the source control diff-viewer that’s already in JDeveloper. Normally it is used to compare two different versions of a file and show them side-by-side with the changes marked. It shouldn’t be too difficult to show the base and customized version side-by-side in a similar fashion. The product manager presenting on the subject really liked the idea so perhaps they’ll take it into consideration for a next version. You really see that the conference is not only useful for us as customers but the Oracle people are also getting tons of feedback from this.

The next session I attended was titled “Migrating from Oracle Forms to Oracle Application Express”. Although I’m very unlikely to migrate from Forms to Apex, I was still very interested. I’m from a Forms background myself and the OraFormsFaces product I’m presenting on is about integrating and reusing Oracle Forms as fully functional JSF components. Although that’s a totally different approach, both solutions might be interesting to existing Forms customers. In the end, the session was more on Apex features that the actual migration from Oracle Forms. That’s to be expected as the actual conversion process is not that complicated. It reads the FMB files (actually the XML files after converting the FMBs) and looks at the data usages in the Forms. Based on that metadata, it creates the same data-usages in Apex. You end up with a basic application that works for querying and manipulating the same data. But that’s only the beginning. You still have to go into Apex and add all the necessary business logic and finer details to get your final result. So, yes they take information from the Forms application to get you started but it’s far from a 100% automated process. To be honest, that’s also not what they were saying or promising but this is what Forms users are looking for. I think they’ll never find it. Oracle Forms is so different in architecture and technology than whatever new technology you want to use, that a fully automated conversion is just not an option. You have to think carefully about migrating to whatever new technology you want. Our own solution is to not migrate, but integrate to get started. With OraFormsFaces you can integrate your existing forms in a new JSF/ADF application. In fact it’s not even tied to JSF and the technology can be used with any web architecture. It does allow you to integrate existing Forms with minimal or no changes to the Forms. No matter how good the migration/conversion tools get they’ll never beat this. Once you’ve integrated existing Forms into your new web application, you can start thinking about replacing individual Forms or groups of Forms with your new technology of choice. This gives you a way to gradually migrate to your new technology and prevents a big bang migration or rewrite scenario.

My last session for the Monday was on the new data visualization components in ADF 11g. These are the great looking graphing tools in JDeveloper 11g. It looked just as simple as creating a graph in Excel. These are just awesome. You can create interactive, 3D, animated graphs with all the features you can think of. This can create some really sexy looking enterprise applications.