[CASE Study]異質資料庫資料交換架構
| 實務案例 |
專案變的越來越複雜，系統間的合作越來越密切。
多年前在職場上遇過一個Case，我所任職的公司要與外部廠商做資料庫的資料交換。那時我任職的公司的ERP是使用鼎新的Tiptop。那時
的版本還是屬於要使用Netteam去連線使用的版本。Tiptop 在那時也沒有Http的能力。本來想把這個棘手的問題交給鼎新去解決，礙於
經費有限的各項問題，我們必須自己完成這個案子。那時候的背景環境；我們公司在台灣，而對方公司在大陸。之間也沒有任何的專線
，所以要靠網際網路交換資料。對方是什麼系統，我們也不知道。(對方的IT部門也不會跟我們說的)。所以經過交涉後，雙方決定用
Web Service來解決交換資料中所有衍生的問題；包括 交易、資訊安全….等。而我們就有以下幾個問題要解決。
1. Tiptop 的 4GL 沒有 Http能力，所以要替他長出的 Web Service 的接口來。
2. ERP 有複雜的資料表關聯性，你的資料要寫入ERP。一般都是嚴禁你應用程式繞過ERP的程式去直接寫資料庫，這是不被允許的。所
以你的 Web Service 要能處發 4GL 讓原本的那隻負責新增進這個資料庫的 4GL 去寫資料庫。
3. 這支Web Service 放出去公司外部，不是所有人都可以來呼叫使用他。所以第一關用防火牆去過濾來源位置。
4. 但是兩邊ERP資料交換會有一些比較敏感的資料，這些敏感的資料就在網路上用Http 或 SOAP封包傳送是很危險的，所以使用SSL機制
來保護資料。
5. 雖然有防火牆過濾惡意的封包，但是為了避免來源IP遭到偽造( 雖然機率不大 )，所以要求了對方在封包內夾帶數位簽章。來作為身份
的確認性與不可否認性的防護。
6.有了數位簽章可以證明來源了，但是不是證明來源的人都可以使用這個web Service來送資料給我們的ERP。所以在XML資料中有協定了
一個區塊來做授權的動作。
7. 上面都過關了以後，接著就是交易的問題。當對方說它們送出過資料而我們資料庫卻沒有資料寫入，必須確認到底出了什麼問題?? 是
對方送出的資料在路途上遇到網路斷線的問題遺失掉了、還是封包有來到我們公司，在我們內部遺失掉??? 所以要解決交易問題，只要
封包進到我們公司，任何在公司內部發生的問題而造成的交易失敗，指動作都要重新觸發執行，直到完成交易。
所以一開始我們替Tiptop長出一個 Web Service接口。其中我們使用Java 呼叫 Shell的方式來叫用4GL的程式去寫資料庫。因為繞過程式去
直接對資料庫做修改日後衍生出的問題會很多。包括你要把握你的程式都跟4GL都要同步更新。而為什麼會使用JAVA 來呼叫 Shell，是因
為Tiptop所在的主機是 Linux。那就再上面直接起一個JAVA的VM來處裡這件事情了。再來資料在網路上如果直接用SOAP封包互相傳遞也
是很危險的，所以在那邊使用了SSL的技術來保護中間資料的安全性。裡面還包括了用防火牆先過濾非指定的IP位址來存取我們外放的
Web Service、因為是ERP資料的交換；會牽扯到金額，所以雙方的數位簽章驗證….等等。現在的專案變的越來越複雜，系統跟系統間合
作的需求越來越高。中間要注意的問題可能已經不單單只是資料有寫入資料庫就好。交易的問題、資料格式的對應、資料傳輸的安全.
…。使得IT人員受到的挑戰越來越高。如果解決問題的方法又不是很好的話，也許會導致公司在某些方面的競爭力會被削弱。因為IT
人員沒有辦法很 Smart 來協助公司因應市場快速變化下所衍生的需求！
