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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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