Multiple Root Application Module to One Root Application Module

Was quite busy in AM pooling and database connections issue.. but interesting issue..

3 years back somebody designed my application with 7 root AM's and its working fine with few users... but in next few months we are going to have 300+ concurrent users..

We don't want to..
 - take 2100 database connections..
 - have frequent activation and passivation..
 - change the application design to have one main taskflow and let all other task flow to share the transaction...

And we just got 4 weeks to fix this... What is the option I left with.. Create a new root application module and make existing 7 AM's nested.. but we got more than 200 pageDef.. I need atleast 4 months to change everything declaratively and test it thoroughly.. not enough time to do this..


So what I have done is.. Created a new sample application with one root AM and one nested AM.. created a task flow and a page with all kinds of bindings declaratively... closely observed the patterns in pageDef files.. Just following the pattern and wrote a small piece of java code which will replace all the pageDef root AM references to use nested AM references.. And yes it worked out.. Just one day coding and 3 weeks testing.. Now on average 1 User 1 DB Connection... I think the best way would be xslt but I'm not familiar with that and I don't have much time to experiment that.. So went with my favorite java code..


I'm sure the same situation will be faced by other developers also.. So I'm sharing my code here.. Just follow the below steps:


1. Create a new Application Module (Say TestRootAM) and make all your existing AM's as nested of RootAM.


2. Create a datacontrol usage in DataBindings.cpx for the new AM. (Simple way is to drag and drop an attribute from a nested AM which will create this entry automatically) Also remove all other datacontrol usages from DataBindings.cpx


3. Download my java code and set proper value for variables
ROOT_AM_NAME (new AM name TestRootAM ) and 
ROOT_DIR (root directory of pageDef files) 
and then run it.. It will replace all root AM references to use nested AM references.

4. Test your application and make sure everything works fine.

Do not forget to change the new AM configurations..

That's it now my application code/design looks same as if it would have been implemented declaratively via jdeveloper with one root AM and multiple nested AM.

In future if you don't want to make any other AM's as root AM then hide all nested AM data controls as per my earlier post.

Also this script will fix Oracle ADF Bug 13837650 which I mentioned in my earlier post.

Good luck and incase if you find any issues in my script please put your comments so that I will modify it. 

Note : Please note that I'm just sharing the code for reference and its your responsibility to use this and test your application thoroughly.

Thiru

Bind values set for a VO on nested AM method call activity is not reflected in my page

And finally my first informative post is here:

When you have a taskflow which does not share datacontrol 

and it has a methodCall and view activities.

Here if this method call activity is created from a nested AM then the pageDef binding will be:

With this code the bind parameters set on the method call activity will not be reflected in the view activity. 

The reason is ADF creates 2 application modules here, one for method call activity and another for view activity. So the view object in view activity does not have the bind parameters applied in method call activity.

This issue is due to 'Root' keyword in instanceName attribute.

Change the instance name attribute from:   

    InstanceName="AppRootAMDataControl.dataProvider.Root.DeptEmpAM1">

to 

    InstanceName="AppRootAMDataControl.dataProvider.DeptEmpAM1"

to fix this issue.

Initially I was wondering why the bind parameters are lost and after some detailed analysis I found that both are different AM instances and logged SR with reproducible test case. Then Oracle Support asked me to remove the Root keyword and also they confirmed that the issue will be fixed via 

Bug 13837650: REMOVE ROOT FROM THE INSTANCE NAME OF METHODACTION BINDING

Looks like this bug is planned for JDeveloper 12.1 release, till that time if you create action or MethodAction make sure that Root is removed manually.

For my detailed analysis and reproducible test case refer my Oracle Forum Post.