DB4201T536.2-2017_云端武汉_政务数据资源目录体系与数据交换技术规范 第2部分_数据共享交换.docx

ICS 35.240.01L 67备案号：0071-2017DB4201武汉市地方技术规范DB4201/T 536.22017“云端武汉”政务数据资源目录体系与数据交换技术规范第 2 部分：数据共享交换Technical specifications for Wuhan government cloud government data resource catalog system and data exchange Part 2: data share and exchange2017 - 11 - 16 发布2017 - 12 - 15 实施武汉市质量技术监督局武汉市互联网信息办公室发 布DB4201/T 536.22017目次前言III1 范围12 规范性引用文件13 术语与定义14 缩略语35 数据交换体系总体框架35.1 总体技术架构35.2 共享交换服务建设流程36 数据共享交换技术规范66.1 概述66.2 交换模式66.3 数据接口交换规则76.4 前置数据库交换规则167 数据资源交换管理规范247.1 概述247.2 角色职责247.3 管理环节257.4 制度建设26附录 A（资料性附录） 政务共享交换服务表单示例27附录 B（资料性附录） 数据接口参数示例28附录 C（资料性附录） SDK 调用示例32参考文献35IDB4201/T 536.22017前言本标准按照GB/T 1.1-2009 标准化工作导则 第1部分：标准的结构和编写给出的规则起草。本标准由武汉市互联网信息办公室提出并归口。本标准起草单位：武汉市信息中心、武汉市标准化研究院。本标准主要起草人：王留军、袁远明、崔新强、黄勇、张洁、肖迎霜、董波涛、向小雪、李文、刘肖骏。IIIDB4201/T 536.22017“云端武汉”政务数据资源目录体系与数据交换技术规范第 2 部分：数据共享交换1 范围本标准规定了“云端武汉”政务数据共享交换中的术语与定义、缩略语、数据交换体系总体框架、数据共享交换技术规范、数据资源交换管理规范。本标准规范适用于武汉市各行政机关或其他依法经授权、受委托行使行政职能的组织采集、归集和共享交换政务数据资源。2 规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。武网发20169号 武汉市政务云平台数据资源安全管理实施细则3 术语与定义下列术语和定义适用于本文件。3.1行政主管部门 administrative department行政机关或者其他依法经授权、受委托行使行政职能的组织。3.2武汉政务云数据中心 Wuhan government cloud data center指按“物理分散、逻辑集中”的原则将各行政主管部门政务数据资源进行归集，为各行政主管部门的数据共享提供支撑的技术服务平台。简称“数据中心”。3.3政务数据资源 government data resource行政主管部门通过数据中心进行传输、交换、存储的非涉密数据，是具有某个作用功能的元数据集合。3.41武政办2015146号 武汉市政务数据资源共享管理暂行办法数据项 data item各行政主管部门可共享的单个政务数据资源不可再分割的组成元素。3.5服务及服务项 service and service item服务项主要是指数据提供单位可对外公开的单个服务，为实现政务数据资源的交换而提供的一组对数据项操作的集合，数据项可来自于多个政务数据资源，而服务是整个服务项集合的总称。3.6数据需求方 data demand side指通过数据中心获取政务数据资源的各行政主管部门。3.7管理者 manager指数据中心的运维单位。3.8数据提供方 data provider指向数据中心提供数据资源的各行政主管部门。3.9共享交换服务 shared exchange service各行政主管部门之间根据自身的办事事项进行政务数据资源交换工作的统称。共享交换服务所涉及的数据资源由各行政主管部门自身的业务信息系统所提供、产生、发布并进行运行管理。3.10共享信息服务系统 shared information service system对各行政主管部门提供的共享交换服务及接口统一维护管理的平台系统。3.11接口 interface又称服务接口，本标准中专指各行政主管部门间政务数据资源共享交换的技术实现手段，具体技术形式包含：数据接口、前置数据库两种。3.12访问密钥标识/秘密访问密钥 API_key/ API_secret根据非对称加密的方法来验证某个请求者身份。2DB4201/T 536.220173.13会话 session指用户与服务器进行的一次交互，包括从发起到退出的整个过程。4 缩略语下列缩略语适用于本文件。HTTP：超文本传输协议（HyperText Transfer Protocol） API：应用程序编程接口（Application Programming Interface） URL：统一资源定位符（Uniform Resource Locator）XML：可扩展标记语言（Extensible Markup Language）5 数据交换体系总体框架5.1 总体技术架构5.1.1 组成政务数据共享交换体系技术总体架构包括交换信息库和共享交换服务系统两方面组成。5.1.2 交换信息库交换信息库是各行政主管部门为实现政务数据共享交换而建立的前置虚拟交换区，交换区内存储可提供的共享交换服务信息。5.1.3 共享交换服务系统5.1.3.1 前置数据库子系统由交换前置服务器、交换信息库、交换适配器及相关中间件等组成。前置数据库子系统与各行政主管部门业务应用系统之间通过建立虚拟共享交换区，实现数据采集交换，保证部门业务数据库和业务应用系统的独立性。5.1.3.2 数据接口子系统为各行政主管部门对外共享交换服务数据接口提供注册、挂接、配置、授权等管理。5.1.3.3 交换管理子系统实现对整个数据交换过程的配置、部署、执行和整个共享交换服务系统运行进行监控、管理。5.2 共享交换服务建设流程如图1所示，共享交换服务建设包括4个环节：a) 申请：数据需求方整理各自办事业务、应用系统、服务事项等需要，依法依规提出政务数据共享交换申请，按照“政务数据共享交换申请单”模版格式要求填写相关信息，单位盖章后报至市政务数据主管部门；3DB4201/T 536.22017b) 确认：市政务数据主管部门受理共享交换申请后，对需求合理性进行初审，通过后转交数据提供方确认，数据提供方应在 5 个工作日内反馈意见。如有分歧，由市政务数据主管部门组织需求方、提供方协商达成一致，双方依据协商结果填写政务数据共享交换确认单，加盖公章后提交市政务数据主管部门备案；c) 实施：共享交换需求确认后，对于数据中心上已发布的数据服务，由数据中心直接完成权限配置和数据推送；对于数据中心上未发布的数据服务，由市政务数据主管部门指导数据提供方开展设计开发，并由数据中心工作人员完成该项数据服务的对接工作，全部工作应在 30 个工作日内完成；d) 考核：市政务数据主管部门对各部门数据共享工作响应程度、实施进度、工作质量进行考核。对不按照要求进行数据共享交换的部门，予以通报批评；情节特别严重的部门，市政务数据主管部门将取消其通过数据中心共享其他部门数据的资格。4行政机关提供方结合需求方申请内容，给出反馈意见登记所需数据项和对应政务部门数据提供方数据中心数据需求方协商结果形成需求方、提供方、管理方的三方确认单与需求方、提供方协商创建服务申请单整理办事事项涉及的共享数据资源及相关信息开始申请与反馈意见一并提交审核审核服务同意申请单拒绝已有是否已有相关服务没有收集各政务部门反馈结果各政务部门分别进行新建服务工作服务接口实施挂接结束通知结果给服务涉及相关政务部门图1 共享交换服务建设流程图5.2.1 政务数据共享交换申请单各行政主管部门登记共享交换服务申请内容，需按照附录A中表A.1进行相关信息填写。5.2.2 政务数据共享交换确认单数据需求方、提供方就政务数据共享交换申请内容达成一致意见后，需按照附录A中表A.2进行相关信息填写。56 数据共享交换技术规范6.1 概述结合武汉市政务数据资源共享交换工作特点，将各行政主管部门利用数据中心进行数据共享交换的方式划分为：数据接口、前置数据库两种类型。本部分逐一介绍每个交换方式的技术规范要求，各行政主管部门在利用数据中心进行数据共享交换时，需要结合自身采用的数据交换方式，遵循相对应的技术规范要求，同时也为第三方相关单位的研发工作提供标准依据。6.2 交换模式6.2.1 数据接口类型数据提供方 .工 商 数据接口民 政 数据接口公 安 数据接口共享信息服务系统API认证机制接口注册发布接口接口订阅授权管理监控管理.各行政主管部门的数据接口，应遵循如图2所示的交换模式进行政务数据资源交换。各数据提供方的数据接口在共享信息服务系统中集中注册、挂接、发布，其相关访问地址、帐号、密码等信息不对外公布，只显示业务描述、请求参数、响应参数等基本信息。各数据需求方访问共享信息服务系统公示的统一访问地址，调取自身权限范围内的数据接口，共享信息服务系统将数据提供方返回的结果信息进行封装整理后，统一返回至各数据需求方。共享信息服务系统根据注册发布的数据接口信息，分别调取访问统一访问共享信息服务系统，调取授权范围内的数据接口共享信息服务系统封装返回结果，统一返回各政务部门公 安 数据接口民 政 数据接口工 商 数据接口 .数据需求方图2 数据接口交换模式示意图6公安数据库民政数据库工商数据库 .数据需求方6.2.2 前置数据库类型利用数据中心采用数据库模式进行政务数据交换的各行政主管部门，应遵循如图 3 所示的交换模式进行政务数据资源交换。各数据提供方的数据库及业务表信息在共享信息服务系统中集中注册、挂接、发布，根据定时抓取、定时推送或 FTP 上传文件导入三种形式，将各行政主管部门业务数据传至共享信息服务系统提供的前置交换区中，各数据需求方利用共享信息服务系统提供的直接访问数据库、调取接口、FTP 文件导出三种方式，访问自身权限范围内的数据业务表信息。数据提供方 .工商数据库民政数据库公安数据库共享信息服务系统数据库注册发布数据业务表业务表订阅授权管理监控管理.根据定时抓取、定时推送或FTP文件导入等方式，将提供方政务数据传至前置交换区前置交换区统一访问共享信息服务系统，查阅授权范围内的业务表共享信息服务系统封装返回结果，统一返回各政务部门图3 前置数据库交换模式示意图6.3 数据接口交换规则6.3.1 数据接口管理流程6.3.1.1 数据接口注册、发布流程各数据提供方的数据接口在共享信息服务系统中集中注册、挂接、发布，其工作流程如图4所示， 注册发布包括6个环节：7DB4201/T 536.22017a) 指定类目：共享信息服务系统结合各行政主管部门数据特性，按照“服务分类”标准为每个行政主管部门初始相关的接口类目，后期若行政主管部门需要新增服务接口类目，可直接向数据中心管理员申请；b) 登记、注册：由各数据提供方行政主管部门登记自身对外提供的接口及相关参数信息；c) 提交：由行政主管部门提交发布申请至数据中心；d) 审核：由平台中心对各行政主管部门的数据接口内容进行审核；e) 配置、测试：审核通过后，由数据中心管理员结合数据接口内容，配置并测试各数据提供方接口是否运行正常；f) 发布：数据接口配置、测试成功后，其数据接口才发布完成。其他行政主管部门可定位该数据接口，查阅相关的描述说明，并申请数据接口的访问权限。8DB4201/T 536.22017申请新类目数据中心选择对外发布数据接口所属类目登记对外发布数据接口相关参数数据提供方开始类目是否已存在不存在不通过已存在提交审核审核新类目通过不通过提交审核审核接口内容通过配置、测试接口测试成功发布结束图4 数据接口注册、发布流程图96.3.1.2 数据接口订阅、授权流程各数据需求方通过共享信息服务系统统一提出申请，由数据中心管理员进行审核，对所选数据接口进行调取授权，其工作流程如图5所示，订阅授权包括4个环节：a) 申请：各数据需求方通过共享信息服务系统统一提出对已发布数据接口的调取申请；b) 审核：由平台中心对各行政主管部门的数据接口订阅请求进行审核；c) 授权：为各数据需求方授权相应的数据接口调取权限；数据中心数据需求方选择所需数据接口开始提出订阅申请不通过提交审核审核订阅申请通过分配访问权限配置、测试接口测试成功结束图5 数据接口订阅、授权流程图10d) 配置、测试：数据中心管理员配合各数据需求方进行数据接口调取的测试工作，保证数据需求方成功获取所需的接口数据。DB4201/T 536.220176.3.2 技术要求6.3.2.1 提供方数据接口发布规范6.3.2.1.1 数据接口示例数据提供方所发布的数据接口内容，参照附录B表B.1示例进行描述。6.3.2.1.2 接口命名规范数据提供方数据接口的命名遵循以下规则：a) 应由半角格式的英文或数字组成，不允许包含全角格式、汉字或特殊字符，所有数据接口的命名为无缝连写，首词汇采用小写字母，其余每个词汇的缩写的首字母采用大写；b) 命名在本规则范围内应唯一，若不同行政主管部门的数据接口名称出现重复，可在数据接口名称前增加“虚拟名称”用于区分不同的行政主管部门。最终格式例如：“虚拟名称.真实数据接口名称（gaj.getPersonByIDCard）”；c) 虚拟名称命名应为半角格式的英文无缝连写；d) 本规则范围内不允许接口的命名与其对应版本号同时重复。6.3.2.1.3 数据接口基础属性规范数据接口的基础属性除命名外，还包括：接口版本号、接口描述、接口类型、返回报文类型、访问地址、访问帐号、访问密码、提供方名称、技术联系人、联系人电话，属性具体说明如下：定义：描述数据接口的版本信息注解：必选项；最大出现次数为1b) 接口描述定义：描述数据接口的功能作用注解：必选项；最大出现次数为1c) 接口类型定义：描述数据接口的访问方式类型注解：必选项；最大出现次数为1d) 返回报文类型定义：描述调取本数据接口返回报文的格式类型（xml或josn格式） 注解：必选项；最大出现次数为1e) 访问地址定义：描述数据接口的调取访问地址注解：必选项；最大出现次数为1f) 访问帐号定义：描述调取数据接口时所需的帐号注解：必选项；最大出现次数为1g) 访问密码定义：描述调取数据接口时所需的密码注解：必选项；最大出现次数为1h) 提供方名称定义：数据接口提供单位名称11a) 接口版本号注解：必选项；最大出现次数为1i) 技术联系人定义：负责数据接口对接调试工作技术人员姓名注解：必选项；最大出现次数为1j) 联系人电话定义：负责数据接口对接调试工作技术人员的手机号码或座机号码注解：必选项；最大出现次数为16.3.2.1.4 请求参数规范调取数据提供方数据接口所需的各请求参数描述应遵循以下规则：a) 各参数命名应由半角格式的英文、数字或“_”符号组成，不允许包含全角格式、汉字或其他特殊字符，所有数据接口的请求参数为无缝连写；b) 各参数首词汇全部采用小写字母，其余每个词汇的缩写的首字母采用大写；c) 每个请求参数的属性包括：名称、类型、数据长度、是否必须、默认值、描述，属性具体说明如下：1) 名称定义：描述请求参数的英文名称注解：必选项；最大出现次数为 12) 类型注解：必选项；最大出现次数为 13) 数据长度定义：描述请求参数最大长度限制注解：必选项；最大出现次数为 14) 是否必须定义：描述请求参数是否为必填项注解：必选项；最大出现次数为 15) 默认值定义：描述请求参数的默认数值，说明当调取数据接口时该参数不传值的情况下，默认的数值内容注解：可选项；最大出现次数为 16) 描述定义：说明请求参数的含义及用途注解：必选项；最大出现次数为 16.3.2.1.5 响应参数规范数据提供方数据接口的响应返回结果中各参数描述应遵循以下规则：a) 各参数命名应由半角格式的英文、数字或“_”符号组成，不允许包含全角格式、汉字或其他特殊字符，所有数据接口的响应参数为无缝连写；b) 各参数首词汇全部采用小写字母，其余每个词汇的缩写的首字母采用大写；c) 所有的响应数据编码皆为 utf-8 格式；d) 每个响应参数的属性包括：名称、类型、数据长度、示例值、描述，属性具体说明如下：12定义：描述请求参数对应的数据类型DB4201/T 536.220171) 名称定义：描述响应参数的英文名称注解：必选项；最大出现次数为 12) 类型定义：描述请求参数对应的数据类型注解：必选项；最大出现次数为 13) 数据长度定义：描述响应参数最大长度限制注解：必选项；最大出现次数为 14) 示例值定义：描述响应参数的示例数值，为需求方提供返回示例注解：必选项；最大出现次数为 15) 描述定义：说明响应参数的含义及用途注解：必选项；最大出现次数为 16.3.2.1.6 错误结果参数规范调取数据提供方数据接口出现错误时，其返回结果内容应遵循以下规则：b) 各参数首词汇全部采用小写字母，其余每个词汇的缩写的首字母采用大写；c) 每个错误结果参数的属性包括：名称、类型、数据长度、示例值、描述，属性具体说明如下：1) 名称定义：描述错误结果参数的英文名称注解：必选项；最大出现次数为 12) 类型定义：描述错误结果参数对应的数据类型注解：必选项；最大出现次数为 13) 数据长度定义：描述错误结果参数最大长度限制注解：必选项；最大出现次数为 14) 示例值定义：描述错误结果参数的示例数值，为需求方提供返回错误结果示例注解：必选项；最大出现次数为 15) 描述定义：说明错误结果参数的含义及用途注解：必选项；最大出现次数为 16.3.2.1.7 错误代码定义数据提供方数据接口应包括错误代码及其对应的描述说明，每个错误代码定义的属性包括：错误代码、错误消息、错误说明，属性具体说明如下：a) 错误代码13a) 各参数命名应为半角格式的英文、数字或“_”符号组成，不允许包含全角格式、汉字或其他特殊字符，所有数据接口的错误结果参数为无缝连写；定义：描述错误结果参数的代码编号注解：必选项；最大出现次数为 1b) 错误消息定义：描述错误代码对应的错误消息内容注解：可选项；最大出现次数为 1c) 错误说明定义：描述错误代码对应的中文描述注解：必选项；最大出现次数为 16.3.2.2 需求方数据接口使用规范6.3.2.2.1 访问地址规范数据需求方调取提供方数据接口时，其访问地址为共享信息服务系统提供的统一访问 URL。URL 的格式例如：公共访问 IP 地址(http:/localhost:9099/api/ws/rest)?公共请求参数+业务请求参数。URL 地址参数说明：a) URL 地址中各参数应由半角格式的英文、数字或“_”符号组成，不允许包含全角格式、汉字或其他特殊字符，所有数据接口的请求参数为无缝连写；b) URL 地址中各参数首词汇全部采用小写字母，其余每个词汇的缩写的首字母采用大写；c) URL 里的所有请求参数名和参数值的数据编码皆为 utf-8 格式；d) 参数名与参数值拼装起来的 URL 长度小于 1024 个字符时，可以用 GET 发起请求；参数类型含byte类型或拼装完成的请求 URL 过长时，应用 POST 发起请求；e) 公共请求参数详见 6.3.2.2.2 公共请求参数规范章节；f) 业务请求参数详见 6.3.2.1.4 请求参数规范章节。6.3.2.2.2 公共请求参数规范数据需求方在调取数据接口时，应按照共享信息服务系统要求，传入系统所需的公共请求参数， 公共请求参数描述遵循以下规则：a) 各参数命名应由半角格式的英文、数字或“_”符号组成，不允许包含全角格式、汉字或其他特殊字符，所有公共请求参数为无缝连写；b) 各参数首词汇全部采用小写字母，其余每个词汇的缩写的首字母采用大写；c) 每个公共请求参数的属性包括：名称、类型、是否必须、默认值、描述，属性具体说明如下：1) 名称定义：描述公共请求参数的英文名称注解：必选项；最大出现次数为 12) 类型定义：描述公共请求参数对应的数据类型注解：必选项；最大出现次数为 13) 数据长度定义：描述公共请求参数最大长度限制注解：必选项；最大出现次数为 14) 是否必须定义：描述公共请求参数是否为必填项注解：必选项；最大出现次数为 114DB4201/T 536.220175) 默认值定义：描述公共请求参数的默认数值，说明当调取数据接口时该参数不传值的情况下，默认的数值内容注解：可选项；最大出现次数为 16) 描述定义：说明公共请求参数的含义及用途注解：必选项；最大出现次数为 1d) 目前梳理的公共请求参数如表 1 所示。表1 数据接口访问公共请求参数表名称类型数据长度是否必须默认值描述methodString20是无待调取数据接口名称api_keyString50是无分配给应用的API_KeytimestampString10是无时间戳，格式为YYYY-MM-DD HH:mm:ss，时区为GMT+8，例如： 2016-01-01 12:00:00。服务端允许客户端请求最大时间误差为10分钟vString5是1.0数据接口版本signString2048是无输入参数签名结果，签名算法参照下面的介绍。6.3.2.2.3 数据接口示例共享信息服务系统向数据需求方提供所需数据接口调取方式，如附录B 表B.2 示例所示。6.3.2.3 认证机制6.3.2.3.1 API 认证简介为保证数据接口访问调取的安全性，防止恶意、超权限访问数据接口，各数据需求方行政主管部门通过共享信息服务系统调取相关数据接口之前，应进行资质认证。系统通过使用 API_Key/ API_Secret 加密的方法来验证各行政主管部门身份，API_Key (以下简称为“AK”)是系统为每个访问者分配的唯一标识；API_Secret (以下简称为“AS”)是用于加密的认证字符串，调取数据接口时，根据特定算法将“AS”与请求参数信息组合加密形成需求方的验证密匙，具体方法详见 6.3.2.3.3 签名算法章节描述。AS 信息严格保密，仅限行政主管部门管理员和数据中心管理员有权查阅。6.3.2.3.2 API 认证方式共享信息服务系统获取各数据需求方发送的HTTP 请求后，按以下步骤进行需求方身份资质认证：a) 获取数据需求方的 API_Key 信息，判断该数据需求方是否存在，若不存在，系统将拒绝该请求； 若存在，则执行后续的验证工作；b) 根据签名算法得出本次数据接口调取请求的合法签名内容，与数据需求方请求时提供的 sign值比对，若不一致，系统将拒绝该请求；若一致，则执行后续的验证工作；15DB4201/T 536.22017c) 判断请求是否超时，即共享信息服务系统服务器收到数据接口调取请求的时间需要符合以下要求：“timestamp-10min服务器接收到请求时间timestamp+10min”；其中，timestamp 代表需求方调取数据接口的请求时间。为了防止数据需求方服务器与共享信息服务系统服务器时钟不同步而导致的认证失败，引入10分钟的宽松系数。若共享信息服务系统服务器收到数据接口调取请求的时间不符合以上时间要求，则认为请求超时，系统将拒绝该请求；若符合上述要求，则表示认证成功，系统将按照数据需求方的请求内容进行操作。6.3.2.3.3 签名算法为了防止调取 API 数据接口过程中被黑客恶意篡改，数据需求方在调取任何一个 API 数据接口时都需要携带签名（公共参数中的“sign”参数对应的内容），共享信息服务系统会根据请求参数，对签名进行验证，签名不合法的请求将会被拒绝。共享信息服务系统目前只运用 MD5 签名算法，计算签名内容过程如下：a) 对所有 API 请求参数（包括公共参数和业务参数，除去 sign 参数和 byte类型的参数），根据参数名称的 ASCII 码表的顺序排序。如：foo=1, bar=2, foo_bar=3, foobar=4 排序后的顺序是 bar=2, foo=1, foo_bar=3, foobar=4；b) 将排序好的参数名和参数值拼装在一起，根据上一步的示例得到的结果为：bar2foo1foo_bar3foobar4；c) 把拼装好的字符串采用 utf-8 编码，使用签名算法对编码后的字节流进行摘要。使用 MD5 算法， 在 拼 装 的 字 符 串 前 后 加 上 API _Secret， 再 进 行 摘 要 ， 如 ： md5(AS+bar2foo1foo_bar3foobar4+AS)；d) 将进行摘要后所得到的字节流结果统一转成大写字母。6.4 前置数据库交换规则6.4.1 前置数据库管理流程6.4.1.1 数据库业务表注册、发布流程6.4.1.1.1 定时抓取模式各数据提供方的数据库业务表在共享信息服务系统中集中注册、挂接、发布，由共享信息服务系统定时抓取各数据提供方的数据库业务表数据模式的工作流程如图 6 所示，注册发布包括 4 个环节：a) 提交信息：由各数据提供方向数据中心管理员提供自身业务数据库的基础配置信息（线下填写纸质或电子文档形式完成）；b) 登记、注册：由数据中心管理员登记各数据提供方的业务数据库相关信息；c) 配置、测试：数据中心管理员为每个数据提供方分配前置交换区，创建对应数据库表结构，配置、调试前置交换区抓取各数据提供方数据库业务表数据功能；d) 发布：数据库业务表抓取数据功能配置、测试成功后，其前置交换区数据库内所有业务表自动发布完成。其他行政主管部门可定位该数据库业务表，查阅相关的描述说明，并申请业务表的访问权限。16提交自身数据库及业务表相关信息（线下）数据中心数据提供方发布配置、测试数据抓取登记、注册数据库业务表信息开始测试成功结束图6 数据库注册、发布流程图（定时抓取模式）6.4.1.1.2 定时推送模式各数据提供方的数据库业务表在共享信息服务系统中集中注册、挂接、发布，由各数据提供方定时推送自身数据库业务表数据至共享信息服务系统模式的工作流程如图7 所示，注册发布包括4 个环节：a) 提交信息：由各数据提供方向数据中心管理员提供自身业务表的基础配置信息（线下填写纸质或电子文档形式完成）；b) 分配交换区：各数据提供方配合数据中心管理员为该行政主管部门分配前置交换区，创建相应数据库表结构；c) 配置、测试：各数据提供方配合数据中心管理员配置、调试定时向前置交换区推送自身数据库业务表数据功能是否正常（线下完成）；d) 发布：数据库推送数据功能配置、测试成功后，其前置交换区数据库内所有业务表自动发布完成。其他行政主管部门可定位该数据库业务表，查阅相关的描述说明，并申请业务表的访问权限。17配置、测试数据推送分配交换区提交自身业务表相关信息（线下）数据中心数据提供方发布开始测试成功结束图7 数据库注册、发布流程图（定时推送模式）6.4.1.1.3 FTP 文件上传模式各数据提供方的数据库业务表在共享信息服务系统中集中注册、挂接、发布，由各数据提供方将自身数据库业务表数据制作成相关文件导入至共享信息服务系统模式的工作流程如图 8 所示，注册发布包括 4 个环节：a) 提交信息：由各数据提供方向数据中心管理员提供自身业务表的基础配置信息（线下填写纸质或电子文档形式完成）；b) 分配交换区：各数据提供方配合数据中心管理员为本部门分配前置交换区，创建相应数据库表结构；c) 配置、测试：各数据提供方制作相关文件，通过 FTP 上传，配合数据中心管理员调试向前置交换区导入自身数据库业务表数据功能是否正常（线下完成）；d) 发布：相关数据文件导入业务表数据功能配置、测试成功后，其前置交换区数据库内所有业务表自动发布完成。其他行政主管部门可定位该数据库业务表，查阅相关的描述说明，并申请业务表的访问权限。18配置、测试FTP上传文件导入分配交换区提交自身业务表相关信息（线下）数据中心数据提供方发布开始测试成功结束图8 数据库注册、发布流程图（FTP 文件上传模式）6.4.1.2 数据库业务表订阅、授权流程各数据需求方通过共享信息服务系统统一提出申请，由数据中心管理员审核授权对所选数据库业务表进行访问。具体工作流程如图 9 所示，订阅授权包括以下 4 个环节：a) 申请：各数据需求方通过共享信息服务系统统一提出对已发布数据库业务表的访问申请；b) 审核：由平台中心对各数据需求方的数据库业务表订阅请求进行审核；c) 授权：为各数据需求方授权相应的数据库业务表访问权限；d) 配置、测试：数据中心管理员配合各数据需求方配置、测试查询数据库业务表数据功能，保证需求方成功获取所需的业务表数据。19提出订阅申请数据中心数据需求方分配访问权限选 择 所 需 数据库业务表开始不通过提交审核审核订阅申请通过配置、测试测试成功结束图9 数据库业务表订阅、授权流程图6.4.2 技术要求6.4.2.1 建表规范创建前置交换区表结构需遵循以下规范：a) 前置交换区数据库类型目前暂定为 Oracle，所有业务表均建成“周期快照事实”，后续可根据实际需要扩展其他类型格式的数据库；b) 业务表数据的更新周期若为每天，且每周期全量数据量小于 100 万条，需要按月份分表，按周期分区。每个分区内含本周期全量数据，历史表数据保留半年（例如：8 月 1 日，清空当年 1 月份历史数据）；c) 业务表数据的更新周期若为每天，且每周期全量数据量大于 100 万条，需要按周期分表，不需要分区。每个表内含本周期全量数据，历史表数据根据存储情况制定保留方案；20DB4201/T 536.22017d) 业务表数据的更新周期若大于每天小于等于每月，且每周期全量数据量小于 100 万条，需要按月分表，按周期分区。每个分区内含该周期全量数据，历史表数据保留半年（例如：8 月 1 日， 清空当年 1 月份历史数据）；e) 业务表数据的更新周期若大于每天小于等于每月，且每周期全量数据量大于 100 万条，需要按月份分表，按周期分区。每个分区内含该周期全量数据，历史表数据根据存储情况制定保留方案；f) 业务表数据的更新周期若大于每月，需要按周期分表，不需要分区。每个表内含该周期全量数据，历史表数据根据存储情况制定保留方案；g) 每张业务表中新增时间戳字段（insert