分布式事务实战——seata整合flowable（一）

seata整合flowable——AT模式实战

章节简介：

1. 背景介绍
2. 实战部分
3. 踩坑和解决方案

1.背景介绍

背景是微服务项目，采用的是seata分布式事务整合flowable工作流引擎。
首先看业务场景，需要做分布式事务改造的分为工作流服务、业务服务两个微服务，其中：

a.工作流服务就是flowable引擎封装的发起流程、审批等部分。
通过工作流引擎提供的ExecutionListener事件监听器在审批结束之后调用业务的审批通过接口。
b.业务服务主要是通过调用flowable服务的送审、接收flowable的审批回调完成自身对业务单据状态的修改。

2.实战——全局事务的发起和验证

整合seata和flowable，关键点在于弄清楚全局事务的发起方，也就是@GlobalTransactional的添加位置。
以下简称工作流服务为workflow，业务服务简称为business。

a).发起流程

发起流程，也就是business传递业务单据的businessKey（业务唯一键），去调用workflow服务的对应发起流程接口，然后workflow成功之后business接收返回。
全局事务添加在business业务服务的发起流程方法上即可，如果需要验证seata的全局事务，参照下图：

如何验证：
可以在workflow发起流程成功但是没有返回之前打断点，正常的情况应当是：

business的sql都已经提交了，可以在数据库查证，但是seata的undo_log表中business本次提交的反向sql没有被删除。

当你在断点位置构造一个异常，可以发现seata的日志会提示：undo_log表的反向sql被执行，全局事务回滚，回滚完成后undo_log表的对应sql记录被删除，分布式验证也就成功了。