1. 关于工作流
工作流是由不同的人做出的一系列决策，根据定义和可重复的过程，确定其中一个人所做出的特定请求会发生什么。
2. 工作流过程 (Process) 的配置和用户
在我们可以在此工作流引擎数据库中设计任何其他内容之前，我们首先需要定义确切构成流程的内容，以及我们的用户是谁以及哪些人可以修改流程本身。
Process (流程表) 设计
可能包含的字段:
| 名称 | 描述 | 类型 |
|---|---|---|
| id | id | integer |
| name | 流程标识 | string |
该表虽然非常简单，但却是其余设计的中心参考点; 此数据库中的大多数表（例如，状态 (State)，转换(Transition)，请求(Request) 等）都需要直接或间接地与此表相关联。
User (用户) 设计
在不同系统中设计可不一样
3. 工作流状态 (State) 和转换 (Transition) 的设计
在一次工作流程中会设计到不同的状态(state), 状态之间的流转需要不同的程序, 我们将之命名为转换(transition)
状态 (State) 的设计
工作流中的不同状态各有不同的属性类型, 在此总结出几种常见的状态类型枚举:
- 开始(start)：每个进程只应该一个。此状态是创建新请求时所处的状态。
- 正常(normal)：没有特殊名称的常规状态。
- 完成(complete)：表示此状态下的任何请求已正常完成的状态。
- 拒绝(denied)：表示此状态下的任何请求已被拒绝的状态（例如，从未开始且不会被处理）。
- 已取消(cancelled)：表示此状态下的任何请求已被取消的状态（例如，工作已开始但尚未完成）。
一个状态在一次流程中是唯一的，每个状态都有名称，描述和类型。
| 名称 | 描述 | 类型 |
|---|---|---|
| id | id | integer |
| process_id | 所属流程的 id | integer |
| name | 状态名称 | string |
| state_type | 状态类型 | string |
| description | 状态描述 | string |
转换 (Transition) 的设计
流程中不同的状态之间存在状态的转换 (Transition)
转换在进程下也是唯一的，标记着从一个状态到另一个状态的过程, 因此转换由主键，进程 ID，当前状态和下一个状态组成：
| 名称 | 描述 | 类型 |
|---|---|---|
| id | id | integer |
| process_id | 所属流程的 id | integer |
| current_state_id | 当前状态 id | integer |
| next_state_id | 下一状态 id | integer |
4. 工作流操作动作 (Action) 和后续事件 (Activity) 的设计
状态 (State) 之间的流转我们称之为转换(Transition), 那么促成这个转换发生的动作和转换发生后的后续影响事件. 我们成为:
- 动作(Action): 用户在某个状态节点可操作的行为
- 活动(Activity): 转换到状态节点后产生的事件
动作 (Action) 的设计
同样的不同的动作也各有不同的属性类型, 在此总结出几种常见的动作类型枚举:
- 批准(approve)：操作人将请求应移至下一个状态。
- 拒绝(deny)：操作人将请求应移至上一个状态。
- 取消(cancel)：操作人将请求应在此过程中移至“已取消”状态。
- 重新启动(restart)：操作人将将请求移回到进程中的“开始”状态。
- 解决(resolve)：操作人将将请求一直移动到 Completed 状态。
| 名称 | 描述 | 类型 |
|---|---|---|
| id | id | integer |
| process_id | 所属流程的 id | integer |
| action_type | 操作类型 | string |
| name | 操作名称 | string |
| description | 操作描述 | string |
这里需要提及的一点是, 现实工作中往往会存在着一次的审批需要多人协作上下级协作后才会生效的情景, 或者是多个不同动作可以达到同样的效果. 所以设计中是允许多个动作对一次转换进行操作的, 即转换 (Transition) 和动作 (Action) 之间是多对多的, 因此:
引入中间表 TransitionAction
| 名称 | 描述 | 类型 |
|---|---|---|
| transition_id | transition_id | integer |
| action_id | action_id | integer |
此外, 活动 (Activity) 是标记转换到状态节点后产生的事件.
可以是当工作进入到了某个状态, 也可以是完成了从某个状态到某个状态的转换触发的.
活动 (Activity) 的设计
活动 (Activity) 本身的设计和动作 (Action) 结构类似, 不同的是在不同系统中 Activity 是可以被多态关联到不同的动作事件的, 在这就不引申出去讲.
回到事件本身, 可以是由 state 触发的, 也可以是 Transition 触发的, 他们之间亦是多对多的关系
设计表: 略
5. 工作流请求 (Request) 的设计
在我们的工作流引擎中，将请求定义为: 在某一个流程下由某个用户发起的一次申请, 请求具有以下基本部分：
- 基本信息：标题，创建日期，创建用户和当前状态 ID。
- 数据：与单个请求相关的可变数据集。
- 利益相关者：一组将接收有关请求的定期更新的用户。
- 文件：与单个请求相关的任何文件。
- 备注：用户输入的与个人请求相关的任何注释。
- 请求操作：可以在请求的任何给定时间执行的操作
请求 (Request) 的设计
请求是在流程下的一次操作所以表的设计可能包含:
| 名称 | 描述 | 类型 |
|---|---|---|
| id | id | integer |
| process_id | 关联流程的 id | integer |
| title | 请求的标题 | string |
| user_id | 请求的用户 | integer |
| current_state_id | 请求的用户 | integer |
| requested_at | 请求的时间 | datetime |
在不同的工作流程下, 请求需要发送的数据可能都不一样, 所以针对请求数据 (RequestData) 也做了一层包装:
| 名称 | 描述 | 类型 |
|---|---|---|
| id | id | integer |
| request_id | 所属请求的 id | integer |
| key | 数据的 key | string |
| value | 数据的 value | string |
一次的请求也可能要包含通知的对象(User). 利益相关者(RequestStakeHolder)
| 名称 | 描述 | 类型 |
|---|---|---|
| request_id | 所属请求的 id | integer |
| user_id | 所属用户的 id | integer |
当然一次完整的工作流程不只包含了这些, 它可能会有关联的文件(Attach), 备注(Note), 这些都可以用基础的附件, 备注对象多态关联到各个步骤下所需要的地方去.
6. 工作流请求操作 (RequestAction) 的设计
到目前为止，我们建立的所有基础设施都已经基本完成。最后，我们可以构建模式的最后一部分：Request Actions 表。
请求操作(RequestAction) 的设计
请求操作(RequestAction)
我们现在拥有用户可以执行的操作来调用 Transitions, 当然请求是不能执行任何操作的, 只执行我们配置的范围内的动作.
让我们先看看 RequestActions 表的模式，然后展示它将如何实际使用：
| 名称 | 描述 | 类型 |
|---|---|---|
| id | id | integer |
| request_id | 所属请求的 id | integer |
| action_id | 所属操作的 id | integer |
| transition_id | 所属转换的 id | integer |
| is_active | 是否可执行 | boolean |
| is_complete | 是否已完成 | boolean |
我们是如何来使用 request_action 的呢
- 当请求进入状态时，我们从该状态获得所有符合的转换。对于那些 Transitions 中的每个 Action，我们构建出 RequestAction 对象，且 is_active = true，is_completed = false。
- 用户可以随时提交动作。每个提交的 Action 都包含一个 RequestID 和一个 UserID。
- 提交操作时，我们检查指定请求的 RequestActions。如果提交的 Action 与其中一个（is_active = true）的活动 RequestActions 匹配，设置 is_active = false 和 is_completed = true。
- 将提交的操作标记为已完成后，我们将检查该请求 (Request) 中该转换 (Transition) 的所有操作(RequestAction)。如果所有 RequestActions 都标记为已完成，那么我们将禁用所有剩余的操作（通过设置 is_active = false，例如，未匹配的 Transitions 的所有操作）。
实例演示:
工作流有
状态(State): A(开始), B(同意), C(拒绝)
转换(Transition): A -> B（ID 1），A -> C（ID 2），B -> C（ID 3）
过渡行动(Action)：
A – > B：申请人批准（ID 1）并由主管批准（ID 2）
A – > C：被高管拒绝（ID 3）
B – > C：被请求者拒绝（ID 4）
创建
申请人甲创建了一个请求 (ID 1), 该请求立即被置于 A 状态。
此时, 系统将查找状态 A 的所有转换，并找到其中两个转换，转换 1 和 2. 然后，它将以下数据加载到 RequestActions 中：
| 请求 ID | 动作 ID | 转换 ID | is_active | is_completed |
|---|---|---|---|---|
| 1 | 1 | 1 | true | false |
| 1 | 2 | 1 | true | false |
| 1 | 3 | 2 | true | false |
现在请求只是处于当前状态，等待提交动作。
提交
当甲提交申请后, 状态流转到 A, 变成了可以同意可以拒绝的形态.
| 请求 ID | 动作 ID | 转换 ID | is_active | is_completed |
|---|---|---|---|---|
| 1 | 1 | 1 | false | true |
| 1 | 2 | 1 | true | false |
| 1 | 3 | 2 | true | false |
批准
领导乙批准了甲的申请
| 请求 ID | 动作 ID | 转换 ID | is_active | is_completed |
|---|---|---|---|---|
| 1 | 1 | 1 | false | true |
| 1 | 2 | 1 | false | true |
| 1 | 3 | 2 | true | false |
注意，此时因为转换 Transition 1 的两个动作都已完成，我们现在必须遵循转换 1 并将请求移动到下一个状态，即状态 B. 在我们转到状态 B 后，我们从该状态加载转换的动作并禁用任何旧的行动;
即, 状态流入 B 后, A->B 之间的 Transition(1) 的所有 Action(1, 2) 都被完成了, is_completed = true
并且, 处于状态 A 的所有 Action(1, 2, 3)都被禁用了. is_active = false
| 请求 ID | 动作 ID | 转换 ID | is_active | is_completed |
|---|---|---|---|---|
| 1 | 1 | 1 | false | true |
| 1 | 2 | 1 | false | true |
| 1 | 3 | 2 | false | false |
| 1 | 4 | 3 | true | false |
7. 结语
以上就是关于工作流引擎的表结构设计