在寫這個專題時，心情很怪異，如果您是專業人土，應該對下面的看似簡單的模式有所觸動，對于本人來講，這簡短的幾句話意味著的是上百萬的項目成本與近兩個月的項目延期的問題，因此，本人顯然對所有經歷過的大型項目中IT人員在此專題上的表現非常不滿意，因此把個人的想法在此與您分享，希望對您有所幫助（下面場景以A系統上傳數據到B系統，此方案不考慮中間件模式，主要從業務需求的角度上來分析）：
1、考慮從A系統重復上傳數據至B系統的問題。
?????? 1）、通過上傳數據時使用同一關鍵字可自然避免此問題。
?????? 2）、如果業務流程中難以使用同一關鍵字，則首先要明確A、B系統中各自數據行的關鍵字，然后一定要在從A系統上傳B系統時將A系統的關鍵字賦值到B系統數據行的某個字段，且這個字段一定要方便查詢，如具有搜索幫助功能的字段。
?????? 3）數據上傳是否成功需要反回值，并在A系統中有所記錄，單獨做日志記錄或修改上傳數據行狀態需根據需要而定。
?????? 4）強調3），判斷數據是否成功上傳的方式嚴格意義上來說應該是在上傳動作處理完后到B系統去抓對應的數據，除非B系統是非常標準可靠的大系統，接口為標準化可靠技術，才可以通過反回代碼來判定是否成功上傳數據。
?????? 5）區分第1次上傳與第1+N次上傳處理，如，當第2次按下了上傳鍵，則首先要去查看數據行狀態，如果為上傳成功狀態，則取消后續操作，如果為不成功，則要謹慎對待，這時嚴格做法是去B系統搜索是否上傳成功，如果B系統已成功，但A系統狀態沒改過來，出現報警日志，需手工確定、處理，如果B系統的確沒有該數據行+A系統中狀態為未成功，則可執行第2次上傳任務。注意這個“+”，少了它，您的邏輯就缺乏嚴謹性了，例如，上傳B成功，但在返回值時出現異常，從而出現重復上傳。
2、考慮某些異常處理方法。
????? 1）、如上所述，如果自動上傳失敗，您要有手動處理的方式。
????? 2）、要具備既能自動批量上傳，也可以手動批量上傳的功能。例如在A、B系統成功對接前，需要在A、B系統中手工單獨處理業務數據，一旦對接成功，這時需自動上傳，那么在此之前的業務數據需要補充上傳；或是在某種特殊情況下需要暫停A系統上傳B系統，后續再補提，那么在程序開發時需要考慮到這種業務需求，建議是通過某種方便的“閘”來統一控制，如定制參數等。“閘”的優點是統一、同時、一個不漏的控制業務對象。
3、定期的、規范的數據校對功能。
????? 如果不是A、B雙向接口，缺了這一功能，是您的失誤。由于A上傳B，通常會要求A、B兩系統中的基礎數據一致、業務數據同步一致，但往往很難從技術上去解決A、B系統雙向接口，這時我們需要考慮到當B系統單獨更改了基礎數據或是從A系統上傳的數據行時造成的數據不一致的校正工作。
????? 或許有人說我們在流程上已經規定了A、B系統單獨修改時必須同時更改，但是作為IT人員應該窮舉所有的特殊情況處理，比如，操作人員沒有按流程去做呢？
????? 因此，建議按具體業務來定統一校對工作，注意，不同的業務校對的時間間隔可設為不同，且要具備錯誤后續處理功能。
其它相關原創文章：
????????1.大型軟件系統應該具備的一些細節功能
??????? 2.專業專題點評：淺談物料編碼與技術實現
????????3.專業專題點評：數據歸檔/刪除處理邏輯簡介
（特別說明：以上為個人觀點，僅供參考，本人不對此方案負任何責任！—ERP Senior Consultant Vilion）