Seata分布式事务框架提供的这四种模式适用于不同应用场景，XA和AT是基于数据库层面的分布式事务，TCC和SAGA是基于业务层面的分布式事务，数据库层面事务回滚依赖的是undo sql脚本，业务层面事务回滚依赖的是自己写补偿代码，用户在选择分布式事务模式时需要兼并考虑代码的侵入性和长事务性能问题。目前看，XA事务模型由于其性能最差，实际项目用的很少了；AT事务模型无代码侵入，性能较好，在交易类业务系统（比如：ERP、MES、CRM等）中推荐使用；TCC事务模型虽然性能最好，但需要写代码，且需要结合业务设计

本文介绍基于开源规则引擎LiteFlow，如何开发规则设计器，在低代码平台中集成规则引擎，并在项目中实现应用的效果。由于低代码平台使用规则引擎实现了逻辑编排的需求，所以本文中的叫法为“逻辑设计”、“逻辑编排”、“逻辑流引擎”等。逻辑设计（规则设计），可以将复杂且多变的业务规则从硬编码中解耦，封装成独立、可复用的业务组件，通过可视化规则设计器按业务需求编排业务组件的执行逻辑，使得业务规则的变更无需修改项目代码、不用重启服务器就可以在线上环境立即生效，实现灵活应对业务需求变化。比如说订单价格计算，有折扣、满减

Element Plus 和 Ant Design Vue 都是基于 Vue.js 的 UI 组件库，它们具备一系列可复用的组件和丰富的功能，并且是当前国内主流的两个 UI 组件库。Element Plus 是饿了么前端团队推出的开源项目，是对 Element UI 的升级版。它采用了 TypeScript 编写，提供了一套易于使用、响应式的组件，支持自定义主题、国际化等特性。Element Plus 的设计风格简洁明快，适用于企业级应用界面的构建。

本文以springboot+vue技术开发的低代码平台为案例，介绍应用系统如何集成企业微信，包括同步企业微信组织用户、单点登录、消息发送等。

Halo，大家好，我是一只努力奋斗的程序猿小白。作为第一次接触低代码，我回想自己这么久以来，花费两三天去完成的需求，竟然可以短时间内完成，难道小丑是我自己？下面我就分享第一次使用低代码平台开发项目的经验，希望可以帮助大家了解低代码开发。

全世界最牛逼顶级好用的低代码开发平台：Visual LANSA、Zoho Creator、The m-Power Development Platform、GeneXus、Web.com、UI Bakery、Strikingly、Jotform、Pixpa、Formaloo、Appian、KiSSFLOW、Mendix、OutSystems、Salesforce Lightning

自2021年年初我一个人来到了北京，开始了我在北京的快乐（苦逼）生活，来北京后先后经历了A公司和B公司两段工作经历。在A公司，我参与了公司自用的生产制造业ERP系统的开发，系统开发了整整两年才得以上线，每个模块都是修修改改无数次，导致经常要加班写代码赶需求。因为经常加班系统又做的很慢除我以外其他所有的后端开发人员都没有坚持超过半年的，而我也在这A公司拼命坚持两年后离开了这家公司。

利用LiteFlow，你可以将瀑布流式的代码，转变成以组件为核心概念的代码结构，这种结构的好处是可以任意编排，组件与组件之间是解耦的，组件可以用脚本来定义，组件之间的流转全靠规则来驱动。有的时候大家把LiteFlow叫做规则引擎，其实，逻辑引擎和规则引擎还是不一样，我认为LiteFlow是逻辑流引擎，它偏向于组件级接口的编排，粒度更细更底层，而规则引擎（比如：drools），它更偏向于业务规则计算，比如决策树、决策表等，解决某一个特定的业务需求，比如：保险行业投保规则计算。以下的测试类采用了组件声明方式。

Camunda 流程引擎在运行时会默认记录运行时指标，有助于得出有关 Camunda 平台的使用情况、负载和性能的结论。其中，ACT_RU_METER_LOG表记录了流程引擎一系列活动实例的度量指标；ACT_RU_TASK_METER_LOG表记录了人工活动分配处理人的度量值。默认情况下会记录一组内置指标，所有内置指标的标识符都可以作为org.camunda.bpm.engine.management.Metrics类的常量使用。

本文重点介绍camunda开源流程引擎的事务配置，以及在高并发多线程情况下，可能会发生多个线程尝试对相同流程实例数据进行更改的情况，Camunda如何通过数据库的乐观锁解决这种并发冲突的，并介绍了乐观锁和悲观锁的适用场景、性能影响等。

​camunda工作流引擎是一个开放的架构，除了流程引擎默认提供的功能外，开发者可以通过流程插件机制，对流程引擎功能进行扩展。即流程引擎插件是流程引擎配置的扩展。插件必须提供ProcessEnginePlugin接口的实现。除了在 BPMN 2.0 XML 中显式配置的执行和任务侦听器之外，流程应用程序 API 支持定义全局 ExecutionListener 和全局 TaskListener，它们会收到有关流程应用程序部署的流程中发生的所有事件的通知

多租户考虑的是单个 Camunda 安装应该为多个租户提供服务的情况，是实现SaaS化的重要技术手段。对于每个租户，应做出一定的隔离保证。例如，一个租户的流程实例不应干扰另一租户的流程实例。多租户可以通过两种不同的方式实现。一种方法是每个租户使用一个流程引擎。另一种方法是仅使用一个流程引擎并将数据与租户标识符相关联。这两种方式在数据隔离级别、维护工作量和可扩展性方面有所不同。两种方式的组合也是可能的。

camunda工作流引擎中有好多以ACT_HI_*开始的数据库表，HI代表历史。这些表包含历史数据，如过去的流程实例、变量、任务等。camunda流程引擎内部有历史记录事件流的机制，在流程执行过程中，会产生大量的历史数据，这些历史数据可以通过历史记录级别参数来设置，也可以通过API接口查询这些历史实例数据，或者通过历史实例任务数据进行统计分析，找到业务流程执行瓶颈，或者为业务KPI考核提供依据。但大量的历史记录数据存储会对流程引擎的执行性能产生影响，这就需要通过设置历史记录的清理策略，根据不同的业务需要定时

本文基于Camunda7.19.0版本，介绍Camunda开源工作流引擎的数据库架构和ER模型，Camunda7.19.0共49张表，包括了BPMN流程引擎、DMN规则引擎、CMMN引擎、历史数据、用户身份等方面的表结构定义，以及表与表之间的关联关系。

从本质上讲，业务流程是长期运行的，流程实例可能会持续数周或数月。同时，流程实例的状态将存储到数据库中。但是，即使仍有正在运行的实例，您也可能需要更改流程定义。流程引擎支持此功能：如果重新部署更改的流程定义，则会在数据库中获得新版本。正在运行的流程实例将继续在启动它们的版本中运行。新的流程实例将在新版本中运行 - 除非显式指定。在特定限制内支持将流程实例迁移到新版本。

Camunda Connect提供了一个简单的API，用于连接HTTP服务和其他内容。它针对两种使用场景：在Camunda平台流程引擎等通用系统中使用，以及通过API独立使用。Camunda Connect提供了一个REST HTTP和一个SOAP HTTP连接器，用户也可以在 camunda 中实现自己的自定义连接器。

camunda流程引擎支持两种执行服务任务的方式:1.内部任务：同步调用与流程应用程序一起部署的代码。2.外部任务：在列表中提供可由员工轮询的工作单元。第一个选项可以通过委托代码（Delegation） 或者脚本（Script）实现.相反，外部（服务）任务的工作方式是Process Engine流程引擎将工作单元发布给Worker来获取和完成。我们将其称为外部任务模式（the external task pattern）。外部任务模式是camunda工作流引擎特有的机制。

我们在使用工作流的时候，常常有“流程退回”、“流程跳转”、“自由流”、“动态加签”等这样的需求。Camunda流程平台提供了这样的机制和接口，虽然流程模型定义活动执行顺序的序列流，但有时需要灵活地重新启动活动或取消正在运行的活动，进而可以实现中国特色的流程需求。文本重点讲如何使用camunda的API接口实现流程跳转、流程退回的需求。

我们在使用工作流的时候，经常遇到“流程激活”或者“流程重启”的需求，即流程实例已经结束，由于某些特殊业务需求，仍然需要重新激活重启该流程实例。Camunda流程平台提供了这样的机制和接口，可以实现流程重启的需求，流程实例终止后，其历史数据仍然存在，并且可以访问以恢复流程实例，前提是历史级别设置为FULL。本文以开源流程引擎Camunda7.19.0版本介绍流程重启的API接口。

本文章介绍camunda流程引擎中变量的概念。流程变量可用于向流程运行时状态添加数据，或者更具体地说，向变量作用域添加数据。更改这些实体状态的各种 API 方法允许更新附加的变量。通常，变量由名称和值组成。该名称用于跨流程构造进行标识。例如，如果一个活动设置了一个名为 var 的变量，则后续活动可以使用此名称访问它。变量的值是一个 Java 对象。