基于低代码平台来开发MDM主数据管理系统，我的一点思考

在前面我已经谈过多篇关于MDM主数据系统的文章，也谈到了当前MDM系统的主流趋势是形成一个快速开发平台，后续的主数据对象创建，流程管理，数据集成和数据质量都可以快速的开发和配置完成。

简单来说核心还是对象驱动的流程管理系统，只是里面增加了后期的数据集成和分发，数据质量管理方面的内容。

一个MDM系统的参考功能架构如下：

但是一般来讲MDM系统都涉及到数据的集成，后续主数据的服务共享，数据分发等操作。也是我经常谈到的MDM系统一般都集成了ETL数据采集集成能力，SOA里面的服务共享和接口管理能力。比如下图参考：

这也是MDM系统的快速开发比一般的OA或工单类系统复杂的一个原因。

那么是否可以基于当前的低代码开发平台来快速地开发MDM系统，或者说为了满足MDM系统的快速开发，低代码开发平台需要具备哪些能力？

在前面我讲低代码平台核心建模的时候，给出过一个参考架构图如下：

我们接着这个图来思考如何基于低代码平台开发MDM系统。

MDM开发需要具备核心底层技术能力

对于需要具备的能力前面已经谈到，实际上包括了低代码开发，数据集成和API接口管理，数据质量和规则引擎多方面能力，简单总结如下：

对象建模

组织和权限建模（4A引擎）

表单建模和表单设计

BPM流程建模（人工流+自动业务流）

数据集成（传统ETL能力）

数据分发和API服务暴露(API快速开发和API网关）

数据质量管理(规则引擎）

报表管理(报表引擎）

从上面来看，将我们已有的4A+流程引擎，ETL数据集成和SOA相关能力进行抽象和整合，并融入到当前的低代码开发平台中，完全可以构建一个满足低代码开发的主数据平台。

我们拿供应商数据来举例说明下核心场景。

首先还是供应商主数据的对象建模，当前低代码平台的对象建模能力完全可以满足要求，从单表到主从表，包括1对多对多等各种复杂的对象模型结构都可以很好的支撑。对象建模在整个建模里面相当关键，起到了很好的承上启下的作用。

注意，在对象建模完成后，基于业务对象和对象属性的参考完整性检查，这个规则实际是可以在对象建模的时候就进行配置，因为这个规则和界面和表单的呈现方式无关。

类似供应商是否重名，字段类型的检查，简单复合判断规则等。当前也有类似供应商名称相似性的检查，这个属于复杂规则，实际很难配置。那么你可以单独实现一个检查接口，也可以是这类规则进行共性抽象，形成通用化的规则检查配置能力。

其次是表单设计和配置，这块实际也没有太大的难度，当前的表单设计器已经足够灵活，支撑各种单表，多表，各类UI界面控件的设计和绑定，包括进行单页分组，多页Tab设计等。同时可以做到复合对象可以做到完整事务处理。

类似供应商新增，实际包括两个独立场景，一个是系统管理员进行的供应商信息CRUD操作，一个是实际业务用户进行的单个供应商新增并挂接流程审批操作。

实际在配置的时候这两个场景也需要单独配置。

对于单个供应商新增流程，那么一进入就应该是供应商新增功能界面，并将界面元素和对象模型进行绑定，除了单据保存或暂存按钮外，在挂接流程的时候默认配置提交按钮，提交按钮跟一家配置完成的某一个流程模板编码进行关联。

第三是工作流配置，工作流配置是一个独立功能，可以进入到工作流管理信息流程模板配置，当前工作流引擎实际包括两个能力的支持，其一是可以调用外部WS服务的能力，其二是可以将表单数据通过Json对象传入到流程引擎中的功能。这样工作流引擎中才方便实现简单的业务规则判断和逻辑处理。

对于工作流配置，可以看到对于流程活动阶段往往不仅仅是单据简单的审核操作，同时还涉及到具体新增字段信息的填写等，因此在工作流配置中活动节点处也涉及到具体的可视化表单设计，同时这部分表单数据信息还应该回写回供应商基础对象属性中。

第四是规则和复杂逻辑处理，这块实际要实现完全可配置相当困难。即使一个简单的供应商申请，你会看到如何去判断供应商信息相似并给出提示信息？这个简单的逻辑规则就很难完全配置出来。

因此这类规则处理最好的方法还是自己写API接口服务来实现，前端要做的事情简单来说就是组织前端界面数据去调用和触发接口操作。最终根据返回的信息进行相关的逻辑处理和判断。这样整体的灵活性才足够好。

在这里有两个情况需要处理。

其一是通用的事件处理机制，每个界面控件都可能会触发事件操作，事件会触发一些通用性的行为，类似通知提示，发邮件等，也必须具备支持调用外部API接口服务。其二是提供简单的API接口服务编排能力，这个我在前面的文章中专门谈到过。

第五是数据集成和分发自动化集成，你会看到这块实际需要几个方面的技术能力，一个是常说的ETL数据集成，一个是数据分发和调用外部API接口服务能力，一个是将自身的对象模型发布为一个API接口服务的能力。

对于ETL能力，可以看到在对象模型配置完成后，需要能够支撑ETL数据采集集成能力，即能够从源端采集和集成数据写入到对象模型对应的数据库中。

同时对象模型配置完成后，类似API快速开发平台的思路，应该支持对象模型直接发布为API接口服务能力，同时可以发布类似CRUD的多种Http接口服务能力。

类似供应商申请流程，在供应商审批通过后也可能是直接调用外部的接口服务将供应商数据分发给需要的目标系统，因此在整个流程配置中，还需要支持自动化的业务流节点，能够去调用外部的WS服务接口。

第六是数据质量管理，对于数据质量管理是MDM主数据管理系统特有的一个关键功能，简单来说至少需要支持基于规则驱动的规则创建，规则检查，规则输出，告警通知等全面生命周期管理能力。

规则本身包括了单表单字段规则，也包括了单笔行规则，类似重复和相似，还包括了多表管理依赖校验规则的。这些规则在建设和实施了MDM系统后都可以进一步提取共性进行抽象，形成完整的数据质量管理模块。

也就是说数据质量管理模块可能不是低代码开发出来的，但是该模块完全能够支撑后期扩展的所有主数据对象的质量管理和规则检查。