[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [bpel4people] BP-83 Propsal (Override capabilities for a task)
All, Please see attached the new resolution proposal for BP-83. Regards, Alex -----Original Message----- From: Alex Malek [mailto:alexma@exchange.microsoft.com] Sent: Wednesday, August 05, 2009 7:44 AM To: bpel4people@lists.oasis-open.org Subject: RE: [bpel4people] BP-83 - Override capabilities for a B4P peopleActivity 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to 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]