一、概述
OracleEBS是Oracle公司的ERP產品，這個產品非常龐大，可以對企業的各個方面進行強大的管理功能，一般大型企業都會用到它的部分模塊，根據公司的性質不同，選擇的模塊也會有所不同。對於生產型企業，所采購的模塊中都會包括產品及價格等管理模塊。
ERP屬於大型系統，能選擇Oracle ERP的企業，規模一般也不會太小，所以在IT方面，除了ERP產品本身，一般還會有其它一些小型的專有業務系統來支撐，這些系統有些是在ERP上線之前就在一直使用的，並不能簡單的用ERP產品來全部替換他們。根據實際情況來看，少不了要在各個系統與EBS之間，實現部分信息的同步，特別是產品信息，一般將會選擇在ERP系統中維護，而其它系統可以直接引用ERP系統中的信息，這樣保證產品信息只有一套，不會出現冗余，也不會出現歧義。
我們公司在以前與ERP進行接口的時候，用到了很多的辦法，其中最常用的就是直接從ERP里讀取信息，然后直接寫入業務系統，或者由業務系統發起，直接向 ERP中寫入信息。對於簡單的信息，這種做法還基本能行的通，但是對於更復雜的業務邏輯，這種做法風險是不能小看的，因為根據使用EBS的經驗來看，EBS的設計非常的復雜，表結構與套用關系也是錯綜復雜，有時感覺修改一個表就夠了，但是在真正使用的時候，或用過一段時間之后，才發現ERP的數據一致性已經被破壞，有時甚至會造成ERP系統出現問題，並且有時候已經很難恢復，所以這種做法並不可取。
EBS本身提供了一系列的接口表，所以向EBS寫入數據的過程，Oracle公司都建議使用接口表，在臨時數據寫入接口表之后，OracleEBS的產品中會有相應的接口程序來實現對接口表的描述及導入生產表，這樣會盡量維持EBS的數據完整性。當然從本質上來說，還是對數據庫表的操作，但是這種做法已經安全了很多。
以上所說的一般都是指應用系統與ERP系統都處於公司的同一個網段，這種情況下才有可能用數據庫連接的方式來集成，但是對於有些應用系統位於不同的地理位置，甚至位於海外的時候，這種方式就顯得力不從心了，因為從其它數據中心發起的請求是無法直接到達ERP的數據庫的。
其實很多系統的集成需求抽象出來，有很大的相似性，但是如果由各個廠商自己來制定標准，可能對EBS的影響比較大。出於此種情況，可以考慮將EBS的接口進行規范化。
在對EBS接口進行規范化的時候，需要考慮幾點問題
Ø 數據的安全性
接口只能開放相關系統需要的部分，不能讓更多的業務數據向外開放；
相關應用系統只能通過合法的手段進行接口驗證，未授權的系統不能使用該接口。
Ø 數據的一致性
EBS系統的結構相當復雜，在數據寫入的時候，一定要注意數據的完整性和一致性，如果系統中存在多個表的冗余，一定要把所有相關的表全部同時處理，如果所處理的表不全面，會造成EBS致命的錯誤。為了實現這個一致性，應該盡可能使用EBS自身的接口表系統，然后由EBS自身的標准請求來處理后續的工作。
Ø 系統的通用性
此接口系統需要考慮對目前需要接入的幾個系統的通用性支持，即此接口系統盡量要做到與業務系統無關，通過簡單的配置即可實現對不同的系統的支持；
另一個需要考慮的因素就是接入EBS的第三方系統，有些位於企業總部，可以直接連接到EBS的數據庫服務器，而有些系統位於海外，沒有能力直接與EBS的數據庫相連，為了實現這個通用性，考慮使用WebService的方式來處理，即發布一個公網的WebService，讓它與EBS的數據庫相連接，這樣就可以實現不同地理位置的系統的連接。
在下一期中，我們將討論一下實現集成的架構。
上面一期簡要介紹了一下思路，這一篇文章講一下實現。
接上文
二、架構
系統從總體上分為兩部分，一部為企業的EBS及接口系統，第二部分為第三方廠商自建系統。
在企業總部系統部分，又分為兩部分，一部分為WS接口系統，第二部分為原始EBS系統。
在EBS部分，又可以分為正式表和接口表兩部分。
整體需求在技術上分為兩類：
Ø 只讀EBS
WS直接從EBS生產表或接口表中讀取數據，因為不涉及到寫入操作，所以只要清楚數據庫結構即可得到所需要的數據；
Ø 讀寫EBS（需要交互）
這部分工作比較復雜，需要對EBS進行寫入操作，因為EBS的復雜性，需要把內容寫入到接口表中，由標准請求來處理接口表到正式表的導入。
在數據導入到正式表的過程中，有可能發生驗證失敗的情況，這種情況下，標准請求一般會在接口表或其它地方記錄出錯的信息，如果第三方需要這個信息，可以調用接口表從而得出相應的結論。總之，第三方與EBS的交互可以靠兩種方式組合得出，但是交互的效率可能會相對稍慢，即中間有一定的延時。
所謂標准請求，是指EBS自帶的一些功能，至於它都有哪些標准請求，需要查閱EBS的相關文檔，它們有的就是有，它們沒有的，誰也不能提供。
在技術架構方面，WebService接口部分采用Visual Studio 2008來開發，因為WebService與具體的程序語言無關，所以只要使用標准的接口規則，就可以被多個第三方廠商所使用。
三、WebService接口實現
WS服務器采用Windows2008+IIS來實現，由WS來實現第三方廠商與EBS的溝通及交互，保證第三方廠商的系統（無論是在總部還是在海外IDC）都可以順利的與EBS進行通訊。在接口實現這一部分，將分多個部分進行說明：
Ø 安全通訊
在第三方與WS通訊的時候，需要考慮通訊的安全性，WS本身將采用HTTPS的方式來工作。
因為不能保證全部第三方系統都能采用域驗證的方式來使用，所以在數據傳輸上，還需要考慮一些更通用的WS的驗證方式。
在每新增加一個第三方廠商的時候，系統會分配給他們一個密碼串（32字節），這個密碼串是每個廠商（系統）唯一的，也不會在不同的廠商之間互相通報，每次數據發送，都會帶着這個密碼串一起發過來，這樣可以首先確定上載數據的合法性，同理，數據下傳的時候也會采用此種方式。
Ø 靈活性
WS設計的原則應該是盡量把數據庫表進行封裝，使得第三方無須過多的了解EBS的表結構即可以正常工作，但是同時還要考慮WS的擴展性，所以不能做太多的接口函數，應該盡量采用Schema的方式來描述，每個Schema將與具體的業務及操作相對應，Schema的擴展相當靈活，可以隨着業務的發展和新的第三方廠商的介入不斷的完善及發展，形成一個標准的EBS接口Schema庫，並形成相應的說明，可以挑選合適的Schema來使用。
到此為止，我們只說明了實現的兩個方面，安全性和靈活性，在下一期中，我們將對其它幾個方面進行說明。
Ø 讀取數據
讀取數據使用專門的接口函數，並且只有一個函數，可以做幾次重載來實現不同的需要，更多的情況是靠schema參數來區分操作的類型，返回的類型為XML 文件，並且第三方會知道按何種方式來拆解此返回的XML。XML可以是單表，也可是多表的記錄集的形式，具體返回格式完全由Schema來指定；在返回之前，考慮傳輸的效率，需要對返回的數據進行壓縮，然后再二進制數組的形式來返回
² 函數原型
public byte[] GetData(string schemaName,string whereClause,string password) //取出指定條件的記錄集
² 參數
schemaName
指定的模式名稱，對於模式及模式的使用方式，在后面會有專門的描述
根據指定的模式，系統會找到相對應的表，返回所需要的字段
whereClause
它是根據一個查詢條件來返回記錄，這樣可以實現很復雜的查詢功能，返回的記錄集遵循指定的Schema
password
由系統分配給第三方廠商（系統）的一個hash串，作為唯一的標識，服務器端接收到消息后，會檢查這個密碼串的合法性，如果系統中不存在這個串，則不能進行任何操作。
關於密碼串的具體說明和用法，在后面有專門的描述。
² 返回值
返回值一律為字節數組，而不采用XML直接返回，這樣可以在傳輸之前做更多的處理，比如壓縮和加密，本次設計中暫不包括加密處理，壓縮采用標准的壓縮算法。
第三方在收到字節數組后，使用標准的壓縮算法將其解開，還原成一個XML文件
在第三方客戶端，會存在相應的Schema來解析這個XML，具體使用哪個Schema，由客戶端自己來把握，與服務器端無關，信息拆解后如何使用，也由客戶端自己把握。
如果操作失敗，返回的錯誤也會按字節數組的形式來返回，所以客戶端接收后首先要檢查操作是否成功，如果確認沒有失敗，再去檢查具體的返回內容。
Ø 寫入函數
寫入動作是指由客戶端發起，向服務器寫入相關的內容，在本系統中，寫入的內容與業務無關，全部抽象為技術層面來處理。
² 函數原型
public byte[] WriteData(string schemaName,byte[] content,string password)
² 參數
schemaName
與讀取函數的功能相似。
content
要寫入的內容，在客戶端生成，首先生成一個XML文件，與schemaName相對應，生成XML后，在客戶端進行壓縮和加密等操作，生成一個二進制的字節數組上傳 到服務器。
password
與讀取函數功能相似。
² 返回值
與讀取函數類似，返回字節數組，客戶端先要對其進行解壓和解密方可使用，盡管很少量的內容返回壓縮后反而會更大，但是為了統一的管理方式，仍采用這種方式來工作。
Ø 數據傳遞
數據為雙向傳輸，即有些是從第三方系統寫入EBS，有些是從EBS讀取返回給第三方系統。
對於單向讀取（EBS->第三方），沒有數據一致性的風險，直接返回即可，完全通過Schema的添加和配置就可以實現數據安全有效的控制。
但是對於另一個方面的傳輸（第三方->EBS），就存在着一個比較敏感的問題，因為EBS的數據結構非常復雜，很難完全掌握它的結構，所以這個方向的傳輸，一定要把握一個原則，就是只能寫到EBS的接口表中，不能直接寫入生產表。這部分內容會在Schema部分有更詳細的說明。
在下一期中，我們將來詳細的介紹一下系統的安全性。
四、安全體系
在上面的章節也提到了數據的安全及一些策略，在此將詳細的論述安全的數據傳輸。
Ø SSL體系
這是一個網絡層的解決方案，具體做法是在IIS上配置相應的SSL證書，從而實現一個SSL的站點，安全證書采用VeriSign，可以從中國的代理機構購買。
SSL的方式會增高系統的安全性，但是也會對性能有一點點的影向，不過不會成為系統的性能瓶頸。
另外還需要驗證是否所有的第三方廠商在寫程序的時候都支持這種SSL方式，因此這個體系作為一個可選件存在，可以隨時啟用，不影響整體的架構。
Ø 壓縮與加密
當數據在客戶端與服務器通訊的時候，如果不采用SSL的方式，則信息在internet上是可以被截獲並破解的，為了解決這個問題，需要對數據做一定的預處理，然后再 進行傳輸。
壓縮是必選項，采用標准的ZIP壓縮算法，客戶端采用何種工具進行壓縮和解密由客戶端自己把握，不提供專門的處理函數。
對於加密算法，可以采用標准的加密算法，也可以采用自己定義的簡單加密算法，也可以暫時不考慮加密，只用壓縮來處理，本期暫不考慮加密算法。
Ø 密碼串（識別碼）
系統會為每個第三方廠商（系統）分配一個唯一的識別碼，為了加強此識別碼的強度，采用32字節長度的密碼串，此密碼串本身沒有任何含義，只作為唯一的標識，加大它的長度，即減少了被盜用的風險。
關於密碼串的分發，不考慮程序實現，只用手工處理即可，可以使用郵件的方式來發送。
為了驗證密碼串，需要服務器端與客戶端都同時存儲這個密碼串，這樣才可以驗證。這里的服務器指的是WebService服務器，而不是EBS服務器，因為不方便在EBS中添加過多的定制化內容。
在服務器端，密碼串的存儲可以直接使用XML文件或平面文件都可以，這個可以在具體實現的時候再決定，在文件中僅需要簡單的存儲以下信息：
² 密碼串
用於溝通的字符串，32字節長，手工產生，隨意生成，沒有規則，只要保證能正確下發到相關的第三方廠商手中即可。
² 廠商名稱
用於標識，系統中不使用此標識。
² 有效起始日期
大於此日期后，該密碼串才被認為是合法的，此字段不能為空，可以靠很小的日期來處理特別情況。
² 有效結束日期
小於此日期，該密碼串才被認為是合法的，此字段不能為空，可以靠很大的日期來認為是無限期的，以上兩個日期可以隨時調整，以更改密碼的可用性。
² 創建日期
此條記錄添加的日期。
² 創建人（字符串描述）
是誰添加了這條記錄。
² 最后修改日期
² 最后修改人
在服務器IIS啟動的時候，在Instance_Startup類型的函數中，加上特別的處理，把所有的密碼串全部讀出來，放入Global變量中（只讀取密碼串一個字段，其它均不讀入），在WebService的GetData/WriteData函數中，首選檢查傳入的密碼串參數是否是合法的，如果是合法的，再繼續后面的操作，如果是非法的，直接返回“非法使用”之類的錯誤。
驗證函數如下：
private bool ValidPassword(string password)
客戶端收到總部關於密碼的郵件后，所有的操作均必須帶着這個密碼，如果因為密碼填寫錯誤，會造成一系列的錯誤，需要第三方自己把握。
關於密碼變更：
密碼變更在服務器上需要對原密碼的有效結束日期進行更改，並記錄更改人；
同時添加一條新的記錄，並確認結束日期合法；
最后把新的密碼下發給第三方廠商。
Ø 數據庫表ACL
原則上客戶端會按照約定的規則來讀取和寫入數據，但是為了防止惡意讀寫，在此專門設置ACL，控制哪些表可以讀寫，ACL文件為標准的XML文件，包括以下三個屬性：
² 表名（大寫）
² 是否可讀（BOOL型）
² 是否可寫（BOOL型）
同樣，在系統啟動的時候，會把這些信息讀入到內存中備用。
Ø 私有信息
同一張接口表中，可能會同時有多個廠商進行操作，這時要保證不同的廠商之間的操作不會互相影響，為此需要在相應的接口表中找一個合適的字段，來存儲廠商的密碼串。
在后面的部分，我們將對Schema進行描述，這是數據通信的基本單位。
五、XML Schema
為了實現更通用性的交互，Schema是最重要的一部分。
這里的Schema是標准的模版xsd文檔，遵循所有的標准規格。
關於XML Schema的詳細內容，在此不做描述，可以從其官方網站上得到解釋。
在讀取數據和寫入數據的時候，都會用到Schema，Schema就是用來實現對原始表的一個映射。
在服務器端（WebService服務器）和客戶端都存在一份Schema列表，在服務器上存儲全部的Schema，但是在客戶端，只存儲和自己業務相關的部分，不會存儲全部Schema。
Ø 數據讀取
Schema文件用於數據的描述，但是和數據庫本身沒有任何依賴關系，現在需要根據這個Schema來得到一個SQL語句才可以去數據庫里取數據。為了簡單快速的實現Schema與SQL語句的轉換，可以再寫一個專門的文件，文件名與Schema相同，擴展名為.select，表示是一個選擇數據的SQL 語句，此文件只存在於服務器上，客戶端不知道此文件的存在。在Instance_Startup的函數中，將所有相關的SQL全部一次性讀入到內存中，方便后期快速使用，當然如果有任何這種文件的變化，都需要IIS的重新起動。
對於where條件，可以作為一個字符串直接拼接在SQL后面，得到一個真正的SQL語句，SQL中沒有參數的概念，拼接完成的SQL，在數據庫中可以直接使用，為保證SQL的可用性，客戶端在寫where條件的時候一定要遵循一定的規則，包括and / or 之類的匹配關系，小括號/單引號的使用等，一定要正確。
對於標准的XML的生成，有兩種方案：
如果Oracle10g支持XML SQL，可以直接生成符合xsd標准的XML文件；
如果不支持，只能返回一個DataSet，再參考Schema的格式，手工生成一個XML文件。
生成XML后，調用壓縮工具包對其進行相關的壓縮處理，生成二進制數組，直接返回。
如果使用過程中發生錯誤，則返回“查詢錯誤”之類的代碼，可以把相關的錯誤代碼返回。
在讀取之前，需要判斷此表在ACL列表中是否可讀（如果不好判斷，可以跳過此步驟，因為SQL不是客戶端可以更改的）。
Ø 數據寫入
數據寫入的函數里面有一個字節數組，首先對其進行解壓及解密，生成一個XML文件，此文件與Schema配合，讀入系統成為一個標准的DataSet，此時可以利用現有的技術直接把該內容寫入到數據庫中，在寫入之前，一定要去ACL中檢查一下，此表是否可以寫入。
六、EBS端相關操作
所有的寫入操作均寫入EBS的接口表中，不會直接寫入正式表，因此寫入接口表中后，需要調用EBS的標准請求來把接口表寫入正式表。
關於接口表，不同的模塊有不同的接口表，並且有不同的操作方式，有不同的請求來實現，所以需要根據實際的接口情況，考慮EBS的接口表及標准請求，並研究標准請求返回的錯誤信息及含義，還有就是錯誤返回的存儲位置，有些直接回寫入接口表，有些會寫入標准的錯誤日志表中，具體在操作的時候再確定。
七、總結
以上方式已經在我公司得到真正的應用，並已經為多個業務系統服役，使用效果良好，希望大家參考后能有所幫助。
天道酬勤不酬怨
李鳴(aicken)原創 轉載注明
FROM:
http://www.cnblogs.com/isline/archive/2010/04/14/1711910.html
http://www.cnblogs.com/isline/archive/2010/04/15/1712428.html