a workflow engine base on django 基于django的工作流引擎系统,通过http接口调用。 可以作为企业内部统一的工作流引擎,提供诸如权限申请、资源申请、发布申请、请假、报销、it服务等所有工作流场景的服务。如果有一定的开发能力建议只使用后端引擎功能,前端根据场景定制开发可分散于各个内部后台管理系统(如人事、运维、监控、cmdb等等)。
欢迎访问我的博客了解我的设计思路 http://loonapp.com/blog/27/
最新代码见develop分支,正式版本见release中,推荐使用最新的版本.可以直接通过此链接下载https://github.com/blackholll/loonflow/releases,或者git checkout vx.x.x(具体的版本号,如v0.1.4)拉取代码
本人2011年开始接触工作流,2013年开始开发工作流第一版本,至今经历了多个版本。目前着手开发一个开源版本,致力于提供企业统一工作流引擎方案
欢迎加入qq群一起交流工作流相关技术: 558788490
LOONFLOW 分为两部分:
- 使用django自带的admin来管理工作流的配置信息
- 提供http api供各个系统(如果oa、cmdb、运维系统、客服系统)的后端调用以完成各自系统定制化的工单需求
loonflow只提供后端调用api和工作流的配置后台,感谢youshutong2080(使用vue.js https://github.com/youshutong2080/shutongFlow)和jimmy201602(使用bootstrap, https://github.com/jimmy201602/workflowdemo)分别帮忙写的一个调用方demo.下面是效果图和动画
另外boostrap版本还提供了docker镜像,供新人快速部署:https://hub.docker.com/r/webterminal/workflowdemo/
-
为什么没使用django rest framework
因为不使用外键(为什么不使用?可以百度搜下)且使用框架不够用灵活
-
为什么使用http api方式提供服务
loonflow的理念是:工单应该是嵌入到各个系统中(如oa,cmdb,运维平台、客服系统等等), 这些系统通过后端api调用loonflow。所以loonflow只有管理界面(v0.1版本直接使用django admin,后面会重写管理界面)。后续会提供几个调用方demo供大家参考。感谢@youshutong帮忙写的调用方demo(vue+django): https://github.com/youshutong2080/shutongFlow
-
为何不建议调用方前端直接调用loonflow
调用方和loonflow之前需要做权限验证,签名算法考虑到安全只能写在调用方后端;作为引擎,loonflow不提供用户登录验证功能,只校验调用方的合法性,所以登录验证需要做在调用方自己的后端;每个调用方除了纯粹的工单的功能,还会需要一些额外的功能,比如根据自定义字段筛选工单列表,loonflow提供了工单列表的接,但是因为loonflow的自定义字段是纵表形式存储的,无法提供根据这些字段来筛选工单列表。如果需要自定义字段的筛选,需要调用方自己保存一份工单数据,用于筛选;比如需要做一个项目全生命周期管理的系统,需要用到工作流。 但是还有比如发布,获取人员信息、和其他系统交互、日志查看、项目数据统计等等功能。这些需要做在自己的后端
-
调用方是否需要保存工单的基础数据
根据情况而定,如果调用方在显示工单数据的时候需要显示更多相关信息,可以本地保存一份附属信息与loonflow中对应关系。针对本地保存的情况,如果涉及工单流转的字段(如参与人等),在本地修改时需要同时调用loonflow修改loonflow中保存的字段的值(v0.2版本会提供修改工单字段值的接口)
-
如何限制用户查看工单权限
默认会限制工单的查看权限(通过api获取工单详情时,只有username参数是工单相关人员时才能获取到数据)。如果需要放开限制,可以修改工作流配置中的“查看权限校验”为否。权限配置只针对工作流的,多个类型的工作流需要单独配置
-
为何需要同步用户及部门信息到loonflow
因为工单流转涉及到较多的用户信息获取,所以需要将用户信息(包括部门)同步到loonflow的账户系统中。同步部门信息的时候,如果发现部门被删除,建议修改部门名字,如前面加个 “已废弃:”,否则如果该部门存在某个工单的当前处理人的时候会有问题。用户离职的情况设置is_active=0.另外用户密码请随便填写(为了不允许普通用户登录)。管理员账户请通过python manage.py creatsuperuser来创建。只需要管理员实现一个同步脚本定时执行即可,其他调用方不用考虑此问题
-
如何支持根据工单的自定义字段查询
loonflow只提供工单基础字段的查询,如果需要针对自定义字段的查询,请在自己系统中保存一份工单数据(注意工单处理过程中,如果有字段修改,也需要更新自己系统中的数据)
-
工单列表支持排序
只支持根据创建时间排序。其他字段排序可以在调用方系统中保存一份数据来自己实现排序,然后只有在获取工单详情的时候调用loonflow接口
-
工单类型需要支持多级 比如需要支持“运维�-权限申请-vpn权限申请”。 因为loonflow的工作流只有一级,如果需要支持多级类型,需要在调用方保存一份工单类型与loonflow工作流关联的数据。表字段可以如下:type_id, type_name, up_type_id, loonflow_workflow_id
- 【API】新建工单
- 【API】获取工单列表:待办、关联、创建的工单
- 【API】获取工单详情(区分是否有处理权限,如果处理权限显示处理表单,有查看权限显示展现表单)
- 【API】用户对工单可以做的操作
- 【API】处理工单(提交、保存、同意、拒绝、完成等等配置的操作)
- 【API】获取工单流转记录(工单的历史操作记录)
- 【API】工单step(简化的处理记录顺序图)
- 【API】修改工单状态
- 【API】批量获取工单状态(逗号隔开,简单的状态信息:只包括状态id,状态名称)
- 【API】获取工单状态详情
- 【API】接单(当工单当前的处理人实际为多个人时,支持先接单,然后再处理)
- 【API】转交工单
- 【API】加签工单
- 【内部逻辑】支持在工单流转过程中自动化执行python脚本(可以通过写脚本实现各种定制化的操作)
- 【内部逻辑】必填字段的校验支持不同transiton区分配置是否开启
相关术语(如转交、接单、加签等等)见使用文档
- 【API】提供修改工单字段的值的api
- 【API】工单列表中接口中state对象增加label信息
- 【API】提供接口获取工作流拥有的状态(state)列表
- 【API】工单脚本允许重试执行(执行失败的情况),重试工单脚本的api
- 【API】工单列表接口支持根据state_ids,是否已经结束,工单ids来查询
- 【内部逻辑】自定义字段新增标签字段,用于调用方自行处理逻辑
- 【内部逻辑】工单流水号前缀自定义
- 【内部逻辑】工单的分配支持随机处理、全部处理(工单状态的处理人为多人、部门、角色等实际对应为多个处理人时候,如果该状态设置的分配方式为随机处理,则将会工单处理人设置为其中的某一个人。 如果该状态设置的分配方式为全部处理,那么需要涉及的每个人都处理完才会进入到下一个状态)
- 【内部逻辑】支持条件流转(如请假申请工单,当请假天数>3需要总监审批,当请假天数>5需要CEO审批)
- 【内部逻辑】支持设置transion为同意、拒绝、还是其他属性,并更新工单状态
- 【内部逻辑】待办通知功能(通过自定义的发送消息脚本来发送, 支持通知内容模板自定义)
- 【内部逻辑】新建工单的权限支持(通过权限限制表达式来实现支持限制周期、限制人员、限制级别等等)
- 【内部逻辑】退回操作支持自定义是否退回到目标状态最后一个处理人(如权限申请类型的工单,其中有个状态是运维人员处理中,运维A接单处理完成后,达到申请人验证中,如果申请人发现验证不通过需要退回,可以定义退回到所有运维人员还是只退回到之前处理的运维A)
- 【内部逻辑】API调用授权范围管理:支持根据调用方确定列表范围(不同来源应用只允许查询该应用相关的数据:工单列表、工单详情、等等)
- 【内部逻辑】定时器流转(如果需要工单在某个工单状态下超过多长时间自动流转到下个状态,可以通过此来实现)--使用celery的countdown实现
- 【内部逻辑】工单历史记录中保存当前工单所有信息便于回查(工单每次操作 都会当前工单的所有字段的信息保存起来)
- 【内部逻辑】其他优化(包括部分代码重构,逻辑优化等)
- 优化代码逻辑(重复代码整合等)
- 管理配置后台(admin->另写一份)
- 通过绘制流程图直接生成工作流配置
- 其他待定功能