【正文】 在一個 FileID 的主鍵關(guān)聯(lián)到文檔表。 同樣的，外協(xié)系統(tǒng)在反饋的報文中返回成功刪除主鍵的信 息，如果其中一條記錄不能正常物理刪除，則外協(xié)自動回滾所有刪除的操作。 物理刪除是徹底的從數(shù)據(jù)庫中刪除一條記錄，不能恢復(fù)。 具體的字段名稱請參見提供的數(shù)據(jù)模型 刪除一條記錄 這里的刪除指的是物理刪除。實際中，這些標(biāo)簽都是字典的英文名。 Result 反饋報文中的保存成功與否信息。外協(xié)系統(tǒng)返回的主鍵值。在修改的時候，施工系統(tǒng)所給的主鍵字段內(nèi)容不能為空。 請求報文： ?xml version= encoding=utf8? XmlData UserInfo UserZhangSan/User PassWord123456/PassWord /UserInfo Description Note停工通知確認 /Note /Description Records Record KeyFieldKeyValue1/KeyField NormalField1Value1/NormalField1 NormalField2Value2/NormalField2 NormalField3Value3/NormalField3 NormalField4Value4/NormalField4 /Record Record KeyFieldKeyValue2/KeyField NormalField1Value1/NormalField1 NormalField2Value2/NormalField2 NormalField3Value3/NormalField3 NormalField4Value4/NormalField4 /Record /Records /XmlData 響應(yīng)報文： ?xml version= encoding=utf8? XmlData Description Result成功 /Result !如果失敗，則 Result里面內(nèi)容是：失?。海ㄥe誤原因） /Description Records Record KeyFieldValue1/KeyField /Record Record KeyFieldValue2/KeyField /Record /Records /XmlData 報文說明： 標(biāo)簽名 說明 XmlData 報文數(shù)據(jù)主體 Description 報文頭部信息 Records 記錄集合 Record 一行記錄 UserInfo 業(yè)務(wù)認證的用戶信息 User 業(yè)務(wù)用戶登錄名 PassWord 業(yè)務(wù)用戶驗證口令 Note 業(yè)務(wù)的簡單描述。只是需要在 Note業(yè)務(wù)的簡單描述中說明“邏輯刪除”。 施工系統(tǒng)不是對記錄做物理刪除，而僅僅是作了邏輯刪除，即僅僅在記錄的刪除標(biāo)志位上面做了“ 1”的標(biāo)志。但是，這種情況下，施工系統(tǒng)可能不再需要維護這個主鍵。如果施工系統(tǒng)報文中主鍵不為空，而外協(xié)系統(tǒng)在數(shù)據(jù)庫對應(yīng)的表中又沒有發(fā)現(xiàn)對應(yīng)的記錄，則自動轉(zhuǎn)換成新增的方式來處理這條記錄。 如果保存成功，則信息是“成功” 如果保存失敗，則信息是“失?。海ê竺媸清e 誤的詳細信息）” 修改一條記錄 施工系統(tǒng)在修改了一條記錄的時候，上傳的報文中與新增的報文類似，只是主鍵的信息不能為空。這里的主鍵值和施工系統(tǒng)發(fā)送的記錄的順序是一一對應(yīng)的。外協(xié)系統(tǒng)中根據(jù)主鍵字段內(nèi)容為空，認為這是一條新增的記錄 響應(yīng)中的 KeyField 一行記錄中的主鍵字段。比如：開工報告、施工組織方案 等 請求中的 KeyField 一行記錄中的主鍵字段。 施工單位獲得鍵 值之后，可以在本地表中更新記錄的主鍵值。 這種情況的優(yōu)點是：數(shù)據(jù)和表相關(guān)，施工單位可以靈活的控制表之間的關(guān)系；同時，數(shù)據(jù)包中的報文比較簡單，容易解析；接口上面比較清晰，與業(yè)務(wù)的耦合比較低。然后，把剛剛獲得的主表的主鍵值賦值給從表的對應(yīng)外鍵，再上傳從表數(shù)據(jù)，得到從表的主鍵值。 具體的字段名稱請參見提供的數(shù)據(jù)模型 新增一條記錄，得到記錄的鍵值 為了簡化數(shù)據(jù)模型的處理，本方案不考慮主從表的并發(fā)處理情況。實際中，這些標(biāo)簽都是字典的英文名。如果客戶端需要按照時間范圍來查詢，則必須 KeyValue空。如果用戶需要按照業(yè)務(wù)時間來查詢數(shù)據(jù)，則施工系統(tǒng)把外協(xié)系統(tǒng)的數(shù)據(jù)獲取到本地進行保存，在施工系統(tǒng)中提供按照業(yè)務(wù)時間查詢的功能。同時，外協(xié)系統(tǒng)中刪除記錄僅僅在“記錄是否刪除”字段中標(biāo)記“ 1”，并不是真正的物理刪除記錄。表示客戶端要求服務(wù)端查詢在這個時間范圍之內(nèi)所有變更過的記錄（包括新增、修改、刪除）。 QueryBeginTime QueryEndTime 查詢時時間段范圍。如果客戶端提供了主鍵的值，則服務(wù)端將忽略QueryBeginTimeQueryEndTime中的值。這個 KeyValue和下面的QueryBeginTimeQueryEndTime是互斥的。一次調(diào)用，就返回全部的結(jié)果。以此類推循環(huán)調(diào)用，直到服務(wù)端達到記錄的末尾，這時候，服務(wù)端在返回的結(jié)果中 RowID= RowID=0，終止循環(huán)調(diào)用。但是，客戶端第二次發(fā)送請求繼續(xù)查詢的時候， RowID的值要賦值為第一次返回的值，即RowID=99。服務(wù)端根據(jù)條件查詢，發(fā)現(xiàn)結(jié)果超過 100 條記錄，則在返回的結(jié)果中， RowID的值為 99，表示服務(wù)端當(dāng)前的記錄位置處在第 100條的位置上，后面還會有剩余的記錄。為了滿足數(shù)據(jù)的下載，外協(xié)系統(tǒng)提供了按照某一個表的主鍵來下載數(shù)據(jù)和按照記錄的變更時間范圍來下載數(shù)據(jù)的兩種方式查詢請求。為了簡化接口，而不是在接口上進行業(yè)務(wù)操作，所以，外協(xié)系統(tǒng)將施工系統(tǒng)發(fā)起的數(shù)據(jù)查詢請求看作是數(shù)據(jù)下載的一種方式，而不為了復(fù)雜的業(yè)務(wù)查詢請求提供復(fù)雜的條件解析。至于如何使用分頁查詢的功能，參見下面的 XML 框架說明。 ? 如果返回結(jié)果數(shù)據(jù)集非常多，在性能考慮和數(shù)據(jù)量沖突的情況下，可以使用分頁返回數(shù)據(jù)集的方式分批返回數(shù)據(jù)（每次返回最多 100 條記錄）。 ? 報文中如果存在多條記錄，則在 Records標(biāo)簽中就包含 多個的 Record標(biāo)簽。 ? 報文中的 true 和 false 數(shù)據(jù)類型，轉(zhuǎn)換成 0(表示 false)、 1（表示 true） ? 報文中的二進制數(shù)據(jù)，轉(zhuǎn)換成 Base64字符方式發(fā)送。 ? 報文中的日期信息，轉(zhuǎn)換成 YYYYMMDD HHmmss 文本格式（ 24 小時制）。報文中數(shù)值的單位使用國標(biāo)的單位，比如貨幣使用“元”，長度使用“米”等。 ? 報文中的其他數(shù)據(jù)類型，比如貨幣、 RowID,自定義對象類型等，根據(jù)需要轉(zhuǎn)換成文本、數(shù)值或二進制（最終轉(zhuǎn)換成 Base64字符）的數(shù)據(jù)類型。 約定 ? 報文中所有的字典信息（比如性別 1男， 2女），都以代碼的值（ 1 或者 2）來傳遞。生成結(jié)果報文，以 xml格式頁返回給請求者。 客戶端和服務(wù)端互相之間通訊的請求報文和結(jié)果報文遵循 XML格式。我們統(tǒng)稱這些傳遞的數(shù)據(jù)為報文。服務(wù)端應(yīng)能夠?qū)崿F(xiàn)相同數(shù)據(jù)包重新發(fā)送過來的處理機制。 ?網(wǎng)絡(luò)連接正常，但是無信息反饋：這種情況下，一般是服務(wù)端出現(xiàn)了異常，但是又沒有捕捉到的情況下發(fā)生。所以，服務(wù)端應(yīng)當(dāng)能夠捕捉異常信息，比如“非法 XML格式”等，然后反饋給客戶端。所以，客戶端系統(tǒng)應(yīng)該實現(xiàn)手工發(fā)送數(shù)據(jù)的功能。本方案定為重試發(fā)送 20次，每次時間間隔 2小時。 ?網(wǎng)絡(luò)連接失?。涸谡{(diào)用接口的時候，由于網(wǎng)絡(luò)不通，造成數(shù)據(jù)不能正常傳輸。 7 容錯處理 客戶端向 服務(wù)端發(fā)送數(shù)據(jù)，服務(wù)端解析數(shù)據(jù)，反饋信息給客戶端，這中間的環(huán)節(jié)只要某一個環(huán)節(jié)出現(xiàn)問題，都會造成接口的失敗。 ?選擇適用的大數(shù)據(jù)包傳送方式。 ?考慮為復(fù)雜的 WebMethod提供輸入校驗。 ?盡量使用原始數(shù)據(jù)類型參數(shù)。 ?基于消息的編程而不是遠程過程調(diào)用 (RPC)。 ?適當(dāng)?shù)脑O(shè)置（如果有代理）代理超時，頁面超時， WebService超時。 ?考慮使用 XML 壓縮。 ?對于并行的接口調(diào)用使用異步的調(diào)用方式。同時，在項目的開發(fā)過程要反復(fù)進行測試，可以從機器的吞吐量和響應(yīng)時間兩個基本的指標(biāo)來衡量接口的性能。接口中事務(wù)的發(fā)起總是由客戶端發(fā)起的，并負責(zé)事務(wù)的提交和回滾等控制。 接口中的服務(wù)端和客戶端的環(huán)境事務(wù)始終相同，客戶端創(chuàng)建的事務(wù)上下文并應(yīng)用對于服務(wù)端的當(dāng)前的事務(wù)，以便對于該事務(wù)上下文是 當(dāng)前的。要啟用分布式事務(wù)，可 能需要通過網(wǎng)絡(luò)啟用 MS DTC（考慮外協(xié)平臺和施工平臺都是運行在 Windows上），以便在使用應(yīng)用了最新的 Service Pack 的較新操作系統(tǒng)（例如 Windows XP 或 Windows 2020）時使用分布式事務(wù)。即使只有一個參與者無法保證這一點，整個事務(wù)也將失敗，在事務(wù)范圍內(nèi)對數(shù)據(jù)的任何更改均將回滾。要提交分布式事務(wù)，所有參與者都必須保證對數(shù)據(jù)的任何更改是永久的。 5 事務(wù)處理 事務(wù)是一組相關(guān)的任務(wù)，作為獨立于其他任務(wù)的獨立單元成功（提交）或失?。ㄖ兄梗?。利用 XML的數(shù)字簽名（ XML Digital Signature syntax [XMLSignature]）對 SOAP進行擴展，在 SOAP的頭元素中定義簽名屬性（ SOAPSEC:Signature）來實現(xiàn)。密鑰的發(fā)布方式待定。本方案采用的是最后一種的方式。涉及到加密技術(shù)就要涉及到加密的密鑰問題。所以，無論是發(fā)送數(shù)據(jù)還是返回結(jié)果，都要求采用對 XML數(shù)據(jù)加密之后來傳輸。 數(shù)據(jù)安全 數(shù)據(jù)的安全表現(xiàn)為如何保證數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中 不會被截獲并被解析其中的內(nèi)容而引起信息泄露與如何保證數(shù)據(jù)在傳輸?shù)倪^程中的數(shù)據(jù)的完整性兩個方面。業(yè)務(wù)認證其實就是應(yīng)用系統(tǒng)認證的組成部分。服務(wù)端在收到請求的時候，應(yīng)先驗證業(yè)務(wù)的授權(quán)用戶，如果該業(yè)務(wù)用戶沒有執(zhí)行當(dāng)前業(yè)務(wù)的權(quán)限，應(yīng)終止業(yè)務(wù)的執(zhí)行，并給出非法用戶的警告信息反饋回客戶端。同時，業(yè)務(wù)用戶認證中的用戶信息也是記錄接口日志 中的重要組成部分。 ? 在服務(wù)端禁用跟蹤，禁用調(diào)式編譯 業(yè)務(wù)用戶認證： 由于接口涉及電信工程中的各個不同的業(yè)務(wù)，有獲取字典、獲得項目信息、發(fā)送開工報告等，所以，建立一套業(yè)務(wù)的用戶認證機制是必須的。 ? 使用最低權(quán)限的進程帳戶運行 Web 服務(wù)（通過 中的 processModel 元素來配置）。 ? 另外，接口采用 SOAP協(xié)議，因此在接口配置上面需要屏蔽 HTTP GET 和 HTTP POST 等其他協(xié)議。考慮施工系統(tǒng)的開發(fā)平臺的多樣性，但同時接口服務(wù)運行平臺都是 Windows 的情況，本方案采用 Windows安全身份認證的方式。所以，從接口 調(diào)用上，必須考慮調(diào)用的認證安全問題。 ? 施工系統(tǒng)主動請求外協(xié)系統(tǒng)獲得數(shù)據(jù)，也會主動請求外協(xié)系統(tǒng)發(fā)送數(shù)據(jù)。以后，一旦發(fā)生數(shù)據(jù)的變動，由外協(xié)系統(tǒng)主動往施工系統(tǒng)發(fā)送信息。 ? 施工系統(tǒng)建立用戶映像對照表、字典對照表、單位對照表等數(shù)據(jù)映像，傳遞給外協(xié)的數(shù)據(jù)使用的是映像中轉(zhuǎn)換后的外協(xié)系統(tǒng)能夠識別數(shù)據(jù)；同時，接收到的數(shù)據(jù)也根據(jù)對照表轉(zhuǎn)換成各自能夠解釋的數(shù)據(jù)格式。 ? 外協(xié)系統(tǒng)要求能夠有目的，信息有過濾的把業(yè)務(wù)信息通過接口正確的發(fā)送給相應(yīng)施工系統(tǒng)接口。同時，也要求各個施工單位所提供的接口 API及其參數(shù)、格式等也必須要求統(tǒng)一。而這些單位也各有其各自工程應(yīng)用系統(tǒng)。提供由外協(xié)系統(tǒng)提交信息的 API接口。提供由施工系統(tǒng)調(diào)用獲得信息；并且提供施工系統(tǒng)提交信息的 API 接口。 ? 接口數(shù)據(jù)傳輸采用 XML數(shù)據(jù)交換格式， utf8 編碼。反之亦然。本方案中，除了特殊另外說明外，不考慮外協(xié)系統(tǒng)和施工系統(tǒng)角色換位的問題。 項目功能需求包括： ? 建立工程外部協(xié)作系統(tǒng)與 MSS 等系統(tǒng)的接口； ? 建立設(shè)計協(xié)作服務(wù)、監(jiān)理協(xié)作服務(wù)、施工協(xié)作服務(wù)模塊，為郵電設(shè)計院、電話監(jiān)理公司和電信工程公司提供工程部所需的協(xié)作服務(wù)，保證工程建設(shè)實施流程的開展； ? 在建立工程協(xié)作服務(wù)模塊的基礎(chǔ)上，建立工程外部協(xié)作系統(tǒng)與郵電設(shè)計院、電話監(jiān)理公司、電信工程公司信息系統(tǒng)的接口，實現(xiàn)工程部與三家實施單位的信息交互與業(yè)務(wù)協(xié)作； 本技術(shù)解決方案就是針對實現(xiàn)工