记者应急调度系统的设计与实现

杨 正

(羊城晚报报业集团,广东 广州 510660)

0 引言

传统纸质媒体正在经历着转型升级的阵痛,其“高高在上”的姿态正逐步被新媒体融合所替代,纸质媒体转型发展势在必行。当前,纸媒记者角色日益多样化,随着互联网信息的高速发展,传统的采访套路以及传统的资源优势都面临着挑战。全国各地报业兄弟单位都面临着由传统媒体向新媒体转型的诸多问题[1]。某报业集团在新媒体转型升级的过程中,提出充分利用自身媒体的资源优势,为社区做好基础服务。为了能让记者更加精准、垂直地为社区服务,报道社区的各种好新闻,必须建立一套基于记者的调度系统。

建立记者调度应急管理系统的解决方案,目前在市面上并没有非常成熟的类似系统可以直接采购,必须通过报社的技术人员进行前期的需求分析、架构设计、代码开发等。结合现有的架构以及二次开发的综合考虑,最终由某晚报信息技术部研发部牵头并参与研发了应急调度系统。

1 需求分析

平台解决方案如图1所示。调度系统的定位是敏捷、轻量化的地图界面化的管理系统,首先要确定该系统的使用人员为记者以及指挥中心调度值班员。记者是以移动端为基础,安装相应的App对地理位置坐标做采集上传。而指挥中心调度值员则是通过网页端的页面,实时查看记者采访的线路以及位置,并能确保记者的人身安全。

图1 平台解决方案

地图模块的选择有两种免费的API接口,一个是百度地图的API接口,一个是高德地图的API接口。在做了相应的测试后,最终决定了采用高德地图作为该系统的基础地图数据包,并分析了系统前期需要投入的各种硬件设备,包括系统硬件服务器以及带宽所能承载的最高峰值。由于目前该系统的初步设定仅作为报社内部记者使用,所以拟投入一套日常使用的硬件服务器以及电信10M的带宽[2]。

用户操作模块主要分为两部分,第一部分是记者使用的羊城记者App,该模块为记者提供地理位置传输、求助模块以及消息接收模块。第二部分为指挥中心值班员操作的Web前端页面,该页面主要接收记者移动端传回来的地理位置坐标、求助信息以及给记者移动端推送具体的任务内容。

2 系统设计与开发

2.1 系统整体设计

系统整体采用B/S架构(见图2),前端采用HTML 5+JQuery+Bootstrap等主流技术,服务器端以Windows服务的形式,安装Apache以及MySQL,采用Java的后端编程语言,服务器方面租用了阿里云的服务器,并采购了负载均衡服务。

图2 系统架构

2.2 系统需求体系结构简介

系统逻辑设计如图3所示,其具体功能如下:

图3 系统逻辑设计

(1)记者通过在随身携带的智能终端设备上面安装记者调度的移动端App,实现实时上传地理位置坐标。

(2)某晚报指挥中心的值班人员通过记者调度管理平台网页端,知晓所有记者实时而准确的地理位置。当总部收到热点新闻或突发事件相关消息的时候,在平台网页端上面标出突发事件的地理坐标,以其为中心,一定距离为半径划定范围,迅速推送信息指引该范围内的记者做出响应;同时也可以选择给特定的某个或某些记者发送通知。

(3)记者在移动端上收到通知后,结合自身工作情况迅速赶往热点新闻或突发事件所在地点。

(4)记者在执行外勤工作急需帮助时,可以通过移动端上的一键求助向指挥中心值班人员寻求帮助。

2.3 记者调度移动端模块

2.3.1 移动端功能设计

移动端开发包括了安卓和IOS,配合PC端的管理平台形成整体的调度协同系统。

2.3.2 接收消息推送设计

消息接收主要通过极光推送平台的服务,移动端通过网络接收Web端推送的文字消息,文字信息会先经过极光的云端服务器存储后再进行推送,并再次保存在本地的存储服务器数据库上。

2.3.3 一键求助功能设计

一键求助顾名思义就是当记者遇到一些危险情况,点击应急调度App的求助按钮即可向指挥中心发出求助状态信息,并在移动端进行录音,求助结束后录音文件会及时传送到指挥中心的Web控制端。求助功能如图4所示,该模块也是基于B/S架构,通过数据匹配到每一个记者用户,并能通过GPS以及基站精准定位,并在Web端高亮显示。移动端求助录音在上传到服务器后,本地文件依然会存储着该录音文件,方便用户后期导出处理加工。如无须使用到该文件,可以通过个人信息中的清除缓存设置直接将录音文件删除,这样就不会占用过多的手机内存资源。

图4 一键求助功能逻辑设计

2.4 调度平台值班员操作平台

2.4.1 后台多用户支持

系统支持多用户独立的账号登录,记者用户登录手机移动端只能查看到自己的相关记录,而指挥中心值班员账号登录Web端则可以看到相关记者具体的地理位置,并实时更新地理坐标,推送具体的消息以及观察求助录音。

2.4.2 自定义查询控制方案

(1)时间控制端。

管理端值班员可以在平台内操作添加各种控制的方式,在时间控制端,可以设置记者位置更新的间隔时间,可以选择默认的几个选项,例如5分钟、10分钟等,也可以通过手动填写的方式修改。

(2)范围控制端。

在范围控制框中,值班员可以通过选择一个半径,并在地图上通过拖动范围框,在地图上被范围框选中的记者便会出现在左边的记者列表中,点击记者列表就能查看具体记者的名片,包括姓名、部门、电话等信息。这能帮助值班员在有突发事件的时候,直接框选到距离突发事件最近的记者,并获取记者的信息,可以通过调度系统推送消息的方式让记者获取到该信息,或者是通过短信、电话的方式联系上记者并让其前往调查。

(3)实时位置控制端。

管理值班员通过点击实时位置按钮,激活系统服务器向每一台安装了应急调度App的移动端推送一个“心跳包”移动端通过“心跳包”。反馈是否在线以及传送最新的地理坐标,服务器将最新的坐标更新至Web端的地图界面,并记录更新时间,地图上每个用户均能记录到最后的更新时间。

(4)搜索控制端。

该搜索引擎在组件的基础上做了地图的检索,在此基础上开发了一个小型的地图搜索引擎,可以直接在搜索输入框中输入关键字或地标建筑,例如输入“广州天河城”,就可以所搜出关于天河城的具体位置以及默认1 000 m范围内是否有记者在活动。该功能及时检索突发事件的地点,发现附近正在活动的记者并生成列表,让指挥中心调度员第一时间调度能前往事发地点的记者。

(5)查看求助控制端。

记者在移动端按下求助按钮后,指挥中心值班员能在地图上迅速发现求助记者,并通过求助模块调出求助记者的即时录音。求助控制端除了能即时发现求助人员并听取录音外,还能通过日期查询过往的求助信息。求助功能通过前后端配合,能更好地保护记者的人身安全,如某些较为危险的采访任务都能通过该特殊模块的功能定位、录音,并在指挥中心帮助记者报警求助。该功能是目前市面上所有的商业产品所不具备的,随着系统的长期运行,数据会逐渐沉淀,日后这将会成为报社宝贵的信息财富,也可以作为音频栏目的一个新的标杆。

2.4.3 消息推送

指挥中心值班员通过Web端消息推送管理界面,可以选择推送消息的范围和推送的目标。通过范围选取,可以框定需要推送目标范围内的记者,在地域突发事件中较为常用,通过位置选择后精准推送到事发附近记者的移动端上,通知能行动的记者前往采访。而通过目标推送,既可以单个推送,也能群组推送,这个在推送某些消息通知时较为常用,该推送设置可以个人为单位,也能以部门为单位进行推送。

2.4.4 用户统计

用户统计的初衷是通过“心跳包”的传送反馈记录在线人数,而在线人数的统计分为两种形式。

(1)活跃用户。

应急调度平台服务器会每隔15 min发送一次“心跳包”,每一个小时为1次计量单位,而在一小时内移动端接收到“心跳包”后能成功反馈3次以上记录的均为活跃用户,即该用户移动端网络正常,有登录该管理终端并通过该终端查看信息等操作。

(2)系统用户。

在一小时内的“心跳包”传送中,反馈次数大于1次和低于3次的用户我们定义为系统用户,由于网络延迟、GPS定位偏差等硬性条件的缺失导致的统计失败或异常,在这一部分系统均将其排列在系统用户之列。

2.5 调度平台管理员操作平台

管理员操作平台由晚报社信息技术部控制,这个是后端的管理平台,具备超级管理员权限,可以批量导入用户列表,设置用户权限,并通过管理控制端增、删、改、查移动端和Web端用户。

2.5.1 用户管理

在用户管理界面可以通过用户名、部门以及真实姓名作为搜索的关键字进行筛选排查,选择特定的用户后可以进行增、删、改、查、并重置密码。所有的用户信息以及地理位置文件、求助文件、录音文件都和用户ID直接关联,一旦删除该用户,该用户的所有资料将一并被删除。

2.5.2 部门管理

在部门管理界面可以直接增、删、改、查各个部门,新增部门后在移动端会增加相应的部门信息,而删除一个部门后,相对应的用户管理中,整个部门的人员也会被相应的删除,而绑定用户的文件也会一并被抹去。在部门管理中,部门ID是该数据库的关键字,绑定用户ID作为外键,防止部门被删除时,用户数据溢出。

2.5.3 还原用户密码

当移动端用户忘记登录密码时,可以求助于系统管理员,通过后端的重置可以将移动端用户的密码进行默认还原操作,移动端用户登录后可以重新修改密码。

3 结语

整个项目从立项到开发完成历时两个月,整个研发过程也非一帆风顺,项目进度按前期制定分进度计划逐步推进。从系统最终开发的结果看,基本实现了当初立项的要求,同时本次研发能否顺利完成取决于敏捷的决策、调研、使用快速原型的方法等。互联网、自媒体等新兴媒体的崛起,总会让人感觉传统媒体的寒冬已至[1-2]。但传统媒体积累的经验能在产业架构和模式上发挥一定的积极作用,再结合新技术新方法,相信一定能厚积而薄发。