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 14:33:07 -0400
Your last paragraph is exactly the point that I raised on
the call.
Ah, interesting -- I have to admit I
hadn't thought of that -- but you are right of course, if there are parameters
and this is the first resolution, there must be a way to bind them. Admittedly,
I don't like the associated complexity for a capability that I consider a pretty
special case (IMO, you'd typically use an assign from logicalPeopleGroup clause
to explicitly trigger LPG resolution, at least in a BPEL process, and there you
already can specify the arguments) ... but still, if we want the full capability
to access LPGs in XPath, too (which was a design goal), then we need the
overloading you describe. So, yes, I agree.
Regarding resolution and re-resolution vs. running the people query: Not
sure whether we agree 100% here or not. IMO, and I think you are saying the
same: When accessed, the LPG should always provide a "meaningful value", so that
means its resolved on first touch _at_the_latest_ (could in theory be resolved
at deployment time, during process instantiation or at any other time before
being accessed). Whether it is allowed to change its value after that through
re-resolution (such as running a people query) is out of scope in general --
however, when the LPG received its value through an explicit assignment, the
assumption should be that this value is retained. In all other cases, when you
want to make sure you get a specific set of user IDs, either assign the LPG into
a variable, or use a function such as getPotentialOwners(), but don't assume the
LPG returns the same set of userIDs when accessed at a later point in
time.
Viele
Grüße/Kind regards,
-Matthias
From:
| "Mark Ford"
<mark.ford@activevos.com>
|
To:
| Matthias
Kloppmann/Germany/IBM@IBMDE
|
Cc:
| <bpel4people@lists.oasis-open.org>,
"'Trickovic, Ivana'" <ivana.trickovic@sap.com>, "'Martin Chapman'"
<martin.chapman@oracle.com>
|
Date:
| 23.05.2008 15:23
|
Subject:
| RE: [bpel4people] ISSUE 6: Title: Does
ht:getLogicalPeopleGroup() cause an LPG to
evaluate? |
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.
From: Matthias Kloppmann [mailto:matthias-kloppmann@de.ibm.com]
Sent: Friday, May 23, 2008 6:35 AM
To: Mark
Ford
Cc: bpel4people@lists.oasis-open.org; 'Trickovic, Ivana'; 'Martin
Chapman'
Subject: RE: [bpel4people] ISSUE 6: Title: Does
ht:getLogicalPeopleGroup() cause an LPG to evaluate?
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]