This specification introduces an extension to BPEL in order
to support a broad range of scenarios that involve people within business
processes.
The BPEL specification focuses on business processes the
activities of which are assumed to be interactions with Web services, without
any further prerequisite behavior. But the spectrum of activities that make up
general purpose business processes is much broader. People often participate in
the execution of business processes introducing new aspects such as interaction
between the process and user interface, and taking into account human behavior.
This specification introduces a set of elements which extend the standard BPEL
elements and enable the modeling of human interactions, which may range from
simple approvals to complex scenarios such as separation of duties, and
interactions involving ad-hoc data.
The specification introduces the people activity as a new
type of basic activity which enables the specification of human interaction in
processes in a more direct way. The implementation of a people activity could
be an inline task or a standalone human task defined in the WS-HumanTask
specification [WS-HumanTask]. The syntax and state diagram of the people
activity and the coordination protocol that allows interacting with human tasks
in a more integrated way is described. The specification also introduces XPath
extension functions needed to access the process context.
The goal of this specification is to enable portability and
interoperability:
Portability - The ability to take design-time artifacts
created in one vendor's environment and use them in another vendor's
environment.
Interoperability - The capability for multiple components
(process infrastructure, task infrastructures and task list clients) to
interact using well-defined messages and protocols. This enables combining
components from different vendors allowing seamless execution.
Out of scope of this
specification is how processes with human interactions are deployed or
monitored. Usually people assignment is accomplished by performing queries on a
people directory which has a certain organizational model. The mechanism of how
an implementation evaluates people assignments, as well as the structure of the
data in the people directory is also out of scope.
The keywords "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119 [RFC 2119].
[BPEL4WS 1.1]
Business Process Execution Language
for Web Services Version 1.1, BEA Systems, IBM, Microsoft, SAP AG and Siebel
Systems, May 2003, available via http://www-128.ibm.com/developerworks/library/specification/ws-bpel/,
http://ifr.sap.com/bpel4ws/
[RFC 2119]
Key words for use in RFCs to
Indicate Requirement Levels, RFC
2119, available via http://www.ietf.org/rfc/rfc2119.txt
[RFC 3066]
Tags for the Identification of
Languages, H. Alvestrand, IETF, January 2001, available via http://www.isi.edu/in-notes/rfc3066.txt
[WS-Addr-Core]
Web
Services Addressing 1.0 - Core, W3C Recommendation, May 2006, available via
http://www.w3.org/TR/ws-addr-core
[WS-Addr-SOAP]
Web
Services Addressing 1.0 – SOAP Binding, W3C Recommendation, May 2006,
available via http://www.w3.org/TR/ws-addr-soap
[WS-Addr-WSDL]
Web
Services Addressing 1.0 – WSDL Binding, W3C Working Draft, February 2006,
available via http://www.w3.org/TR/ws-addr-wsdl
[WS-BPEL 2.0]
OASIS Standard, “Web Service
Business Process Execution Language Version 2.0”, 11 April 2007, http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html
[WSDL 1.1]
Web Services Description Language
(WSDL) Version 1.1, W3C Note, available via http://www.w3.org/TR/2001/NOTE-wsdl-20010315
[WS-HumanTask]
OASIS Committee Draft, “Web
Services – Human Task (WS-HumanTask) Specification Version 1.1, CD-06”, 04
November 2009, http://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cd-06.doc
[XML Infoset]
XML Information Set,
W3C Recommendation, available via http://www.w3.org/TR/2001/REC-xml-infoset-20011024/
Namespaces in XML 1.0 (Second Edition), W3C
Recommendation, available via http://www.w3.org/TR/REC-xml-names/
[XML Schema Part 1]
XML Schema Part 1: Structures, W3C
Recommendation, October 2004, available via http://www.w3.org/TR/xmlschema-1/
[XML Schema Part 2]
XML Schema Part 2: Datatypes, W3C
Recommendation, October 2004, available via http://www.w3.org/TR/xmlschema-2/
[XMLSpec]
XML Specification, W3C
Recommendation, February 1998, available via http://www.w3.org/TR/1998/REC-xml-19980210
[XPATH 1.0]
XML Path Language (XPath) Version
1.0, W3C Recommendation, November 1999, available via http://www.w3.org/TR/1999/REC-xpath-19991116
There are no non-normative references made by this
specification.
As part of this specification, the following conformance
targets are specified
·
BPEL4People Definition
A BPEL4People Definition is a WS-BPEL 2.0 process definition that uses the
BPEL4People extensions to WS-BPEL 2.0 specified in this document.
·
BPEL4People Processor
A BPEL4People Processor is any implementation that accepts a BPEL4People
definition and executes the semantics defined in this document.
·
WS-HumanTask Definition
A WS-HumanTask Definition is any
artifact that complies with the human interaction schema and additional
constraints as defined by the WS-HumanTask 1.1 specification.
·
WS-HumanTask Processor
A WS-HumanTask Processor is any
implementation that accepts a WS-HumanTask definition and executes the
semantics as defined by the WS-HumanTask 1.1 specification.
The BPEL4People extension is defined in a way that it is
layered on top of BPEL so that its features can be composed with BPEL features
whenever needed. All elements and attributes introduced in this extension are
made available to both BPEL executable processes and abstract processes.
This extension introduces a set of elements and attributes
to cover different complex human interaction patterns, such as separation of
duties, which are not defined as first-class elements.
Throughout this specification, WSDL and schema elements may
be used for illustrative or convenience purposes. However, in a situation where
those elements or other text within this document contradict the separate
BPEL4People, WS-HumanTask, WSDL or schema files, it is those files that have
precedence and not this document.
2.1
Dependencies on Other Specifications
BPEL4People utilizes the following specifications:
- WS-BPEL 2.0: BPEL4People extends the WS-BPEL 2.0 process
model and uses existing WS-BPEL 2.0 capabilities, such as those for data
manipulation.
- WS-HumanTask 1.1: BPEL4People uses the definition of human
tasks and, notifications, and extends generic human roles and people
assignments introduced in WS-HumanTask 1.1.
- WSDL 1.1: BPEL4People uses WSDL for service interface
definitions.
- XML Schema 1.0: BPEL4People utilizes XML
Schema data model.
- XPath 1.0: BPEL4People uses XPath as default
query and expression language.
BPEL4People references these namespaces:
·
htd – http://docs.oasis-open.org/ns/bpel4people/ws-humantask/200803
·
htt – http://docs.oasis-open.org/ns/bpel4people/ws-humantask/types/200803
·
bpel – http://docs.oasis-open.org/wsbpel/2.0/process/executable
·
abstract – http://docs.oasis-open.org/wsbpel/2.0/process/abstract
·
wsdl – http://schemas.xmlsoap.org/wsdl/
·
xsd – http://www.w3.org/2001/XMLSchema
·
xsi – http://www.w3.org/2001/XMLSchema-instance
The BPEL4People specification extends the reach of the
standard BPEL extensibility mechanism to BPEL4People elements. This allows:
Attributes from other namespaces to appear on any
BPEL4People element
Elements from other namespaces to appear within BPEL4People
elements
Extension attributes and extension elements MUST NOT
contradict the semantics of any attribute or element from the BPEL4People
namespace.
The standard BPEL element <extension> MUST be used to declare
mandatory and optional extensions of BPEL4People.
This section explains the structure of BPEL4People extension
elements, including the new activity type people activity, inline human tasks
and people assignments.
Informal syntax of a BPEL process and scope containing
logical people groups, inline human tasks, and people activity follows.
<bpel:process b4p:shareComments="xsd:boolean"? ...
...
xmlns:b4p="http://docs.oasis-open.org/ns/bpel4people/bpel4people/200803"
xmlns:htd="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/200803">
...
<bpel:extensions>
<bpel:extension
namespace="http://docs.oasis-open.org/ns/bpel4people/bpel4people/200803"
mustUnderstand="yes"/>
<bpel:extension
namespace="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/200803"
mustUnderstand="yes"/>
</bpel:extensions>
<bpel:import
importType="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/200803"
…/>
...
<b4p:humanInteractions>?
<htd:logicalPeopleGroups/>?
<htd:logicalPeopleGroup name="NCName" reference="QName"?>+
...
</htd:logicalPeopleGroup>
</htd:logicalPeopleGroups>
<htd:tasks>?
<htd:task name="NCName">+
...
</htd:task>
</htd:tasks>
<htd:notifications>?
<htd:notification name="NCName">+
...
</htd:notification>
</htd:notifications>
</b4p:humanInteractions>
<b4p:peopleAssignments>?
...
</b4p:peopleAssignments>
...
<bpel:extensionActivity>
<b4p:peopleActivity name="NCName"
...>
...
</b4p:peopleActivity>
</bpel:extensionActivity>
...
</bpel:process>
A BPEL4People Definition MUST use BPEL4People extension
elements and elements from WS-HumanTask namespace. Therefore elements from
namespaces BPEL4People and WS-HumanTask MUST be understood.
The element <b4p:humanInteractions>
is optional and contains declarations of elements from WS-HumanTask namespace,
that is <htd:logicalPeopleGroups>, <htd:tasks> and <htd:notifications>.
The element <htd:logicalPeopleGroup>
specifies a logical people group used in an inline human task or a people
activity. The name attribute specifies the name of the logical people group.
The name MUST be unique among the names of all logical people groups defined
within the <b4p:humanInteractions>
element.
The <htd:task>
element is used to provide the definition of an inline human task. The syntax
and semantics of the element are provided in the WS-HumanTask specification.
The name attribute specifies the name of the task. The name MUST be unique
among the names of all tasks defined within the <htd:tasks>
element.
The <htd:notification>
element is used to provide the definition of an inline notification. The syntax
and semantics of the element are provided in the WS-HumanTask specification.
The name attribute specifies the name of the notification. The name MUST be
unique among the names of all notifications defined within the <htd:notifications> element.
The element <b4p:peopleAssignments>
is used to assign people to process-related generic human roles. This element
is optional. The syntax and semantics are introduced in section 3.1 “Generic
Human Roles”.
New activity type <b4p:peopleActivity>
is used to model human interactions within BPEL processes. The new activity is
included in the BPEL activity <bpel:extensionActivity>
which is used as wrapper. The syntax and semantics of the people activity are
introduced in section 4 “People Activity”.
Any scope (or the process itself) can specify @b4p:shareComments="true" to specify
that the comments that are added to any task executed within the scope (or a
child scope) should be propagated to any other task within the same scope that
is started after the first task completes. When comments propagate to later
tasks, all metadata for the comment MUST also be propagated.
Note that, when a scope specifies the sharing of comments,
it is not possible to override that sharing for child or descendent scopes. When
a scope specifies @b4p:shareComments="true"
then child and descendent scopes MUST NOT specify @b4p:shareComments="false". However, an
individual people activity can prevent its tasks’ comments from being
propagated by specifying @dontShareComments="true".
<bpel:scope b4p:shareComments="xsd:boolean"? ...>
...
<b4p:humanInteractions>?
...
</b4p:humanInteractions>
...
<bpel:extensionActivity>
<b4p:peopleActivity name="NCName"
dontShareComments="xsd:boolean" ...>
...
</b4p:peopleActivity>
</bpel:extensionActivity>
...
</bpel:scope>
BPEL scopes can also include elements from BPEL4People and
WS-HumanTask namespaces except for the <b4p:peopleAssignments>
element.
All BPEL4People Definition elements MAY use the element <b4p:documentation> to provide annotation
for users. The content could be a plain text, HTML, and so on. The <b4p:documentation> element is optional and
has the following syntax:
<b4p:documentation xml:lang="xsd:language">
...
</b4p:documentation>
The
XPath 1.0 specification [XPATH 1.0] defines the context in which an XPath
expression is evaluated. When XPath 1.0 is used as an Expression Language in
BPEL4People or inlined WS-HumanTask language elements then the XPath context is
initialized as follows:
- Context node: none
- Context position: none
- Context size: none
- Variable bindings: all WS-BPEL variables visible to the
enclosing element as defined by the WS-BPEL scope rules
- Function library: Core XPath 1.0, WS-BPEL, BPEL4People and
WS-HumanTask functions MUST be available and processor-specific functions
MAY be available
- Namespace declaration: all in-scope namespace declarations
from the enclosing element
Note that XPath 1.0 explicitly requires that any element or
attribute used in an XPath expression that does not have a namespace prefix
must be treated as being namespace unqualified. As a result, even if there is a
default namespace defined on the enclosing element, the default namespace will
not be applied.
Many of the concepts in BPEL4People are inherited from the
WS-HumanTask specification so familiarity with this specification is assumed.
3.1 Generic Human Roles
Process-related generic human roles define what a person or
a group of people resulting from a people assignment can do with the process
instance. The process-related human roles complement the set of generic human
roles specified in [WS-HumanTask]. There are three process-related generic
human roles:
- Process initiator
- Process stakeholders
- Business administrators
Process initiator is the person associated with
triggering the process instance at its creation time. The initiator is
typically determined by the infrastructure automatically. This can be
overridden by specifying a people assignment for process initiator. A
BPEL4People Definition MAY define assignment for this generic human role. A compliant
BPEL4People Processor MUST ensure that at runtime at least one person is associated
with this role.
Process stakeholders are people who can influence the
progress of a process instance, for example, by adding ad-hoc attachments,
forwarding a task, or simply observing the progress of the process instance.
The scope of a process stakeholder is broader than the actual BPEL4People
specification outlines. The process stakeholder is associated with a process
instance. If no process stakeholders are specified, the process initiator
becomes the process stakeholder. A BPEL4People Definition MAY define assignment
for this generic human role. A compliant BPEL4People Processor MUST ensure that
at runtime at least one person is associated with this role.
Business administrators are people allowed to perform
administrative actions on the business process, such as resolving missed
deadlines. A business administrator, in contrast to a process stakeholder, has
an interest in all process instances of a particular process type, and not just
one. If no business administrators are specified, the process stakeholders
become the business administrators. A BPEL4People Definition MAY define
assignment for this generic human role. A compliant BPEL4People Processor MUST
ensure that at runtime at least one person is associated with this role.
<b4p:peopleAssignments>?
<htd:genericHumanRole>+
<htd:from>...</htd:from>
</htd:genericHumanRole>
<b4p:peopleAssignments>
The genericHumanRole
abstract element introduced in the WS-HumanTask specification is extended with
the following process-related human roles.
<b4p:peopleAssignments>?
<b4p:processInitiator>?
<htd:from ...>...</htd:from>
</b4p:processInitiator>
<b4p:processStakeholders>?
<htd:from ...>...</htd:from>
</b4p:processStakeholders>
<b4p:businessAdministrators>?
<htd:from ...>...</htd:from>
</b4p:businessAdministrators>
</b4p:peopleAssignments>
Only process-related human
roles MUST be used within the <b4p:peopleAssignments> element.
People are assigned to these roles as described in section 3.2 (“Assigning
People”).
Assigning people to process-related generic
human roles happens after BPEL process initialization (see [WS-BPEL 2.0],
section 12.1). A BPEL4People Processor MUST initialize process-related generic
human roles after the end of the initial start activity of the process and
before processing other activities or links leaving the start activity. If that
initialization fails then the fault b4p:initializationFailure MUST be thrown by
a BPEL4People Processor.
To determine who is responsible for acting on a process, a
human task or a notification in a certain generic human role, people need to be
assigned. People assignment can be achieved in different ways:
- Via logical people groups (see 3.2.1 “Using Logical People Groups”)
- Via literals (as introduced section 3.2.2 in
[WS-HumanTask])
- Via expressions (see 3.2.2 “Computed Assignment”)
When specifying people assignments then the data type htt:tOrganizationalEntity defined in
[WS-HumanTask] is used. Using htt:tOrganizationalEntity
allows to assign either a list of users or a list of unresolved groups of
people (“work queues”).
This section focuses on describing aspects of logical people
groups that are specific to business processes. Logical people groups define
which person or set of people can interact with a human task or a notification
of a people activity. Details about how logical people groups are used with
human tasks and notifications are provided by the WS-HumanTask specification.
Logical people groups can be specified as part of the
business process definition. They can be defined either at the process level or
on enclosed scopes. Definitions on inner scopes override definitions on outer
scopes or the process respectively.
Logical people group definitions can be referenced by
multiple people activities. Each logical people group is bound to a people
query during deployment.
In the same way as in WS-HumanTask, a logical people group
has one instance per set of unique arguments. Whenever a logical people group
is referenced for the first time with a given set of unique arguments, a new
instance MUST be created by the BPEL4People Processor. To achieve that, the
logical people group MUST be evaluated / resolved for this set of arguments.
Whenever a logical people group is referenced for which an in-stance already
exists (i.e., it has already referenced before with the same set of arguments),
the logical people group MAY be re-evaluated / re-resolved.
In particular, for a logical people group with no
parameters, there is a single instance, which MUST be evaluated / resolved when
the logical people group is first referenced, and which MAY be re-evaluated /
re-resolved when referenced again.
Hence, using the same logical people group does not
necessarily mean that the result of a people query is re-used, but that the
same query is used to obtain a result. If the result of a previous people query
needs to be re-used, then this result needs to be referenced explicitly from
the process context. Please refer to section 5 “XPath Extension Functions” for
a description of the syntax.
Assignment of Logical People Groups
A
BPEL4People Definition MAY use the <assign> activity
(see [WS-BPEL 2.0] section 8.4 for more details) to manipulate values of
logical people group. A mechanism to assign to a logical people group or to
assign from a logical people group using BPEL copy assignments is provided. The
semantics of the <copy>
activity introduced in [WS-BPEL 2.0] (see sections 8.4.1, 8.4.2 and 8.4.3 for
more details) applies.
BPEL4People extends the from-spec and to-spec forms
introduced in [WS-BPEL 2.0] as shown below:
<bpel:from b4p:logicalPeopleGroup="NCName">
<b4p:argument name="NCName" expressionLanguage="anyURI"?>*
value
</b4p:argument>
</bpel:from>
<to b4p:logicalPeopleGroup="NCName"/>
In this form of from-spec and to-spec the b4p:logicalPeopleGroup attribute provides the
name of a logical people group. The from-spec variant MAY include zero or more <b4p:argument> elements in order to pass
values used in the people query. The expressionLanguage attribute specifies the language used in the expression. The attribute
is optional. If not specified, the default language as inherited from the
closest enclosing element that specifies the attribute is used.
Using a logical people group in the from-spec causes the
evaluation of the logical people group. Logical people groups return data of
type htt:tOrganizationalEntity. This data
can be manipulated and assigned to other process variables using standard BPEL
to-spec variable variants.
The new form of the from-spec can be used with the following
to-spec variants:
·
To copy to a variable
<bpel:to variable="BPELVariableName"
part="NCName"? >
<bpel:query queryLanguage="anyURI"? >?
queryContent
</bpel:query>
</bpel:to>
·
To copy to non-message variables and parts of message variables
<bpel:to expressionLanguage="anyURI"?>expression</bpel:to>
·
To copy to a property
<bpel:to variable="BPELVariableName"
property="QName"/>
·
To copy to a logical people group
<bpel:to b4p:logicalPeopleGroup="NCName"/>
Using a logical people group in the to-spec of a <bpel:copy> assignment enables a set of
people to be explicitly assigned. Whenever the logical people group is used
after the assignment this assigned set of people is returned. Assigning values
to a logical people group overrides what has been defined during deployment.
This is true irrespective of any parameters specified for the logical people
group.
The new form of the to-spec can be used with the following
from-spec variants:
·
To copy from a variable
<bpel:from variable="BPELVariableName"
part="NCName"? >
<bpel:query queryLanguage="anyURI"? >?
queryContent
</bpel:query>
</bpel:from>
·
To copy from a property
<bpel:from variable="BPELVariableName"
property="QName"/>
·
To copy from non-message variables and parts of message variables
<bpel:from expressionLanguage="anyURI"?>expression</bpel:from>
·
To copy from a literal value
<bpel:from>
<bpel:literal>literal
value</bpel:literal>
</bpel:from>
·
To copy from a logical people group
<bpel:from b4p:logicalPeopleGroup="NCName"/>
Below are several examples illustrating the usage of logical
people groups in copy assignments. The first example shows assigning the
results of the evaluation of a logical people group to a process variable.
<bpel:assign name="getVoters">
<bpel:copy>
<bpel:from b4p:logicalPeopleGroup="voters">
<b4p:argument name="region">
$electionRequest/region
</b4p:argument>
</bpel:from>
<bpel:to variable="voters"
/>
</bpel:copy>
</bpel:assign>
The next example demonstrates assigning a set of people to a
logical people group using literal values.
<bpel:assign>
<bpel:copy>
<bpel:from>
<bpel:literal>
<htt:tOrganizationalEntity>
<htt:user>Alan</htt:user>
<htt:user>Dieter</htt:user>
<htt:user>Frank</htt:user>
<htt:user>Gerhard</htt:user>
<htt:user>Ivana</htt:user>
<htt:user>Karsten</htt:user>
<htt:user>Matthias</htt:user>
<htt:user>Patrick</htt:user>
</htt:tOrganizationalEntity>
</bpel:literal>
</bpel:from>
<bpel:to b4p:logicalPeopleGroup="bpel4peopleAuthors"
/>
</bpel:copy>
</bpel:assign>
The third example shows assigning the results of one logical
people group to another logical people group.
<bpel:assign>
<bpel:copy>
<bpel:from b4p:logicalPeopleGroup="bpel4peopleAuthors"
/>
<bpel:to b4p:logicalPeopleGroup="approvers"
/>
</bpel:copy>
</bpel:assign>
All computed assignment variants described in [WS-HumanTask]
(see section 3.2 “Assigning People” for more details) are supported. In
addition, the following variant is possible:
<htd:genericHumanRole>
<bpel:from variable="NCName"
part="NCName"? >
...
</bpel:from>
</htd:genericHumanRole>
The from-spec variant <bpel:from
variable> is used to assign people that have been specified using
variable of the business process. The data type of the variable MUST be of type
htt:tOrganizationalEntity.
All other process context can be accessed using expressions
of the following style:
<bpel:from expressionLanguage="anyURI"?>expression</bpel:from>
with XPath extension functions defined in section 5 “XPath Extension Functions”. The expressionLanguage
attribute specifies the language used in the expression. The attribute is
optional. If not specified, the default language as inherited from the closest
enclosing element that specifies the attribute is used.
Processes can have ad-hoc attachments. It is possible to
exchange ad-hoc attachments between people activities of a process by
propagating ad-hoc attachments to and from the process level.
When a people activity is activated, attachments from
earlier tasks and from the process can be propagated to its implementing human
task. On completion of the human task, its ad-hoc attachments can be propagated
to the process level, to make them globally available.
All manipulations of ad-hoc attachments at the process level
are instantaneous, and not subject to compensation or isolation.
People activity is a basic activity used to integrate human
interactions within BPEL processes. The following figure illustrates different
ways in which human interactions (including human tasks and notifications)
could be integrated.
Figure 1: Constellations
Constellations 1 and 2 show models of interaction in which
tasks are defined inline as part of a BPEL process. An inline task can
be defined as part of a people activity (constellation 1). In this case, the
use of the task is limited to the people activity encompassing it.
Alternatively, a task can be defined as a top-level construct of the BPEL
process or scope (constellation 2). In this case, the same task can be used
within multiple people activities, which is significant from a reuse
perspective. BPEL4People processes that use tasks in this way are portable
among BPEL engines that implement BPEL4People. This also holds true for
notifications.
Constellation 3 shows the use of a standalone task within
the same environment, without the specification of a callable Web services
interface on the task. Thus the task invocation is implementation-specific.
This constellation is similar to constellation 2, except that the definition of
the task is done independently of any process. As a result, the task has no
direct access to process context. This also holds true for notifications.
Constellation 4 shows the use of a standalone task from a
different environment. The major difference when compared to constellation 3 is
that the task has a Web services callable interface, which is invoked using Web
services protocols. In addition, the WS-HumanTask coordination protocol is used
to communicate between processes and tasks (see section 6 “Coordinating Standalone Human Tasks” for more details on the WS-HumanTask coordination protocol).
Using this mechanism, state changes are propagated between task and process
activity, and the process can perform life cycle operations on the task, such as
terminating it. BPEL4People processes that use tasks in this way are portable
across different BPEL engines that implement BPEL4People. They are
interoperable, assuming that both the process infrastructures and the task
infrastructures implement the coordination protocol. In case of notifications a
simplified protocol is used. For more detail on the relationship of
WS-HumanTask and the BPEL4People specifications refer to section 1.1 of
WS-HumanTask.
Definition of people activity:
<bpel:extensionActivity>
<b4p:peopleActivity name="NCName"
inputVariable="NCName"?
outputVariable="NCName"? isSkipable="xsd:boolean"?
dontShareComments="xsd:boolean"?
standard-attributes>
standard-elements
( <htd:task>...</htd:task>
| <b4p:localTask>...</b4p:localTask>
| <b4p:remoteTask>...</b4p:remoteTask>
| <htd:notification>...</htd:notification>
| <b4p:localNotification>...</b4p:localNotification>
| <b4p:remoteNotification>...</b4p:remoteNotification>
)
<b4p:scheduledActions>? ...</b4p:scheduledActions>
<bpel:toParts>?
<bpel:toPart part="NCName" fromVariable="BPELVariableName" />+
</bpel:toParts>
<bpel:fromParts>?
<bpel:fromPart part="NCName"
toVariable="BPELVariableName" />+
</bpel:fromParts>
<b4p:attachmentPropagation fromProcess="all|none"
toProcess="all|newOnly|none" />?
</b4p:peopleActivity>
</bpel:extensionActivity>
The <b4p:peopleActivity>
element is enclosed in the BPEL extensionActivity
and has the following attributes and elements:
- inputVariable: This
attribute refers to a process variable which is used as input of the WSDL
operation of a task or notification. The process variable in the
BPEL4People Definition MUST have a WSDL message type. This attribute is
optional. If this attribute is not present the <bpel:toParts> element MUST be used.
- outputVariable: This
attribute refers to a process variable which is used as output of the WSDL
operation of a task. The process variable in the BPEL4People Definition
MUST have a WSDL message type. This attribute is optional. If the people
activity uses a human task and this attribute is not present the <bpel:fromParts> element MUST be used.
The outputVariable attribute MUST NOT
be used if the people activity uses a notification.
- isSkipable: This
attribute indicates whether the task associated with the activity can be
skipped at runtime or not. This is propagated to the task level. This
attribute is optional. The default for this attribute is “no”.
- dontShareComments: This
attribute, if set to “true”, indicates
that comments that are added to the task associated with this people
activity MUST NOT be propagated to any other task.
- standard-attributes:
The activity makes available all BPEL’s standard attributes.
- standard-elements: The
activity makes available all BPEL’s standard elements.
- htd:task: This element
is used to define an inline task within the people activity
(constellation 1 in the figure above). This element is optional. Its
syntax and semantics are introduced in section 4.3 “People Activities Using Local Human Tasks”.
- b4p:localTask: This
element is used to refer to a standalone task with no callable Web
service interface (constellations 2 or 3). This element is optional. Its
syntax and semantics are introduced in section 4.3 “People Activities Using Local Human Tasks”
- b4p:remoteTask: This
element is used to refer to a standalone task offering callable Web
service interface (constellation 4). This element is optional. Its syntax
and semantics are introduced in section 4.5 “People Activities Using
Remote Human Tasks”.
- htd:notification: This
element is used to define an inline notification within the people
activity (constellation 1 in the figure above). This element is optional.
Its semantics is introduced in section 4.4 “People Activities Using Local
Notifications”.
- b4p:localNotification:
This element is used to refer to a standalone notification with no
callable Web service interface (constellations 2 or 3). This element is
optional. Its semantics is introduced in section 4.4 “People Activities Using Local Notifications”.
- b4p:remoteNotification:
This element is used to refer to a standalone notification offering
callable Web service interface (constellation 4). This element is optional.
Its syntax and semantics are introduced in section 4.6 “People Activities Using Remote Notifications”.
- b4p:scheduledActions:
This element specifies when the task changes its state. Its syntax and
semantics are introduced in section 4.7 “Elements for Scheduled Actions”.
- bpel:toParts: This
element is used to explicitly create multi-part WSDL message from multiple
BPEL variables. The element is optional. Its syntax and semantics are
introduced in the WS-BPEL 2.0 specification, section 10.3.1. The <bpel:toParts> element and the inputVariable attribute are mutually
exclusive.
- bpel:fromParts: This
element is used to assign values to multiple BPEL variables from an
incoming multi-part WSDL message. The element is optional. Its syntax and
semantics are introduced in the WS-BPEL 2.0 specification, section 10.3.1.
The <bpel:fromParts> element and
the outputVariable attribute are
mutually exclusive. This element MUST NOT be used in a BPEL4People
Definition if the people activity uses a notification.
- b4p:attachmentPropagation:
This element is used to describe the propagation behavior of ad-hoc
attachments to and from the people activity. On activation of the people
activity, either all ad-hoc attachments from the process are propagated to
the people activity, so they become available to the corresponding task,
or none. The fromProcess attribute is
used to specify this. On completion of a people activity, all ad-hoc
attachments are propagated to its process, or only newly created ones (but
not those that were modified), or none. The toProcess
attribute is used to specify this. The element is optional. The default
value for this element is that all attachments are propagated from the
process to the people activity and only new attachments are propagated
back to the process.
Certain properties of human tasks and notifications can be
specified on the process level as well as on local and remote task definitions
and notification definitions allowing the process to override the original
human task and notification definitions respectively. This increases the
potential for reuse of tasks and notifications. Overriding takes place upon invocation
of the Web service implemented by the human task (or notification) via the
advanced interaction protocol implemented by both the process and the task (or
notification).
The following elements can be overridden:
- people assignments
- priority
People assignments can be specified on remote and local
human tasks and notifications. As a consequence, the invoked task receives the
results of people queries performed by the business process on a per generic
human role base. The result will be of type tOrganizationalEntity.
The result needs to be understandable in the context of the task, i.e., the
user identifiers and groups need to a) follow the same scheme and b) there
exists a 1:1 relationship between the user identifiers and users. If a generic
human role is specified on both the business process and the task it calls then
the people assignment as determined by the process overrides what is specified
on the task. In other words, the generic human roles defined at the task level
provide the default. The same applies to people assignments on remote and local
notifications.
The task’s originator is set to the process stakeholder.
Priority of tasks and notifications can be specified on
remote and local human tasks and notifications. If specified, it overrides the
original priority of the human task (or notification).
Standard-overriding-elements is used in the syntax
below as a shortened form of the following list of elements:
<htd:priority expressionLanguage="anyURI"? >
integer-expression
</htd:priority>
<htd:peopleAssignments>?
<htd:genericHumanRole>
<htd:from>...</htd:from>
</htd:genericHumanRole>
</htd:peopleAssignments>
People activities can be implemented using local human
tasks. A local human task is one of the following:
- An inline task declared within the people activity. The
task can be used only by that people activity
- An inline task declared within either the scope containing
the people activity or the process scope. In this case the task can be reused
as implementation of multiple people activities enclosed within the scope
containing the task declaration
- A standalone task identified using a QName. In this case
the task can be reused across multiple BPEL4People processes within the
same environment.
The syntax and semantics of people activity using local
tasks is given below.
<b4p:peopleActivity inputVariable="NCName"? outputVariable="NCName"?
isSkipable="xsd:boolean"? standard-attributes>
standard-elements
( <htd:task>...</htd:task>
| <b4p:localTask reference="QName">
standard-overriding-elements
</b4p:localTask>
)
</b4p:peopleActivity>
Properties
Element <htd:task>
is used to define an inline task within the people activity. The syntax and
semantics of the element are given in the WS-HumanTask specification. In
addition, XPath expressions used in enclosed elements MAY refer to process
variables. Enclosed elements MUST use the current value of the process
variable. Changes to process variables MUST NOT directly cause changes in
the execution of the enclosed elements, but only provide more current values
when the enclosed elements choose to re-evaluate the expressions.
Element <b4p:localTask>
is used to refer to a task enclosed in the BPEL4People process (a BPEL scope or
the process scope) or a standalone task provided by the same environment.
Attribute reference provides the QName of
the task. The attribute is mandatory. The element MAY contain standard
overriding elements explained in section 4.2 “Standard Overriding Elements”.
The following code shows a people activity declaring an
inline task.
<b4p:peopleActivity inputVariable="candidates"
outputVariable="vote"
isSkipable="yes">
<htd:task>
<htd:peopleAssignments>
<htd:potentialOwners>
<htd:from>$voters/users/user[i]</htd:from>
</htd:potentialOwners>
</htd:peopleAssignments>
</htd:task>
<b4p:scheduledActions>
<b4p:expiration>
<b4p:documentation xml:lang="en-US">
This people activity expires when not completed
within 2 days after having been activated.
</b4p:documentation>
<b4p:for>P2D</b4p:for>
</b4p:expiration>
</b4p:scheduledActions>
</b4p:peopleActivity>
The following code shows a people activity referring to an
inline task defined in the BPEL4People process.
<extensionActivity>
<b4p:peopleActivity name="firstApproval"
inputVariable="electionResult" outputVariable="decision">
<b4p:localTask reference="tns:approveEmployeeOfTheMonth"
/>
</b4p:peopleActivity>
</extensionActivity>
People activities can be implemented using local notifications.
A local notification is one of the following:
- An inline notification declared within the people
activity. The notification can be used only by that people activity
- An inline notification declared within either the scope
containing the people activity or the process scope. In this case the
notification can be reused as implementation of multiple people activities
enclosed within the scope containing the notification declaration
- A standalone notification identified using a QName. In
this case the notification can be reused across multiple BPEL4People
processes within the same environment.
The syntax and semantics of people activity using local
notifications is given below.
4.4.1 Syntax
<b4p:peopleActivity name="NCName"? inputVariable="NCName"?
standard-attributes>
standard-elements
( <htd:notification>...</htd:notification>
| <b4p:localNotification reference="QName">
standard-overriding-elements
</b4p:localNotification>
)
</b4p:peopleActivity>
Properties
Element <htd:notification>
is used to define an inline notification within the people activity. The syntax
and semantics of the element are given in the WS-HumanTask specification. In
addition, XPath expressions used in enclosed elements MAY refer to process
variables. Enclosed elements MUST use the current value of the process
variable. Changes to process variables MUST NOT directly cause changes in
the execution of the enclosed elements, but only provide more current values
when the enclosed elements choose to re-evaluate the expressions.
Element <b4p:localNotification>
is used to refer to a notification enclosed in the BPEL4People Definition (a
BPEL scope or the process scope) or a standalone notification provided by the
same environment. Attribute reference
provides the QName of the notification. The attribute is mandatory. The element
MAY contain standard overriding elements explained in section 4.2 “Standard Overriding Elements”.
The following code shows a people activity using a
standalone notification.
<bpel:extensionActivity>
<b4p:peopleActivity name="notifyEmployees"
inputVariable="electionResult">
<htd:localNotification reference="task:employeeBroadcast"/>
<!-- notification is not
defined as part of this document,
but within a separate
one
-->
</b4p:peopleActivity>
</bpel:extensionActivity>
People activities can be implemented using remote human
tasks. This variant has been referred to as constellation 4 in Figure 1. The
remote human task is invoked using a mechanism similar to the BPEL invoke
activity: Partner link and operation identify the human task based Web service
to be called. In addition to that, the name of a response operation on the myRole
of the partner link is specified, allowing the human task based Web service to
provide its result back to the calling business process.
Constellation 4 allows interoperability between BPEL4People
compliant business processes of one vendor, and WS-HumanTask compliant human
tasks of another vendor. For example, the communication to propagate state
changes between the business process and the remote human task happens in a
standardized way, as described in section 6 “Coordinating Standalone Human
Tasks”.
The remote human task can also define a priority element and
people assignments. The priority and people assignments specified here override
the original priority of the human task.
<b4p:remoteTask
partnerLink="NCName"
operation="NCName"
responseOperation="NCName"?>
standard-overriding-elements
</b4p:remoteTask>
The attribute responseOperation
(of type xsd:NCName) specifies the name of
the operation to be used to receive the response message from the remote human
task. The operation attribute refers to an
operation of the myRole port type of the
partner link associated with the <b4p:remoteTask>.
The attribute MUST be set in the BPEL4People Definition when the operation
attribute refers to a WSDL one-way operation. The attribute MUST NOT be set
when the operation attribute refers to a
WSDL request-response operation.
<bpel:extensionActivity>
<b4p:peopleActivity name="prepareInauguralSpeech"
inputVariable="electionResult"
outputVariable="speech"
isSkipable="no">
<b4p:remoteTask partnerLink="author"
operation="prepareSpeech"
responseOperation="receiveSpeech">
<htd:priority>0</htd:priority> <!-- assign highest priority -->
<htd:peopleAssignments>
<htd:potentialOwners>
<htd:from>$electionResult/winner</htd:from>
</htd:potentialOwners>
</htd:peopleAssignments>
</b4p:remoteTask>
</b4p:peopleActivity>
</bpel:extensionActivity>
A WS-HumanTask Processor MUST send a response message back
to its calling process. The endpoint to which the response is to be returned to
typically becomes known as late as when the human task is instantiated. This is
no problem in case the human task is invoked synchronously via a
request-response operation: a corresponding session between the calling process
and the human task will exist and the response message of the human task uses
this session.
But if the human task is called asynchronously via a one-way
operation, such a session does not exist when the response message is sent. In
this case, the BPEL4People Processor MUST pass the endpoint reference of the
port expecting the response message of the human task to the WS-HumanTask
Processor hosting the human task. Conceptually, this endpoint reference
overrides any deployment settings for the human task. Besides the address of
this port that endpoint reference MUST also specify additional metadata such
that the port receiving the response is able to understand that the incoming
message is in fact the response for an outstanding request (see [WS-HumanTask]
section 8.2 for the definition of the metadata). Finally, such an endpoint
reference MUST specify identifying data to allow the response message to be
targeted to the correct instance of the calling process.
The additional metadata MAY consist of the name of the port
type of the port as well as binding information about how to reach the port
(see [WS-Addr-Core]) in order to support the replying activity of the human
task to send its response to the port. In addition, the name of the receiving
operation at the calling process side is REQUIRED. This name MUST be provided
as value of the responseOperation
attribute of the <b4p:remoteTask>
element (discussed in the previous section) and is passed together with an
appropriate endpoint reference.
The above metadata represents the most generic solution
allowing the response to be returned in all situations supported by WSDL. A
simpler solution is supported in the case of the interaction between the
calling process and the human task being based on SOAP: In this case, the
metadata of the endpoint reference simply contains the value of the action
header to be set in the response message.
In both cases (a request-response <b4p:remoteTask> as well as a <b4p:remoteTask> using two
one-ways) the <b4p:remoteTask> activity
is blocking. That is, the normal processing of a <b4p:remoteTask>
activity does not end until a response message or fault message has been
received from the human task. If the human task experiences a non-recoverable
error, the WS-HumanTask Processor will signal that to the BPEL4People Processor
and an b4p:nonRecoverableError
fault MUST be raised in the parent process.
As described in the previous section, people activities can
also be implemented using remote notifications. This variant is also referred
to as constellation 4. Using remote notifications is very similar to
using remote human tasks. Except for the name of the element enclosed in the
people activity the main difference is that the remote notification is one-way
by nature, and thus does not allow the specification of a response operation.
Remote notifications, like remote human tasks allow
specifying properties that override the original properties of the notification
Web service. The mechanism used is the same as described above. Like remote
human tasks, remote notifications also allow overriding both people assignments
and priority.
<b4p:remoteNotification
partnerLink="NCName"
operation="NCName">
standard-overriding-elements
</b4p:remoteNotification>
<bpel:extensionActivity>
<b4p:peopleActivity name="notifyEmployees"
inputVariable="electionResult">
<b4p:remoteNotification partnerLink="employeeNotification"
operation="receiveElectionResult">
<htd:priority>5</htd:priority> <!-- assign moderate priority -->
<htd:peopleAssignments>
<htd:recipients>
<htd:from>$voters</htd:from>
</htd:recipients>
</htd:peopleAssignments>
</b4p:remoteNotification>
</b4p:peopleActivity>
</bpel:extensionActivity>
Scheduled actions allow the specification of determining
when a task needs to change its state. The following scheduled actions are
defined:
DeferActivation: Specifies the activation time of the
task. It is defined as either the period of time after which the task reaches
state Ready (in case of explicit claim) or state Reserved (in
case of implicit claim), or the point in time when the task reaches state Ready
or state Reserved. The default value is zero, i.e. the task is
immediately activated. If the activation time is defined as a point in time and
the task is created after that point in time then the BPEL4People Processor
MUST activate the task immediately.
Expiration: Specifies the expiration time of the task
when the task becomes obsolete. It is defined as either the period of time
after which the task expires or the point in time when the task expires. The
time starts to be measured when the task enters state Created. If the
task does not reach one of the final states (Completed, Failed, Error,
Exited, Obsolete) by the expiration time the BPEL4People Processor MUST
change the task state to Exited. Additional user-defined actions MUST
NOT be performed. The default value is infinity, i.e. the task never expires.
If the expiration time is defined as a point in time and the task is created
after that point in time the BPEL4People Processor MUST change the task state
to Exited. Note that deferred activation does not impact expiration.
Therefore the task MAY expire even before being activated.
Element <b4p:scheduledActions> is used to include the
definition of all scheduled actions within the task definition. If present, at
least one scheduled activity MUST be defined in the BPEL4People Definition.
Syntax:
<b4p:scheduledActions>?
<b4p:deferActivation>?
( <b4p:for expressionLanguage="anyURI"?>
duration-expression
</b4p:for>
| <b4p:until expressionLanguage="anyURI"?>
deadline-expression
</b4p:until>
)
</b4p:deferActivation>
<b4p:expiration>?
( <b4p:for expressionLanguage="anyURI"?>
duration-expression
</b4p:for>
| <b4p:until expressionLanguage="anyURI"?>
deadline-expression
</b4p:until>
)
</b4p:expiration>
</b4p:scheduledActions>
Properties
The <b4p:scheduledActions>
element has the following optional elements:
- b4p:deferActivation:
The element is used to specify activation time of the task. It includes
the following elements:
- b4p:for: The element
is an expression which specifies the period of time (duration) after
which the task reaches state Ready (in case of explicit claim) or
state Reserved (in case of implicit claim).The absolute time of
this transition is computed by adding the specified duration to the time
at which the people activity begins execution.
- b4p:until: The element
is an expression which specifies the point in time when the task reaches
state Ready or state Reserved.
Elements <b4p:for> and <b4p:until>
are mutually exclusive. There MUST be at least one <b4p:for>
or <b4p:until> element.
- b4p:expiration: The
element is used to specify the expiration time of the task when the task
becomes obsolete:
- b4p:for: The element
is an expression which specifies the period of time (duration) after
which the task expires. The absolute time of the expiration is computed
by adding the duration to the time at which the people activity begins
execution.
- b4p:until: The element
is an expression which specifies the point in time when the task expires.
Elements <b4p:for> and <b4p:until>
are mutually exclusive. There MUST be at least one <b4p:for>
or <b4p:until> element.
The language used in expressions is specified
using the expressionLanguage attribute. This attribute is optional. If not specified, the default
language as inherited from the closest enclosing element that specifies the
attribute is used.
If specified, the scheduledActions
element MUST NOT be empty, that is one of the elements b4p:deferActivation and b4p:expiration MUST be defined.
Example:
<b4p:scheduledActions>
<b4p:deferActivation>
<b4p:documentation xml:lang="en-US">
Activation of this task is
deferred until the time specified
in its input data.
</b4p:documentation>
<b4p:until>htd:getInput()/activateAt</b4p:until>
</b4p:deferActivation>
<b4p:expiration>
<b4p:documentation xml:lang="en-US">
This task expires when not
completed within 14 days after
having been activated.
</b4p:documentation>
<b4p:for>P14D</b4p:for>
</b4p:expiration>
</b4p:scheduledActions>
Figure 2 shows the different states of the people activity
and state transitions with associated triggers (events and conditions) and
actions to be performed when transitions take place.
Figure 2: State diagram of the people activity
When the process execution instantiates a people activity
this activity triggers the creation of a task in state Running. Upon
receiving a response from the task, the people activity completes successfully
and its state changes into the final state Completed.
If the task returns a fault, the people activity completes
unsuccessfully and moves to final state Failed and the fault is thrown
in the scope enclosing the people activity. If the task experiences a
non-recoverable error, the people activity completes unsuccessfully and the
standard fault nonRecoverableError is thrown
in the enclosing scope.
The people activity goes to final state Obsolete if
the task is skipped.
If the termination of the enclosed scope is triggered while
the people activity is still running, the people activity is terminated
prematurely and the associated running task is exited. A response for a
terminated people activity MUST be ignored by the BPEL4People Processor.
If the task expires, the people activity is terminated
prematurely and the associated task exits. In this case the standard fault b4p:taskExpired is thrown in the enclosing scope.
When the process exits the people activity will also be terminated and the
associated task is exited.
4.9
Task Instance Data
As defined by [WS-HumanTask], task instance data falls into
the categories presentation data, context data, and operational data. Human
tasks defined as part of a BPEL4People compliant business process have a
superset of the instance data defined in [WS-HumanTask].
The presentation data of tasks defined as part of a
BPEL4People compliant business process is equivalent to that of a standalone
human task.
Tasks defined as part of a BPEL4People business process not
only have access to the context data of the task, but also of the surrounding
business process. The process context includes
- Process state like variables and ad-hoc attachments
- Values for all generic human roles of the business
process, i.e. the process stakeholders, the business administrators of the
process, and the process initiator
- Values for all generic human roles of human tasks running
within the same business process
The operational data of tasks that is defined as part of a
BPEL4People compliant business process is equivalent to that of a standalone
human task.
This section introduces XPath extension functions that are
provided to be used within the definition of a BPEL4People business process to
access process context. Definition of these XPath extension functions is
provided in the table below. Input parameters that specify peopleActivity name
MUST be literal strings. This restriction does not apply to other parameters.
Because XPath 1.0 functions do not support returning faults, an empty node set
is returned in the event of an error.
|
Operation Name
|
Description
|
Parameters
|
|
getProcessStakeholders
|
Returns the stakeholders of the process. It MUST return an
empty htt:organizationalEntity
in case of an error.
|
Out
- organizational entity (htt:organizationalEntity)
|
|
getBusinessAdministrators
|
Returns the business administrators of the process. It
MUST return an empty htt:organizationalEntity
in case of an error.
|
Out
- organizational entity (htt:organizationalEntity)
|
|
getProcessInitiator
|
Returns the initiator of the process. It MUST return an
empty htt:tUser in case of an
error.
|
Out
- the process initiator (htt:tUser)
|
|
getLogicalPeopleGroup
|
Returns the value of a logical people group. It MUST
return an empty htt:organizationalEntity
in case of an error.
|
In
- name of the logical people group (xsd:string)
·
The optional parameters that follow MUST appear in pairs. Each
pair is defined as:
- the qualified name of a logical people group parameter
- the value for the named logical people group parameter; it can
be an XPath expression
Out
- the value of the logical people group (htt:organizationalEntity)
|
|
getActualOwner
|
Returns the actual owner of the task associated with the
people activity. It MUST return an empty htt:tUser
in case of an error.
|
In
- people activity name (xsd:string)
Out
- the actual owner (htt:tUser)
|
|
getTaskInitiator
|
Returns the initiator of the task. Evaluates to an empty
htt:user in case there is no initiator. It MUST return an empty htt:tUser in case of an error.
|
In
- people activity name (xsd:string)
Out
- the task initiator
(user id as htt:user)
|
|
getTaskStakeholders
|
Returns the stakeholders of the task.
It MUST evaluate to an empty htt:organizationalEntity in case of an error.
|
In
- people activity name (xsd:string)
Out
- task stakeholders (htt:organizationalEntity)
|
|
getPotentialOwners
|
Returns the potential owners of the task associated with
the people activity. It MUST return an empty htt:organizationalEntity
in case of an error.
|
In
- people activity name (xsd:string)
Out
- potential owners (htt:organizationalEntity)
|
|
getAdministrators
|
Returns the administrators of the task associated with the
people activity. It MUST return an empty htt:organizationalEntity
in case of an error.
|
In
- people activity name (xsd:string)
Out
- business administrators (htt:organizationalEntity)
|
|
getTaskPriority
|
Returns the priority of the task associated with the
people activity. It MUST evaluate to "5" in case the priority is
not explicitly set.
|
In
- people activity name (xsd:string)
Out
|
|
getOutcome
|
Returns the task outcome of the task associated with the
people activity
|
In
- people activity name (xsd:string)
Out
- the task outcome (xsd:string)-
if the outcome is not present, the empty nodeset MUST be returned.
|
|
getState
|
Returns the state of the people activity
|
In
- people activity name
(xsd:string)
Out
- the people activity state (xsd:string - see 4.8 People Activity Behavior and
State Transitions)
|
XPath functions accessing data of a human task only
guarantee to return data once the corresponding task has reached a final state.
Using the WS-HT coordination protocol introduced by [WS-HumanTask] (see
section 7 “Interoperable Protocol for Advanced Interaction with Human
Tasks” for more details) to control the autonomy and life cycle of human
tasks, a BPEL process with a people activity can act as the parent application
for remote human tasks.
Figure 3 shows some message exchanges between a BPEL process
containing a people activity to perform a task (e.g. risk assessment)
implemented by a remote human. The behavior of the people activity is the same
as for a people activity with an inline human task. That behavior is achieved
by coordinating the remote human task via the WS-HT coordination protocol.
The BPEL4People Processor people activity MUST support the
following behavior and the protocol messages exchanged with a standalone task.
A summary is provided in the table below.
- When the process execution reaches a people activity and
determines that this activity can be executed, the BPEL4People Processor
MUST create a WS-HT coordination context associated with the activity.
This context is sent together with the request message to the appropriate
service associated with the task. In addition, overriding attributes from
the people activity, namely priority, people assignments, the skipable
indicator and the task’s expiration time, are sent. Also the BPEL4People
Processor MAY propagate ad-hoc attachments from the process. All this
information is sent as part of the header fields of the requesting
message. These header fields as well as a corresponding mapping to SOAP
headers are discussed in [WS-HumanTask].
- When a response message is received from the task that indicates
the successful completion of the task, the people activity completes. This
response MAY include all new ad-hoc attachments from the human task.
- When a response message is received from the task that
indicates a fault of the task, the people activity faults. The fault MUST
be thrown in the scope of the people activity.
- When protocol message fault is received, the fault
nonRecoverableError MUST be thrown in the scope enclosing the people
activity.
- When protocol message skipped is received, the people
activity MUST move to state Obsolete.
- If the task does not reach one of the final states by the
expiration deadline, the people activity MUST be terminated. Protocol
message exit is sent to the task.
- When the people activity is terminated, protocol message
exit MUST be sent to the task.
- When the process encounters an <exit> activity,
protocol message exit MUST be sent to the task.
The following table summarizes this behavior, the protocol
messages sent, and their direction, i.e., whether a message is sent from the
people activity to the task (“out” in the column titled Direction) or vice
versa (“in”).
|
Message
|
Direction
|
People activity behavior
|
|
application request with WS-HT coordination context (and
callback information)
|
Out
|
People activity reached
|
|
task response
|
In
|
People activity completes
|
|
task fault response
|
In
|
People activity faults
|
|
Fault
|
In
|
People activity faults with b4p:nonRecoverableError
|
|
Skipped
|
In
|
People activity is set to obsolete
|
|
Exit
|
Out
|
Expired time-out
|
|
Exit
|
Out
|
People activity terminated
|
|
Exit
|
Out
|
<exit> encountered in enclosing process
|
BPEL abstract processes are indicated by the namespace "http://docs.oasis-open.org/wsbpel/2.0/process/abstract".
All constructs defined in BPEL4People extension namespaces MAY appear in
abstract processes.
Opaque tokens defined in BPEL (activities, expressions,
attributes and from-specs) MAY be used in BPEL4People extension constructs. The
syntactic validity constraints of BPEL MUST apply in the same way to an
Executable Completion of an abstract process containing BPEL4People extensions.
BPEL4people does not change the way opaque activities can be
replaced by an executable activity in an executable completion of an abstract
process, that is, an <abstract:opaqueActivity>
MAY also serve as a placeholder for a <bpel:extensionActivity>
containing a <b4p:peopleActivity>.
Any expression introduced by BPEL4People MAY be made opaque.
In particular, the following expressions MAY have the opaque="yes" attribute:
<htd:argument name="NCName" expressionLanguage="anyURI"? opaque="yes" />
<htd:priority expressionLanguage="anyURI"
opaque="yes" />
<b4p:for expressionLanguage="anyURI"? opaque="yes"
/>
<b4p:until expressionLanguage="anyURI"? opaque="yes"
/>
Any attribute introduced by BPEL4People MAY have an opaque
value "##opaque" in an abstract
process.
In BPEL, any from-spec in an executable process can be
replaced by an opaque from-spec <opaqueFrom/>
in an abstract process. This already includes any BPEL from-spec extended with
the BPEL4People b4p:logicalPeopleGroup="NCName"
attribute. In addition, the extension from-spec <htd:from>
MAY also be replaced by an opaque from-spec in an abstract process.
In BPEL, omittable tokens are all attributes, activities,
expressions and from-specs which are both (1) syntactically required by the
Executable BPEL XML Schema, and (2) have no default value. This rule also
applies to BPEL4People extensions in abstract processes. For example, <b4p:localTask reference="##opaque">
is equivalent to <b4p:localTask>.
The Abstract Process Profile for Observable Behavior,
indicated by the process attribute abstractProcessProfile="http://docs.oasis-open.org/wsbpel/2.0/process/abstract/ap11/2006/08",
provides a means to create precise and predictable descriptions of observable
behavior of the service(s) provided by an executable process.
The main application of this profile is the definition of
business process contracts; that is, the behavior followed by one business
partner in the context of Web services exchanges. A valid completion has to
follow the same interactions as the abstract process, with the partners that are
specified by the abstract process. The executable process can, however, perform
additional interaction steps relating to other partners. Likewise, the
executable process can perform additional human interactions. Beyond the
restrictions defined in WS-BPEL 2.0, the use of opacity is not restricted in
any way for elements and attributes introduced by BPEL4People.
7.3 Abstract Process Profile for Templates
The Abstract Process Profile for Templates, indicated by the
process attribute abstractProcessProfile="http://docs.oasis-open.org/wsbpel/2.0/process/abstract/simple-template/2006/08",
allows the definition of Abstract Processes which hide almost any arbitrary
execution details and have explicit opaque extension points for adding
behavior.
This profile does not allow the use of omission shortcuts
but the use of opacity is not restricted in any way. For abstract processes
belonging to this profile, this rule is extended to the elements and attributes
introduced by BPEL4People.
The XML schema pointed to by the RDDL document at the
namespace URI, defined by this specification, are considered to be
authoritative and take precedence over the XML schema defined in the appendix
of this document.
There are four conformance targets defined as part of this specification:
a BPEL4People Definition, a BPEL4People Processor, a WS-HumanTask Definition
and a WS-HumanTask Processor (see section 2.3). In order to claim conformance
with BPEL4People 1.1, the conformance targets MUST comply with all normative
statements in the BPEL4People and the WS-HumanTask specification, notably all
MUST statements have to be implemented.
The following list specifies the standard faults defined
within the BPEL4People specification. All standard fault 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.
|
The following section illustrates the portability and
interoperability aspects of the various usage constellations of BPEL4People
with WS-HumanTask as described in Figure 1:
Portability - The ability to take design-time artifacts
created in one vendor's environment and use them in another vendor's
environment. Constellations one and
two provide portability of BPEL4People processes with embedded human
interactions in. Constellations three and four provide portability of
BPEL4People processes with referenced human interactions.
Interoperability - The capability for multiple components
(process engine, task engine and task list client) to interact using
well-defined messages and protocols. This enables to combine components from
different vendors allowing seamless execution.
Constellation four achieves interoperability between process and tasks from
different vendor implementations.
Constellation 1
Task definitions are defined inline of the people
activities. Usage in this manner is typically for self-contained people
activities, whose tasks definitions are not intended to be reused elsewhere in
the process or across multiple processes. This format will also provide
scoping of the task definition since it will not be visible or accessible
outside the people activity in which it is contained. Portability for this
constellation requires support of both WS-HumanTask and BPEL4People artifacts
using the inline task definition format. Since the process and task
interactions are combined in one component, interoperability requirements are
limited to those between the task list client and the infrastructure.
Constellation 2
Similar to constellation 1, but tasks are defined at the
process level. This allows task definitions to be referenced from within
people activities enabling task reuse. Portability for this constellation
requires support of both WS-HumanTask and BPEL4People artifacts using the
process level scoped task definition format. Since the process and task
interactions are combined in one component, interoperability requirements are
limited to those between the task list client and the infrastructure.
Constellation 3
In this constellation, the task and people activity
definitions are defined as separate artifacts and execute in different
infrastructure components but provided by the same vendor. Portability for
this constellation requires support of both WS-HumanTask and BPEL4People as
separate artifacts. Since the process and task components are implemented by
the same vendor, interoperability requirements are limited to those between the
task list client and the infrastructure.
Constellation 4
Identical to constellation 3 in terms of the task and people
activity definitions, but in this case the process and task infrastructure are
provided by different vendors. Portability for this constellation requires
support of both WS-HumanTask and BPEL4People as separate artifacts.
Interoperability between task and process infrastructures from different
vendors is achieved using the WS-HumanTask coordination protocol.
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) OASIS Open 2009. All Rights Reserved.
-->
<xsd:schema
targetNamespace="http://docs.oasis-open.org/ns/bpel4people/bpel4people/200803"
xmlns="http://docs.oasis-open.org/ns/bpel4people/bpel4people/200803"
xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:htd="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/200803"
elementFormDefault="qualified"
blockDefault="#all">
<xsd:annotation>
<xsd:documentation>
XML Schema for BPEL4People 1.1 - WS-BPEL 2.0 Extension for
Human Task Interactions
</xsd:documentation>
</xsd:annotation>
<!-- other namespaces -->
<xsd:import
namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd" />
<xsd:import namespace="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/200803"
schemaLocation="ws-humantask.xsd" />
<xsd:import
namespace="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
schemaLocation="http://docs.oasis-open.org/wsbpel/2.0/OS/process/executable/ws-bpel_executable.xsd"
/>
<!-- base types for
extensible elements -->
<xsd:complexType name="tExtensibleElements">
<xsd:sequence>
<xsd:element
name="documentation" type="tDocumentation"
minOccurs="0" maxOccurs="unbounded"
/>
<xsd:any namespace="##other"
processContents="lax" minOccurs="0"
maxOccurs="unbounded" />
</xsd:sequence>
<xsd:anyAttribute
namespace="##other" processContents="lax"
/>
</xsd:complexType>
<xsd:complexType
name="tExtensibleMixedNamespaceElements">
<xsd:sequence>
<xsd:element name="documentation"
type="tDocumentation"
minOccurs="0" maxOccurs="unbounded"
/>
<xsd:element name="extensions"
type="tExtensions" minOccurs="0" />
</xsd:sequence>
<xsd:anyAttribute namespace="##other"
processContents="lax" />
</xsd:complexType>
<xsd:complexType name="tDocumentation"
mixed="true">
<xsd:sequence>
<xsd:any
namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute
ref="xml:lang" />
</xsd:complexType>
<xsd:complexType
name="tExtensions">
<xsd:sequence>
<xsd:any
namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
<!-- element "humanInteractions" to be used within
"bpel:process" -->
<xsd:element
name="humanInteractions" type="tHumanInteractions" />
<xsd:complexType
name="tHumanInteractions">
<xsd:complexContent>
<xsd:extension
base="tExtensibleMixedNamespaceElements">
<xsd:sequence>
<xsd:element
ref="htd:logicalPeopleGroups" minOccurs="0" />
<xsd:element
ref="htd:tasks" minOccurs="0"
/>
<xsd:element
ref="htd:notifications" minOccurs="0" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!-- element "peopleAssignments" to be used within
"bpel:process" -->
<xsd:element
name="peopleAssignments" type="tPeopleAssignments" />
<xsd:complexType
name="tPeopleAssignments">
<xsd:complexContent>
<xsd:extension
base="tExtensibleElements">
<xsd:sequence>
<xsd:element
ref="genericHumanRole" minOccurs="1" maxOccurs="unbounded"
/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!-- element "genericHumanRole" within BPEL4People
-->
<xsd:element
name="genericHumanRole" type="htd:tGenericHumanRoleAssignmentBase"
abstract="true" block=""/>
<xsd:element
name="processStakeholders" type="htd:tGenericHumanRoleAssignment" substitutionGroup="genericHumanRole"/>
<xsd:element
name="businessAdministrators" type="htd:tGenericHumanRoleAssignment" substitutionGroup="genericHumanRole"/>
<xsd:element
name="processInitiator" type="htd:tGenericHumanRoleAssignment" substitutionGroup="genericHumanRole"/>
<!-- element "argument" to be used within
"bpel:from" -->
<xsd:element
name="argument" type="tArgument"
/>
<xsd:complexType
name="tArgument">
<xsd:complexContent>
<xsd:extension
base="bpel:tExpression">
<xsd:attribute
name="name" type="xsd:NCName"
/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!-- attribute "logicalPeopleGroup" to be used
within "bpel:from" and "bpel:to" -->
<xsd:attribute
name="logicalPeopleGroup" type="xsd:NCName" />
<!-- attribute "shareComments" to be used within
"bpel:process" and "bpel:scope" -->
<xsd:attribute
name="shareComments" type="xsd:boolean" />
<!-- element "peopleActivity" to be used within
"bpel:extensionActivity" -->
<xsd:element
name="peopleActivity" type="tPeopleActivity" />
<xsd:complexType
name="tPeopleActivity">
<xsd:complexContent>
<xsd:extension
base="tExtensibleMixedNamespaceElements">
<xsd:sequence>
<xsd:element
ref="bpel:targets" minOccurs="0" />
<xsd:element
ref="bpel:sources" minOccurs="0" />
<xsd:choice>
<xsd:element
ref="htd:task" />
<xsd:element
ref="localTask" />
<xsd:element
ref="remoteTask" />
<xsd:element
ref="htd:notification" />
<xsd:element
ref="localNotification" />
<xsd:element
ref="remoteNotification" />
</xsd:choice>
<xsd:element
ref="scheduledActions" minOccurs="0" />
<xsd:element
ref="toParts" minOccurs="0"
/>
<xsd:element
ref="fromParts" minOccurs="0"
/>
<xsd:element
ref="attachmentPropagation" minOccurs="0" />
<xsd:any
namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"
/>
</xsd:sequence>
<xsd:attribute
name="name" type="xsd:NCName"
/>
<xsd:attribute
name="suppressJoinFailure" type="tBoolean"
use="optional" />
<xsd:attribute
name="inputVariable" type="xsd:QName" />
<xsd:attribute
name="outputVariable" type="xsd:QName" />
<xsd:attribute
name="isSkipable" type="tBoolean"
use="optional" default="no"
/>
<xsd:attribute
name="dontShareComments" type="tBoolean"
use="optional" default="no"
/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType
name="tOverridableTaskElements">
<xsd:complexContent>
<xsd:extension
base="tExtensibleMixedNamespaceElements">
<xsd:sequence>
<xsd:element
ref="htd:priority" minOccurs="0" />
<xsd:element
ref="htd:peopleAssignments" minOccurs="0" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
name="localTask" type="tLocalTask"
/>
<xsd:complexType
name="tLocalTask">
<xsd:complexContent>
<xsd:extension
base="tOverridableTaskElements">
<xsd:attribute
name="reference" type="xsd:QName"
use="required" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
name="remoteTask" type="tRemoteTask" />
<xsd:complexType
name="tRemoteTask">
<xsd:complexContent>
<xsd:extension
base="tOverridableTaskElements">
<xsd:attribute
name="partnerLink" type="xsd:NCName"
use="required" />
<xsd:attribute
name="operation" type="xsd:NCName"
use="required" />
<xsd:attribute
name="responseOperation" type="xsd:NCName" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType
name="tOverridableNotificationElements">
<xsd:complexContent>
<xsd:extension
base="tExtensibleMixedNamespaceElements">
<xsd:sequence>
<xsd:element
ref="htd:priority" minOccurs="0" />
<xsd:element
ref="htd:peopleAssignments" minOccurs="0" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
name="localNotification" type="tLocalNotification" />
<xsd:complexType
name="tLocalNotification">
<xsd:complexContent>
<xsd:extension
base="tOverridableNotificationElements">
<xsd:attribute
name="reference" type="xsd:QName"
use="required" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
name="remoteNotification" type="tRemoteNotification" />
<xsd:complexType
name="tRemoteNotification">
<xsd:complexContent>
<xsd:extension
base="tOverridableNotificationElements">
<xsd:attribute
name="partnerLink" type="xsd:NCName"
use="required" />
<xsd:attribute
name="operation" type="xsd:NCName"
use="required" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
name="scheduledActions" type="tScheduledActions" />
<xsd:complexType
name="tScheduledActions">
<xsd:complexContent>
<xsd:extension
base="tExtensibleElements">
<xsd:sequence>
<xsd:element
name="deferActivation"
type="tScheduledActionsDetails" minOccurs="0" />
<xsd:element
name="expiration"
type="tScheduledActionsDetails" minOccurs="0" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType
name="tScheduledActionsDetails">
<xsd:complexContent>
<xsd:extension
base="tExtensibleElements">
<xsd:sequence>
<xsd:choice>
<xsd:element
name="for" type="bpel:tDuration-expr"
/>
<xsd:element
name="until" type="bpel:tDeadline-expr"
/>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
name="fromParts" type="tFromParts"
/>
<xsd:complexType
name="tFromParts">
<xsd:complexContent>
<xsd:extension
base="tExtensibleElements">
<xsd:sequence>
<xsd:element
ref="fromPart" maxOccurs="unbounded"
/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
name="fromPart" type="tFromPart"
/>
<xsd:complexType
name="tFromPart">
<xsd:complexContent>
<xsd:extension
base="tExtensibleElements">
<xsd:attribute
name="part" type="xsd:NCName"
use="required" />
<xsd:attribute
name="toVariable" type="bpel:BPELVariableName"
use="required" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
name="toParts" type="tToParts"
/>
<xsd:complexType
name="tToParts">
<xsd:complexContent>
<xsd:extension
base="tExtensibleElements">
<xsd:sequence>
<xsd:element
ref="toPart" maxOccurs="unbounded"
/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
name="toPart" type="tToPart"
/>
<xsd:complexType
name="tToPart">
<xsd:complexContent>
<xsd:extension
base="tExtensibleElements">
<xsd:attribute
name="part" type="xsd:NCName"
use="required" />
<xsd:attribute
name="fromVariable"
type="bpel:BPELVariableName" use="required" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element
name="attachmentPropagation"
type="tAttachmentPropagation" />
<xsd:complexType
name="tAttachmentPropagation">
<xsd:complexContent>
<xsd:extension
base="tExtensibleElements">
<xsd:attribute
name="fromProcess" type="tFromProcess"
default="all" />
<xsd:attribute
name="toProcess" type="tToProcess"
default="newOnly" />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:simpleType
name="tFromProcess">
<xsd:restriction
base="xsd:string">
<xsd:enumeration
value="all" />
<xsd:enumeration
value="none" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType
name="tToProcess">
<xsd:restriction
base="xsd:string">
<xsd:enumeration
value="all" />
<xsd:enumeration
value="newOnly" />
<xsd:enumeration
value="none" />
</xsd:restriction>
</xsd:simpleType>
<!-- miscellaneous helper elements and types -->
<xsd:simpleType
name="tBoolean">
<xsd:restriction
base="xsd:string">
<xsd:enumeration
value="yes" />
<xsd:enumeration
value="no" />
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
This appendix contains a sample that outlines the basic
concepts of this specification. The sample process implements the election of
the “Employee of the month” in a fictious company. The structure of the
business process is shown in the figure below:
The process is started and as a first step, the people are
determined that qualify as voters for the “Employee of the month”. Next, all
the voters identified before get a chance to cast their votes. After that, the
election result is determined by counting the votes casted. After the result is
clear, two different people from the set of people entitled to approve the
election either accept or reject the voting result. In case any of the two
rejects, then there is no “Employee of the month” elected in the given month,
and the process ends. In case all approvals are obtained successfully, the
employees are notified about the outcome of the election, and a to-do is
created for the elected “Employee of the month” to prepare an inaugural speech.
Once this is completed, the process completes successfully.
The sections below show the definition of the BPEL process
implementing the “Employee of the month” process.
D.1 BPEL Definition
<?xml version="1.0"
encoding="UTF-8"?>
<!--
Copyright (c) OASIS Open 2009. All Rights Reserved.
-->
<process
name="EmployeeOfTheMonthProcess"
targetNamespace="http://www.example.com"
xmlns:tns="http://www.example.com"
xmlns:hr="http://www.example.com/approval"
xmlns:el="http://www.example.com/election"
xmlns:ty="http://www.example.com/types"
xmlns:ta="http://www.example.com/tasks"
xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns:b4p="http://docs.oasis-open.org/ns/bpel4people/bpel4people/200803"
xmlns:htd="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/200803"
xmlns:htt="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/types/200803"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://docs.oasis-open.org/ns/bpel4people/bpel4people/200803
../../xml/bpel4people.xsd
http://docs.oasis-open.org/ns/bpel4people/ws-humantask/200803
../../xml/ws-humantask.xsd
http://docs.oasis-open.org/ns/bpel4people/ws-humantask/types/200803
../../xml/ws-humantask-types.xsd">
<documentation>
Example for BPEL4People 1.1 - WS-BPEL 2.0 Process with
BPEL4People Extensions
</documentation>
<b4p:humanInteractions>
<htd:logicalPeopleGroups>
<htd:logicalPeopleGroup name="voters">
<htd:documentation
xml:lang="en-US">
The group
entitled to vote the employee of the month for the
given region.
</htd:documentation>
<htd:parameter
name="region" type="xsd:string"
/>
</htd:logicalPeopleGroup>
<htd:logicalPeopleGroup name="approvers">
<htd:documentation
xml:lang="en-US">
The group
entitled to approve the elected employee of the
month for the given region.
</htd:documentation>
<htd:parameter
name="region" type="xsd:string"
/>
</htd:logicalPeopleGroup>
<htd:logicalPeopleGroup name="employees">
<htd:documentation xml:lang="en-US">
The group of employees to be notified about the election
result of the employee of the month election for the
given
region.
</htd:documentation>
<htd:parameter
name="region" type="xsd:string"
/>
</htd:logicalPeopleGroup>
<htd:logicalPeopleGroup name="regionalElectionCommittee">
<htd:documentation xml:lang="en-US">
The group who is in charge for the election of the
employee of the month election for the given region.
</htd:documentation>
<htd:parameter
name="region" type="xsd:string"
/>
</htd:logicalPeopleGroup>
</htd:logicalPeopleGroups>
<htd:tasks>
<htd:task
name="approveEmployeeOfTheMonth">
<htd:documentation
xml:lang="en-US">
The
reusable definition of the task used to approve the
election of the employee of the month.
</htd:documentation>
<htd:interface
operation="approve" portType="hr:approvalPT"/>
<htd:peopleAssignments>
<htd:potentialOwners>
<htd:from
logicalPeopleGroup="approvers">
<!-- variables used here need to be defined on the
enclosing scope or above -->
<htd:argument
name="region">
$electionRequest/region
</htd:argument>
</htd:from>
</htd:potentialOwners>
</htd:peopleAssignments>
<htd:presentationElements/>
</htd:task>
</htd:tasks>
</b4p:humanInteractions>
<b4p:peopleAssignments>
<b4p:processStakeholders>
<htd:from
logicalPeopleGroup="regionalElectionCommittee">
<htd:argument
name="region">
$electionRequest/region
</htd:argument>
</htd:from>
</b4p:processStakeholders>
<b4p:businessAdministrators>
<htd:from>
<htd:literal>
<htt:organizationalEntity>
<htt:user>Peter</htt:user>
<htt:user>Paul</htt:user>
<htt:user>Mary</htt:user>
</htt:organizationalEntity>
</htd:literal>
</htd:from>
</b4p:businessAdministrators>
</b4p:peopleAssignments>
<extensions>
<extension
namespace="http://docs.oasis-open.org/ns/bpel4people/bpel4people/200803"
mustUnderstand="yes"/>
<extension
namespace="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/200803"
mustUnderstand="yes"/>
</extensions>
<import
importType="http://www.w3.org/2001/XMLSchema"
namespace="http://www.example.com/types"/>
<import
importType="http://www.example.org/WS-HT"
namespace="http://www.example.com/tasks"/>
<import
importType="http://schemas.xmlsoap.org/wsdl/"
namespace="http://www.example.com/election"
location="bpel4people-example-election.wsdl"/>
<import
importType="http://schemas.xmlsoap.org/wsdl/"
namespace="http://www.example.com/approval"
location="bpel4people-example-approval.wsdl"/>
<partnerLinks>
<partnerLink
partnerLinkType="electionPLT"
name="electionPL"/>
</partnerLinks>
<variables>
<variable
name="candidates" type="htt:users"/>
<variable
name="voters" type="htd:tOrganizationalEntity"/>
<variable
name="electionRequest" type="ty:electionRequestData"/>
<variable
name="electionResult" type="ty:electionResultData"/>
<variable
name="decision" type="xsd:boolean"/>
<variable
name="speech" type="ty:document"/>
</variables>
<sequence>
<receive
partnerLink="electionPL"
portType="el:electionPT"
operation="elect"
variable="electionRequest"
createInstance="yes"/>
<assign
name="getVoters">
<copy>
<from>$electionRequests/candidates</from>
<to variable="candidates"/>
</copy>
<copy>
<from b4p:logicalPeopleGroup="voters">
<b4p:argument
name="region">
$electionRequest/region
</b4p:argument>
</from>
<to variable="voters" />
</copy>
</assign>
<forEach
counterName="i" parallel="yes">
<startCounterValue> 1 </startCounterValue>
<finalCounterValue>
count($voters/users/user)
</finalCounterValue>
<scope>
<variables>
<variable
name="vote" type="htt:user"/>
</variables>
<sequence>
<!-- Constellation 1 -->
<extensionActivity>
<b4p:peopleActivity name="electEmployeeOfTheMonth"
inputVariable="candidates"
outputVariable="vote"
isSkipable="yes">
<htd:task
name="votingTask">
<htd:interface
operation="vote"
portType="el:votingPT"/>
<htd:peopleAssignments>
<htd:potentialOwners>
<htd:from>$voters/users/user[i]</htd:from>
</htd:potentialOwners>
</htd:peopleAssignments>
<htd:presentationElements/>
</htd:task>
<b4p:scheduledActions>
<b4p:expiration>
<b4p:documentation xml:lang="en-US">
This people activity expires when not completed
within 2 days after having been activated.
</b4p:documentation>
<b4p:for>P2D</b4p:for>
</b4p:expiration>
</b4p:scheduledActions>
</b4p:peopleActivity>
</extensionActivity>
<assign>
<copy>
<from>$vote</from>
<to>$electionResult/votes[i]</to>
</copy>
</assign>
</sequence>
</scope>
</forEach>
<!-- Might be Constellation 5 - standard WS-BPEL 2.0 invoke
-->
<!--
<invoke name="determineElectionResult"
partnerLink="..." operation="..." />
-->
<!-- Constellation 2 -->
<extensionActivity>
<b4p:peopleActivity name="firstApproval"
inputVariable="electionResult"
outputVariable="decision">
<b4p:localTask
reference="tns:approveEmployeeOfTheMonth"/>
</b4p:peopleActivity>
</extensionActivity>
<!-- Constellation 2 with override specifications -->
<extensionActivity>
<b4p:peopleActivity name="secondApproval"
inputVariable="electionResult"
outputVariable="decision">
<b4p:localTask
reference="tns:approveEmployeeOfTheMonth">
<htd:peopleAssignments>
<htd:excludedOwners>
<htd:from>
b4p:getActualOwner("tns:firstApproval")
</htd:from>
</htd:excludedOwners>
</htd:peopleAssignments>
</b4p:localTask>
</b4p:peopleActivity>
</extensionActivity>
<!-- Constellation 3 -->
<extensionActivity>
<b4p:peopleActivity name="notifyEmployees"
inputVariable="electionResult">
<b4p:localNotification reference="ta:employeeBroadcast"/>
<!-- notification is not defined as part of this document,
but within a separate one
-->
</b4p:peopleActivity>
</extensionActivity>
<!-- Constellation 4 -->
<extensionActivity>
<b4p:peopleActivity name="prepareInauguralSpeech"
inputVariable="electionResult"
outputVariable="speech"
isSkipable="no">
<b4p:remoteTask
partnerLink="author"
operation="prepareSpeech"
responseOperation="receiveSpeech">
<htd:priority>0</htd:priority> <!-- assign highest priority -->
<htd:peopleAssignments>
<htd:potentialOwners>
<htd:from>$electionResult/winner</htd:from>
</htd:potentialOwners>
</htd:peopleAssignments>
</b4p:remoteTask>
</b4p:peopleActivity>
</extensionActivity>
</sequence>
</process>
D.2 WSDL Definitions
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) OASIS Open 2009. All Rights Reserved.
-->
<wsdl:definitions
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://www.example.com/approval"
targetNamespace="http://www.example.com/approval">
<wsdl:documentation>
Example for BPEL4People 1.1 - PeopleActivity Interface
Definition
</wsdl:documentation>
<!-- Messages -->
<wsdl:message
name="approvalInput">
<wsdl:part
name="parameters" type="xsd:string" />
</wsdl:message>
<wsdl:message
name="approvalOutput">
<wsdl:part
name="parameters" type="xsd:string" />
</wsdl:message>
<!-- Port Type -->
<wsdl:portType
name="approvalPT">
<wsdl:operation
name="approve">
<wsdl:input
message="tns:approvalInput" />
<wsdl:output
message="tns:approvalOutput" />
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
<?xml version="1.0"
encoding="UTF-8"?>
<!--
Copyright (c) OASIS Open 2009. All Rights Reserved.
-->
<wsdl:definitions
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype"
xmlns:tns="http://www.example.com/election"
targetNamespace="http://www.example.com/election">
<wsdl:documentation>
Example for BPEL4People 1.1 - PeopleActivity Interface
Definition
</wsdl:documentation>
<!-- WS-BPEL 2.0 Partner Link Type -->
<plnk:partnerLinkType name="electionPLT">
<plnk:role
name="electionService" portType="tns:electionPT" />
</plnk:partnerLinkType>
<!-- Messages -->
<wsdl:message
name="electionInput">
<wsdl:part
name="parameters" type="xsd:string" />
</wsdl:message>
<wsdl:message
name="votingInput">
<wsdl:part
name="parameters" type="xsd:string" />
</wsdl:message>
<!-- Port Types -->
<wsdl:portType
name="electionPT">
<wsdl:operation
name="elect">
<wsdl:input
message="tns:electionInput" />
</wsdl:operation>
</wsdl:portType>
<wsdl:portType
name="votingPT">
<wsdl:operation
name="vote">
<wsdl:input
message="tns:votingInput" />
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
The following individuals have participated in the creation
of this specification and are gratefully acknowledged:
Members of the BPEL4People Technical Committee:
Phillip Allen, Microsoft
Corporation
Ashish Agrawal,
Adobe Systems
Mike Amend, BEA
Systems, Inc.
Stefan Baeuerle, SAP
AG
Charlton Barreto,
Adobe Systems
Justin Brunt, TIBCO
Software Inc.
Martin Chapman,
Oracle Corporation
Luc Clément, Active
Endpoints, Inc.
Manoj Das, Oracle
Corporation
Alireza Farhoush,
TIBCO Software Inc.
Mark Ford, Active
Endpoints, Inc.
Sabine Holz, SAP AG
Dave Ings, IBM
Gershon Janssen,
Individual
Diane Jordan, IBM
Anish Karmarkar,
Oracle Corporation
Ulrich Keil, SAP AG
Oliver Kieselbach,
SAP AG
Matthias Kloppmann,
IBM
Dieter König, IBM
Marita Kruempelmann,
SAP AG
Frank Leymann, IBM
Mark Little, Red
Hat
Alexander Malek, Microsoft
Corporation
Ashok Malhotra,
Oracle Corporation
Mike Marin, IBM
Vinkesh Mehta,
Deloitte Consulting LLP
Jeff Mischkinsky,
Oracle Corporation
Ralf Mueller,
Oracle Corporation
Krasimir Nedkov,
SAP AG
Benjamin Notheis,
SAP AG
Michael Pellegrini, Active
Endpoints, Inc.
Hannah Petereit, SAP
AG
Gerhard Pfau, IBM
Karsten Ploesser, SAP
AG
Ravi Rangaswamy,
Oracle Corporation
Alan Rickayzen, SAP
AG
Michael Rowley,
BEA Systems, Inc.
Ron Ten-Hove, Sun
Microsystems
Ivana Trickovic,
SAP AG
Alessandro Triglia,
OSS Nokalva
Claus von Riegen, SAP
AG
Peter Walker, Sun
Microsystems
Franz Weber, SAP AG
Prasad Yendluri,
Software AG, Inc.
BPEL4People 1.0 Specification Contributors:
Ashish Agrawal, Adobe
Mike Amend, BEA
Manoj Das, Oracle
Mark Ford, Active Endpoints
Chris Keller, Active Endpoints
Matthias Kloppmann, IBM
Dieter König, IBM
Frank Leymann, IBM
Ralf Müller, Oracle
Gerhard Pfau, IBM
Karsten Plösser, SAP
Ravi Rangaswamy,
Oracle
Alan Rickayzen, SAP
Michael Rowley, BEA
Patrick Schmidt, SAP
Ivana Trickovic, SAP
Alex Yiu, Oracle
Matthias Zeller,
Adobe
In addition, the following individuals have
provided valuable input into the design of this specification: Dave Ings, Diane
Jordan, Mohan Kamath, Ulrich Keil, Matthias Kruse, Kurt Lind, Jeff Mischkinsky,
Bhagat Nainani, Michael Pellegrini, Lars Rueter, Frank Ryan, David Shaffer,
Will Stallard, Cyrille Waguet, Franz Weber, and Eric Wittmann.
|
Revision
|
Date
|
Editor
|
Changes Made
|
|
WD-01
|
2008-03-12
|
Dieter König
|
First working draft created from submitted specification
|
|
WD-02
|
2008-03-13
|
Dieter König
|
Added specification editors
Moved WSDL and XSD into separate artifacts
|
|
WD-02
|
2008-06-25
|
Ivana Trickovic
|
Resolution of Issue #8 incorporated into the
document/section 5
|
|
WD-02
|
2008-06-28
|
Dieter König
|
Resolution of Issue #13 applied to complete document and
all separate XML artifacts
|
|
WD-02
|
2008-06-28
|
Dieter König
|
Resolution of Issue #21 applied to section 2
Resolution of Issue #22 applied to sections 2.4.1 and
3.1.1
|
|
WD-02
|
2008-07-06
|
Vinkesh Mehta
|
Resolution for Issue #3 applied to sections 2.4.1 (~line
353)
|
|
WD-02
|
2008-07-25
|
Krasimir Nedkov
|
Resolution for Issue #18 applied to sections 4.6.2 and 5;
Typos correction.
|
|
WD-02
|
2008-07-29
|
Ralf Mueller
|
Resolution for Issue #11 applied to section 3.1.2
|
|
WD-02
|
2008-07-29
|
Luc Clément
|
Resolution for Issue #10 applied to first paragraph of
section 3.3
|
|
CD-01-rev-1
|
2008-10-02
|
Ralf Mueller
|
Resolution for Issue #17 and #24 applied to section 2 and
5
|
|
CD-01-rev-2
|
2008-10-07
|
Michael Rowley
|
Resolution for Issue #2 applied in section 4.7, and for
issue #19 in sections 4.3.1 and 4.4.1.
|
|
CD-01-rev-3
|
2008-10-20
|
Dieter König
|
Resolution for Issue #23 applied to section 3.2.1
Resolution of Issue #6 applied to section 5
|
|
CD-01-rev-3
|
2008-10-20
|
Vinkesh Mehta
|
Resolution of issue-12, section 3.2.2, 4.2 font changed to
italics for htd:genericHumanRole. Also modified XML artifacts for
boel4people.xsd, humantask.xsd, humantask-context.xsd
|
|
CD-01-rev-3
|
2008-12-03
|
Ralf Mueller
|
Resolution for Issue #16 applied to sections 1 – 6
|
|
CD-01-rev-3
|
2008-12-12
|
Ravi Rangaswamy
|
Resolution for Issue #16 applied to sections 7 and
appendix B
|
|
CD-01-rev-3
|
2008-12-18
|
Ravi Rangaswamy
|
Resolution for Issue #16: Undid changes to appendix B
|
|
CD-01-rev-4
|
2008-12-19
|
Ralf Mueller
|
Incorporated review comments from Ivana and Luc for Issue
BP-16
|
|
CD-02
|
2009-01-18
|
Luc Clément
|
Committee Draft 2
|
|
CD-02-rev-1
|
2009-02-20
|
Dieter König
|
Issue 47: added getState() in section 5
Issue 48: abstract BPEL ns in 7.1.1
Issue 50, sections 3 and 5 (htd:ŕhtt:)
|
|
CD-02-rev-2
|
2009-03-11
|
Ralf Mueller
|
Issue 76: Changes for RFC2119
|
|
CD-03
|
2009-04-15
|
Luc Clément
|
Committee Draft 3
|
|
CD-03-rev-2
|
2009-04-29
|
Luc Clément
|
Issue 72: add WS-HumanTask and WS-HumanTask Processor
definitions to section 2.3
|
|
CD-03-rev3
|
2009-06-01
|
Luc Clément
|
Issue 65
|
|
CD-03-rev4
|
2009-06-02
|
Michael Rowley
|
Issue 38, 39
|
|
CD-04-rev0
|
2009-06-17
|
Luc Clément
|
Committee Draft 4
|
|
CD-04-rev1
|
2009-06-17
|
Luc Clément
|
Acknowledgement update
|
|
CD-04-rev2
|
2009-06-26
|
Dieter König
|
Formatting
|
|
CD-05-rev0
|
2009-07-15
|
Luc Clément
|
Committee Draft 5
|
|
CD-05-rev1
|
2009-08-08
|
Luc Clément
|
Editors update
|
|
CD-05-rev2
|
2009-09-28
|
Dieter König
|
Issue 125
|
|
CD-05-rev3
|
2009-10-22
|
Dieter König
|
Issue 129
XML artifacts copied back to appendix
|
|
CD-05-rev4
|
2009-11-01
|
Luc Clément
|
Issue 131
OASIS Spec QA Checklist updates
|
|
CD-06-rev0
|
2009-11-01
|
Luc Clément
|
Committee Draft 6
|
