Flowable学习心得
参考文档：
l https://www.freesion.com/article/50381339562/ (FLOWABLE自定义属性添加,未来可考虑添加那些选人的name)
l https://tkjohn.github.io/flowable-userguide/
l https://www.cnblogs.com/phyger/p/14067201.html (flowable表结构说明及数据字典说明)
l http://www.blackzs.com/archives/1557
（flowable model设计器）
Flowable的所有数据库表都以ACT_开头。第二部分是说明表用途的两字符标示符。服务API的命名也大略符合这个规则。
ACT_RE_*: 'RE’代表repository。带有这个前缀的表包含“静态”信息，例如流程定义与流程资源（图片、规则等）。
ACT_RU_*: 'RU’代表runtime。这些表存储运行时信息，例如流程实例（process instance）、用户任务（user task）、变量（variable）、作业（job）等。Flowable只在流程实例运行中保存运行时数据，并在流程实例结束时删除记录。这样保证运行时表小和快。
ACT_HI_*: 'HI’代表history。这些表存储历史数据，例如已完成的流程实例、变量、任务等。
ACT_GE_*: 通用数据。在多处使用。
a. 一般数据(2)
ACT_GE_BYTEARRAY 通用的流程定义和流程资源
ACT_GE_PROPERTY 系统相关属性
b. 流程历史记录(8)
ACT_HI_ACTINST 历史的流程实例
ACT_HI_ATTACHMENT 历史的流程附件
ACT_HI_COMMENT 历史的说明性信息
ACT_HI_DETAIL 历史的流程运行中的细节信息
ACT_HI_IDENTITYLINK 历史的流程运行过程中用户关系
ACT_HI_PROCINST 历史的流程实例
ACT_HI_TASKINST 历史的任务实例
ACT_HI_VARINST 历史的流程运行中的变量信息
c. 用户用户组表(9)
ACT_ID_BYTEARRAY 二进制数据表
ACT_ID_GROUP 用户组信息表
ACT_ID_INFO 用户信息详情表
ACT_ID_MEMBERSHIP 人与组关系表
ACT_ID_PRIV 权限表
ACT_ID_PRIV_MAPPING 用户或组权限关系表
ACT_ID_PROPERTY 属性表
ACT_ID_TOKEN 系统登录日志表
ACT_ID_USER 用户表
d. 流程定义表(3)
ACT_RE_DEPLOYMENT 部署单元信息
ACT_RE_MODEL 模型信息
ACT_RE_PROCDEF 已部署的流程定义
e. 运行实例表(10)
ACT_RU_DEADLETTER_JOB 正在运行的任务表
ACT_RU_EVENT_SUBSCR 运行时事件
ACT_RU_EXECUTION 运行时流程执行实例
ACT_RU_HISTORY_JOB 历史作业表
ACT_RU_IDENTITYLINK 运行时用户关系信息
ACT_RU_JOB 运行时作业表
ACT_RU_SUSPENDED_JOB 暂停作业表
ACT_RU_TASK 运行时任务表
ACT_RU_TIMER_JOB 定时作业表
ACT_RU_VARIABLE 运行时变量表
f. 其他表(2)
ACT_EVT_LOG 事件日志表
ACT_PROCDEF_INFO 流程定义信息
ProcessEngine processEngine = ProcessEngines.getDefaultProcessEngine();
RuntimeService runtimeService = processEngine.getRuntimeService();
RepositoryService repositoryService = processEngine.getRepositoryService();
TaskService taskService = processEngine.getTaskService();
ManagementService managementService = processEngine.getManagementService();
IdentityService identityService = processEngine.getIdentityService();
HistoryService historyService = processEngine.getHistoryService();
FormService formService = processEngine.getFormService();
DynamicBpmnService dynamicBpmnService = processEngine.getDynamicBpmnService();
在ProcessEngines.getDefaultProcessEngine()第一次被调用时，将初始化并构建流程引擎，之后的重复调用都会返回同一个流程引擎。可以通过ProcessEngines.init()创建流程引擎，并由ProcessEngines.destroy()关闭流程引擎。
ProcessEngines会扫描flowable.cfg.xml与flowable-context.xml文件。对于flowable.cfg.xml文件，流程引擎会以标准Flowable方式构建引擎：ProcessEngineConfiguration.createProcessEngineConfigurationFromInputStream(inputStream).buildProcessEngine()。对于flowable-context.xml文件，流程引擎会以Spring的方式构建：首先构建Spring应用上下文，然后从该上下文中获取流程引擎。
所有的服务都是无状态的。这意味着你可以很容易的在集群环境的多个节点上运行Flowable，使用同一个数据库，而不用担心上一次调用实际在哪台机器上执行。不论在哪个节点执行，对任何服务的任何调用都是幂等（idempotent）的。
RepositoryService很可能是使用Flowable引擎要用的第一个服务。这个服务提供了管理与控制部署(deployments)与流程定义(process definitions)的操作。在这里简单说明一下，流程定义是BPMN 2.0流程对应的Java对象，体现流程中每一步的结构与行为。部署是Flowable引擎中的包装单元，一个部署中可以包含多个BPMN 2.0 XML文件及其他资源。开发者可以决定在一个部署中包含的内容，可以是单个流程的BPMN 2.0 XML文件，也可以包含多个流程及其相关资源（如’hr-processes’部署可以包含所有与人力资源流程相关的的东西）。RepositoryService可用于部署这样的包。部署意味着将它上传至引擎，引擎将在储存至数据库之前检查与分析所有的流程。在部署操作后，可以在系统中使用这个部署包，部署包中的所有流程都可以启动。
此外，这个服务还可以：
查询引擎现有的部署与流程定义。
暂停或激活部署中的某些流程，或整个部署。暂停意味着不能再对它进行操作，激活刚好相反，重新使它可以操作。
获取各种资源，比如部署中保存的文件，或者引擎自动生成的流程图。
获取POJO版本的流程定义。它可以用Java而不是XML的方式查看流程。
与提供静态信息（也就是不会改变，至少不会经常改变的信息）的RepositoryService相反，RuntimeService用于启动流程定义的新流程实例。前面介绍过，流程定义中定义了流程中不同步骤的结构与行为。流程实例则是流程定义的实际执行过程。同一时刻，一个流程定义通常有多个运行中的实例。RuntimeService也用于读取与存储流程变量。流程变量是流程实例中的数据，可以在流程的许多地方使用（例如排他网关经常使用流程变量判断流程下一步要走的路径）。RuntimeService还可以用于查询流程实例与执行(Execution)。执行也就是BPMN 2.0中 'token' 的概念。通常执行是指向流程实例当前位置的指针。最后，还可以在流程实例等待外部触发时使用RuntimeService，使流程可以继续运行。流程有许多等待状态(wait states)，RuntimeService服务提供了许多操作用于“通知”流程实例：已经接收到外部触发，流程实例可以继续运行。
对于像Flowable这样的BPM引擎来说，核心是需要人类用户操作的任务。所有任务相关的东西都组织在TaskService中，例如：
查询分派给用户或组的任务
创建独立运行(standalone)任务。这是一种没有关联到流程实例的任务。
决定任务的执行用户(assignee)，或者将用户通过某种方式与任务关联。
认领(claim)与完成(complete)任务。认领是指某人决定成为任务的执行用户，也即他将会完成这个任务。完成任务是指“做这个任务要求的工作”，通常是填写某个表单。
IdentityService很简单。它用于管理（创建，更新，删除，查询……）组与用户。请注意，Flowable实际上在运行时并不做任何用户检查。例如任务可以分派给任何用户，而引擎并不会验证系统中是否存在该用户。这是因为Flowable有时要与LDAP、Active Directory等服务结合使用。
FormService是可选服务。也就是说Flowable没有它也能很好地运行，而不必牺牲任何功能。这个服务引入了开始表单(start form)与任务表单(task form)的概念。 开始表单是在流程实例启动前显示的表单，而任务表单是用户完成任务时显示的表单。Flowable可以在BPMN 2.0流程定义中定义这些表单。表单服务通过简单的方式暴露这些数据。再次重申，表单不一定要嵌入流程定义，因此这个服务是可选的。
HistoryService暴露Flowable引擎收集的所有历史数据。当执行流程时，引擎会保存许多数据（可配置），例如流程实例启动时间、谁在执行哪个任务、完成任务花费的事件、每个流程实例的执行路径，等等。这个服务主要提供查询这些数据的能力。
ManagementService通常在用Flowable编写用户应用时不需要使用。它可以读取数据库表与表原始数据的信息，也提供了对作业(job)的查询与管理操作。Flowable中很多地方都使用作业，例如定时器(timer)，异步操作(asynchronous continuation)，延时暂停/激活(delayed suspension/activation)等等。后续会详细介绍这些内容。
DynamicBpmnService可用于修改流程定义中的部分内容，而不需要重新部署它。例如可以修改流程定义中一个用户任务的办理人设置，或者修改一个服务任务中的类名。
Process存在多个部署版本，模型也存在多个部署版本。这样的好处是，当老的流程和新的流程都希望同时运行时，能做到互相不干扰。
Flowable只有受理人,候选人,候选组这三个办理人的概念。可以通过设置${userid}进行动态设定，但是这样做也不是很方便，因为对于系统来讲有很多的办理人是非常灵活的，例如领导，指定下个角色或部门或办理者(多人，多部门，多角色等等)。如果要做到非常灵活，则需要在代码中动态的设置受理人，候选人，候选组。 但由于flowable的流程可以非常复杂（主流程，子流程，各种task(usertask只是其中一种）），导致找下一个节点非常难。但可以在设计阶段，限制流程不使用子流程，不使用其他task则相对来讲，解决了大量的复杂度。
另外切记，flowable的各种service，基本都是多线程的异步执行，这就导致代码中执行了完成任务，但是数据库的数据可能还没有开始改动，这个时候如果获取新的任务则得到的是老数据或者空数据。目前是通过sleep 2秒钟解决了该问题，但这种方式不好。可以换成2次前端请求解决该问题，但那样做更浪费性能。
Flowable有自己的表达式判断方式，通过command的方式，可以使用flowable自带的表达式计算。目前本项目已经实现了该功能。
流程，部署，模型，任务，实例，历史实例，多实例，监听，办理者，变量，起始者，挂起，激活，跳转条件，跳过条件，备注等等这些概念都应该熟悉，否则很难理解flowable的运行机制。
从引擎中查询数据有两种方式：查询API与原生(native)查询。查询API可以使用链式API，通过编程方式进行类型安全的查询。你可以在查询中增加各种条件（所有条件都用做AND逻辑），也可以明确指定排序方式。下面是示例代码：
List<Task> tasks = taskService.createTaskQuery()
.taskAssignee("kermit")
.processVariableValueEquals("orderId", "0815")
.orderByDueDate().asc()
.list();
有时需要更复杂的查询，例如使用OR操作符查询，或者使用查询API不能满足查询条件要求。我们为这种需求提供了可以自己写SQL查询的原生查询。返回类型由使用的查询对象决定，数据会映射到正确的对象中（Task、ProcessInstance、Execution，等等）。查询在数据库中进行，因此需要使用数据库中定义的表名与列名。这需要了解内部数据结构，因此建议小心使用原生查询。数据库表名可以通过API读取，这样可以将依赖关系减到最小。
List<Task> tasks = taskService.createNativeTaskQuery()
.sql("SELECT count(*) FROM " + managementService.getTableName(Task.class) +
" T WHERE T.NAME_ = #{taskName}")
.parameter("taskName", "gonzoTask")
.list();
long count = taskService.createNativeTaskQuery()
.sql("SELECT count(*) FROM " + managementService.getTableName(Task.class) + " T1, " +
managementService.getTableName(VariableInstanceEntity.class) + " V1 WHERE V1.TASK_ID_ = T1.ID_")
.count();
流程实例按步骤执行时，需要使用一些数据。在Flowable中，这些数据称作变量(variable)，并会存储在数据库中。变量可以用在表达式中（例如在排他网关中用于选择正确的出口路径），也可以在Java服务任务(service task)中用于调用外部服务（例如为服务调用提供输入或结果存储），等等。
流程实例可以持有变量（称作流程变量 process variables）；用户任务以及执行(executions)——流程当前活动节点的指针——也可以持有变量。流程实例可以持有任意数量的变量，每个变量存储为ACT_RU_VARIABLE数据库表的一行。
只是在classpath中添加依赖，并使用@SpringBootAplication注解，就会在幕后发生很多事情：
自动创建了内存数据库（因为classpath中有H2驱动），并传递给Flowable流程引擎配置
创建并暴露了Flowable的ProcessEngine、CmmnEngine、DmnEngine、FormEngine、ContentEngine及IdmEngine bean
所有的Flowable服务都暴露为Spring bean
创建了Spring Job Executor
并且：
processes目录下的任何BPMN 2.0流程定义都会被自动部署。创建processes目录，并在其中创建示例流程定义（命名为one-task-process.bpmn20.xml）。
cases目录下的任何CMMN 1.1事例都会被自动部署。
forms目录下的任何Form定义都会被自动部署。
首先需要有流程定义，也就是ProcessDefinition，也就是需要部署流程。然后通过runtimeService启动实例：
runtimeService.startProcessInstanceByKey("processKey", variables);
启动完实例后，会创建一个执行(execution)，后期的流转就靠执行往下进行。
Process是流程总的定义概览，例如一个流程包括多个流程图，多个子流程，多个决策模型等等。可以通过打包的方式然后在Flowable中进行Deploy。 Deploy后产生DeployId进行信息关联。
Model是指在Flowable提供的流程模型设计器中进行设计。单纯的新建的Model只是在ACT_RE_MODEL中有数据，一旦进行了模型设计并且进行了保存，则相关的ACT_GE_BYTEARRAY中会存入xml数据及png数据。Process可以转换成Model。
Deploy是指发布模型，这样使用者就可以启动流程了。Deploy后，会在ACT_RE_DEPLOYMENT表中保存相关数据。
act_re_deployment：流程模型部署对象表。
每部署一次生成一条记录，首先生成这条数据，它的id主键将会被act_re_procdef和act_ge_bytearray作为外键。
act_re_procdef：流程定义表。
一次部署可能采用zip/bar进行部署，里面是有多份流程定义文件xml的，这时候act_re_deployment只有一条部署信息，但act_re_procdef有多个记录（一个流程定义对应一条），这个表有DEPLOYMENT_ID_外键字段，用它关联act_re_deployment。
act_ge_bytearray：资源文件表。
流程模型资源文件的真正存放地方，它每部署一次就会产生2条记录，一条是关于bpmn规范的文件内容存放在BYTES字段中，另一条是图片信息，采用二进制格式存储。
提示：可以部署后解析bpmn文件的内容自动生成流程图，实现流程图的跟踪线路。
act_re_model：这张表，在xml进行部署时，它没有内容(flowable放弃了此表改用act_de_model保存流程模型信息）
参考：
https://blog.csdn.net/weixin_39604685/article/details/111947153
事务的使用过程中，用的最多的传播行为是require，在大部分的mis系统里，可以对整个业务层切一个require的事务就可以满足需要。
但spring提供的不仅如此，对于复杂的业务，Spring也提供了相应的事务传播行为来满足业务需要。
Spring中的传播行为如下：
Require：支持当前事务，如果没有事务，就建一个新的，这是最常见的；
Supports：支持当前事务，如果当前没有事务，就以非事务方式执行；
Mandatory：支持当前事务，如果当前没有事务，就抛出异常；
RequiresNew：新建事务，如果当前存在事务，把当前事务挂起；
NotSupported：以非事务方式执行操作，如果当前存在事务，就把事务挂起；
Never：以非事务方式执行，如果当前存在事务，则抛出异常。
Nested：新建事务，如果当前存在事务，把当前事务挂起。与RequireNew的区别是与父事务相关，且有一个savepoint。
其中，Require、Supports、NotSupported、Never两个看文字也就能了解，就不多说了。而Mandatory是要求所有的操作必须在一个事务里，较Require来说，对事务要求的更加严格。
RequireNew：当一个Require方法A调用RequireNew方法B时，B方法会新new一个事务，并且这个事务和A事务没有关系，也就是说B方法出现异常，不会导致A的回滚，同理当B已提交，A再出现异常，B也不会回滚。
Nested：这个和RequireNew的区别是B方法的事务和A方法的事务是相关的。只有在A事务提交的时候，B事务都会提交。也就是说当A发生异常时，A、B事务都回滚，而当B出现异常时，B回滚，而A回滚到savepoint
说完了事务传播的行为，现在再说下事务隔离级别，事务隔离级别的出现，是为了使你在性能与数据的有效性之间做一个平衡，不是说级别越高越好，只有合适才是最好的。
事务隔离级别如下：
Serializable：最严格的级别，事务串行执行，资源消耗最大；
Repeatable Read：保证了一个事务不会修改已经由另一个事务读取但未提交(回滚)的数据。
Read Committed：大多数主流数据库的默认事务等级，保证了一个事务不会读到另一个并行事务已经修改但未提交的数据。适用于大多数系统。
Read Uncommitted：保证了读取过程中不会读取到非法数据。
想要理解这四个级别，还需要知道三种不讨人喜欢的事情：
dirty reads：脏读，就是说事务A未提交的数据被事务B读走，如果事务A失败回滚，将导致B所读取的数据是错误的。
non-repeatable reads：不可重复读，就是说事务A中两处读取数据，第一次读时是100，然后事务B把值改成了200，事务A再读一次，结果就发现值变了，造成A事务数据混乱。
phantom read：幻读，和不可重复读相似，也是同一个事务中多次读不一致的问题。但是不可重复读的不一致是因为它所要取的数据集被改变了，而幻读所要读的数据不一致却不是他所要读的数据改变，而是它的条件数据集改变。比如：Select id where name="ppgogo*"，第一次读去了6个符合条件的id，第二次读时，由于事务B把第一个贴的名字由"dd"改成了“ppgogo9”，结果取出来7个数据。
Flowable是采用事务拦截器进行事务处理，传播行为用的是”Require”
扫码关注不迷路！！！
郑州升龙商业广场B座25层
service@iqiqiqi.cn
联系电话：400-8049-474
联系电话：187-0363-0315
联系电话：199-3777-5101
