How To: Design Business Workflow Components

J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat.

Applies To

  • Business components that are used to implement workflow solutions for an application.

Summary

There are many scenarios where tasks must be completed in an ordered way based on the completion of specific steps, or on human interaction. This article examines different scenarios and provides guidance on how to design business workflow components.

Contents

  • Objectives
  • Overview
  • Summary of Steps
  • Step 1 – Identify Workflow Style Using Scenarios
  • Step 2 – Choose an Authoring Mode
  • Step 3 – Determine How Rules Will be Handled
  • Step 4 – Choose a Workflow Solution
  • Step 5 – Design Business Components to Support Workflow
  • Additional Resources

Objectives

  • Identify the workflow style for your application using common scenarios.
  • Choose an authoring mode for creating workflows based on requirements and rule-handling options.
  • Choose a workflow solution that supports your requirements.
  • Learn how to design components that support different workflow solutions.

Overview

This guide starts with a look at real-world scenarios that are mapped to key workflow scenarios. Next, it examines how requirements and rules affect the options you have for implementing workflow components. The final step provides guidance on designing workflow components to support the different options that are available.

Summary of Steps

  • Step 1 – Identify workflow style using scenarios.
  • Step 2 – Examine requirements to choose an authoring mode.
  • Step 3 – Determine how business rule handling requirements affect the choice of authoring mode.
  • Step 4 – Choose a workflow solution based on the capabilities provided.
  • Step 5 –Design business components to support workflow.

Step 1 – Identify Workflow Style Using Scenarios

There are three basic types of workflow style: sequential, state-machine, and data-driven. With sequential workflow, a task moves through a specific set of steps until it is completed. With a state-machine workflow, activities are defined as a set of states and events that cause transitions from one state to another. With data-driven workflow, activities are executed based on information associated with data. As a result, the first step in designing workflow components is to understand the style of workflow you need to support. The following lists shows some examples of the different workflow styles.
Sequential Workflow Style: With a sequential workflow style, the workflow controls the sequence of activities and decides the steps which occur next. Though the sequential workflow can also have conditional branching and looping, the path it follows is predictable. Consider sequential workflows for the following scenarios:
  • You need to execute a series of predefined steps to accomplish a certain task.
  • Systems management.
  • Business-to-business orchestration.
  • Business rule processing.
State-Machine Workflow Style: The workflow is in a given state and waits for events to occur to move into another state. Consider state-machine style for the following scenarios:
  • You need to workflows which are designed for event-driven scenarios.
  • User interface page flows, such as a wizard interface.
  • Order processing system, where an order is processed based on its state.
Data-driven Workflow Style: Document approval process, where information in the document determines the activities to execute.

Step 2 – Examine requirements to choose an authoring mode

Authoring of workflows can use code, markup languages, or a combination of both code and markup. The approach you take depends on the authoring mode requirements for your solution. The authoring mode which you choose will influence how you will package and distribute the application.
Choose a code-only option:
  • If the workflow solution will not change over time.
  • If complex business rules cannot be defined using markup.
  • If the development team is more familiar with managed code rather than designer.
  • If you want to create new workflow types which is not possible using the no-code option.
Choose a code-separation option:
  • If the workflow solution will change over time.
  • If complex business rules must be handled by business components.
  • If you wish to provide your end users the facility to modify the workflows by using workflow designers.
Choose a no-code option:
  • If the workflow solution will change over time.
  • If business rules associated with the workflow can be defined using markup languages.
  • If you do not need to create new workflow types.
  • If you need the flexibility to update the workflow model without rebuilding the workflow types referenced by the model.

Step 3 – Determine how business rule handling requirements affect the choice of authoring mode

At this point, you should have identified the workflow style and determined an authoring mode for creating workflows. The next step is to determine how your workflow will handle the rules. The option you choose is based on the complexity, durability, and management requirements associated with the rules.
If rules are complex:
  • You should use a code-only or code-separation authoring mode.
  • Business components will be required to implement the rules.
If rules are not durable:
  • For simple or data-driven rules, you should use a no-code authoring mode.
  • You can use a code-only or code-separation authoring mode if the rules are managed by an external system, such as a business rules engine.
If business users or analysts are required to manage rules:
  • You will require a solution that provides visual designers.
  • You can use a code-separation authoring mode if the rules are managed by an external system, such as a business rules engine.

Step 4 – Choose a workflow solution based on the capabilities provided

Now that you have an understanding of the workflow style, authoring mode, and rule handling requirements for your workflow, the next step is to choose a workflow solution. The choice you make is based on capabilities that each solution provides.

Windows Workflow Foundation (WF)

Windows Workflow Foundation has the following features:
  • Provides a developer-centric solution for creating workflows.
  • Supports sequential, state-machine, and data-driven workflows.
  • Supports code-only, code-separation, and no-code authoring modes.
  • Designer support is available through Visual Studio 2005 with extensions, and directly in Visual Studio 2008.
  • Includes protocol facilities for secure, reliable, transacted data exchange and a broad choice of transport and encoding options.
  • Provides support for long running workflows that can persist across system shutdowns and restarts.

Microsoft Office SharePoint Server (MOSS) and Windows SharePoint Services (WSS)

Microsoft Office SharePoint Server and Windows SharePoint Services have the following features:
  • Uses Windows Workflow Foundation (WF) to implement workflows.
  • Approval-based workflow related to list items can be defined using the Web interface.
  • SharePoint designer can be used to define conditional or data-driven workflows.
  • Visual Studio can be used to create custom workflows using WF components and services.
  • Integrates closely with applications in the Microsoft Office suite.

BizTalk Server 2006

BizTalk Server 2006 has the following features:
  • Supports sequential, state-machine, and data-driven workflows.
  • Supports code-separation, and no-code authoring modes.
  • Enables electronic document exchange relationships between companies using Electronic Data Interchange (EDI) and/or XML formats.
  • Contains powerful orchestration capabilities for designing and executing long-running, loosely coupled business processes.
  • Provides an orchestration designer to author workflows.
  • Integrates with heterogeneous applications and systems through adapters.
  • Provides a business rules engine and Business Activity Monitoring (BAM).

Step 5 – Design Business Components to Support Workflow

When it comes to business workflow components, the types of components you design are based on the workflow solution, workflow style, and authoring mode. When designing business workflows, you must consider method invocations that require no reply, or have long response times.

Windows Workflow Foundation (WF)

The different business components you would design for WF include custom workflow, activity, and state objects; as well as custom services. The components you require depend on the workflow style and authoring mode.
When designing Sequential Workflows you:
  • Define or use existing Activity classes (code-only and code-separation).
  • Define custom workflow classes (code-only).
  • Define business process components that interact with workflow components (code-only).
When designing State Machine Workflows you:
  • Define state classes used to represent different states of the process (code-only and code-separation).
  • Define or use existing events used to trigger state changes (code-only and code-separation).
  • Define or use existing Activity classes used to manage state transitions (code-only and code-separation).
  • Define custom workflow classes (code-only).
  • Define business process components that interact with workflow components (code-only).
When designing State-Driven Workflows you:
  • Define or use existing Activity classes (code-only and code-separation).
  • Define or use existing Condition classes to interact with data providers (code-only and code-separation).
  • Define custom workflow classes (code-only).
  • Define business process components that interact with workflow components (code-only).
When designing custom services you:
  • Define or use existing Activity classes to interact with the service.
  • Define a service interface that supports required operations.
  • Design the service using proven practices.
  • Choose the appropriate host for your service (IIS, WAS, or WorkflowServiceHost)
When designing workflow markup you can:
  • Use the Visual Studio designer, which is available as an extension to Visual Studio 2005 and directly in Visual Studio 2008.
  • Use SharePoint Designer to build workflows based on SharePoint lists.
  • Use a third party designer, such as those provided by K2 Blackpearl, to create markup associated with the third party product.
  • Hand-code the markup using appropriate XAML syntax.

BizTalk Server 2006

BizTalk can support either a code-separation or a no-code authoring mode. With BizTalk, you may need to design workflow components that are used within BizTalk orchestration. Examples of workflow components include adapters and connectors. You may also need to create services that provide operations required by the workflow, or design business components that handle requests from BizTalk workflows.
You can also use BizTalk without writing custom components, which represents a no-code authoring mode. In other words, if only simple operations are required, you can take advantage of the message transformation and the function features of BizTalk Server.
When designing BizTalk workflow components you:
  • Define a class that implements the appropriate interface.
  • Register the class with COM for use in BizTalk.
When designing business components for BizTalk you:
  • Define business components that support required operations
  • May initiate atomic transactions within business components that are called by an orchestration.
  • Design the business layer to support the required operations using proven practices.
When designing custom services you:
  • Define or use existing BizTalk classes to interact with the service.
  • Define a service interface that supports required operations.
  • Design the service using proven practices.
  • Choose the appropriate host for your service (IIS or WAS)
Figure 1 shows how all of these components can work together to support a BizTalk workflow.
BizTalk.jpg
Figure 1. Components working together to support a BizTalk workflow.

BizTalk with ESB

The Microsoft Enterprise Service Bus (ESB) Guidance extends BizTalk with capabilities focused on building connected, service-oriented applications. The Microsoft ESB guidance consists of components that support and implement a messaging environment, making it easier to build message-based enterprise applications.
Components provided by the Microsoft ESB include:
  • Web services
  • Itinerary services
  • Itinerary on-ramps
  • On-ramps
  • Off-ramps
  • Exception Management Framework
  • ESB Management Portal

Using Windows Workflow Foundation (WF) and BizTalk Together

There are many cases where Windows Workflow Foundation (WF) or BizTalk may not individually provide full support for the workflows you must implement. When faced with this situation you can often take advantage of the appropriate features from both workflow solutions within the same application.
Scenarios for using both solutions together include:
  • When you want to implement business-rule workflow using WF components in a code-only authoring mode that interacts with the BizTalk rules engine.
  • When you have existing WF workflows that must be invoked from a BizTalk orchestration.
  • When you are writing a SharePoint workflow that must execute a BizTalk orchestration.
  • When a WF workflow must integrate with heterogeneous or legacy systems.

Additional Resources

Last edited Dec 17, 2008 at 7:38 PM by prashantbansode, version 4

Comments

No comments yet.