现在我们以演示的采购工作流来研究工作流系统的设计。本文将讨论一个通用的工作流“引擎”包含哪些功能。通过需求分析和梳理，我们已经获得如下的流程图。由此可知该流程由一组状态、与状态对应的一组用户和流程处于某种状态时当前用户所能进行的若干操作组成。
接下来逐个分析这些操作。首先看IT部门的起草人填完采购单后提交。此时流程系统须做以下工作：
- 校验必填字段。
- 生成采购单号。
- 修改采购单状态为Waiting For IT Approval。
- 将流程的当前处理人由起草人改为负责审批的IT Leader，将起草人添加入读者域，将容纳采购单基本信息的存取控制区段的写权限设置为无人。
- 添加操作记录，即何时起草人将采购单从草稿提交，以及可能有的备注。
- 发送邮件通知IT Leader处理该单。
IT Leader通过邮件链接或者直接在采购系统的My Work视图下看到该采购单，他可以选择批准或驳回。批准时流程系统将做以下动作：
- 修改采购单状态为Waiting For Finance Verification。
- 将IT Leader存入读者域，将流程当前处理人改为财务部负责Finance Verification的同事。
- 添加操作记录，即何时IT Leader将采购单从Waiting For Finance Verification状态批准，以及可能有的备注。
- 发送邮件通知当前处理人处理该单。
我们再选取其他几个节点的某些操作。流程处于Waiting For Finance Confirmation状态时，财务部负责Finance Confirmation的员工选择批准时：
- 如果采购金额超过500元，修改采购单状态为Waiting For Final Review，否则改为Inputting Payment Information。
- 将负责当前状态的用户存入读者域，将流程当前处理人据上述规则改为对应状态的处理人。如果下一状态为Inputting Payment Information，将Payment Information所在的存取控制区段的写权限设置为该状态的处理人。
- 添加操作记录。
- 发送邮件通知当前处理人处理该单。
流程处于Inputting Payment Information状态时，负责处理的起草人如果选择Change Price：
- 系统将弹出修改价格对话框。
- 修改采购单状态为Waiting For IT Approval。
- 将流程的当前处理人由起草人改为负责审批的IT Leader，将起草人添加入读者域。
- 添加操作记录。
- 发送邮件通知IT Leader处理该单。
流程处于Inputting Bank Information状态时，负责处理的财务部员工选择关闭：
- 修改采购单状态为Closed。
- 将流程的当前处理人由改为代表没有人的[Nobody]，将当前用户添加入读者域，将所有存取控制区段的写权限设置为无人。
- 添加操作记录。
- 发送邮件通知起草人该单已审批完成。
- 在财务部的费用报销流程系统里自动创建一张报销单，从当前采购单填入相关信息。
可以看出，上述节点操作有相当部分是相似的，例如修改采购单的权限，包括有关的读者域、作者域、存取控制区段，只是具体每个操作修改的内容不同。因此与其为每个操作写代码，更理想的方式是写通用的代码来处理这些相似的动作，而在每个操作上某个动作用到的具体的数据则由配置文档提供。这些通用代码就构成所谓的流程引擎。至于某个操作包含的特定动作，则要根据每个流程的具体需求临时编写。
我们看看流程引擎包含哪些功能：
虽然上面的操作实例中，只有提交需要校验必填字段，但这项功能在其他节点操作中也时有需要，并且功能的需求边界清晰，易于标准化，所以包含在我们的流程引擎中。此外流程文档从一个状态跳转至另一状态时，有时需要修改一些业务字段的值，将此功能包括在流程引擎里也能省去为很多此类简单的特定动作编写代码。生成采购单号之类流水号，虽然在开发中也很常见，但是此功能并不仅限与于流程系统，而且实现它用到的流水号配置文档也最好单独保存，所以虽然也采用通用的配置文档和代码来生成流水号，但是独立于流程系统之外。再加上从以上的操作例子中可明显看出的相似动作，最终流程引擎包含以下功能：
- 校验必填字段。
- 修改流程文档的权限，包括有关的读者域、作者域、存取控制区段。
- 添加操作记录。
- 修改配置的业务字段。
- 发送邮件通知相关处理人。