WF Scenarios Guidance: Human Workflow

Article
03/09/2009

May 2008

Michele Leroux Bustamante, IDesign

Zoiner Tejada, Hershey Technologies

Windows Workflow Foundation (WF or, Workflow) is Microsoft’s 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 human workflow or 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 and editing 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 helpful for human workflow.

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 completion.
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 be useful 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 to interact 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 – although custom 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:

Workflows exposing WCF service endpoints (also called Workflow Services)
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

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 raised 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 a HandleExternalEventActivity 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

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

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

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

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

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

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 time metrics 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 reviewer’s decision – which for this scenario represents a substantial portion of the workflow instance’s lifecycle and is likely measured in days.

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 be called 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

This architecture assumes a single tier deployment – where the web server hosts the presentation layer, core system functionality, and the Workflow Runtime. Further simplifying 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.
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 this case, 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:

3: Changes to implementation characteristics for distributed scenario

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 application’s 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.

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

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

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 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 rule (called TryPromo) only applies when the Region is Southwest and the original approximate value is at least $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

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.

Local Services: In order to communicate with the state machine workflow’s 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.

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.
Business Rules	Business rules are configured as part of the workflow definition. These are stored in XML files 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.

Share via

WF Scenarios Guidance: Human Workflow

Additional resources