bpel4people message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [bpel4people] ISSUE 6: Title: Does ht:getLogicalPeopleGroup() cause an LPG to evaluate?
- From: "Mark Ford" <mark.ford@activevos.com>
- To: "'Matthias Kloppmann'" <matthias-kloppmann@de.ibm.com>
- Date: Fri, 23 May 2008 09:16:16 -0400
Matthias,
Would you agree then that the function needs to have
optional arguments in order to behave the same way that accessing an LPG in a
task would?
Something along the lines of:
ht:getLogicalPeopleGroup( 'Salesperson', 'region',
getInput()/region, 'orderAmount', getInput()/orderAmount )
The first argument is required and it is the name of the
LPG. The additional arguments are optional but if present must come in pairs of
literal/expression in the same way that the bpel:doXslTransform
works.
I think the spec should clarify exactly when an
LPG should be resolved or re-resolved but it should be up to the underlying
implementation whether or not to re-run the underlying people
query. For example, if you assign to an LPG then you never re-resolve it.
This gives the process designer total control over the value of that
LPG. All other decisions about whether or not to re-resolve the LPG
should be an implementation detail that is under the control of the
deployer of the process which is outside of our
scope.
Mark, Martin, all,
(Unfortunately, I couldn't participate in
the 5/14 meeting, so don't know exactly what was discussed ...)
However, from my point of view the
intention of that function was the ability to explicitly retrieve the user IDs
associated with an LPG, _in_the_same_way_ that using that LPG in a task would
do. Specifically, that means that if the LPG hadn't been resolved yet, it is
resolved.
Also, our original
intention was to leave it open (i.e., out of scope for the spec, as an
implementation/optimization detail) when an LPG would actually be resolved or
re-resolved, so whether or not accessing that function (or using the LPG in a
task, which is the same) triggers re-resolution or not is out of scope. I can
see why people would not be happy with leaving that out of scope, but personally
I still think it's a good idea. (As an analogy: Does BPEL state when a
partnerLink is bound to an EPR, or whether it could be re-bound during execution
of a process instance because of changed information in a registry? Readers of
the spec will make their assumptions, but I doubt [i.e., hope] that it's
specified, leaving implementor's and users of BPEL with different
options.)
Viele
Grüße/Kind regards,
-Matthias
From:
| "Mark Ford"
<mark.ford@activevos.com>
|
To:
| "'Martin Chapman'"
<martin.chapman@oracle.com>,
<bpel4people@lists.oasis-open.org>, "'Trickovic, Ivana'"
<ivana.trickovic@sap.com>
|
Date:
| 15.05.2008 16:24
|
Subject:
| RE: [bpel4people] ISSUE 6: Title: Does
ht:getLogicalPeopleGroup() cause an LPG to
evaluate? |
Martin,
Technically it's not the function's
behavior that's different but rather the
LPG's behavior. Once an LPG is
assigned to it is sticky. Therefore any
request for its data will return the
value previously assigned, ignoring any
arguments passed into the LPG for its
evaluation.
Based on your comment, I would expect you would raise a
similar concern over
the ht:from and bpel:from logicalPeopleGroup variations
since they exhibit
the same behavior.
-----Original
Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Thursday, May 15, 2008 9:47 AM
To: 'Mark Ford';
bpel4people@lists.oasis-open.org; 'Trickovic, Ivana'
Subject: RE:
[bpel4people] ISSUE 6: Title: Does ht:getLogicalPeopleGroup()
cause an LPG to
evaluate?
Mark,
A function that behaves differently depending on
context, as suggested in
the last paragraph, is always a bad idea in my
opinion.
I'd rather see two different functions, or a parameter requesting
evaluation
or not.
Martin.
>-----Original
Message-----
>From: Mark Ford [mailto:mark.ford@activevos.com]
>Sent: Wednesday, May 14, 2008 8:54 PM
>To:
bpel4people@lists.oasis-open.org; 'Trickovic, Ivana'
>Subject:
[bpel4people] ISSUE 6: Title: Does
>ht:getLogicalPeopleGroup() cause an
LPG to evaluate?
>
>
>The discussion at today's conference
call clarified that the
>original intent for this custom function was to
provide a
>means for getting a value from an LPG without triggering an
>evaluation of the LPG. The assumption is that the LPG would
>have
been previously evaluated and the process or task
>definition wants to
reference the same value from that LPG to
>ensure that it doesn't change
with another evaluation.
>
>I don't see the use case for this
implementation. If a user
>wants to ensure that they're getting the exact
same values
>from an LPG then they can use a local variable to store
those
>values and read from that variable. If the function is going
>to be used within a task definition then the caller would more
>likely want to pull organizational entities from one of the
>task's generic human roles as opposed to pulling directly from
>the LPG. The same would apply if someone were building a four
>eyes pattern with people activities. It's better to use the
>b4p
functions to pull the values from the generic human roles
>rather than to
try and reuse a value from an LPG.
>
>The simpler approach is to
have one way of accessing LPG data.
>Each call into an LPG triggers an
evaluation of the LPG. The
>only exception is if the LPG was previously
assigned. With
>this model, an LPG has two states: unassigned and
assigned.
>LPG's are in the assigned state when they are the target of a
>copy operation. In this state they always returns the same
>value. An LPG in the unassigned state always evaluates. In
>this
approach, there is no difference between the custom
function
>ht:getLogicalPeopleGroup() and the ht:from or
bpel:from.
>
>
>
>---------------------------------------------------------------------
>To
unsubscribe from this mail list, you must leave the OASIS
>TC that
generates this mail. You may a link to this group and
>all your TCs
in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]