An introduction to OA Framework
In case you’ve never heard of OA Framework, here’s a brief marketing-style synopsis:
Oracle Application Framework is the development and deployment platform that Oracle themselves have used for the past few years to develop the Oracle E-Business Suite “Self-Service” or web-based applications. OA Framework embraces the principles of developer and end-user productivity, performance and flexibility through the use of open standards. The Framework, based on the industry-standard Model-View-Controller design pattern, can be used to develop extensions to existing E-Business Suite functionality or completely bespoke Self-Service applications.
So, what does that mean in real terms? Oracle themselves have been using OA Framework to develop all new E-Business Suite screens for the past few years, eschewing the traditional Oracle Forms 6i development tool. We’ve all seen the wonderful web-based screens that have been released by Oracle. Personally, I’ve been itching to get my hands on the technology used to build them for quite some time. It’s only since Release 11.5.10 that Oracle have let the rest of us have a play with their new toy.
OA Framework itself consists of a number of components, some used for development, other for deployment. A developer’s first encounter with OA Framework will be with a customised version of JDeveloper, based on v9.0.3 for Release 11. This customised version has been extended to be “aware” of the various OAF objects and provides a number of wizards to help you build them.
The typical build of an OAF application roughly follows these steps:
- Design your Model using BC4J (Business Components for Java)
- Design your Views using UIX
- Build your Controllers using standard Java classes
Building the Model using BC4J is very straightforward, as Oracle provide wizards to help you build all of the different types of objects that you need. The wizards write out a number of XML fles which stores the Model declaratively. BC4J provides the ability to add basic validation without any code, although you will need to write some Java for more complex validation.
The User Interface is also built declaratively and saved in XML files. When building applications for Release 11 using JDeveloper 9.0.3 there is no visual layout editor for UIX; the developer is shown a tree-like representation of the screen being built. The lack of a layout editor in general slows development, as you need to run the screen more often to ensure that the changes that you’ve just made look OK. However, once you get used to the idiosyncrasies of building your screen in this manner, you can build complex screens quite quickly. OA Framework in Release 12 uses the 10g version of JDeveloper, which has a simple screen layout tool.
Lastly, you need to build Controller classes in Java to bring it all together. I had done very little Java before starting with OA Framework; the facts that Java is relatively easy to learn and that Oracle provide some very useful classes with clear documentation means that you should be able to build Controllers pretty easily.
Once you’ve got all that done, you’ll want test your Application. Fortunately, JDeveloper comes with a local runtime environment so that you can test the screens on your PC without having to upload them to the Application Server every time. This is very useful when it comes to debugging, in that you can single-step through your Java code, examining the contents of variables as you go. Finally, once you’re happy with everything, the Application is uploaded to the Application Server. I’d recommend testing your Application again at this point as there are some minor differences in the way the two runtime environments work.
In all, OA Framework development is relatively simple, but for developers coming from a traditional Apps background of Forms, Reports and PL/SQL, it is quite a culture shock. Personally, I think it’s worth getting over this and getting stuck in – OA Framework is the future of Apps development… well, at least until Fusion Applications comes along.
While I am not quite as enamoured with the J2EE model as the person who wrote this blog is (I think it is a bit of a pain and the fact we won’t have Examine going forward will be a nightmare at first) – Oracle do a good book for existing Forms and Reports developers which takes the J2EE concepts and translates them into what traditional Forms/Reports people are used to:
Oracle JDeveloper 10g for Forms & PL/SQL Developers: A Guide to Web Development with Oracle ADF (Osborne Oracle Press Series) (Paperback)
It is available on Amazon. ADF is the technology Oracle are writing Fusion in – it uses the J2EE model much like the existing OA Framework so it is all relevant.
Robertwgrace thanks for your comment on this post, great to see people add their experience and suggestions.
Oracle realized that the Examine functionality did not exist within the OA Framework applications that were being delivered as part of the Oracle E-Business Suite. To address this, an About this page feature was delivered which is a link at the bottom left hand side of the page. when clicked upon, the user can view specific information around that page, not just the data values associated with the java components but items such as which controllers are being called, the view objects referenced as well as which patches were applied on the environment – much more information to the user.
However, you cant change any of the values so that data updates are controlled and business rules are not violated. You’ll find that many products are building new features and functions using this technology. With the rise in uptake, continuous improvements on ATG are being made and keeping one eye on the technology stack (ATG Etc) announcements with every release can even help customers push those uptakes to product teams to include (if they have not already!).
Suhail
Rysigo Technologies Corp, San Francisco, CA