DB51 T 2941-2022 “天府通办”政务服务平台技术规范.pdf

《DB51 T 2941-2022 “天府通办”政务服务平台技术规范.pdf》由会员分享，可在线阅读，更多相关《DB51 T 2941-2022 “天府通办”政务服务平台技术规范.pdf（8页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 35.080 CCS L 67 DB51四川省地方标准 DB51/T 29412022 “天府通办”政务服务平台技术规范 2022-10-24 发布2022-12-01 实施四川省市场监督管理局 发 布 DB51/T 29412022 I 目 次 前 言.II 1 范围.1 2 规范性引用文件.1 3 术语和定义.1 4 缩略语.1 5 平台架构和功能要求.1 6 政务服务应用接入流程.2 7 政务服务应用技术要求.4 DB51/T 29412022 II 前 言 本文件按照GB/T 1.1-2020标准化工作导则 第1部分：标准化文件的结构和起草规则的规定起草。请注意本文件的某些内容

2、可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由四川省大数据中心提出、归口并解释。本文件起草单位：四川省大数据中心政务服务技术处，中国电信股份有限公司四川分公司，大汉软件股份有限公司，成都工业学院。本文件主要起草人：赵启斌，张军，刘雯，乐益矣，徐晶，沈益民，唐为之，解岩，罗定兰，苟斌，任墨海，姚刚，雷山锋，张文阳，文冠人，陈璟，李波，赖永波，余兵，陈欣，王庆凯，陈峥。本文件首次发布。DB51/T 29412022 1“天府通办”政务服务平台技术规范 1 范围 本文件规定了四川省“天府通办”政务服务平台的架构和功能要求、政务服务应用接入流程和政务服务应用技术要求等。本文件适用于四川省

3、“天府通办”政务服务平台的建设和运行。2 规范性引用文件 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 39044 政务服务平台接入规范 3 术语和定义 下列术语和定义适用于本文件。3.1 “天府通办”政务服务平台 the government service platform“Tianfu Tongban”四川省政务服务全域可办、一网通办、一次办成的支撑平台，包括四川政务服务网、全省一体化政务服务平台及支撑体系、移动客户端及各类小程序等，简称“天

4、府通办”。3.2 政务服务应用 the government service application 由地方或部门为自然人、法人和其他组织提供的各类网上政务服务应用系统。4 缩略语 以下缩略语适用于本文件。CSS：层叠样式表（Cascading Style Sheets）HTTP：超文本传输协议（Hyper Text Transfer Protocol）JS：Java脚本（Javascript）PV：页面浏览量（Page View）UV：独立访客数（Unique Visitor）5 平台架构和功能要求“天府通办”技术架构应遵循GB/T 39044技术框架，并应具备以下功能：DB51/T 294

5、12022 2 移动多端管理功能：应对“天府通办”移动端的站点管理、页面样式、栏目结构和发布信息等进行管理和变更控制。应用汇聚功能：应提供开发组件，支持各类应用的应用测试、上下架和运维管理的标准化，实现对应用的整个生命周期的流程化管理，应支持敏感数据交互的安全、统一服务。接口管理功能：应提供标准的接口入驻方式、统一域名、统一接口地址和统一发布，实现对所有政务服务应用的原始业务接口运行状况的监管和异常报警。消息中心功能：应提供消息通知，方便开发人员和管理人员及时进行相关处理。用户中心功能：应提供统一的身份认证体系和用户信息交互标准，供政务服务应用管理单位获取用户信息。事项管理功能：应对接全省在线

6、办事、在线预约等事项服务，提供办事表单自动生成、前端事项动态管理等功能。门户管理功能：应能支撑全省政务服务门户内容发布的统一管理与调度。数据统计功能：应提供接入服务的PV、UV、服务点击量、业务办理量等关键数据统计功能。运维分析功能：应提供统一的作业管理、巡检中心、软件管理和数据库管理等数据运营监控功能，以提高平台整体稳定性和运维工作效率。智能检索功能：应提供基于平台资源的数据采集、智能标签、智能检索、智能导航、关联推荐、智能提示等智能服务，为用户提供一站式搜索服务。6 政务服务应用接入流程 6.1 流程概述 政务服务应用接入“天府通办”的流程应分为接入准备、接口开发、应用部署三个步骤，如图1

7、所示。图1 政务服务应用接入流程图 6.2 接入准备 6.2.1 接入申请 政务服务应用管理单位在向“天府通办”主管单位提交政务服务应用接入申请前，应确保业务服务场景的合理性。应用部署应用开发应用自测应用提交应用审核应用上下架接口开发接口封装接口注册接口调用接入准备接入申请应用注册DB51/T 29412022 3 6.2.2 应用注册 政务服务应用管理单位应使用“天府通办”接口管理功能进行应用注册，并创建应用唯一标识。6.3 接口开发 6.3.1 接口封装 政务服务应用管理单位应对政务服务应用接口进行封装，封装要求如下：应符合基于HTTP的RestFul设计风格，请求方式支持get或post

8、。接口调用参数可以采用以下四种：a）Json格式：参数方式为键值对类型，key为参数名，value为参数值。value类型支持String、Integer；b）Form-Data格式：参数方式为键值对类型，key为参数名，value为参数值。value类型支持String、Integer，支持表单提交；c）x-form-urlencoded格式：参数方式为键值对类型，key为参数名，value为参数值。value类型支持String、Integer；d）Raw格式：直接填写参数值，不支持File类型参数。接口应进行安全性处理，涉及敏感信息应进行加密或脱敏处理。6.3.2 接口注册 政务服务应用

9、管理单位需要将开发应用所需接口（涉及用户信息接口除外）注册至“天府通办”接口管理功能中。6.3.3 接口调用 成功注册的接口 应经过接口管理平台进行域名转换，生成统一域名的接口网关地址：https:/:8085/api/jmas-api-gateway-server/gateway。6.4 应用部署 6.4.1 应用开发 PC端应用和移动端应用均应采用HTML5语言开发，原则上开发过程中除用户信息外的接口，必须来源于“天府通办”接口管理功能。应用中所有涉及用户基本信息、证照信息和办事信息等系统已有数据，应自动关联数据，避免让用户二次输入。6.4.2 应用自测 应用开发工作完成后，政务服务应用管

10、理单位需进行应用功能测试。其中，PC端应用应使用带有调试模式的浏览器进行应用功能测试；移动端应用应使用“预览助手”进行应用功能测试。6.4.3 应用提交 应用代码需封装成压缩包。政务服务应用管理单位应在“天府通办”中完善应用基本信息、子服务名称和地址、填写审核规范表单，并提交应用压缩包。6.4.4 应用审核“天府通办”主管单位应用审核员应使用调试工具进行应用测试，审核通过应用可上架提供服务。审核原则包括：DB51/T 29412022 4 服务风格统一。文字大小、图片尺寸、按钮规格、表单样式、加载效果和底部落款等应统一。服务功能完善。应达到流程高效、控件正确、数据无误，不应出现二次登录。服务体

11、验流畅。不应出现空白页、错链、死链等情况。服务性能稳定。应具备响应速度快和高并发能力，并应准备故障解决预案。服务安全可靠。应经过安全加密、数据脱敏等处理，具备数据存储安全和备份能力。6.4.5 应用上下架“天府通办”主管单位对已上线运行的政务服务应用进行统一监控，对政务服务应用不稳定、出现安全风险、运行性能差的应用，应及时通知应用管理单位整改，对于情况严重的应用应暂停或下架处理。7 政务服务应用技术要求 7.1 信息安全要求 应符合国家、四川省相关信息安全法律法规要求。应采用“天府通办”的用户认证体系，通过调用“天府通办”相关功能，支持个人/法人用户的登录、注册、刷脸认证等。页面加载的所有资源

12、应支持加密访问。7.2 用户信息获取要求 各政务服务应用管理单位如需获取用户信息，应通过采用Web Service请求通道与“天府通办”进行交互，流程图如图2所示。图2 用户信息获取流程 7.3 接口鉴权要求 各单位提供的应用可以使用以下两种鉴权模式：安全鉴权，即请求签名机制，双方以安全方式存储通讯密钥。白名单鉴权，即接口仅向平台的白名单开放。7.4 数据脱敏要求 政务服务应用管理单位应根据国家相关法律、规章和标准，对数据进行脱敏处理。脱敏范围应不少于50%，常见用户隐私信息的脱敏要求如下：DB51/T 29412022 5 中文姓名脱敏：保留第1位，后面应以*替换；公民身份号码脱敏：保留前2

13、位和最后4位，其余应以*替换；固定电话号码脱敏：保留后4位，其余应以*替换；手机号码脱敏：保留第1位和最后2位，其余应以*替换；地址脱敏：保留前6位，其余应以*替换；电子邮箱脱敏：保留后面的部分，其余应以*替换；银行卡号脱敏：保留前6位和最后4位，其余应以*替换；开户银行联号脱敏：保留前2位，其余应以*替换；日期脱敏：可根据不同业务需求场景自行判断是否脱敏。如需脱敏，则保留月份、日期，年度应以*替换。7.5 数据缓存要求 应支持接口缓存。缓存数据应进行脱敏处理。7.6 兼容性要求 移动端应用应兼容iOS、安卓和鸿蒙系统，可适配大部分主流屏幕的尺寸。PC端应用应兼容Windows和Linux系统

14、。7.7 图形验证码使用要求 接入服务应用涉及到表单提交时可加入验证码。要求用户登录的服务应用必须在提交表单时加入图形验证码。若验证码影响用户体验，应在第三次提交表单后再显示验证码。验证码设计应采用增加背景干扰元素等方式，避免被轻易地破解。验证码在一次使用后应立即失效，新的请求需要重新生成验证码，防止验证码多次有效。7.8 表单输入校验要求 政务服务应用应在服务端代码对输入数据进行校验，而客户端校验只能作为辅助手段。一旦发现数据不合法，应该告知用户输入非法并且提示用户纠正输入。7.9 底部统一标识要求 政务服务应用的所有页面底部都需注明“本服务由某某单位提供”。7.10 外部资源调用要求 禁止应用前端直接调用外部服务资源，包括但不限于政务服务应用管理单位开放的外网应用系统数据接口。对于应用服务页面内容引用的外部文件（JS文件、CSS文件、图片等），应尽量随应用服务部署在政务服务网公有云平台上，不使用外链资源。_