OraTransplant

Monday at OpenWorld 2008

25 September 2008 at 10:08 CEST | In Uncategorized |

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.