基于WebService的数字城管对接机制完善

朱 佳，李庆坤

(1.江苏省苏州市城市管理监督指挥中心，江苏 苏州 215000；2.北京数字政通科技股份有限公司，北京 100000)

0 引言

在数字化城市管理建设的过程中，会根据城市的行政级别、规模、职能部门设置等具体情况，进行因地制宜的数字城市管理模式建设。在十多年不断的改革和实践中，数字化城市管理探索出五类监督指挥模式，分别是一级监督一级指挥、一级监督两级指挥、两级监督一级指挥、两级监督两级指挥以及综合监督管理模式。各个地区可以根据自己城市的实际规模和工作需要，选择其中适合自己的一类进行扩展完善。

苏州市数字城管建设时考虑到苏州市各区城市管理的实际运行情况，采用了两级监督两级指挥的监督管理模式，如图1所示。市区两级各有自行独立的数字城管业务系统，同时拥有自己的信息采集来源渠道，既可在各自平台进行独立监督指挥，又能够根据实际需要将问题上报市级平台或接收市级平台下派的问题，保证了城市管理问题处置的灵活性，提升了问题属地处置效率和处置效果。

为了能将各下辖区县级子系统互连互通，并在之间较好地传递数据、交换信息，系统集成性能的安全性和稳定性至关重要。通过基于WebService技术的扩展标记语言(eXtensible Markup Language,XML)进行多系统间接口的信息交互能够让信息更加清晰有序、可读性强、灵活应对接口协议的变更[1]。

图1 苏州市数字城管运行模式现状

但是由于两级监督两级指挥模式涉及市区两级独立平台的数据交互对接(如图2所示)，在实际运行中不可避免地会因为网络问题或者数据内容写入错误导致工单无法正常传输，滞留在接口中影响城市管理问题的及时接收处办和反馈[2-3]。

针对这些问题，苏州市数字城管在不断实践探索的基础上，从后端代码优化到前端机制建立等多角度总结出多个查漏补缺的方法，这些方法互相补充互相完善，为苏州市两级数字城管的无故障运行打下了坚实的技术基础。

1 函数过滤特殊字符

苏州市级数字城管平台与各个区级平台之间采用简单对象访问协议(Simple Object Access Protocol，SOAP)调用的方式传递工单基本数据，并根据实际运行需要开发共计16个对接接口，涉及案件上报、任务分派、拒签、延期、结案等多个上下行业务交互场景，承载传递的数据内容以XML方式进行通信。XML是一种可扩展标记语言，用户可自定义标签进行数据传输[4]。

但由于标签的数据类型不同，且用户行为不一致，会导致很多因为个人习惯或者手误写下的字符无法被正确解析入库，从而导致卡在接口中无法及时在目的平台生成工单信息。针对这类问题可以通过XML的CDATA函数进行转义过滤，避免标签中文本非法字符导致的解析错误。

CDATA函数由""结束，它会将方括号内的所有内容当作字符串处理，避免文本中出现XML语言的保留字符或者实体对解析造成影响。

比如未加CDATA转义符的XML语言执行的市区对接下行任务分派语句为：

结果接收方在执行这段代码后出现报错：

DEBUG -【插入数据出错！】java.sql.SQLException:ORA-00917:缺失逗号。

之所以会报ORA-00917缺失逗号的错误，是因为受理员输入有误，案发时间的冒号变成了单引号，XML程序在标签中检测到符号

图2 信息从市级平台到区级平台

“ ‘ ”，未将该符号视作标签中的普通字符，而是当作正常的XML代码解析，然而XML代码要求该符号需要成对出现，但是程序只找到了一个，所以会报缺失逗号的警告。想要去掉该警告，只需要让XML停止识别此类保留字符，仅视作普通字符串进行传输。在XML语言定义中，“<”、“>”、“&”、“‘”、““”这五个字符都是XML语言的保留字符，错误地加在XML标签中将会导致解析程序无法正确读取标签而解析报错，然而在人为输入描述的过程中不可避免地会有人使用这些符号进行特定的表述或者因手误输入错误，所以为了避免解析失败就需要使用进行特殊字符的转义。

因此上述报错XML语句在文字描述字段增加函数过滤后变为：

这时再进行XML解析将不再报错，工单数据可正常入库并在前端业务系统进行实时展示。

因此为避免工单流转因人为输入信息问题导致的特殊字符无法解析，在市区对接中严格明确所有人为输入意见类字符串类型字段均需在传输中添加函数进行转义过滤，以避免这类隐患的再次发生。

2 优化自动重发机制

因工单本身的文字描述不规范导致的接口解析问题，在一定程度上可以通过上述转义字符方式避免。但是接口传输不可避免地会受到网络环境等客观因素影响，而网络环境波动导致的影响与需发送的数据内容无关，无需人为介入修改任何信息，仅需要在网络情况恢复时再次重发即可。此时就需要后台程序定时扫描失败任务并自行调用接口程序重新发送。

据了解，数字城管各市区对接项目都建立了失败任务自动重发机制，但是其重发机制是失败后连续重新执行3～5次，重发的间隔有时还不到1 s，但是很多网络波动导致的失败在几秒内可能无法恢复，因此短时间内多次重发在大多数情况下没有良好效果。

针对这个问题并结合实际情况，苏州市级数字城管优化了接口数据重发机制，从不间断短时间多次调用改为首次失败后每隔10 min重新发送一次，连续发送3次。仍然失败的拉长重发间隔，半小时重发一次，连续发送3次。通过优化这个机制尽量避开一些偶然因素导致的接口掉线情况。

然而一直不停地持续重发也没有意义，在实际运行中必然存在某些地区因为网络故障或者设备检修等原因停电断网数小时的情况，所以设定最大重发次数上限为6次，如果一张工单两个小时都无法发送成功，就会停止重发并在业务前端相关人员工作界面进行显示(如图3所示)。

图3 需重发内容的前端提示截图

苏州市级数字城管在数据库接口表里通过Taskstateid来标识任务是否成功，失败的任务会将该值置为-1。同时还有一个Retrytimes字段用来标识任务重发的次数。当定时轮询任务扫描到Taskstateid=-1的任务，接口就会自动执行重发，每发送一次Retrytimes字段值+1(表1)，网络正常的情况下大部分任务均会在3次之内发送成功，而那些Retrytimes>3且Taskstateid=-1的任务则会显示在管理员账号的业务系统前台任务栏。

表1 数据库重发字段信息

在网络服务中断或者停电等导致接口超时的状况恢复后，相应人员可以在任务栏选中工单并点击重发按钮，系统会在数据库中将对应任务的Retrytimes重置为0，上述轮询程序扫描到该任务以后会继续向目的区平台发送请求，因网络问题导致的接口滞留基本可以通过该手段解决，既避免联系信息技术人员后台处理耗时费力延误工单处置，又进一步增强了用户的使用便捷性和主动性。

3 建立短信预警机制

近年来，手机短信息服务(SMS)在我国得到广泛应用,在电子政务建设中,短信息服务可以用于业务流转提醒、事项告知、受理答复通知等情景[5-6]。因此重发机制可以配合短信预警机制共同使用，建立完善的短信预警机制并设定对应预警场景。

比如，当接口任务返回报错语句中包含“ConnectException、Timeout”等常见接口返回报错关键字的时候，工单进入重发栏并根据定时任务设计的间隔开始轮巡扫描计数，超过一张则调用短信发送程序，发送短信到指定接收预警手机号。

重发栏短信预警机制核心语句如下：

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：= ′[重发栏预警]有′||iCount||′张工单未能成功同步，请及时重发。′;

其中短信发送服务直接调用短信平台发布的WebService地址，调用方法如下：

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

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

对应的发送短信XML结构为：

重发栏预警只是短信预警方式中最基本的一种，除此以外还有任务积压预警、长时间无单预警等。比如苏州市数字城管设置当市区接口超过20条任务未执行，则发送短信，因为正常情况下市区对接接口是不会积累20条以上的任务无法处理的，所以超过20条极有可能代表市区接口程序异常导致任务积压，需要及时主动排查解决。

任务积压短信预警机制核心语句如下：

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

if iCount > 20 then

sMsgText：= ′市区下行接口程序可能发生异常，′||iCount||′条任务未发送，请及时排查。′;

同样，根据实际运行模式和对接需要，建立其他各种预警场景，并设置对应短信触发情景和内容，可直观清楚地提醒相关运维人员把握对接接口运行情况。

4 建立接口异常查询功能

转义符和前台重发机制分别解决了因主观原因输入错误引起的接口异常，以及因客观接口网络问题引起的传输异常，但是由于对接平台的多量化会导致对接问题的多样化，因此针对不属于上述两个原因的对接问题就需要用其他方法进行解决排查归类。

苏州市级数字城管使用的前端接口异常查询功能会将所有Taskstateid=-1的任务罗列出来，对于前台重发机制是一种有效补充，因为前台重发机制仅会将某几类可以通过重发解决的报错显示在前台供相关人员手动重发，但接口异常查询功能却可以显示所有失败的任务，这些任务的失败原因也是多种多样的。查询界面主体字段如图4所示。

图4 接口异常查询界面

运维人员可以定期到该页面查询一段时间内的异常对接报错工单，并针对报错具体问题具体分析，一一排查解决并及时优化重发及预警逻辑，以避免交办工单长时间停滞在接口中。建立前端接口异常查询功能也仅是一种查询和预警手段，具体问题的解决还是需要联系信息技术人员进一步排查，并根据排查结果督促对接双方相对应地做好防范措施，尽量避免同样的报错再次发生影响日常的业务工作。

5 结束语

两级监督两级指挥的城市管理模式涉及多个业务平台之间的信息交互，所以对接机制的完善非常重要，要能够尽量充分地考虑到各种情况下的对接情形。苏州市数字城管在这种管理模式下，基于WebService技术，探索并建立了完善的接口对接机制，在很大程度上保证了工单流程的顺畅，提升了城市管理的效率[7]。同时WebService的松耦合方式也有助于增量方式开发、部署分布式计算环境，极大地降低了电子政务的成本，为持续性开发提供了良好基础[8]。