介绍

BPM 平台是 BPMN 图成为工作代码的引擎。有许多产品实现了这些概念。其中一些被宣传为低代码，无需任何程序员帮助即可供企业使用。其中一些只是 Java 库，支持软件开发人员级别的业务流程实现。他们中的许多人都在努力获得简单性和 BPMN 驱动的代码，以实现复杂的、特定的要求和量身定制的解决方案。在众多平台中，Camunda BPM 作为一个平台脱颖而出，它是无代码简单性和低代码能力之间的诚实折衷。无论您选择哪种实施模型（在此处了解有关实施模型的更多信息：BPM 平台：独立和微服务实施），业务分析师和 BPM 平台程序员都可以在同一个 Camunda 项目上一起工作。

BPM 平台“圣杯”：无代码概念

我什么时候需要程序员？

现在，您可能想知道：“如果存在无代码 BPM 平台——我为什么还需要程序员？有许多工具被宣传为无代码概念，其中业务流程专家是设计和实施端到端流程的人。”答案很简单：您不需要程序员，如果您的 BPM 平台仅用于一个业务单元中非常简单的流程实现，无需数据集成。如果您想在组织级别实施业务流程，这对业务至关重要并且需要数据集成，那么没有无代码 BPM 平台可以满足您的需求。

在 BlueSoft 中，我们推荐 Camunda BPM 作为简单的、UI 驱动的业务流程设计（从无代码平台已知）和在 IT 工程师的帮助下实施数据集成和复杂业务规则的能力之间的最佳权衡。 Camunda BPM 的巨大优势在于，由业务专家完成的流程设计是 IT 工程师也在处理的代码的一部分。

实施 Camunda BPM 流程时的最佳最佳实践

现在，当我们知道如何建立在 Camunda BPM 中工作的团队时，让我们专注于业务专家和 IT 工程师在建模流程方面的最佳实践和工具。

当我们考虑流程建模时，我们有很多方法和工具来表达自己。它们由 BPMN 2.0 标准提供：流程应该如何工作以及它应该如何与其他微服务或遗留系统进行通信。不幸的是，在技术实现方面，标准方法是“少即是多”。作为程序员，我们习惯于遵守这条规则，但即便如此——这也不是不争的事实。

Camunda Modeler 的建模过程也是如此。常见的方法是仅使用主路径中的部分。但是，就从项目的其他贡献者的角度对过程的理解而言，我们需要在分析部分给他们一点帮助。在这种情况下，通道和外部系统调用就派上用场了。我们添加这些注释而不影响 Camunda 引擎处理流程 .bpmn 文件的方式。

bpm

现在，让我们试着设身处地为业务分析师着想。当试图仅使用主通道（示例图中的销售流程）来理解流程时，我们根本不知道这两个服务任务究竟做了什么。可以有一个逻辑调用内部数据库，或者从缓存中访问数据，或者从初始过程数据中计算一些东西。但是当所有部分都存在时，我们清楚地看到这些步骤调用了外部系统。我们甚至知道他们对外部系统使用了哪些特定的 REST 请求！

在对流程进行整体分析时，公司从上述方法中受益。这种方法可以作为设计高级业务流程时的第一个表达工具。然后可以将 .bpmn 文件发送给开发团队，作为开始使用的输入文件。

活动实施原则

当谈到 BPMN 流程编程的可读性时，原则就派上用场了。最常见的反模式是打破 SOLID 原则的第一条规则——“单一责任模式”。这是当今编程世界最重要的原则之一。它指出单个类或包应该只负责解决一个问题。它影响从低级类实现到高级架构设计的所有概念决策。就过程的长期开发和维护而言，步骤应尽可能简单。它应该只负责调用外部系统、为最终用户提供表单或计算收集的数据。

一起实现多个外部调用或在一个步骤中计算流程的所有数据是最常见的错误。即使该流程最初是由业务分析师以这种方式设计的，开发团队也有责任将这一业务步骤拆分为多个技术步骤，并保留原始业务描述。

最好的防线是坚持总体流程——当然，这只是总体思路的基本可视化：

第 1 步：从外部系统调用中获取数据
第 2 步：计算此数据，对其进行转换等。
第 3 步：使用已处理数据中的手动任务为最终用户提供表单。重要提示——不要试图在这部分中包含一种计算形式！对于字典等，尝试对表单进行建模以使用前端-后端 API。
第 4 步：保存用户表单中的数据并将其转换为流程模型（如果保存表单数据是唯一的选项，则从附加流程返回第 3 步）
重复一般的想法

请记住将可配置性带到步骤中

在 Camunda 中实施流程过程中的另一个重要事项是 SOLID 的“开闭”原则。有些步骤与流程非常相关，没有理由使外部配置成为可能。但其中许多步骤，即使涉及与其他系统的集成，也可以在流程的不同部分或流程的不同部分重复使用。为了实现这一点，我们应该使用元素模板（https://github.com/camunda/camunda-modeler/tree/develop/docs/element-te…）。 Modeler 的用户可以更灵活地重用流程步骤。当然，它需要为每个活动实现一点可配置性。在访问常见的产品数据、发送电子邮件或推送到客户的移动应用程序时，如果您为该步骤提供更多可配置性，那么游戏可能是得不偿失的。

异常处理和超时

在实施之前，我们可能需要更多的时间来分析和设计所有流程的所有出口点。特别是识别来自外部系统调用的所有异常或错误代码起着至关重要的作用。我们建议为每个流程制作一个专用矩阵。最后但同样重要的是，我们需要设计流程应该如何响应这些异常。有两种常见的方法：

第一个是将所有步骤回滚到前一个事务点。通常，这些将是人工手动任务或事件处理程序。这种行为很容易实现，但需要在下一次重试流程中覆盖对外部系统的所有数据更改。当然，这些更改不会影响相应系统中的任何业务相关流程）。
第二种是使用默认的 Camunda 的“重试和等待”机制。当 Camunda 尝试重复该步骤（默认 3 次）然后抛出异常等待管理员的操作时。当由于某些业务案例（例如，客户已经为产品付款，因此没有回头路）而难以实施甚至不可能回滚时，这是一种合适的方法。在这种情况下，必须考虑外部作业或 API 调用，以便在修复错误或系统重新联机时自动执行重试过程。这通常是指补偿流量。
最后，我们应该考虑进程超时的问题。在实际的行业案例中，大多数流程都应该有一个计时器，当客户没有反应时，它会结束它们。没有它，未完成流程的数量可能会不断增长，并扩展到数十万个。在大多数示例中，计时器仅分配给人工任务。这是一种有效且常见的方法，但是当我们需要在每一步都升级时怎么办？或者计时器应该是全局的？在这种情况下，全局处理程序或升级处理程序应该使用 BPMN 流程而不是纯粹的编程方法来建模，以便为业务分析师提供更清晰的信息。

避免冗长的流程

避免冗长的流程说起来很容易，但在实施时却很难获得。有时我们被迫设计流程，而人工手动任务可能需要几个月的时间。这与前面提到的微服务方法——短期流程相反。防止长期流程发生的最佳方法是将流程拆分为较小的流程，仅在当事方做出决定/输入有效数据时创建。但是，当您被迫设计和维护那些长期存在的流程时，请记住在对流程进行任何更改之前必须解决的关键问题：

每一条数据都可以处于任何状态并且是变化的一部分。有时不可能列出流程中的所有变量并创建升级矩阵。创建新版本流程的最佳方法是强制将所有流程移动到所需状态，并将这种方法传达给企业。
默认情况下，进程是版本化的。但复杂的前端表单和代码不是。当然，您可以使用 OSGi 插件系统 (https://www.osgi.org/) 和已维护的代码的几个版本，但在实际情况下，就成本而言，这是一种非常罕见的方法经过考虑的。很少有框架使用 OSGi 的所有功能（其中之一是我们的开源 BPMN 项目 - Aperte Worklow https://github.com/bluesoft-rnd/aperte-workflow-core），但即便如此，它的成本也很高为每个现有流程版本维护相同代码的多个版本。
BPMN 系统不是面向表单的门户。它们强制特定的数据状态提供验证和流动。但正因为如此，当这个流程和数据发生变化时，它们很难维护。最简单的方法是在新版本的生产发布之前强制完成所有流程。在某些情况下，更改与可以使用单个脚本转换的其他步骤和数据有关。但是在这些情况下，当流程必须保持当前状态时，分析人员必须创建“数据矩阵”，即数据作为一个维度呈现，当前状态作为另一个维度呈现。并且您应该始终分析在引入使用历史数据状态的代码的新版本时该过程将如何进行。

bpm