mirror of
https://gitee.com/dotnetchina/OpenAuth.Net.git
synced 2025-09-21 02:57:54 +08:00
72 lines
2.9 KiB
Markdown
72 lines
2.9 KiB
Markdown
# 工作流中的概念
|
||
|
||
|
||
## 并行网关
|
||
|
||
并行网关处理的是流程分支和汇聚，每个分支可以是不同的业务逻辑和不同的处理人。它有以下特点：
|
||
|
||
- 分支时：所有出口流向都会被激活（创建多条并行路径）
|
||
- 汇聚时：等待所有进入的分支完成才继续往下执行
|
||
- 每条路径通常由不同的活动和不同的处理人完成
|
||
- 路径之间互相独立
|
||
|
||
在网关开始时（即分支时），可以设置并行网关的类型，目前支持两种模式：全部通过和至少一个通过。如下：
|
||
|
||
|
||
全部通过：网关所有分支审批通过，节点审批通过。
|
||
|
||
至少一个通过：网关中任意一个分支审批通过，节点审批通过。
|
||
|
||
具体的审批人员或角色，需要在【网关开始】和【网关结束】之间的节点配置，如上图中的admin、test。
|
||
|
||
## 会签
|
||
|
||
会签又称为联名签署，处理的是同一个任务需要多人审批的情况。它的特点：
|
||
|
||
- 是同一个任务的多个副本
|
||
- 分配给多个执行人执行相同的工作
|
||
- 可以设置完成条件（如全部通过、部分通过即可）
|
||
- 处理的是同一个业务节点，只是执行人不同
|
||
|
||
## 加签
|
||
|
||
有时需要在原有审批流程中**临时**增加一个或多个审批节点，这时就需要用到加签的功能。它通常有以下特性：
|
||
|
||
* 临时性：加签是在流程执行过程中临时增加的，并非流程设计时就已经固定的审批节点。
|
||
|
||
* 发起主体：加签通常由当前审批人发起，他们认为需要额外的人员进行审核或批准。
|
||
|
||
* 新增审批节点：加签会在当前审批节点之后，插入一个或多个新的审批节点，这些节点需要审批通过后，原流程才能继续执行。
|
||
|
||
* 不改变流程结构：加签不会改变原有流程的整体逻辑或终点，只是插入临时节点，完成后流程继续按原定路径执行。
|
||
|
||
|
||
#### 与会签的区别：
|
||
|
||
* 加签：在已有审批流程上临时添加审批人，原审批人仍有审批权。
|
||
|
||
* 会签：多个审批人同时审批，所有会签人均需审批，才能通过节点。
|
||
|
||
加签功能常用在遇到不明确的情况时，需要其他人协助处理。
|
||
|
||
|
||
|
||
|
||
## 条件分支
|
||
|
||
有时需要根据提交数据不同（如报销金额、请假天数等）流程转向不同的审批者。这时需要在连线上面配置分支条件，如下图：
|
||
|
||
|
||
|
||
|
||
## 知会
|
||
|
||
知会指的是在流程执行过程中，将审批结果通知给指定人员，但这些人员不参与实际审批或决策过程。知会的目的是确保相关人员知晓流程的进展或结果，但他们不会影响流程的走向。如下图：
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|