基于WebService的數(shù)字城管對(duì)接機(jī)制完善

朱 佳，李慶坤

(1.江蘇省蘇州市城市管理監(jiān)督指揮中心，江蘇 蘇州 215000；2.北京數(shù)字政通科技股份有限公司，北京 100000)

0 引言

在數(shù)字化城市管理建設(shè)的過程中，會(huì)根據(jù)城市的行政級(jí)別、規(guī)模、職能部門設(shè)置等具體情況，進(jìn)行因地制宜的數(shù)字城市管理模式建設(shè)。在十多年不斷的改革和實(shí)踐中，數(shù)字化城市管理探索出五類監(jiān)督指揮模式，分別是一級(jí)監(jiān)督一級(jí)指揮、一級(jí)監(jiān)督兩級(jí)指揮、兩級(jí)監(jiān)督一級(jí)指揮、兩級(jí)監(jiān)督兩級(jí)指揮以及綜合監(jiān)督管理模式。各個(gè)地區(qū)可以根據(jù)自己城市的實(shí)際規(guī)模和工作需要，選擇其中適合自己的一類進(jìn)行擴(kuò)展完善。

蘇州市數(shù)字城管建設(shè)時(shí)考慮到蘇州市各區(qū)城市管理的實(shí)際運(yùn)行情況，采用了兩級(jí)監(jiān)督兩級(jí)指揮的監(jiān)督管理模式，如圖1所示。市區(qū)兩級(jí)各有自行獨(dú)立的數(shù)字城管業(yè)務(wù)系統(tǒng)，同時(shí)擁有自己的信息采集來(lái)源渠道，既可在各自平臺(tái)進(jìn)行獨(dú)立監(jiān)督指揮，又能夠根據(jù)實(shí)際需要將問題上報(bào)市級(jí)平臺(tái)或接收市級(jí)平臺(tái)下派的問題，保證了城市管理問題處置的靈活性，提升了問題屬地處置效率和處置效果。

為了能將各下轄區(qū)縣級(jí)子系統(tǒng)互連互通，并在之間較好地傳遞數(shù)據(jù)、交換信息，系統(tǒng)集成性能的安全性和穩(wěn)定性至關(guān)重要。通過基于WebService技術(shù)的擴(kuò)展標(biāo)記語(yǔ)言(eXtensible Markup Language,XML)進(jìn)行多系統(tǒng)間接口的信息交互能夠讓信息更加清晰有序、可讀性強(qiáng)、靈活應(yīng)對(duì)接口協(xié)議的變更[1]。

圖1 蘇州市數(shù)字城管運(yùn)行模式現(xiàn)狀

但是由于兩級(jí)監(jiān)督兩級(jí)指揮模式涉及市區(qū)兩級(jí)獨(dú)立平臺(tái)的數(shù)據(jù)交互對(duì)接(如圖2所示)，在實(shí)際運(yùn)行中不可避免地會(huì)因?yàn)榫W(wǎng)絡(luò)問題或者數(shù)據(jù)內(nèi)容寫入錯(cuò)誤導(dǎo)致工單無(wú)法正常傳輸，滯留在接口中影響城市管理問題的及時(shí)接收處辦和反饋[2-3]。

針對(duì)這些問題，蘇州市數(shù)字城管在不斷實(shí)踐探索的基礎(chǔ)上，從后端代碼優(yōu)化到前端機(jī)制建立等多角度總結(jié)出多個(gè)查漏補(bǔ)缺的方法，這些方法互相補(bǔ)充互相完善，為蘇州市兩級(jí)數(shù)字城管的無(wú)故障運(yùn)行打下了堅(jiān)實(shí)的技術(shù)基礎(chǔ)。

1 函數(shù)過濾特殊字符

蘇州市級(jí)數(shù)字城管平臺(tái)與各個(gè)區(qū)級(jí)平臺(tái)之間采用簡(jiǎn)單對(duì)象訪問協(xié)議(Simple Object Access Protocol，SOAP)調(diào)用的方式傳遞工單基本數(shù)據(jù)，并根據(jù)實(shí)際運(yùn)行需要開發(fā)共計(jì)16個(gè)對(duì)接接口，涉及案件上報(bào)、任務(wù)分派、拒簽、延期、結(jié)案等多個(gè)上下行業(yè)務(wù)交互場(chǎng)景，承載傳遞的數(shù)據(jù)內(nèi)容以XML方式進(jìn)行通信。XML是一種可擴(kuò)展標(biāo)記語(yǔ)言，用戶可自定義標(biāo)簽進(jìn)行數(shù)據(jù)傳輸[4]。

但由于標(biāo)簽的數(shù)據(jù)類型不同，且用戶行為不一致，會(huì)導(dǎo)致很多因?yàn)閭€(gè)人習(xí)慣或者手誤寫下的字符無(wú)法被正確解析入庫(kù)，從而導(dǎo)致卡在接口中無(wú)法及時(shí)在目的平臺(tái)生成工單信息。針對(duì)這類問題可以通過XML的CDATA函數(shù)進(jìn)行轉(zhuǎn)義過濾，避免標(biāo)簽中文本非法字符導(dǎo)致的解析錯(cuò)誤。

CDATA函數(shù)由""結(jié)束，它會(huì)將方括號(hào)內(nèi)的所有內(nèi)容當(dāng)作字符串處理，避免文本中出現(xiàn)XML語(yǔ)言的保留字符或者實(shí)體對(duì)解析造成影響。

比如未加CDATA轉(zhuǎn)義符的XML語(yǔ)言執(zhí)行的市區(qū)對(duì)接下行任務(wù)分派語(yǔ)句為：

結(jié)果接收方在執(zhí)行這段代碼后出現(xiàn)報(bào)錯(cuò)：

DEBUG -【插入數(shù)據(jù)出錯(cuò)！】java.sql.SQLException:ORA-00917:缺失逗號(hào)。

之所以會(huì)報(bào)ORA-00917缺失逗號(hào)的錯(cuò)誤，是因?yàn)槭芾韱T輸入有誤，案發(fā)時(shí)間的冒號(hào)變成了單引號(hào)，XML程序在標(biāo)簽中檢測(cè)到符號(hào)

圖2 信息從市級(jí)平臺(tái)到區(qū)級(jí)平臺(tái)

“ ‘ ”，未將該符號(hào)視作標(biāo)簽中的普通字符，而是當(dāng)作正常的XML代碼解析，然而XML代碼要求該符號(hào)需要成對(duì)出現(xiàn)，但是程序只找到了一個(gè)，所以會(huì)報(bào)缺失逗號(hào)的警告。想要去掉該警告，只需要讓XML停止識(shí)別此類保留字符，僅視作普通字符串進(jìn)行傳輸。在XML語(yǔ)言定義中，“<”、“>”、“&”、“‘”、““”這五個(gè)字符都是XML語(yǔ)言的保留字符，錯(cuò)誤地加在XML標(biāo)簽中將會(huì)導(dǎo)致解析程序無(wú)法正確讀取標(biāo)簽而解析報(bào)錯(cuò)，然而在人為輸入描述的過程中不可避免地會(huì)有人使用這些符號(hào)進(jìn)行特定的表述或者因手誤輸入錯(cuò)誤，所以為了避免解析失敗就需要使用進(jìn)行特殊字符的轉(zhuǎn)義。

因此上述報(bào)錯(cuò)XML語(yǔ)句在文字描述字段增加函數(shù)過濾后變?yōu)椋?/p>

這時(shí)再進(jìn)行XML解析將不再報(bào)錯(cuò)，工單數(shù)據(jù)可正常入庫(kù)并在前端業(yè)務(wù)系統(tǒng)進(jìn)行實(shí)時(shí)展示。

因此為避免工單流轉(zhuǎn)因人為輸入信息問題導(dǎo)致的特殊字符無(wú)法解析，在市區(qū)對(duì)接中嚴(yán)格明確所有人為輸入意見類字符串類型字段均需在傳輸中添加函數(shù)進(jìn)行轉(zhuǎn)義過濾，以避免這類隱患的再次發(fā)生。

2 優(yōu)化自動(dòng)重發(fā)機(jī)制

因工單本身的文字描述不規(guī)范導(dǎo)致的接口解析問題，在一定程度上可以通過上述轉(zhuǎn)義字符方式避免。但是接口傳輸不可避免地會(huì)受到網(wǎng)絡(luò)環(huán)境等客觀因素影響，而網(wǎng)絡(luò)環(huán)境波動(dòng)導(dǎo)致的影響與需發(fā)送的數(shù)據(jù)內(nèi)容無(wú)關(guān)，無(wú)需人為介入修改任何信息，僅需要在網(wǎng)絡(luò)情況恢復(fù)時(shí)再次重發(fā)即可。此時(shí)就需要后臺(tái)程序定時(shí)掃描失敗任務(wù)并自行調(diào)用接口程序重新發(fā)送。

據(jù)了解，數(shù)字城管各市區(qū)對(duì)接項(xiàng)目都建立了失敗任務(wù)自動(dòng)重發(fā)機(jī)制，但是其重發(fā)機(jī)制是失敗后連續(xù)重新執(zhí)行3～5次，重發(fā)的間隔有時(shí)還不到1 s，但是很多網(wǎng)絡(luò)波動(dòng)導(dǎo)致的失敗在幾秒內(nèi)可能無(wú)法恢復(fù)，因此短時(shí)間內(nèi)多次重發(fā)在大多數(shù)情況下沒有良好效果。

針對(duì)這個(gè)問題并結(jié)合實(shí)際情況，蘇州市級(jí)數(shù)字城管優(yōu)化了接口數(shù)據(jù)重發(fā)機(jī)制，從不間斷短時(shí)間多次調(diào)用改為首次失敗后每隔10 min重新發(fā)送一次，連續(xù)發(fā)送3次。仍然失敗的拉長(zhǎng)重發(fā)間隔，半小時(shí)重發(fā)一次，連續(xù)發(fā)送3次。通過優(yōu)化這個(gè)機(jī)制盡量避開一些偶然因素導(dǎo)致的接口掉線情況。

然而一直不停地持續(xù)重發(fā)也沒有意義，在實(shí)際運(yùn)行中必然存在某些地區(qū)因?yàn)榫W(wǎng)絡(luò)故障或者設(shè)備檢修等原因停電斷網(wǎng)數(shù)小時(shí)的情況，所以設(shè)定最大重發(fā)次數(shù)上限為6次，如果一張工單兩個(gè)小時(shí)都無(wú)法發(fā)送成功，就會(huì)停止重發(fā)并在業(yè)務(wù)前端相關(guān)人員工作界面進(jìn)行顯示(如圖3所示)。

圖3 需重發(fā)內(nèi)容的前端提示截圖

蘇州市級(jí)數(shù)字城管在數(shù)據(jù)庫(kù)接口表里通過Taskstateid來(lái)標(biāo)識(shí)任務(wù)是否成功，失敗的任務(wù)會(huì)將該值置為-1。同時(shí)還有一個(gè)Retrytimes字段用來(lái)標(biāo)識(shí)任務(wù)重發(fā)的次數(shù)。當(dāng)定時(shí)輪詢?nèi)蝿?wù)掃描到Taskstateid=-1的任務(wù)，接口就會(huì)自動(dòng)執(zhí)行重發(fā)，每發(fā)送一次Retrytimes字段值+1(表1)，網(wǎng)絡(luò)正常的情況下大部分任務(wù)均會(huì)在3次之內(nèi)發(fā)送成功，而那些Retrytimes>3且Taskstateid=-1的任務(wù)則會(huì)顯示在管理員賬號(hào)的業(yè)務(wù)系統(tǒng)前臺(tái)任務(wù)欄。

表1 數(shù)據(jù)庫(kù)重發(fā)字段信息

在網(wǎng)絡(luò)服務(wù)中斷或者停電等導(dǎo)致接口超時(shí)的狀況恢復(fù)后，相應(yīng)人員可以在任務(wù)欄選中工單并點(diǎn)擊重發(fā)按鈕，系統(tǒng)會(huì)在數(shù)據(jù)庫(kù)中將對(duì)應(yīng)任務(wù)的Retrytimes重置為0，上述輪詢程序掃描到該任務(wù)以后會(huì)繼續(xù)向目的區(qū)平臺(tái)發(fā)送請(qǐng)求，因網(wǎng)絡(luò)問題導(dǎo)致的接口滯留基本可以通過該手段解決，既避免聯(lián)系信息技術(shù)人員后臺(tái)處理耗時(shí)費(fèi)力延誤工單處置，又進(jìn)一步增強(qiáng)了用戶的使用便捷性和主動(dòng)性。

3 建立短信預(yù)警機(jī)制

近年來(lái)，手機(jī)短信息服務(wù)(SMS)在我國(guó)得到廣泛應(yīng)用,在電子政務(wù)建設(shè)中,短信息服務(wù)可以用于業(yè)務(wù)流轉(zhuǎn)提醒、事項(xiàng)告知、受理答復(fù)通知等情景[5-6]。因此重發(fā)機(jī)制可以配合短信預(yù)警機(jī)制共同使用，建立完善的短信預(yù)警機(jī)制并設(shè)定對(duì)應(yīng)預(yù)警場(chǎng)景。

比如，當(dāng)接口任務(wù)返回報(bào)錯(cuò)語(yǔ)句中包含“ConnectException、Timeout”等常見接口返回報(bào)錯(cuò)關(guān)鍵字的時(shí)候，工單進(jìn)入重發(fā)欄并根據(jù)定時(shí)任務(wù)設(shè)計(jì)的間隔開始輪巡掃描計(jì)數(shù)，超過一張則調(diào)用短信發(fā)送程序，發(fā)送短信到指定接收預(yù)警手機(jī)號(hào)。

重發(fā)欄短信預(yù)警機(jī)制核心語(yǔ)句如下：

select count(*) into iCount from tobuffertask where taskstateid=-1 and retrytimes=6 and (callinfo like ′%ConnectException%′ or callinfo like ′%Timeout%′);

if iCount > 0 then

sMsgText：= ′[重發(fā)欄預(yù)警]有′||iCount||′張工單未能成功同步，請(qǐng)及時(shí)重發(fā)?！?

其中短信發(fā)送服務(wù)直接調(diào)用短信平臺(tái)發(fā)布的WebService地址，調(diào)用方法如下：

MessageService.MessageService messageService = new Oceansoft.SMS.WebUI.MessageService.MessageService();

StringreturnGuid=messageService.SendMessage(sendMobile,reciveMobiles,content,code,userName);

對(duì)應(yīng)的發(fā)送短信XML結(jié)構(gòu)為：

重發(fā)欄預(yù)警只是短信預(yù)警方式中最基本的一種，除此以外還有任務(wù)積壓預(yù)警、長(zhǎng)時(shí)間無(wú)單預(yù)警等。比如蘇州市數(shù)字城管設(shè)置當(dāng)市區(qū)接口超過20條任務(wù)未執(zhí)行，則發(fā)送短信，因?yàn)檎Ｇ闆r下市區(qū)對(duì)接接口是不會(huì)積累20條以上的任務(wù)無(wú)法處理的，所以超過20條極有可能代表市區(qū)接口程序異常導(dǎo)致任務(wù)積壓，需要及時(shí)主動(dòng)排查解決。

任務(wù)積壓短信預(yù)警機(jī)制核心語(yǔ)句如下：

select count(*) into iCount from dltrans.tobuffertask b where b.sendercode′00′ and b.taskstateid=0;

if iCount > 20 then

sMsgText：= ′市區(qū)下行接口程序可能發(fā)生異常，′||iCount||′條任務(wù)未發(fā)送，請(qǐng)及時(shí)排查。′;

同樣，根據(jù)實(shí)際運(yùn)行模式和對(duì)接需要，建立其他各種預(yù)警場(chǎng)景，并設(shè)置對(duì)應(yīng)短信觸發(fā)情景和內(nèi)容，可直觀清楚地提醒相關(guān)運(yùn)維人員把握對(duì)接接口運(yùn)行情況。

4 建立接口異常查詢功能

轉(zhuǎn)義符和前臺(tái)重發(fā)機(jī)制分別解決了因主觀原因輸入錯(cuò)誤引起的接口異常，以及因客觀接口網(wǎng)絡(luò)問題引起的傳輸異常，但是由于對(duì)接平臺(tái)的多量化會(huì)導(dǎo)致對(duì)接問題的多樣化，因此針對(duì)不屬于上述兩個(gè)原因的對(duì)接問題就需要用其他方法進(jìn)行解決排查歸類。

蘇州市級(jí)數(shù)字城管使用的前端接口異常查詢功能會(huì)將所有Taskstateid=-1的任務(wù)羅列出來(lái)，對(duì)于前臺(tái)重發(fā)機(jī)制是一種有效補(bǔ)充，因?yàn)榍芭_(tái)重發(fā)機(jī)制僅會(huì)將某幾類可以通過重發(fā)解決的報(bào)錯(cuò)顯示在前臺(tái)供相關(guān)人員手動(dòng)重發(fā)，但接口異常查詢功能卻可以顯示所有失敗的任務(wù)，這些任務(wù)的失敗原因也是多種多樣的。查詢界面主體字段如圖4所示。

圖4 接口異常查詢界面

運(yùn)維人員可以定期到該頁(yè)面查詢一段時(shí)間內(nèi)的異常對(duì)接報(bào)錯(cuò)工單，并針對(duì)報(bào)錯(cuò)具體問題具體分析，一一排查解決并及時(shí)優(yōu)化重發(fā)及預(yù)警邏輯，以避免交辦工單長(zhǎng)時(shí)間停滯在接口中。建立前端接口異常查詢功能也僅是一種查詢和預(yù)警手段，具體問題的解決還是需要聯(lián)系信息技術(shù)人員進(jìn)一步排查，并根據(jù)排查結(jié)果督促對(duì)接雙方相對(duì)應(yīng)地做好防范措施，盡量避免同樣的報(bào)錯(cuò)再次發(fā)生影響日常的業(yè)務(wù)工作。

5 結(jié)束語(yǔ)

兩級(jí)監(jiān)督兩級(jí)指揮的城市管理模式涉及多個(gè)業(yè)務(wù)平臺(tái)之間的信息交互，所以對(duì)接機(jī)制的完善非常重要，要能夠盡量充分地考慮到各種情況下的對(duì)接情形。蘇州市數(shù)字城管在這種管理模式下，基于WebService技術(shù)，探索并建立了完善的接口對(duì)接機(jī)制，在很大程度上保證了工單流程的順暢，提升了城市管理的效率[7]。同時(shí)WebService的松耦合方式也有助于增量方式開發(fā)、部署分布式計(jì)算環(huán)境，極大地降低了電子政務(wù)的成本，為持續(xù)性開發(fā)提供了良好基礎(chǔ)[8]。