activiti6表单引擎_Activiti 6：核心引擎的演进

activiti6表单引擎

本文介绍了有关Activiti核心引擎的变化以及版本6与版本5的区别。此处的所有材料（包括代码示例） 于6月在巴黎展示 ，但我相信也将其写下来是很好的以博客形式供不喜欢看Youtube电影的人使用（尽管我认为这很有趣＆＃55357;＆＃56841;）

如果您不喜欢Actviti 6设计的理论背景，请向下滚动以查看一些不错的Activiti 5 vs Activiti 6示例！

Activiti引擎已有5年历史了。 在过去的五年中，我们看到Activiti取得了长足的发展，如今，它已在世界各地的各种公司和用例中得到广泛使用。 在IT领域，五年是很长的时间，但是事实证明，我们与Activiti一起选择的体系结构是正确的选择。 在过去的五年中，我们还学到了很多关于Activiti的使用方式（也许（滥用）（使用））的信息。

我们确定了我们认为可以改进引擎的四个关键部分。 我们决定一次全部完成所有工作，并在代码中将它们变得干净整洁，而不是一步一步地破解所有这些东西。 那就是Activiti 6引擎。 因此，版本6并不是重写引擎或新引擎，事实上它与版本5完全兼容。Activiti版本6是核心引擎的演进 ，同时考虑了我们在过去五年中学到的所有知识以及我们（开发人员，社区和客户）认为，以尽可能最简洁的方式应对未来五年的用例是必需的。

无论如何，足够的绒毛，让我们深入探讨这四个问题区域。

问题1：模型转换

在Activiti版本5中，流程定义在内部解析为另一个模型（称为流程虚拟机 模型）。 深入研究引擎的人员将看到诸如ActivityImpl，ExecutionImpl，ProcessDefinitionImpl之类的类。 然后，该模型由核心引擎中的“原子操作 ”解释和执行。

这种方法的问题在于该模型与BPMN模型甚至与BPMN规范中描述的某些概念都不匹配1-1。 而且，就像软件层之间的任何模型转换一样，发生的事情是模型细节在层之间泄漏 。 例如，看一下此类 ：低级模型泄漏到行为类中。 您可能会说没关系，但这确实意味着该行为类别的开发人员需要头脑中的思维模型与从BPMN规范中学到的东西不匹配。

版本6中的相同代码看起来像这样 （可以写得短很多，但这是为了清楚起见）：在这里，我们要推理当前BPMN元素上的序列流。 事实证明，当这种行为与BPMN规范对应1-1时，编写此类行为（就像我们对BPMN的核心结构所做的那样）要容易得多。 该代码变得更大量阅读和理解，你可以推理非常复杂的结构有更轻松。

问题2：执行树

从版本5开始的核心目标之一是使数据库的插入次数尽可能少。 我们做了什么：我们（过度）尽可能地优化和重用了执行实体（执行的流程实例的表示）。

这种口头禅的结果是，现在您可以在许多地方找到if-else构造，这些构造可以非常具体地优化特定用例或模式。 问题在于，在版本5中，很难查看数据库中的执行树并确切知道它如何映射到BPMN结构。 如果您想进行动态流程定义和/或实例而不被黑客入侵，这至关重要 。

在版本6中，我们为执行树的结构选择了简单明了的准则，从而使您可以轻松地查看执行树并确切地知道流程实例在何处以及如何执行。

问题3：竞争的运营堆栈

Activiti中的每个API调用都归结为对运行时执行结构的操纵，方法是将更改应用于运行时模型，并将其输入到核心引擎中，在此由“原子操作”对其进行解释。

这是一个好方法，除了在早期，这些操作的堆栈并不是设计为中心的。 相反，可能同时存在多个这样的操作堆栈。 长话短说，这意味着某些模式无法在v5引擎上执行。

在版本6中，我们实现了一个中央议程 ，该议程用于计划所有核心业务。 这可以修复这些模式，同时使流程执行也更易于跟踪和调试 。

问题4：持久性代码

代码自然地增长。 五年前，我们试图很好地保持持久性逻辑的存在……但是在过去的五年中，许多持久性代码无处不在。 这使得不可能用自定义实现换出持久层。

当然，您可以绕开所有方法（论坛上的人都这样做了：）），但是从长远来看，它确实很脏，无法维护。

在版本6中，我们将持久性代码（和实体逻辑）干净地分成了不同的可插入接口。 实际上，这项工作最近才完成。 期待很快有关于它的博客文章。

几个例子

这些仅是Activiti 5引擎无法实现的一些示例，但确实可以在v6上运行。 再有，我们可能可以通过在v5引擎上进行大量的黑客攻击来使它们全部正常工作，但它并不是我们现在在v6引擎中拥有的漂亮干净的解决方案。

示例1：“棘手的包容性合并”

这是我在合作伙伴BP3的博客上找到的一个示例：假设任务A和B已完成。 到此，C完成，并且专用网关条件使其转到E。然后E完成。 此时，D应该变为活动状态，并且流程实例可以完成。

在版本5中，发生的情况是流程实例永远不会完成，因为永远不会到达D。 这样做的原因是，到达包含性合并网关后处于Hibernate状态的执行将不再被激活。

在版本6中，我们通过引入一种“背景ActivityBehavior”解决了此问题（以及类似的模式），使某些构造（例如包含网关）具有背景行为，在这种情况下，可以验证执行条件的条件合并已满。

示例2：“循环和尾递归”

在此示例中，服务任务在到达结束事件之前已被访问1000次。

在Activiti 5中，这导致StackOverflowException（论坛上的许多人都报告了它！）。

在Activiti 6中，此过程将按预期运行。 这样做的原因是使用尾部递归和运行循环实现的集中操作议程。

示例3：“边界事件后的并发性”

不要让示例的大小吓到您，这里的嵌入式子过程实际上并不重要（只在此处打动＆＃55357;＆＃56841;）。

这里真正的问题是边界事件，它具有两个平行的计时器边界事件输出流。 在Activiti 5中，这种模式是不可能的（您必须使用并行网关）。 在Activiti 6中，此操作实际上没有任何工作，因为直接BPMN模型解释不会留下任何其他执行它的方式

我想亲自尝试一下！

对您来说是个好消息！ 我们上周发布了Activiti 6的第一个Beta版 ！

如果您有兴趣为Activiti 6运行新的UI，Tijs 在此处撰写了一篇很棒的文章 。

翻译自: https://www.javacodegeeks.com/2015/09/activiti-6-an-evolution-of-the-core-engine.html

activiti6表单引擎