介绍

BPM 是一个描述、建模和管理复杂业务流程的概念。使用 BPMN，我们可以轻松定义流程中的顺序，编排多个任务、决策和事件。有许多 IT 平台可以将 BPMN 设计变成工作代码。事实证明，协调服务、系统和业务任务的 BPM 模型和支持 IT 平台是实现业务流程的可靠来源。

那就是微服务出现的时候。也就是说，松散耦合的、基于事件的服务，旨在实现特定的业务功能，通过事件进行通信，并实现编排消息传递模型。微服务是否意味着 BPM 平台的终结？或者恰恰相反——像 Camunda 这样的 BPM 平台能否在复杂业务流程的微服务整合中发挥关键作用？

BPM 实施模型

当公司准备好启动 BPM 计划时，第一个决定是选择合适的实施模型和合适的 BPM 平台。

首先，让我们讨论该模型，它将定义整个 BPM 倡议方法本身。这是一个关键决策，需要深思熟虑，因为它将定义整个组织将如何创建和实现业务流程。有两种最流行的建模方法：

• BPM 平台可以是一个单一的 IT 系统，它将在一个地方为业务流程编排和配置规则。
• BPM 引擎可以是微服务的一部分，包含特定的子流程。这些微服务及其子流程将使用编排通信模式整合到业务流程中。

Camunda BPM Platform 可以从技术和业务角度实现这两种方法。这就是在 BlueSoft 中我们推荐该软件作为我们项目中主要 BPM 工具的主要原因之一，我们将使用它作为进一步概念的示例。

Camunda BPM 作为业务流程管理单体

自第一个 BPM 平台出现以来，这种方法已在许多组织中实施。它通常用于将集成层中的 ESB 服务编排成流程引擎层中定义良好的业务流程。我们可以从两个角度看待这种架构——业务和功能以及技术。

业务与功能视角

从业务和功能的角度来看，最重要的是业务流程本身。 Camunda 作为业务流程实现的核心，是业务定义规则和监控流程的第一层。每个业务流程都有其负责人负责业务成果和流程执行的可靠性。在流程引擎的顶部，作为最终用户的网关，通常有多个前端和门户，用户决定业务流程的实现。对于业务视角，集成层 API 就像负责数据供应和请求履行的“黑盒”，业务流程所有者不对其行为和数据管理负责。

正如我们所见，IT 团队和业务团队之间的合作主要集中在流程引擎上——而业务流程负责人定义需求和流程模型，而工程师则致力于他们的技术实现。集成和数据治理团队支持流程团队，但他们不负责业务流程和业务功能。

技术视角

从技术的角度来看，有一个多层的、集成的 IT 架构，它提供了实现业务流程实现的功能。 最重要的是，有可以使用多种不同技术（Javascript、PHP、Angular、React 等）交付的前端。 在较低级别，有 Camunda，它是业务流程定义的中心。 它存储业务规则、决策图表并在前端编排后端集成层功能和 UI 表单。 集成层是技术服务供应的中心。 在实践中，像 MuleSoft、WebMethods、Oracle ESB 等 ESB 平台通常是集成层。 他们的目标是为流程引擎提供具有标准化数据模型的 API。 该层负责公开多个系统功能、集成数据、统一协议、管理服务治理和编排简单的技术处理。

优点与挑战

微服务架构中的 Camunda BPM

微服务架构引入了一种不同的 IT 系统设计方法，其中具有大量业务功能的大型单一单体被专为业务目的设计的较小的自主服务所取代。这样的设计会对业务流程的实施方式产生影响。我们也可以从业务&功能和技术角度来看架构设计，但它们在一个微服务中密切相关，为一个业务领域提供业务功能。

业务与功能视角

从业务和功能的角度来看，将业务流程分解为更小的子流程非常重要，这些子流程专注于在一个业务对象中提供价值和决策。由于没有集中的业务流程引擎，这些子流程对事件流层中的事件做出反应。然后，他们启用自己的业务逻辑并为其他子流程生成结果事件。与 Camunda Monolith BPM Platform 不同，跟踪业务流程实现是在两个层面上完成的：在 Camunda Engine 中的微服务层面提供特定功能，以及在事件流层中跟踪子流程之间的事件。这种流程管理导致不同的组织模型——我们仍然有业务流程所有者，但他们在管理和监控整个流程本身方面的责任较少。相反，他们像乐高积木一样构建他们的流程，使用为组合提供小型子流程的微服务。微服务团队有负责端到端数据管理、与遗留系统和外部系统集成、业务子流程实现甚至最终用户 UI 的领导——无论是从技术角度还是业务角度。这种方法导致小型、敏捷、独立的团队与业务专家和 IT 工程师相结合。

这个概念比经典的分层架构具有更大的灵活性——但也让提供每个业务功能的团队承担更多责任。它可以选择适当的技术、语言、数据库和框架来有效地满足需求。团队全权负责完成业务服务，并与技术和业务专家结合，密切合作——从数据定义开始，到业务处理，最后到最终用户的 UI 表示。

技术视角

从技术的角度来看，任何分解的子流程都会成为一组在微服务的业务层中实现的功能——在我们的示例中，一个用于客户数据更新，另一个用于风险计算更新。每个微服务都有自己的数据存储和结构，自己的集成 API 层，自己的 Camunda 引擎来实现子流程，甚至自己的 UI 表示。每一层都可以用不同的技术编写——但是在业务层中坚持使用 Camunda 对于构建跟踪和监控整个业务流程的外部架构很有用。子流程通信是通过在一个地方发布事件来完成的，其他子流程也在事件流层中发布和消费事件。在这个架构中至关重要的是，Event Streaming Layer 只是事件共享的管道，不包含任何消息编排逻辑。用于此目的的最常用技术是分布式流和队列平台，如 Kafka、Pulsar 或 Rabbit MQ。

优点与挑战

结论

重要的是要记住，并非每个 BPM 平台都可以实现微服务和独立实现模式。使用无代码平台，可能很难在微服务内部实现完整的业务逻辑，因此它们将作为业务流程管理的单一平台更好地工作。使用低代码平台，我们失去了 BPMN 图驱动的开发，只依赖于工程师和业务专家之间的密切理解。这种理解只发生在微服务团队中。 BPM 平台在这里是最灵活的。它们将这两个好处结合在一起：业务分析师的 BPM 图表建模工具，感谢 IT 工程师，它变成了工作代码。 Camunda BPM 是一个平台，可用于两种实现模型。

在 BlueSoft 中，我们设法将 Camunda BPM 合并到两种实施模型中：

• BPM & Microservices 并以 Trans.eu 架构为例：https://bluesoft.com/project/microservices-based-integration-platform-f…。
• BPM 作为一个简单的业务流程管理工具集，以支持在线商店和 Polarbulk 架构为例：https://bluesoft.com/project/innovative-one-click-purchase-robot-for-po…

您想知道使用 BPM 解决方案是什么样的吗？阅读这篇文章，了解有助于充分利用 Camunda BPM 并避免常见陷阱的关键最佳实践：https://bluesoft.com/camunda-bpm-best-practices/

原文：https://bluesoft.com/bpm-platforms-standalone-microservices-implementat…

本文：https://jiagoushi.pro/node/1833

介绍

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 文件的方式。

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

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

活动实施原则

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

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

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

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

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

在 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 系统不是面向表单的门户。它们强制特定的数据状态提供验证和流动。但正因为如此，当这个流程和数据发生变化时，它们很难维护。最简单的方法是在新版本的生产发布之前强制完成所有流程。在某些情况下，更改与可以使用单个脚本转换的其他步骤和数据有关。但是在这些情况下，当流程必须保持当前状态时，分析人员必须创建“数据矩阵”，即数据作为一个维度呈现，当前状态作为另一个维度呈现。并且您应该始终分析在引入使用历史数据状态的代码的新版本时该过程将如何进行。

更多最佳实践。

Camunda 的官方文档是最佳实践的重要资源，我们强烈建议参与设计流程或开发团队成员的每个人仔细阅读 - https://camunda.com/best-practices/using- 我们的最佳实践/。 在这篇特别的文章中，我们想总结我们参与的许多项目的经验，以突出最常见的错误以及如何避免它们。 根据我们的经验，BPMN 设计过程并非易事，大部分知识都是在犯错时收集的，这些错误在长期使用这些过程时会发生。 我们认为，这些突出显示的要点是设计至少适当流程的关键。 对于那些与 Camunda 一起开始冒险的人来说，这样做是巨大的成功。

原文：https://bluesoft.com/camunda-bpm-best-practices/

本文：https://jiagoushi.pro/node/1834