工作流服务

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

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

在人与流程之间可以建立多种类型的关系。最常见的关系之一就是人与流程进行交互的方式（人力角色）。可以将组织中的人组合到在语义上与某个业务活动相关的角色中，如流程管理员或任务所有者。另一种常见的关系是流程如何标识要与哪些人交互（人员链接和查询）。在 业务流程中，某些用户组从业务观点来看是相关的。人员链接用于表示参与流程执行的不同组人员。针对组织目录进行的查询用于确定与人员链接相关联的个人，而 且被绑定到人员链接。在我们的示例中，普通的人力角色 — 财务经理可以由人员链接主管限定， 后者被绑定到以下查询：“选择部门领导，其中部门名称为财务”。

身份服务负责与用户相关的功能，如身份验证、授权或人员解析。用户信息通常存储在组织目录（例如，Active Directory 目录服务、LDAP 目录或关系数据库）中。身份服务的工作可以独立于组织目录。根据适配器模式，可以通过提供程序提取目录访问，该提供程序能够执行查询来获取目录中的信息。 此方法可以从用户的存储区中提取工作流功能。

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

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

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

任务分配模式

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

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

对于此解决方案，通过四个交互将工作流组件组合起来。该任务是使用与任务管理服务交互的客户端应用程序配置的；该任务的生存期或任务状态得到了配 置。作为业务流程的一部分，使用任务管理服务将任务分配到用户组。用户之一认领该任务，任务管理服务应用正确的策略以防止其他用户处理同一个任务。业务流 程使用任务管理服务获取任务的状态更新。

现在，让我们来考虑一个顺序工作流示例。顺序工作流代表一个方案，在该方案中，任务必须由一组用户按顺序批准。例如，当购买订单批准系统使用业务流 程处理购买订单时， 属于“主管”组的一名雇员要对购买订单进行初步评估。在初始用户批准购买订单之后，由该用户的经理批准它。在经理批准后，该购买订单被转发至计帐和运输部 门。该解决方案包含四个交互。与任务管理服务进行交互，以配置任务和设置合适的策略。定义应该处理任务的用户的顺序。启动与任务管理服务交互的任务。第一 个用户将认领该任务以开始处理它， 处理完成后， 任务管理服务会将该任务传送到该组中的下一个用户。

平行工作流模式代表如下方案：一个任务必须由不同的用户同时批准。每一个审批者都可以独立于其他人添加备注和附件。例如，招聘流程用于招聘新雇员。 每个面试人员都需要投票以支持或反对应聘者。如果有75% 的投票表示支持，则会雇用该应聘者；否则，该应聘者将会落选。此流程使用平行工作流建模，其中每个面试人员都可以独立于其他面试人员进行投票。实现该解决 方案需要五个交互。与任务管理服务进行交互，以配置任务和设置合适的策略。定义应该处理任务的用户的顺序。启动与任务管理服务交互的任务。任务管理服务将 该任务传送给所有用户。 任务管理服务只有在所有用户都完成任务的处理时才能完成该任务。