当我们在2020年6月从集团金融事业部接收工作流原型时，对我们来说没有可用性，但确实已经有一个初步原型了。感谢前期投入的兄弟们......不管怎么样，都给我们完成了大量的试错工作......

接手后我们用了一周的时间来把原型构建完成，并初步进行了测试.整个体系到实战使用的差距确实很大。我们整个团队2020年才从.net转向Java，任何东西对我们来说都是全新的.......

1.我们的需求

经过2015年对工作流重构后在超大型企业落地，给我们带来了大量的实测数据，也让我们有更大的实现压力。

首先，工作流的独立性

由于工作流引擎是高数据集中操作类型的系统，并且存在大量的及时计算，所以工作流组件需要完成独立，形成独立的体系。

流程设计器、工作流需要消息来驱动流转，但不能绑定消息平台。

其次，工作流的中国化改造

工作流的核心操作时流转，所以存在继续/返回修改/取回操作，并且领导只关注自身的审批事项，不关注是否能正常流转到下一环节，这需要支持由发起人或指定人员能在流程停顿时选择后续分支或审批人员，完成流程流转工作。

再次，工作流的可运营性

工作流是高频操作功能，并与消息平台/第方法平台进行了紧密集成，必须提供全方位的运营支持工具，来快速实现异常流程的矫正。

为了方便业务规划与流程运营管理，对标准化的流程能形成独立流程段（子流程），方便业务管理人员能在业务流程固化时使用子流程，达到简化运营管理的目的。

在执行审批过程中，需要能查看到运行流程全貌。

java activity工作流。为了加快业务进展，流程发起人员能在流程启动前或流程运行中能对流程进行预处理。

对特定单据，能查看到工作流相关的所有数据，并在需要时提供修正功能。

最后，工作流的性能问题

在完成以上所有需求后，还需要能保证一定的性能，以便能支持超大行客户的全集团流程管理需求。

2.我们改造内容

2.1独立性

2.1.1SDK:

工作流是一套慢系统，所以构建的越内聚越好。对外提供标准接口，让外围使用sdk完成业务流转集成。

流程引擎，2.1.2统一流程管理平台（WFBKS)：

1. 引入抽象的业务功能模块，来定义业务系统中的功能，并且在特定的功能下构建一维数据模型定义与存储结构，实现特定业务功能清单与业务功能数据字段元数据，方便动态构建业务数据存储模型。
2. 构建业务模型与业务流程管理体系，提供特定功能下的流程定义，并在流程分支中使用业务模型元数据来定义流转条件。
3. 根据flowable以提供de/re模型，完成业务流程的版本管理，同时隔离出设计期版本与运行期版本。
4. 构建参与流程审批的业务数据索引表，不分类型统一存在数据，形成有业务意义的流程实例清单。
5. 构建基于流程实例清单的流程统一运营入口。
6. 对管理平台的所有操作进行记录，形成统一流程管理平台操作审计数据源。
7. 重新定义了审批人选择方案，支持基于4个层级过滤的审批人选择器，并支持组织/部门/岗位/人员/部门群/岗位群/人员组 相关性能的组合使用。

2.2国情化改造

2.2.1flowable采用了统一大事务，来保证流程能从一个环节能自动流转到下一环节，但中国的企业中往往允许流转断联，并且提供其他方案来完成流程流转。

在这个需求中，我们引入了下一环节探针，来预先检测当前节点是否需要选人或选择执行分支，或者是能自动完成流转，或者是当前审批人不需要考虑后续节点的处理机制（如果能自动流转则自动完成否则流程将有发起人或指定人员来完成流转操作）。

探针提供了：【需要先确认后续环节/自动完成/发起人提交（指定人提交）/会签跳过】等状态。

为了在flowable执行流迁移过程中实现探针结果的上下文继承，我们重新了执行流对象并改造了流转执行流构建。

2.2.2 在特定场景下,会签节点可以由提交人确认是否跳过节点

为节点提供了会签跳过属性配置，根据会签节点的属性，提供了会签节点跳过功能（基于flowable的统一CMD模式构建）。

统一业务平台、2.2.3为方便运营，在设计器中对CallActivity进行了改造，使系统能适应运营要求。

2.2.4 为业务需求，提供了基于审批结论流程走向映射，使系统提供的决策更有语义。

2.2.5提供了运行期审批流全貌数据，并提供了执行顺序与状态信息。

2.2.6基于运行期审批全貌信息，提供了审批流程待处理环节预处理功能。

2.2.7,审批人员单据........

德国再次统一的流程，2.2.8,其他基于国情的改造.....

2.3流程运营管理

基于业务审批数据索引，形成了业务数据管理功能。在特定业务数据界面中，提供了全方位的运营功能。

2.4工作流性能改造

经过今天下午的处理，子流程方案已初步成型，后续将进行运营与系统性能优化改造。

3.其他