1两套状态难对应
本地五段办理状态与省平台推送、签收、退回、办理四类动作不能一一对应。
政务
网络问政对接省民意一体化平台
内网前置机唯一出口，推送、签收、退回、办结回执双向闭环。
已上线政务小型项目PC 运维台
- 客户
- 某市网络问政平台按约定不公开
- 行业
- 政务
- 终端
- PC 运维台
- 规模
- 小型项目 · 2025
01项目背景
某市网络问政平台已运行多年，群众来信、转办、答复与办结都沉淀在 Oracle 业务库中。省级民意反映一体化平台推广后，地方信件需要按省级接口规范与上级平台双向互通。项目要求不改动原信箱核心业务，另建一条可审计的对接通道。
- 客户类型
- 某市网络问政平台
- 业务量级
- 日均约 100–200 条信件
- 用户角色
- 办理人员、对接运维
- 部署方式
- 内网前置机，VPN + 堡垒机运维
02业务痛点
2数据源分散
信件、签收退回、正式答复分在三张表，共用一个增量时间戳会互相覆盖。
3核心不能改动
信箱流程运行稳定，嵌入式改造会影响现网办理，也难以单独验收。
4失败不可见
脚本推送失败只散落在日志里，办理岗不知道哪封信没进省库。
要与省级平台双向闭环，又不能碰正在运行的信箱核心。
03解决方案
在内网独立部署前置对接服务，作为与省级平台交互的唯一出口，原信箱系统不直连省接口。前置服务负责增量抽取、字段映射、鉴权调用与下行回写，并配套 PC 运维台让每封信的同步状态可查。
前置机唯一出口
对接服务独立部署在内网前置机，与信箱进程隔离，可单独启停和迭代。
四类动作上行推送
本地新信件、签收、退回、办结答复按省级规范转换后逐条上报。
办结回执下行回写
接收省平台办结回执，按业务标识匹配信件，回写状态、回复与流转记录。
分动作增量水位
按「表 + 操作类型」分别记录同步水位，签收与退回互不覆盖，中断后可续跑。
幂等与自动重试
同一业务标识加同一动作不重复上报；网络失败自动进入重试队列，超限转人工。
运维台可查可重推
查看水位、同步明细与请求日志，可按查询编号强制重推且不打乱增量进度。
04核心流程
信件上下行闭环
- 1
增量抽取
按动作类型从 Oracle 读取增量
- 2
字段映射
转为省级规范报文，缺省项走配置
- 3
鉴权推送
签名换取令牌后调用省级接口
- 4
记录明细
保存回执结果，失败进入重试队列
- 5
接收回执
省级平台下行推送办结结果
- 6
本地回写
更新信件状态，补写回复与流转
同一封信从推送到办结全程使用同一业务标识，上行与下行可逐条对账。
05项目价值
合规接入不停摆
满足省级平台统一接入与内网数据归集要求，原信箱流程无需重构。
状态可对账
同一业务标识贯穿推送到办结，任一封信的上下行记录都能查到。
运维可问责
同步明细、请求日志与重试队列替代翻服务器日志，日志留存不少于 180 天。
对接模式可复用
「旁路前置 + 断点明细」的做法，可复制到其他省级数据交换场景。
06界面展示
界面图为原型或用示例数据重做的界面，不含真实客户数据、金额与账号。
07技术栈
- 后端
- Spring BootMyBatis-FlexCool-Admin
- 运维前端
- Vue 3Element Plus
- 数据与集成
- OracleMySQLApache HttpClient签名令牌鉴权
- 部署
- 内网前置机VPN堡垒机
