前端開發還可以這麼玩？元資料實踐分享
摘要：元資料是業務流中前端和業務側實現共同使用的一種規範，是溝通前後端的橋樑，其通過統一的資料格式進行約束，從而約定前後端傳參。使用元資料，大幅提升了開發效率，又降低了維護及二次開發成本。
1 ROMA 業務流簡介
ROMA 業務流（以下簡稱“業務流”）是一個基於ROMA Connect平臺的應用整合與資料開放服務，適用於跨例項、跨應用的企業系統整合場景。業務流支援通過視覺化UI介面來建立任務，從而降低了不同經驗背景的使用者的開發門檻。
圖1-1 業務流demo
2 元資料概述
Metadata（以下稱作“元資料”）是業務流的一個重要概念，用於約束前端生成的資料模型，同時驅動業務的邏輯實現，是前端頁面和後端業務共同使用的一種規範。
在前端的實現中，元資料負責驅動前端框架，用於構建一個完全由元資料建模動態生成的介面。在業務流開發過程中，只需新增新的Json格式的元資料即可新增新的元件，而無需再進行前端開發，這實現了快速開發、減少維護的目標。
在業務側，處理程式是按照元資料模型實現的，這也就意味著使用者將會在前端輸入足夠執行業務側的資料從而正確執行業務邏輯。
並非為前端服務
需要注意的是，元資料並不是以前端開發為中心，它主要是為模型的生成器和模型消費者提供一致的通用建模。在業務流中，前端框架只是嚴格按照建模的概念生成業務資料模型。但是業務側不應受到前端的限制，應當適用於任何可以符合元資料正確生成資料模型的前端框架。
元資料的另一個核心用法是“驗證”，在後端服務中，服務應該在部署業務側之前利用元資料模型來驗證服務請求是否合法。
圖2-1 元資料驅動模型
3 元資料屬性
3.1 元件
元件是業務流任務中的基本單元，每個元件都有特定的功能，如“Open API”元件用於定義和開放一個API、“資料來源”型別元件用於選擇資料來源用於資料遷移或者資料開放、“指令碼處理”元件用於使用指令碼處理資料等，使用者通過配置和連線各種型別的元件進行業務編排。下圖是當前業務流提供的元件。
圖3-1 業務流元件
3.2 元件元資料
開發過程中，通過新增新的“元件元資料”即可生成新的元件。“元件元資料”模型包含前端輔助資料和業務側依賴的屬性。“元件元資料”的關鍵屬性如下表所示。
表3-1 “元件元資料”屬性
通過定義上述屬性，我們可以快速在前端新增新的元件。以下為一個型別為“sample_component”的元資料元件的示例。
{ "type":"sample_component", "categories":["sample"], "display":"sample component", "description":"Input types illustration sample component", "iconURL":"", "inputs":[ { "key":"parameter01", "display":"parameter 1", "type":"text", "placeholder":"A input hint message here.", "default":"default_value", "required":true }, { "key":"parameter02", "display":"parameter 2", "type":"text", "placeholder":"A input hint message here.", "default":"default_value", "required":true } ] }
根據上述元資料，前端渲染出的元件效果如下圖所示。
圖3-2 “sample_component”元件效果
點選“sample_component”元件後，元件配置如下圖所示。
圖3-3 “sample_component”元件配置
使用者配置完成該元件並啟動業務流後，業務側將對接收的元資料進行解析。其中，業務側將根據“type”欄位來確定執行邏輯。
{ "id": "UUID", "name": "name", "category": "sample", "description": "description" "metadata": { "type": "sample_component", "configuration": { "parameter01": "parameter01 value", "parameter02": "parameter02 value" } } }
3.3 輸入元資料
“元件元資料”的“inputs”屬性，代表了當前元件的輸入資訊，其通過“輸入元資料”來定義。
“輸入元資料”是輸入引數的集合，它使得開發者可以用最少的程式碼來提供業務處理所需的資訊。“輸入元資料”基本屬性如下表所示。
表3-2 “輸入元資料”基本屬性
務流的元資料框架中，當前支援多種“輸入源資料”的引數型別，而且大多數型別都具有附加屬性。接下來將對部分“輸入源資料”的引數型別做簡要介紹。
3.3.1 Text
通用的的純文字輸入型別。附加屬性包括“maxlength”和“pattern”。
“Text”型別輸入引數的示例如下所示。
{ "key":"text_sample", "display":"Text Input", "type":"text", "placeholder":"A input hint message here.", "default":"default input", "required":true, "maxlength":20, "pattern":"/.+" }
前端渲染效果如下圖所示。
圖3-4 “Text”型別輸入引數示例
3.3.2 TextArea
多行文字區域輸入型別。 附加屬性為“maxlength”。
“TextArea”型別輸入引數的示例如下所示。
{ "key":"textarea_sample", "display":"Text Area Input", "type":"textarea", "placeholder":"A input hint message here.", "required":true, "maxlength":100 }
前端渲染效果如下圖所示。
圖3-5 “TextArea”型別輸入引數示例
3.3.3 Number
具有範圍和步長支援的數字輸入欄位。 附加屬性包括“min”、“max”和“step”。
“Number”型別輸入引數的示例如下所示。
{ "key":"number_sample", "display":"Numeric Input", "type":"number", "default":50, "min":"0", "max":"100", "step":"1", "required":true }
前端渲染效果如下圖所示。
圖3-6 “Number”型別輸入引數示例
3.3.4 Password
帶掩碼的文字輸入型別，用於密碼文字等輸入。
“Password”型別輸入引數的示例如下所示。
{ "key":"password_sample", "display":"Password Input", "type":"password", "default":"default", "required":true }
前端渲染效果如下圖所示。
圖3-7 “Password”型別輸入引數示例
3.3.5 Selection
“Selection”代表下拉選擇列表，分為“靜態選擇”和“動態選擇”。
- 1. 靜態選擇
預定義值的靜態選擇列表。附加屬性為“choices”。
“靜態選擇”型別輸入引數的示例如下所示。
{ "key":"selection_sample", "display":"Static Selection Sample", "type":"selection", "default":"default_value", "required":true, "choices":[ { "display":"item_1", "value":"1" }, { "display":"item_2", "value":"2" }, { "display":"item_default", "value":"default_value" } ] }
前端渲染效果如下圖所示。
圖3-8 “靜態選擇”型別輸入引數示例
- 2. 動態選擇
執行時使用外部REST API的請求結果作為選擇列表。 附加屬性如下表所示。
表3-3
“動態選擇”型別輸入引數的示例如下所示。
{ "key":"selection_sample", "display":"Dynamic Selection Sample", "type":"selection", "required":true, "selector":{ "uri":"http://my.domain.com/v1/samples", "method":"GET", "placeholder":"loading...", "selector_display":"$.samples[*].sample_name", "selector_value":"$.samples[*].sample_id" } }
點選該元件時，將自動呼叫“http://my.domain.com/v1/samples”的請求，並將請求結果放入選擇列表。請求結果如下所示。
{ "samples":[ { "sample_name":"sample01", "sample_id":"01" }, { "sample_name":"sample02", "sample_id":"02" }, { "sample_name":"sample03", "sample_id":"03" } ] }
前端渲染效果如下圖所示。
圖3-9 “動態選擇”型別輸入引數示例
3.3.6 Tableinput
表格輸入。附加屬性為“columns”。
“columns”型別輸入引數的示例如下所示。{ "key":"tableinput_sample", "display":"Table Input Sample", "description":"Table with custom columns", "required":true, "type":"tableinput", "columns":[ { "key":"key-1", "display":"col-1", "default":"", "type":"text", "required":true }, { "key":"key-2", "display":"col-2", "default":"default_value", "type":"text", "required":true }, { "key":"key-3", "display":"col-3", "placeholder":"a placeholder message", "type":"text", "required":true } ] }
前端渲染效果如下圖所示。
圖3-10 “Tableinput”型別輸入引數示例
4 結語
元資料是業務流中前端和業務側實現共同使用的一種規範，是溝通前後端的橋樑，其通過統一的資料格式進行約束，從而約定前後端傳參。使用元資料，大幅提升了開發效率，又降低了維護及二次開發成本。正是通過元資料渲染的方式，助力業務流服務的快速發展，幫助企業快速、簡單的聯接雲上雲下，消除數字鴻溝，構建業務敏捷性，驅動數字化轉型。
本文分享自華為雲社群《前端開發還可以這麼玩？ROMA 業務流元資料實踐分享》，原文作者：中介軟體小哥。