在寫這個(gè)專題時(shí),心情很怪異,如果您是專業(yè)人土,應(yīng)該對(duì)下面的看似簡(jiǎn)單的模式有所觸動(dòng),對(duì)于本人來講,這簡(jiǎn)短的幾句話意味著的是上百萬的項(xiàng)目成本與近兩個(gè)月的項(xiàng)目延期的問題,因此,本人顯然對(duì)所有經(jīng)歷過的大型項(xiàng)目中IT人員在此專題上的表現(xiàn)非常不滿意,因此把個(gè)人的想法在此與您分享,希望對(duì)您有所幫助(下面場(chǎng)景以A系統(tǒng)上傳數(shù)據(jù)到B系統(tǒng),此方案不考慮中間件模式,主要從業(yè)務(wù)需求的角度上來分析):
1、考慮從A系統(tǒng)重復(fù)上傳數(shù)據(jù)至B系統(tǒng)的問題。
?????? 1)、通過上傳數(shù)據(jù)時(shí)使用同一關(guān)鍵字可自然避免此問題。
?????? 2)、如果業(yè)務(wù)流程中難以使用同一關(guān)鍵字,則首先要明確A、B系統(tǒng)中各自數(shù)據(jù)行的關(guān)鍵字,然后一定要在從A系統(tǒng)上傳B系統(tǒng)時(shí)將A系統(tǒng)的關(guān)鍵字賦值到B系統(tǒng)數(shù)據(jù)行的某個(gè)字段,且這個(gè)字段一定要方便查詢,如具有搜索幫助功能的字段。
?????? 3)數(shù)據(jù)上傳是否成功需要反回值,并在A系統(tǒng)中有所記錄,單獨(dú)做日志記錄或修改上傳數(shù)據(jù)行狀態(tài)需根據(jù)需要而定。
?????? 4)強(qiáng)調(diào)3),判斷數(shù)據(jù)是否成功上傳的方式嚴(yán)格意義上來說應(yīng)該是在上傳動(dòng)作處理完后到B系統(tǒng)去抓對(duì)應(yīng)的數(shù)據(jù),除非B系統(tǒng)是非常標(biāo)準(zhǔn)可靠的大系統(tǒng),接口為標(biāo)準(zhǔn)化可靠技術(shù),才可以通過反回代碼來判定是否成功上傳數(shù)據(jù)。
?????? 5)區(qū)分第1次上傳與第1+N次上傳處理,如,當(dāng)?shù)?span lang="EN-US">2次按下了上傳鍵,則首先要去查看數(shù)據(jù)行狀態(tài),如果為上傳成功狀態(tài),則取消后續(xù)操作,如果為不成功,則要謹(jǐn)慎對(duì)待,這時(shí)嚴(yán)格做法是去B系統(tǒng)搜索是否上傳成功,如果B系統(tǒng)已成功,但A系統(tǒng)狀態(tài)沒改過來,出現(xiàn)報(bào)警日志,需手工確定、處理,如果B系統(tǒng)的確沒有該數(shù)據(jù)行+A系統(tǒng)中狀態(tài)為未成功,則可執(zhí)行第2次上傳任務(wù)。注意這個(gè)“+”,少了它,您的邏輯就缺乏嚴(yán)謹(jǐn)性了,例如,上傳B成功,但在返回值時(shí)出現(xiàn)異常,從而出現(xiàn)重復(fù)上傳。
2、考慮某些異常處理方法。
????? 1)、如上所述,如果自動(dòng)上傳失敗,您要有手動(dòng)處理的方式。
????? 2)、要具備既能自動(dòng)批量上傳,也可以手動(dòng)批量上傳的功能。例如在A、B系統(tǒng)成功對(duì)接前,需要在A、B系統(tǒng)中手工單獨(dú)處理業(yè)務(wù)數(shù)據(jù),一旦對(duì)接成功,這時(shí)需自動(dòng)上傳,那么在此之前的業(yè)務(wù)數(shù)據(jù)需要補(bǔ)充上傳;或是在某種特殊情況下需要暫停A系統(tǒng)上傳B系統(tǒng),后續(xù)再補(bǔ)提,那么在程序開發(fā)時(shí)需要考慮到這種業(yè)務(wù)需求,建議是通過某種方便的“閘”來統(tǒng)一控制,如定制參數(shù)等。“閘”的優(yōu)點(diǎn)是統(tǒng)一、同時(shí)、一個(gè)不漏的控制業(yè)務(wù)對(duì)象。
3、定期的、規(guī)范的數(shù)據(jù)校對(duì)功能。
????? 如果不是A、B雙向接口,缺了這一功能,是您的失誤。由于A上傳B,通常會(huì)要求A、B兩系統(tǒng)中的基礎(chǔ)數(shù)據(jù)一致、業(yè)務(wù)數(shù)據(jù)同步一致,但往往很難從技術(shù)上去解決A、B系統(tǒng)雙向接口,這時(shí)我們需要考慮到當(dāng)B系統(tǒng)單獨(dú)更改了基礎(chǔ)數(shù)據(jù)或是從A系統(tǒng)上傳的數(shù)據(jù)行時(shí)造成的數(shù)據(jù)不一致的校正工作。
????? 或許有人說我們?cè)诹鞒躺弦呀?jīng)規(guī)定了A、B系統(tǒng)單獨(dú)修改時(shí)必須同時(shí)更改,但是作為IT人員應(yīng)該窮舉所有的特殊情況處理,比如,操作人員沒有按流程去做呢?
????? 因此,建議按具體業(yè)務(wù)來定統(tǒng)一校對(duì)工作,注意,不同的業(yè)務(wù)校對(duì)的時(shí)間間隔可設(shè)為不同,且要具備錯(cuò)誤后續(xù)處理功能。
其它相關(guān)原創(chuàng)文章:
????????1.大型軟件系統(tǒng)應(yīng)該具備的一些細(xì)節(jié)功能
??????? 2.專業(yè)專題點(diǎn)評(píng):淺談物料編碼與技術(shù)實(shí)現(xiàn)
????????3.專業(yè)專題點(diǎn)評(píng):數(shù)據(jù)歸檔/刪除處理邏輯簡(jiǎn)介
(特別說明:以上為個(gè)人觀點(diǎn),僅供參考,本人不對(duì)此方案負(fù)任何責(zé)任!—ERP Senior Consultant Vilion)
評(píng)論
# re: 專業(yè)專題點(diǎn)評(píng):淺談系統(tǒng)間數(shù)據(jù)傳遞與數(shù)據(jù)一致性的核心技術(shù)模式
2006-05-31 10:13
charon@xxx
這個(gè)做法比較原始,如果只有A,B兩個(gè)系統(tǒng)還可以忍受。一旦分立系統(tǒng)數(shù)目增加,這種處理方式會(huì)產(chǎn)生網(wǎng)狀依賴,其復(fù)雜性是不可接受的。
實(shí)際上有一些可靠的機(jī)制可以可靠的搞定這些東西,比如MQSI之類的消息中間件。 回復(fù) 更多評(píng)論
實(shí)際上有一些可靠的機(jī)制可以可靠的搞定這些東西,比如MQSI之類的消息中間件。 回復(fù) 更多評(píng)論
# re: 專業(yè)專題點(diǎn)評(píng):淺談系統(tǒng)間數(shù)據(jù)傳遞與數(shù)據(jù)一致性的核心技術(shù)模式
2006-05-31 10:31
恩達(dá)
謝謝您的提醒,我已經(jīng)更改了文章適用前提的限制條件,使用中間件的確是最好的技術(shù)方案,但不是最經(jīng)濟(jì)的商業(yè)方案,涉及到中間件軟件及技術(shù)專家成本問題,因此,在一些企業(yè)一期項(xiàng)目中通常不采用中間件來做技術(shù)實(shí)現(xiàn),而是后期自已的IT隊(duì)伍改進(jìn)時(shí)用中間件來實(shí)現(xiàn)。 回復(fù) 更多評(píng)論
只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。 | ||
![]() |
||
網(wǎng)站導(dǎo)航:
博客園
IT新聞
Chat2DB
C++博客
博問
管理
|
||
相關(guān)文章:
|
||