Camunda与Flowable比较： 两个优秀的流程和工作流自动化平台

Camunda与Flowable比较： 两个优秀的流程和工作流自动化平台

这篇博客简要介绍了自动化工作流平台：Camunda 和 Flowable：
Camunda 和 Flowable 是两个用于工作流和业务流程自动化的开源平台，它们为工作流、业务流程和规则的创建、管理和可视化提供工具。

Camunda 和 Flowable 均基于 BPMN 2.0 标准 ( https://www.omg.org/spec/BPMN/2.0/PDF )构建，该标准为工作流建模提供图形符号，包括业务流程和规则、用户界面、执行、监控, 和优化。

Camunda 和 Flowable 都是 Activiti 的分支，Activiti 是一种业务流程自动化工具，据信其功能和功能不如 Camunda。

然而，与 Activiti 相比，Flowable 具有与 Camunda 非常相似的功能。Camunda 于 2013 年从 Activiti 分离出来，Flowable 于 2016 年从 Activiti 分叉出来，由与 Activiti 相同的工程师开发。

用户界面
Camunda 提供免费的建模工具。它有网页版和桌面版。这两个版本都使您能够对 BPMN 图、DMN 决策、表单和外部系统的连接器进行建模，而无需接触 xml 文件。如果您希望查看或编辑原始 xml 文件，该工具也允许您这样做。

Camunda 不再支持 Eclipse 或 InteliJ 插件，并鼓励您改用 Camunda 建模器。
Camunda 建模器是一个独立的工具，不依赖于任何 IDE。如果我们将 BPMN 文件设置为与操作系统中的 Camunda 建模器相关联，那么 BPMN 文件将从我们选择的 IDE 在 Camunda 建模器中打开。

Flowable 的用户界面类似于 Camunda。Flowable自带Eclipse插件——Flowable Eclipse Designer。所以如果我们的项目是在Eclipse中，就很方便了，不用从Eclipse跳到外部工具去新建模型。
该插件还有其他方便的功能，例如，它允许为 Flowable 图表自动生成单元测试。

我们可以通过使用 Flowable web application – Flowable modeller 来避免使用 Eclipse。另外，Intelij IDEA 有一个 Flowable BPMN visualizer插件，允许用户在 InteliJ 中查看和编辑 Flowable 图表。但遗憾的是，我们仍然需要 Eclipse 或 Flowable 建模器来创建新的 Flowable Diagram。

Camunda 和 Flowable 用户界面都是高度可定制的。例如，我们可以创建自定义元素、连接器和形状来表示特定于我们业务领域的事物。

对于 Camunda 建模器，可以通过更改安装文件夹中的 css 文件 (app.css) 来更改外观。此外，Camunda 允许添加具有不同功能的插件，这些插件可以从 GitHub 开发或下载。

自定义插件是使用 JavaScript 和 Camunda Modeller API 开发的。要加载我们的自定义插件，您需要在 config.app.js 文件的插件部分指定我们插件的路径。我们还可以创建具有预定义值的自定义元素模板。要在 Camunda 中创建元素模板，我们需要创建一个实现 Camunda 元素模式的 json。

Flowable 允许扩展 Flowable Designer 的功能。可以扩展托盘和输出格式。与应用js插件的Camunda相比，Flowable Designer的扩展是JAR文件。

Flowable 目前不支持像 Camunda 这样的元素模板。

除了建模功能外，这两个平台还提供用于监控性能、任务分配和管理的 UI。Camunda 提供 Camunda Cockpit，用于监控工作流和业务流程性能、识别和修复业务流程或决策表中的问题、暂停流程、编辑和删除任务以及将流程实例迁移到新版本。

Flowable 没有像 Camunda 这样的驾驶舱应用程序，但它有不同的应用程序用于单点登录、角色和访问管理（Flowable IDM）、任务管理，包括启动和停止流程实例（Flowable 任务），以及包括基本的管理工作监控和更改业务流程（Flowable admin）。

与 Flowable 相比，Camunda 允许在单个应用程序中更好地控制和调查问题及其解决方案。

建模特点
这两个平台都支持建模业务流程 (BPMN) 和决策表 (DMN)。而最近Camunda也包含了Flowable同样提供的表单创建和任务分配。我们可以在我们的建模器中创建一个表单并将该表单分配给用户任务。

此外，Camunda 和 Flowable 支持 DRD – Decision Requirement Diagram。它允许使用单个 DRD 对多个决策表进行建模，而不是使用具有多个结果规则的流程来聚合决策表。

Flowable 以支持和生成 CMMN 引擎（案例管理模型和符号）的更多功能来应对不可预测的流程而自豪。Flowable 声称，将 CMMN、BPMN 和 DMN 结合在一个工具中，允许开发人员创建非常人性化和事件驱动的问题模型。另一方面，Camunda 停止开发基于 CMMN 引擎的功能。在 Camunda 建模器中打开 CMMN 是可能的，但默认情况下，它是关闭的。其背后的原因是，根据 Camunda 团队的研究，只有少数开发人员使用 CMMN。根据 Camunda 代表的说法，大多数流程都是可预测的，与可预测环境的小偏差可以通过子流程建模。

Flowable 还允许动态流程注入，允许 AI 或人类按需将流程片段注入到正在运行的实例中。当我们不想依赖特定条件来触发流程但有一个临时决定运行流程来处理不同情况时，这很有用。此外，它允许简化正在注入的流程模型，因为它不再依赖于触发条件。在撰写此博客时，Camunda 尚不支持这些功能。

与外部系统集成
Camunda 允许开发人员在广泛的 Camunda REST API 和连接器的帮助下创建与其他系统的集成。

Camunda 提供云连接器，包括 Kafka 流、AWS 和 Azure。例如，将 BPMN 服务与 AWS 连接以调用 AWS lambda Camunda 提供了AWS lambda 连接器。同样，Camunda 为 AWS Simple Queu Service 消息和 AWS Simple 通知服务提供连接器。

其他连接器包括包含 Salesforce 和 SWIFT 的业务连接器、包含 Microsoft teams 和 slack 的生产力应用程序连接器、允许将内容推送到 Box 和 Opentext 等系统或从系统中提取内容的企业内容连接器、允许将数据推送到或从系统中提取内容的数据连接器从商业智能系统、数据湖和数据仓库等提供商处提取数据。

此外，Camunda 允许创建自定义连接器以使用集成框架集成到外部服务中。

与 Camunda 类似，Flowable 提供与外部系统的现成集成，例如与 AWS SQS、Kafka、Rabbit MQ 和 Active MQ 的事件流集成，用于事件驱动的业务流程。此外，Flowable 还提供包括 Whatsapp 在内的第三方消息集成。它还具有抽象数据源集成，并支持关系和非关系数据库。然而，Flowable 似乎与 Camunda 等外部系统的现成集成较少。

部署
Flowable 在部署方面比 Camunda 更灵活。Camunda 可以部署在云端和本地。Flowable 也可以部署为混合解决方案。

语言支持
两个平台都支持不同的语言，例如

• Groovy
• Kotlin
• JavaScript
• Python

除了这些，Camunda 还支持 PHP 和 .NET。

Camunda 还是 Flowable？
最终两个平台之间的选择取决于项目和项目需要什么。通常，Flowable 适合需要更大部署灵活性的项目，或/和必须通过动态流程注入和 CMMN 解决业务流程中不可预测的上下文。
而 Camunda 适合具有复杂业务流程和规则以及与不同外部系统集成的更大项目。

一些最佳实践
所以我们决定我们有一个用于实施自动化业务流程平台的用例。假设我们为此选择了 Camunda。我们可以使用 Camunda 建模器，然后开始创建我们的模型。然而，随着我们的前进，我们的模型可能会变得难以理解、更改或维护。这可能是因为我们没有遵守此类平台推荐的最佳做法。Camunda 和 Flowable 都对自动化流程的建模和开发的最佳实践提出了建议。

1、可读性
模型应该保持简单。易于理解且标签清晰。活动应以描述性方式标记，以便清楚地了解它们的内容。同样，网关应根据命名约定命名。例如，XOR 网关应标记为具有互斥答案的问题。来自网关的传出序列流或路径应标有相应的答案。
所有生成的 ID 和标签都应替换为连贯的命名，包括模型所代表的业务流程的通用语言，以便所有利益相关者（例如，开发人员和业务分析师）都能理解。
模型应该系统地从左到右建模。不建议在难以遵循流程方向的地方使用重叠的顺序流程。但是，如果读者清楚流程的去向，则可以使用指向一个目标的重叠序列流。
应尽可能避免隐式 BPMN 构造。

2、单一职责
我有没有提到我们的流程模型应该尽可能简单？啊，是的，我做到了。好吧，我会重复一遍——它应该尽可能简单。流程模型应该只负责解决一个问题。该过程中的活动应该只对一件事负责。在一个步骤中计算业务流程的所有数据是一种应该避免的反模式。
如果流程非常复杂，则可以将其分解为子流程。这使我们能够将某些流程封装成有意义的块。子流程可以是嵌入式子流程（嵌入在父流程中并且只能由该流程访问的流程）、事件子流程（由事件触发）或全局子流程。仍然可以从使用它们的父进程中看到/扩展视觉子进程。

3、可重用性
流程中的某些流程和步骤可能与其他流程中的流程和步骤相似或相同。正如您可能猜到的那样，对于这些情况，可以创建全局子流程并由其他流程重用。在我们的狗行为自动化流程系统中，开发票客户或错误处理可以是在不同流程中重复使用的子流程。
此外，元素模板是不同流程重用流程步骤的另一种方式。元素模板还确保流程之间的一致性。

4、优雅的失败
在我们的过程中总是有可能出现问题。例如，如果在我们的“建议生成过程”中，OpenAI 集成系统出现错误怎么办？我们必须预见到这些失败，并确保我们的流程以我们希望的方式结束。在“Advice generation process”中，我们可以通过给客户发邮件找借口来处理这个错误，比如“抱歉，我现在正在休假”，然后中止这个过程。
如果出现故障，我们还可以执行其他步骤：

• 回滚到以前的交易点，
• 重试/等待多次，
• 为流程/子流程/活动设置全局或本地计时器，
• 错误边界事件，错误事件子过程

高性能
Camunda 和 Flowable 都具有内置的监控和报告功能。强烈建议定期使用它们来监视流程实例并识别任何瓶颈和性能问题。

缺点挑战
BPMN 图形符号是 xml 文件。它们不仅包含有关工作流、活动和元素的信息，还包含图形表示，例如这些元素的位置。因此，当开发人员进行更改时，这些更改很难进行代码审查。特别是如果开发人员没有遵守最佳实践并且没有为活动、规则和条件提供连贯的标签和 ID。
有时提供更改前后的图表图像会有所帮助。但是，如果提供的图像不代表所做的实际更改，它也可能会产生误导。

同样，合并冲突也很困难，因为我们需要确定我们需要在 xml 文件中保留、合并或丢弃哪个版本的更改，该文件可能非常复杂，并且还包含有关不同元素位置的信息。

Camunda、Flowable 和其他 BPMN 平台是面向状态的，当特定状态的流和数据发生变化时，很难维护。通常，建议使用历史数据分析新版本中流程的行为，以避免出现重大错误。

更改也会影响性能。因此需要监控、调整配置和微调以确保最佳性能。

结论
这篇博客简要介绍了工作流自动化平台 Camunda 和 Flowable，并试图说明我们为什么要使用它们。这些平台使我们能够自动化工作流程和流程、任务分配、表格和决策表。Flowable 是一个更轻量级的平台，可以非常有效地与 Eclipse 一起使用。Camunda 提供了比 Flowable 更强大的监控和问题调查和解决能力。两个平台之间的选择取决于项目和要求。

这两个平台都使我们能够自动化、执行和监控业务流程。Camunda 和 Flowable 还可以让所有利益相关者更好地直观地了解流程中发生的事情。

然而，在实践中，实施这些平台可能具有挑战性。特别是当流程需要更改时。通过遵循两个平台提供的推荐最佳实践，可以减少或避免一些挑战。