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