最這一個月和sap做整合，把主資料中的資料寫入到sap系統中，做整合就離不開聯調，平時開發中，一個複雜點的系統還容易出問題，涉及到兩個系統，由於兩個或多個系統來自不同的廠家，各個廠家的開發對業務的理解深淺不一樣，各廠家所用的開發語言不一樣，技術不一樣，經驗也不一樣，這麼多一樣，一旦出現問題，就比較棘手，聯調起來就困難。
下面來說一下，多個系統整合，通常的做法：
1，webservice 介面，這個恐怕是最普遍的做法了。 能使得執行在不同機器上的不同應用無須藉助附加的、專門的第三方軟體或硬體， 就可相互交換資料或整合。依據Web Service規範實施的應用之間， 無論它們所使用的語言、 平臺或內部協議是什麼， 都可以相互交換資料。Web Service是自描述、 自包含的可用網路模組， 可以執行具體的業務功能。Web Service也很容易部署， 因為它們基於一些常規的產業標準以及已有的一些技術，諸如XML和HTTP。Web Service減少了應用介面的花費。Web Service為整個企業甚至多個組織之間的業務流程的整合提供了一個通用機制。
總結起來的優點有：1，跨平臺（這裡指的是不同的系統平臺），2，易部署，3，方便遠端呼叫，4實時
2，採用庫方法，資料提供方往中間庫寫資料，另一方從中間庫中取資料，好處非常明顯，責任明確，缺點是不能實時反應資料更新，如果對資料的實時性要求更，則需要提供心跳服務，實時去檢測中間庫資料有沒有更新，這樣帶來的是效能的損耗，
3，第三方提供的中介軟體介面，缺點是，通用性不強，需要專門去學習，出錯難除錯。
這次和sap整合採用的是第三種方式，由sap提供介面元件，sap介面根本不熟悉，sap方說網上sap介面資料大把大把的，這個確實不假，但用vb寫的確實很少，相關的教程很少，有木有?好不容易照貓畫虎完成了，卻整合不通過...
仔細找原因,現在總結幾條通過這幾次做整合的經驗教訓：
1，引用第三方元件時，注意檢視適用.net的版本，在一次引用NPOI時，NPOI適用於.net2.0 sp1,及以上版本，沒注意後面的sp1，釋出伺服器端一直出錯，原因找了好幾天才發現。注意選擇專案的.net版本，今天做引用sap元件時，把專案版本設為.net2.0時，會報錯，設定.net3.0時就不會，可能與引用元件有關，
2，在做一個複雜的整合時，先分解任務，先個精簡版本的整合再一步一步擴充套件。這樣可以隨時對比，找出不同。
3，拆分模組，優先保證前置模組的正確性。這與2類似。不要等到所有模組做完了才發現第一個模組不正確，不合理，如果這時底層東西不合理，修改起來也是相當困難的。
4，在一新的自己不熟悉的業務或技術面前，最好不好全新開發，找一個成熟穩定的demo照著改，比自己從頭學起要來得快。
再來看一下今天和sap整合的demo吧，採用的是RFC方式整合的，推薦sap專題，點選查閱：http://www.cnblogs.com/mengxin523/category/257935.html
直接上程式碼吧，