OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bpel4people message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [bpel4people] BP-83 - Override capabilities for a B4PpeopleActivity calling a task defined with a routing pattern or composite


All, my proposal for BP-83 is that we go with proposal #3 from Dieter below. I.e. in the case a task has a single-level routing pattern and the task context tPeopleAssignments contained more than one person, we would overwrite the existing users in the task defintion routern pattern with the ones from the task context. As Dieter calls out below, we would not support override in nested routing patterns or composite tasks.

I think we should define this in section 8.4.1, but wanted to get feedback from the TC before working up the proposed text.

Thanks,
alex

-----Original Message-----
From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com]
Sent: Thursday, June 18, 2009 3:19 PM
To: bpel4people@lists.oasis-open.org
Subject: [bpel4people] BP-83 - Override capabilities for a B4P peopleActivity calling a task defined with a routing pattern or composite



At the 2009-06-18 TC F2F meeting, we discussed options for resolving BP-83 (without getting to a decision).

Depending on the resolution, it may affect the following:
(a) BPEL4People 1.1, section 4.2 Standard Overriding Elements
    Elements
<htd:{local,remote}Task>/<htd:peopleAssignments>/<htd:potentialOwners>
(b) WS-HumanTask 1.1, section 7.4 Providing Human Task Context
    Element
<htc:humanTaskRequestContext>/<htc:peopleAssignments>/<htc:potentialOwners>

Options (an incomplete list):
(1) don't change (a) and (b) -- only allow override for simple tasks
(2) don't change (a) and (b) -- allow override, but the result will become a simple task (replace any routing pattern)
(3) don't change (a) and (b) -- allow override for simple tasks and single-level parallel/sequential routing patterns)
(4) extend (a) and (b) -- allow override for all tasks, but the structure must fit to the routing pattern definition
(5) extend (a) and (b) -- allow override for all tasks, include a change of the structure

Mike R. noted that routing patterns are useful syntax in addition to composite tasks, partly because they separate the issue of "who" does tasks from the definition of the "what gets done" of the task.  This is especially useful for override.  We would be able to say that people activities can override the who, but not the what.

As a result, we may allow flexible override (e.g. as in option (5) above) for routing patterns (and simple tasks), but not for composite task definitions.

Kind Regards

Dieter König

Senior Technical Staff Member, WebSphere Process Server Architect) IBM Software Group, Application and Integration Middleware Software WSS Business Process Solutions





  Phone:            +49-7031-16-3426           IBM Deutschland                      (Embedded
                                                                                  image moved
                                                                                     to file:
                                                                                pic30242.gif)

  E-Mail:           dieterkoenig@de.ibm.com    Schönaicher Str. 220

                                               71032 Böblingen

                                               Germany





  IBM Deutschland
  Research &
  Development
  GmbH /
  Vorsitzender des
  Aufsichtsrats:
  Martin Jetter
  Geschäftsführung:
  Erich Baier
  Sitz der
  Gesellschaft:
  Böblingen /
  Registergericht:
  Amtsgericht
  Stuttgart, HRB
  243294



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]