|
|
|
In this example,
a WfProcess is created by an application implementing the
|
|
WfRequester
interface; an appropriate WfProcessMgr is identified and the WfProcess
|
|
is created using
the create_process operation on this process manager. The process
|
|
manager creates
a new WfProcess and returns a reference to the requester.
|
|
The requester
retrieves information about the signature of the process using the
|
|
get_context_info
and get_result_info operations on the process manager and uses the
|
|
information on
the structure of the process context to initialize the process context
|
|
using the
set_context operation on the WfProcess.
|
|
Next, the
requester initiates enactment of the process using the start operation of the
|
|
WfProcess; as a
result, the process determines the activities to be activated (in our
|
|
example it is
only one, there might be more), creates a WfActivity that represents the
|
|
first step in
the process and sets the context of that activity using the data that were
|
|
provided during
initialization of the process and potentially additional information.
|
|
In this
scenario, the WfActivity then establishes an association with a WfResource
that
|
|
can potentially
perform the work request represented by the activity. The association is
|
|
establish be
creating a WfAssignment which establishes an association with an
|
|
appropriate
resource using internal knowledge about resource selection. Note that it
|
|
could use, for
example, a resource selection WfProcess to perform this task; the
|
|
resource
selection mechanism is not subject of this specification. Note also that
instead
|
|
of assigning the
activity to a resource, the activity could also be realized by another
|
|
workflow process
which essentially performs the same operations that are performed
|
|
by the resource
in our scenario.
|
|
Next, the
process starts the activity and the potential assignment is changed into an
|
|
’actual’ one
because the resource decided to accept the assignment (and changed the
|
|
state of the
assignment accordingly).
|
|
Then, the
resource (or some application) performs the work request represented by the
|
|
activity,
returns the result to the activity and invokes the complete operation on the
|
|
activity to
signal that the task has been completed.
|
|
The activity
informs the process about the status change and passes the result on for
|
|
further
processing by the process. The process could use the information to determine
|
|
the next
activities to be activated; in our example, however, the process decides that
|
|
the work is done
and signals completion to its requester using the result of the activity
|
|
to determine the
overall process result.
|
|
The requester
receives the process completion notification and retrieves the process
|
|
result using the
get_result operation on the process.
|