这是一个创建于 840 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景
当时项目需要实现个审批流，因为当时的流程比较简单，都是些二级审批，没有各种复杂的转派或并列审批等，所以自己实现了个审批流。当时也调研了 Activiti 这样的框架，觉得太重就没使用。现在团队开发遇到的一些问题，想咨询下大家。
我们怎么做的
简单介绍下我们现在的做法，我们定义了一些审批流程框架，举个例子，流程 Flow1-上架一个产品的流程，这个流程的 1 级审批角色，2 级审批角色之类的信息。 每次发起个 Flow1 ，就会生成一个 Flow1Instance ，里面包含这次流程的一些信息，流程状态，下级审批人，发起人，审批成功、拒绝之后的回调请求体（我们是通过回调更新接口来执行审批后的数据变更）之类的信息。 还有个实体是每次 Flow1 中的，每个节点审批具体信息，比如 1 级审批人同意或者驳回。
遇到的问题
1 、每次新增 /编辑流程的信息都包含在回调的 requestbody 里，后面业务提出希望流程发起之前对于这些字段做排重校验，但我们使用关系型数据存储的一个大 json 数据，所以做排重很困难； 2 、我们现在维护实体状态和审批状态有点耦合，比如产品这个实体里，需要同时判断 status 和 auditStatus 两个字段才能得到产品是否可用的状态。
基于以上信息，想咨询下大家有没有更好的轮子或者基于我们目前结构的优化建议
 |
1
murmur 2022-07-21 15:36:53 +08:00
直接买国产的工作流引擎，总有考虑不到的离谱需求，到头来最后还得买第三方
|
 |
2
wolfie 2022-07-21 16:01:05 +08:00
描述有点混乱，建议直接花几天时间参考 activiti 表结构。
|
 |
3
clf 2022-07-21 16:04:37 +08:00
我们是参考泛微 OA 的设计。
把数据、表单展现、流程、数据报表、人事管理等分离。 先定义一个数据表：有哪些字段，字段的类型是什么。这个数据表用于存储数据，你可以配置它的报表，可以配置填写它的表单。 流程引擎只管理流程的流转，人事组织架构来负责按条件取人。流程创建的时候选择一个数据表，每个节点可以配置表单的展现，可以选择性的只读 /隐藏 /可编辑某些字段。 |
 |
4
akakidz 2022-07-21 17:37:52 +08:00
我司使用的 flowable 引擎，涉及的流程比较复杂，后台的业务与工作流是分开设计的，目前遇到最大的问题就是业务和流程冗杂在一起，业务较多时维护起来很痛苦。我是个前端，优化方面没办法给建议，抱歉～
|
 |
5
carrie96 2022-07-21 17:52:09 +08:00
用 bpm 工作流
|
 |
6
Heroininu 2022-07-21 17:55:46 +08:00
审批和业务一定要做分离，审批仅仅用来获得待办、节点流转、处理各节点审核人，其他业务相关的，统一由业务代码管理。
|
 |
7
xiaoyu18369 2022-07-21 17:55:55 +08:00
flowable 挺不错的
|
 |
8
caroline1022 2022-07-21 18:22:10 +08:00
之前也干过一个平台内部简单的审批流。排重的问题也遇到了，我是选择把某些关键字段作为审批表的列存起来，在对 json 验重之前先排除了一大半的无关记录。
状态的问题没遇到，因为我这边的场景是即使某个产品在审批流中，也不影响该产品的可用性。因为不太了解你的具体场景，我在想，是否可以将 status 和 auditStatus 做个状态的结合？当产品进入审批流时，把它的 status 维护成「审批中」，待审批流程结束，再将它的 status 维护成「正常」? |
 |
9
potatowish 2022-07-21 18:40:53 +08:00 via iPhone
activiti 框架是轻量级的啊，找个文档过一下，把流程图画好，提供几个接口出来就可以了
|
 |
12
alexfarm OP |
|
14
clf 2022-07-21 21:30:43 +08:00
@alexfarm #13
所有流程中的表单数据都是体现在绑定的数据表内的，数据表可以是一个绑定多个流程定义。 数据表本身提供了数据变动历史的记录功能（不仅仅是流程里会用到，像其它用到表单的也会用到，属于可选属性，只是流程绑定时默认选择记录变动历史）。 一个流程实例会往这个数据表里创建一份数据，而每次提交时对数据的修改会产生这个数据的历史版本，每次流转都会记录相应的历史版本的 ID 。 整体来说，审批流主要有这么两种： 1. 单纯的审批流，和其它的业务没有关联，这种是最简单的，所有表单填写的历史数据都在数据表里，展示也是对数据表的直接展示。 2. 由业务触发的审批流，这时候需要业务主动创建一个流程，在创建的时候往数据表定义里填入一些业务数据。 第 2 种回调数据有两种方式（其实还有别的方式，各有优劣，自行选择合适的即可）： 1. 按一定规范约定好回调的结构，然后实现这个回调接口，填入到流程定义里。 2. 流程流转的时候会产生相关事件，可以监听消息队列去获得流程的实时状态，并执行一定的逻辑。 也就是说，无论如何，流程的流转一定会引起数据表的变动。无论和其它业务是否挂钩。 |
|
15
clf 2022-07-21 21:42:35 +08:00
@alexfarm #12 flowable 和 activiti 差不多的，就是 activiti 的分支产品，类似的还有 camunda
我也曾经做过相关调研，我们最后没选用的原因就是，作为一个流程引擎它管的东西太多了，很多东西完全可以做成独立的基础服务，而且后续能够让流程开放给用户编辑的可能性不是很大。 还有就是无法满足我们的多租户分库的需求（印象里 camunda 的多租户是用租户 id 标记的），起码改造成我们自己的动态数据源需要比较大的成本。 虽然说用了它可以满足大部分的流程流转需求，但和自己系统要整合到一起的成本，我们评估是大于自己写一套流程引擎。 |
 |
16
rodrick 2022-07-21 21:43:04 +08:00
记得很久以前老东家有买过一个叫驰骋的流程引擎 开源收服务费那种 实在是难用到离谱 购买第三方需谨慎
|
 |
17
ychost 2022-07-21 22:25:28 +08:00
workflow 还是比较复杂，可以采用插件的形式来管理所有的业务，流本身只关心 DAG 图节点之间的上下文依赖和关系，节点的调用是通过 SPI 唤起插件来执行，具体需要取上下文的哪些字段插件业务自己关心就好了，但是流一定要明确状态，至于插件用什么方式实现，可以考虑动态下载 maven jar 包，然后启动即可，这样 ClassLoader 也隔离了，整个流的逻辑也比较清晰，审批只是将插件与流的 DAG 图组装而已。
|
 |
18
chenshun00 2022-07-21 22:36:52 +08:00
没有看明白 flow1Instance 是什么含义，不过这里的审批代表的其实只是只是一个状态，一个流程中包含很多的节点，每个节点可以被 N 个人审批，审批通过以后自然而然到了下一个人。 每一个流程节点都代表了一个审批过程。 这个思路很简单，不过只能应付一些简单的审批场景。
|
 |
19
x86 2022-07-21 22:40:09 +08:00
钉钉省时省力
|
 |
20
codefever 2022-07-21 22:50:37 +08:00
用 Tracup ，上面有审批的模板，可以直接邮件短信通知到审批人，神奇的是，还是免费的
|
 |
21
VKLER 2022-07-21 23:06:35 +08:00
Activiti + 自定义逻辑
|
 |
22
aguesuka 2022-07-22 09:25:11 +08:00
workitem -> workitem-type -> workflow -> workitem-status -> action ->workflow-sginature
也就是说工作项的工作流由它的类型决定, 不同类型可以配置不同工作流. 工作流定义工作项的状态和状态转移, 每个状态转移对应一个 action, 当 action 触发时判断是否需要签名. |
 |
23
unco020511 2022-07-22 10:11:59 +08:00
购买其他公司产品
|
 |
24
coderstory 2022-08-01 17:15:42 +08:00
Activiti 还还好吧。。 我就写了一套 bpml 的 xml 构建工具类
系统里集成了完成的工作量设计 表单设计 流程部署 运行等功能 除非你肯定确定不会有离谱的东西，或者你有信心觉得自己的代码有足够的扩展性。，，，， |
Select Language