前段时间公司在做一个oa的项目，用到了flowable工作流，刚开始的时候还在纠结于是用activity还是flowable，后来查了相关资料发现flowable的作者之前就是开发activity的作者，只不过后来自己出去又搞了一套就叫做flowable，
所以不需要纠结用哪一套，实际在研究了一段时间后发现两者差别并不是很大，基本都可以满足常用的工作流的开发，我这边由于领导指定了要用flowable，所以整个项目的工作流基于flowable引擎。到目前为止研究的时间也并没有多长，其中也遇到很多迷茫的地方，希望能把自己的心得体会跟大家分享一下。本篇文章主要适用于第一次接触工作流的读者能够对工作流的开发过程有个大概的了解，本文不涉及太详细的介绍。
1.流程图设计
在进行工作流的开发时，第一个要做的事就是设计流程图，流程图的主要作用有两个，一个是用来启动一个流程，另一个就是在查看流程走向时需要用到。
流程图的设计一般需要用到专门的工具，以前的做法是在eclipse中安装一个Activiti BPMN2.0 designer插件，现在idea里面好像也支持安装这个插件，不过版本都比较老，现在一般的项目都集成flowable的web版本的流程设计，提供ui设计界面，比较方便，如下图所示：

设计完保存后的文件是一个bpmn文件，可以直接用来生成一个xml文件，这两个文件都可以看作是流程的定义文件，也都可以用来部署流程。
（1）任务执行人设置
流程设计图中一个很重要的步骤就是设置流程中每个任务的执行人,执行人的设计分为静态设置和动态设置。所谓静态设置即在设计流程图的时候就制定执行人,在任务激活后的分配（Assgin）一栏中直接填写执行人，执行人的内容可填写用户id也可填写用户名字；动态设置则是指在流程的运行过程中动态的给任务指定执行人，不过在指定的时机上要注意，一般不能晚于要指定的任务的上一个任务结束前，动态指定的方法一般是给执行人设定一个表达式，例如${executor},然后在代码中通过给execcutor设置值来指定。
执行人设置的方式又可以分为3种：第一种是指定单个用户，就是说这个任务只有一个可选执行人；第二种是多个候选人，就是说可能存在多个候选人来执行这一任务，候选人都可以在自己的待办任务看到这个任务，在执行任务时要进行签收，一旦其中一个候选人签收了任务，其他候选人就看不到该任务；第三种方式是候选组，只要属于该组的用户都可以看到该任务，不需要签收任务，可直接办理任务。
（2）业务表单
为什么需要业务表单？想象一个请假流程，你在提交请假流程的时候必须得填写请假时间，请假理由吧。。。。业务表单的作用就是用来存储这些数据的，在设计流程图中任务视图有一栏叫做formKey的，就是用来对应业务表单的。
2.流程的部署
流程的部署有多种方式，一般是通过加载流程的定义文件来部署的。
在讨论部署之前大致看一下流程引擎API的大致结构如下图所示:

图片参考至官网，https://www.flowable.org/docs/userguide/index.html#apiEngine
最上层ProcessEngineConfiguration以及flowable.cfg.xml用来配置流程的基本信息，包括数据库信息、事务管理等。
在实际的应用中我们一般在flowable.cfg.xml中配置了如下:





其中repositoryService一般用来获取流程定义的基本信息，查询引擎已知的部署和流程定义，一般是一些流程的静态信息。
runtimeService是我们会经常用到的对象，可以从这个服务类中获取很多关于流程执行相关的信息。
taskService是任务服务类，可以从这个类中获取任务的信息；查询分配给用户或组的任务；创建新的独立任务。这些是与流程实例无关的任务；操作分配任务的用户或以某种方式参与任务的用户。
historyService是历史服务类，可以用来查询已经完成的流程、任务相关信息。
managementService管理服务类，可用来进行Job任务管理，执行数据库相关操作，执行引擎命令。
还有一些服务类对象没有介绍了，大致可参考官网的详细介绍。说了这么多，也就是我们在工作流开发中启动流程、查询流程、设置流程等相关操作都会用到上面的对象，具体方法就不再这里详说了。
再来看看流程的部署方式：
部署流程资源有很多种方法，包括classpath、InputStream、字符串、zip格式压缩包，可参考https://blog.csdn.net/ctwy291314/article/details/81285408
流程部署成功后就可以进行测试了，看看流程的流转是否按照自己设计的模型运转。