92. 基于Notes/Domino的文档工作流系统（四）

现在我们以演示的采购工作流来研究工作流系统的设计。本文将讨论1个通用的工作流“引擎”包括哪些功能。通过需求分析和梳理，我们已取得以下的流程图。由此可知该流程由1组状态、与状态对应的1组用户和流程处于某种状态时当前用户所能进行的若干操作组成。
 
接下来逐一分析这些操作。首先看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。
• 将负责当前状态的用户存入读者域，将流程当前处理人据上述规则改成对应状态的处理人。如果下1状态为Inputting Payment Information，将Payment Information所在的存取控制区段的写权限设置为该状态的处理人。
• 添加操作记录。
• 发送邮件通知当前处理人处理该单。

流程处于Inputting Payment Information状态时，负责处理的起草人如果选择Change Price：

• 系统将弹出修改价格对话框。
• 修改采购单状态为Waiting For IT Approval。
• 将流程确当前处理人由起草人改成负责审批的IT Leader，将起草人添加入读者域。
• 添加操作记录。
• 发送邮件通知IT Leader处理该单。

流程处于Inputting Bank Information状态时，负责处理的财务部员工选择关闭：

• 修改采购单状态为Closed。
• 将流程确当前处理人由改成代表没有人的[Nobody]，将当前用户添加入读者域，将所有存取控制区段的写权限设置为无人。
• 添加操作记录。
• 发送邮件通知起草人该单已审批完成。
• 在财务部的费用报销流程系统里自动创建1张报销单，从当前采购单填入相干信息。

可以看出，上述节点操作有相当部份是类似的，例如修改采购单的权限，包括有关的读者域、作者域、存取控制区段，只是具体每一个操作修改的内容不同。因此与其为每一个操作写代码，更理想的方式是写通用的代码来处理这些类似的动作，而在每一个操作上某个动作用到的具体的数据则由配置文档提供。这些通用代码就构成所谓的流程引擎。至于某个操作包括的特定动作，则要根据每一个流程的具体需求临时编写。
我们看看流程引擎包括哪些功能：
虽然上面的操作实例中，只有提交需要校验必填字段，但这项功能在其他节点操作中也时有需要，并且功能的需求边界清晰，易于标准化，所以包括在我们的流程引擎中。另外流程文档从1个状态跳转至另外一状态时，有时需要修改1些业务字段的值，将此功能包括在流程引擎里也能省去为很多此类简单的特定动作编写代码。生成采购单号之类流水号，虽然在开发中也很常见，但是此功能其实不仅限与于流程系统，而且实现它用到的流水号配置文档也最好单独保存，所以虽然也采取通用的配置文档和代码来生成流水号，但是独立于流程系统以外。再加上从以上的操作例子中可明显看出的类似动作，终究流程引擎包括以下功能：

• 校验必填字段。
• 修改流程文档的权限，包括有关的读者域、作者域、存取控制区段。
• 添加操作记录。
• 修改配置的业务字段。
• 发送邮件通知相干处理人。