WF Scenarios Guidance_ Human Workflow

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


2/26


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


3/26



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


4/26



.

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:


5/26



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


6/26



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



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


8/26



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


9/26



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


10/26



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.


11/26



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


12/26



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.


13/26



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.


14/26



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


15/26



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.


16/26



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:


17/26




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.


18/26



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


19/26



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


20/26



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


21/26



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


22/26



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


23/26



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.


24/26



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.


25/26



4: Implementation characteristics of the collaboration architecture


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.

Documents

WF Scenarios Guidance_ Human Workflow