長此以往，IT雖勞苦，但收效甚微，很能理解給業務帶來的作業困難與無奈，于是團隊決策者開始靜下來著手解決之道，個中不斷尋求系統廠商助力，但似乎都已成世紀難題。從尋求專業的系統集成解決商，例如ESB、資料中臺等等，尋而往來，卻不得解，路漫漫其修遠兮，吾將上下而求索！
知己所需還應知彼長短。初心未變，變的是歲月，此情此景我想聊聊我們對服務互動探索的淺見：
?人工處理實作：人工傳遞、手工錄入，不限于兩邊系統對照、郵件等溝通后人工在各自系統中錄入、匯入、修改等方式；大量及重復的操作、查詢溝通才能處理，雖適合大批量，少單據、少變化的企業。但終不是正確之道。短期方案可備選。
?中間庫模式：各自系統實作邏輯傳遞到中間庫，同時相關資訊各自獲取進行后續處理；難以完成時序、邏輯校驗，優勢在于邊界清晰，錯誤定位責任清晰；但資料復雜，查找問題困難，處理問題往往需要在紛繁的事務中不斷摸索、優化。此模式目前為90%左右實施方標準方案，為啥？管殺不管埋，保證雙方責任邊界清晰，同時有記錄，專案得以必要保障。
?調度模式：適用于雙方系統提供查詢、回寫介面，需求方定時獲取資料及變化來更新目的庫資料，同樣需要在時間段內去對比資訊，事務處理非常困難，同樣難以承載時序、邏輯校驗。
?資料庫觸發器開發模式：適用于簡單基礎資料類對接(無邏輯處理)，其他業務要求考慮全面，在技術上作到最好，才能不影響業務和性能。觸發器也確實不容易被注意，給后期維護帶來困難。同時業務往往需要考慮觸發器的掛載和事務處理。此方法目前大量被乙方實施公司采用，主要原因為實作快，邏輯相對于簡單，它不用考慮操作端局限，只監聽資料庫對應的變化。作為甲方我們應該嚴格抵制它，這種不完善的方案終將如深埋的雷，往往帶來的風險、后果會超出你的想象。慎用之更應禁用之。
?代碼開發模式：適用于定向開發，優勢明顯在于可靠實作清晰的業務流程，資料互動，握手校驗，劣勢也非常明顯，在于開發很多不了解業務，業務很多講不清需求，理解不了開發架構。在企業業務變化為不變的真理時，往往會大量投入資源來應對，同時周期及交付難以把控，常常會牽涉多方溝通、管理接入、調整難，維護更難的局面，管理者應重視管理、運維、系統遷移、改造、代碼管理等等情形。同時應考慮怎么合理分配資源，協調資源可靠、快速完成以及人員培養定位、團隊建設。
?平臺模式：要實作系統的集成，底層的結構、軟體、硬體以及異構網路的特殊需求都必須得到集成。平臺集成處理一些程序和工具，以保證這些系統進行快速安全的通信。平臺兼備管理、運維、訊息等機制。
通過對比分析、取長補短，毋容置疑，平臺模式為我們奮斗的目標，選擇的根本，不難發現我們需要的平臺功能它應該具備:
?必須建立一套完善的系統來管理所有資料傳輸，并能夠快速擴展以回應客戶變化的需求，滿足應用程式可用性和用戶數目的增加。
?需要正視網路非可靠傳輸的因素，應建立端、或者類似網關的機制，可本地部署、云部署或者混合部署解決安全可靠、跨域的問題，實時系統監控,自動警報。
?輕量、高效、標準不失靈活的平臺功能，具備服務治理管理、更新管理、應具備核心的轉換和集成開發功能，同時提供可視化、快速實作、運維的需求。
?應杜絕大量繁瑣的作業才能實作互聯互通，建立服務生態系統，服務開放即可重用，系統遷移或新上時，更多傾向考慮本身API的功能即可互動。
?應具備清晰的資料記錄、結果記錄、應對系統業務不可重現時平臺需支持資料互動的傳遞及運維，同時應具備完整的操作日志、運行日志、訊息機制的推送等。
?應具備完整的安全機制、加密機制，身份驗證，授權和訪問，通用的訪問管理解決方案集成兼容，多種認證機制，標準和令牌型別等
平臺開發啟動同時啟動了ERP的介面開發：此次開發監管ERP資料底層，在ERP本身功能及API上進行二次開發封裝，實作了ERP觸發時機、
對接資料、單據流關聯等可視化配置操作，例如標準采購(訂單)指定組織，
由開立→審核觸發異步模式新增服務到WMS系統中，
由審核→審核觸發變更修改服務，同步模式校驗WMS資料，校驗成功允許修改，否則彈窗報錯不允許修改，事務回滾。
由審核→開立觸發洗掉服務同步模式校驗WMS資料，校驗成功允許洗掉，否則彈窗報錯不允許洗掉，事務回滾。
同時啟動了WMS、MES介面開發與封裝；
接著我們將此子公司的介面全部進行測驗、遷移、優化，將近三個月，發現業務互動事件化，清晰透明，追溯查找方便；在后面幾個分子公司的系統上線時，介面配置，上線僅僅只用了一個星期。從以往的開發多方溝通實作，轉變為由實施人員根據業務自主配置物體觸發、手工批量觸發等方式來完成及交換。上線后例外服務提示對應人員，分析查找問題變得非常容易，資料不再是底層不可見的互動。同時對平臺實作自動分發，即時互動，服務上傳即生效，設計節點接收、傳輸資料，大大降低宕機、網路傳輸帶來的資料丟失。支持同步模式:系統間需要握手互動驗證；異步無序：負責資料傳輸、無序系統間校驗，效率最高；異步有序：資料包執行需考慮先后順序執行。
經過幾年的求知之路，更加堅定了設想的初衷，所謂正確的選擇，更多的是認準了思路。雖然專案是短期的經營活動、資源的分配利用、以及成果的交付，但作為資訊化的支撐團隊，我們更應像掌舵者，雖然路途漫長，程序艱辛。但苦中帶甘。更加覺得企業應自身強大起來，成為資訊化自主的實作者、管理者、決策者、運維者以及引路人。是以分享經歷，學知識，傳遞己見，贈人玫瑰，手留余香。在這個我認為的平行世界里，也許存在眾多的同道者、困惑者，還望不吝賜教，相互學習。再次感謝撥冗翻閱拙文，如若不棄，可互友把酒桑麻。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/169990.html
標籤：企業信息化