情況描述：
兩個不同的業務系統m系統與e系統，兩者之間的資料交換採用esb平台，從而可以保證esb內部的資料傳遞流程可以具有乙個全域性的事務，一旦發生任何異常，都會回滾。
資料傳遞的方向為從m系統傳遞至e系統。
前期約定的內容，esb獲取m系統的資料，資料獲取方式為從esb與m系統約定的資料庫中間表中獲取（相當於m系統的前置機），呼叫e系統的webservice，將資料寫入e系統，並且將呼叫是否成功的結果寫回與m系統約定的中間表中（寫回m系統中間表的工作由esb負責完成），呼叫e系統的ws之後，除了回寫與m系統的中間表，還會有一些其他的資料庫更新等操作。
問題：
事務的問題可以交由esb來處理，可以忽略。
呼叫ws如果資料未能寫入e系統，ws不會丟擲異常，而是會返回乙個未能寫入的**，並返回原因。
呼叫ws成功，並且成功寫入e系統，但是，在後續esb處理其他事情的過程中發生異常，事務照樣回滾。而e系統的ws，沒有補償機制，不會對資料是否已經存在進行判斷，而且e系統的ws由於各種原因，呼叫時效能不佳
解決方案：
對於問題1。無需關注。
對於問題2。由於前期esb與m系統約定，一旦發生esb呼叫e系統的ws未能寫入的情況，m系統會重新生成新的資料，而不是對原有資料進行修改。esb只需將呼叫e系統的ws的結果返回寫入中間表即可，不管任何一方發生異常，均由m系統重新生成資料，重新傳遞。這樣esb只需監控新增的資料，並按順序執行相應操作即可。
對於問題3。就需要在呼叫e系統的ws之前，對e系統中是否存在相應資料進行判斷，如果存在，並且同時最近一次呼叫時返回的結果為正常，則不再重複呼叫ws，而是直接執行後續操作；如果不存在或者呼叫時返回的結果不正常，甚至沒有返回結果，則重新從頭開始執行相應操作。
另外，如果沒有與m系統關於呼叫e系統ws未能寫入的情況的約定，則esb需要根據e系統的ws的返回值進行判斷，如果不正常，則可以直接丟擲乙個異常，從而回滾整個事務（當然，也可以暫時將異常資料暫存至另外的資料庫表中或者其他什麼位置，防止此問題資料重複出現），保證流程下次可以再次取得此數值。當然，這樣也存在乙個問題，就是回滾整個事務，與m系統約定的中間表中，就無法取到呼叫結果是否正常的資訊，除非在esb平台中有乙個地方可以檢視異常資訊及資料，並且有專人來處理此類事情，否則，表面看起來就是esb停在某條資料那裡不動了，會對業務產生影響。
還有一種方案就是由於監控的增量資料都會記錄在乙個表中，如果發生呼叫e系統的ws未能寫入資料的情況，則不允許esb將監控到的增量資料刪除，並不是丟擲異常回滾整個事務，也就能夠正常檢視到產生錯誤的原因。
個人認為最後的解決方案是乙個比較不錯的思路，記錄一下以饗自己。
我碰到Cookie的乙個問題
csdn的使用者反饋回來乙個很詭異的bug，當使用者系統的時間不正確的時候，比正確時間快或者慢時，使用者就登入不上去，很詭異。解決這個問題花了我不少時間。導致這個問題的原因如下 使用 httpcontext.current.response.cookies.set 更新乙個cookie後，會導致 h...
安裝MSSQL碰到的乙個問題
為安全考濾，安裝之後會把一些內建的儲存過程去掉了。use master exec sp dropextendedproc xp cmdshell exec sp dropextendedproc sp oacreate exec sp dropextendedproc sp oadestroy ex...
安裝MSSQL碰到的乙個問題
為安全考濾，安裝之後會把一些內建的儲存過程去掉了。use master exec sp dropextendedproc xp cmdshell exec sp dropextendedproc sp oacreate exec sp dropextendedproc sp oadestroy ex...