Upload
bogdan-comsa
View
230
Download
0
Embed Size (px)
Citation preview
7/30/2019 WF Scenarios Guidance_ Human Workflow
1/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx
WF Scenarios Guidance: Human
Workflow35 out of 38 rated this helpful
May 2008
Michele Leroux Bustamante, IDesign
Zoiner Tejada, Hershey Technologies
Windows Workflow Foundation (WF or, Workflow) is Microsofts technology platform for building workflow-
enabled applications. The platform includes a set of tools for designing and managing workflows, a
programming model for implementing workflow logic, a rules engine, and a workflow runtime execution
engine. Workflow technology can be employed in a wide range of application scenarios the most common of
which are listed in Table 1.
: Common production application scenarios for Workflow
Scenario Description
SharePoint
2007 and
Workflow
SharePoint 2007 relies on Workflow technology for its packaged workflows, and for
custom workflows created with SharePoint Designer 2007 or Visual Studio 2008.
Human
Workflow
Workflow provides the underlying tools to support both human and system interaction
according to business rules.
Workflow and
WCF Services
Seamless integration between Workflow and WCF enables workflows to be exposed as
services and to coordinate calls to WCF services.
Coordinating
Presentation
Flow
Both Windows and web applications can leverage workflows to drive presentation flow.
Workflow
Designer Re-
Hosting
Applications can host the Workflow Designer to provide a fully customized design
experience for developers or business users.
This whitepaper summarizes the value proposition for scenarios that involve human workflow.
Workflow is particularly useful for coordinating business processes that involve people often referred to as
http://msdn.microsoft.com/en-us/library/cc835242.aspxhttp://msdn.microsoft.com/en-us/library/dd557867.aspxhttp://msdn.microsoft.com/en-us/library/cc825354.aspxhttp://msdn.microsoft.com/en-us/library/cc748597.aspxhttp://msdn.microsoft.com/en-us/library/cc748597.aspxhttp://msdn.microsoft.com/en-us/library/cc835242.aspxhttp://msdn.microsoft.com/en-us/library/dd557867.aspxhttp://msdn.microsoft.com/en-us/library/cc825354.aspxhttp://msdn.microsoft.com/en-us/library/cc748597.aspx7/30/2019 WF Scenarios Guidance_ Human Workflow
2/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 2
human workflowor people-driven processes. This type of workflow automates the interaction between people, as
well as between people and systems. In fact, this type of workflow encourages human participation. When
business users think of workflow, this is the type of automation to which they generally refer.
The hallmark of a human workflow is that it is designed to support long running processes with instance
lifecycles governed by the activity of human users that is measured in days, weeks or even months not
milliseconds. These human activities may be performed in other systems, or be physical activities independent
of any system that are confirmed by input. This implies that workflow execution must at some point pause until
an external event, usually triggered by some user interaction or system event, advances the workflow.
The primary goal of a human workflow is to automate business processes to minimize or eliminate the interval
spent waiting between human activities, and therefore increases productivity. A corollary of that goal is that
these workflows provide an auditable system that exposes detailed metrics that capture how efficiently the
process is functioning. Visibility into the current state and history of a process flow is critical. Stakeholders tend
to be interested in answering questions like:
Where is my document currently?
Who is holding it up?
How much longer will the process take?
What steps have yet to be done?
Workflow metrics are also useful to identify the most time consuming or resource expensive tasks so that
workflows can be further optimized to remove the bottlenecks.
There are many examples of human workflow that involve concepts such as routing, task assignment, approval
processes, escalation procedures and collaboration around documents or data but the following two
examples capture the essence of human workflow:
Document Review and Approval: This type of workflow defines the steps that a document (a vacation
request, for example) takes as it gets reviewed on its path to final approval, typically following a
company hierarchy. The document itself is usually not edited, but metadata around the document tracks
the individual decisions of all involved reviewers. As the review of the document might require the user
to perform out-of-band research (such as calling the originator for clarification) or might itself be an
involved process, the workflow must be capable of waiting efficiently for the user to respond. This
ultimately results in the need for the workflow to support bursty execution patterns (e.g., a user
approves, the business rules are applied, the document is routed and then the workflow goes back to
waiting) and long running processes.
Collaboration: This workflow is characterized by the joint efforts of multiple users reviewing andediting
a document (such as a user manual). In this scenario, the workflow is usually less rigidly structured with
regards to how the document is routed and focuses primarily on insuring that users are notified of work
assigned to them as quickly as possible so as to minimize delays between participants. Typically routing
is performed in an ad-hoc fashion, as one chooses the next user, instead of the system making the
choice automatically from business rules. Here the workflow waits while the user performs the time
consuming work on the document, and is activated when the user elects, for example, to route it to a
co-worker for additional edits.
The following sections will explore common architectural characteristics for human workflow, examine where
Workflow technology fits in, and elaborate on these scenarios to describe their implementation using
Workflow. These scenarios will also serve to illustrate key aspects of Workflow design that are specifically
7/30/2019 WF Scenarios Guidance_ Human Workflow
3/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 3
e p u or uman wor ow.
The requirements of a typical human workflow lend itself to a particular type of system architecture,
irrespective of the specific scenario implemented. This common architecture (illustrated in Figure 1) involves
three layers: a presentation layer for user interaction with task assignments and notifications; a system layer
which comprises any services, business logic, data and related functionality including any calls to external
applications; and workflow as the middle tier to coordinate between the two according to business processes
and rules. Within the middle tier, an interaction layer is typically provided to facilitate communications between
the workflow and the layers above and below it.
1: Human workflow architecture and Workflow
This section further describes this architecture , commonly used for human workflow systems.
Interaction with users commonly uses tasks or notifications.
Tasks are typically instructions to perform an activity. These activities can occur within the current
system, within another system, or it could be a physical activity that requires the user to confirm
7/30/2019 WF Scenarios Guidance_ Human Workflow
4/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 4
.
Notifications are confirmations or alerts that a workflow status change has occurred. Example of status
changes include completion of a task by another user or an alert that a submitted workflow has
completed (for example, an invoice was paid).
The user interfaces that participate in human workflow vary in their mode of presenting tasks and notifications
users. They are usually specific to system requirements, typically within an existing user application or
environment. In fact, it is common for multiple user interfaces to participate in a single workflow to present
tasks and notifications at different stages to different users. The user interface may even be an email
notification optionally with an attached document to review, a URL to visit, or a custom form that could beuseful in collecting feedback.
Possible technologies to implement user interfaces for human workflow include rich client applications built
upon Windows Forms or Windows Presentation Foundation (WPF), reach applications built upon ASP.NET web
sites, Microsoft Office add-ins, or applications built for mobile devices. For surfacing notifications, e-mail and
instant messaging can be useful. Rich-client applications are typically used for where customer experience is
paramount and an application is deployed within the firewall, but they could just as easily be extended for use
across the WAN or the Internet. Reach applications, such as ASP.NET web sites, are common, since they
minimize the deployment and configuration effort required to get individuals looped into the process. A
growing requirement for workflow systems is to support workflow participants on location to interact with the
system, which can be performed by applications deployed to Windows Mobile devices, allowing field staff tointeract with the system, completing tasks and receiving notifications even while out of the office.
The choice of client applications for the presentation layer is not limited to one type. A single solution may rely
on a heterogeneous mix of rich, reach, and mobile applications, supplemented with email notifications. Users
will naturally log in to user interfaces appropriate to their current activity and system role.
The Workflow Runtime is responsible for initializing workflows from workflow definitions, executing workflows
according to business rules and policies, persisting workflow state during idle time (for example, waiting for
user input), and tracking activities as they execute for audit trail of the workflow. These services are provided
by the runtime and have default implementations that rely on SQL Server for database storage althoughcustom implementations can be provided for alternate database platforms.
In this architecture, Workflow acts as the middle tier thus, at the heart of the architecture lives a managed
Windows process whose primary function is to host the Workflow Runtime and execute workflow instances. It is
also possible to host the Workflow Runtime within the client Windows Forms or WPF applications, to manage
such things as user presentation state, but Workflow is typically hosted on the server for human workflow
scenarios. Windows Server 2003 deployments typically host the Workflow runtime using Internet Information
Services (IIS) 6.0 or a Windows Service. For Windows Server 2008, developers can choose IIS 7.0 and the
Windows Activation Service (WAS), or a Windows Service.
The IIS and WAS combination provide a rich hosting environment with application pooling, health monitoring,idle-time management and a common set of configuration tools. More importantly, they supply message-
based activation so that requests are not rejected if the host process is not yet running (for example, after
updating configuration for the server). Windows Services, however, are also compelling because of their
deployment simplicity, even though they do not provide these other management features.
Workflow instances are managed by the Workflow Runtime in the middle tier. Communication between the
presentation and system layers to workflow instances must go through the runtime through some form of
interaction layer. Communication from presentation and system layers to workflow can be achieved through:
7/30/2019 WF Scenarios Guidance_ Human Workflow
5/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 5
Workflows exposing ASP.NET Web Service (ASMX) endpoints
Workflows responding to in-process events raised through Local Services
These options are illustrated in Figure 2.
2: Communication with workflow instances
The flow of communication can also go out of the workflow by similar means, and collectively orchestrate the
interaction between people and systems. Workflows can:
Call WCF or ASMX services using built-in activities to support it
Directly call methods on business objects through Local Services
These options are illustrated in Figure 3.
3: Making outgoing calls from a workflow instance
7/30/2019 WF Scenarios Guidance_ Human Workflow
6/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 6
Human workflow designs make heavy use of these event-driven communications and call-outs to the business
layer to facilitate bidirectional communication with the Workflow instance. Workflow Services are covered in a
separate document therefore the sections to follow will focus on the use of Local Services to handle this
communication explaining how to implement event-driven communication and external calls using the built-in
Workflow activities that support it and then explaining how custom activities can help to wrap some of the
initialization code required to interact with Local Services.
The archetypical pattern of human workflow is that a user or system will perform some action and in turn that
action will trigger an event to reactivate the persisted workflow so that it may resume and continue by
executing the logic implemented for event. In the workflow design this translates into using the following
activities:
ReceiveActivity: Used to execute a sequence in response to WCF service operations.
WebServiceInputActivity: Used to execute a sequence in response to web method calls to ASP.NET
Web Services (ASMX).
HandleExternalEventActivity: Used to listen for events ra ised by local services.
DelayActivity: Used to resume workflow execution after a period of time elapses.
The HandleExternalEventActivity is designed to listen for a specific event raised by a Local Service allowing
code to reactivate the workflow instance. Figure 4 illustrates this process. When a workflow instance reaches aHandleExternalEventActivity in a sequence, it will become idle, waiting for that event. This allows the Workflow
Runtime, when configured with a persistence service, to unload the workflow instance from memory and
conserve resources while waiting for the possibly long interval before a user or some other system
functionality triggers the event.
4: Local services interacting with the HandleExternalEventActivity
7/30/2019 WF Scenarios Guidance_ Human Workflow
7/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 7
By comparison, the DelayActivity will wait for a specified period, and when that period elapses the workflow is
activated and continues execution. This is particularly useful for implementing expiration times on user
interaction.
To support communications from a workflow instance to system functionality, Workflow provides several
activities:
SendActivity: Used to make calls to WCF services.
InvokeWebServiceActivity: Used to make calls to ASMX services.CallExternalMethodActivity: Used to call business logic through Local Services (see Figure 5).
When a workflow instance reaches one of these activities it executes the call to the external method or service
operation and waits synchronously for it to complete before continuing with the next activity. For in-process
calls, alongside the HandleExternalEventActivity, CallExternalMethodActivity rounds out the bi-directional
communication that is often required for human workflow.
5: Calling external methods from a workflow instance
7/30/2019 WF Scenarios Guidance_ Human Workflow
8/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 8
The requirements of a human workflow (long running workflows, event driven, bursty execution patterns,
visibility and audit-ability to business users) manifests itself in the design of the workflow definition. In particular
this influences the selection of built-in workflow activities, and the decision to create custom activities.
With respect to Local Services developers must wire up the Local Service interface for each
HandleExternalEventActivity or CallExternalMethodActivity. This process becomes repetitive very quickly as most
workflow-enabled systems will reuse the same event in many workflow definitions. The solution to this repetitive
process is to create a custom activity that is automatically bound to the correct event and can be dragged
directly from the Visual Studio Toolbox.
While it is possible to re-host the workflow designer in a custom application so that workflows can be
designed by business users outside of Visual Studio, creating workflow definitions and custom activities initially
requires programmer involvement. Developers can design custom activities in the workflow designer supplied
with Visual Studio 2008. In addition, Workflow provides the Workflow Communications Activity Generator
(wca.exe) that simplifies creating these custom activities from existing Local Service interface definitions.
Q. Can a workflow instance listen for multiple events in parallel?
Several Workflow activities can be used to listen for multiple events: ListenActivity, ParallelActivity,
ConditionedActivityGroup and ReplicatorActivity. In a sequential workflow, the ListenActivity allows one to
configure as many event handling sequences as desired. Each sequence begins with an event handling activity,
and the sequence associated with the first event to arrive is handled while the other sequences are canceled.
Figure 6 illustrates a ListenActivity configured to perform escalation waiting for an event to arrive for the left
sequence but if a certain amount of time passes, executes the sequence on the right instead. Alternately, a
ParallelActivity (Figure 7) is useful when multiple events are listened for and the activity should not complete
until all events are received. The ConditionedActivityGroup (Figure 8) supports more complex situations such as
waiting for the first two out of three events. In addition, if correlation is a requirement, the ReplicatorActivity
(Figure 9) can be used to listen for a dynamically determined set of events in parallel. Note that for a State
Machine workflow the EventDrivenActivity is the only out-of-the-box way to listen for events in parallel.
6: ListenActivity used for an escalation pattern
7/30/2019 WF Scenarios Guidance_ Human Workflow
9/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 9
Figure 7: ParallelActivity listening for two events
8: Conditioned activity listening for three events
9: Replicator activity
Q. Can a workflow instance use events to implement a cancellation pattern?
A cancellation pattern is a sequence of events that executes a main line sequence of activities until it is
interrupted by another event. Workflow supports the cancellation pattern using a combination of activities that
7/30/2019 WF Scenarios Guidance_ Human Workflow
10/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 10
includes an EventHandlingScopeActivity that defines one main sequence (usually containing a looping activity
such as While), and supports the addition of an unlimited number of EventDrivenActivity event handling
sequences that can be used to complete, cancel or reset the main sequence. Figure 10 illustrates an
EventHandlingScopeActivity configured to respond to three events, each of which might cause the main
sequence (not shown) to cancel or complete.
10: Implementing a cancellation pattern with EventHandlingScopeActivity
Q. Can state machine workflows listen for events?
The StateActivity of any state machine workflow can host one or more activities configured to listen for events.
In a state machine workflow, each EventDrivenActivity can handle a different event and thus allow a particular
state to listen for multiple events in parallel. Figure 11 illustrates a StateActivity that is configured for one event:
11: Receiving events to a StateActivity within a state machine workflow
The travel expense review and approval process shown in Figure 12 illustrates several concepts common tohuman workflow including: task assignment, notifications, approval, event-driven activities, and calls to external
systems. To elaborate many organizations have a formal, structured process that allows employees to submit
their receipts for expenses incurred on business travel and to receive re-imbursement for those expenses. In
this case, a traveler logs into a web site to fill out a travel expense form that describes the charges, attaches
scanned images of the receipts, and submits the package for processing. The submission of the travel expense
form initiates a workflow instance. The workflow coordinates review of the expense report with the appropriate
managers of the employee (as determined by the business rules encapsulated within the workflow definition)
and ultimately drives towards one of two goals. If the request is approved, a payment voucher is created in
Microsoft Dynamics to begin processing of payment and the traveler is notified of the approval via email. If the
request is denied, the traveler is notified via email of the denial.
7/30/2019 WF Scenarios Guidance_ Human Workflow
11/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 1
12: Travel expense review and approval process
Note that the system will likely provide other features such as:
The traveler can log into the web site to check on the status of any submitted expense reports.
Process owners can examine metrics on volume and throughput, allowing them to track any backlog,
review the response times of individual approvers and compute end to end processing times.
Process owners can also create reports on metrics such as the ration of approvals to rejections and can
explore the history of decisions made by individual approvers.
Some of these metrics can be collected with Workflow persistence and tracking services.
The workflow design for this travel expense review and approval process is illustrated in Figure 13. This
workflow employs event-driven activities for human interaction and escalation procedures; rules to evaluate
advancement of the workflow instance; calls to external systems and to send email notifications; and custom
activities where appropriate to encapsulate some of this behavior.
Workflow design for travel expense process
7/30/2019 WF Scenarios Guidance_ Human Workflow
12/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 12
The workflow starts by assigning the initial approver for the expense report (assignFirstApprover), and
subsequently waits to receive an approval (reviewed), or for the escalation process to be activated if there is
no approval for 10 days (escalateInTenDays). This results in assigning a supervisor to approve the report
(assignToSupervisor). When a review is received, a declarative business rule evaluates whether or not the
expense report requires further approval based on the existing approvals and dollar amount. If moreapprovals are required a new approver is assigned (assignApprover). If approved, a call is made to Microsoft
Dynamics (exportToDynamics) to have the expenses paid and an email notification is sent (sendApprovalEmail).
If denied, an email notification is sent indicating the denial (sendDenialEmail).
In terms of activities used to implement this workflow design, the following points are worth noting:
Assigning approvers, sending email, and calling external systems are all activities that require custom code to
interact with business logic. In this example, the assumption is that this business logic was previously
implemented in an assembly and that logic is reused when called in-process using Local Services. Thus, three
custom activities are used to encapsulate tedious coding effort and support reuse in this and other workflows.
7/30/2019 WF Scenarios Guidance_ Human Workflow
13/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 13
The escalation scenario is implemented by using a ListenActivity (review). The two children of this activity are
both event-driven activities. On the left side (waitForReview) a HandleExternalEvent activity (reviewed) is
configured to listen for the ExpenseReportReviewed event. On the right side (escalate) a Delay activity
(escalateInTenDays) is configured to wait for ten days.
A declarative business rule is configured to determine if more approvals are necessary. It is attached to the
outer while loop (whileNeedsApproval) to determine if the loop should continue, and attached to the if/else
condition after a review is received (ifNeedsMoreApproval) to determine if the new review has satisfied
business requirements.
Figure 14 illustrates the relevant workflow runtime services that are registered to support the travel expense
scenario. The rationale behind the choice of services is explored in this section.
14: Runtime services used by the travel expense process
Tracking Service: The SqlTrackingService is registered so that the traveler to can determine the current status
of his expense report submission. The tracking service will trace information about the workflow including this
status and the web site can query this information to present it to users in a friendly manner. For example, the
web site can ask for workflow level details such as whether or not the workflow is still in process or completed
or who is currently performing the review. For process owners the web site can present processing timemetrics for specific business activities; end-to-end processing time; response times of individual approvers;
history of decisions made by individual approvers; and the ratio of approvals to rejections.
Persistence Service: The SqlWorkflowPersistenceService is registered so that the workflow can be persisted
during idle time to conserve system resources, and to support load distribution and related scenarios. This is
particularly important with human workflow since they are long-running and have potentially unpredictable
lifecycles. This service can be configured to automatically persist workflow state during idle time to pursue an
aggressive memory management result by unloading the instance from memory. This means that workflows
are unloaded as soon as they begin waiting for a reviewers decision which for this scenario represents a
substantial portion of the workflow instances lifecycle and is likely measured in days.
7/30/2019 WF Scenarios Guidance_ Human Workflow
14/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 14
Scheduler Service: The ManualWorkflowSchedulerService is registered so that ASP.NET requests executing
workflow will start the workflow on the same thread. The assumption here is that the workflow will execute a
few activities synchronously and then go idle, thus releasing the thread without burdening the system. If the
workflow does not go idle within such short timespans it is better to register the
DefaultWorkflowSchedulerService which means that workflow initialization is performed on a new thread and
releases the ASP.NET thread running asynchronously.
Local Services: Since this example illustrates communication between the application and workflow in-process,
Local Services must be defined to facilitate that communication. In order for an event-driven activity to becalled from a client application, the client must be able to raise that event to the workflow runtime. The runtime
is then able to initialize the workflow and raise the event to the workflow instance (see Figure 15).
15: Communication from ASP.NET page to workflow instance
A simple architectural design for the travel expense scenario (from Figure 12) is illustrated in Figure 16.
16: Single-tier logical architecture for travel expense process
7/30/2019 WF Scenarios Guidance_ Human Workflow
15/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 15
This architecture assumes a single tier deployment where the web server hosts the presentation layer, core
system functionality, and the Workflow Runtime. Further s implifying the architecture the application and the
Workflow Runtime interact using in-process calls. A summary of implementation characteristics for this
architecture are listed in Table 2.
2: Implementation characteristics of the travel expense architecture
Characteristic Description
Presentation
Layer
Business requirements for a travel expense system tend to dictate flexibility of access so
that travelers can submit their reports from the convenience of their home or on the road.
This makes an ASP.NET web application ideal candidate for presenting the user interface.
The ASP.NET application is hosted in IIS 6 on Windows Server 2003, IIS 7 on Windows
Server 2008.
Workflow
Runtime
Workflow shares the hosting environment of the web application which is IIS. Requests
and workflow instances are executed within a specific application domain of a particular
worker process. One instance of the Workflow Runtime is allocated per application
domain.
Business
Layer
Business logic is implemented in assemblies hosted on the web server in the same
application domain as the page request, and called by workflow instances in-process.
Workflow
Interaction
ASP.NET pages use Local Services used to make in-process calls to interact with workflow
instances.Workflows use Local Services to make in-process calls to business logic that interact with
external systems, send email notifications, and communicate with the database.
Tasks Each user logs in to the web application and is presented with tasks according to
information stored in the Expense Reports database. Each task is associated to a particular
user and workflow instance, via a custom Expense Reports database, to support
correlation of user interaction with the correct workflow.
Notifications Email notifications are sent based on the result of the workflow.
7/30/2019 WF Scenarios Guidance_ Human Workflow
16/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 16
Persistence Persistence services are enabled for the Workflow Runtime to support idle time
management of each workflow instance. This conserves resources on the web server when
workflows are waiting for an event to continue processing.
Tracking Tracking services are enabled for the Workflow Runtime to provide an audit trail for each
workflow instance.
Figure 17 illustrates a refinement of this architecture in which the application is more service-oriented. In thiscase, ASP.NET pages rely on WCF services to access workflows and other business functionality. This makes it
possible to distribute that functionality to another physical tier.
17: Service-oriented architecture for travel expense process
Changes to the implementation characteristics from Table 2 are listed in Table 3:
7/30/2019 WF Scenarios Guidance_ Human Workflow
17/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 17
Characteristic Description
Services
Layer
A new services layer is introduced to the logical application architecture using WCF
services to host Workflow and other business functionality. In this case, workflows are
directly exposed as WCF services.
WCF services are hosted in a Windows Service on Windows Server 2003, IIS 7 and WAS on
Windows Server 2008.
Workflow
Runtime
Workflow shares the WCF service host environment. One instance of the Workflow Runtime
is allocated per application domain regardless of the hosting environment.
Workflow
Interaction
ASP.NET pages use WCF proxies to call workflows exposed as WCF services.
Since in this scenario the workflow is exposed as a WCF service (Workflow Services), Local Services are not
required to interact with the Workflow Runtime. In fact this removes the need for any workflow initialization
code since the WCF service operation results in the initialization of the appropriate workflow instance.
Exposing workflows as services makes it possible to distribute workflows and other business functionality to
another tier such as the application server in this case. This is useful in scenarios where there is a DMZ a
second firewall behind the web server to further protect access to application resources; and to offload work
from the web server when long running business processes may be resource intensive to improve overall
scalability.
Q.How are users associated with workflow instances?
Every workflow instance has an identifier associated with it. This identifier is used by persistence services so
that the state of a workflow instance can be saved during idle time and used to reload the workflow instance.
Developers can use this workflow instance identifier to associate a workflow instances with users that interact
with application interfaces. User interfaces can then present a list of workflow instances that are currently
running, idle, or completed according to the applications requirements.
Q. Are there any implications of hosting workflow in a distributed environment?
In a distributed environment where workflow is hosted across load-balanced machines it is always possible that
a new machine, a new worker process (for IIS/WAS) or Windows Service host, or a new application domain will
be allocated for subsequent requests. Since persistence services are usually stored in a database shared by all
machines, the same workflow instance can be retrieved and initialized between requests, with the correct state,regardless if it is in the same application domain.
Q. Where would exception handling fit in this workflow design?
It could take weeks for the travel expense report to be fully reviewed. If the workflow were to terminate
prematurely at the end because of an error communicating with the SMTP mail server while trying to send the
approval, the submitter would be quite unhappy about having waited so long and would join the reviewers in
bemoaning having to start the process all over again. Therefore this workflow, which uses a Sequential
Workflow, the logic for handling any faults could be added at the workflow level and thereby provide for long
term stability.
7/30/2019 WF Scenarios Guidance_ Human Workflow
18/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 18
Q. Can workflow persistence and tracking be stored in the same database?
Both the persistence and tracking database schemas are provided by Workflow, and can be installed to the
same or different database. When sharing the same database, it is recommended to take advantage of
database connection optimizations offered by the SharedConnectionWorkflowCommitWorkBatchService.
Figure 18 illustrates a collaboration scenario that involves task assignment, collaborative review and approval
between multiple parties, event-driven activities, and business rules. The scenario is based on a typical pre-sales process that involves multiple users working together on a presentation in an effort to close a deal. This
type of collaboration is very often unstructured or ad-hoc as each user may choose the next person to work on
the task, and there is no system prescribed ordering of task assignments. In this scenario Workflow is used to
support this collaboration between individuals in marketing, sales, engineering, and domain experts.
18: Collaboration process
7/30/2019 WF Scenarios Guidance_ Human Workflow
19/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 19
Although platforms such as Office SharePoint 2007 supply similar collaborative solutions out of the box there
are times when a custom solution may be warranted. For example, a combination of the following may apply:
Lightweight and simple collaboration scenarios.
The need for a customized set of Windows client application interfaces.
The need for a fully integrated application interface that does not require users to bounce between
multiple applications and perform copy and paste operations, nor are any complex application
integration efforts required.
Workflow is the perfect platform to build these types of custom solutions. In fact, Workflow is at the heart of
SharePoint 2007 workflow implementations.
Although there are many different types of users that may participate in the collaboration process described in
Figure 18, the same task is essentially reassigned to a different user as each user transfers control prior to
completing the workflow. The entire workflow, in fact, is centered on a single document the slide presentation
to be created for a particular sales lead. Each user assigned the task can modify and review the slides before
deciding the next course of action. Although this process could be expressed in a sequential workflow
definition, there are some benefits to using a state machine workflow definition. State machine workflows have
the following valuable characteristics:
The top level view focuses only on the available states the workflow can be in.
Additional states are easy to add from this top level view.
By drilling down, it is possible to see the sequential commands implemented for each state.
For this scenario the workflow will be expressed by a state machine workflow that contains three states. At a
high level, the workflow receives a lead from Marketing and after evaluating a policy, transitions to the
SalesCollaboration state. From there the workflow will loop, remaining in that state as users transfer the
document between themselves. When the sales person marks the workflow complete, the slide presentation
review task is no longer associated with a user, and the workflow completes. Figure 19 illustrates the top level
view of this state machine workflow design.
19: Collaboration process state machine workflow design
7/30/2019 WF Scenarios Guidance_ Human Workflow
20/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 20
A new instance of the workflow is initialized when Marketing enters a lead into the system. The workflow begins
in the NewLead state, and automatically begins executing the StateInitializationActivity ApplyPolicy (see Figure
20).
20: ApplyPolicy initialization sequence
Within ApplyPolicy is a sequential flow with the following activities:
PromotionPolicy: This is a Policy activity that evaluates a rule set to determine potential sales promotions that
the slide presentation should incorporate. This sets up variables for the workflow that can be presented in the
user interface for example when the sales person reviews the specifics for the task.
AssignToSalesUser: This is a custom activity that creates a task associated with the salesperson (user)
assigned the lead, and associates this with the workflow for correlation. This task record will be presented in
the user interface for the assigned user.
SetStateSales: When the ApplyPolicy sequence completes the workflow transitions to the SalesCollaboration
state. This state change is handled by SetStateSales a SetState activity.
Following this initialization the workflow is in the SalesCollaboration state where it waits for a Transferred event.
At first, the collaboration task is assigned to the sales person for the lead based on initialization and so it is
up to this user to reassign the task, or complete it. Every hand-off of the slide presentation occurs as the result
7/30/2019 WF Scenarios Guidance_ Human Workflow
21/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 2
of a transfer from one user to another through the client application, which results in the execution of the
sequence shown in Figure 21.
21: Transfer task assignment sequence
The SalesCollaboration state has an EventDrivenActivity Transferred that waits for an event to be raised as
a result of user interaction. When a user transfers the task to another user the Transferred event wakes up the
workflow and checks event parameters to determine if the task is being reassigned, or completed. If
reassigned, the workflow state is set to SalesCollaboration state again but the task assignment record is
updated to reflect a different user. The newly assigned user will now see the task in their list, and the cycle
continues. If completed, then workflow will be set to Completed state and terminate.
At the outset of the collaboration workflow described in Figure 18 a PolicyActivity, shown in Figure 20, is
executed to evaluate business rules for the workflow. This Policy activity (promotionPolicy) recommends an
appropriate promotion to the Sales person that the lead will be assigned to. In this example a single sales
promotion, called the Southwest 5K Promotion. This promotion offers a $5,000 discount if the customer is in the
Southwest sales region and the approximate value of the sale is worth at least $50,000 after the discount.
The promotion logic is implemented using the Rule Set Editor for the Policy activity, shown in Figure 22 and
Figure 23. This rule set contains only two rules, but is quite expressive in its power. The requirement that the
approximate value of the sale must be at least $50,000 means that the rule has to be evaluated again. The first
7/30/2019 WF Scenarios Guidance_ Human Workflow
22/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 22
rue ca e ry romo ony app es w en e eg on s ou wes an e or g na approx ma e va ue s a eas
$50,000 (this is expressed in the Condition textbox). When this is the case the system suggests the
Southwestern 5K Promotion and applies the discount to the approximate value (shown under Then Actions).
22: Rule configuration for TryPromo within the rule set
The second rule, ValidatePromo is then evaluated (see Figure 22). In trying to apply the promotion by applying
the discount, a situation might emerge where the approximate value becomes less than $50,000. Therefore,
the ValidatePromo rule undoes the application of the rule by setting the ApproximateValue to its original
amount (adding back $5,000) and concluding that no promotion apply by setting the SuggestedPromotion to
None.
22: Rule configuration for ValidatePromo within the rule set
7/30/2019 WF Scenarios Guidance_ Human Workflow
23/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 23
The point of this rule set is to initialize variables that the workflow can use to pass between states, and present
in the user interface for decision making. The two variables set in this case are: ApproximateValue and
SuggestedPromotion. The sales person can use this discount information in the slide presentation for the sales
lead.
The advantage of using a rule set in combination with XAML based workflows, as in this scenario, is that all of
the rules, their conditions, then actions and else actions are written to an XML rules file (.rules) that can be
edited without Visual Studio, and the changes will take effect the next time a new workflow is created.
In the previous scenario, Document Review and Approval, Figure 14 illustrated the relevant runtime services
registered with the workflow runtime to support the scenario. For this collaboration scenario, the same runtime
services will be registered as discussed in this section.
Tracking Service: The SqlTrackingService is registered so that the client application can access information
about the user that currently owns the slide presentation and which user last had the presentation.
Persistence Service: The SqlWorkflowPersistenceService is required to support collaboration efforts which
could take several days to complete.
Scheduler Service: The DefaultWorkflowSchedulerService is registered since it provides the necessary
functionality of automatically allocating new worker threads to workflow instances.
7/30/2019 WF Scenarios Guidance_ Human Workflow
24/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 24
Local Services: In order to communicate with the state machine workflows EventDriven activity a Local
Service is required to raise the event. This event, Transferred, will pass parameters to the workflow indicating
the name of the user to transfer the task to and any relevant notes.
The architecture for the collaboration scenario is slightly different from that of the document review and
approval scenario primarily due to the choice of presentation layer WPF. Figure 24 illustrates this
architecture.
24: Architecture for collaboration process
This architecture assumes that the client application communicates with system functionality, including
workflows, through WCF services. Since WCF services can support any protocol, these services could be
accessed over the Internet (HTTP) or behind the firewall (over TCP) and the architecture would still be
equivalent. A summary of implementation characteristics for this architecture are listed in Table 4.
7/30/2019 WF Scenarios Guidance_ Human Workflow
25/26
9/2/13 WF Scenarios Guidance: Human Workflow
msdn.microsoft.com/en-us/library/cc709416.aspx 25
4: Implementation characteristics of the collaboration architecture
Characteristic Description
Presentation
Layer
In this collaborative process a single WPF client application can be designed to support all
users allowing them to retrieve any tasks currently assigned to them and to open slide
presentations with the associated program (PowerPoint). In this case, the use of a thick
client is beneficial since it can also allow users to gather a list of tasks and presentations to
review, and work offline.
The WPF application can be deployed using ClickOnce to streamline updates to the
application. The ClickOnce deployment requires FullTrust.
Services
Layer
Workflows are exposed as WCF services in this scenario, so that they can be reached by
remote client applications. These Workflow Services may be accessible over the Internet, or
intranet.
For Internet access, the hosting environment will be IIS 6 on Windows Server 2003, and IIS
7 and WAS on Windows Server 2008.
For intranet access, the hosting environment will be a Windows Service on Windows Server
2003, and IIS 7 and WAS on Windows Server 2008.
Workflow
Runtime
Workflow shares the hosting environment of the services layer since they are exposed as
WCF services.
Workflow
Interaction
WPF clients interact with workflow via WCF service operations which initialize the workflow
when called.
Workflows use Local Services to make in-process calls to business logic that communicate
with the database.
BusinessRules
Business rules are configured as part of the workflow definition. These are stored in XMLfiles that can be edited post-deployment so that workflow instances always have access to
the latest rules.
Tasks Each user logs in to the client application and is presented with tasks according to
information stored in the Tasks database. Each task is associated to a particular user and
workflow instance to support correlation of user interaction with the correct workflow.
Persistence Persistence services are enabled for the Workflow Runtime to support idle time
management of each workflow instance. This conserves resources on the server when
workflows are waiting for an event to continue processing.
Tracking Tracking services are enabled for the Workflow Runtime to provide an audit trail for each
workflow instance.
Q. Can the Workflow Service support both Internet and intranet use?
Since Workflow Services are based on WCF, the same functionality can support called over HTTP and TCP, for
example. The client application can configured explicitly to use Internet or intranet, or code could be written to
make an intelligent selection based on the deployment scenario for the client application.
7/30/2019 WF Scenarios Guidance_ Human Workflow
26/26
9/2/13 WF Scenarios Guidance: Human Workflow
2013 Microsoft. All rights reserved.