Re: Data Control Scope

[Steven]

Frank,

Yes, good plan. Coincidentally, chris m started a thread on the same topic on the adf emg, so i am including that list to share our discussion. Adf emg members can probably add use cases as well.

To summarize my use cases so far

- use same btf as top level entry from a dynamic tab, and as detail region under another top level btf. This asks for the option to set the dc scope on the taskflow binding in the page def. 

- use same btf for deeplinking and querying one row from a calling btf, and accesing all rows directly from the menu. This asks for the option to set the dc scope when calling a task flow.    

Steven.  

On 27 apr. 2011, at 18:11, Frank Nimphius <frank.n...@oracle.com> wrote:

Lets go by the use case when this would be needed and see if we find a solution that would work the same. If not then we may be able to formulate an ER out of what we cannot do. Given the development lifecycle of JDeveloper I think we are talking about a target release after Abrams, which gives us plenty of time. There also is a confusion in ADF about what the impact of the transaction settings in ADF task flows are, which I am also currently trying to sort out. I think there is an opportunity to work on task flow ERs, so we could join forces here ;-)

Frank

On 4/26/2011 7:47 PM, Maiko Rocha wrote:

Hi Frank,

I think that it doesn't need to be as dynamic as you're saying - by any means it doesn't to be RT-dynamic, which ties back to your explanation below which I agree with.

I think that would be more beneficial to set the transaction scope from the caller's perspective, and not from the callee. This is again instance-based. I wouldn't change the TX scope on the fly at all. So, putting it simply:

1. Caller would be able to set the TX type and DC scope when calling a TF (instance-based config)
2. If callee has non-default TX type and DC scope this overrides caller settings (config by exception)
3. Commit/Rollback returns in the callee would be a no-op depending on the TX type and DC scope set by the caller.

I can see that this would be a big change to our codebase though, and it would require thorough testing and backward compatibility support.

[]s!
Maiko




On 4/26/2011 10:04 AM, Frank Nimphius wrote:

Steven,

I understood that If you abandon a taskflow, ADF will automatically rollback the transaction

I actually did not try what happens when you abandon a shared Data Control flow that contains changes to the underlying data structure. My thinking is that it may go back to the transaction save point but also may not (in which case it behaves as if you passed in a mutable object reference as an input parameter). So this is subject of testing (though an interesting question).

The problem I see with dynamically switching between share and isolated data controls is the change it requires in the overall task flow architecture. Isolated task flows require you to start a new transaction or use no transaction. This also means you exit the task flow with commit or rollback. If you switch such a task flow to shared then commit or rollback may not be what you want. Though in your use case, where you want to commit master/child data this is convenient, in another use case where the same transaction contains a shopping cart and your account profile changes, you may not want this (though a m/d synchronization between the shopping cart and your account status may be desired). From my perspective, the question would be more "how to achieve the desired behavior" you want and "what is best practice for reuse". In my opinion, reuse ends where sharing starts. So a solution to m/d synchronization and commit orchestration must come through eventing and messaging (especially given that shared transactions is something that currently works for ADF BC as no other data control supports this concept of commit / rollback and requires a method to be explicitly called).

Anyway, I am open for change and happy to work on enhancing the integration, if there is a use case that explain the dev-team what they need to provide without confusing other users or breaking existing applications. Maiko ?

Frank

On 4/22/2011 1:29 PM, steven davelaar wrote:

Frank,

You write:
Setting data control scope at runtime is not filed as far as I know. I don't think it will be easy to implememnt and easy to use if implemented because a scope of isolated requires you to end btf with commit or rollback, whereas shared DC scope doesn't require this. Also, master data / detail data synchronization differs as well if no data control is shared (at least in the ADF BC case). So your ER may open a can of worms here that many users will have difficulties to understand how it works. However, if there is a need for this feature, go ahead and file an ER

I understood that If you abandon a taskflow, ADF will automatically rollback the transaction. See method TaskFlowReturnActivityLogic abandonTransaction. Am I wrong here?

The fact that master-detail synch no longer works when the detail region taskflow has isolated data control scope is one of the reasons  we need this feature:

Many of my customers use a customized version of the UIShell dynamic tabs implementation.
To be able to have separate transactions in each dynamic tab, they set the data control scope to "Isolated", so each tab is using its own AM instance.
Now, if you want to reuse such a taskflow  accessible from a dynamic tab, as a child region in master/detail scenario (using dynamic iterator binding to switch VO usage), then the data control scope must be shared for ADF BC md sync to work, and to be able to commit master and detail data in one transaction.

(If they would use declarative support for transactions, they would need to use "Requires New Transaction" which also causes problems in the master/detail scenario, because then it should share the transaction from the master taskflow which is not possible because we configured ot to require a new transaction. Btw, most of them don't like declarative transactions, they just want the user to determine when to commit a transaction. Many of their taskflows don't have a clear end point where a commit should take place.)

Also, another typical scenario when using the default shared scope (no dyn tabs)  is when you deep-link into another task flow, and query one row. For example, in employees taskflow, you can click the job hyperlink to navigate to the job taskflow and show the selected job. To do this, you set View Criteria to query the right job by passing in the job row key value. Now, when the user wants to access the same Jobs taskflow directly from the menu, he will still see this one row, and is not able to query all job rows because the deep link view criteria is still applied. Of course, this could be solved by clearing out the deeplink view criteria when starting or abandoning the taskflow (for example using initializer, finalizer methods) but this makes the implementation more complex and error-prone. It would be much easier if you can set the data control scope to isolated at runtime, only for the deeplink taskflow call, so the View criteria are applied to the VO of a separate AM instance.

Maiko, do you have other scenario's to support the ER?

Regards,
Steven.

Steven Davelaar| Technology Director | Oracle Consulting Tel +31 30 669 8113 | Fax +31 30 669 9966 Oracle Nederland BV | Rijnzathe 6, 3454 PV De Meern, The Netherlands PO Box 147, 3454 ZJ De Meern,The Netherlands | KvK nr. 30096087

Oracle Expert Services | JHeadstart

--
<mime-attachment.gif>
Frank Nimphius | Senior Principal Product Manager
Phone: +49 211 74839 334 | |
Oracle Application Development Tools

ORACLE Deutschland B.V. & Co. KG | Bleiwaesche 11 | 42489 Wuelfrath

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

<mime-attachment.gif> Oracle is committed to developing practices and products that help protect the environment

--
<oracle_sig_logo.gif>
Frank Nimphius | Senior Principal Product Manager
Phone: +49 211 74839 334 | |
Oracle Application Development Tools

ORACLE Deutschland B.V. & Co. KG | Bleiwaesche 11 | 42489 Wuelfrath

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

<green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment

[Chris Muir]

Hi Steve

Thanks for forwarding the thread to the group. Regarding your idea of
having the caller initiate the task flow options, in my other thread
(http://groups.google.com/group/adf-methodology/browse_thread/thread/
f94f30c8e9bedfcc/411e47a61423aca9?hl=en#411e47a61423aca9) you'll note
we're in agreement:

-quote-
A final point and just a point for conjecture really, one thing we've
found odd after some experience working with task flows, is why did
Oracle provide the transaction and data control scope options in the
task flow itself? It seems at times it's really the caller of the BTF
that has more knowledge about how it wants the child BTF to behave in
terms of transactions & data control scope, the called BTF is just a
participant. Does anybody have any input into Oracle's chosen design
here?
-end qoute-

Our use case is this. In our latest application utilizing the UI
Shell we of course make use of BTFs for each tab. The top level BTF
is as Steve describes, typically isolated/begin new transaction; we
tend to call these sort of BTFs the "Composite" or "Family" implying
they bring together other BTFs to sit within that tab. However that
BTF can call/consume several other BTFs, who in turn can call/consume
more BTFs. It's at this point with some of our very fined grained and
1 level deep BTFs, sometimes which just contain a table, or editable
fields based on one VO only, that we are interested in the transaction
options beyond just isolated. From our point of view it doesn't seem
to make sense that the consumed BTF should dictate what transaction
options it should have set. If we take the editable fields BTF example
and say it sets Always Begin New Transaction/Isolated, this is overly
inflexible, because maybe the caller wants to use that BTF as part of
a larger transaction combining several BTFs into a train/process.

I also understand Frank's point, I think extending the options will
tip an already complicated set of options for average developers to
unfathomable. Maybe the solution for the ER is to implement a
programmatic solution only - such that the default and existing
declarative options are all current developers see and it doesn't get
have to get any more confusing. Potentially the programmatic solution
could sit in the BTF initializer, with the caller's options for the
transactions/scope settings to be passed through as BTF parameters?

Of course that's not what the framework currently supports. In the
end we've gone with the flow (boom boom!) and thus my other post about
picking TF options that are as reusable as possible.

Btw Steve, at KScope11 I'll be presenting "Angels in the Architecture:
ADF Architectural Patterns" where I present a number of patterns on
pulling ADF applications together. The presentation isn't meant to be
an ultimate discourse on the patterns, but rather the start of a
discussion on how people are pulling large ADF applications together.
The presentation takes an A-B-C approach in building up patterns for
the everyday delegate, but in the last pattern I'll describe our fine
grained "Services" pattern that I think will be of interest to many
experts, including Oracle employees to see what can be built when we
use these options (BTFs, ADF Libraries, transactions & scope) to their
ultimate extreme, as separate to whatever Oracle is doing with Fusion
Apps.

At Kscope11 would you be interested in holding a Birds of a Feather
session to discuss this? I'll invite Maiko, Aino, Luc and Andrejus
(et all) too.

Regards,

CM.

On Apr 28, 11:00 pm, Steven <steven.davel...@oracle.com> wrote:
> Frank,
>
> Yes, good plan. Coincidentally, chris m started a thread on the same topic on the adf emg, so i am including that list to share our discussion. Adf emg members can probably add use cases as well.
>
> To summarize my use cases so far
> - use same btf as top level entry from a dynamic tab, and as detail region under another top level btf. This asks for the option to set the dc scope on the taskflow binding in the page def.
> - use same btf for deeplinking and querying one row from a calling btf, and accesing all rows directly from the menu. This asks for the option to set the dc scope when calling a task flow.    
>
> Steven.  
>

[Maiko]

I'm in for the BoF at KScope. :-)

[]s
Maiko
------------------------------------------
Sent from my iPhone. Please excuse any typos, mistakes, etc.
------------------------------------------

> --
> 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).