Designing task flows for reuse – data control scope & transaction options
1,368 views
Skip to first unread message
Chris Muir
Apr 20, 2011, 11:24:23 PM4/20/11
to ADF Enterprise Methodology Group
I'd like to ask ADF EMG members questions around task flow design,
namely consideration of ensuring task flows are ultimately reusable
without change, and specifically looking at the task flow data control
scope & transaction options.
Members would be familiar that bounded task flows (BTF) support both
isolated and shared data control scopes, as well as four transaction
options: <No Controller Transaction>, Always Begin New Transaction,
Always Use Existing Transaction and Use Existing Transaction if
Possible, as described in the Fusion Dev Guide section 16.4 and
onwards: http://download.oracle.com/docs/cd/E17904_01/web.1111/b31974/taskflows_parameters.htm#CHDIEDEH
When building an ADF application, typically BTFs will be built and
used by that application alone. This makes it easier to determine the
transaction and data control scope options of the BTF as the developer
will know what context the BTF will be used in. For example say a BTF
to manage Customers is created, in context of the consuming
application if the requirements say the Customers can be created
outside the main transaction, then the Customers BTF should have its
transaction option set to Always Begin New Transaction & isolated data
control scope. However if the Customers BTF is called in sequence
from some composite BTF as part of a larger transaction, the Customers
BTF should use Always Use Existing Transaction and shared data control
scope.
However what if we're building our BTF to be used by more than one
application, potentially a theoretical set of future applications that
may want to use the BTF in all sorts of different transactional ways?
One calling application may want to use the BTF in an isolated
transaction, but another as part of a running transaction. We
immediately hit a problem as if the BTF sets the wrong transaction and
data control scope options, it can constrain its future use, and any
post changes may break it's current use.
And this is where I'd like input from members please. From my
thinking it would seem that such reusable BTFs should always have
their transaction options set to Use Existing Transaction if Possible,
and Shared data control scope set. This would allow the BTF to join a
transaction or create its own if a transaction is not available from
the caller. This provides for the flexibility required by any
theoretical consumer/caller.
My thinking then goes further to say if the calling application wants
to change the BTFs transactional and data control scope options, it
can wrap the called BTF in another BTF that changes its own
transaction and data control scope options, which are then inherited
by the called BTF. For example if the caller create a new
transaction, the called BTF will join that transaction. However if
the caller has no transaction, then the called BTF will create its own
transaction.
Anybody have any thoughts on this?
As a side note please understand I'm not saying there aren't times
when you will build BTFs that purely require its own transaction and
isolated data control scope. Rather I'm talking about a BTF that we
know we want to be as flexible as possible to assist reuse in any
transactional scenario in the future.
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?
Your thoughts and comments appreciated.
CM.
namely consideration of ensuring task flows are ultimately reusable
without change, and specifically looking at the task flow data control
scope & transaction options.
Members would be familiar that bounded task flows (BTF) support both
isolated and shared data control scopes, as well as four transaction
options: <No Controller Transaction>, Always Begin New Transaction,
Always Use Existing Transaction and Use Existing Transaction if
Possible, as described in the Fusion Dev Guide section 16.4 and
onwards: http://download.oracle.com/docs/cd/E17904_01/web.1111/b31974/taskflows_parameters.htm#CHDIEDEH
When building an ADF application, typically BTFs will be built and
used by that application alone. This makes it easier to determine the
transaction and data control scope options of the BTF as the developer
will know what context the BTF will be used in. For example say a BTF
to manage Customers is created, in context of the consuming
application if the requirements say the Customers can be created
outside the main transaction, then the Customers BTF should have its
transaction option set to Always Begin New Transaction & isolated data
control scope. However if the Customers BTF is called in sequence
from some composite BTF as part of a larger transaction, the Customers
BTF should use Always Use Existing Transaction and shared data control
scope.
However what if we're building our BTF to be used by more than one
application, potentially a theoretical set of future applications that
may want to use the BTF in all sorts of different transactional ways?
One calling application may want to use the BTF in an isolated
transaction, but another as part of a running transaction. We
immediately hit a problem as if the BTF sets the wrong transaction and
data control scope options, it can constrain its future use, and any
post changes may break it's current use.
And this is where I'd like input from members please. From my
thinking it would seem that such reusable BTFs should always have
their transaction options set to Use Existing Transaction if Possible,
and Shared data control scope set. This would allow the BTF to join a
transaction or create its own if a transaction is not available from
the caller. This provides for the flexibility required by any
theoretical consumer/caller.
My thinking then goes further to say if the calling application wants
to change the BTFs transactional and data control scope options, it
can wrap the called BTF in another BTF that changes its own
transaction and data control scope options, which are then inherited
by the called BTF. For example if the caller create a new
transaction, the called BTF will join that transaction. However if
the caller has no transaction, then the called BTF will create its own
transaction.
Anybody have any thoughts on this?
As a side note please understand I'm not saying there aren't times
when you will build BTFs that purely require its own transaction and
isolated data control scope. Rather I'm talking about a BTF that we
know we want to be as flexible as possible to assist reuse in any
transactional scenario in the future.
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?
Your thoughts and comments appreciated.
CM.
Michael Koniotiakis
Apr 21, 2011, 4:18:13 PM4/21/11
to ADF Enterprise Methodology Group
I also have similar concerns.
Since Transaction Management is done in application module i don't
fully understand the transaction options of task flows
If you use different application modules in calling and called task
flows then transactions are different anyway
If it is the same application module in both task flows then i can't
imagine why to have different transactions.
So I feel transaction management depend mostly on application module
design.
The difference i see is in order how to handle pending changes since
on called task flow the binding is dirty if first task flow has
changes
findDataControlFrame(currentDataControlFrame).isTransactionDirty();
in isolated it is not.
Also transaction options force to have commit or rollback return
activites
So it feels like their usage is mostly to handle pending changes
during navigations.
In an enterprise application that we migrated from old forms we have
300 indipendent application modules and about the same taskflows with
the convention 1 application per task flow and all task flows shared
and <No Controller Transaction>,
It does not have any transaction issues, yet we dont use regions and
reusability is limited to calling task flows as diferent pages.
On an other project with BPMN that we have 1 application module with
many task flows that are used are human tasks (regions inside a custom
worklist) the design is to use Isolated and Always Begin New
Transaction. I will tell you how it will turn out.
May be some second level regions will need to be shared.
Regards
MK
On Apr 21, 6:24 am, Chris Muir <chriscm...@gmail.com> wrote:
> I'd like to ask ADF EMG members questions around task flow design,
> namely consideration of ensuring task flows are ultimately reusable
> without change, and specifically looking at the task flow data control
> scope & transaction options.
>
> Members would be familiar that bounded task flows (BTF) support both
> isolated and shared data control scopes, as well as four transaction
> options: <No Controller Transaction>, Always Begin New Transaction,
> Always Use Existing Transaction and Use Existing Transaction if
> Possible, as described in the Fusion Dev Guide section 16.4 and
> onwards:http://download.oracle.com/docs/cd/E17904_01/web.1111/b31974/taskflow...
Since Transaction Management is done in application module i don't
fully understand the transaction options of task flows
If you use different application modules in calling and called task
flows then transactions are different anyway
If it is the same application module in both task flows then i can't
imagine why to have different transactions.
So I feel transaction management depend mostly on application module
design.
The difference i see is in order how to handle pending changes since
on called task flow the binding is dirty if first task flow has
changes
findDataControlFrame(currentDataControlFrame).isTransactionDirty();
in isolated it is not.
Also transaction options force to have commit or rollback return
activites
So it feels like their usage is mostly to handle pending changes
during navigations.
In an enterprise application that we migrated from old forms we have
300 indipendent application modules and about the same taskflows with
the convention 1 application per task flow and all task flows shared
and <No Controller Transaction>,
It does not have any transaction issues, yet we dont use regions and
reusability is limited to calling task flows as diferent pages.
On an other project with BPMN that we have 1 application module with
many task flows that are used are human tasks (regions inside a custom
worklist) the design is to use Isolated and Always Begin New
Transaction. I will tell you how it will turn out.
May be some second level regions will need to be shared.
Regards
MK
On Apr 21, 6:24 am, Chris Muir <chriscm...@gmail.com> wrote:
> I'd like to ask ADF EMG members questions around task flow design,
> namely consideration of ensuring task flows are ultimately reusable
> without change, and specifically looking at the task flow data control
> scope & transaction options.
>
> Members would be familiar that bounded task flows (BTF) support both
> isolated and shared data control scopes, as well as four transaction
> options: <No Controller Transaction>, Always Begin New Transaction,
> Always Use Existing Transaction and Use Existing Transaction if
> Possible, as described in the Fusion Dev Guide section 16.4 and
Chris Muir
Apr 28, 2011, 12:28:46 AM4/28/11
to adf-met...@googlegroups.com
Hi Michael
Thanks for your feedback and sharing your experience.
In addressing some of your points:
"If it is the same application module in both task flows then i can't
imagine why to have different transactions."
...we make use of the UI Shell which allows users to spawn multiple
tabs, each containing a task flow. It's feasible that each tab can
use the same AM, but allow the user to undertake a different
transaction, so we require the "Always Begin New Transaction" ADFc
functionality. Admittedly most applications wont have this
requirement, it's one provided through the UI Shell and it's multi-tab
approach.
"So I feel transaction management depend mostly on application module design."
Well, kind of (IMHO). I think you first start with the AM design, but
the ADFc task flow options extend (complicate?) the options. I think
you'd be interested in the following [1] OTN forum thread with Frank
Nimphius for a discussion on "No Controller Transaction", and in turn
note the link to an earlier discussion [2] with Steve Muench about AM
pooling and his highlighted concept that AMs can be automatically
nested by the framework:
[1] http://forums.oracle.com/forums/thread.jspa?threadID=2211040&tstart=0
[2] http://forums.oracle.com/forums/thread.jspa?messageID=4022731
"Also transaction options force to have commit or rollback return
activites. So it feels like their usage is mostly to handle pending
changes during navigations."
We've had a few cases where we've created dummy task flow returns
(either commit/rollback) which aren't used at all in the task flow, as
we need to finalize the task flow with a parent navigation action. So
what we do is programatically commit the task flow and then call the
parent navigation action. In hindsight I'm not 100% this is necessary
anymore as I'm back to square 1 in assessing my task flow transaction
options.
Regarding your final comment on your BPMN solution, I'd be keen to
hear your outcomes. You will be spawning a lot of connections, but
whether it really makes a difference is questionable, I guess it
depends on the scalability you're looking for. Again refer to Steve
Muench's replies to the 2nd OTN forum thread above, he has some
experienced insight into AM design.
Cheers,
CM.
> --
> 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).
>
Steven
Apr 28, 2011, 10:36:56 AM4/28/11
to adf-met...@googlegroups.com, adf-met...@googlegroups.com
Chris,
To keep transactional flexibility and increased reuse options i have never used the taskflow transaction settings with my customers so far. Most of my customers also use a customized implementation of dynamic tabs, we ensure each tab gets its own transaction by using data control scope is isolated.
Following my tweet last week on setting data control scope at runtime, i had an email discussion this week with frank nimphius and maiko rocha on exactly the same topic. I will forward that email thread to this group. Main conclusion was that being able to set the dc scope and transaction when calling a btf might be a good ER.
Regards,
Steven
Younis
Apr 28, 2011, 6:21:10 PM4/28/11
to ADF Enterprise Methodology Group
Hi Chris,
We are just dappling in this area at this stage, so I am not sure we
have covered to the depth that others have managed to do, generally
speaking, I found that the most useful transaction options are: No
Controller Transaction & Use Existing Transaction if Possible, I will
start with the latter first
Use Existing Transaction if Possible, as the name suggests will start
a new transaction if none exist otherwise, it will join the existing
transaction, this however have its gotachs, first, you cannot call
explicit commits, that is using a commit exposed from the AM instance,
as it will commit the whole transaction (I cannot imagine a case where
the child BTF would commit the master BTF), likewise for roll-back,
the second is that the commit and roll-back on the return activity
will only be honoured if the BTF started the transaction, they will be
ignored otherwise !!! These 2 makes a really interesting
implementation when you chose to cancel user changes, as you should
not be calling a roll-back on a child BTF, one option is to use save
point (hint: have you noticed on the return activity there is the
option to restore save point), and it is doubly hard if you wish to
implement an undo edit behaviour. So really only the BTF that have
started the transaction is assumed to be the one that will decide the
fate of the whole transaction.
No Controller Transaction: in this instance the BTF will not create
new transactions for you, it is instead you have to managed the commit
and roll-back using the AM instance, I did a quick test on that, and
it seems that it uses the AM to manage the transaction, so if you have
2 BTFs and they both using the same AM instance, then committing at
any stage will commit all, while if you have 2 separate AMs then each
commit will only commit its own data controls. In other words the
AM(s) are managing the transaction not the controller.
I hope I managed to explain my understanding, and what I am saying
actually makes sense, please do share your findings with us as we have
a lot of interest in that.
P.S. I am happy to share the very quick and dirty examples that I have
done, they are based on the HR schema.
Regards,
Younis
We are just dappling in this area at this stage, so I am not sure we
have covered to the depth that others have managed to do, generally
speaking, I found that the most useful transaction options are: No
Controller Transaction & Use Existing Transaction if Possible, I will
start with the latter first
Use Existing Transaction if Possible, as the name suggests will start
a new transaction if none exist otherwise, it will join the existing
transaction, this however have its gotachs, first, you cannot call
explicit commits, that is using a commit exposed from the AM instance,
as it will commit the whole transaction (I cannot imagine a case where
the child BTF would commit the master BTF), likewise for roll-back,
the second is that the commit and roll-back on the return activity
will only be honoured if the BTF started the transaction, they will be
ignored otherwise !!! These 2 makes a really interesting
implementation when you chose to cancel user changes, as you should
not be calling a roll-back on a child BTF, one option is to use save
point (hint: have you noticed on the return activity there is the
option to restore save point), and it is doubly hard if you wish to
implement an undo edit behaviour. So really only the BTF that have
started the transaction is assumed to be the one that will decide the
fate of the whole transaction.
No Controller Transaction: in this instance the BTF will not create
new transactions for you, it is instead you have to managed the commit
and roll-back using the AM instance, I did a quick test on that, and
it seems that it uses the AM to manage the transaction, so if you have
2 BTFs and they both using the same AM instance, then committing at
any stage will commit all, while if you have 2 separate AMs then each
commit will only commit its own data controls. In other words the
AM(s) are managing the transaction not the controller.
I hope I managed to explain my understanding, and what I am saying
actually makes sense, please do share your findings with us as we have
a lot of interest in that.
P.S. I am happy to share the very quick and dirty examples that I have
done, they are based on the HR schema.
Regards,
Younis
Chris Muir
Apr 28, 2011, 8:33:52 PM4/28/11
to ADF Enterprise Methodology Group
Thanks for your feedback Younis
One point I'd make is be careful to include data control scope in your
discussions. Just discussing the transaction options are not enough,
the scope is if not more important than the transaction options.
However from the context of your discussion, assuming you meant Use
Existing Transaction if Possible and *shared* data control scope, then
I believe we're in agreement.
However regards No Controller Transaction, as noted in a previous
post, I suggest you read (if not already) this OTN thread with further
implications about using this option:
http://forums.oracle.com/forums/thread.jspa?threadID=2211040&tstart=0
In turn just be a little careful in saying "No Controller Transaction:
in this instance the BTF will not create new transactions for you" ...
remembering the transactions and associated connections interact with
an Oracle database, where the simply act of querying data will start a
transaction (aka. read consistency).
For other readers please note's Steven Davelaar's new thread on data
control scope: http://groups.google.com/group/adf-methodology/browse_thread/thread/cc7f4ca53ef5af6c?hl=en#
CM.
One point I'd make is be careful to include data control scope in your
discussions. Just discussing the transaction options are not enough,
the scope is if not more important than the transaction options.
However from the context of your discussion, assuming you meant Use
Existing Transaction if Possible and *shared* data control scope, then
I believe we're in agreement.
However regards No Controller Transaction, as noted in a previous
post, I suggest you read (if not already) this OTN thread with further
implications about using this option:
http://forums.oracle.com/forums/thread.jspa?threadID=2211040&tstart=0
In turn just be a little careful in saying "No Controller Transaction:
in this instance the BTF will not create new transactions for you" ...
remembering the transactions and associated connections interact with
an Oracle database, where the simply act of querying data will start a
transaction (aka. read consistency).
For other readers please note's Steven Davelaar's new thread on data
control scope: http://groups.google.com/group/adf-methodology/browse_thread/thread/cc7f4ca53ef5af6c?hl=en#
CM.
Younis
Apr 28, 2011, 9:21:04 PM4/28/11
to ADF Enterprise Methodology Group
Hi Chris,
You are right on the money that the data scope changes have to be
considered, I think what I was trying to do is to fix one, based on
the behaviour that I want, then the choices will be limited. Plus, my
perspective is heavily weighed in on by our implementation (e.g.
shared AM, passing data vs sharing DC, single DB vs. multiple DB),
which would definitely have an impact on the choices one would have to
make.
I think with the "No Controller Transaction", as I mentioned, I have
tried 2 simple example one using 2 AMs and the other using 1, it seems
that when you are using 2 AMs each commit is handled independently,
this has been my observation when using a ADF BC, the case as it is
highlighted in the OTN entry might be more complicated.
Regards,
Younis
On Apr 29, 10:33 am, Chris Muir <chriscm...@gmail.com> wrote:
> Thanks for your feedback Younis
>
> One point I'd make is be careful to include data control scope in your
> discussions. Just discussing the transaction options are not enough,
> the scope is if not more important than the transaction options.
> However from the context of your discussion, assuming you meant Use
> Existing Transaction if Possible and *shared* data control scope, then
> I believe we're in agreement.
>
> However regards No Controller Transaction, as noted in a previous
> post, I suggest you read (if not already) this OTN thread with further
> implications about using this option:http://forums.oracle.com/forums/thread.jspa?threadID=2211040&tstart=0
>
> In turn just be a little careful in saying "No Controller Transaction:
> in this instance the BTF will not create new transactions for you" ...
> remembering the transactions and associated connections interact with
> an Oracle database, where the simply act of querying data will start a
> transaction (aka. read consistency).
>
> For other readers please note's Steven Davelaar's new thread on data
> control scope:http://groups.google.com/group/adf-methodology/browse_thread/thread/c...
You are right on the money that the data scope changes have to be
considered, I think what I was trying to do is to fix one, based on
the behaviour that I want, then the choices will be limited. Plus, my
perspective is heavily weighed in on by our implementation (e.g.
shared AM, passing data vs sharing DC, single DB vs. multiple DB),
which would definitely have an impact on the choices one would have to
make.
I think with the "No Controller Transaction", as I mentioned, I have
tried 2 simple example one using 2 AMs and the other using 1, it seems
that when you are using 2 AMs each commit is handled independently,
this has been my observation when using a ADF BC, the case as it is
highlighted in the OTN entry might be more complicated.
Regards,
Younis
On Apr 29, 10:33 am, Chris Muir <chriscm...@gmail.com> wrote:
> Thanks for your feedback Younis
>
> One point I'd make is be careful to include data control scope in your
> discussions. Just discussing the transaction options are not enough,
> the scope is if not more important than the transaction options.
> However from the context of your discussion, assuming you meant Use
> Existing Transaction if Possible and *shared* data control scope, then
> I believe we're in agreement.
>
> However regards No Controller Transaction, as noted in a previous
> post, I suggest you read (if not already) this OTN thread with further
> implications about using this option:http://forums.oracle.com/forums/thread.jspa?threadID=2211040&tstart=0
>
> In turn just be a little careful in saying "No Controller Transaction:
> in this instance the BTF will not create new transactions for you" ...
> remembering the transactions and associated connections interact with
> an Oracle database, where the simply act of querying data will start a
> transaction (aka. read consistency).
>
> For other readers please note's Steven Davelaar's new thread on data
Chris Muir
Apr 28, 2011, 10:26:03 PM4/28/11
to ADF Enterprise Methodology Group
"Plus, my perspective is heavily weighed in on by our implementation"
...it's this point when discussing BTFs makes it so hard. Ultimately
there's a huge amount of variables and combination of options when
using BTFs that different applications can make use of. From this
thread and others I can see we're each discussing the options from our
limited usage, which makes one man's definitive rule, another man's
option.
My fear is, given all the different combination of options, by
arbitrarily picking one option set, we may limit our future ability to
expand the application or make use of all of ADFs features.
CM.
Michael Koniotiakis
May 3, 2011, 5:02:06 AM5/3/11
to ADF Enterprise Methodology Group
--Quota
We had a big failure that kept me up last night about this design
decision
It seems that When we use Task flow transaction controler options then
the ApplicationModuleImpl.getUserPrincipalName gives a
java.lang.NullPointerException.
http://adfbugs.blogspot.com/2011/05/application-module-cannot-get-principal.html
I also posted SR 3-3526884161 about this.
I just wonder if a workaround like:
getDBTransaction().getSession().getEnvironment().get("jbo.user.principal")
is enough or will i meet other walls around the corner?
Have you come accross something similar?
Thanks
> > > > Younis- Απόκρυψη κειμένου σε παράθεση -
>
> - Εμφάνιση κειμένου σε παράθεση -
On an other project with BPMN that we have 1 application module with
many task flows that are used are human tasks (regions inside a
custom
worklist) the design is to use Isolated and Always Begin New
Transaction. I will tell you how it will turn out.
--
many task flows that are used are human tasks (regions inside a
custom
worklist) the design is to use Isolated and Always Begin New
Transaction. I will tell you how it will turn out.
We had a big failure that kept me up last night about this design
decision
It seems that When we use Task flow transaction controler options then
the ApplicationModuleImpl.getUserPrincipalName gives a
java.lang.NullPointerException.
http://adfbugs.blogspot.com/2011/05/application-module-cannot-get-principal.html
I also posted SR 3-3526884161 about this.
I just wonder if a workaround like:
getDBTransaction().getSession().getEnvironment().get("jbo.user.principal")
is enough or will i meet other walls around the corner?
Have you come accross something similar?
Thanks
>
> - Εμφάνιση κειμένου σε παράθεση -
Jan Vervecken
May 4, 2011, 5:12:36 PM5/4/11
to ADF Enterprise Methodology Group
hi Michael
About your blog post "Application Module cannot get principal when you
use transaction controller in task flows"
at http://adfbugs.blogspot.com/2011/05/application-module-cannot-get-principal.html
see also forum thread "ADFContext instead of
ApplicationModuleImpl.getUserPrincipalName()"
at http://forums.oracle.com/forums/thread.jspa?threadID=2217602
regards
Jan Vervecken
On May 3, 11:02 am, Michael Koniotiakis <mko...@hotmail.com> wrote:
> --Quota
> On an other project with BPMN that we have 1 application module with
> many task flows that are used are human tasks (regions inside a
> custom
> worklist) the design is to use Isolated and Always Begin New
> Transaction. I will tell you how it will turn out.
> --
>
> We had a big failure that kept me up last night about this design
> decision
>
> It seems that When we use Task flow transaction controler options then
> the ApplicationModuleImpl.getUserPrincipalName gives a
> java.lang.NullPointerException.
>
> http://adfbugs.blogspot.com/2011/05/application-module-cannot-get-pri...
> > > > > Younis- Áðüêñõøç êåéìÝíïõ óå ðáñÜèåóç -
>
> > - ÅìöÜíéóç êåéìÝíïõ óå ðáñÜèåóç -
About your blog post "Application Module cannot get principal when you
use transaction controller in task flows"
at http://adfbugs.blogspot.com/2011/05/application-module-cannot-get-principal.html
see also forum thread "ADFContext instead of
ApplicationModuleImpl.getUserPrincipalName()"
at http://forums.oracle.com/forums/thread.jspa?threadID=2217602
regards
Jan Vervecken
On May 3, 11:02 am, Michael Koniotiakis <mko...@hotmail.com> wrote:
> --Quota
> On an other project with BPMN that we have 1 application module with
> many task flows that are used are human tasks (regions inside a
> custom
> worklist) the design is to use Isolated and Always Begin New
> Transaction. I will tell you how it will turn out.
> --
>
> We had a big failure that kept me up last night about this design
> decision
>
> It seems that When we use Task flow transaction controler options then
> the ApplicationModuleImpl.getUserPrincipalName gives a
> java.lang.NullPointerException.
>
> I also posted SR 3-3526884161 about this.
>
> I just wonder if a workaround like:
> getDBTransaction().getSession().getEnvironment().get("jbo.user.principal")
> is enough or will i meet other walls around the corner?
>
> Have you come accross something similar?
>
> Thanks
>
>
> I just wonder if a workaround like:
> getDBTransaction().getSession().getEnvironment().get("jbo.user.principal")
> is enough or will i meet other walls around the corner?
>
> Have you come accross something similar?
>
> Thanks
>
>
> > - ÅìöÜíéóç êåéìÝíïõ óå ðáñÜèåóç -
Michael Koniotiakis
May 8, 2011, 1:25:56 PM5/8/11
to ADF Enterprise Methodology Group
Thanks for your replies on the bug.
In our application we have a main page that we load Task flows in
dynamic regions.
We needed a way to handle the transactions generically no matter which
task flow is loaded.
To do that we needed either to
• Use only 1 root application module (cannot be done since we import
other taskflows as adf libraries)
• Use DataControl frame transactions:
BindingContext bindingContext = BindingContext.getCurrent();
String dCFrameName =
bindingContext.getCurrentDataControlFrame();
DataControlFrame dcf =
bindingContext.findDataControlFrame(dCFrameName);
dcf.commit();
dcf.rollback();
In order the above code to work all loaded task flows in regions
should try to share the same transaction if possible and data control
scope.
If Transaction controller of task flow is <No Controller Transaction>,
or < Always Begin New Transaction> then the above code does not work.
In first option because the transaction is not handled by the
controller, in second option because the transaction is different in
different task flows.
For this reason in all task flows we should use the <Use Existing
Transaction if possible>and shared dc.
On May 5, 12:12 am, Jan Vervecken <verv...@gmail.com> wrote:
> hi Michael
>
> About your blog post "Application Module cannot get principal when you
> use transaction controller in task flows"
> athttp://adfbugs.blogspot.com/2011/05/application-module-cannot-get-pri...
> > > - ÅìöÜíéóç êåéìÝíïõ óå ðáñÜèåóç -- Hide quoted text -
>
> - Show quoted text -
In our application we have a main page that we load Task flows in
dynamic regions.
We needed a way to handle the transactions generically no matter which
task flow is loaded.
To do that we needed either to
• Use only 1 root application module (cannot be done since we import
other taskflows as adf libraries)
• Use DataControl frame transactions:
BindingContext bindingContext = BindingContext.getCurrent();
String dCFrameName =
bindingContext.getCurrentDataControlFrame();
DataControlFrame dcf =
bindingContext.findDataControlFrame(dCFrameName);
dcf.commit();
dcf.rollback();
In order the above code to work all loaded task flows in regions
should try to share the same transaction if possible and data control
scope.
If Transaction controller of task flow is <No Controller Transaction>,
or < Always Begin New Transaction> then the above code does not work.
In first option because the transaction is not handled by the
controller, in second option because the transaction is different in
different task flows.
For this reason in all task flows we should use the <Use Existing
Transaction if possible>and shared dc.
On May 5, 12:12 am, Jan Vervecken <verv...@gmail.com> wrote:
> hi Michael
>
> About your blog post "Application Module cannot get principal when you
> use transaction controller in task flows"
> see also forum thread "ADFContext instead of
> ApplicationModuleImpl.getUserPrincipalName()"
> athttp://forums.oracle.com/forums/thread.jspa?threadID=2217602
> ApplicationModuleImpl.getUserPrincipalName()"
>
> - Show quoted text -
Chris Muir
May 17, 2011, 12:26:43 AM5/17/11
to ADF Enterprise Methodology Group
Hi Michael
As a follow up to your replies, I've been working through some
examples trying to understand the behaviour of the framework with
different BTF transaction options, the result being the following 2
blog entries:
1) 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
2) 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
Apologies for the length, but I felt it necessary to explain the
basics before leaping into the nesting feature.
As per the end of the 2nd blog post I'm not 100% sure my posts are
correct, each post was really based on the comment by Steve Muench,
and then trying to find examples to exhibit the behaviour Steve
described. However our current application design heavily relies on
the automatic nesting behaviour to minimize connections, so I hope
it's right! Point being if you see anything glaringly wrong with
either post besides typos, I'd be more than happy to discuss the issue
here on the ADF EMG.
Hopefully this blog posts will be helpful to others too.
CM.
PS. Apologies, but the first blog post has some text chopped off the
beginning. I'll attempt to rectify this tonight.
As a follow up to your replies, I've been working through some
examples trying to understand the behaviour of the framework with
different BTF transaction options, the result being the following 2
blog entries:
1) 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
2) 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
Apologies for the length, but I felt it necessary to explain the
basics before leaping into the nesting feature.
As per the end of the 2nd blog post I'm not 100% sure my posts are
correct, each post was really based on the comment by Steve Muench,
and then trying to find examples to exhibit the behaviour Steve
described. However our current application design heavily relies on
the automatic nesting behaviour to minimize connections, so I hope
it's right! Point being if you see anything glaringly wrong with
either post besides typos, I'd be more than happy to discuss the issue
here on the ADF EMG.
Hopefully this blog posts will be helpful to others too.
CM.
PS. Apologies, but the first blog post has some text chopped off the
beginning. I'll attempt to rectify this tonight.
Michael Koniotiakis
Jun 11, 2011, 5:28:00 AM6/11/11
to ADF Enterprise Methodology Group
Thank you Chris for the udate.
Those are great posts. Nice work.
Yet we still have issues with the reusability of Task flows and Shared
control scope.
When you use the same task flows 2 times as region in the same page,
then only one application module istance is created, and one instance
of view objects.
This causes both regions to display the same data no mater if with
parameters we try to define diferent.
this hapen also if the same region exist in different level of
regions.
If this is by design and not a bug then it realy limit the reuse of
the same region.
Regards
Michael.
On 17 Μάϊος, 07:26, Chris Muir <chriscm...@gmail.com> wrote:
> Hi Michael
>
> As a follow up to your replies, I've been working through some
> examples trying to understand the behaviour of the framework with
> different BTF transaction options, the result being the following 2
> blog entries:
>
> 1) 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-flo...
> ...
>
> διαβάστε περισσότερα »- Απόκρυψη κειμένου σε παράθεση -
Those are great posts. Nice work.
Yet we still have issues with the reusability of Task flows and Shared
control scope.
When you use the same task flows 2 times as region in the same page,
then only one application module istance is created, and one instance
of view objects.
This causes both regions to display the same data no mater if with
parameters we try to define diferent.
this hapen also if the same region exist in different level of
regions.
If this is by design and not a bug then it realy limit the reuse of
the same region.
Regards
Michael.
On 17 Μάϊος, 07:26, Chris Muir <chriscm...@gmail.com> wrote:
> Hi Michael
>
> As a follow up to your replies, I've been working through some
> examples trying to understand the behaviour of the framework with
> different BTF transaction options, the result being the following 2
> blog entries:
>
> 1) JDev 11g, Task Flows & ADF BC – the Always use Existing Transaction
> 2) 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-flo...
>
> διαβάστε περισσότερα »- Απόκρυψη κειμένου σε παράθεση -
Reply all
Reply to author
Forward
0 new messages