數據合規性檢查案例

1.問題描述

1.1 數據驗證的意義

規則引擎可(kě)以在數據驗證和清洗場景中(zhōng)使用(yòng)，通過使用(yòng)規則來驗證數據的有(yǒu)效性和一緻性，具(jù)體(tǐ)如下：

數據格式驗證：驗證數據是否符合特定的格式要求，如郵件地址、電(diàn)話号碼等。
數據範围驗證：驗證數據是否在允許的範围内，如年齡範围、工(gōng)資範围等。
數據一緻性驗證：驗證不同數據項之間的一緻性，如郵寄地址和郵編号碼的一緻性等。

總之，數據驗證是确保用(yòng)戶輸入數據的有(yǒu)效性和正确性的重要手段，可(kě)以使用(yòng)戶提交的數據更加準确可(kě)靠，同時提高系統的可(kě)用(yòng)性和安(ān)全性。

1.2 表單數據驗證常用(yòng)的幾種方式

客戶端驗證

這種驗證方式在用(yòng)戶提交表單之前，先在客戶端進行驗證。客戶端驗證的優勢在于能(néng)夠即時發現并糾正用(yòng)戶的輸入問題，提高用(yòng)戶體(tǐ)驗，它通常使用(yòng)JavaScript或jQuery等前端技(jì )術實現。

這種驗證方式針對表單中(zhōng)的每個元素進行驗證，包括必填項、長(cháng)度、格式、類型等。表單元素驗證可(kě)以提高表單的可(kě)用(yòng)性和用(yòng)戶體(tǐ)驗，同時可(kě)以減少用(yòng)戶輸入錯誤的可(kě)能(néng)性。

服務(wù)端驗證

這種驗證方式在用(yòng)戶提交表單後，由服務(wù)端進行驗證。服務(wù)端驗證可(kě)以防止惡意用(yòng)戶繞過前端驗證，确保數據的完整性和安(ān)全性。它通常使用(yòng)後端編程語言如PHP、Java或Python等實現。

數據庫驗證

這種驗證方式在數據存儲到數據庫之前，對數據進行驗證。數據庫驗證可(kě)以确保數據的有(yǒu)效性和一緻性，同時可(kě)以防止惡意用(yòng)戶繞過前端和後端驗證，它通常使用(yòng)數據庫查詢語句實現。

總之，做好數據驗證工(gōng)作(zuò)，可(kě)極大地提升數據質(zhì)量。

2.架構與設計

2.1 架構

應用(yòng)間交互图

說明

推薦采用(yòng)以上系統間交互方式，通過網關來與規則引擎交互，可(kě)能(néng)更适應于當前市場主流的微服務(wù)體(tǐ)系
将鑒權、流控、熔斷等都集中(zhōng)在應用(yòng)服務(wù)網關上完成，從而保護規則引擎服務(wù)器
由于，規則引擎的輸入接口數據格式比較特殊，可(kě)能(néng)需要在應用(yòng)服務(wù)網關轉換，以更加适配于目标開發团隊現有(yǒu)的技(jì )術棧和接口交互标準

規則項目關系图

說明

規則項目類型有(yǒu)2種，公(gōng)共項目和普通項目，我們的uRule産(chǎn)品支持項目間的引用(yòng)和共享，允許在普通項目中(zhōng)調用(yòng)公(gōng)共項目中(zhōng)的規則文(wén)件
在新(xīn)建規則時，将本單位的輸入規則進行提練，将比較常用(yòng)的、通用(yòng)的規則編寫在【公(gōng)共項目】中(zhōng)，然後在【普通項目】中(zhōng)進行引用(yòng)，按需組合規則并向自己的業務(wù)應用(yòng)系統提供驗證服務(wù)

2.2 數據較驗流程

2.3 設計

用(yòng)戶本地維護的規則編号表

自定義全局編碼	知識包id	較驗規則說明
CK_USERNAME	301	用(yòng)戶名(míng)較驗
CK_USEREMAIL	302	用(yòng)戶郵箱較驗

開發者自建的對照關系表，即能(néng)展示本地特色、方便開發者在前端應用(yòng)界面中(zhōng)記憶等，又(yòu)可(kě)以與uRule解耦，在遷移項目時知識包id可(kě)能(néng)會重新(xīn)編号，出現不能(néng)匹配到的問題
自建的對照表可(kě)以作(zuò)為(wèi)組織的知識庫公(gōng)開顯示和查詢，更能(néng)提升工(gōng)作(zuò)效率

前端在調用(yòng)時，輸入數據問題

規則碼如上图所示，标記着調用(yòng)那個知識包
輸入數據格式需要抽象，并保持全域（所有(yǒu)的消費方）一緻性，方可(kě)多(duō)路複用(yòng)，兼容多(duō)種複雜的場景
輸入參數可(kě)能(néng)是個List集合或者是Map，但不能(néng)是個java對象（BOM），可(kě)能(néng)會涉及到多(duō)個表單要素間的組合性檢查，輸入對象的實例化（Map轉換成BOM）應放在調用(yòng)入口規則上
需要注意此處的字段名(míng)fieldName輸入值來源于“數據字典”，全域公(gōng)用(yòng)的，規則引擎中(zhōng)會根據這個fieldName匹配規則算法

{
  "ckId":"CK_001",
  "inputData":[
    {
      "fieldName":"myName",
      "fieldValue":"張三"      
    },
    {
      "fieldName":"myCerKind",
      "fieldValue":"1"
    },
    {
      "fieldName":"myCerCode",
      "fieldValue":"420322xxxxxxxxxxxx"
    }
  ]
}
{
  "ckId":"CK_002",
  "inputMap":
    {
      "custName":"張三豐",
      "custCerType":"2",
      "custCerCode":"123456789"
    }
}

返回到前端的數據，标準結構

{
  "resultCode":"200",
  "resultMsg":"較驗通過"  
}
{
  "resultCode":"999",
  "resultMsg":"較驗未通過",
  "data":[
    {"checkMsg":"不滿足最小(xiǎo)長(cháng)度","checkCode":"0","checkFieldName":"myName"},
    {"checkCode":"1","checkFieldName":"myCerKind"},
    {"checkMsg":"證件号不滿足行業規範要求","checkCode":"0","checkFieldName":"myCerCode"}
  ]
}

3.示例程序

3.1 業務(wù)需求

3.1.1 技(jì )術要求

實現對客戶信息的輸入項合規性較驗，在業務(wù)場景發生變更時，能(néng)及時調整數據的較驗規則，生産(chǎn)系統能(néng)及時變更生效，無需走繁雜的項目變更發版流程
本單位各業務(wù)系統的具(jù)有(yǒu)相同業務(wù)含義的要素，原則上執行同一套輸入标準，以保證數據的完整性和一緻性

3.1.2 業務(wù)規則

客戶姓名(míng)：元素值是一個長(cháng)度在[4, 120]區(qū)間内的字符串
客戶證件類型：元素值是一個整型數值，取值範围[1,2] ，身份證和戶口本
客戶證件号碼：當證件類型是1-身份證時其長(cháng)度是18位字符串，而且是一個合法的有(yǒu)效的身份證号碼；當證件類型是2-戶口本時其長(cháng)度是9位字符串

3.2 uRule規則引擎實現過程

3.2.1 新(xīn)建項目

新(xīn)建2個規則項目：公(gōng)共項目和普通項目
在公(gōng)共項目中(zhōng)編寫【客戶姓名(míng)較驗規則】【客戶證件類型較驗規則】【客戶證件号較驗規則】

3.2.2 公(gōng)共規則庫項目

3.2.2.1 庫文(wén)件

變量庫（BOM）

客戶信息

輸出BOM

輸入BOM

參數庫

公(gōng)共參數庫

其它參數庫

3.2.2.2 客戶姓名(míng)較驗規則

3.2.2.3 客戶證件類型較驗規則

注意：本示例隻允許1-身份證，2-戶口本這兩種類型

3.2.2.4 客戶證件号較驗規則

戶口本号碼規則

身份證号規則，算法有(yǒu)點複雜，涉及到多(duō)個規則文(wén)件

身份證号較驗算法明細

以下是身份證号較驗算法所需要的轉換關系表，在上述規則中(zhōng)有(yǒu)調用(yòng)

3.2.3 數據分(fēn)析項目（普通規則項目）

3.2.3.1 客戶三要素較驗規則

注意：

在此規則中(zhōng)需要導入【公(gōng)共項目】的參數庫，也會直接調用(yòng)公(gōng)共項目中(zhōng)的規則文(wén)件
根據輸入的【字段名(míng)】動态匹配相應的規則執行組，也可(kě)以增加一個輸入項“規則名(míng)”來匹配規則的
将輸入的Map轉換成【變量】對象，方便後續的規則較驗邏輯的輸入

3.2.3.2 定義公(gōng)共動作(zuò)模闆

說明：将常用(yòng)的賦值語句分(fēn)組定義在動作(zuò)模闆庫中(zhōng)，以達到抽象和快速引用(yòng)目的，提高規則編寫效率和可(kě)讀性；例如上述的規則中(zhōng)就出現了【動作(zuò)模闆：數據較驗返回值賦值動作(zuò)】，二者遙向呼應

3.2.3.3 創建知識包

創建知識包

Rest服務(wù)測試

3.2.4 示例項目（普通規則項目）

3.2.4.1 客戶姓名(míng)較驗規則

注意：将輸入Map轉換成【客戶信息】對象

3.2.4.2 創建知識包

創建知識包

Rest服務(wù)測試

3.3 測試

3.3.1 在postMan工(gōng)具(jù)中(zhōng)模拟消費方

3.3.1.1 客戶三要素較驗測試

3.3.1.2 客戶姓名(míng)較驗測試

輸入數據

[
    {
        "name": "參數",
        "fields": {
            "inputMap": {
                "custName": "張"
            }
        },
        "class": "java.util.HashMap"
    }
]

輸出數據

{
    "output": [
        {
            "參數": {
                "outList": [
                    {
                        "checkMsg": "客戶姓名(míng)違反業務(wù)規則：張",
                        "checkFieldName": "custName",
                        "checkCode": "0"
                    }
                ]
            }
        }
    ],
    "duration": 6
}

3.3.2 在某個消費方業務(wù)系統模拟

3.3.2.1 編寫消費方後端api接口

3.3.2.2 驗證‘客戶姓名(míng)合規性’

（1）前端頁(yè)面代碼

（2）測試用(yòng)例

前端輸入空值，較驗未通過

前端輸入【張三豐】較驗通過

前端輸入【1234】較驗不通過

消費方控制台打印日志(zhì)

3.3.2.3 驗證‘客戶三要素合規性’

（1）編寫前端頁(yè)面代碼