# workflow
**Repository Path**: kyo153/workflow
## Basic Information
- **Project Name**: workflow
- **Description**: No description available
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 0
- **Created**: 2024-01-17
- **Last Updated**: 2024-01-17
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
# workflow
基于camunda实现的工作流设计
## 0.写在前面 ##
系统中使用了camunda框架作为审批流功能开发的支撑。camunda可基于版本化，可视化等优秀特性，作为审批流底层开发支持十分完善。最新版本为7.13，目前系统中采用的是7.12版本。
camunda的用户手册：https://docs.camunda.org/manual/7.12/
camunda中的特有概念：
```
【流程模板】：流程审批流所设定的流程模板，利用其本质为xml的特性可以反解析和解析
【流程key】：针对一个流程而言，修改更新等操作并不会影响key，流程key作为模板标记（举个栗子：流程key即为身份证号，婴儿版本的你，以及长大1.0版本的你共用同一个身份证号）
【流程id】：标记一个版本的模板，也是一个模板的唯一标记（举个栗子：婴儿版本的你名为yoyo，yoyo作为id即可标记某个具体版本的你）
【流程实例】：根据某一个模板，所创建的审批流实例，即真正运行起来的审批流
【流程task】：审批流实例中的审批任务，一个任务对应一个审批人的审批
【流程节点】：审批流中代表某一个流程中一个节点，一个节点可以对应多个审批人，即多个审批任务。（camunda中将任务节点也称作task，与用户任务不是一回事）
```
camunda的基本特性：
```
【版本化】：同一个模板，允许编辑，但每次编辑将产生一个新版本，旧版本依旧有效，因此不影响旧流程实例的正常运行，并不会因为模板更改而导致之前生成的流程遭到影响。
【参数实时化】：可以在流程创建时，向当前节点中写入参数（map），可以为全局参数，也可以为局部参数（本次开发中尚未用到），这些参数在流程的条件控制时可作为条件进行流程流转，值得注意的是，参数在每个节点都可更改，因此在提交时，即便无更改，也需要带上全部参数，否则参数将丢失。
【流程可更改】：在流程创建后，可以灵活更新流程节点任务，可以流转至其中任一流程节点（不推荐）
```
## 1.审批流数据库设计 ##
①camunda中自带表格
```
ACT_* 开头的都为其自带表格
```
②适配性开发数据表
|表名|用途| 特殊说明 |备注
|:-:|:-:|:-:|:-:|
hec_definition_baseinfo| 记录审批流模板的基本信息（名称，备注）以及适用人员范围|baseinfo针对一个模板只有一个，多个模板版本对应一条baseinfo信息
hec_definition_group| 将模板分组，方便操作人员查询和查看| 将相同用途的不同模板放置于一个组
hec_defintiion_condition| 记录模板中的条件配置信息，用于前端记录，后端业务中无实际意义| 模板的不同版本不覆盖
hec_param| 模板中可自定义一部分参数，在流程中独立于单据参数存在
hec_param_conf| 模板中审批流自定义参数针对每个审批流节点的可见性或编辑性等配置
hec_operator_conf |模板执行人配置（特定人员，基于发起人角色，组织架构角色）等执行人身份信息| 每个审批流节点都需要设置其执行人设置
hec_workflow_receipt_instance| 记录流程实例，以及与单据id的对应关系| 审批流实例记录信息
hec_workflow_task_history| 记录流程实例的任务记录| |后续开发审批流具体节点审批详情等内容用得上
## 2.系统架构设计图 ##
### 流程定义 ###
[](https://postimg.cc/N2YbpBWy)
### 流程实例 ###
[](https://postimg.cc/YjHwJg7F)
## 3.审批流详细功能设计 ##
### 1.审批流的适用范围 ###
```
校验：根据流程模板定义基础信息中存储的适用范围，在创建流程时，根据单据模板传递过来的发起人id，检查其是否在指定适用范围的组织架构内
```
### 2.单据审批确定审批流模板 ###
```
目前根据已知需求，暂定为一个审批单据类型，只对应某一个审批模板，根据单据类型来查询对应的模板，由此来发起流程和后续审批操作
```
### 3.审批流中加签，会签，或签等实现 ###
```
加签：加签利用camunda的特性，在节点进行中可以进行加签。具体实现可见代码
会签：无序全部审批才算通过。camunda支持并行多实例审批，本质上等同于会签。实现上则通过前端控制任务类型，并设置完成条件的相关属性以达到会签效果。
或签：camunda本质上没有或签的，但可以通过多实例并行审批任务，来达到或签的效果。
```
***a.会签***
以模型说明，会签实现上：选择多实例并行模式的用户任务，即“|||”所标记的图标，选择后，右侧属性栏会多出“multi instance”的属性栏，collection即审批人列表的字段，element Variable即为列表中每个item的字段，用于和上面的assignee保持一致，在传入collection后，就会自动为每一个审批人分配任务。
下方的completion condition则为任务节点的完成条件。${nrOfActiveInstance == 0}中的字段nrOfActiveInstance为camunda多实例的系统属性。同类型的属性还有：
```
nrOfInstances：任务总数。
nrOfActiveInstances：尚未完成的任务数。
nrOfCompletedInstances：已经完成的任务数。
```
在会签判断条件中，只需要标记尚未完成的任务数==0即可，在全部完成或无审批人时则会自动跳转至下一流程节点。
由此审批流任务的会签功能实现即达到。
[](https://postimg.cc/8spT7WYS)
***b.或签***
与会签相类似的是，或签同样采用了多实例并行模式的用户任务，与会签有所不同的是，完成条件有所不同，即completion condition为${nrOfCompletedInstances >= 1 || nrOfActiveInstances == 0}。即当剩余待完成任务为0或者完成任务数量大于等于1时，即标记当前审批流节点完成。到此，或签便完成其在camunda上的功能依托。
[](https://postimg.cc/qgvdJrtB)
*上述模板内容均由前端写定，此处说明仅为方便后端人员理解其中设计思路。不拓展来讲还有其他搭配用法，若感兴趣可自行学习。*
### 4.审批流中人员去重的设计 ###
***a.发起任务***
[](https://postimg.cc/tZfDGFZx)
***b.完成任务***
[](https://postimg.cc/9R4tbz8F)