今天又要写一篇关于低代码开发平台的文章。刚才讲云原生整体解决方案的时候，讲的是低代码开发平台。一些核心组件和组件之间的集成没有描述，这些只是低代码开发平台设计和实现的关键内容。低代码平台概述对于低代码开发平台，百度词条有一个基本的定义，如下：的代码。一种通过可视化进行应用程序开发的方法（请参阅可视化编程语言），它使各种经验水平的开发人员能够使用拖放组件和模型驱动逻辑，通过图形用户界面创建Web和移动应用程序。低代码开发平台完成业务逻辑和功能构建后，即可实现应用的一键交付和更新。如果我们把这个定义的关键内容抽离出来，它的核心包括：无需编码或少量编码的可视化和可配置性，通过组装或配置构建应用除了这两点之外，还有一个流程支持层面，即，整个开发应用的上线或交付过程要足够简单和自动化，包括上面提到的可以立即生效的配置和一键交付等。目前有很多服务商提供低代码开发平台。虽然每个公司的解决方案或整体架构不同，但本质内容基本相同，就是一切都是可配置、可建模的。你可以想象开发一个简单功能的过程，基本上就是数据库表设计，前端界面设计，编写逻辑层代码和接口实现业务规则，挂接流程引擎实现流程，配置功能和数据权限等等。因此，任何一个低代码开发平台都需要围绕这个核心进行抽象和建模，找出共性的和业务无关的东西进行技术沉淀，也就是我们常说的。完全标准化的事物，直接将非标准但同场景的事物标准化，通过抽象差异实现参数化配置。可以看到，我们LCDP平台的实际搭建，基本都是基于以上的思路。那么LCDP平台的核心要素是什么？具体我画了一张新图来说明。即LCDP平台的核心包括上图中的数据建模、表单建模、流程建模、权限建模、报表建模和规则建模几个关键部分。通过这些建模组件，包括这些组件之间的协作，完成一个完整的业务系统和功能的构建。对象建模驱动一个好的低代码开发平台应该是对象建模驱动的，这有点类似于很久以前提到的MDA模型驱动架构的思想。即先进行对象建模。这里的对象更多的是业务对象或者领域对象。一个对象本身可以对应多个数据库表，可以是层次结构表，也可以是管理结构表。对象建模完成后，可以向前暴露领域服务能力接口，向后连接数据库进行持久化。当领域服务能力接口暴露后，更容易实现前后端逻辑的完全分离和解耦，也更容易在领域服务实现内部进行相关的事务控制。采用对象建模后，实际上是在后端模型和前端接口之间增加了一个对象服务层，通过API接口对外提供对象服务，这与构建SOA分层应用的思想是一致的.对象建模完成后，对象本身可以向下生成数据库表，向上发布API接口服务。对于表单建模，不再直接关联数据库表，而是直接引用相应的API接口服务。在这种情况下，相应的API接口服务本身也会启用强服务契约模式的定义和设计。当有一个独立的接口层时，可以看出，实现上层功能的组合或组装会更加容易和方便，即我们可以提供一个类似传统BPEL流程或服务编排的工具，以及可视化上层业务的接口组装和编排。表单与流程引擎集成市面上很多低代码平台都是从传统的BPM软件或者工作流引擎平台演化而来的，所以流程引擎本身就是低代码平台底层重要的技术服务能力支撑。流程引擎本身与组织模型紧密绑定，进行相应的细粒度数据访问控制和流程动态访问控制。组织引擎和流程引擎的具体集成点这里不再赘述，重点介绍表单和流程引擎的集成。表单设计hooking流程可以先看最简单的场景，即表单设计和流程设计分离。您可以预先设计流程模板，生成流程模板ID，然后开始表单设计。表单设计完成后，可以选择一个流程模板ID进行hook。在这种场景下，在提交表单时启动流程本身也很简单，即：//GenerateFormID();//Form.Save();//StartWorkflow(Formid,WorkflowTemplateID,Userid);流程审核者填写扩展信息如果对于hook的流程，所有流程节点的handler简单检查是否通过，并填写给出处理意见，则完全满足上述处理方式。但更多情况下，需要在审核时填写扩展信息。例如，当供应商创建申请表并传递给采购经理审核时，采购经理需要确定供应商的等级并上传供应商的相关资质信息。供应商等级和供应商资质这两个数据项是供应商对象建模的基础数据项信息，但在提交文件时不维护，而是在审核时维护。在这个场景中，可以看出表单和流程模板之间不能建立简单的关联和映射，而应该进行表单数据项和流程节点之间的映射。单个数据项的映射粒度太细，可以在设计表单时引入数据分组，处理好数据分组与流程活动节点的映射。如上图所示，对表单数据进行分组，建立流程活动节点与表单分组的映射和授权关系。整体表单提交和审批流程变化如下：申请人提交表单信息时，只能看到基本信息审批1进入审批，可以看到扩展组，维护数据，然后提交审批结果审批2回车可以看到3组信息，但只能对扩展组2进行数据维护，审核并提交结果。在流程监控中，对于已经执行过的节点，可以看到扩展组信息，即以上不仅实现了基于流程的参与者动态权限控制，还实现了流程参与者可以维护和填写流程审核过程中的表单信息。扩展分组信息在维护后保留在基础对象数据表中，不在流程实例表中。流程实例表只负责下一阶段流程参与者的状态传递和计算。动态权限+数据权限控制动态权限简单的说就是你在处理流程节点的过程中有查看表单数据的权限，但是处理完成后你的权限就会被撤销。或者您只能看到您审查和处理的表格，而不是所有供应商表格数据。数据权限就是确定你具体可以看到整个数据对象的哪些数据项。比如之前的分组授权，也是一种常见的数据权限控制方式。表单保存和流程启动流程的解耦当流程引擎作为技术服务独立实现时，可以看到流程启动和流程流程都是通过调用API接口服务完成的，那么此时就形成了一个分布式事务场景.更好的做法还是异步解耦表单存储和流程API服务，即先将流程流的触发请求写入消息中间件，再异步订阅消息队列数据启动流程或流程节点。流程规则的实现在整个流程的处理过程中，还涉及到规则的处理和执行，规则可以理解为两种类型。一种是简单的判断规则，比如报销金额超过10000需要转交总经理审核；另一个负责规则判断，例如详细的预算完整性检查，是否通过需要转移到不同的分支机构。结合传统的流程??引擎实现，简单的规则可以通过参数变量传递，复杂的规则可以考虑直接调用外部API接口服务来实现校验。这里只将需要用于流程判断的数据项信息参数传递给流程执行，本身也减少了资源负载。对于Param信息的传递，一种思路是在流程实例启动后缓存，另一种是在每个流程活动节点执行时重新引入。个人建议是在流程实例启动的时候缓存。表单与组织权限模型的集成前面提到，对象建模应该和表单建模分开，即一个对象建模之后，实际上可以基于这个对象构建多个不同的表单模型。我们以供应商为例。一个供应商可以分为供应商完整信息维护、供应商银行信息维护、供应商模糊查询、供应商资质信息查询、特定供应商信息查询等不同的表单功能，即使流程没有关联，但是这些表单的功能都对应同一个对象模型。表单设计完成后，表单功能就形成了。窗体设计好后，可以链接到具体的功能菜单，也可以绑定具体的操作按钮或事件。简单的说，表单本身可能有入口参数。一个供应商查询功能表单，查询结果是一个列表，您可以点击列表中的详细信息链接，此时您应该调整到具体的供应商查看界面，那么供应商ID是一个重要的输入参数。可以看出整体的权限控制思路还是基于角色+资源访问授权。表单挂接到菜单资源，菜单可以委托给用户组或角色。同样，对应表单设计中的数据项或数据组也可以定义为需要细粒度控制的资源对象。资源定义完成后，资源对象被授权给特定的用户组或角色，包括表单中的按钮。思路继续进行。即表单建模完成后，我们需要对建模表单的资源对象进行抽象。资源对象可以是独立的数据项、数据分组或按钮操作。同时，将资源对象绑定到角色或用户上。数据项权限默认设置数据项权限配置最好同时支持默认可见和默认不可见。比如采购订单金额只对采购汇总可见，所以这个数据项的默认值是完全不可见的，并且将金额定义为一个资源，授权给采购总监这个角色。静态权限与动态权限重叠静态权限与动态权限重叠怎么办？一般来说，动态权限应该是主要关注点。例如，静态权限设置是没有权限的，而动态权限是经过计算后可以操作或维护的，因此用户在动态流程执行过程中对相关信息有动态的权限控制。处理过程后权限消失。对于低代码的开发平台、表单和规则引擎，其实我个人不建议引入比较重的规则引擎。你要明白，如果业务规则真的很复杂，使用规则引擎也是需要写很多脚本代码来实现的。而且脚本代码本身后期维护起来也比较困难。规则引擎出现了这么多年，但是在企业信息化领域却很少见到非常成熟的应用场景。对于规则，我们可以分开来看。一种是可以根据当前前端已有的表单数据进行计算验证的规则。这些规则通常是参照完整性规则。比如我在电商平台下单的时候，我选了10个产品，都有不同的折扣，但是有些折扣是不能同时共享的。这时候前端就可以完成规则计算，给出一个最优的折扣和总成本。对于这类规则，表单设计者需要支持。最好的办法就是会脚本，可以写简单的规则定义脚本，自己处理。另一类规则是需要调用后台数据完成计算的规则。比如提交报销文件申请时，需要在后台验证当前预算是否充足、是否满意，满足后才能提交。第二类规则其实就是规则引擎可能涉及到的场景。也就是说，在第二类场景中，整个过程可以理解为在规则模型中定义规则，规则接受输入并产生输出。表单将keyparam参数传递给规则引擎。规则导致根据param参数从数据库后台获取数据。规则计算将规则计算的结果返回给表单前端。如果规则很复杂，你会发现规则不能通过简单的配置来实现，还需要编写大量的规则脚本代码。这种情况下，更推荐的方式是自己实现一个自定义的API接口。在表单设计过程中，您可以针对关键事件点调用自定义API接口。现在的快速开发平台叫低代码开发，这个名字很贴切，就是不要指望所有复杂的地方都要配置，尤其是复杂规则的实现。最好的办法是对复杂的规则自己写代码实现接口，然后在表单建模和流程建模的时候调用自己写的API接口方法。事件是软件开发中的标准概念。点击按钮、下拉选择框、移出焦点都可以触发事件。事件触发后，在没有规则的情况下会调用表单自身的处理逻辑。比如保存按钮，事件触发后，调用表单保存操作保存数据。但实际上你会看到，保存前可能需要进行业务规则和逻辑处理，保存后可能会触发其他相关操作。//Form.SaveBefore();//Form.Save//Form.SaveAfter();目前保存前可能会调用多个API接口进行多次验证。这时候又出现了一个重点，即不仅支持事件前后调用外部API接口，还支持API接口的简单编排。其实大家可以看到，对于一个完整的低代码开发平台，面对各种复杂的业务场景，这种开放的编排能力是很有必要的。这种安排思路其实和SOA上的服务组合或者流程安排思路是一致的。服务组合编排仍然以购买电商产品为例。提交订单时，如果需要同时处理三个动作。即调用订单对象的保存操作，调用库存对象的库存扣减，调用发货单对象自动创建发货单。在这个场景下，大家可以看到，如果没有服务组合和编排能力，是很难实现的。将对象建模暴露的接口能力进一步可视化组合排列，形成复合服务能力，再暴露给表单设计。一个好的低代码开发平台需要参考SOA分层架构和领域建模的思想，即对象建模设计完成后暴露API接口服务能力，前端形态设计是与API接口服务层进行交互。这种设计方式便于后续扩展业务能力编排。即使前期没有可视化的服务编排能力，我们也可以自定义API接口服务能力进行接入。
