用状态构造工作流-案例

目录

概要

案例流程

实现

技术细节

---

概要

业务流程，根据其流转条件复杂程度，可以分别考虑实现方案。对于那种非常复杂的条件，即需要判断的结果需要获取较多的业务数据，例如，根据采购类型、采购来源、采购金额、不同时期采购量、采购人级别等进行判断的综合条件。目前，工作流技术也很难处理复杂条件的自动处理，大多数开源框架都做了简化，比如人为决定下一步把任务交给谁。

对于简单的条件，则可以采用状态控制即可，例如维修申请单状态。这种简单条件控制的流程，不采用工作流框架也可以自己实现。

案例流程

电信故障维修过程：用户通过电话或者网上申报故障，维修公司受理故障，支持自动受理和人工受理；受理后，首先通过自动化检测设备对线路进行初步自动检测，如果返回的错误类型无法自动修复，转人工处理；维修公司对该故障派工并产生派工单，维修工人收到派工单后，根据派工单上提供的故障类型以及地址上门维修；维修后，维修工人做消障操作；对用户回访，问题如果已经解决，流程结束，否则回到派工环节。

通过分析发现，维修过程可以抽象成故障维修状态的变化过程，具体而言就是维修申请单的状态。因此，系统可以仅采用一个表属性来表示。故障申请单状态变化如下图所示。

实现

• 用一个维修申请单号贯穿整个流程的业务数据库表；
• 状态表保存当前状态：维修申请单号、状态；如果采用覆盖的方式，则某一时刻只能保存当前最新状态，如果保存状态变化的整个过程，则还需要一个时间戳或者其他表示最新状态的字段；此外，还需要知道一个状态是否已经处理完的标识；时间戳和是否已处理完也可以考虑共用一个标识；
• 上述状态变迁图，采用数据库表进行存储，相当于工作流模型，workflow model；
• 工作流引擎，或者状态机算法步骤：每个任务完成后，需告知状态表任务已完成；对所有维修单状态表进行扫描，对已完成任务的工单进行处理，对照工作流模型，变迁到下一个状态，置成未完成标识；

技术细节

其实，上述工作流引擎可以有两种工作方式：主动和被动。主动方式下，系统可设置定时器或者类似方法主动扫描状态表。被动方式下，每个任务执行完后，业务模块需要调用引擎去计算下一个状态，业务模块和引擎之间耦合较大，但这种方式鲁棒性好。