ADF 11g project structure advice

[Wes Fang]

Finally gathered my thoughts after reviewing some core concepts from the oracle fusion developer guide & "Angels in the Architecture" slides. Before writing a single line of 11g code, I need to establish a project structure for our team team. Here is what I have so far:

Link to blog with details

http://wesfang.wordpress.com/2012/10/10/adf-11g-project-structure-list-of-content/

Some questions I still have:

CommonApp

Should declarative components,template,fragments be in a separate project and deployed individually in its own adfjar?

MasterApp

Is this a good place for the RootAppModule (which will be the container for nested AMs from the mskcc-app*.jar)?

Feedback is appreciated.

-Wes 

[Wes Fang]

Thinking about this a bit more, the RootAm should not be in the MasterApp because that would mean that each individual app the developers create would have to have a dependency on MasterApp adfjar. Back to the design board...

[Renan Monteiro de Castro]

What about page definitions?

On Thu, Oct 11, 2012 at 11:16 AM, BradW <bwor...@gmail.com> wrote:

Hi Wes.  Here is a really great book you should read which will answer all your questions:

https://blogs.oracle.com/jdevotnharvest/entry/adf_enterprise_application_development_book

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

--

Renan Monteiro de Castro - Linkedin

[Wes Fang]

@Brad

Thanks for the book recommendation. I've placed an order.

@Renan

Since the pageDef file is modified declaratively (well, most of the time anyways), I'm going to leave it alone in its default directory and naming pattern. Do you agree?

Seems like the question of "Where to put my RootAm?" in 11g has been discussed quite often. After reading several blogs by Chris and Andrejus on this topic. I've realized that there are many approaches to this complex topic and in my case a solution will be based on the following criteria:

Developer task:

-Work on a single Application (per logical biz requirement).

-Use CommonApp jars in model and vc project.

-Responsible for creating both ADF Faces and BC projects.

-Should not have to checkout/modify Common or MasterApp.

-deploy adfjars for their App.

Lead developer task:

-Work on  MasterApp & CommonApp.

-Checkout adfjars and add them to MasterApp. 

-call BTFs 

-deploy MasterApp to testing/production environments.

I will try to create a couple of prototype projects with the following settings

DeveloperApp

-Model

 -AppModule

 -deploy\devappmodel.jar 

-VC

 -BTF

 -deploy\devappview.jar

Note: No UTFs, and each BTF will have "Share data controls with calling task flow" defaulted. 

MasterApp

-Model Project use devappmodel.jar

 -RootAM

-VC use devappview.jar

Notes:

Upon integration, each developer AMs will be added to RootAM. This is to ensure a single bc4j.xcfg file to setup and single transaction.

Will report back with prototype results.

[Chris Muir]

Hi Wes

In catching up with this thread, one note on the DeveloperApp workspace is Steven Davelaar's recent Task Flow Tester makes an excellent testing tool for these standalone BTF workspaces.  Previously what I had my teams do was build a mini test page in each BTF workspace, but it was always fraught with peril that the developers built the wrong thing.  Steven's generic tool will iron out concerns about the test harness, so it will be very useful.

On your quest to answer the how-many-root-AMs question, I'd certainly be happy to revisit the question here if you have time to regurgitate your research to date.

Cheers,

CM.

[Wes Fang]

Chris,

Thanks for the response. I will definitely check out the task flow tester. I would really like to hear opinion since most of my research on this topic has been traced to insightful posts you made in the past. Here goes my notes and feel free to correct any misunderstanding...

01/13/2010 AM pools vs Bounded Task Flows 

https://forums.oracle.com/forums/thread.jspa?messageID=4022731

I believe this is the thread that started all of your inquiries regarding AMs (now on my mind as well), TF transaction & DC control. Below are excerpts for some really important factors for me to consider if I choose to use RootAM with nested AM in 11g.

 

From your posts:

 

“…a root AM can be defined in the Common project that can be used by the BTF workspaces, where the BTF workspace can import the AM… then nest it's own AM under the root AM from the Common project.”

 

“…The AM Wizard/Editor only allows the root AM to nest the child AMs, not the other way around. At design time as the root AM isn't available to the BTF workspace to be opened/edited, there's no way to declaratively to tell the root AM to nest the BTF AM …”

 

Yeap, I thought about this too and from my brief interaction with the IDE, this is still not possible.

 

From Steve’s posts:

 

“The problem (I believe he is referring to auto nesting of AMs) with the current mechanism is that depending on whether an AM is referenced first, or referenced subsequently as part of a called task flow, it will either be used as a top-level root AM or a nested AM. This means that its AM pooling parameters only effect the case where it's a top-level AM, and have no effect when its used as a nested AM since it's nested inside some other top-level AM.”

 

“…In case #2, AppModuleTwo AM instance is created as a nested AM inside AppModuleOne. In this case, the AM pool involved is the nesting/parent AM's AM pool, not the nested/child's AM pool.”

 

10/12/2011 Angels in Architecture

https://groups.google.com/forum/?fromgroups=#!searchin/adf-methodology/angels$20in$20architecture/adf-methodology/tdsRKBJDahA/C2nXnFth-yoJ

The different approaches to setting up app/project structure described in this presentation is what I will base our future 11g app on. Our 10g production app falls under the simple “Single Application” approach. All AMs are nested under a RootAM. Developers drag/drop the nested AM DataCtonrols for their modules. I encountered the same issues you described in the presentation as the project grew (now in production for 6 years).

 

What I like (or perhaps become accustomed to) about this structure is a single point of config for AM Pool, for example, AM Pool is turned off for testing deployments and we have a handful of bc4j config parameters tweaked at a single point. (However, I also realize that one of the benefits of having individual AM Pool configs is that user traffic to each biz module varies as per Steve’s point  from  the above OTN thread.)

 

From this presentation, I choose to research further how to establish a “Multi Master App with Multi BTF App”.  The reason being is originally our app only supports internal data collection, however, now a big aim in the community is for open collaboration and multicenter clinical trials. Our app obviously has to support this institutional goal. This translates to “Multi Master App”, where we need to deploy flavors of our internal app onto the internet so different hospitals can access our system.

 

 

4/20/2011 Designing task flows for reuse – data control scope & transaction options

https://groups.google.com/forum/?fromgroups=#!topic/adf-methodology/-U8wyOm-38w

Keeping in mind of TF reuse consideration. You suggest using “Use Existing Transaction if Possible” and Shared properties set. (because the calling parent TF might want to use the child BTF either in its own isolated& Always begin new  transaction OR shared and use existing transaction.

 

 

5/17/2011 JDev 11g, Task Flows & ADF BC – the Always use Existing Transaction option – it's not what it seems

http://one-size-doesnt-fit-all.blogspot.com/2011/05/jdev-11g-task-flows-adf-bc-always-use.html

 

Experiment:

BTF1 settings–

Transaction: “Always begin new transaction”

DC:  “Isolated”

 

BTF2 settings–

Transaction: “Always Use Existing Transaction”

DC scope:  “Shared”

 

Flow:

BTF1 -> BTF2

 

Result after running BTF1. :

AM/Connection not created on page from BTF1. However, navigate to BTF2 and even though the settings above should throw an exception.

 

Conclusion:

ADFc does not directly control ADFbc. Although BTF1 is marked to begin a new transaction, its not until BTF2 actually executes bindings (even though its marked  “always use existing transaction…”), is when the transaction is actually created. This was a good peak under the hood of ADFc & ADFbc interaction, more importantly, setting  “Always use existing transaction” on BTFs does not put a constraint on the developers just as long as a parent BTF marks up a new transaction (flag).

 

5/17/2011 JDev 11g, Task Flows & ADF BC – one root Application Module to rule them all?

http://one-size-doesnt-fit-all.blogspot.com/2011/05/jdev-11g-task-flows-adf-bc-one-root.html

 

Experiment  1:

 

2 RootAM used individually in each BTF.

 

BTF1 setting:

Transaction setting: “No Controller Transaction”

DC  “Shared”

 

BTF2 setting:

Transaction setting: “No Controller Transaction”

DC scope:  “Shared”

 

Flow:

UTF1 -> BTF1

UTF1 –>BTF2

 

Result: Two separate transactions, one for each RootAM. DC marked “Shared” does not effect on behavior of connection.

 

Experiment 2:

Same setup from experiment 1 but BTF2 uses “Always use existing Transaction” for Tx setting. Also,

BTF1 now flows to BTF2.

 

Result: AM in both BTF1 and BTF2 becomes automatically nested under a single Root at runtime. VO instances in respective AM shares entity cache but currency is not preserved as expected since its two separate instances of the same VO class.

 

Conclusion:

 Experiment 1 is basically how our  10g app is structured. No BTF control of transaction. All AMs are nested under a single RootAM. If a developer forgets to nest, a separate session to the db is created and errors will be reported at runtime because the db role is only set in afterConnect() in RootAM (no privileges to views).

Experiment 2 demonstrates auto nesting of AMs in 11g via BTF transaction/dc flags. You go on to references Steve’s reply on how if parent BTF calls a child BTF with two separate RootAMs will result in the RootAM from the child BTF being auto nested under the parent BTF’s RootAM. Pretty neat! Also he goes on to say that the AM pool is from the parent BTF’s RootAM.

Key points

1.       Do not rely on the fact the auto nesting behavior will be constant. Imagine your AM to be nested randomly.

2.       Do not mix “No controller transaction” with other ADFc transaction flags on BTFs.

3.       Transaction behavior might be different for EJBs, PoJos etc. (I’ll keep this in mind when I have to build WS).

 

 

 

 

So, for now, my dichotomize options…

 

If I choose the RootAM path, how can I solve this issue you raised?

 

“…The AM Wizard/Editor only allows the root AM to nest the child AMs, not the other way around. At design time as the root AM isn't available to the BTF workspace to be opened/edited, there's no way to declaratively to tell the root AM to nest the BTF AM …”

 

 

If I choose the auto nesting via BTF path, I need to build a single BTF which will be the point of entry where a connection is opened via marking it “Always use new transaction”.  In subsystem (apps that developers create), all BTFs should be marked “Always use existing Transaction” or “Always use existing transaction, if possible”.  The AM from the MasterApp’s BTF  will be the “RootAM”, I can still overwrite the afterConnect() to for set db role. What about the AM pool settings? E.g. AM Pool On/Off, initial size, etc.. Does that get inherited? Will Dynamic JDBC credentials still work?

Thanks!

-Wes

 

[Chris Muir]

Hi Wes

This certainly provides a nostalgia trip, and you've captured overtime
the research, conclusions and even presentations that resulted.

I need to take time out to digest your post in full, including the
references. I note however you haven't referenced the recent Task Flow
Transaction Fundamentals paper found here:
http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adfarchitect-1639592.html

...from the conclusions you've raised they're broadly all still correct,
though note one of the conclusions from the paper, it's fine with ADF BC
to use <No Controller Transaction>, but as you've captured, just don't
use it with the other transaction options because it's too complicated
to understand the behaviour IMHO.

One of the misleading things I think for beginners in the task flow
transaction options is the option names make it seem this is only the
way to build in transaction support into your application. In reality
what those options are talking about are an abstraction of transactions
just at the ADFc level and it is the <No Controller Transaction> option
that gives a hint to this fact... that option could have better named to
be called "<If you select this option it means the ADFc layer will not
create a transaction abstraction above the model layer unlike my other
siblings>". Duly noted my ER to have this option renamed was rejected.

Regards,

CM.

On 19/10/12 4:06 AM, Wes Fang wrote:
> Chris,
>
> Thanks for the response. I will definitely check out the task flow
> tester. I would really like to hear opinion since most of my research on
> this topic has been traced to insightful posts you made in the past.
> Here goes my notes and feel free to correct any misunderstanding...
>

> *01/13/2010 **AM pools vs Bounded Task Flows***

>
> https://forums.oracle.com/forums/thread.jspa?messageID=4022731
>
> I believe this is the thread that started all of your inquiries
> regarding AMs (now on my mind as well), TF transaction & DC control.
> Below are excerpts for some really important factors for me to consider
> if I choose to use RootAM with nested AM in 11g.
>

> /From your posts:/
>
> //
>
> ��a root AM can be defined in the Common project that can be used by the
> BTF workspaces, where the BTF workspace can import the AM� then nest
> it's own AM under the root AM from the Common project.�
>
> ��The AM Wizard/Editor only allows the root AM to nest the child AMs,

> not the other way around. At design time as the root AM isn't available
> to the BTF workspace to be opened/edited, there's no way to

> declaratively to tell the root AM to nest the BTF AM ��

>
> Yeap, I thought about this too and from my brief interaction with the
> IDE, this is still not possible.
>

> /From Steve�s posts:/
>
> �The problem (I believe he is referring to auto nesting of AMs) with the

> current mechanism is that depending on whether an AM is referenced
> first, or referenced subsequently as part of a called task flow, it will
> either be used as a top-level root AM or a nested AM. This means that
> its AM pooling parameters only effect the case where it's a top-level
> AM, and have no effect when its used as a nested AM since it's nested

> inside some other top-level AM.�
>
> ��In case #2, AppModuleTwo AM instance is created as a nested AM inside

> AppModuleOne. In this case, the AM pool involved is the nesting/parent

> AM's AM pool, not the nested/child's AM pool.�
>
> *10/12/2011 Angels in Architecture*

>
> https://groups.google.com/forum/?fromgroups=#!searchin/adf-methodology/angels$20in$20architecture/adf-methodology/tdsRKBJDahA/C2nXnFth-yoJ
>
> The different approaches to setting up app/project structure described
> in this presentation is what I will base our future 11g app on. Our 10g

> production app falls under the simple �Single Application� approach. All

> AMs are nested under a RootAM. Developers drag/drop the nested AM
> DataCtonrols for their modules. I encountered the same issues you
> described in the presentation as the project grew (now in production for
> 6 years).
>
> What I like (or perhaps become accustomed to) about this structure is a
> single point of config for AM Pool, for example, AM Pool is turned off
> for testing deployments and we have a handful of bc4j config parameters
> tweaked at a single point. (However, I also realize that one of the
> benefits of having individual AM Pool configs is that user traffic to

> each biz module varies as per Steve�s point from the above OTN thread.)

>
> From this presentation, I choose to research further how to establish a

> �Multi Master App with Multi BTF App�. The reason being is originally

> our app only supports internal data collection, however, now a big aim
> in the community is for open collaboration and multicenter clinical
> trials. Our app obviously has to support this institutional goal. This

> translates to �Multi Master App�, where we need to deploy flavors of our

> internal app onto the internet so different hospitals can access our system.
>

> _
>
> *4/20/2011 Designing task flows for reuse � data control scope &
> transaction options*
>
> https://groups.google.com/forum/?fromgroups=#!topic/adf-methodology/-U8wyOm-38w
>
> Keeping in mind of TF reuse consideration. You suggest using �Use
> Existing Transaction if Possible� and Shared properties set. (because

> the calling parent TF might want to use the child BTF either in its own
> isolated& Always begin new transaction OR shared and use existing
> transaction.
>

> *5/17/2011 JDev 11g, Task Flows & ADF BC � the Always use Existing
> Transaction option � it's not what it seems*
>
> http://one-size-doesnt-fit-all.blogspot.com/2011/05/jdev-11g-task-flows-adf-bc-always-use.html
>
> Experiment:
>
> BTF1 settings�
>
> Transaction: �Always begin new transaction�
>
> DC: �Isolated�
>
> BTF2 settings�
>
> Transaction: �Always Use Existing Transaction�
>
> DC scope: �Shared�

>
> Flow:
>
> BTF1 -> BTF2
>
> Result after running BTF1. :
>
> AM/Connection not created on page from BTF1. However, navigate to BTF2
> and even though the settings above should throw an exception.
>
> Conclusion:
>
> ADFc does not directly control ADFbc. Although BTF1 is marked to begin a
> new transaction, its not until BTF2 actually executes bindings (even

> though its marked �always use existing transaction��), is when the

> transaction is actually created. This was a good peak under the hood of

> ADFc & ADFbc interaction, more importantly, setting �Always use
> existing transaction� on BTFs does not put a constraint on the

> developers just as long as a parent BTF marks up a new transaction (flag).
>

> *5/17/2011 JDev 11g, Task Flows & ADF BC � one root Application Module
> to rule them all?*

>
> http://one-size-doesnt-fit-all.blogspot.com/2011/05/jdev-11g-task-flows-adf-bc-one-root.html
>
> Experiment 1:
>
> 2 RootAM used individually in each BTF.
>
> BTF1 setting:
>

> Transaction setting: �No Controller Transaction�
>
> DC �Shared�
>
> BTF2 setting:
>
> Transaction setting: �No Controller Transaction�
>
> DC scope: �Shared�
>
> Flow:
>
> UTF1 -> BTF1
>
> UTF1 �>BTF2

>
> Result: Two separate transactions, one for each RootAM. DC marked

> �Shared� does not effect on behavior of connection.
>
> Experiment 2:
>
> Same setup from experiment 1 but BTF2 uses �Always use existing
> Transaction� for Tx setting. Also,

>
> BTF1 now flows to BTF2.
>
> Result: AM in both BTF1 and BTF2 becomes automatically nested under a
> single Root at runtime. VO instances in respective AM shares entity
> cache but currency is not preserved as expected since its two separate
> instances of the same VO class.
>
> Conclusion:
>
> Experiment 1 is basically how our 10g app is structured. No BTF
> control of transaction. All AMs are nested under a single RootAM. If a
> developer forgets to nest, a separate session to the db is created and
> errors will be reported at runtime because the db role is only set in
> afterConnect() in RootAM (no privileges to views).
>
> Experiment 2 demonstrates auto nesting of AMs in 11g via BTF

> transaction/dc flags. You go on to references Steve�s reply on how if

> parent BTF calls a child BTF with two separate RootAMs will result in

> the RootAM from the child BTF being auto nested under the parent BTF�s

> RootAM. Pretty neat! Also he goes on to say that the AM pool is from the

> parent BTF�s RootAM.
>
> Key points
>
> 1.Do not rely on the fact the auto nesting behavior will be constant.

> Imagine your AM to be nested randomly.
>

> 2.Do not mix �No controller transaction� with other ADFc transaction
> flags on BTFs.
>
> 3.Transaction behavior might be different for EJBs, PoJos etc. (I�ll

> keep this in mind when I have to build WS).
>

> *So, for now, my dichotomize options�*

>
> If I choose the RootAM path, how can I solve this issue you raised?
>

> ��The AM Wizard/Editor only allows the root AM to nest the child AMs,

> not the other way around. At design time as the root AM isn't available
> to the BTF workspace to be opened/edited, there's no way to

> declaratively to tell the root AM to nest the BTF AM ��

>
> If I choose the auto nesting via BTF path, I need to build a single BTF
> which will be the point of entry where a connection is opened via

> marking it �Always use new transaction�. In subsystem (apps that
> developers create), all BTFs should be marked �Always use existing
> Transaction� or �Always use existing transaction, if possible�. The AM
> from the MasterApp�s BTF will be the �RootAM�, I can still overwrite

> the afterConnect() to for set db role. What about the AM pool settings?
> E.g. AM Pool On/Off, initial size, etc.. Does that get inherited? Will
> Dynamic JDBC credentials still work?
>
>
> Thanks!
>
>
> -Wes
>

[Wes Fang]

Finally completed our ADF 11g prototypes, I have documented our "real world" 11g application structure in my latest blog post:

http://wesfang.wordpress.com/2013/07/30/mskcc-adf-11g-application-project-structure/