工作流系统以及人力 — 业务流程交互的一些最具代表性的模式分为两个主要组件。第一个组件是工作流系统以及在集成平台上实现这些系统时它们之间的交互。第二个组件是工作流交互设计模式以及使用工作流系统之间的交互实现这些模式的方式。本论述将详细介绍这些流程。

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

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

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

图一

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

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

任务状态

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

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

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

在我们的示例中，主管需要依次批准20个请求才能完成该业务流程。主管每次完成一项批准之后，引擎都应该能够标识下一个任务。“任务链”代表一种元 数据驱动方法，该方法用来描述业务流程范围内的一组任务之间的关系。任务链可以按照语义组合任务，以帮助用户实现某些功能，如顺序执行和失败管理。

依赖于特定业务流程的任务称为内联任务。完全独立于特定业务流程的任务是独立任务。内联任务通常可以访问与业务流程相关的数据，并且存储在本地的、业务流程元素（如变量或消息）中。相比之下，独立任务通过定义良好的接口与业务流程进行交互，完全不依赖于流程数据本身。