在前面我已經(jīng)談過多篇關于MDM主數(shù)據(jù)系統(tǒng)的文章，也談到了當前MDM系統(tǒng)的主流趨勢是形成一個快速開發(fā)平臺，后續(xù)的主數(shù)據(jù)對象創(chuàng)建，流程管理，數(shù)據(jù)集成和數(shù)據(jù)質量都可以快速的開發(fā)和配置完成。

如何來理解MDM主數(shù)據(jù)管理？

簡單來說核心還是對象驅動的流程管理系統(tǒng)，只是里面增加了后期的數(shù)據(jù)集成和分發(fā)，數(shù)據(jù)質量管理方面的內(nèi)容。

一個MDM系統(tǒng)的參考功能架構如下：

但是一般來講MDM系統(tǒng)都涉及到數(shù)據(jù)的集成，后續(xù)主數(shù)據(jù)的服務共享，數(shù)據(jù)分發(fā)等操作。也是我經(jīng)常談到的MDM系統(tǒng)一般都集成了ETL數(shù)據(jù)采集集成能力，SOA里面的服務共享和接口管理能力。比如下圖參考：

這也是MDM系統(tǒng)的快速開發(fā)比一般的OA或工單類系統(tǒng)復雜的一個原因。

那么是否可以基于當前的低代碼開發(fā)平臺來快速地開發(fā)MDM系統(tǒng)，或者說為了滿足MDM系統(tǒng)的快速開發(fā)，低代碼開發(fā)平臺需要具備哪些能力？

在前面我講低代碼平臺核心建模的時候，給出過一個參考架構圖如下：

我們接著這個圖來思考如何基于低代碼平臺開發(fā)MDM系統(tǒng)。

MDM開發(fā)需要具備核心底層技術能力

對于需要具備的能力前面已經(jīng)談到，實際上包括了低代碼開發(fā)，數(shù)據(jù)集成和API接口管理，數(shù)據(jù)質量和規(guī)則引擎多方面能力，簡單總結如下：

• 對象建模
• 組織和權限建模（4A引擎）
• 表單建模和表單設計
• BPM流程建模（人工流 自動業(yè)務流）
• 數(shù)據(jù)集成（傳統(tǒng)ETL能力）
• 數(shù)據(jù)分發(fā)和API服務暴露(API快速開發(fā)和API網(wǎng)關）
• 數(shù)據(jù)質量管理(規(guī)則引擎）
• 報表管理(報表引擎）

從上面來看，將我們已有的4A 流程引擎，ETL數(shù)據(jù)集成和SOA相關能力進行抽象和整合，并融入到當前的低代碼開發(fā)平臺中，完全可以構建一個滿足低代碼開發(fā)的主數(shù)據(jù)平臺。

功能開發(fā)場景說明

我們拿供應商數(shù)據(jù)來舉例說明下核心場景。

首先還是供應商主數(shù)據(jù)的對象建模，當前低代碼平臺的對象建模能力完全可以滿足要求，從單表到主從表，包括1對多對多等各種復雜的對象模型結構都可以很好的支撐。對象建模在整個建模里面相當關鍵，起到了很好的承上啟下的作用。

注意，在對象建模完成后，基于業(yè)務對象和對象屬性的參考完整性檢查，這個規(guī)則實際是可以在對象建模的時候就進行配置，因為這個規(guī)則和界面和表單的呈現(xiàn)方式無關。

類似供應商是否重名，字段類型的檢查，簡單復合判斷規(guī)則等。當前也有類似供應商名稱相似性的檢查，這個屬于復雜規(guī)則，實際很難配置。那么你可以單獨實現(xiàn)一個檢查接口，也可以是這類規(guī)則也進行共性抽象，形成通用化的規(guī)則檢查配置能力。

其次是表單設計和配置，這塊實際也沒有太大的難度，當前的表單設計器已經(jīng)足夠靈活，支撐各種單表，多表，各類UI界面控件的設計和綁定，包括進行單頁分組，多頁Tab設計等。同時可以做到復合對象可以做到完整事務處理。

類似供應商新增，實際包括兩個獨立場景，一個是系統(tǒng)管理員進行的供應商信息CRUD操作，一個是實際業(yè)務用戶進行的單個供應商新增并掛接流程審批操作。

實際在配置的時候這兩個場景也需要單獨配置。

對于單個供應商新增流程，那么一進入就應該是供應商新增功能界面，并將界面元素和對象模型進行綁定，除了單據(jù)保存或暫存按鈕外，在掛接流程的時候默認配置提交按鈕，提交按鈕跟一家配置完成的某一個流程模板編碼進行關聯(lián)。

第三是工作流配置，工作流配置是一個獨立功能，可以進入到工作流管理信息流程模板配置，當前工作流引擎實際包括兩個能力的支持，其一是可以調用外部WS服務的能力，其二是可以將表單數(shù)據(jù)通過Json對象傳入到流程引擎中的功能。這樣才工作流引擎中方便實現(xiàn)簡單的業(yè)務規(guī)則判斷和邏輯處理。

對于工作流配置，可以看到對于流程活動階段往往不僅僅是單據(jù)簡單的審核操作，同時還涉及到具體新增字段信息的填寫等，因此在工作流配置中活動節(jié)點處也涉及到具體的可視化表單設計，同時這部分表單數(shù)據(jù)信息還應該回寫回供應商基礎對象屬性中。

第四是規(guī)則和復雜邏輯處理，這塊實際要實現(xiàn)完全可配置相當困難。即使一個簡單的供應商申請，你會看到如何去判斷供應商信息相似并給出提示信息？這個簡單的邏輯規(guī)則就很難完全配置出來。

因此這類規(guī)則處理最好的方法還是自己寫API接口服務來實現(xiàn)，前端要做的事情簡單來說就是組織前端界面數(shù)據(jù)去調用和觸發(fā)接口操作。最終根據(jù)返回的信息進行相關的邏輯處理和判斷。這樣整體的靈活性才足夠好。

在這里有兩個情況需要處理。

其一是通用的事件處理機制，每個界面控件都可能會觸發(fā)事件操作，事件會觸發(fā)一些通用性的行為，類似通知提示，發(fā)郵件等，也必須具備支持調用外部API接口服務。其二是提供簡單的API接口服務編排能力，這個我在前面的文章中專門談到過。

第五是數(shù)據(jù)集成和分發(fā)自動化集成，你會看到這塊實際需要幾個方面的技術能力，一個是常說的ETL數(shù)據(jù)集成，一個是數(shù)據(jù)分發(fā)和調用外部API接口服務能力，一個是將自身的對象模型發(fā)布為一個API接口服務的能力。

對于ETL能力，可以看到在對象模型配置完成后，需要能夠支撐ETL數(shù)據(jù)采集集成能力，即能夠從源端采集和集成數(shù)據(jù)寫入到對象模型對應的數(shù)據(jù)庫中。

同時對象模型配置完成后，類似API快速開發(fā)平臺的思路，應該支持對象模型直接發(fā)布為API接口服務能力，同時可以發(fā)布類似CRUD的多種Http接口服務能力。

類似供應商申請流程，在供應商審批通過后也可能是直接調用外部的接口服務將供應商數(shù)據(jù)分發(fā)給需要的目標系統(tǒng)，因此在整個流程配置中，還需要支持自動化的業(yè)務流節(jié)點，能夠去調用外部的WS服務接口。

第六是數(shù)據(jù)質量管理，對于數(shù)據(jù)質量管理是MDM主數(shù)據(jù)管理系統(tǒng)特有的一個關鍵功能，簡單來說至少需要支持基于規(guī)則驅動的規(guī)則創(chuàng)建，規(guī)則檢查，規(guī)則輸出，告警通知等全面生命周期管理能力。

規(guī)則本身包括了單表單字段規(guī)則，也包括了單筆行規(guī)則，類似重復回相似，還包括了多表管理依賴校驗規(guī)則的。這些規(guī)則在建設和實施了MDM系統(tǒng)后都可以進一步提取共性進行抽象，形成完整的數(shù)據(jù)質量管理模塊。

也就是說數(shù)據(jù)質量管理模塊可能不是低代碼開發(fā)出來的，但是該模塊完全能夠支撐后期擴展的所有主數(shù)據(jù)對象的質量管理和規(guī)則檢查。