Friday, October 23, 2009

Integration in Oracle ADF with ADF Task Flows and Common Files

While I was on Oracle OpenWorld'09 last week, I heard lots of questions about how to split and integrate Oracle ADF applications. It seems quite hot topic now on the market, mainly because many people started Oracle ADF 11g projects recently, and now they are in a phase when applications are growing and becoming large. Naturally, when application growing, its harder to control it and keep performance on suitable level. In my project - Slides: Oracle ADF 11g Production Project Experience, we did application splitting into smaller applications and this helped us to keep development performance on solid level. Because splitting/integration topic is hot, I decided to continue a series of my posts and describe how you can reuse common files across splitted applications. Check my previous posts for the same topic:
  1. Integration in Oracle ADF Through ADF Libraries and ADF Task Flows
  2. Integration in Oracle ADF with ADF Task Flows and ADF Security Configuration
I have developed sample application for today post - ADFIntegration3.zip. This application is based on applications from my previous posts mentioned above. It contains one new application called CommonApp, I have created there property file with internationalization support and simple Java class to get currently logged in user name:


Java class and labels will be reused in all three splitted applications. Main strength - common files will be included into different applications, however physically those files will reside on one location. This means, no matter from which application common files will be modified, other applications will be updated with this change automatically.

Common Java class - SecurityUtils.java and file with labels - ButtonsBundle.properties are included into LocalApp application structure:


Same files are included in RemoteApp application structure:


In order to include Java classes, its enough to put Java class files from separate application on your current project Source Path - point to src folder:


Regarding label bundles, additionally I would recommend to register reusable bundle in Bundle Search window, this will allow to use bundles available on Source Path directly through Set Text wizard when assigning labels:


With registered bundle, you can use labels from bundles available in separate applications and declared on project Source Path, same as they would exist in your current project - through Select Text Resource wizard:


You can use common Java classes, by declaring Managed Beans for example. In all three applications I have declared securityUtils bean, its based on common Java class from separate application:


I can use this bean as usual, through Expression language:


On runtime, when I'm running integrated application, I can see labels are assigned properly, current user name is returned correctly from securityUtils bean as well:


Same thing works well in integrated application, common labels are visible and Managed Bean logic is executed:

5 comments:

sreeja said...

Hi Andrejus,

Thanks for the great post, just what I was looking for.

Regards,
-Sreeja.

Unknown said...

Andrejus

One question related to the way to handle CRUD operations in these types of integrated applications..

We have the main application integrating bounded tasksflows from more than one shared application. the shared application themselves have the entity objects/view objects shared from one common application that owns all the entities used in the project.

We are trying to determine the best means of handling the CRUD operations on the tables and the forms.

Our approach:
- When the user hits the save button, a common method in the backing bean would be called.

- This common method would identify all the sub-applications (shared ones) and the view objects within the shared ones that are changed, identify the type of change and then apply the change to the model layer.

We are able to get the applications and the view objects with their current values. We are not able to identify the "changed action" - whether insert or update. Also, in case of deleted rows, wonder how we can identify the deleted ones.

I reviewed the CRUD examples you have posted and these handle one object at a time.

Appreciate if you can shed some light.

Thanks
Ram.

Andrej Baranovskij said...

Hi Ram,

I guess code from Frank Nimphius article can be helpful in your case - How-to cancel an edit form, undoing the edits in Java

Regards,
Andrejus

Unknown said...

Andrejus

Thanks for your suggestion. We have been able to resolve most of the issues highlighted here.

Unknown said...

Andrejus

Please ignore my earlier comment - it got submitted before I could complete it. Sorry about that.

There is one open issue in our development. From the View layer, we are able to identify the objects changed and also the type of change done.

Currently, we are required to define a SQL type object for each table and use java methods to build an array based on each SQL object and call a PLSQL routine to handle the changes. Wondering if this can be done using PLSQL tables or PLSQL records etc., so that the need to define SQL objects for 50+ tables need not be done.

Also, is there any other alternate way of passing collection of records from the view layer to the back end, other than arrays based on SQL objects? If so, please let us know. Appreciate all your help.

Thanks
Ram.