如果不考虑人力交互 （该要素与过程自动化和集成的很多方面语义相关），那么业务流程的完全自动化实际上是无法实现的。 人力交互存在于一些最常见的业务流程中， 如订单审批和人力资源管理。这些人力交互包含从简单的任务分配流程到非常复杂的业务流程通知和任务再分配等各种形式。

　　不同供应商的多种受欢迎的集成服务器中均提供了工作流框架。 我们将从概念上探讨一些在工作流平台以及这些平台之间的交互中存在的主要组件。 我们还将介绍一些最常见的工作流设计模式以及使用上述组件实现这些模式的方式。

　　工作流系统必须支持人与系统之间的通信。 要实现这一支持， 每个工作流系统都必须提供基本的功能， 如任务分配、 标识管理、 通知、 跟踪以及与业务流程管理 (BPM) 系统的互操作（参见图 1）。

　　图一

　　工作流架构的四个主要组件为： 任务管理服务、 跟踪服务、 通知服务和标识服务。 在深入探讨这些服务之前， 需要了解一下任务在工作流系统中的作用。

　　任务是业务流程和人之间的主要通信单元。 通常， 任务被分配给需要执行某个相关操作的用户。 例如， 一位可能需要批准购买某些货物的请求的主管。 通常， 用户必须执行按照语义进行组合的一系列任务。 也就是说，主管可能将每天需要购买的所有货物组合到一个名为 “今天的批准项” 的组中。 这些组称为任务列表。

　　任务状态　在工作流系统的生存期内， 任务列表中的任务不断地从一种状态切换到另一种状态。 例如， 主管的任务首先进入 “未决” 状态； 在主管接受该任务后，状态更改为 “认领” 。 最后， 当主管批准该请求后， 任务进入最终状态“完成” 。 状态用于从概念上描述任务生存期。 一些最常见的状态是 “未决” 、“认领” 、 “完成” 和 “失败” 。 在 “未决” 状态下， 任务已被创建； 在 “认领” 状态下， 用户认领任务并接收任务输入数据； 在 “完成” 状态下， 用户已经完成任务并提供了任务的输出数据； 在 “失败” 状态下， 用户已经完成任务， 并且提供了错误消息。

　　任务通常与时间范围相关联： 到期、 升级、 委派和续订。 在我们的示例中，如果主管没有在指定的时间段内处理批准任务， 则该任务可能到期。 这一到期任务随后可以升级到另一个操作或分配流程中。 主管还可以决定将任务委派给另一个人（例如，经理）以代替他或她执行任务。 经理也可以决定是否让另一位经理参与进来，以便收集其他意见。如果第二位经理没有在给定的时间范围内处理此任务，则该任务将被续订，以便在另一时间段内执行。

　　在其他方案中， 各项任务在语义上彼此相关。 对于问题 “下一个任务是什么？”的回答并不总是无足轻重。在某些情况下，必须在运行时确定答案。任务可以按顺序组合在一个业务流程实例中，以便用户了解在完成当前任务后要执行的下一个任务。

　　在我们的示例中，主管需要依次批准20个请求才能完成该业务流程。主管每次完成一项批准之后，引擎都应该能够标识下一个任务。“任务链”代表一种元数据驱动方法，该方法用来描述业务流程范围内的一组任务之间的关系。任务链可以按照语义组合任务，以帮助用户实现某些功能，如顺序执行和失败管理。　依赖于特定业务流程的任务称为内联任务。完全独立于特定业务流程的任务是独立任务。内联任务通常可以访问与业务流程相关的数据，并且存储在本地的、业务流程元素（如变量或消息）中。相比之下，独立任务通过定义良好的接口与业务流程进行交互，完全不依赖于流程数据本身。

　　工作流服务

　　处理局部任务的架构组件是任务管理服务。在典型方案中，任务管理服务接收任务创建请求， 与标识服务进行交互以选择有资格执行此任务的所有人员，将任务添加到与所选用户相关联的工作列表（待完成工作）中，并分配特定的时间线和策略。最终，一个用户通过认领该任务来决定对其进行处理。然后，该用户可以处理该任务或请求更多的数据。

　　工作流系统的一个关键方面是能够解析允许执行任务的用户集。此用户解析流程可以基于与标识管理平台之间的交互。在我们的示例中，工作流服务需要标识哪些用户能够批准请求，在此情况下是主管。 要完成此标识， 工作流平台必须对照传统上存储在用户目录中的一组用户和角色来解析“主管” 概念。

　　在人与流程之间可以建立多种类型的关系。最常见的关系之一就是人与流程进行交互的方式（人力角色）。可以将组织中的人组合到在语义上与某个业务活动相关的角色中，如流程管理员或任务所有者。另一种常见的关系是流程如何标识要与哪些人交互（人员链接和查询）。在业务流程中，某些用户组从业务观点来看是相关的。人员链接用于表示参与流程执行的不同组人员。针对组织目录进行的查询用于确定与人员链接相关联的个人，而且被绑定到人员链接。在我们的示例中，普通的人力角色 — 财务经理可以由人员链接主管限定， 后者被绑定到以下查询：“选择部门领导，其中部门名称为财务”。　身份服务负责与用户相关的功能，如身份验证、授权或人员解析。用户信息通常存储在组织目录（例如，Active Directory 目录服务、LDAP 目录或关系数据库）中。身份服务的工作可以独立于组织目录。根据适配器模式，可以通过提供程序提取目录访问，该提供程序能够执行查询来获取目录中的信息。此方法可以从用户的存储区中提取工作流功能。

　　在我们的示例中，假设经理想要重建请求 — 批准工作流的执行，以检查是否存在短缺。 跟踪服务可以跟踪与任务和任务链相关的状态更改。此服务应该提供所需功能的基础，以重建任务历史记录更改和执行任务分析。

　　在创建请求 — 批准任务时，我们还需要一种能够通过电子邮件通知主管的服务。通知服务处理向与任务的状态更改相关的用户发送通知的机制。

　　这里讨论的四个运行时服务提供了工作流系统所需的一些最常见功能的良好概览。通过将这些服务组合起来，可处理一些最常见的工作流方案。现在，让我们来探讨一些常见的工作流模式。

　　任务分配模式

　　面向工作流的流程在业界已经存在了一些年。获得的知识可以作为改进的基础，以构建工作流系统。模式在不同的级别（如任务批准、任务创建和任务状态管理）抽象工作流系统。 在此，我们不打算定义工作流模式的分类。相反，我们将从以前定义的架构的角度介绍工作流系统中的一些常见模式。

　　我们将从考察“单用户工作流”示例开始。可以将任务分配给一个用户，并且只有一个用户可以处理该任务。例如，一名雇员通过雇员门户提交了休假请求。该门户启动了一个业务流程，该流程包括一个使用简单工作流建模的用户任务。该任务被分配给此雇员的经理。 当经理批准或拒绝休假请求时，将经理的决定通过电子邮件通知该雇员。