a workflow engine base on django 基于django的工作流引擎系统,通过http接口调用。 可以作为企业内部统一的工作流引擎，提供诸如权限申请、资源申请、发布申请、请假、报销、it服务等所有工作流场景的服务。如果有一定的开发能力建议只使用后端引擎功能，前端根据场景定制开发可分散于各个内部后台管理系统(如人事、运维、监控、cmdb等等)。

欢迎访问我的博客了解我的设计思路 http://loonapp.com/blog/27/

最新代码见develop分支，正式版本见release中,推荐使用最新的版本.可以直接通过此链接下载release版本, 或者使用�以下命令

git clone git@github.com:blackholll/loonflow.git
git checkout vx.x.x  #(具体的版本号，如v0.1.4）拉取代码

本人2011年开始接触工作流，2013年开始开发工作流第一版本，至今经历了多个版本。目前着手开发一个开源版本，致力于提供企业统一工作流引擎方案

欢迎加入qq群一起交流工作流相关技术: 558788490

LOONFLOW 分为两部分:

• 使用django自带的admin来管理工作流的配置信息
• 提供http api供各个系统(如果oa、cmdb、运维系统、客服系统)的后端调用以完成各自系统定制化的工单需求

loonflow只提供后端调用api和工作流的配置后台，感谢youshutong2080(使用vue.js �, shutongFlow 和jimmy201602(使用bootstrap, 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->另写一份)
• 通过绘制流程图直接生成工作流配置
• 其他待定功能