<p>1</p><p>2WS-BPEL Extension for People 3(BPEL4People) 4Specification Version 1.1</p><p>5Working Draft 01 612 March 2008 7 8 9Specification URIs: 10This Version: 11 http://docs.oasis-open.org/bpel4people/bpel4people-1.1-spec-wd-01.html 12 http://docs.oasis-open.org/bpel4people/bpel4people-1.1-spec-wd-01.doc 13 http://docs.oasis-open.org/bpel4people/bpel4people-1.1-spec-wd-01.pdf 14Previous Version: 15 N/A 16Latest Version: 17 http://docs.oasis-open.org/bpel4people/bpel4people-1.1.html 18 http://docs.oasis-open.org/bpel4people/bpel4people-1.1.doc 19 http://docs.oasis-open.org/bpel4people/bpel4people-1.1.pdf 20Latest Approved Version: 21 N/A 22 23Technical Committee: 24 OASIS BPEL4People TC 25 26Chair: 27 Dave Ings, IBM 28 29Editor(s): 30 Charlton Barreto, Adobe Systems 31 Mark Ford, Active Endpoints, Inc. 32 Dieter König, IBM 33 Ralf Mueller, Oracle Corporation 34 Krasimir Nedkov, SAP AG 35 Ivana Trickovic, SAP</p><p>1bpel4people-spec-WD-01 12 March 2008 2Copyright © OASIS® 2008. All Rights Reserved. Page 1 of 54 36 Alessandro Triglia, OSS Nokalva 37 38Related work: 39 This specification is related to: 40  BPEL4People – WS-HumanTask Specification – Version 1.1 41  Web Services – Business Process Execution Language – Version 2.0 – 42 http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html 43 44Declared XML Namespace(s): 45 BPEL4People namespace (defined in this specification): 46  b4p – http://docs.oasis-open.org/ns/bpel4people/bpel4people/200803 47 Other namespaces: 48  htd – http://docs.oasis-open.org/ns/bpel4people/ws-humantask/200803 49  bpel – http://docs.oasis-open.org/wsbpel/2.0/process/executable 50  wsdl – http://schemas.xmlsoap.org/wsdl/ 51  xsd – http://www.w3.org/2001/XMLSchema 52  xsi – http://www.w3.org/2001/XMLSchema-instance 53 54Abstract: 55 Web Services Business Process Execution Language, version 2.0 (WS-BPEL 2.0 or BPEL for 56 brevity) introduces a model for business processes based on Web services. A BPEL process 57 orchestrates interactions among different Web services. The language encompasses features 58 needed to describe complex control flows, including error handling and compensation behavior. 59 In practice, however many business process scenarios require human interactions. A process 60 definition should incorporate people as another type of participants, because humans may also 61 take part in business processes and can influence the process execution. 62 This specification introduces a BPEL extension to address human interactions in BPEL as a first- 63 class citizen. It defines a new type of basic activity which uses human tasks as an 64 implementation, and allows specifying tasks local to a process or use tasks defined outside of the 65 process definition. This extension is based on the WS-HumanTask specification. 66 67Status: 68 This document was last revised or approved by the [TC name | membership of OASIS]on the 69 above date. The level of approval is also listed above. Check the “Latest Version” or “Latest 70 Approved Version” location noted above for possible later revisions of this document. 71 Technical Committee members should send comments on this specification to the Technical 72 Committee’s email list. Others should send comments to the Technical Committee by using the 73 “Send A Comment” button on the Technical Committee’s web page at http://www.oasis- 74 open.org/committees/bpel4people/. 75 For information on whether any patents have been disclosed that may be essential to 76 implementing this specification, and any offers of patent licensing terms, please refer to the 77 Intellectual Property Rights section of the Technical Committee web page (http://www.oasis- 78 open.org/committees/bpel4people/ipr.php. 79 The non-normative errata page for this specification is located at http://www.oasis- 80 open.org/committees/bpel4people/.</p><p>4bpel4people-spec-WD-01 12 March 2008 5Copyright © OASIS® 2008. All Rights Reserved. Page 2 of 54 81Notices</p><p>82Copyright © OASIS® 2008. All Rights Reserved. 83All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 84Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 85This document and translations of it may be copied and furnished to others, and derivative works that 86comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 87and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 88and this section are included on all such copies and derivative works. However, this document itself may 89not be modified in any way, including by removing the copyright notice or references to OASIS, except as 90needed for the purpose of developing any document or deliverable produced by an OASIS Technical 91Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 92be followed) or as required to translate it into languages other than English. 93The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 94or assigns. 95This document and the information contained herein is provided on an "AS IS" basis and OASIS 96DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 97WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 98OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 99PARTICULAR PURPOSE. 100OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 101necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 102to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 103such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 104produced this specification. 105OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 106any patent claims that would necessarily be infringed by implementations of this specification by a patent 107holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 108Mode of the OASIS Technical Committee that produced this specification. OASIS may include such 109claims on its website, but disclaims any obligation to do so. 110OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 111might be claimed to pertain to the implementation or use of the technology described in this document or 112the extent to which any license under such rights might or might not be available; neither does it represent 113that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 114rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 115OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 116to be made available, or the result of an attempt made to obtain a general license or permission for the 117use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 118Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 119information or list of intellectual property rights will at any time be complete, or that any claims in such list 120are, in fact, Essential Claims. 121The names "OASIS", [insert specific trademarked names and abbreviations here] are trademarks of 122OASIS, the owner and developer of this specification, and should be used only to refer to the organization 123and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, 124while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis- 125open.org/who/trademark.php for above guidance.</p><p>7bpel4people-spec-WD-01 12 March 2008 8Copyright © OASIS® 2008. All Rights Reserved. Page 3 of 54 126Table of Contents</p><p>1271 Introduction...... 6 1282 Language Design...... 7 129 2.1 Dependencies on Other Specifications...... 7 130 2.2 Notational Conventions...... 7 131 2.3 Language Extensibility...... 7 132 2.4 Overall Language Structure...... 7 133 2.4.1 Syntax...... 7 1343 Concepts...... 10 135 3.1 Generic Human Roles...... 10 136 3.1.1 Syntax...... 10 137 3.2 Assigning People...... 11 138 3.2.1 Using Logical People Groups...... 11 139 3.2.2 Computed Assignment...... 13 140 3.3 Ad-hoc Attachments...... 14 1414 People Activity...... 15 142 4.1 Overall Syntax...... 15 143 4.1.1 Properties...... 16 144 4.2 Standard Overriding Elements...... 17 145 4.3 People Activities Using Local Human Tasks...... 18 146 4.3.1 Syntax...... 18 147 4.3.2 Examples...... 19 148 4.4 People Activities Using Local Notifications...... 19 149 4.4.1 Syntax...... 19 150 4.4.2 Examples...... 20 151 4.5 People Activities Using Remote Human Tasks...... 20 152 4.5.1 Syntax...... 20 153 4.5.2 Example...... 21 154 4.5.3 Passing Endpoint References for Callbacks...... 21 155 4.6 People Activities Using Remote Notifications...... 22 156 4.6.1 Syntax...... 22 157 4.6.2 Example...... 22 158 4.7 Elements for Scheduled Actions...... 22 159 4.8 People Activity Behavior and State Transitions...... 24 160 4.9 Task Instance Data...... 25 161 4.9.1 Presentation Data...... 25 162 4.9.2 Context Data...... 26 163 4.9.3 Operational Data...... 26 1645 XPath Extension Functions...... 27 1656 Coordinating Standalone Human Tasks...... 29 166 6.1 Protocol Messages from the People Activity’s Perspective...... 29 1677 BPEL Abstract Processes...... 31 168 7.1 Hiding Syntactic Elements...... 31</p><p>10bpel4people-spec-WD-01 12 March 2008 11Copyright © OASIS® 2008. All Rights Reserved. Page 4 of 54 169 7.1.1 Opaque Activities...... 31 170 7.1.2 Opaque Expressions...... 31 171 7.1.3 Opaque Attributes...... 31 172 7.1.4 Opaque From-Spec...... 31 173 7.1.5 Omission...... 31 174 7.2 Abstract Process Profile for Observable Behavior...... 31 175 7.3 Abstract Process Profile for Templates...... 32 1768 Conformance...... 33 1779 References...... 34 178A. Standard Faults...... 36 179B. Portability and Interoperability Considerations...... 37 180C. BPEL4People Schema...... 38 181D. Sample...... 44 182 BPEL Definition...... 45 183 WSDL Definitions...... 49 184E. Acknowledgements...... 51 185F. Non-Normative Text...... 53 186G. Revision History...... 54 187</p><p>13bpel4people-spec-WD-01 12 March 2008 14Copyright © OASIS® 2008. All Rights Reserved. Page 5 of 54 1881 Introduction 189This specification introduces an extension to BPEL in order to support a broad range of scenarios that 190involve people within business processes. 191The BPEL specification focuses on business processes the activities of which are assumed to be 192interactions with Web services, without any further prerequisite behavior. But the spectrum of activities 193that make up general purpose business processes is much broader. People often participate in the 194execution of business processes introducing new aspects such as interaction between the process and 195user interface, and taking into account human behavior. This specification introduces a set of elements 196which extend the standard BPEL elements and enable the modeling of human interactions, which may 197range from simple approvals to complex scenarios such as separation of duties, and interactions involving 198ad-hoc data. 199The specification introduces the people activity as a new type of basic activity which enables the 200specification of human interaction in processes in a more direct way. The implementation of a people 201activity could be an inline task or a standalone human task defined in the WS-HumanTask specification 202[WS-HumanTask]. The syntax and state diagram of the people activity and the coordination protocol that 203allows interacting with human tasks in a more integrated way is described. The specification also 204introduces XPath extension functions needed to access the process context. 205 The goal of this specification is to enable portability and interoperability: 206  Portability - The ability to take design-time artifacts created in one vendor's environment and use 207 them in another vendor's environment. 208  Interoperability - The capability for multiple components (process infrastructure, task 209 infrastructures and task list clients) to interact using well-defined messages and protocols. This 210 enables combining components from different vendors allowing seamless execution. 211Out of scope of this specification is how processes with human interactions are deployed or monitored. 212Usually people assignment is accomplished by performing queries on a people directory which has a 213certain organizational model. The mechanism of how an implementation evaluates people assignments, 214as well as the structure of the data in the people directory is also out of scope.</p><p>16bpel4people-spec-WD-01 12 March 2008 17Copyright © OASIS® 2008. All Rights Reserved. Page 6 of 54 2152 Language Design 216The BPEL4People extension is defined in a way that it is layered on top of BPEL so that its features can 217be composed with BPEL features whenever needed. All elements and attributes introduced in this 218extension are made available to both BPEL executable processes and abstract processes. 219This extension introduces a set of elements and attributes to cover different complex human interaction 220patterns, such as separation of duties, which are not defined as first-class elements. </p><p>2212.1 Dependencies on Other Specifications 222BPEL4People utilizes the following specifications: 223  WS-BPEL 2.0: BPEL4People extends the WS-BPEL 2.0 process model and uses existing WS- 224 BPEL 2.0 capabilities, such as those for data manipulation. 225  WS-HumanTask 1.0: BPEL4People uses the definition of human tasks and, notifications, and 226 extends generic human roles and people assignments introduced in WS-HumanTask 1.0. 227  WSDL 1.1: BPEL4People uses WSDL for service interface definitions. 228  XML Schema 1.0: BPEL4People utilizes XML Schema data model. 229  XPath 1.0: BPEL4People uses XPath as default query and expression language. </p><p>2302.2 Notational Conventions 231The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 232NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described 233in RFC 2119 [RFC 2119].</p><p>2342.3 Language Extensibility 235The BPEL4People specification extends the reach of the standard BPEL extensibility mechanism to 236BPEL4People elements. This allows: 237  Attributes from other namespaces to appear on any BPEL4People element 238  Elements from other namespaces to appear within BPEL4People elements 239Extension attributes and extension elements MUST NOT contradict the semantics of any attribute or 240element from the BPEL4People namespace. 241The standard BPEL element <extension> must be used to declare mandatory and optional extensions 242of BPEL4People. </p><p>2432.4 Overall Language Structure 244This section explains the structure of BPEL4People extension elements, including the new activity type 245people activity, inline human tasks and people assignments.</p><p>2462.4.1 Syntax 247Informal syntax of a BPEL process and scope containing logical people groups, inline human tasks, and 248people activity follows. 249<bpel:process ... 250 ... 251 xmlns:b4p="http://www.example.org/BPEL4People" 252 xmlns:htd="http://www.example.org/WS-HT"></p><p>19bpel4people-spec-WD-01 12 March 2008 20Copyright © OASIS® 2008. All Rights Reserved. Page 7 of 54 253 ... 254 <bpel:extensions> 255 <bpel:extension 256 namespace="http://www.example.org/BPEL4People" 257 mustUnderstand="yes"/> 258 <bpel:extension 259 namespace="http://www.example.org/WS-HT" 260 mustUnderstand="yes"/> 261 </bpel:extensions> 262 263 <bpel:import 264 importType="http://www.example.org/WS-HT" …/> 265 266 ... 267 <b4p:humanInteractions>? 268 269 <htd:logicalPeopleGroups/>? 270 <htd:logicalPeopleGroup name="NCName">+ 271 ... 272 </htd:logicalPeopleGroup> 273 </htd:logicalPeopleGroups> 274 275 <htd:tasks>? 276 <htd:task name="NCName">+ 277 ... 278 </htd:task> 279 </htd:tasks> 280 281 <htd:notifications>? 282 <htd:notification name="NCName">+ 283 ... 284 </htd:notification> 285 </htd:notifications> 286 287 </b4p:humanInteractions> 288 289 <b4p:peopleAssignments> 290 ... 291 </b4p:peopleAssignments> 292 293 ... 294 <bpel:extensionActivity> 295 <b4p:peopleActivity name="NCName" ...> 296 ... 297 </b4p:peopleActivity> 298 </bpel:extensionActivity> 299 ... 300</bpel:process> 301A BPEL4People process must use BPEL4People extension elements and elements from WS- 302HumanTask namespace. Therefore elements from namespaces BPEL4People and WS-HumanTask 303MUST be understood. 304The element <b4p:humanInteractions> is optional and contains declarations of elements from WS- 305HumanTask namespace, that is <htd:logicalPeopleGroups>, <htd:tasks> and 306<htd:notifications>.</p><p>22bpel4people-spec-WD-01 12 March 2008 23Copyright © OASIS® 2008. All Rights Reserved. Page 8 of 54 307The element <htd:logicalPeopleGroup> specifies a logical people group used in an inline human 308task or a people activity. The name attribute specifies the name of the logical people group. The name 309MUST be unique among the names of all logical people groups defined within the 310<b4p:humanInteractions> element. 311The <htd:task> element is used to provide the definition of an inline human task. The syntax and 312semantics of the element are provided in the WS-HumanTask specification. The name attribute specifies 313the name of the task. The name MUST be unique among the names of all tasks defined within the 314<htd:tasks> element. 315The <htd:notification> element is used to provide the definition of an inline notification. The syntax 316and semantics of the element are provided in the WS-HumanTask specification. The name attribute 317specifies the name of the notification. The name MUST be unique among the names of all notifications 318defined within the <htd:notifications> element. 319The element <b4p:peopleAssignments> is used to assign people to process-related generic human 320roles. The syntax and semantics are introduced in section 3.1 “Generic Human Roles”. 321New activity type <b4p:peopleActivity> is used to model human interactions within BPEL 322processes. The new activity is included in the BPEL activity <bpel:extensionActivity> which is 323used as wrapper. The syntax and semantics of the people activity are introduced in section 4 “People 324Activity”. 325<bpel:scope ...> 326 ... 327 <b4p:humanInteractions>? 328 ... 329 </b4p:humanInteractions> 330 ... 331 <bpel:extensionActivity> 332 <b4p:peopleActivity name="NCName" ...> 333 ... 334 </b4p:peopleActivity> 335 </bpel:extensionActivity> 336 ... 337</bpel:scope> 338BPEL scopes may also include elements from BPEL4People and WS-HumanTask namespaces except 339for the <b4p:peopleAssignments> element. 340All BPEL4People elements may use the element <b4p:documentation> to provide annotation for 341users. The content could be a plain text, HTML, and so on. The <b4p:documentation> element is 342optional and has the following syntax: 343<b4p:documentation xml:lang="xsd:language"> 344 ... 345</b4p:documentation></p><p>25bpel4people-spec-WD-01 12 March 2008 26Copyright © OASIS® 2008. All Rights Reserved. Page 9 of 54 3463 Concepts 347Many of the concepts in BPEL4People are inherited from the WS-HumanTask specification so familiarity 348with this specification is assumed.</p><p>3493.1 Generic Human Roles 350Process-related generic human roles define what a person or a group of people resulting from a people 351assignment can do with the process instance. The process-related human roles complement the set of 352generic human roles specified in [WS-HumanTask]. There are three process-related generic human roles: 353  Process initiator 354  Process stakeholders 355  Business administrators 356Process initiator is the person associated with triggering the process instance at its creation time. The 357initiator is typically determined by the infrastructure automatically. This can be overriden by specifying a 358people assignment for process initiator. Compliant implementations MUST ensure that at runtime at least 359one person is associated with this role. 360Process stakeholders are people who can influence the progress of a process instance, for example, by 361adding ad-hoc attachments, forwarding a task, or simply observing the progress of the process instance. 362The scope of a process stakeholder is broader than the actual BPEL4People specification outlines. The 363process stakeholder is associated with a process instance. If no process stakeholders are specified, the 364process initiator becomes the process stakeholder. Compliant implementations MUST ensure that at 365runtime at least one person is associated with this role 366Business administrators are people allowed to perform administrative actions on the business process, 367such as resolving missed deadlines. A business administrator, in contrast to a process stakeholder, has 368an interest in all process instances of a particular process type, and not just one. If no business 369administrators are specified, the process stakeholders become the business administrators. Compliant 370implementations MUST ensure that at runtime at least one person is associated with this role</p><p>3713.1.1 Syntax 372<b4p:peopleAssignments> 373 374 <htd:genericHumanRole>+ 375 <htd:from>...</htd:from> 376 </htd:genericHumanRole> 377 378<b4p:peopleAssignments> 379The genericHumanRole abstract element introduced in the WS-HumanTask specification is extended 380with the following process-related human roles. 381<b4p:peopleAssignments> 382 383 <b4p:processInitiator>? 384 <htd:from ...>...</htd:from> 385 </b4p:processInitiator> 386 387 <b4p:processStakeholders>? 388 <htd:from ...>...</htd:from> 389 </b4p:processStakeholders> 390 391 <b4p:businessAdministrators>? 28bpel4people-spec-WD-01 12 March 2008 29Copyright © OASIS® 2008. All Rights Reserved. Page 10 of 54 392 <htd:from ...>...</htd:from> 393 </b4p:businessAdministrators> 394 395</b4p:peopleAssignments> 396Only process-related human roles MAY be used within the <b4p:peopleAssignments> element. 397People are assigned to these roles as described in the following section. 398Assigning people to process-related generic human roles happens during the process initialization. As 399such it is part of the scope initialization (which occurs when a <bpel:process> or <bpel:scope> is 400entered) and has impact on the scope initialization outcome. That is, if an assignment fails the entire 401process is treated as faulted.</p><p>4023.2 Assigning People 403To determine who is responsible for acting on a process, a human task or a notification in a certain 404generic human role, people need to be assigned. People assignment can be achieved in different ways: 405  Via logical people groups (see 3.2.1 “Using Logical People Groups”) 406  Via literals (as introduced section 3.2.2 in [WS-HumanTask]) 407  Via expressions (see 3.2.2 “Computed Assignment”) 408When specifying people assignments then the data type htd:tOrganizationalEntity defined in 409[WS-HumanTask] is used. Using htd:tOrganizationalEntity allows to assign either a list of users 410or a list of unresolved groups of people (“work queues”).</p><p>4113.2.1 Using Logical People Groups 412This section focuses on describing aspects of logical people groups that are specific to business 413processes. Logical people groups define which person or set of people may interact with a human task or 414a notification of a people activity. Details about how logical people groups are used with human tasks and 415notifications are provided by the WS-HumanTask specification. 416Logical people groups can be specified as part of the business process definition. They can be defined 417either at the process level or on enclosed scopes. Definitions on inner scopes override definitions on 418outer scopes or the process respectively. 419Logical people group definitions can be referenced by multiple people activities. Each logical people 420group is bound to a people query during deployment. Using the same logical people group does not mean 421that the result of a people query is re-used, but that the same query is used to obtain a result. If the result 422of a previous people query needs to be re-used, then this result needs to be referenced explicitly from the 423process context. Please refer to section 5 “XPath Extension Functions” for a description of the syntax. 424Assignment of Logical People Groups 425BPEL <assign> activity (see [WS-BPEL 2.0] section 8.4 for more details) is used for manipulating 426values of logical people group. A mechanism to assign to a logical people group or to assign from a 427logical people group using BPEL copy assignments is provided. The semantics of the <copy> activity 428introduced in [WS-BPEL 2.0] (see sections 8.4.1, 8.4.2 and 8.4.3 for more details) applies. 429BPEL4People extends the from-spec and to-spec forms introduced in [WS-BPEL 2.0] as shown below: 430<bpel:from b4p:logicalPeopleGroup="NCName"> 431 <b4p:argument name="NCName" expressionLanguage="anyURI"?>* 432 value 433 </b4p:argument> 434</bpel:from> 435 436<to b4p:logicalPeopleGroup="NCName"/></p><p>31bpel4people-spec-WD-01 12 March 2008 32Copyright © OASIS® 2008. All Rights Reserved. Page 11 of 54 437In this form of from-spec and to-spec the b4p:logicalPeopleGroup attribute provides the name of a 438logical people group. The from-spec variant may include zero or more <b4p:argument> elements in 439order to pass values used in the people query. The expressionLanguage attribute specifies the 440language used in the expression. The attribute is optional. If not specified, the default language as 441inherited from the closest enclosing element that specifies the attribute is used. 442Using a logical people group in the from-spec causes the evaluation of the logical people group. Logical 443people groups return data of type htd:tOrganizationalEntity. This data can be manipulated and 444assigned to other process variables using standard BPEL to-spec variable variants. 445The new form of the from-spec can be used with the following to-spec variants: 446  To copy to a variable 447 448 <bpel:to variable="BPELVariableName" part="NCName"? > 449 <bpel:query queryLanguage="anyURI"? >? 450 queryContent 451 </bpel:query> 452 </bpel:to> 453 454  To copy to non-message variables and parts of message variables 455 456 <bpel:to expressionLanguage="anyURI"?>expression</bpel:to> 457 458  To copy to a property 459 460 <bpel:to variable="BPELVariableName" property="QName"/> 461 462  To copy to a logical people group 463 464 <bpel:to b4p:logicalPeopleGroup="NCName"/> 465 466Using a logical people group in the to-spec of a <bpel:copy> assignment enables a set of people to be 467explicitly assigned. Whenever the logical people group is used after the assignment this assigned set of 468people is returned. Assigning values to a logical people group overrides what has been defined during 469deployment. This is true irrespective of any parameters specified for the logical people group. 470The new form of the to-spec can be used with the following from-spec variants: 471  To copy from a variable 472 473 <bpel:from variable="BPELVariableName" part="NCName"? > 474 <bpel:query queryLanguage="anyURI"? >? 475 queryContent 476 </bpel:query> 477 </bpel:from> 478 479  To copy from a property 480 481 <bpel:from variable="BPELVariableName" property="QName"/> 482 483  To copy from non-message variables and parts of message variables 484 485 <bpel:from expressionLanguage="anyURI"?>expression</bpel:from> 486 487  To copy from a literal value 488</p><p>34bpel4people-spec-WD-01 12 March 2008 35Copyright © OASIS® 2008. All Rights Reserved. Page 12 of 54 489 <bpel:from> 490 <bpel:literal>literal value</bpel:literal> 491 </bpel:from> 492 493  To copy from a logical people group 494 495 <bpel:from b4p:logicalPeopleGroup="NCName"/> 496 497Below are several examples illustrating the usage of logical people groups in copy assignments. The first 498example shows assigning the results of the evaluation of a logical people group to a process variable. 499<bpel:assign name="getVoters"> 500 <bpel:copy> 501 <bpel:from b4p:logicalPeopleGroup="voters"> 502 <b4p:argument name="region"> 503 $electionRequest/region 504 </b4p:argument> 505 </bpel:from> 506 <bpel:to variable="voters" /> 507 </bpel:copy> 508</bpel:assign> 509 510The next example demonstrates assigning a set of people to a logical people group using literal values. 511<bpel:assign> 512 <bpel:copy> 513 <bpel:from> 514 <bpel:literal> 515 <myns:entity xsi:type="htd:tOrganizationalEntity"> 516 <htd:users> 517 <htd:user>Alan</htd:user> 518 <htd:user>Dieter</htd:user> 519 <htd:user>Frank</htd:user> 520 <htd:user>Gerhard</htd:user> 521 <htd:user>Ivana</htd:user> 522 <htd:user>Karsten</htd:user> 523 <htd:user>Matthias</htd:user> 524 <htd:user>Patrick</htd:user> 525 </htd:users> 526 </myns:entity> 527 </bpel:literal> 528 </bpel:from> 529 <bpel:to b4p:logicalPeopleGroup="bpel4peopleAuthors" /> 530 </bpel:copy> 531</bpel:assign> 532 533The third example shows assigning the results of one logical people group to another logical people 534group. 535<bpel:assign> 536 <bpel:copy> 537 <bpel:from b4p:logicalPeopleGroup="bpel4peopleAuthors" /> 538 <bpel:to b4p:logicalPeopleGroup="approvers" /> 539 </bpel:copy> 540</bpel:assign></p><p>37bpel4people-spec-WD-01 12 March 2008 38Copyright © OASIS® 2008. All Rights Reserved. Page 13 of 54 5413.2.2 Computed Assignment 542All computed assignment variants described in [WS-HumanTask] (see section 3.2 “Assigning People” for 543more details) are supported. In addition, the following variant is possible: 544<htd:genericHumanRole> 545 <bpel:from variable="NCName" part="NCName"? > 546 ... 547 </bpel:from> 548</htd:genericHumanRole> 549The from-spec variant <bpel:from variable> is used to assign people that have been specified using 550variable of the business process. The data type of the variable MUST be of type 551htd:tOrganizationalEntity. 552All other process context may be accessed using expressions of the following style: 553<bpel:from expressionLanguage="anyURI"?>expression</bpel:from> 554with XPath extension functions defined in section 5 “XPath Extension Functions”. The 555expressionLanguage attribute specifies the language used in the expression. The attribute is optional. 556If not specified, the default language as inherited from the closest enclosing element that specifies the 557attribute is used.</p><p>5583.3 Ad-hoc Attachments 559Processes can have ad-hoc attachments. It is possible to exchange ad-hoc attachments between people 560activities of a process, and even propagate ad-hoc attachments to and from the process level. 561When a people activity is activated, attachments from earlier tasks and from the process can be 562propagated to its implementing human task. On completion of the human task, its ad-hoc attachments 563can be propagated to the process level, to make them globally available. 564In all cases, if several attachments of the same name are propagated, they are combined into a list of 565attachments with that name; no attachment is lost or overwritten. 566All manipulations of ad-hoc attachments at the process level are instantaneous, and not subject to 567compensation or isolation. </p><p>40bpel4people-spec-WD-01 12 March 2008 41Copyright © OASIS® 2008. All Rights Reserved. Page 14 of 54 5684 People Activity 569People activity is a basic activity used to integrate human interactions within BPEL processes. The 570following figure illustrates different ways in which human interactions (including human tasks and 571notifications) could be integrated. 572</p><p>BPEL Process BPEL Process BPEL Process BPEL Process</p><p>People People People People Activity Activity Activity Activity</p><p>Inline Callable HT- Human Task WSDL Protocol Interface Interface Inline Standalone Human Task Human Task Standalone Task</p><p>1 2 3 4</p><p>574 Figure 1: Constellations 575 576Constellations 1 and 2 show models of interaction in which tasks are defined inline as part of a BPEL 577process. An inline task can be defined as part of a people activity (constellation 1). In this case, the use of 578the task is limited to the people activity encompassing it. Alternatively, a task can be defined as a top- 579level construct of the BPEL process or scope (constellation 2). In this case, the same task can be used 580within multiple people activities, which is significant from a reuse perspective. BPEL4People processes 581that use tasks in this way are portable among BPEL engines that implement BPEL4People. This also 582holds true for notifications. 583Constellation 3 shows the use of a standalone task within the same environment, without the specification 584of a callable Web services interface on the task. Thus the task invocation is implementation-specific. This 585constellation is similar to constellation 2, except that the definition of the task is done independently of any 586process. As a result, the task has no direct access to process context. This also holds true for 587notifications. 588Constellation 4 shows the use of a standalone task from a different environment. The major difference 589when compared to constellation 3 is that the task has a Web services callable interface, which is invoked 590using Web services protocols. In addition, the WS-HumanTask coordination protocol is used to 591communicate between processes and tasks (see section 6 “Coordinating Standalone Human Tasks” for 592more details on the WS-HumanTask coordination protocol). Using this mechanism, state changes are 593propagated between task and process activity, and the process can perform life cycle operations on the 594task, such as terminating it. BPEL4People processes that use tasks in this way are portable across 595different BPEL engines that implement BPEL4People. They are interoperable, assuming that both the 596process infrastructures and the task infrastructures implement the coordination protocol. In case of 597notifications a simplified protocol is used.</p><p>43bpel4people-spec-WD-01 12 March 2008 44Copyright © OASIS® 2008. All Rights Reserved. Page 15 of 54 5984.1 Overall Syntax 599Definition of people activity: 600<bpel:extensionActivity> 601 602 <b4p:peopleActivity name="NCName" inputVariable="NCName"? 603 outputVariable="NCName"? isSkipable="xsd:boolean"? 604 standard-attributes> 605 606 standard-elements 607 608 ( <htd:task>...</htd:task> 609 | <b4p:localTask>...</b4p:localTask> 610 | <b4p:remoteTask>...</b4p:remoteTask> 611 | <htd:notification>...</htd:notification> 612 | <b4p:localNotification>...</b4p:localNotification> 613 | <b4p:remoteNotification>...</b4p:remoteNotification> 614 ) 615 616 <b4p:scheduledActions>? ...</b4p:scheduledActions> 617 618 <bpel:toParts>? 619 <bpel:toPart part="NCName" fromVariable="BPELVariableName" />+ 620 </bpel:toParts> 621 622 <bpel:fromParts>? 623 <bpel:fromPart part="NCName" toVariable="BPELVariableName" />+ 624 </bpel:fromParts> 625 626 <b4p:attachmentPropagation fromProcess="all|none" 627 toProcess="all|newOnly|none" />? 628 629 </b4p:peopleActivity> 630 631</bpel:extensionActivity></p><p>6324.1.1 Properties 633The <b4p:peopleActivity> element is enclosed in the BPEL extensionActivity and has the 634following attributes and elements: 635  inputVariable: This attribute refers to a process variable which is used as input of the WSDL 636 operation of a task or notification. The process variable MUST have a WSDL message type. This 637 attribute is optional. If this attribute is not present the <bpel:toParts> element MUST be used. 638  outputVariable: This attribute refers to a process variable which is used as output of the 639 WSDL operation of a task. The process variable MUST have a WSDL message type. This 640 attribute is optional. If the people activity uses a human task and this attribute is not present the 641 <bpel:fromParts> element MUST be used. The outputVariable attribute MUST not be 642 used if the people activity uses a notification. 643  isSkipable: This attribute indicates whether the task associated with the activity can be 644 skipped at runtime or not. This is propagated to the task level. This attribute is optional. The 645 default for this attribute is “no”. 646  standard-attributes: The activity makes available all BPEL’s standard attributes. 647  standard-elements: The activity makes available all BPEL’s standard elements.</p><p>46bpel4people-spec-WD-01 12 March 2008 47Copyright © OASIS® 2008. All Rights Reserved. Page 16 of 54 648  htd:task: This element is used to define an inline task within the people activity (constellation 1 649 in the figure above). This element is optional. Its syntax and semantics are introduced in section 650 4.3 “People Activities Using Local Human Tasks”. 651  b4p:localTask: This element is used to refer to a standalone task with no callable Web service 652 interface (constellations 2 or 3). This element is optional. Its syntax and semantics are introduced 653 in section 4.3 “People Activities Using Local Human Tasks” 654  b4p:remoteTask: This element is used to refer to a standalone task offering callable Web 655 service interface (constellation 4). This element is optional. Its syntax and semantics are 656 introduced in section 4.5 “People Activities Using Remote Human Tasks”. 657  htd:notification: This element is used to define an inline notification within the people 658 activity (constellation 1 in the figure above). This element is optional. Its semantics is introduced 659 in section 4.4 “People Activities Using Local Notifications”. 660  b4p:localNotification: This element is used to refer to a standalone notification with no 661 callable Web service interface (constellations 2 or 3). This element is optional. Its semantics is 662 introduced in section 4.4 “People Activities Using Local Notifications”. 663  b4p:remoteNotification: This element is used to refer to a standalone notification offering 664 callable Web service interface (constellation 4). This element is optional. Its syntax and semantics 665 are introduced in section 4.6 “People Activities Using Remote Notifications”. 666  b4p:scheduledActions: This element specifies when the task must change the state. Its 667 syntax and semantics are introduced in section 4.7 “Elements for Scheduled Actions”. 668  bpel:toParts: This element is used to explicitly create multi-part WSDL message from multiple 669 BPEL variables. The element is optional. Its syntax and semantics are introduced in the WS- 670 BPEL 2.0 specification, section 10.3.1. The <bpel:toParts> element and the 671 inputVariable attribute are mutually exclusive. 672  bpel:fromParts: This element is used to assign values to multiple BPEL variables from an 673 incoming multi-part WSDL message. The element is optional. Its syntax and semantics are 674 introduced in the WS-BPEL 2.0 specification, section 10.3.1. The <bpel:fromParts> element 675 and the outputVariable attribute are mutually exclusive. This element MUST not be used if 676 the people activity uses a notification. 677  b4p:attachmentPropagation: This element is used to describe the propagation behavior of 678 ad-hoc attachments to and from the people activity. On activation of the people activity, either all 679 ad-hoc attachments from the process are propagated to the people activity, so they become 680 available to the corresponding task, or none. The fromProcess attribute is used to specify this. 681 On completion of a people activity, all ad-hoc attachments are propagated to its process, or only 682 newly created ones (but not those that were modified), or none. The toProcess attribute is used 683 to specify this. The element is optional. The default value for this element is that all attachments 684 are propagated from the process to the people activity and only new attachments are propagated 685 back to the process.</p><p>6864.2 Standard Overriding Elements 687Certain properties of human tasks and notifications may be specified on the process level as well as on 688local and remote task definitions and notification definitions allowing the process to override the original 689human task and notification definitions respectively. This increases the potential for reuse of tasks and 690notifications. Overriding takes place upon invocation of the Web service implemented by the human task 691(or notification) via the advanced interaction protocol implemented by both the process and the task (or 692notification). 693The following elements can be overridden: 694  people assignments</p><p>49bpel4people-spec-WD-01 12 March 2008 50Copyright © OASIS® 2008. All Rights Reserved. Page 17 of 54 695  priority 696People assignments can be specified on remote and local human tasks and notifications. As a 697consequence, the invoked task receives the results of people queries performed by the business process 698on a per generic human role base. The result will be of type tOrganizationalEntity. The result 699needs to be understandable in the context of the task, i.e., the user identifiers and groups need to a) 700follow the same scheme and b) there must be a 1:1 relationship between the users identifiers and users. 701If a generic human role is specified on both the business process and the task it calls then the people 702assignment as determined by the process overrides what is specified on the task. In other words, the 703generic human roles defined at the task level provide the default. The same applies to people 704assignments on remote and local notifications. 705The task’s originator is set to the process stakeholder. 706Priority of tasks and notifications can be specified on remote and local human tasks and notifications. If 707specified, it overrides the original priority of the human task (or notification). 708Standard-overriding-elements is used in the syntax below as a shortened form of the following list of 709elements: 710<htd:priority expressionLanguage="anyURI"? > 711 integer-expression 712</htd:priority> 713 714<htd:peopleAssignments>? 715 <htd:genericHumanRole> 716 <htd:from>...</htd:from> 717 </htd:genericHumanRole> 718</htd:peopleAssignments></p><p>7194.3 People Activities Using Local Human Tasks 720People activities may be implemented using local human tasks. A local human task is one of the 721following: 722  An inline task declared within the people activity. The task can be used only by that people 723 activity 724  An inline task declared within either the scope containing the people activity or the process 725 scope. In this case the task can be reused as implementation of multiple people activities 726 enclosed within the scope containing the task declaration 727  A standalone task identified using a QName. In this case the task can be reused across multiple 728 BPEL4People processes within the same environment. 729The syntax and semantics of people activity using local tasks is given below. </p><p>7304.3.1 Syntax 731 732<b4p:peopleActivity inputVariable="NCName"? outputVariable="NCName"? 733 isSkipable="xsd:boolean"? standard-attributes> 734 standard-elements 735 736 ( <htd:task>...</htd:task> 737 | <b4p:localTask reference="QName"> 738 standard-overriding-elements 739 </b4p:localTask> 740 ) 741 742</b4p:peopleActivity></p><p>52bpel4people-spec-WD-01 12 March 2008 53Copyright © OASIS® 2008. All Rights Reserved. Page 18 of 54 743 744Properties 745Element <htd:task> is used to define an inline task within the people activity. The syntax and 746semantics of the element are given in the WS-HumanTask specification. In addition, XPath expressions 747used in enclosed elements may refer to process variables. 748Element <b4p:localTask> is used to refer to a task enclosed in the BPEL4People process (a BPEL 749scope or the process scope) or a standalone task provided by the same environment. Attribute 750reference provides the QName of the task. The attribute is mandatory. The element may contain 751standard overriding elements explained in section 4.2 “Standard Overriding Elements”. </p><p>7524.3.2 Examples 753The following code shows a people activity declaring an inline task. 754<b4p:peopleActivity inputVariable="candidates" 755 outputVariable="vote" 756 isSkipable="yes"> 757 <htd:task> 758 <htd:peopleAssignments> 759 <htd:potentialOwners> 760 <htd:from>$voters/users/user[i]</htd:from> 761 </htd:potentialOwners> 762 </htd:peopleAssignments> 763 </htd:task> 764 <b4p:scheduledActions> 765 <b4p:expiration> 766 <b4p:documentation xml:lang="en-US"> 767 This people activity expires when not completed 768 within 2 days after having been activated. 769 </b4p:documentation> 770 <b4p:for>P2D</b4p:for> 771 </b4p:expiration> 772 </b4p:scheduledActions> 773</b4p:peopleActivity> 774 775The following code shows a people activity referring to an inline task defined in the BPEL4People 776process. 777<extensionActivity> 778 <b4p:peopleActivity name="firstApproval" 779 inputVariable="electionResult" outputVariable="decision"> 780 <b4p:localTask reference="tns:approveEmployeeOfTheMonth" /> 781 </b4p:peopleActivity> 782</extensionActivity></p><p>7834.4 People Activities Using Local Notifications 784People activities may be implemented using local notifications. A local notification is one of the following: 785  An inline notification declared within the people activity. The notification can be used only by that 786 people activity 787  An inline notification declared within either the scope containing the people activity or the process 788 scope. In this case the notification can be reused as implementation of multiple people activities 789 enclosed within the scope containing the notification declaration</p><p>55bpel4people-spec-WD-01 12 March 2008 56Copyright © OASIS® 2008. All Rights Reserved. Page 19 of 54 790  A standalone notification identified using a QName. In this case the notification can be reused 791 across multiple BPEL4People processes within the same environment. 792The syntax and semantics of people activity using local notifications is given below. </p><p>7934.4.1 Syntax 794<b4p:peopleActivity name="NCName"? inputVariable="NCName"? 795 standard-attributes> 796 standard-elements 797 798 ( <htd:notification>...</htd:notification> 799 | <b4p:localNotification reference="QName"> 800 standard-overriding-elements 801 </b4p:localNotification> 802 ) 803</b4p:peopleActivity> 804 805Properties 806Element <htd:notification> is used to define an inline notification within the people activity. The 807syntax and semantics of the element are given in the WS-HumanTask specification. In addition, XPath 808expressions used in enclosed elements may refer to process variables. </p><p>809Element <b4p:localNotification> is used to refer to a notification enclosed in the BPEL4People 810process (a BPEL scope or the process scope) or a standalone notification provided by the same 811environment. Attribute reference provides the QName of the notification. The attribute is mandatory. 812The element may contain standard overriding elements explained in section 4.2 “Standard Overriding 813Elements”.</p><p>8144.4.2 Examples 815The following code shows a people activity using a standalone notification. 816<bpel:extensionActivity> 817 <b4p:peopleActivity name="notifyEmployees" 818 inputVariable="electionResult"> 819 <htd:localNotification reference="task:employeeBroadcast"/> 820 <!-- notification is not defined as part of this document, 821 but within a separate one 822 --> 823 </b4p:peopleActivity> 824</bpel:extensionActivity></p><p>8254.5 People Activities Using Remote Human Tasks 826People activities may be implemented using remote human tasks. This variant has been referred to as 827constellation 4 in Figure 1. The remote human task is invoked using a mechanism similar to the BPEL 828invoke activity: Partner link and operation identify the human task based Web service to be called. In 829addition to that, the name of a response operation on the myRole of the partner link is specified, allowing 830the human task based Web service to provide its result back to the calling business process. 831Constellation 4 allows interoperability between BPEL4People compliant business processes of one 832vendor, and WS-HumanTask compliant human tasks of another vendor. The communication to, for 833example, propagate state changes between the business process and the remote human task happens in 834a standardized way, as described in section 6 “Coordinating Standalone Human Tasks”. 835The remote human task can also define a priority element and people assignments. The priority and 836people assignments specified here override the original priority of the human task. 58bpel4people-spec-WD-01 12 March 2008 59Copyright © OASIS® 2008. All Rights Reserved. Page 20 of 54 8374.5.1 Syntax 838<b4p:remoteTask 839 partnerLink="NCName" 840 operation="NCName" 841 responseOperation="NCName"?> 842 843 standard-overriding-elements 844 845</b4p:remoteTask> 846 847The attribute responseOperation (of type xsd:NCName) specifies the name of the operation to be 848used to receive the response message from the remote human task. The operation attribute refers to 849an operation of the myRole port type of the partner link associated with the <b4p:remoteTask>. The 850attribute MUST be set when the operation attribute refers to a WSDL one-way operation. The attribute 851MUST NOT be set when the operation attribute refers to a WSDL request-response operation.</p><p>8524.5.2 Example 853<bpel:extensionActivity> 854 <b4p:peopleActivity name="prepareInauguralSpeech" 855 inputVariable="electionResult" 856 outputVariable="speech" 857 isSkipable="no"> 858 <b4p:remoteTask partnerLink="author" 859 operation="prepareSpeech" 860 responseOperation="receiveSpeech"> 861 <htd:priority>0</htd:priority> <!-- assign highest prio --> 862 <htd:peopleAssignments> 863 <htd:potentialOwners> 864 <htd:from>$electionResult/winner</htd:from> 865 </htd:potentialOwners> 866 </htd:peopleAssignments> 867 </b4p:remoteTask> 868 </b4p:peopleActivity> 869</bpel:extensionActivity></p><p>8704.5.3 Passing Endpoint References for Callbacks 871A human task must send a response message back to its calling process. The endpoint to which the 872response is to be returned to typically becomes known as late as when the human task is instantiated. 873This is no problem in case the human task is invoked synchronously via a request-response operation: a 874corresponding session between the calling process and the human task will exist and the response 875message of the human task uses this session. 876But if the human task is called asynchronously via a one-way operation, such a session does not exist 877when the response message is sent. In this case, the calling process has to pass the endpoint reference 878of the port expecting the response message of the human task to the WS-HT implementation hosting the 879human task. Conceptually, this endpoint reference overrides any deployment settings for the human task. 880Besides the address of this port that endpoint reference must also specify additional metadata such that 881the port receiving the response is able to understand that the incoming message is in fact the response 882for an outstanding request (see [WS-HumanTask] section 8.2 for the definition of the metadata). Finally, 883such an endpoint reference must specify identifying data to allow the response message to be targeted to 884the correct instance of the calling process. 885The additional metadata may consist of the name of the port type of the port as well as binding 886information about how to reach the port (see [WS-Addr-Core]) in order to support the replying activity of </p><p>61bpel4people-spec-WD-01 12 March 2008 62Copyright © OASIS® 2008. All Rights Reserved. Page 21 of 54 887the human task to send its response to the port. In addition, the name of the receiving operation at the 888calling process side is required. This name MUST be provided as value of the responseOperation 889attribute of the <b4p:remoteTask> element (discussed in the previous section) and is passed together 890with an appropriate endpoint reference. 891The above metadata represents the most generic solution allowing the response to be returned in all 892situations supported by WSDL. A simpler solution is supported in the case of the interaction between the 893calling process and the human task being based on SOAP: In this case, the metadata of the endpoint 894reference simply contains the value of the action header to be set in the response message. 895In both cases (a request-response <b4p:remoteTask> as well as a <b4p:remoteTask> using two 896one-ways) the <b4p:remoteTask> activity is blocking. That is, the normal processing of a 897<b4p:remoteTask> activity does not end until a response message or fault message has been received 898from the human task. If the human task experiences a non-recoverable error, the WS-HumanTask 899compliant implementation will signal that to the BPEL4People compliant implementation and an 900b4p:nonRecoverableError fault is raised in the parent process. </p><p>9014.6 People Activities Using Remote Notifications 902As described in the previous section, people activities may also be implemented using remote 903notifications. This variant is also referred to as constellation 4. Using remote notifications is very similar to 904using remote human tasks. Except for the name of the element enclosed in the people activity the main 905difference is that the remote notification is one-way by nature, and thus does not allow the specification of 906a response operation. 907Remote notifications, like remote human tasks allow to specify properties that override the original 908properties of the notification Web service. The mechanism used is the same as described above. Like 909remote human tasks, remote notifications also allow overiding both people assignments and priority. </p><p>9104.6.1 Syntax 911<b4p:remoteNotification 912 partnerLink="NCName" 913 operation="NCName"> 914 915 standard-overriding-elements 916 917</b4p:remoteNotification></p><p>9184.6.2 Example 919<bpel:extensionActivity> 920 <b4p:peopleActivity name="notifyEmployees" 921 inputVariable="electionResult"> 922 <b4p:remoteNotification partnerLink="employeeNotification" 923 operation="receiveElectionResult"> 924 <htd:priority>42</htd:priority> <!-- assign moderate prio --> 925 <htd:peopleAssignments> 926 <htd:recipients> 927 <htd:from>$voters</htd:from> 928 </htd:recipients> 929 </htd:peopleAssignments> 930 </b4p:remoteNotification> 931 </b4p:peopleActivity> 932</bpel:extensionActivity></p><p>64bpel4people-spec-WD-01 12 March 2008 65Copyright © OASIS® 2008. All Rights Reserved. Page 22 of 54 9334.7 Elements for Scheduled Actions 934Scheduled actions allow specification determining when a task must change the state. The following 935scheduled actions are defined: 936DeferActivation: Specifies the activation time of the task. It is defined as either the period of time after 937which the task reaches state Ready (in case of explicit claim) or state Reserved (in case of implicit claim), 938or the point in time when the task reaches state Ready or state Reserved. The default value is zero, i.e. 939the task is immediately activated. If the activation time is defined as a point in time and the task is created 940after that point in time then the task will be activated immediately. 941Expiration: Specifies the expiration time of the task when the task becomes obsolete. It is defined as 942either the period of time after which the task expires or the point in time when the task expires. The time 943starts to be measured when the task enters state Created. If the task does not reach one of the final 944states (Completed, Failed, Error, Exited, Obsolete) by the expiration time it will change to state Exited and 945no additional user-defined action will be performed. The default value is infinity, i.e. the task never 946expires. If the expiration time is defined as a point in time and the task is created after that point in time 947then the task will immediately change to state Exited. Note that deferred activation does not impact 948expiration. Therefore the task may expire even before being activated. 949Element <b4p:scheduledActions> is used to include the definition of all scheduled actions within the 950task definition. If present, at least one scheduled activity must be defined. 951Syntax: 952<b4p:scheduledActions>? 953 954 <b4p:deferActivation>? 955 ( <b4p:for expressionLanguage="anyURI"?> 956 duration-expression 957 </b4p:for> 958 | <b4p:until expressionLanguage="anyURI"?> 959 deadline-expression 960 </b4p:until> 961 ) 962 </b4p:deferActivation> 963 964 <b4p:expiration>? 965 ( <b4p:for expressionLanguage="anyURI"?> 966 duration-expression 967 </b4p:for> 968 | <b4p:until expressionLanguage="anyURI"?> 969 deadline-expression 970 </b4p:until> 971 ) 972 </b4p:expiration> 973 974</b4p:scheduledActions> 975 976Properties 977The <b4p:scheduledActions> element has the following optional elements: 978  b4p:deferActivation: The element is used to specify activation time of the task. It includes 979 the following elements: 980 o b4p:for: The element is an expression which specifies the period of time (duration) 981 after which the task reaches state Ready (in case of explicit claim) or state Reserved (in 982 case of implicit claim). </p><p>67bpel4people-spec-WD-01 12 March 2008 68Copyright © OASIS® 2008. All Rights Reserved. Page 23 of 54 983 o b4p:until: The element is an expression which specifies the point in time when the 984 task reaches state Ready or state Reserved. 985 Elements <b4p:for> and <b4p:until> are mutually exclusive. There MUST be at least 986 one <b4p:for> or <b4p:until> element. 987  b4p:expiration: The element is used to specify the expiration time of the task when the task 988 becomes obsolete: 989 o b4p:for: The element is an expression which specifies the period of time (duration) 990 after which the task expires. 991 o b4p:until: The element is an expression which specifies the point in time when the 992 task expires. 993 Elements <b4p:for> and <b4p:until> are mutually exclusive. There MUST be at least 994 one <b4p:for> or <b4p:until> element. 995The language used in expressions is specified using the expressionLanguage attribute. This attribute 996is optional. If not specified, the default language as inherited from the closest enclosing element that 997specifies the attribute is used. 998If specified, the scheduledActions element must not be empty, that is one of the elements 999b4p:deferActivation and b4p:expiration MUST be defined. 1000Example: 1001<b4p:scheduledActions> 1002 1003 <b4p:deferActivation> 1004 <b4p:documentation xml:lang="en-US"> 1005 Activation of this task is deferred until the time specified 1006 in its input data. 1007 </b4p:documentation> 1008 <b4p:until>htd:getInput()/activateAt</b4p:until> 1009 </b4p:deferActivation> 1010 1011 <b4p:expiration> 1012 <b4p:documentation xml:lang="en-US"> 1013 This task expires when not completed within 14 days after 1014 having been activated. 1015 </b4p:documentation> 1016 <b4p:for>P14D</b4p:for> 1017 </b4p:expiration> 1018 1019</b4p:scheduledActions></p><p>10204.8 People Activity Behavior and State Transitions 1021Figure 2 shows the different states of the people activity and state transitions with associated triggers 1022(events and conditions) and actions to be performed when transitions take place. </p><p>70bpel4people-spec-WD-01 12 March 2008 71Copyright © OASIS® 2008. All Rights Reserved. Page 24 of 54 1023 Inactive</p><p>[Reached by navigation] Send request to the task, pass new WS-HT context</p><p>[Process exits] Send "WS-HT Exit" [WS-HT fault] Throw "nonRecoverableError" [Termination signal received] Send "WS-HT Exit" Running [Expiration signal received] Send "WS-HT Exit"</p><p>[Task returns application fault] [Task returns response] [WS-HT skipped] Throw application fault Continue navigation Continue navigation</p><p>Failed Completed Obsolete Terminated</p><p>Closed 1024 Figure 2: State diagram of the people activity 1025 1026When the process execution instantiates a people activity this activity triggers the creation of a task in 1027state Running. Upon receiving a response from the task, the people activity completes successfully and 1028its state changes into the final state Completed. 1029If the task returns a fault, the people activity completes unsuccessfully and moves to final state Failed and 1030the fault is thrown in the scope enclosing the people activity. If the task experiences a non-recoverable 1031error, the people activity completes unsuccessfully and the standard fault nonRecoverableError is 1032thrown in the enclosing scope. 1033The people activity goes to final state Obsolete if the task is skipped. 1034If the termination of the enclosed scope is triggered while the people activity is still running, the people 1035activity is terminated prematurely and the associated running task is exited. When a response is received 1036for a terminated people activity it MUST be ignored. 1037If the task expires, the people activity is terminated prematurely and the associated task exits. In this case 1038the standard fault b4p:taskExpired is thrown in the enclosing scope. When the process exits the 1039people activity will also be terminated and the associated task is exited. </p><p>10404.9 Task Instance Data 1041As defined by [WS-HumanTask], task instance data falls into the categories presentation data, context 1042data, and operational data. Human tasks defined as part of a BPEL4People compliant business process 1043have a superset of the instance data defined in [WS-HumanTask]. </p><p>10444.9.1 Presentation Data 1045The presentation data of tasks defined as part of a BPEL4People compliant business process is 1046equivalent to that of a standalone human task. </p><p>73bpel4people-spec-WD-01 12 March 2008 74Copyright © OASIS® 2008. All Rights Reserved. Page 25 of 54 10474.9.2 Context Data 1048Tasks defined as part of a BPEL4People business not only have access to the context data of the task, 1049but also of the surrounding business process. The process context includes 1050  Process state like variables and ad-hoc attachments 1051  Values for all generic human roles of the business process, i.e. the process stakeholders, the 1052 business administrators of the process, and the process initiator 1053  Values for all generic human roles of human tasks running within the same business process</p><p>10544.9.3 Operational Data 1055The operational data of tasks defined as part of a BPEL4People compliant business process is equivalent 1056to that of a standalone human task.</p><p>76bpel4people-spec-WD-01 12 March 2008 77Copyright © OASIS® 2008. All Rights Reserved. Page 26 of 54 10575 XPath Extension Functions 1058The following XPath extension functions are provided to be used within the definition of a BPEL4People 1059business process to access process context. Because XPath 1.0 functions do not support returning faults, 1060an empty node set is returned in the event of an error. 1061 Operation Name Description Parameters getProcessStakeholders Returns the Out stakeholders of the  organizational entity process. (htd:organizationalEntity) getBusinessAdministrators Returns the business Out administrators of the  organizational entity process. (htd:organizationalEntity) getProcessInitiator Returns the initiator of Out the process.  the process initiator (htd:tUser) getLogicalPeopleGroup Returns the value of a In logical people group.  name of the logical people group (xsd:string) Out  the value of the logical people group (htd:organizationalEntity) getActualOwner Returns the actual In owner of the task  people activity name associated with the people activity. (xsd:string) Out  the actual owner (htd:tUser) getTaskInitiator Returns the initiator of In the task. Evaluates to  people activity name an empty htd:user in case there is no (xsd:string) initiator. Out  the task initiator (user id as htd:user) getTaskStakeholders Returns the In stakeholders of the  people activity name task. (xsd:string) Evaluates to an empty htd:organizationalEntit Out y in case of an error.  task stakeholders (htd:organizationalEntity) getPotentialOwners Returns the potential In</p><p>79bpel4people-spec-WD-01 12 March 2008 80Copyright © OASIS® 2008. All Rights Reserved. Page 27 of 54 owners of the task associated with the  people activity name people activity. (xsd:string) Out  potential owners (htd:organizationalEntity) getAdministrators Returns the In administrators of the  people activity name task associated with the people activity. (xsd:string) Out  business administrators (htd:organizationalEntity) getTaskPriority Returns the priority of In the task associated  people activity name with the people activity. (xsd:string) Out  priority (xsd:nonNegativeInteger)</p><p>1062 1063XPath functions accessing data of a human task only guarantee to return data once the corresponding 1064task has reached a final state. </p><p>82bpel4people-spec-WD-01 12 March 2008 83Copyright © OASIS® 2008. All Rights Reserved. Page 28 of 54 10656 Coordinating Standalone Human Tasks 1066Using the WS-HT coordination protocol introduced by [WS-HumanTask] (see section 7 “Interoperable 1067Protocol for Advanced Interaction with Human Tasks” for more details) to control the autonomy and life 1068cycle of human tasks, a BPEL process with a people activity can act as the parent application for remote 1069human tasks. 1070</p><p>(1)requestMessage (HT coordination context, Task overriding task attributes, Coordinator attachments, callback EPR)</p><p>Risk Assessm ent × (2) Coor Register (EPR of task Credit Requestor: Joe Rich Process protocol handler) Credit Amount: 1M€ Engine Risk Rating: _ _ _ _ (3) Coor RegisterResponse (EPR of process engine protocol handler) ... S ubmit ... S kip <peopleActivity name="AssessRisk"> <remoteTask...> (4a) responseMessage <priority...> (attachments) ... </remoteTask> (4b) Skipped </peopleActivity> ...</p><p>Figure 3: Message exchange between a people activity and a human task</p><p>1072Figure 3 shows some message exchanges between a BPEL process containing a people activity to 1073perform a task (e.g. risk assessment) implemented by a remote human. The behavior of the people 1074activity is the same as for a people activity with an inline human task. That behavior is achieved by 1075coordinating the remote human task via the WS-HT coordination protocol. </p><p>10766.1 Protocol Messages from the People Activity’s Perspective 1077The people activity MUST support the following behavior and the protocol messages 1078exchanged with a standalone task. A summary is provided in the table below. 10791. When the process execution reaches a people activity and determines that this 1080 activity can be executed, a WS-HT coordination context associated with the activity is 1081 created. This context is sent together with the request message to the appropriate 1082 service associated with the task. In addition, overriding attributes from the people 1083 activity, namely priority, people assignments, the skipable indicator and the task’s 1084 expiration time, are sent. Also ad-hoc attachments may be propagated from the 1085 process. All this information is sent as part of the header fields of the requesting </p><p>85bpel4people-spec-WD-01 12 March 2008 86Copyright © OASIS® 2008. All Rights Reserved. Page 29 of 54 1086 message. These header fields as well as a corresponding mapping to SOAP headers are 1087 discussed in [WS-HumanTask]. 10882. When a response message is received from the task that indicates the successful 1089 completion of the the task, the people activity completes. This response may include all 1090 new ad-hoc attachments from the human task. 10913. When a response message is received from the task that indicates a fault of the task, 1092 the people activity faults. The fault is thrown in the scope of the people activity. 10934. When protocol message fault is received, the fault nonRecoverableError is 1094 thrown in the scope enclosing the people activity. 10955. When protocol message skipped is received, the people acitivity moves to state 1096 Obsolete. 10976. If the task does not reach one of the final states by the expiration deadline, the 1098 people activity will be terminated. Protocol message exit is sent to the task. 10997. When the people activity is terminated, protocol message exit is sent to the task. 11008. When the process encounters an <exit> activity, protocol message exit is sent to 1101 the task. 1102 1103The following table summarizes this behavior, the protocol messages sent, and their 1104direction, i.e., whether a message is sent from the people activity to the task (“out” in the 1105column titled Direction) or vice versa (“in”). 1106 1107 Message Direction People activity behavior application request with WS-HT coordination context (and Out People activity reached callback information) task response In People activity completes task fault response In People activity faults People activity faults with Fault In b4p:nonRecoverableError Skipped In People activity is set to obsolete Exit Out Expired time-out Exit Out People activity terminated <exit> encountered in enclosing Exit Out process</p><p>88bpel4people-spec-WD-01 12 March 2008 89Copyright © OASIS® 2008. All Rights Reserved. Page 30 of 54 11087 BPEL Abstract Processes 1109BPEL abstract processes are indicated by the namespace "http://docs.oasis- 1110open.org/wsbpel/2.0/process/abstract". All constructs defined in BPEL4People extension 1111namespaces MAY appear in abstract processes. </p><p>11127.1 Hiding Syntactic Elements 1113Opaque tokens defined in BPEL (activities, expressions, attributes and from-specs) can also be used in 1114BPEL4People extension constructs. The syntactic validity constraints of BPEL apply in the same way to 1115an Executable Completion of an abstract process containing BPEL4People extensions. </p><p>11167.1.1 Opaque Activities 1117BPEL4people does not change the way opaque activities can be replaced by an executable activity in an 1118executable completion of an abstract process, that is, a <bpel:opaqueActivity> may also serve as a 1119placeholder for a <bpel:extensionActivity> containing a <b4p:peopleActivity>. </p><p>11207.1.2 Opaque Expressions 1121Any expression introduced by BPEL4People can be made opaque. In particular, the following expressions 1122may have the opaque="yes" attribute: 1123<htd:argument name="NCName" expressionLanguage="anyURI"? opaque="yes" /> 1124<htd:priority expressionLanguage="anyURI" opaque="yes" /> 1125<b4p:for expressionLanguage="anyURI"? opaque="yes" /> 1126<b4p:until expressionLanguage="anyURI"? opaque="yes" /></p><p>11277.1.3 Opaque Attributes 1128Any attribute introduced by BPEL4People can have an opaque value "##opaque" in an abstract 1129process.</p><p>11307.1.4 Opaque From-Spec 1131In BPEL, any from-spec in an executable process can be replaced by an opaque from-spec 1132<opaqueFrom/> in an abstract process. This already includes any BPEL from-spec extended with the 1133BPEL4People b4p:logicalPeopleGroup="NCName" attribute. In addition, the extension from-spec 1134<htd:from> can also be replaced by an opaque from-spec in an abstract process. </p><p>11357.1.5 Omission 1136In BPEL, omittable tokens are all attributes, activities, expressions and from-specs which are both (1) 1137syntactically required by the Executable BPEL XML Schema, and (2) have no default value. This rule also 1138applies to BPEL4People extensions in abstract processes. For example, <b4p:localTask 1139reference="##opaque"> is equivalent to <b4p:localTask>. </p><p>11407.2 Abstract Process Profile for Observable Behavior 1141The Abstract Process Profile for Observable Behavior, indicated by the process attribute 1142abstractProcessProfile="http://docs.oasis- 1143open.org/wsbpel/2.0/process/abstract/ap11/2006/08", provides a means to create precise 1144and predictable descriptions of observable behavior of the service(s) provided by an executable process. </p><p>91bpel4people-spec-WD-01 12 March 2008 92Copyright © OASIS® 2008. All Rights Reserved. Page 31 of 54 1145The main application of this profile is the definition of business process contracts; that is, the behavior 1146followed by one business partner in the context of Web services exchanges. A valid completion has to 1147follow the same interactions as the abstract process, with the partners that are specified by the abstract 1148process. The executable process may, however, perform additional interaction steps relating to other 1149partners. Likewise, the executable process may perform additional human interactions. Beyond the 1150restrictions defined in WS-BPEL 2.0, the use of opacity is not restricted in any way for elements and 1151attributes introduced by BPEL4People.</p><p>11527.3 Abstract Process Profile for Templates 1153The Abstract Process Profile for Templates, indicated by the process attribute 1154abstractProcessProfile="http://docs.oasis- 1155open.org/wsbpel/2.0/process/abstract/simple-template/2006/08", allows the definition 1156of Abstract Processes which hide almost any arbitrary execution details and have explicit opaque 1157extension points for adding behavior. 1158This profile does not allow the use of omission shortcuts but the use of opacity is not restricted in any 1159way. For abstract processes belonging to this profile, this rule is extended to the elements and attributes 1160introduced by BPEL4People.</p><p>94bpel4people-spec-WD-01 12 March 2008 95Copyright © OASIS® 2008. All Rights Reserved. Page 32 of 54 11618 Conformance 1162(tbd.)</p><p>97bpel4people-spec-WD-01 12 March 2008 98Copyright © OASIS® 2008. All Rights Reserved. Page 33 of 54 11639 References 1164[BPEL4WS 1.1] 1165 Business Process Execution Language for Web Services Version 1.1, BEA Systems, IBM, 1166 Microsoft, SAP AG and Siebel Systems, May 2003, available via http://www- 1167 128.ibm.com/developerworks/library/specification/ws-bpel/, http://ifr.sap.com/bpel4ws/ 1168[RFC 2119] 1169 Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, available via 1170 http://www.ietf.org/rfc/rfc2119.txt 1171[RFC 3066] 1172 Tags for the Identification of Languages, H. Alvestrand, IETF, January 2001, available via 1173 http://www.isi.edu/in-notes/rfc3066.txt 1174[WS-Addr-Core] 1175 Web Services Addressing 1.0 - Core, W3C Recommendation, May 2006, available via 1176 http://www.w3.org/TR/ws-addr-core 1177[WS-Addr-SOAP] 1178 Web Services Addressing 1.0 – SOAP Binding, W3C Recommendation, May 2006, available via 1179 http://www.w3.org/TR/ws-addr-soap 1180[WS-Addr-WSDL] 1181 Web Services Addressing 1.0 – WSDL Binding, W3C Working Draft, February 2006, available via 1182 http://www.w3.org/TR/ws-addr-wsdl 1183[WS-BPEL 2.0] 1184 Web Service Business Process Execution Language Version 2.0, Working Draft, January 2006, 1185 OASIS Technical Committee, available via http://www.oasis-open.org/committees/wsbpel 1186[WSDL 1.1] 1187 Web Services Description Language (WSDL) Version 1.1, W3C Note, available via 1188 http://www.w3.org/TR/2001/NOTE-wsdl-20010315 1189[WS-HumanTask] 1190 Published simultaneously with this specification. 1191[XML Infoset] 1192 XML Information Set, W3C Recommendation, available via http://www.w3.org/TR/2001/REC-xml- 1193 infoset-20011024/ 1194[XML Namespaces] 1195 Namespaces in XML 1.0 (Second Edition), W3C Recommendation, available via 1196 http://www.w3.org/TR/REC-xml-names/ 1197[XML Schema Part 1] 1198 XML Schema Part 1: Structures, W3C Recommendation, October 2004, available via 1199 http://www.w3.org/TR/xmlschema-1/ 1200[XML Schema Part 2] 1201 XML Schema Part 2: Datatypes, W3C Recommendation, October 2004, available via 1202 http://www.w3.org/TR/xmlschema-2/ 1203[XMLSpec] 1204 XML Specification, W3C Recommendation, February 1998, available via 1205 http://www.w3.org/TR/1998/REC-xml-19980210 100bpel4people-spec-WD-01 12 March 2008 101Copyright © OASIS® 2008. All Rights Reserved. Page 34 of 54 1206[XPATH 1.0] 1207 XML Path Language (XPath) Version 1.0, W3C Recommendation, November 1999, available via 1208 http://www.w3.org/TR/1999/REC-xpath-19991116 1209</p><p>103bpel4people-spec-WD-01 12 March 2008 104Copyright © OASIS® 2008. All Rights Reserved. Page 35 of 54 1210A. Standard Faults</p><p>1211The following list specifies the standard faults defined within the BPEL4People specification. All standard 1212fault names are qualified with the standard BPEL4People namespace. </p><p>Fault name Description</p><p> nonRecoverableError Thrown if the task experiences a non-recoverable error.</p><p> taskExpired Thrown if the task expired. </p><p>106bpel4people-spec-WD-01 12 March 2008 107Copyright © OASIS® 2008. All Rights Reserved. Page 36 of 54 1213B. Portability and Interoperability Considerations</p><p>1214The following section illustrates the portability and interoperability aspects of the various usage 1215constellations of BPEL4People with WS-HumanTask as described in Figure 1: 1216 1217  Portability - The ability to take design-time artifacts created in one vendor's environment and use 1218 them in another vendor's environment. Constellations one and two provide portability of 1219 BPEL4People processes with embedded human interactions in. Constellations three and four 1220 provide portability of BPEL4People processes with referenced human interactions.</p><p>1222  Interoperability - The capability for multiple components (process engine, task engine and task list 1223 client) to interact using well-defined messages and protocols. This enables to combine 1224 components from different vendors allowing seamless execution. 1225 Constellation four achieves interoperability between process and tasks from different vendor 1226 implementations. 1227 1228Constellation 1 1229Task definitions are defined inline of the people activities. Usage in this manner is typically for self- 1230contained people activities, whose tasks definitions are not intended to be reused elsewhere in the 1231process or across multiple processes. This format will also provide scoping of the task definition since it 1232will not be visible or accessible outside the people activity in which it is contained. Portability for this 1233constellation requires support of both WS-HumanTask and BPEL4People artifacts using the inline task 1234definition format. Since the process and task interactions are combined in one component, interoperability 1235requirements are limited to those between the task list client and the infrastructure. 1236 1237Constellation 2 1238Similar to constellation 1, but tasks are defined at the process level. This allows task definitions to be 1239referenced from within people activities enabling task reuse. Portability for this constellation requires 1240support of both WS-HumanTask and BPEL4People artifacts using the process level scoped task 1241definition format. Since the process and task interactions are combined in one component, interoperability 1242requirements are limited to those between the task list client and the infrastructure. 1243 1244Constellation 3 1245In this constellation, the task and people activity definitions are defined as separate artifacts and execute 1246in different infrastructure components but provided by the same vendor. Portability for this constellation 1247requires support of both WS-HumanTask and BPEL4People as separate artifacts. Since the process and 1248task components are implemented by the same vendor, interoperability requirements are limited to those 1249between the task list client and the infrastructure. 1250 1251Constellation 4 1252Identical to constellation 3 in terms of the task and people activity definitions, but in this case the process 1253and task infrastructure are provided by different vendors. Portability for this constellation requires support 1254of both WS-HumanTask and BPEL4People as separate artifacts. Interoperability between task and 1255process infrastructures from different vendors is achieved using the WS-HumanTask coordination 1256protocol.</p><p>109bpel4people-spec-WD-01 12 March 2008 110Copyright © OASIS® 2008. All Rights Reserved. Page 37 of 54 1257C. BPEL4People Schema</p><p>1258<?xml version="1.0" encoding="UTF-8"?> 1259<xsd:schema targetNamespace=" http://www.example.org/BPEL4People" 1260 xmlns=" http://www.example.org/BPEL4People" 1261 xmlns:htd="http://www.example.org/WS-HT" 1262 xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable" 1263 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1264 elementFormDefault="qualified" blockDefault="#all"> 1265 1266 <!-- other namespaces --> 1267 <xsd:import namespace="http://www.w3.org/XML/1998/namespace" 1268 schemaLocation="http://www.w3.org/2001/xml.xsd" /> 1269 <xsd:import namespace="http://www.example.org/WS-HT" 1270 schemaLocation="ws-humantask.xsd" /> 1271 <xsd:import 1272 namespace="http://docs.oasis-open.org/wsbpel/2.0/process/executable" 1273 schemaLocation="ws-bpel_executable.xsd" /> 1274 1275 <!-- base types for extensible elements --> 1276 <xsd:complexType name="tExtensibleElements"> 1277 <xsd:sequence> 1278 <xsd:element name="documentation" type="tDocumentation" 1279 minOccurs="0" maxOccurs="unbounded" /> 1280 <xsd:any namespace="##other" processContents="lax" minOccurs="0" 1281 maxOccurs="unbounded" /> 1282 </xsd:sequence> 1283 <xsd:anyAttribute namespace="##other" processContents="lax" /> 1284 </xsd:complexType> 1285 <xsd:complexType name="tExtensibleMixedNamespaceElements"> 1286 <xsd:sequence> 1287 <xsd:element name="documentation" type="tDocumentation" 1288 minOccurs="0" maxOccurs="unbounded" /> 1289 <xsd:element name="extensions" type="tExtensions" minOccurs="0" /> 1290 </xsd:sequence> 1291 <xsd:anyAttribute namespace="##other" processContents="lax" /> 1292 </xsd:complexType> 1293 <xsd:complexType name="tDocumentation" mixed="true"> 1294 <xsd:sequence> 1295 <xsd:any namespace="##other" processContents="lax" minOccurs="0" 1296 maxOccurs="unbounded" /> 1297 </xsd:sequence> 1298 <xsd:attribute ref="xml:lang" /> 1299 </xsd:complexType> 1300 <xsd:complexType name="tExtensions"> 1301 <xsd:sequence> 1302 <xsd:any namespace="##other" processContents="lax" minOccurs="0" 1303 maxOccurs="unbounded" /> 1304 </xsd:sequence> 1305 </xsd:complexType> 1306 1307 <!-- element "humanInteractions" to be used within "bpel:process" or 1308"bpel:scope" --> 1309 <xsd:element name="humanInteractions" type="tHumanInteractions" /></p><p>112bpel4people-spec-WD-01 12 March 2008 113Copyright © OASIS® 2008. All Rights Reserved. Page 38 of 54 1310 <xsd:complexType name="tHumanInteractions"> 1311 <xsd:complexContent> 1312 <xsd:extension base="tExtensibleMixedNamespaceElements"> 1313 <xsd:sequence> 1314 <xsd:element ref="htd:logicalPeopleGroups" minOccurs="0" /> 1315 <xsd:element ref="htd:tasks" minOccurs="0" /> 1316 <xsd:element ref="htd:notifications" minOccurs="0" /> 1317 </xsd:sequence> 1318 </xsd:extension> 1319 </xsd:complexContent> 1320 </xsd:complexType> 1321 1322 <!-- element "peopleAssignments" to be used within "bpel:process" or 1323"bpel:scope" --> 1324 <xsd:element name="peopleAssignments" type="tPeopleAssignments" /> 1325 <xsd:complexType name="tPeopleAssignments"> 1326 <xsd:complexContent> 1327 <xsd:extension base="tExtensibleElements"> 1328 <xsd:sequence> 1329 <xsd:group ref="genericHumanRole" minOccurs="1" 1330 maxOccurs="unbounded" /> 1331 </xsd:sequence> 1332 </xsd:extension> 1333 </xsd:complexContent> 1334 </xsd:complexType> 1335 1336 <!-- element "genericHumanRole" within BPEL4People --> 1337 <xsd:group name="genericHumanRole"> 1338 <xsd:choice> 1339 <xsd:element ref="processStakeholders" /> 1340 <xsd:element ref="businessAdministrators" /> 1341 <xsd:element ref="processInitiator" /> 1342 </xsd:choice> 1343 </xsd:group> 1344 <xsd:element name="processStakeholders" 1345 type="htd:tGenericHumanRole" /> 1346 <xsd:element name="businessAdministrators" 1347 type="htd:tGenericHumanRole" /> 1348 <xsd:element name="processInitiator" type="htd:tGenericHumanRole" /> 1349 1350 <!-- element "argument" to be used within "bpel:from" --> 1351 <xsd:element name="argument" type="tArgument" /> 1352 <xsd:complexType name="tArgument"> 1353 <xsd:complexContent> 1354 <xsd:extension base="bpel:tExpression"> 1355 <xsd:attribute name="name" type="xsd:NCName" /> 1356 </xsd:extension> 1357 </xsd:complexContent> 1358 </xsd:complexType> 1359 1360 <!-- attribute "logicalPeopleGroup" to be used within "bpel:from" and 1361"bpel:to" --> 1362 <xsd:attribute name="logicalPeopleGroup" type="xsd:NCName" /> 1363 1364 <!-- element "peopleActivity" to be used within "bpel:extensionActivity" --> 1365 <xsd:element name="peopleActivity" type="tPeopleActivity" /> 1366 <xsd:complexType name="tPeopleActivity"></p><p>115bpel4people-spec-WD-01 12 March 2008 116Copyright © OASIS® 2008. All Rights Reserved. Page 39 of 54 1367 <xsd:complexContent> 1368 <xsd:extension base="tExtensibleMixedNamespaceElements"> 1369 <xsd:sequence> 1370 <xsd:element ref="bpel:targets" minOccurs="0" /> 1371 <xsd:element ref="bpel:sources" minOccurs="0" /> 1372 <xsd:choice> 1373 <xsd:element ref="htd:task" /> 1374 <xsd:element ref="localTask" /> 1375 <xsd:element ref="remoteTask" /> 1376 <xsd:element ref="htd:notification" /> 1377 <xsd:element ref="localNotification" /> 1378 <xsd:element ref="remoteNotification" /> 1379 </xsd:choice> 1380 <xsd:element ref="scheduledActions" minOccurs="0" /> 1381 <xsd:element ref="toParts" minOccurs="0" /> 1382 <xsd:element ref="fromParts" minOccurs="0" /> 1383 <xsd:element ref="attachmentPropagation" minOccurs="0" /> 1384 <xsd:any namespace="##other" processContents="lax" 1385 minOccurs="0" maxOccurs="unbounded" /> 1386 </xsd:sequence> 1387 <xsd:attribute name="name" type="xsd:NCName" /> 1388 <xsd:attribute name="suppressJoinFailure" type="tBoolean" 1389 use="optional" /> 1390 <xsd:attribute name="inputVariable" type="xsd:QName" /> 1391 <xsd:attribute name="outputVariable" type="xsd:QName" /> 1392 <xsd:attribute name="isSkipable" type="tBoolean" 1393 use="optional" default="no" /> 1394 </xsd:extension> 1395 </xsd:complexContent> 1396 </xsd:complexType> 1397 <xsd:complexType name="tOverridableTaskElements"> 1398 <xsd:complexContent> 1399 <xsd:extension base="tExtensibleMixedNamespaceElements"> 1400 <xsd:sequence> 1401 <xsd:element ref="htd:priority" minOccurs="0" /> 1402 <xsd:element ref="htd:peopleAssignments" minOccurs="0" /> 1403 </xsd:sequence> 1404 </xsd:extension> 1405 </xsd:complexContent> 1406 </xsd:complexType> 1407 <xsd:element name="localTask" type="tLocalTask" /> 1408 <xsd:complexType name="tLocalTask"> 1409 <xsd:complexContent> 1410 <xsd:extension base="tOverridableTaskElements"> 1411 <xsd:attribute name="reference" type="xsd:QName" 1412 use="required" /> 1413 </xsd:extension> 1414 </xsd:complexContent> 1415 </xsd:complexType> 1416 <xsd:element name="remoteTask" type="tRemoteTask" /> 1417 <xsd:complexType name="tRemoteTask"> 1418 <xsd:complexContent> 1419 <xsd:extension base="tOverridableTaskElements"> 1420 <xsd:attribute name="partnerLink" type="xsd:NCName" 1421 use="required" /> 1422 <xsd:attribute name="operation" type="xsd:NCName" 1423 use="required" /></p><p>118bpel4people-spec-WD-01 12 March 2008 119Copyright © OASIS® 2008. All Rights Reserved. Page 40 of 54 1424 <xsd:attribute name="responseOperation" type="xsd:NCName" /> 1425 </xsd:extension> 1426 </xsd:complexContent> 1427 </xsd:complexType> 1428 <xsd:complexType name="tOverridableNotificationElements"> 1429 <xsd:complexContent> 1430 <xsd:extension base="tExtensibleMixedNamespaceElements"> 1431 <xsd:sequence> 1432 <xsd:element ref="htd:priority" minOccurs="0" /> 1433 <xsd:element ref="htd:peopleAssignments" minOccurs="0" /> 1434 </xsd:sequence> 1435 </xsd:extension> 1436 </xsd:complexContent> 1437 </xsd:complexType> 1438 <xsd:element name="localNotification" type="tLocalNotification" /> 1439 <xsd:complexType name="tLocalNotification"> 1440 <xsd:complexContent> 1441 <xsd:extension base="tOverridableNotificationElements"> 1442 <xsd:attribute name="reference" type="xsd:QName" 1443 use="required" /> 1444 </xsd:extension> 1445 </xsd:complexContent> 1446 </xsd:complexType> 1447 <xsd:element name="remoteNotification" type="tRemoteNotification" /> 1448 <xsd:complexType name="tRemoteNotification"> 1449 <xsd:complexContent> 1450 <xsd:extension base="tOverridableNotificationElements"> 1451 <xsd:attribute name="partnerLink" type="xsd:NCName" 1452 use="required" /> 1453 <xsd:attribute name="operation" type="xsd:NCName" 1454 use="required" /> 1455 </xsd:extension> 1456 </xsd:complexContent> 1457 </xsd:complexType> 1458 <xsd:element name="scheduledActions" type="tScheduledActions" /> 1459 <xsd:complexType name="tScheduledActions"> 1460 <xsd:complexContent> 1461 <xsd:extension base="tExtensibleElements"> 1462 <xsd:sequence> 1463 <xsd:element name="deferActivation" 1464 type="tScheduledActionsDetails" minOccurs="0" /> 1465 <xsd:element name="expiration" 1466 type="tScheduledActionsDetails" minOccurs="0" /> 1467 </xsd:sequence> 1468 </xsd:extension> 1469 </xsd:complexContent> 1470 </xsd:complexType> 1471 <xsd:complexType name="tScheduledActionsDetails"> 1472 <xsd:complexContent> 1473 <xsd:extension base="tExtensibleElements"> 1474 <xsd:sequence> 1475 <xsd:choice> 1476 <xsd:element name="for" type="bpel:tDuration-expr" /> 1477 <xsd:element name="until" type="bpel:tDeadline-expr" /> 1478 </xsd:choice> 1479 </xsd:sequence> 1480 </xsd:extension></p><p>121bpel4people-spec-WD-01 12 March 2008 122Copyright © OASIS® 2008. All Rights Reserved. Page 41 of 54 1481 </xsd:complexContent> 1482 </xsd:complexType> 1483 <xsd:element name="fromParts" type="tFromParts" /> 1484 <xsd:complexType name="tFromParts"> 1485 <xsd:complexContent> 1486 <xsd:extension base="tExtensibleElements"> 1487 <xsd:sequence> 1488 <xsd:element ref="fromPart" maxOccurs="unbounded" /> 1489 </xsd:sequence> 1490 </xsd:extension> 1491 </xsd:complexContent> 1492 </xsd:complexType> 1493 <xsd:element name="fromPart" type="tFromPart" /> 1494 <xsd:complexType name="tFromPart"> 1495 <xsd:complexContent> 1496 <xsd:extension base="tExtensibleElements"> 1497 <xsd:attribute name="part" type="xsd:NCName" use="required" /> 1498 <xsd:attribute name="toVariable" type="bpel:BPELVariableName" 1499 use="required" /> 1500 </xsd:extension> 1501 </xsd:complexContent> 1502 </xsd:complexType> 1503 <xsd:element name="toParts" type="tToParts" /> 1504 <xsd:complexType name="tToParts"> 1505 <xsd:complexContent> 1506 <xsd:extension base="tExtensibleElements"> 1507 <xsd:sequence> 1508 <xsd:element ref="toPart" maxOccurs="unbounded" /> 1509 </xsd:sequence> 1510 </xsd:extension> 1511 </xsd:complexContent> 1512 </xsd:complexType> 1513 <xsd:element name="toPart" type="tToPart" /> 1514 <xsd:complexType name="tToPart"> 1515 <xsd:complexContent> 1516 <xsd:extension base="tExtensibleElements"> 1517 <xsd:attribute name="part" type="xsd:NCName" use="required" /> 1518 <xsd:attribute name="fromVariable" 1519 type="bpel:BPELVariableName" use="required" /> 1520 </xsd:extension> 1521 </xsd:complexContent> 1522 </xsd:complexType> 1523 <xsd:element name="attachmentPropagation" 1524 type="tAttachmentPropagation" /> 1525 <xsd:complexType name="tAttachmentPropagation"> 1526 <xsd:complexContent> 1527 <xsd:extension base="tExtensibleElements"> 1528 <xsd:attribute name="fromProcess" type="tFromProcess" 1529 default="all" /> 1530 <xsd:attribute name="toProcess" type="tToProcess" 1531 default="newOnly" /> 1532 </xsd:extension> 1533 </xsd:complexContent> 1534 </xsd:complexType> 1535 <xsd:simpleType name="tFromProcess"> 1536 <xsd:restriction base="xsd:string"> 1537 <xsd:enumeration value="all" /></p><p>124bpel4people-spec-WD-01 12 March 2008 125Copyright © OASIS® 2008. All Rights Reserved. Page 42 of 54 1538 <xsd:enumeration value="none" /> 1539 </xsd:restriction> 1540 </xsd:simpleType> 1541 <xsd:simpleType name="tToProcess"> 1542 <xsd:restriction base="xsd:string"> 1543 <xsd:enumeration value="all" /> 1544 <xsd:enumeration value="newOnly" /> 1545 <xsd:enumeration value="none" /> 1546 </xsd:restriction> 1547 </xsd:simpleType> 1548 1549 <!-- miscellaneous helper elements and types --> 1550 <xsd:simpleType name="tBoolean"> 1551 <xsd:restriction base="xsd:string"> 1552 <xsd:enumeration value="yes" /> 1553 <xsd:enumeration value="no" /> 1554 </xsd:restriction> 1555 </xsd:simpleType> 1556 1557</xsd:schema></p><p>127bpel4people-spec-WD-01 12 March 2008 128Copyright © OASIS® 2008. All Rights Reserved. Page 43 of 54 1558D. Sample</p><p>1559This appendix contains a sample that outlines the basic concepts of this specification. The sample 1560process implements the election of the “Employee of the month” in a fictious company. The structure of 1561the business process is shown in the figure below: 1562</p><p>1563The process is started and as a first step, the people are determined that qualify as voters for the 1564“Employee of the month”. Next, all the voters identified before get a chance to cast their votes. After that, 1565the election result is determined by counting the votes casted. After the result is clear, two different 1566people from the set of people entitled to approve the election either accept or reject the voting result. In 1567case any of the two rejects, then there is no “Employee of the month” elected in the given month, and the 1568process ends. In case all approvals are obtained successfully, the employees are notified about the 1569outcome of the election, and a to-do is created for the elected “Employee of the month” to prepare an 1570inaugural speech. Once this is completed, the process completes successfully. 1571The sections below show the definition of the BPEL process implementing the “Employee of the month” 1572process. </p><p>130bpel4people-spec-WD-01 12 March 2008 131Copyright © OASIS® 2008. All Rights Reserved. Page 44 of 54 1573 BPEL Definition 1574<process 1575 name="EmployeeOfTheMonthProcess" 1576 targetNamespace="http://www.example.com" 1577 xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable" 1578 xmlns:b4p="http://www.example.org/BPEL4People" 1579 xmlns:htd="http://www.example.org/WS-HT" 1580 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1581 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 1582 xmlns:tns="http://www.example.com" 1583 xmlns:hr="http://www.example.com/approval" 1584 xmlns:el="http://www.example.com/election" 1585 xmlns:ty="http://www.example.com/types" 1586 xmlns:ta="http://www.example.com/tasks" 1587 xsi:schemaLocation="http://www.example.org/BPEL4People 1588 ws-bpel4people.xsd"> 1589 1590 <b4p:humanInteractions> 1591 1592 <htd:logicalPeopleGroups> 1593 1594 <htd:logicalPeopleGroup name="voters"> 1595 <htd:documentation xml:lang="en-US"> 1596 The group entitled to vote the employee of the month for the 1597 given region. 1598 </htd:documentation> 1599 <htd:parameter name="region" type="xsd:string" /> 1600 </htd:logicalPeopleGroup> 1601 1602 <htd:logicalPeopleGroup name="approvers"> 1603 <htd:documentation xml:lang="en-US"> 1604 The group entitled to approve the elected employee of the 1605 month for the given region. 1606 </htd:documentation> 1607 <htd:parameter name="region" type="xsd:string" /> 1608 </htd:logicalPeopleGroup> 1609 1610 <htd:logicalPeopleGroup name="employees"> 1611 <htd:documentation xml:lang="en-US"> 1612 The group of employees to be notified about the election 1613 result of the employee of the month election for the given 1614 region. 1615 </htd:documentation> 1616 <htd:parameter name="region" type="xsd:string" /> 1617 </htd:logicalPeopleGroup> 1618 1619 <htd:logicalPeopleGroup name="regionalElectionCommittee"> 1620 <htd:documentation xml:lang="en-US"> 1621 The group who is in charge for the election of the 1622 employee of the month election for the given region. 1623 </htd:documentation> 1624 <htd:parameter name="region" type="xsd:string" /> 1625 </htd:logicalPeopleGroup> 1626 1627 </htd:logicalPeopleGroups> 1628 133bpel4people-spec-WD-01 12 March 2008 134Copyright © OASIS® 2008. All Rights Reserved. Page 45 of 54 1629 <htd:tasks> 1630 <htd:task name="approveEmployeeOfTheMonth"> 1631 <htd:documentation xml:lang="en-US"> 1632 The reusable definition of the task used to approve the 1633 election of the employee of the month. 1634 </htd:documentation> 1635 <htd:interface operation="approve" 1636 portType="hr:approvalPT"/> 1637 <htd:peopleAssignments> 1638 <htd:potentialOwners> 1639 <htd:from logicalPeopleGroup="approvers"> 1640 <!-- variables used here need to be defined on the 1641 enclosing scope or above --> 1642 <htd:argument name="region"> 1643 $electionRequest/region 1644 </htd:argument> 1645 </htd:from> 1646 </htd:potentialOwners> 1647 </htd:peopleAssignments> 1648 <htd:presentationElements/> 1649 </htd:task> 1650 </htd:tasks> 1651 1652 </b4p:humanInteractions> 1653 1654 <b4p:peopleAssignments> 1655 1656 <b4p:processStakeholders> 1657 <htd:from logicalPeopleGroup="regionalElectionCommittee"> 1658 <htd:argument name="region"> 1659 $electionRequest/region 1660 </htd:argument> 1661 </htd:from> 1662 </b4p:processStakeholders> 1663 1664 <b4p:businessAdministrators> 1665 <htd:from> 1666 <htd:literal> 1667 <htd:entity xsi:type="htd:organizationalEntity"> 1668 <htd:users> 1669 <htd:user>Peter</htd:user> 1670 <htd:user>Paul</htd:user> 1671 <htd:user>Mary</htd:user> 1672 </htd:users> 1673 </htd:entity> 1674 </htd:literal> 1675 </htd:from> 1676 </b4p:businessAdministrators> 1677 1678 </b4p:peopleAssignments> 1679 1680 <extensions> 1681 <extension 1682 namespace="http://www.example.org/BPEL4People" 1683 mustUnderstand="yes"/> 1684 <extension 1685 namespace="http://www.example.org/WS-HT" </p><p>136bpel4people-spec-WD-01 12 March 2008 137Copyright © OASIS® 2008. All Rights Reserved. Page 46 of 54 1686 mustUnderstand="yes"/> 1687 </extensions> 1688 1689 <import 1690 importType="http://www.w3.org/2001/XMLSchema" 1691 namespace="http://www.example.com/types"/> 1692 <import 1693 importType="http://www.example.org/WS-HT" 1694 namespace="http://www.example.com/tasks"/> 1695 <import 1696 importType="http://schemas.xmlsoap.org/wsdl/" 1697 namespace="http://www.example.com/election" 1698 location="election.wsdl"/> 1699 <import 1700 importType="http://schemas.xmlsoap.org/wsdl/" 1701 namespace="http://www.example.com/approval" 1702 location="approval.wsdl"/> 1703 1704 <partnerLinks> 1705 <partnerLink partnerLinkType="electionPLT" 1706 name="electionPL"/> 1707 </partnerLinks> 1708 1709 <variables> 1710 <variable name="candidates" type="htd:users"/> 1711 <variable name="voters" type="htd:tOrganizationalEntity"/> 1712 <variable name="electionRequest" type="ty:electionRequestData"/> 1713 <variable name="electionResult" type="ty:electionResultData"/> 1714 <variable name="decision" type="xsd:boolean"/> 1715 <variable name="speech" type="ty:document"/> 1716 </variables> 1717 1718 <sequence> 1719 <receive partnerLink="electionPL" 1720 portType="el:electionPT" 1721 operation="elect" 1722 variable="electionRequest" 1723 createInstance="yes"/> 1724 1725 <assign name="getVoters"> 1726 <copy> 1727 <from>$electionRequests/candidates</from> 1728 <to variable="candidates"/> 1729 </copy> 1730 <copy> 1731 <from b4p:logicalPeopleGroup="voters"> 1732 <b4p:argument name="region"> 1733 $electionRequest/region 1734 </b4p:argument> 1735 </from> 1736 <to variable="voters" /> 1737 </copy> 1738 </assign> 1739 1740 <forEach counterName="i" parallel="yes"> 1741 <startCounterValue> 1 </startCounterValue> 1742 <finalCounterValue> </p><p>139bpel4people-spec-WD-01 12 March 2008 140Copyright © OASIS® 2008. All Rights Reserved. Page 47 of 54 1743 count($voters/users/user) 1744 </finalCounterValue> 1745 1746 <scope> 1747 <variables> 1748 <variable name="vote" type="htd:user"/> 1749 </variables> 1750 1751 <sequence> 1752 <!-- Scenario 1 --> 1753 <extensionActivity> 1754 <b4p:peopleActivity name="electEmployeeOfTheMonth" 1755 inputVariable="candidates" 1756 outputVariable="vote" 1757 isSkipable="yes"> 1758 <htd:task name="votingTask"> 1759 <htd:interface operation="vote" 1760 portType="el:votingPT"/> 1761 <htd:peopleAssignments> 1762 <htd:potentialOwners> 1763 <htd:from>$voters/users/user[i]</htd:from> 1764 </htd:potentialOwners> 1765 </htd:peopleAssignments> 1766 <htd:presentationElements/> 1767 </htd:task> 1768 <b4p:scheduledActions> 1769 <b4p:expiration> 1770 <b4p:documentation xml:lang="en-US"> 1771 This people activity expires when not completed 1772 within 2 days after having been activated. 1773 </b4p:documentation> 1774 <b4p:for>P2D</b4p:for> 1775 </b4p:expiration> 1776 </b4p:scheduledActions> 1777 </b4p:peopleActivity> 1778 </extensionActivity> 1779 1780 <assign> 1781 <copy> 1782 <from>$vote</from> 1783 <to>$electionResult/votes[i]</to> 1784 </copy> 1785 </assign> 1786 1787 </sequence> 1788 </scope> 1789 </forEach> 1790 1791 <!-- Might be scenario 5 ... --> 1792 <invoke name="determineElectionResult" 1793 partnerLink="" 1794 portType="" 1795 operation="" 1796 inputVariable="" 1797 outputVariable=""/> 1798 1799 <!-- Scenario 2 --></p><p>142bpel4people-spec-WD-01 12 March 2008 143Copyright © OASIS® 2008. All Rights Reserved. Page 48 of 54 1800 <extensionActivity> 1801 <b4p:peopleActivity name="firstApproval" 1802 inputVariable="electionResult" 1803 outputVariable="decision"> 1804 <b4p:localTask reference="tns:approveEmployeeOfTheMonth"/> 1805 </b4p:peopleActivity> 1806 </extensionActivity> 1807 1808 <!-- Scenario 2 with override specifications --> 1809 <extensionActivity> 1810 <b4p:peopleActivity name="secondApproval" 1811 inputVariable="electionResult" 1812 outputVariable="decision"> 1813 <b4p:localTask reference="tns:approveEmployeeOfTheMonth"> 1814 <htd:peopleAssignments> 1815 <htd:excludedOwners> 1816 <htd:from> 1817 b4p:getActualOwner("tns:firstApproval") 1818 </htd:from> 1819 </htd:excludedOwners> 1820 </htd:peopleAssignments> 1821 </b4p:localTask> 1822 </b4p:peopleActivity> 1823 </extensionActivity> 1824 1825 <!-- Scenario 3 --> 1826 <extensionActivity> 1827 <b4p:peopleActivity name="notifyEmployees" 1828 inputVariable="electionResult"> 1829 <b4p:localNotification reference="task:employeeBroadcast"/> 1830 <!-- notification is not defined as part of this document, 1831 but within a separate one 1832 --> 1833 </b4p:peopleActivity> 1834 </extensionActivity> 1835 1836 <!-- Scenario 4 --> 1837 <extensionActivity> 1838 <b4p:peopleActivity name="prepareInauguralSpeech" 1839 inputVariable="electionResult" 1840 outputVariable="speech" 1841 isSkipable="no"> 1842 <b4p:remoteTask partnerLink="author" 1843 operation="prepareSpeech" 1844 responseOperation="receiveSpeech"> 1845 <htd:priority>0</htd:priority> <!-- assign highest prio --> 1846 <htd:peopleAssignments> 1847 <htd:potentialOwners> 1848 <htd:from>$electionResult/winner</htd:from> 1849 </htd:potentialOwners> 1850 </htd:peopleAssignments> 1851 </b4p:remoteTask> 1852 </b4p:peopleActivity> 1853 </extensionActivity> 1854 1855 </sequence> 1856 145bpel4people-spec-WD-01 12 March 2008 146Copyright © OASIS® 2008. All Rights Reserved. Page 49 of 54 1857</process></p><p>1858 WSDL Definitions 1859<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 1860 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1861 xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype" 1862 xmlns:tns="http://www.example.com/election" 1863 targetNamespace="http://www.example.com/election"> 1864 1865 <plnk:partnerLinkType name="electionPLT"> 1866 <plnk:role name="electionService" portType="tns:electionPT" /> 1867 </plnk:partnerLinkType> 1868 1869 <wsdl:message name="electionInput"> 1870 <wsdl:part name="parameters" element="xsd:string" /> 1871 </wsdl:message> 1872 <wsdl:message name="votingInput"> 1873 <wsdl:part name="parameters" element="xsd:string" /> 1874 </wsdl:message> 1875 1876 <wsdl:portType name="electionPT"> 1877 <wsdl:operation name="elect"> 1878 <wsdl:input message="tns:electionInput" /> 1879 </wsdl:operation> 1880 </wsdl:portType> 1881 <wsdl:portType name="votingPT"> 1882 <wsdl:operation name="vote"> 1883 <wsdl:input message="tns:votingInput" /> 1884 </wsdl:operation> 1885 </wsdl:portType> 1886 1887</wsdl:definitions> 1888 1889<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 1890 xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1891 xmlns:tns="http://www.example.com/approval" 1892 targetNamespace="http://www.example.com/approval"> 1893 1894 <!-- Messages --> 1895 <wsdl:message name="approvalInput"> 1896 <wsdl:part name="parameters" element="xsd:string" /> 1897 </wsdl:message> 1898 <wsdl:message name="approvalOutput"> 1899 <wsdl:part name="parameters" element="xsd:string" /> 1900 </wsdl:message> 1901 1902 <!-- Mandatory Asynchronous Messaging PortTypes --> 1903 <wsdl:portType name="approvalPT"> 1904 <wsdl:operation name="approve"> 1905 <wsdl:input message="tns:approvalInput" /> 1906 <wsdl:output message="tns:approvalOutput" /> 1907 </wsdl:operation> 1908 </wsdl:portType> 1909 1910</wsdl:definitions></p><p>148bpel4people-spec-WD-01 12 March 2008 149Copyright © OASIS® 2008. All Rights Reserved. Page 50 of 54 1911E. Acknowledgements</p><p>1912The following individuals have participated in the creation of this specification and are gratefully 1913acknowledged: 1914 1915Members of the BPEL4People Technical Committee: 1916 Ashish Agrawal, Adobe Systems 1917 Mike Amend, BEA Systems, Inc. 1918 Stefan Baeuerle, SAP AG 1919 Charlton Barreto, Adobe Systems 1920 Justin Brunt, TIBCO Software Inc. 1921 Martin Chapman, Oracle Corporation 1922 James Bryce Clark, OASIS 1923 Luc Clement, Active Endpoints, Inc. 1924 Manoj Das, Oracle Corporation 1925 Mark Ford, Active Endpoints, Inc. 1926 Sabine Holz, SAP AG 1927 Dave Ings, IBM 1928 Gershon Janssen, Individual 1929 Diane Jordan, IBM 1930 Anish Karmarkar, Oracle Corporation 1931 Ulrich Keil, SAP AG 1932 Oliver Kieselbach, SAP AG 1933 Matthias Kloppmann, IBM 1934 Dieter König, IBM 1935 Marita Kruempelmann, SAP AG 1936 Frank Leymann, IBM 1937 Mark Little, Red Hat 1938 Ashok Malhotra, Oracle Corporation 1939 Mike Marin, IBM 1940 Mary McRae, OASIS 1941 Vinkesh Mehta, Deloitte Consulting LLP 1942 Jeff Mischkinsky, Oracle Corporation 1943 Ralf Mueller, Oracle Corporation 1944 Krasimir Nedkov, SAP AG 1945 Benjamin Notheis, SAP AG 1946 Michael Pellegrini, Active Endpoints, Inc. 1947 Gerhard Pfau, IBM 1948 Karsten Ploesser, SAP AG 1949 Ravi Rangaswamy, Oracle Corporation</p><p>151bpel4people-spec-WD-01 12 March 2008 152Copyright © OASIS® 2008. All Rights Reserved. Page 51 of 54 1950 Alan Rickayzen, SAP AG 1951 Michael Rowley, BEA Systems, Inc. 1952 Ron Ten-Hove, Sun Microsystems 1953 Ivana Trickovic, SAP AG 1954 Alessandro Triglia, OSS Nokalva 1955 Claus von Riegen, SAP AG 1956 Peter Walker, Sun Microsystems 1957 Franz Weber, SAP AG 1958 Prasad Yendluri, Software AG, Inc. 1959 1960BPEL4People 1.0 Specification Contributors: 1961 Ashish Agrawal, Adobe 1962 Mike Amend, BEA 1963 Manoj Das, Oracle 1964 Mark Ford, Active Endpoints 1965 Chris Keller, Active Endpoints 1966 Matthias Kloppmann, IBM 1967 Dieter König, IBM 1968 Frank Leymann, IBM 1969 Ralf Müller, Oracle 1970 Gerhard Pfau, IBM 1971 Karsten Plösser, SAP 1972 Ravi Rangaswamy, Oracle 1973 Alan Rickayzen, SAP 1974 Michael Rowley, BEA 1975 Patrick Schmidt, SAP 1976 Ivana Trickovic, SAP 1977 Alex Yiu, Oracle 1978 Matthias Zeller, Adobe 1979 1980In addition, the following individuals have provided valuable input into the design of this specification: 1981Dave Ings, Diane Jordan, Mohan Kamath, Ulrich Keil, Matthias Kruse, Kurt Lind, Jeff Mischkinsky, Bhagat 1982Nainani, Michael Pellegrini, Lars Rueter, Frank Ryan, David Shaffer, Will Stallard, Cyrille Waguet, Franz 1983Weber, and Eric Wittmann.</p><p>154bpel4people-spec-WD-01 12 March 2008 155Copyright © OASIS® 2008. All Rights Reserved. Page 52 of 54 1984F. Non-Normative Text</p><p>157bpel4people-spec-WD-01 12 March 2008 158Copyright © OASIS® 2008. All Rights Reserved. Page 53 of 54 1985G. Revision History</p><p>1986[optional; should not be included in OASIS Standards] 1987 Revision Date Editor Changes Made WD-01 2008-03-12 Dieter König First working draft created from submitted specification</p><p>1988</p><p>160bpel4people-spec-WD-01 12 March 2008 161Copyright © OASIS® 2008. All Rights Reserved. Page 54 of 54</p>