« Oracle JHeadstart 10.1.3.1 Now Available! | Main | New Master Index, with Category Feeds »

Fusion cooking

Fusion is hot, not only in many modern kitchens, but also at Oracle, where it means the synergy between our middleware and applications offering. As you might know, the next version of our eBusiness Suite, quite appropriately referred to as Oracle Fusion Applications, is being built using ADF and other products in the Oracle Fusion Middleware range. Today we'll show you a quick recipe to cook Fusion Applications right at home, with just a cup of ADF and two tablespoons of OAF in the our favourite high-temperature JHeadstart oven. We'll show you how we created a small ADF application that hooks up nicely with classic eBS screens.

Business case

For this demo, we came up with a highly realistic business case. Imagine you sell magical wands and bought yourself a license of the Oracle eBusiness Suite to keep track of your many customers. As those customers are often a few hundred years old, they have difficulty in keeping track of their credit card numbers. Our Fusion application will help them by storing their credit card information nicely in the database, to enable them to just choose their favourite credit card from a list upon their next visit to your offline shop (these weird men with blue-silver dresses and hats don't like online shops). The application we'll build serves to manage credit cards and has only two tables to be added to the ones in the eBS suite:

Basic JHeadstart application

As we'll be cooking things in our JHeadstart oven, our model project will have to be developed in ADF Business Components. After generating the tables, we'll let JDeveloper do the dirty work and generate ADF BC artifacts based on these tables, which we'll then extend slightly to use generated PKs for new records and we added a method to the application module to generate random credit card numbers (very useful !).

When the model's ready, we fired up a JHeadstart project and spent a few clicks refining the basic application. As this was supposed to be a quick recipe, we stuck to quite simple Master-Details screens with a wizard to add new credit cards.

Fusion at your Fingertips

While the JAG is toasting our application definition file, we'll take a look at a sample eBS R12 screen that offers an overview of Customers in the system. This specific screen was custom-made with Oracle Applications Framework for the demo, but what comes next is pure personalisation and could be done to any eBS screen by a user with access rights to the personalize button.

Imagine we have this eBS customer list in front of us when another bearded old man arrives at our shop, wanting to buy a fiery fire wand. Because he forgot to bring his wallet and doesn't quite remember his teleporting spells too well, we want to quickly jump into our ADF application to see all the credit cards he used at our shop in the past. That's what JHeadstart 10.1.3 supports deep linking for, so we bring up the application definition editor, add the following to the deep linking section of the Customer group and fire up the JAG again.

Note that we deviate a little from the suggested values and expressions, because we come from a different application (outside the JSF context). We also added the deepLink == true requirement because we don't want the deep linking to be triggered every time we access the Customer page, but only when passing through this specific URL.
All we have to do left to get to 'real' Fusion is to add this deep linking URL to our eBS page as a link, which is easily done by setting the "Destination URI" for the customer name column in the personalizations screen to:

http://localhost:8988/Demo/faces/pages/Customers.jspx?deepLink=true&RowID={$TheRowId}

The resulting, personalized page will now link every eBS nicely to the appropriate ADF page!

Which leads to

That's it, Fusion in twenty clicks. Obviously, this is only a very simple business case with only one-way integration, captured in a simple and publicly accessible URL. In cases where a little more security is involved (not an issue with credit cards, is it?), you'll need to enable Oracle Single Sign-On for your eBS and the ADF application and probably some effort will go in managing the security roles appropriately.
Anyway, the above shows that small-scale integration between existing systems and JHeadstart-powered ADF is fairly easy, given the powerful deep linking functionality of JHeadstart, and might provide quick solutions in many well-scoped business cases.

The source of this mini-demo can be found here. Unzip and open the application archive, then go to the Project Properties of the "WorkingDemo" project, then to JSP Tag Libraries, and Add the 2 JSF tag libraries, ADF Faces Components, and ADF Faces HTML (which we left out to keep the zip small).

Comments (2)

Great to See the Extension of Ebusiness (R12) Applications With Jheadstart?> I Am sure same thing can be done for 11.5.10 Screens also correct? How does Authentication Work? What are the Plans to Make Jheadstart available for Extending Ebusiness Applications R12 (Instead of OA Extension)

Of course it can also be done for R11. The demo just uses R12 for fanciness, but the general idea is that you build your ADF application using JHeadstart directly on top of the database for superior productivity. <br/>Authentication is indeed an interesting challenge, but as the JHeadstart Authentication filter encapsulates J2EE security (cf JHeadstart Developers Guide chapter 5), an eBS system with an OID/SSO solution can use the exact same security context as the generated application.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)