OASIS Specification Template s7

2WS-BPEL Extension for People 3(BPEL4People) 4Specification Version 1.1

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

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/.

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.

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

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

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.

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.

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.

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].

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 must be used to declare mandatory and optional extensions 242of BPEL4People.

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.

2462.4.1 Syntax 247Informal syntax of a BPEL process and scope containing logical people groups, inline human tasks, and 248people activity follows. 249

19bpel4people-spec-WD-01 12 March 2008 20Copyright © OASIS® 2008. All Rights Reserved. Page 7 of 54 253 ... 254 255 258 261 262 263 265 266 ... 267 ? 268 269 ? 270 + 271 ... 272 273 274 275 ? 276 + 277 ... 278 279 280 281 ? 282 + 283 ... 284 285 286 287 288 289 290 ... 291 292 293 ... 294 295 296 ... 297 298 299 ... 300 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 is optional and contains declarations of elements from WS- 305HumanTask namespace, that is , and 306.

22bpel4people-spec-WD-01 12 March 2008 23Copyright © OASIS® 2008. All Rights Reserved. Page 8 of 54 307The element 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 element. 311The 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 element. 315The 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 element. 319The element 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 is used to model human interactions within BPEL 322processes. The new activity is included in the BPEL activity which is 323used as wrapper. The syntax and semantics of the people activity are introduced in section 4 “People 324Activity”. 325 326 ... 327 ? 328 ... 329 330 ... 331 332 333 ... 334 335 336 ... 337 338BPEL scopes may also include elements from BPEL4People and WS-HumanTask namespaces except 339for the element. 340All BPEL4People elements may use the element to provide annotation for 341users. The content could be a plain text, HTML, and so on. The element is 342optional and has the following syntax: 343 344 ... 345

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.

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

3713.1.1 Syntax 372 373 374 + 375 ... 376 377 378 379The genericHumanRole abstract element introduced in the WS-HumanTask specification is extended 380with the following process-related human roles. 381 382 383 ? 384 ... 385 386 387 ? 388 ... 389 390 391 ? 28bpel4people-spec-WD-01 12 March 2008 29Copyright © OASIS® 2008. All Rights Reserved. Page 10 of 54 392 ... 393 394 395 396Only process-related human roles MAY be used within the 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 or is 400entered) and has impact on the scope initialization outcome. That is, if an assignment fails the entire 401process is treated as faulted.

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”).

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 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 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 431 * 432 value 433 434 435 436

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 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 449 ? 450 queryContent 451 452 453 454  To copy to non-message variables and parts of message variables 455 456 expression 457 458  To copy to a property 459 460 461 462  To copy to a logical people group 463 464 465 466Using a logical people group in the to-spec of a 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 474 ? 475 queryContent 476 477 478 479  To copy from a property 480 481 482 483  To copy from non-message variables and parts of message variables 484 485 expression 486 487  To copy from a literal value 488

34bpel4people-spec-WD-01 12 March 2008 35Copyright © OASIS® 2008. All Rights Reserved. Page 12 of 54 489 490 literal value 491 492 493  To copy from a logical people group 494 495 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 500 501 502 503 $electionRequest/region 504 505 506 507 508 509 510The next example demonstrates assigning a set of people to a logical people group using literal values. 511 512 513 514 515 516 517 Alan 518 Dieter 519 Frank 520 Gerhard 521 Ivana 522 Karsten 523 Matthias 524 Patrick 525 526 527 528 529 530 531 532 533The third example shows assigning the results of one logical people group to another logical people 534group. 535 536 537 538 539 540

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 545 546 ... 547 548 549The from-spec variant 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: 553expression 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.

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.

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

BPEL Process BPEL Process BPEL Process BPEL Process

People People People People Activity Activity Activity Activity

Inline Callable HT- Human Task WSDL Protocol Interface Interface Inline Standalone Human Task Human Task Standalone Task

1 2 3 4

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.

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 601 602 605 606 standard-elements 607 608 ( ... 609 | ... 610 | ... 611 | ... 612 | ... 613 | ... 614 ) 615 616 ? ... 617 618 ? 619 + 620 621 622 ? 623 + 624 625 626 ? 628 629 630 631

6324.1.1 Properties 633The 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 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 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.

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 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 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.

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

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 711 integer-expression 712 713 714? 715 716 ... 717 718

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.

7304.3.1 Syntax 731 732 734 standard-elements 735 736 ( ... 737 | 738 standard-overriding-elements 739 740 ) 741 742

52bpel4people-spec-WD-01 12 March 2008 53Copyright © OASIS® 2008. All Rights Reserved. Page 18 of 54 743 744Properties 745Element 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 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”.

7524.3.2 Examples 753The following code shows a people activity declaring an inline task. 754 757 758 759 760 $voters/users/user[i] 761 762 763 764 765 766 767 This people activity expires when not completed 768 within 2 days after having been activated. 769 770 P2D 771 772 773 774 775The following code shows a people activity referring to an inline task defined in the BPEL4People 776process. 777 778 780 781 782

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

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.

7934.4.1 Syntax 794 796 standard-elements 797 798 ( ... 799 | 800 standard-overriding-elements 801 802 ) 803 804 805Properties 806Element 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.

809Element 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”.

8144.4.2 Examples 815The following code shows a people activity using a standalone notification. 816 817 819 820 823 824

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 842 843 standard-overriding-elements 844 845 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 . 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.

8524.5.2 Example 853 854 858 861 0 862 863 864 $electionResult/winner 865 866 867 868 869

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

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 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 as well as a using two 896one-ways) the activity is blocking. That is, the normal processing of a 897 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.

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.

9104.6.1 Syntax 911 914 915 standard-overriding-elements 916 917

9184.6.2 Example 919 920 922 924 42 925 926 927 $voters 928 929 930 931 932

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 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? 953 954 ? 955 ( 956 duration-expression 957 958 | 959 deadline-expression 960 961 ) 962 963 964 ? 965 ( 966 duration-expression 967 968 | 969 deadline-expression 970 971 ) 972 973 974 975 976Properties 977The 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).

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 and are mutually exclusive. There MUST be at least 986 one or 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 and are mutually exclusive. There MUST be at least 994 one or 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 1002 1003 1004 1005 Activation of this task is deferred until the time specified 1006 in its input data. 1007 1008 htd:getInput()/activateAt 1009 1010 1011 1012 1013 This task expires when not completed within 14 days after 1014 having been activated. 1015 1016 P14D 1017 1018 1019

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.

[Reached by navigation] Send request to the task, pass new WS-HT context

[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"

[Task returns application fault] [Task returns response] [WS-HT skipped] Throw application fault Continue navigation Continue navigation

Failed Completed Obsolete Terminated

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.

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].

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.

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

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.

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

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)

1062 1063XPath functions accessing data of a human task only guarantee to return data once the corresponding 1064task has reached a final state.

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

(1)requestMessage (HT coordination context, Task overriding task attributes, Coordinator attachments, callback EPR)

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 (4a) responseMessage (attachments) ... (4b) Skipped ...

Figure 3: Message exchange between a people activity and a human task

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.

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

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 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 encountered in enclosing Exit Out process

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.

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.

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 may also serve as a 1119placeholder for a containing a .

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 1124 1125 1126

11277.1.3 Opaque Attributes 1128Any attribute introduced by BPEL4People can have an opaque value "##opaque" in an abstract 1129process.

11307.1.4 Opaque From-Spec 1131In BPEL, any from-spec in an executable process can be replaced by an opaque from-spec 1132 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 can also be replaced by an opaque from-spec in an abstract process.

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, is equivalent to .

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.

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.

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.

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

1211The following list specifies the standard faults defined within the BPEL4People specification. All standard 1212fault names are qualified with the standard BPEL4People namespace.

Fault name Description

nonRecoverableError Thrown if the task experiences a non-recoverable error.

taskExpired Thrown if the task expired.

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.

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.

1258 1259 1265 1266 1267 1269 1271 1274 1275 1276 1277 1278 1280 1282 1283 1284 1285 1286 1287 1289 1290 1291 1292 1293 1294 1295 1297 1298 1299 1300 1301 1302 1304 1305 1306 1307 1309

112bpel4people-spec-WD-01 12 March 2008 113Copyright © OASIS® 2008. All Rights Reserved. Page 38 of 54 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1324 1325 1326 1327 1328 1329 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1346 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1362 1363 1364 1365 1366

115bpel4people-spec-WD-01 12 March 2008 116Copyright © OASIS® 2008. All Rights Reserved. Page 39 of 54 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1386 1387 1388 1390 1391 1392 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1413 1414 1415 1416 1417 1418 1419 1420 1422

124bpel4people-spec-WD-01 12 March 2008 125Copyright © OASIS® 2008. All Rights Reserved. Page 42 of 54 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557

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

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.

130bpel4people-spec-WD-01 12 March 2008 131Copyright © OASIS® 2008. All Rights Reserved. Page 44 of 54 1573 BPEL Definition 1574 1589 1590 1591 1592 1593 1594 1595 1596 The group entitled to vote the employee of the month for the 1597 given region. 1598 1599 1600 1601 1602 1603 1604 The group entitled to approve the elected employee of the 1605 month for the given region. 1606 1607 1608 1609 1610 1611 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 1616 1617 1618 1619 1620 1621 The group who is in charge for the election of the 1622 employee of the month election for the given region. 1623 1624 1625 1626 1627 1628 133bpel4people-spec-WD-01 12 March 2008 134Copyright © OASIS® 2008. All Rights Reserved. Page 45 of 54 1629 1630 1631 1632 The reusable definition of the task used to approve the 1633 election of the employee of the month. 1634 1635 1637 1638 1639 1640 1642 1643 $electionRequest/region 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 $electionRequest/region 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 Peter 1670 Paul 1671 Mary 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1684

136bpel4people-spec-WD-01 12 March 2008 137Copyright © OASIS® 2008. All Rights Reserved. Page 46 of 54 1686 mustUnderstand="yes"/> 1687 1688 1689 1692 1695 1699 1703 1704 1705 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1724 1725 1726 1727 $electionRequests/candidates 1728 1729 1730 1731 1732 1733 $electionRequest/region 1734 1735 1736 1737 1738 1739 1740 1741 1 1742

139bpel4people-spec-WD-01 12 March 2008 140Copyright © OASIS® 2008. All Rights Reserved. Page 47 of 54 1743 count($voters/users/user) 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1758 1759 1761 1762 1763 $voters/users/user[i] 1764 1765 1766 1767 1768 1769 1770 1771 This people activity expires when not completed 1772 within 2 days after having been activated. 1773 1774 P2D 1775 1776 1777 1778 1779 1780 1781 1782 $vote 1783 $electionResult/votes[i] 1784 1785 1786 1787 1788 1789 1790 1791 1792 1798 1799

142bpel4people-spec-WD-01 12 March 2008 143Copyright © OASIS® 2008. All Rights Reserved. Page 48 of 54 1800 1801 1804 1805 1806 1807 1808 1809 1810 1813 1814 1815 1816 1817 b4p:getActualOwner("tns:firstApproval") 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1829 1830 1833 1834 1835 1836 1837 1838 1842 1845 0 1846 1847 1848 $electionResult/winner 1849 1850 1851 1852 1853 1854 1855 1856 145bpel4people-spec-WD-01 12 March 2008 146Copyright © OASIS® 2008. All Rights Reserved. Page 49 of 54 1857

1858 WSDL Definitions 1859 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910

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

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.

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