第三方数据交换平台方案v1.1.4

ralphone 贡献于2015-01-26

作者 danghui  创建于2012-03-06 09:18:00   修改者Windows 用户  修改于2012-08-10 07:26:00字数36658

文档摘要: 从核心数据处理功能来讲,三方数据交换平台设计实现为一个数据ETL(Extract Transform Load)平台,该平台首先从定义好的第三方数据源抽取(Extract)数据,然后经过转换(Transform)处理进入平台系统,最后通过一定的技术手段装载(Load)为可以直接应用的数据
关键词:

江苏省第三方数据交换平台 设计说明书 文件编号 TH-DEP-TD-01 文件状态 [ ]草稿 [ ] 正式发布 [ ]正在修改 当前版本 1.1 拟 制 党辉、蒋烨、朱曙锴、顾小明 日期 2012-08-03 审 核 党辉 日期 2012-08-06 批 准 周志敏 日期 2012-08-09 修订历史记录 A - 增加 M - 修订 D - 删除 变更版本号 日期 变更类型 (A*M*D) 修改人 摘 要 V1.0 20120320 A 党辉、蒋烨 根据原始需求文档和2012年3月若干讨论会意见形成初步技术方案 V1.1 20120726 A 朱曙锴、顾小明 根据2012年7月24日演示讨论会及后续讨论会意见对文档进行内容增加 V1.1 20120803 M 党辉 修改和校订 目录 1. 引言 7 1.1 编写目的 7 1.2 背景 7 1.3 术语与缩写解释 8 1.4 参考资料 8 2. 概要设计 8 2.1 平台设计与定位 8 2.1.1 概述 8 2.1.2 与现有系统的关系 10 2.2 硬件与网络 12 2.2.1 核心硬件和网络 12 2.2.2 外围硬件与网络 13 2.2.3 网络互联的安全 13 2.2.4 节点部署说明 14 2.2.2 软件系统 15 2.3 核心软件系统结构 16 2.3.2 第三方数据源 17 2.3.2 数据接口层 18 2.3.3 传输控制层 19 2.3.4 数据处理层 20 2.3.5 交换数据库 21 2.3.6 数据展现界面 21 2.3.7 数据应用接口 22 2.3.8 上下级系统数据共享 22 2.3.9 数据交换标准 22 2.4 核心软件系统设计原则 24 2.4.1 自动化数据交换 24 2.4.2 可定制数据交换 24 2.4.3 多重方式数据的展现与利用 25 2.4.4 数据全生命周期管理 25 2.4.5 数据字段业务标准 26 2.5 数据存储设计 26 2.6 数据流管理设计 27 3. 技术架构设计 28 3.1 概述 28 3.2 基础组件 29 3.2.1 Spring Framework 29 3.2.2 Swim Framework 30 3.2.3 Piston远程数据交换中间件 32 3.3 领域模型和逻辑设计 34 3.3.1 概述 34 3.3.2 任务调度引擎 34 3.3.3 规则处理引擎 37 3.3.4 系统核心功能设计概述 43 3.3.5 数据导入设计 43 3.3.6 数据加工设计 51 3.3.7 数据应用设计 58 3.3.8 数据上传和下发设计 64 3.3.9 任务监控管理中心设计 71 3.3.10 系统权限设计 72 3.3.11 数据权限设计 75 3.3.12 数据标准设计 76 3.3.13 现有系统集成设计 78 3.3.14 数据使用反馈设计 79 4. 系统功能设计 81 4.1 概述 81 4.2 数据交换部分 82 4.2.1 数据交换流程 83 4.2.2 交换项目设置 83 4.2.3 交换项目调度 89 4.2.4 交换项目的监控 89 4.2.5 数据交换的一些原则 91 4.3 数据加工部分 91 4.3.1 数据加工流程 92 4.3.2自动匹配 93 4.3.3 手工匹配 98 4.3.4手工撤销匹配 99 4.3.5 数据匹配综合管理 100 4.4 数据应用部分 101 4.4.1 数据字典查询 102 4.4.2 交换项目情况查询 103 4.4.3 按交换项目的简单数据查询 103 4.4.4 单户明细信息查询 104 4.4.5 数据输出接口 104 4.4.6 对于异地数据交换的说明 105 4.4.7 成果展示 105 4.4.8数据利用反馈展现 106 4.5 数据上传下发 107 4.5.1 数据上传 107 4.5.2 数据下发 108 4.5.3系统全景图查询 108 4.6 系统设置和管理部分 109 4.6.1 层级管理 109 4.6.2 岗位设置 110 4.6.3 权限管理 111 4.6.4 代码表设置 111 4.6.5 交换项目设置备份和恢复 111 1. 引言 1.1 编写目的 根据《江苏地税第三方数据交换平台系统需求思路》以及多次需求和技术讨论会,特别是3月份和7月份演示讨论会后,依据省局领导的意见,形成该三方数据交换平台的技术设计说明书。该文档把三方数据交互平台的技术和功能方面的设计,通过文字和图表明确的表述出来,以供领导审阅。同时,也依据该设计文档,进行下一步的设计和开发工作。 1.2 背景 根据省局《关于委托常州地方税务局开发“第三方数据交换平台项目”的通知》的要求,立足于全省地税系统应用和管理的实际情况,开发建设具有通用性、适应性强的数据交换平台。 该平台是支撑税源专业改革新模式的重要数据平台,为风险管理平台和日常税源监控及税收分析提供了强大的第三方信息库。该平台的开发立足于第三方信息进得来、管得住、整合得好,为风险平台的后期数据应用及其它业务需求提供可靠的信息源,为税源专业化改革的深化推进提供重要的支撑平台。 1.3 术语与缩写解释 缩写、术语 解 释 ETL Extract,transform and load. 数据处理的三个环节:抽取、转换与装载。 MVC Model,view and controller. 一种系统设计的常用模式:模型、视图、控制器。 IOC Inversion of control. 控制反转,面向对象设计的一种模式。 AOP Aspect Oriented Programming. 面向切面编程,软件设计的一种方法。 RPC Remote procedure call. 远程过程调用,一种协议和程序调用方式,使得远程程序的调用跟本地程序调用在调用者角度没有差异。 1.4 参考资料 《江苏地税第三方数据交换平台系统需求思路》 2. 概要设计 2.1 平台设计与定位 2.1.1 概述 从核心数据处理功能来讲,三方数据交换平台设计实现为一个数据ETL(Extract Transform Load)平台,该平台首先从定义好的第三方数据源抽取(Extract)数据,然后经过转换(Transform)处理进入平台系统,最后通过一定的技术手段装载(Load)为可以直接应用的数据,如下图所示。 数据ETL过程图 三方数据交换平台是一个专注于数据处理的技术平台,它将提供丰富的数据导入、处理和应用方式,充分考虑多种应用场合,实现方便的定制功能,使得操作人员在数据处理层面上有多种多样的选择方式,可以根据不同数据来源和去向定制各异的数据导入、加工与应用规则。 三方数据交换平台也是一个相对独立的系统,它与其它系统之间没有业务上的直接耦合关系,对外它只提供数据的输入接口和输出接口,仅仅是数据的采集和提供者。所有的数据业务关系,是通过平台的使用人员通过不同的数据处理规则去定制实现的。在这种机制下,业务规则不是固化在平台实现里,从而提供了极大的灵活性,增强了系统的可使用性。 下面的三方数据交换平台示意图比较直观的显示了上述内容。 三方数据交换平台示意图 通俗来讲,三方数据交换平台可以视作一个数据加工厂和数据流桥梁。原始的三方数据相当于原料,原料进工厂(数据导入)以后,经过加工过程(数据加工),成为可以发售的产品(可以应用的数据)。除了数据工厂作用以外,它还是数据流环节中的一个桥梁,通过这个桥梁,数据可以在不同的应用系统之间进行流动。 2.1.2 与现有信息系统的关系 三方数据交换平台建设的初衷不是一个孤立的系统,它是为了加工处理数据,进而为其他系统服务的。在现阶段,可以预见的跟它有数据关系的系统包括政府公共信息网、省地等级别的相关数据系统(国税、工商、供电、供水、社保、国土等等) 以及地税内部现存的信息系统,包括大集中系统、风险管理平台等。三方数据交换平台系统在这样一种关系网络中,处于中间地位,通过该平台的建设,打通数据在现有的这些系统之间的流动路径,使得原本孤立的这些信息孤岛能够连成一片,实现信息数据的共享和应用。它是各个系统之间的纽带,为建设综合治税这样的大概念平台打下了坚实的基础。 三方数据交换平台关系示意图 因为现存的系统各种各样,对外的接口也不尽然相同,所以为了尽可能多的适应当前系统,在对当前系统对外接口不做过多的改变的前提下(事实上,要对现有系统接口做修改在很多情况下没有太大的可行性),三方数据交换平台将会提供多种形式的数据输入接口和输出接口,这在后续将会详细讲述。 因为当前需要接入的系统就很多,业务规则也千差万别,未来也可能有更多的系统接入, 所以三方数据交换平台不可能一开始就设计好与其它系统之间的业务关系,否则接入一个新的系统,平台就要做相应修改,这个工作量是不可想象的。所以,三方数据交换平台设计为和其它系统之间并没有直接的业务耦合关系,它只是提供了多种多样的数据处理规则和方式,让平台系统的操作人员去动态的定制,这样间接的实现了业务规则的转换,从而为多种不同业务系统的接入,提供了可能性。站在其它系统的角度来看,三方数据交换平台仅仅提供了数据的输入和输出接口。从三方数据交换平台内部来看,它提供了多种多样的数据处理规则,通过这些规则的灵活定制,实现了数据的业务处理。 2.2 硬件与网络 2.2.1 核心硬件和网络 核心硬件与网络是指本系统在税务系统内部的硬件与网络部分。从宏观来讲,该平台是一个分布式系统,由地理位置上分离的各个数据交换平台软硬件系统节点组成。从单个数据交换平台软硬件系统节点来看,它又是一个自成体系的系统。所以,网络和硬件的设计也必须按照数据交换业务的实际需求来设计,实现互联和安全访问。 对于部署在不同地理位置的数据交换平台软硬件系统,称之为节点。从上下级关系来看,系统的部署可以分为多个级次,每一级次都是由一个到多个节点组成。例如,在省、市两级进行部署,省、市分别为部署在本地的数据交换平台软件系统准备合适的硬件平台和网络环境。另外,在网络结构上,具有上下级关系的节点之间的能实现相互访问,而同级节点之间,则不一定需要直接进行相互访问这样的功能。在这一级别上,可以采用专网、防火墙等技术实现该平台所需的分布式网络。 2.2.2 外围硬件与网络 外围硬件与网络是指和第三方数据源直接有干系的硬件和网络。因为第三方数据源的情况现在并不明朗,只有到具体接入实施的时候,才会知道具体的情况。所以,为了考虑兼容和接入不同的三方数据源,网络接口的设计也需要具有比较大的灵活性。 关于外围硬件与网络,需要在几个不同的方面加以说明。 首先,在通信的发起上,分为主动和被动方式。主动方式是指核心网络主动去访问第三方数据源,这一形式只能在第三方数据源提供了网络连接支持,并开放了访问权限的前提下,才能实现,那么这需要第三方数据源提供接口主机并保证数据安全传输的前提下,以专网或公网为传输媒介进行通信。被动方式是指在核心网络的外围,提供可以访问的接口主机,提供多种可以访问的手段,让第三方数据源主动发起数据通信。 其次,在网络的接口和互联上可能有多种形式,包括直接互联走专网的方式以及在公网上间接提供接口主机的形式。那么接口主机可能位于核心网络,也可能位于第三方数据源,这要看通信由谁发起来决定。 2.2.3 网络互联的安全 因为数据交互牵涉到大量的保密数据的交换,所以在硬件互联层面上,安全性也是非常核心的一环。在本系统设计和部署的时候,将严格按照地税和相关其它部门的安全规范和规定,确保万无一失。另外一点就是,本系统只部署在安全网络环境内,不考虑直接通过Internet和第三方数据源进行交互,系统可以提供间接的方式,例如对外的Web上传界面,Ftp等,实现数据的采集,采集的数据通过异步方式转移到核心系统内。 2.2.4 节点部署说明 如下图所示,该数据交换平台系统在宏观上由部署在不同地理位置的多个节点组成,这些节点位于不同的层级,一个层级对应有一个到多个节点。所谓节点也就是在一定的地理位置实际部署的软硬件系统。层级分为省级和地市级,所有在地域行政级别相同的节点属于同一个层级,例如南京市与常州市的市级部署节点它都属于市一级的三方数据交换平台系统。节点部署只是一个宏观的概念,在实际部署中,对于要部署几层、多少节点,这个根据省局的安排和当地实际业务情况来进行。比如说一个区(县)可以选择部署和不部署这样的数据交换平台系 基于节点的网络部署图 统。在不部署平台系统的情况下,它可以直接访问上级机构部署的节点,实现数据的交换和数据利用。当然这需要有一些前提条件:首先网络要互联;另外还需在上级机构的系统里进行用户设置和访问权限的设置。 2.2.2 软件系统 软件系统的主要包括操作系统平台、数据库管理系统、Web及应用服务器软件,以及需要接下来设计和开发完成数据导入、处理、应用的核心软件系统。这些软件系统根据需求,依据硬件和网络设置进行分布式部署。 操作系统可以为Windows的服务器版本或者Linux的服务器版本,但是本着效率、稳定性等方面的考虑,推荐以Linux相关操作系统版本为主。 数据库软件以Oracle系列数据库管理系统来进行构建。 Web服务器推荐使用Nginx高性能服务器,另外包括Tomcat等Java应用服务器以及所需要的Ftp服务器。 以上的软件只需部署安装,按照系统实际运行所需进行相应的配置即可。真正完成数据交换的核心软件需要接下来开发完成。从宏观角度来看,它主要由后台数据自动化处理组件和Web操作控制系统及数据展现应用系统组成。 后台数据自动化处理组件将会被设计成后台自动运行的模式,通过提前定义好的标准接口以及标准业务处理规则,完成数据交换、处理以及生成可应用数据接口。在编程实现上,将会充分利用Java企业编程所提供的基础技术框架结合相关的数据库开发技术以及充分考虑各种因素,实现最大程度上的数据自动化交换。 Web操作控制系统和数据展现系统包含两部分内容,一部分是对数据交换过程进行操作和控制,它主要完成数据交换的过程管理。另一部分是数据展现应用系统,主要是把获取和处理好的数据,以各种形式展现出来,提供不同方式的展现形式,支持固定和可定制的信息查询。另外还提供可编程或非编程方式的数据访问接口。 2.3 核心软件系统结构 核心软件系统结构图 如上图所示,以模块化分层的方式表述了数据交换系统的软件架构,从大的方面来讲,主要包含第三方数据源、数据接口层、传输控制层、数据处理层、交换数据库、数据应用接口和数据展现界面等分层模块。从 2.2所述可以知道,软件系统由位于不同层级的节点组成。但是从软件架构上来讲,部署在不同层级的软件系统,除了在上下级系统之间,具有不同的数据流的处理(数据的上传和下发),除此之外,各个节点的数据交换软件系统在软件架构上是一致的。 2.3.2 第三方数据源 第三方数据源是整个系统所要交换数据的原始采集地,由于各个数据源的情况差别很大,存在很大的不确定性,所以就要求系统要支持多种类别的数据源。在综合分析以后,确定系统支持以下一些方式的数据源:数据库直连、FTP方式,手工文本。 数据库直连是信任度最高的一种数据源提供方式。假定第三方机构以某种方式,对其数据库访问,提供了一定权限的访问接口。在这样一种方式下,系统以事先约定好的访问规则,去对数据源进行自动访问,实现数据的采集。 FTP方式可能包括两种类型,一种是在数据接口层提供FTP服务器,以供第三方数据源的相关操作人员或自动运行的程序将所需交换的数据按事先约定好的文本格式,以一定的频率进行进行文件上传。另外一种方式是第三方数据源在其网络接口层提供可以访问的FTP服务器,本系统根据事先的约定,来完成FTP服务器的定时访问,获取到固定格式的文本数据。 手工文本方式是指通过其它渠道,以人工方式获取到的固定格式的第三方数据,它文本方式存储。 在这一层面,需要确定通信和数据采集的一些基本协议。例如,所要采集数据的格式、频率等。 2.3.2 数据接口层 数据接口层和第三方数据源示意图 本层主要负责对外接口,提供数据库访问程序、FTP数据访问程序,FTP服务器、WEB操作界面等具体功能来实现和第三方数据源的连接,实现数据的采集。 数据库访问程序直接连接第三方数据源提供的数据库访问接口,按照接口协议,实现数据的直接读取。 FTP服务器提供给第三方机构,使其可以按照访问协议,上传本系统所需数据。 FTP数据访问程序连接第三方数据源提供的FTP服务器或者本系统FTP服务器,按照访问协议,获取数据并将其解析成可以利用的原始数据。 WEB操作界面提供数据导入功能,可以实现格式化数据的导入。 除了这些对外的功能性接口以外,本层还负责数据安全传输、数据有效性检测等。 2.3.3 传输控制层 传输控制层示意图 传输控制层是实现自动化数据采集的关键,它根据事先定义好的协议,去自动处理用户定制的数据采集任务,同时处理数据采集中产生的异常情况,并进行反馈和预警。 自动数据采集采用监听任务脚本的方式去进行处理。首先,用户通过WEB界面去进行数据采集任务的定制,定制完成以后,会在后台形成一定格式的任务脚本的描述。其次,传输控制层得监听模块如果获取到了新增或修改过的任务描述脚本,则对脚本进行解析,按照脚本描述的规则,去驱动相应的程序模块进行通信,完成数据的自动化采集。 另外,传输控制层还会反馈一些预警信息,比如定制的数据采集任务没有完成或者采集过程中发生了异常,传输控制层都会对此过程进行记录,通过WEB界面把预警信息反馈给用户。 2.3.4 数据处理层 数据处理层示意图 数据处理层实现了原始采集数据的存储以及数据的预处理等环节。 原始数据以数据的原始结构进行保存,并记录操作时间,操作人员等信息。数据的处理包括宏观数据和微观数据的处理,宏观数据直接处理存储,微观数据则要和纳税户信息进行有效的关联,使其和地税户管建立对照表,进行自动匹配以及手工匹配。 自动匹配建立在关联字段信息一致性上,根据一定规则进行匹配,通过程序遍历,来自动生成匹配数据自动装载到对照表中,包含的字段有税务管理码、纳税人名称、第三方唯一标识码、企业名称、主关联字段、次关联字段等。如果部分关联信息一致或没有一致的关联信息,则需要提供界面去进行手工匹配,手工操作后,该部分数据也自动进入对照表。 数据处理层除了需要制定完备的数据匹配规则以外,还需进行多重逻辑校验,实现一定的容错性,以最大可能来反映数据的准确性。 2.3.5 交换数据库 交换数据库是交换系统所有数据的存储地,包括系统初始化数据、系统管理数据、原始采集数据、预处理后的正式交换数据等。根据需求,数据库进行良好的设计。 2.3.6 数据展现界面 本层主要实现数据的展现,包括各种查询分析功能。主要有固定查询、自主定制组合查询、信息交换统计查询、单户明细信息查询、适用税种查询分析、交换数据质量跟踪监控情况查询、可利用数据信息查询等内容。 2.3.7 数据应用接口 本层提供编程与非编程数据接口,使得交换系统的最终数据,可以为其它系统和部门所用。根据实际的需求情况,可考虑提供各种访问途径,例如:数据库直接访问方式、FTP文本数据共享、可编程远程接口、人工导出文本等。 2.3.8 上下级系统数据共享 本系统除了第三方数据交换功能以外,在级别上有省、市、县(区)三个级别,所以数据除了从本层第三方数据源进入本层交换系统以外,还可能存在数据的跨级别访问。比如,上级部门的交换数据可提供给下级部门进行展现和应用,而下级部门的数据交换情况,也可以提供给上级部门查看,比如提供数据交换总览图这样的功能,使得上级部门可以直接获知数据交换系统各个地方的部署实施情况等。 上下级数据的共享可以考虑两种方式,一种是直接操作上级或下级的交换平台系统,另外一种是提供数据的上传或下发,根据用户的实际需要,会同时提供两种方式。 2.3.9 数据交换标准 因为本系统可能会涉及到众多的第三方数据源,可能包含海量数据的交换处理与存储,而且数据的交换和处理环节也很多,所以为了更好的对数据进行交换和处理,使得数据最终能得到有效的利用,我们就需要制定各个环节的标准、规范和协议。而标准、规范、协议也是自动化数据处理的一个前提,否则很多环节必须通过人工干预才能进行。 首先关于数据源的标准化,也就是本系统都支持哪些类型的数据源,某种特定的数据源都必须要提供哪些参数。比如,如果支持数据库直连方式,那么就需要确定IP地址、端口、数据库、表(视图,存储过程等)、字段等参数,在用户进行数据采集任务定制的时候,如果选定了这种方式,那么上述所列的参数就必须提供。 其次是数据格式的标准化。只有采集到标准格式的数据,才能被后续环节所自动化处理。在进行数据采集之前,必须要确定数据以什么样的载体存在,在载体中以什么样一种格式存在。比如以数据库直连方式,那么数据应该就是以数据库表的方式存在。如果是以文本方式,那么就必须确定是什么样的文本格式:自定义文本格式、csv、excel等。这个还可以继续延伸下去,比如自定义格式是怎样的自定义规则,数据字段间以什么样方式分隔,数据字段的名字采用什么样的存储方式等等。 最后,是数据源和数据存储的标准化。因为采集的原始数据可能是多样性的,而这样的原始数据是不能为后续的系统例如风险评估系统来应用的,所以在数据的预处理阶段必须遵循数据源和数据存储的标准化,使得处理过的正式数据可以被其它第三方系统所识别,从而成为真正可以利用的数据。系统将根据税务系统制定的数据源或数据存储标准,去建立数据源,包括表的命名、字段的命名、字段的类型、字段的含义。因为当前阶段标准化工作还在进行中,所以系统的设计上要考虑多种方式的标准化接入。现阶段可以预见到的有:标准以文档的方式提供;标准以可编程接口提供。在数据源建立或数据存储建立的时候,根据一定的关键字去查询该标准,如果有匹配的标准定义,则遵循标准执行。如果没有标准,则可以自定义构建。 另外,还需要制定详尽的数据比对规则,只有这样,才能最大程度的进行数据的自动化匹配,进行有效数据的筛选与存储。 当然,还有很多的处理环节需要标准化,这将会在后续的详细设计中一一实现。 2.4 核心软件系统设计原则 2.4.1 自动化数据交换 在数据交换平台的软件体系内,处于最核心的部件是数据交换控制组件,该组件自动运行在后台,依据既定的标准交换协议对数据交换的各个环节进行监听,一旦监听到有需要处理的任务,则在后台自动化的完成数据的处理过程,这一过程不需要人工干预。如果某一过程的处理中,存在问题,则会自动预警。例如,原本定义好每天需要有新的交换文本上传到FTP进行交换,但是自动化处理过程在自动处理过程中,没有发现当天需要交换的新文本,则会向系统发一条预警通知,该通知会以某种方式,在WEB操作界面展现出来。 2.4.2 可定制数据交换 软件系统将实现数据交换的可定制化。在Web操作控制界面上,具有一定权限的操作人员,可以根据数据交换的需要,在既定的标准交换协议框架之内,实现灵活的的可定制数据交换操作。可以定制数据源、数据采集方式、采集频率等等。 当操作人员按照规则进行了数据交换的可定制操作以后,系统会生成一定的流程描述脚本提供给数据交换控制组件来自动运行。 2.4.3 多重方式数据的展现与利用 数据交换的最终目的是为了对数据进行管理和应用。那么,经过数据的采集与预处理,得到了可以利用的数据,我们最终需要以某种方式将数据加以展现和利用。本系统中,我们将会以两种方式来进行数据的展现与利用。 对于本系统的最终用户,系统将会提供基于Web的操作界面,来进行数据的查询与展现。根据业务需求,将会提供固定条件的数据查询与展现,以及在一定的业务范畴之内的可定制的数据查询与展现。 当然除了提供Web操作界面提供给最终用户来进行数据的查询与展现,还需提供基于不同方式的数据查询与展现接口以供第三方系统或用户来对数据进行查询和应用。那么根据需求,我们可以提供可编程数据访问接口、数据库直连、FTP自动交换以及文本导出等不同方式的接口。这个要在保证数据存储、传输的安全条件下,根据具体的需求来确定最终采用哪些方式。 2.4.4 数据全生命周期管理 本系统的核心着眼点是数据的交换处理和利用,所以对于数据的管理是最核心的一环。基于这一问题,需要设计完备的数据生命周期管理,从数据抽取到系统的第一步起,到数据最终的展现和应用。每个环节,都会提供相应的管理功能和操作界面,供具有权限的操作人员去对数据进行控制和处理。 另外,对于数据每个环节的操作和管理,系统都会提供详尽日志,以供后期分析查询使用,提供数据交换成果的统计与分析功能。 2.4.5 数据字段业务标准 本系统自动化成分很高,自动建表,索引,存储过程等工作都是由系统脚本自动生成。例如在创建数据交换项的时候,数据进入系统采用的数据字段都是要满足《数据标准平台》的标准的,新字段要通过《数据标准平台》审核。 2.5 数据存储设计 在本系统中,数据存储的设计包括两方面的内容,首先是数据库的部署设计,其次是数据库表的设计。 因为本系统跨地域、跨部门、跨业务,跨上下级关系,所以要实现数据的采集处理和共享,决定了本系统是一个分布式系统。数据库的部署也必须分地区,分层次,各个地方部署各自的数据库进行交换数据的存储。省级的交换数据存储在省级的数据库服务器中,市级的交换数据存储在市级的数据库服务器中,县(区)级的交换数据存储在县(区)级的数据库服务中。 另外,因为要经过数据的ETL,才能得到可以利用的数据,所以在数据库的设计上,要考虑到包括原始数据数据表和经过数据转换和清洗后的正式数据表。 关于数据表的设计,要包括系统初始化所需的支撑表、权限控制表以及处于核心的业务数据表等不同类型的数据表。另外,因为系统中存在各地各个级别的数据,所以要设计合理的数据关联关系,设定一定的访问控制标志,以保证数据的安全共享与访问。 因为本系统涉及到海量数据的处理,所以要充分发挥分布式存储和运算技术,利用Oracle数据库管理技术为中心的各项技术手段,来实现数据的安全存储,高效处理。 2.6 数据流管理设计 从宏观方面讲,数据的流向大体有两个方向。 一个是横向的数据流动,也就是数据从第三方数据源获取,经过处理后进入本系统数据库中进行存储和利用。这是本系统所需处理的核心问题,也就是数据从第三方数据源怎样进入本系统,并成为有效可利用的数据,并且可以提供给其它系统进行扩展应用。这在前边基本上已经过阐述。 另一个方向是数据的纵向流动,也就是处于行政关系的上下级单位间数据存储之间的数据流动。主要是上级部门的交换数据,可以共享给下级部门。下级部门的数据交换部署实施情况、数据利用成果等可以共享给上级部门。这里有两种方案可以选择:一种是上级(下级)部门的交换数据存储在上级(下级)部门的数据库中,给下级(上级)部门开发访问权限,根据访问规则,下级(上级)部门可以访问具有权限的数据。另外一种是上级(下级)部门交换数据下发(上传)到下级(上级)部门。 第一种方式的好处是数据没有冗余,集中存储。但是由于要开放下级(上级)访问接口,这就涉及到这些接口怎么去设计、数据怎样控制、Web系统通过怎么样方式的去访问、怎么样去部署都提出了一些技术挑战。另外由于增加了下级(上级)访问,那么一方面数据库访问压力会增大,另外一方面远程数据访问的效率如何,也不得而知。 第二种方式的好处是数据本地存储,这对数据的访问效率以及减轻上级(下级)部门数据库的压力是有很大好处的。但是,这一方式就带来了海量数据的远程传输控制问题,怎样保证数据能够高效安全的传输到下级(上级)部门,这是需要首要解决的技术问题。 在实际系统的设计和部署中,根据上下级所要交互的数据的类型、规模等因素,同时提供这两种方式的数据共享和交换方式,用户可针对不同情况,酌情选择使用。 3. 技术架构设计 3.1 概述 系统架构示意图 系统以Java和数据库技术为依托,采用JEE相关技术,以MVC模式为核心,采用分层思想,构建健壮、灵活的Web应用程序。在数据库访问层,使用高效的Swim Sql映射框架,实现数据的获取和持久化。在领域逻辑层,使用Spring框架,通过IOC和AOP,实现业务模块的可配置和灵活增加、删减,另外也可以在面的基础上,对业务实现代码进行功能增强。在表现层,综合使用各种Web2.0技术,以Jquery框架为核心,构建具有良好用户体验的GUI 。 3.2 基础组件 3.2.1 Spring Framework 【框架描述】 Spring为编写企业应用程序提供了轻量的解决方案,同时仍然支持使用声明式事务、 用RMI或web service远程调用、以及使用多种方式来将数据持久化到数据库。Spring框架包含许多特性,并被很好地组织在下图所示的六个模块中。 Spring框架架构图 【框架引用目的】 1. Spring 的 Core 封装包 Spring 的 Core 封装包是框架的最基础部分,提供IoC和依赖注入特性。这里的基础概念是BeanFactory,它提供对Factory模式的经典实现来消除对程序性单例模式的需要,并真正地允许我们从程序逻辑中分离出依赖关系和配置。 2. Spring的 AOP 封装包 Spring的 AOP 封装包提供了符合 AOP Alliance规范的面向方面的编程(aspect-oriented programming)实现,让你可以定义,例如方法拦截器(method-interceptors)和切点(pointcuts),从逻辑上讲,从而减弱代码的功能耦合,清晰的被分离开。而且,利用source-level的元数据功能,还可以将各种行为信息合并到你的代码中。我们主要用于对Java数据库操作的事务配置、任务异常监控。 3. Spring中的 MVC 封装包 Spring中的 MVC 封装包提供了Web应用的Model-View-Controller(MVC)实现。Spring的MVC框架并不是仅仅提供一种传统的实现,它提供了一种清晰的分离模型,在领域模型代码和web form之间。 3.2.2 Swim Framework 【框架描述】 Swim 框架是江苏同和软件技术有限公司为了JAVA的数据库快速编程而开发的一个O/R和sql映射编程框架,它对JDBC进行了非常轻量级的操作封装,使得JAVA程序员可以方便地使用SQL来操纵数据库,可以应用在任何可以使用JDBC的场合,既可以在JAVA的客户端使用,也可以在Servlet/JSP的Web应用中使用。 SWIM框架技术架构图 基于Spring和Swim的应用架构图 【框架引用目的】 系统与数据库的交互多而杂,有第三方数据交换平台自身的数据库,有第三方数据源的数据库。Swim框架对于JDBC操作是做过许多优化的,兼容主流的数据库类型,具有非常高的数据操作效率 。 对于动态数据源的处理也是Swim框架的强项,用于应对连接不同的第三方数据源。 Swim提供的O/R映射能满足系统领域逻辑模式的设计。 3.2.3 Piston远程数据交换中间件 【框架描述】 Piston 远程数据交换中间件 ,为江苏同和软件技术有限公司研发的此类中间件的Java版本,在不同的应用系统之间,经常会有数据交换的现象出现,为了让异构信息系统集成技术平台实现数据的共享和交换,并且实现高效的通信、安全的数据传输和编程的透明性,Piston远程数据交换中间件是必不可少的高性能中间件。 Piston工作原理示意图 该中间件包含了数据交换的服务器端组件和客户端组件,它在底层实现了数据加密、压缩、传输等系统级的功能,对外提供了一系列的数据远程交换接口,开发人员只需要根据数据交换的需求,调用相应的编程接口,并把组件和开发的程序正确的部署在需要交换数据的系统中,就可以方便的实现不同地理位置的信息系统之间的数据交互和共享。 【框架引用原因】 1)Piston采用自定义通信协议,在二进制流上做了高效的数据压缩。 2)Piston采用基于HTTP协议之上的应用协议,为远程数据的交换提供了方便的通道。 3)Piston采用MD5、RSA、Blowfish等多种加密手段,确保数据交换的安全。 4)Piston采用类似于数字证书的客户端验证机制,保证数据交换的客户端身份不被伪造。 5) Piston支持多客户端,服务器端使用java编程语言实现,客户端可以是任何语言实现的组件,只要遵循协议就可。 6)Piston提供了web控制台,可以对服务器端中间件的一些参数进行管理,web控制台的登录采用了用户名、密码、验证码和数字口令码结合的方式,采用ssl进行通信,确保web控制台的安全。 3.3 领域模型和逻辑设计 3.3.1 概述 此部分文档用于说明该平台相关领域逻辑在技术上的设计,为了方便描述后续的实现机理,首先介绍领域逻辑层核心的两个组件:任务调度引擎;规则处理引擎。然后讲述核心功能(数据导入、数据加工、数据应用)相关主要领域逻辑设计、权限设计、数据上传和下发设计等。 数据交换、数据加工都涉及到了一个任务的概念。为了更好地控制、管理这些任务,我们设计了一套任务调度引擎,负责任务的定时调度、修改、删除、宕机后任务状态恢复等。 数据加工部分引入了一个规则的概念,我们对规则的第一印象就是量多、相互独立。应对不同业务需求肯定就需要很多种规则去控制数据匹配的过程,所以系统预定的顶级规则肯定数量不少;每种规则都有自己特有的处理方式,否则也不需要使用多种规则了,所以系统对每一种规则都必须有对应的独立的处理过程。面对这种复杂的处理要求,我们设计了一套规则处理引擎,负责对用户定制的规则作出解析,映射出相应的处理程序,再配合任务调度引擎,就能灵活的在平台中执行复杂的匹配任务。 3.3.2 任务调度引擎 3.3.2.1 概述 任务调度引擎工作原理图 本系统为实现自动化的数据采集、匹配,则必然涉及到这个任务可能每天或每周星期二晚上11:30,或许仅仅每个月的最后一天执行。一个自动执行而无须干预的任务在执行过程中如果发生一个严重错误,应用能够知到其执行失败并尝试重新执行。 为了解决这些难题,本系统特引入了任务调度引擎工具的设计,底层开发语言为JAVA,与整个应用无缝连接。整体的工作原理如上图所示,为了便于理解,图中主要展现了几个重要的模块。整个引擎引入以下几个概念:1.任务适配器 2.任务管理器 3.任务驱动核心 4.任务线程池。下面我们就分别讨论他们的作用。 3.3.2.2 任务适配器 任务适配器是整个任务调度引擎的耳朵,是任务调度引擎的入口。在设计上采用了策略模式。一旦有任务模型请求连接,立即抽取、校验任务的执行配置信息,获取到任务实例,需要执行的任务脚本方法名。通过一系列预处理,通知任务管理器做下一步的处理。 3.3.2.3 任务管理器 任务管理器是整个任务调度引擎的大脑,由他来初始化未完成的任务、装载任务脚本、监控任务线程池、发出异常警告。 初始化未完成的任务:在服务器宕机或者服务器重启的情况下,JAVA进程关闭,服务器内存中所有的任务线程肯定都会丢失。当下一次平台启动后为了继续之前的任务,任务管理器就提供了一个初始化的功能,从数据库读取出未完成的任务信息,自动化地启动所有任务。 装载任务脚本: 由任务适配器传递过来的任务模型提供了相应的需要执行的任务脚本,这些脚本定义了具体的任务内容,任务管理器就负责把脚本装备进任务驱动核心,由任务驱动核心去驱动一个新的任务线程。 监控任务线程池:任务线程一旦开启就必须有一个良好的管理机制,以便于平台更好的控制任务。这个控制的过程对于用户是不可见的,由系统去处理。但是会暴露响应的控制接口给用户,主要功能设定在交换项目的监控功能中,后文会具体介绍。 发出异常警告:当任务的执行遇到问题,比如第三方数据源的意外关闭,网闸的重启等意外情况导致的不能执行数据采集等情况,任务管理器马上会给平台一个警告信息,通知平台做出相应的处理,比如生成异常日志文件,Web操作界面的通知,Email的通知等等机制。 3.3.2.4 任务驱动核心 任务驱动核心接收到任务管理器的指令后,会根据要求生成一条线程或使一条空闲的线程,去执行任务脚本。它拥有多个任务开启端口,以满足各种执行方式的任务执行,并且是可扩展的,比如这个任务是周期执行还是延迟执行,是任务管理器识别用户任务定制信息后,向任务驱动核心命令需要从哪个端口开启任务线程。 3.3.2.5 任务线程池 任务线程池是整个任务调度引擎的任务清单,上面记载了任务的来源、执行信息等等,并且为每一个任务提供了一个开展作业的场地。每一个任务都将会开启一个线程去执行,所有的线程组就是我们这里所指的任务线程池,任务线程池在概念上分为内存线程池和外存线程池。 内存线程池指的是在服务器内存中的一组队列数据结构,包含了任务线程的先关信息,便于平台程序监控; 外存线程池指的是持久化到数据库的任务执行信息,只有形态上与内存线程池有差别,在逻辑上他们是保持一致的。外存线程池可以用来保证在断电或JAVA进程杀死的情况下保存任务内存信息,以便于系统重启时任务执行状态的恢复。 3.3.3 规则处理引擎 3.3.3.1 概述 数据规则处理引擎是整个数据匹配加工的核心架构。主要由三个部分组成:规则解析器、规则分发器、规则处理器。 规则解析器:负责把操作员在界面配置的信息,转化成程序可识别的数据描述语言格式;负责把规则描述数据格式(xml或json格式)转化成操作员可视别的规则参数配置界面。 规则分发器:检查交换项目规则列表的处理器类型,识别出该规则组应该由哪个规则处理器执行,动态加载对应规则处理器,调用并执行。 规则处理器:是负责数据匹配加工的实际数据操作程序。解析规则描述数据,针对规则描述的不同,程序自动识别匹配加工条件,完成数据匹配加工处理。 3.3.3.1 处理流程图 规则分发器 规则处理流程图 3.3.3.2 设计原则 从系统平台的稳定、效率、安全、可靠、可维护性的角度出发,设计了一套规则设置和规则处理在功能上完全独立、在业务逻辑上相联系的机制—— “数据规则处理引擎”。 这套机制的主要特点主要体现在: 1. 系统平台对操作员开放的只有规则设置功能和任务时间的设置。所有的加工匹配规则都有程序自动识别规则处理,减少由于人为操作造成的错误。 2. 操作员对交换项目的设置完成后,只需填写任务引擎的开启时间和周期,由“任务调度引擎”(详细说明见任务调度引擎说明部分)去调用规则处理引擎,无需等待,不耽误操作员进行平台其他功能的操作。 3. 采用松耦合的设计原则,在以后的项目维护过程中,规则处理器的实现修改不会影响到前台操作员的操作,同样有新规则需求扩充时,规则解析器和规则处理器都采用策略匹配设计原则,新增规则时,只需针对新规则添加新的解析器和处理器,不需要对原有代码结构做任何调整。 3.3.3.3 规则解析器 规则解析器示意图 为了能让程序去识别规则,系统必须对每个规则有个预定义的数据描述格式。规则解析器由两个解析部分组成: 正向解析:是程序把操作员填写输入的各种参数,根据当前设置的规则类型,按照预定义的数据描述格式,把参数插入到数据格式中,形成规则处理器能识别的规则数据描述。 反向解析:是程序根据规则数据描述和预定义的数据描述格式,扫描出规则的各种参数,并把这些参数重新填写到用户界面中,让操作员可以直观的看懂规则内容。 操作员在页面上设置的规则有各种各样的参数包括表名、字段、字段值等,这些参数只有单独的含义,程序是无法通过这些参数自动识别并转化成数据加工的数据库条件的,所以我们需要把这些参数先转换成程序可识别的一种描述语言。针对规则定义一个规则描述格式,参数值预留。在程序获取用户输入参数后,把参数自动填写进预留位置,形成程序可识别的规则描述。现在比较流行有的有XML和JSON两种数据描述格式。 3.3.3.4 规则分发器 规则分发器示意图 此功能主要提供根据规则或规则组的处理器类型,分别动态去调用相符合的规则处理器去处理这条规则或规则组。 每个交换项目的规则或规则组数量和类型都不会相同,为了灵活适应这种变化,规则分发器提供了一个统一的入口。可以接受任意数量和任意类型的规则或规则组。 在规则分发器内部去遍历传入的规则组列表,根据规则组的处理类型,动态创建规则处理器的实例,来处理这条规则组。 3.3.3.5 规则处理器 此功能主要负责去识别规则的描述语言格式动态生成sql并完成数据处理部分的功能。 规则处理器都是由规则分发器负责实例化,不同类型的规则或规则组都有自己专属的规则处理器。所有的规则处理器都继承自同一个父类,每个规则处理器都有自己特定的实现功能。例如新建最终数据表结构规则处理器,根据新建最终数据表规则描述去动态建立最终数据表;数据匹配处理器,根据匹配规则组动态生成sql select、update、insert语句,然后再根据这些sql语句去查询数据进行匹配。 3.3.4 系统核心功能设计概述 系统最核心的功能主要分为三个部分:数据导入,数据加工,数据应用。具体流程如下图所示: 系统核心功能图 系统通过这三个部分,可以达到数据进的来,能加工,出的去的过程。下面针对每个环节作出更加详细的描述。 3.3.5 数据导入设计 3.3.5.1 概述 【导入方式分类】 导入方式分类图 导入方式根据数据来源的不同可以分为三种:数据库直连;FTP自动导入;界面手工导入。其中数据库直连和FTP自动导入属于自动导入,只需人为设置一次,之后的周期性任务都可由系统自动完成。 【导入流程】 所有类型的导入流程如下图所示: 数据导入流程图 首先操作人员选择是何种类型的导入方式,定义导入参数,不同的导入方式需要以不同的参数设置,后续内容会详细描述。所有的参数都定制完成后系统会生成一条数据导入任务。任务调度引擎的任务适配器会监测到此条任务,此时任务管理器发出指令利用任务驱动核心驱动此条任务,并且推入任务线程池。系统会对任务进行管理和监控。在任务执行的过程中若出现异常(比如第三方数据源突然连接不上,交换平台本身服务器环境异常等)操作人员在监控中心会得到相应的反馈信息,给出后续操作的建议。关于任务调度引擎以及其内部组件的概念在3.3.2节中已经给出详细的解释。 执行的任务:根据导入参数的设置,后台自动建表,该表称作原始数据表。执行数据导入,将导入的数据存储在原始数据表中。对于一个定制的导入,只对应一张原始数据表,如果三方数据源涉及多张表达的情况,则需定制多个导入,或者将多张表在导入环节处理成一张表。 导入界面的设计采用向导方式,稍有数据库知识的操作人员即可准确地定制数据交换项,完成导入工作。 3.3.5.2 数据库直接导入 数据库直连方式支持oracle,sybase,sqlserver,mysql等常见数据库,如选择oracle,系统将提供ip,端口,sid,user,password等相关项目的设置,设置完成后提供连接测试功能,保证数据库能顺利连通。 数据库连通后指定数据库直连导入类型,导入类型又可分为三种类型:表方式、视图方式、存储过程方式。 数据库直连导入类型分类图 操作人员需要录入如下信息作为数据交换项的属性: l IP,端口号,数据库类型,表名(视图名,存储过程名) l 导入频率(天、周、月等) l 导入数据的字段名和类型(默认显示源的字段名称和类型,如果有数据交换定义标准则自动根据字段含义进行比对按标准进行名称和类型的设置,操作人员可以修改) 数据库直连导入工作原理图 3.3.5.3 FTP导入 FTP导入的方式在外部表现上有两种:1.FTP服务器为外部服务器;2.FTP服务器为三方数据交换内部FTP服务器。在系统内部实现上是一样的,都是通过连接FTP服务器,下载相关数据。这边主要要说的是支持的文件类型,系统预设是如下三种,后续可以扩展,EXCEL、CSV、TXT。 FTP方式支持的文件类型图 操作人员需要录入如下信息作为数据交换项的属性: l IP,端口号,目录 l 导入频率(天、周、月、年等) l 文本格式(表头、数据字段名称和类型、分隔符等) FTP导入工作原理图 3.3.5.4 界面人工上传 创建界面人工上传方式的数据交换项后,操作人员可以通过系统提供的web界面上传数据。支持的文件类型和FTP方式的一致,系统预设是如下三种,后续可以扩展,EXCEL、CSV、TXT。 界面人工上传方式支持的文件类型图 操作人员需要录入如下信息作为数据交换项的属性: l 文本格式(表头、数据字段名称和类型、分隔符等) 以下为界面分工上传方式的工作原理图: 界面人工上传导入工作原理图 3.3.6 数据加工设计 3.3.6.1 自动匹配设计 3.3.6.1.1 概述 数据加工流程示意图 一个完整的自动匹配流程由两部分组合完成:前台配置、后台数据处理。 前台配置:有操作员负责完成,针对交换项目逐步按步骤完成匹配数据源设置→最终表结构定义→匹配加工规则定义→任务时间→保存 。 • 输入匹配数据源表名 • 加载匹配数据源和原始数据表结构信息 • 表结构信息临时保存以便设置规则时调用 • 对照表是指经过加工以后,数据的最终存储表。 • 勾选匹配数据表和原始数据表需要导入进最终数据表的有效字段。 • 对勾选的字段进行统一规范化重定义。 • 配置界面由规则类型规定。 • 规则参数:匹配表字段名、匹配表字段值、原始表字段名、原始表字段值、字段关系、截取下标 • 设置匹配执行时间和周期 后台数据处理:由任务引擎自动完成,检测并触发任务执行,创建规则处理引擎,传入规则组列表,规则处理引擎自动识别解析器类型,依次执行规则组,并记录相关日志信息。 3.3.6.1.2 设计原则 数据加工设计原则示意图 灵活性: 三方原始数据的不确定,数据结构未知,匹配条件交换平台无法预知,自动匹配设计要能够处理各种各样的数据进行比对。 通用性: 提取整个匹配流程中所有交换项目数据处理过程共同的地方:数据源设置、最终表结构定义、规则定义、任务时间设置,变成操作员可配置。 安全可靠性: 操作员只需要配置参数就可完成整个自动匹配流程,核心的数据匹配处理由系统分析配置去执行。核心的数据处理对于操作员来说是一个“黑盒”。如果配置参数有误,这个“黑盒”程序会自动阻止后续任务执行,并返回错误信息给操作员。 系统可扩展性: 规则解析变化,数据存放位置变化等等对操作员来说,没有任何的影响,操作员只需关心配置参数的设置是否正确。其他调整都在程序内部调整。 时效性: 匹配数据是一个大量数据操作的过程,数据量越大,所需要的时间越长,操作员不可能一直等待数据匹配的完成。操作员只需要配置完参数,定时设置好任务执行时间,就可使用平台其他的功能,在执行完成后,在匹配结果功能中查询信息就可以查看到详细的结果。 3.3.6.2 手工匹配设计 3.3.6.2.1 概述 数据无法通过自动匹配完成,遗留下不可用数据。这个现象是无法避免的,所以系统需要设计手工匹配把这部分数据利用起来。 原始数据越规整,匹配规则设置的越详细,遗留下的无法匹配的数据就越少,手工匹配数据需要操作员做大量的人工操作去维护。 整个手工匹配流程如图: 手工匹配流程图 前3个步骤由操作员去完成,后2个步骤由程序自动完成。操作员只需关心和确认原始数据和匹配数据是否对应,无需关心匹配后数据如何保存,如何固化规则。系统只会返回给操作员匹配是否成功的操作结果。 3.3.6.2.2 设计原则 操作便捷性:因为手工匹配会涉及到很多数据,简化每个步骤显的极为重要。操作员只需要查询未匹配数据和匹配源数据,进行确认操作。其他工作都由系统程序自动完成。 智能学习:系统为手工匹配预留一个固化规则库,每当操作员手工确认一条数据,系统会自动把原始数据和匹配数据的一一对应关系,保存到固化规则库中。在该交换项目下一次自动匹配过程中,会检查这个固化规则库,相同的数据就不需要再一次就行手工匹配了。 3.3.6.3 数据加工规则 3.3.6.3.1 概述 l 原始表字段等于匹配表字段 字段值一一对应关系,比如地税基础表中的工商登记号=国土地块信息表中的工商登记号、地税基础表中的企业名称=工商数据表中的企业名称等。 l 原始数据表过滤 原始表字段+过滤条件,原始数据中只有一部分数据需要比对,或者某个规则只适用于这个范围的原始数据。比如原始数据中只需要匹配某个乡镇的数据,乡镇代码=“32048309”、只需要匹配今年的数据,年份=2012、只需要匹配税号是“3204000083”开头等。 l 匹配数据表过滤 匹配表字段+过滤条件,原始数据只与匹配表中某部分数据进行匹配。比如原始数据内容比较少,只有常州市的数据,而匹配表包含全省数据,为提高处理效率,可设置匹配表地区=“常州”。 l 原始表字段等于匹配表字段截取 原始表字段=匹配表字段部分,比如地税表中有区号,但是匹配表没有提供区号这个字段,但是匹配表中有个字段是由区号+编号信息组成,就可以使用这条规则截取匹配表的字段提取区号。 l 原始表字段截取等于匹配表字段截取 例如,税务局的数据唯一编号前4位代表是地市区号,工商局的数据唯一编号中的6到10位代表是地市区号,就可以通过这条规则截取税务局唯一编号的0到4位等于工商局数据唯一编号的6到10位达到数据匹配关系的建立。 l 原始表字段截取等于匹配表字段 原始表字段部分=匹配表字段,规则原理等同上述第四条规则 l 截取字段生成新字段 举例,数据需要按地市下发数据,而最终数据表中没有地市这个字段,但是有乡镇代码字段,乡镇代码字段=地市编号+序号,系统可以根据这条规则截取乡镇代码的前6位,保存成地市字段。 l 字段翻译 在利用比对数据的时候,无法避免遇到下列状况:有数据状态字段的值一般都是0、1、2、3;管理机构字段一般都保存的是机构代码;操作员难以理解0、1、2这些数值代表什么含义,机构代码代表是具体哪个机构。字段翻译可以通过基础数据字典表查找,把这些字段值翻译成能让人容易理解的具体说明。 l 补充关联信息 举例,地税户管基础表包含的数据不够全面,也有数据保存在其他表中,但是和基础表都有税务管理码这个字段,利用该规则可以通过税务管理码作为关联字段,把其他表的信息作为一个新字段补充道最终数据表中。 l 计算生成新字段 例如在导入的原始数据(国土数据),国土数据只有该企业的厂房面积,而匹配数据(地税数据)只有该企业面积单位税额。在数据利用时,操作员很关心该纳税总额(厂房面积×单位税额),该规则可以自动帮操作员计算出总税额,并保存在最终数据表中,操作员不必导出数据后人工进行计算得到总税额。 上述是系统预先定义的加工规则,是保证数据能够正确建立匹配关系的基础。随着系统的不断完善,导入的三方数据的多样化,可以不断的补充、完善平台的规则库。 扩展加工规则时,需要预先定义其数据保存结构,预留参数值,保证其能够适用于各种类型的交换项目。然后分别去实现新规则定义的解析器和规则处理器。 3.3.6.3.2 设计原则 通用性:加工规则必须要能适应各种不同数据来源的交换项目,不能只能适用于某一个交换项目或者某些特定的交换项目。 灵活性:规则的预定义只是定义规则的数据结构,方便程序去解析,具体的规则参数值全部由操作员根据具体的交换项目来设置。 扩展性:良好的扩展性方便日后系统规则的修改、补充、完善。每个规则的结构都是独立实现。修改某一个规则结构不会影响到其他规则。同样新增一种规则,也不需要去修改原来的规则结构。 3.3.7 数据应用设计 3.3.7.1 概述 根据当前需求,数据应用大致可分为:固定查询、单户明细信息查询、文本导出、外部数据库直接推送、dblink数据库直连和程序接口。 数据应用分类图 3.3.7.2 固定查询 系统提供web界面以供操作人员进行查询工作,此处的固定查询包括了数据库字典查询、数据交换项明细查询等。 3.3.7.3 单户明细信息查询 通过系统提供的web界面,操作人员可以针对地税方的单一户管相匹配的所有的交换数据,便于数据利用人员全面的了解某一户企业的第三方数据情况。 3.3.7.4 文本导出 系统对于以上查询结果都提供了excel或者csv文件导出的功能,以供人工使用。 3.3.7.5 外部数据库直接推送 操作人员可以通过数据推送定制界面配置需要使用数据的外部数据库,系统的任务调度引擎会开启一个数据推送的任务,把第三方数据交换平台的相应数据推送至指定外部数据库。 外部数据库直接推送图 此种方式推送工作都是在本系统中完成,外部系统只需要给出数据库的写入权限。 3.3.7.6 Dblink 本系统数据库采用Oracle,所以可以对外开放dblink连接,外部系统可以通过dblink方式用读取本系统的数据库数据。 dblink是定义一个数据库到另一个数据库的路径的对象,dblink允许你查询远程表及执行远程程序。 3.3.7.7 程序接口 程序接口主要采用Web Service、轻量级RPC等方式。开发结束后会提供详细的API描述文档,方便其他系统调用。 3.3.7.7.1 Web Service接口 不管其他系统的Web service是用什么工具,什么语言写出来的,只要你用SOAP协议通过HTTP来调用它就行。 客户生成的SOAP请求会被嵌入在一个HTTP POST请求中,发送到本系统的Web服务器来。Web服务器再把这些请求转发给Web service请求处理器。请求处理器的作用在于,解析收到的SOAP请求,调用Web service,然后再生成相应的SOAP应答。Web服务器得到SOAP应答后,会再通过HTTP应答的方式把它送回到客户端,客户端就获得了需要的数据。这样就完成了一次Web Service调用。 Web Service应用结构图 3.3.7.7.2 RPC接口 RPC,Remote Procedure Call,远程过程调用。其他系统作为客户端,向第三方数据交换平台程序接口发送数据操作请求,平台则根据调用参数给出回应。请求流程参考下图: RPC应用结构图 A系统读取本系统数据可以分为如下步骤(序号为图中显示序号): (1) A系统的程序调用“RPC客户端内核”。此内核为本系统开发结束阶段提供。A系统可以在各自代码中嵌入。 (2) “RPC客户端内核”与“RPC服务端内核”通信,传达请求信息。 (3) “RPC服务端内核”调用第三方数据交换平台的数据读取程序。 (4) 数据读取程序向“RPC服务端内核”返回数据。 (5) “RPC服务端内核”向“RPC客户端内核”返回数据。 (6) “RPC客户端内核”向A系统的调用程序返回数据。 3.3.8 数据上传和下发设计 3.3.8.1 概述 市级交换平台系统需要向省级交换平台上传交换项目数据,以及定时上传市级平台使用情况统计信息等。 省级交换平台需要向市级交换平台以交换项目为单位下发该交换项目的原始数据或最终比对好的数据。 所有上传下发的数据下载和推送工作其实都是在子节点进行,即市局节点。下面分别对数据上传和数据下发作相应的描述。 3.3.8.2 数据上传 数据上传示意图 市级交换平台与省级交换平台之间存在一个相互简单通讯的通道,数据上传和下发任务都是通过这个通道来实现通讯。市局节点定期统计交换项的信息,包括数据利用率、使用情况等信息。这些信息需要定时上传省局节点的。 数据上传发起端为市局节点,每次上传都需要向上级节点发出申请信号确认网络良好的情况下,由任务调度引擎开启一个任务线程,执行相应的数据推送任务。 任务执行完毕,相应的日志信息,执行情况在省局和市局节点都会有相应的反馈。在当前网络环境不是很良好或者数据异常的情况下系统会对市局节点的管理员发出警报,由管理员处理后手动上传,若管理员长时间不响应,系统将作常规检查后尝试继续重新上传。 数据上传流程图 3.3.8.3 数据下发 数据下发方示意图 省级交换平台向市级交换平台以数据交换项为单位下发该交数据交换项的原始数据或最终比对好的数据。 有些交换项目是由省级创建,并且原始数据是通过省级才能采集到,但数据真正的利用者却是市级的管理员。省级的管理员可以统一匹配好数据,把匹配完的最终数据下发给各个市级节点。如果全省数据过于庞大,管理员可直接按照地市分割数据下发,有市级节点去匹配数据。 数据下发任务发起端在省局节点,省局节点只需新建一个数据下发的描述,子节点就能获取到这样一个信息。其实子节点每个一定时间会去查看一下省局是否有新的下发描述发布,这就是一个监听的概念。 数据下发任务的描述,包括下发哪个交换项目,项目相关权限信息,下发数据给那个市级平台,下发数据如何分割,数据库地址、帐号密码等信息。 市级节点监听到与自己的相关的描述,则读取下发描述,在本地建立一个下载数据的任务,从省级数据库中读取数据到本地,交由任务调度引擎决定何时执行。 数据下发与数据上传不同,数据下发一般都是下发三方数据源或者匹配好的对照数据,数据量比较大。 数据下发流程图 3.3.9 任务监控管理中心设计 本系统的核心着眼点是数据的交换处理和利用,所以对于数据的管理是最核心的一环。为了便于数据的全生命周期管理,在本系统中引入了数据交换项的定义。数据的导入、加工、应用、下发、权限管理等都以数据交换项为宿主。 数据交换项示意图 在系统中我们关心的数据不同的生命周期(导入前、导入时、导入后、加工时、加工后、成品数据,都是指的数据不同生命周期)可以认为就是数据交换项的生命周期。而怎么改变数据交换项的生命周期都是由任务调度引擎去调度的。一个数据交换项需要多个任务去遍历整个生命周期,所以任务的监控管理是非常重要的。 在系统中我们利用面向对象编程、面向切面编程等思想解决了任务监控的难点。数据在每个环节都会有对应的用户界面展示,而且可以控制。 另外,对于数据每个环节的操作和管理,系统都会提供详尽日志,以供后期分析查询使用,提供数据交换成果的统计与分析功能。 交换项的异常情况也会很好的反馈。这里所说的异常情况的反馈是指后台自动运行的一些诸如数据导入、数据加工、数据下发等任务,在遇到异常情况时怎样进行反馈。在系统中,会将产生的异常进行详细记录,并通过系统信箱的方式,通知该异常相关的处理人员。 系统用户登录系统后,就会看到产生异常的反馈信息,用户根据系统提供的信息,分析异常的产生原因,从而去处理异常。 3.3.10 系统权限设计 对于系统来说,具有很多不同的操作人员,而不同的操作人员对于系统功能也具有不同的操作权限。这方面,我们主要通过系统提供的登录与权限验证系统来保证。在系统的岗位设置模块中,包含了权限分配与控制模块。操作人员登录后,系统会自动根据管理员预先分配的权限(岗位),展现相关的系统操作功能,除了展现的这些功能以外,用户不能对其它功能进行操作。系统的登录分配权限流程如下图所示 用户登录流程图 当用户成功登录以后,就交由权限验证系统进行权限的验证。权限系统我们采用基于岗位和用户的两级权限分配和验证系统。具体来说,就是系统中的用户,必须具有一定的岗位(一个或多个),而岗位才拥有具体的权限。系统内置的管理员拥有系统中权限分配管理模块的所有操作权限,他负责维护用户信息以及岗位,并进行权限分配。所谓权限,就是指对系统中某项或多项功能具有操作权。这样一种权限系统的设计,一方面把权限和用户解藕,提高了灵活性。另外一方面,通过岗位的引入,可以让系统管理员的权限分配工作变的更为轻松。其关系如 下图所示。 功能权限关系图 对于系统功能的操作,除了在权限上严格设置保证功能的操作安全外,对于每次功能操作,系统都会在程序级别进行记录,以供后期的查询分析或者责任追溯,如下图所示。 权限监控分析图 3.3.11 数据权限设计 数据权限指的是用户查看数据的权限。数据权限系统我们采用基于岗位和交换项的两级权限分配。和功能权限的考虑出发点不同,功能权限由用户作为主体,分配岗位,由岗位获得功能权限。而数据权限由数据交换项(概念包括了一组第三方数据)作为主体,操作人员配置交换项时会有一项步骤勾选岗位,选中的岗位对应的用户即对此交换项拥有了访问权限,交换项与岗位的绑定在交换项的管理界面可以做后续的修改。对应关系如下图: 数据权限关系图 系统对外暴露的接口也必须使用拥有相应数据权限的账号密码才能获取数据信息。 3.3.12 数据标准设计 操作人员在创建数据交换项的时候,数据进入系统采用的数据字段都是要满足《税收数据标准管理系统》的标准,新类型字段必须通过《税收数据标准管理系统》审核。 在设计上我们在系统中植入《税收数据标准管理系统》接口。操作人员新建数据交换项在配置数据字段的步骤中,系统根据《税收数据标准管理系统》的标准控制操作人员定制的字段,如果操作人员发现现有标准不满足自己对字段的需求, 页面上可以点开申请字段的弹出框向《税收数据标准管理系统》发出申请。待申请结束后,若通过则交换项配置成功,若不通过则重新配置交换项。具体流程如下图所示: 数据标准实现流程图 在界面操作上系统提供最友好的优化设计方案,保证操作人员易于操作,使字段规范化轻松实现。 3.3.13 现有系统集成设计 考虑各地当前数据交换方式不同,有些已有自己独立的数据交换系统。更换系统操作上需要适应的过程,老数据也要能合理方便的迁移到新的交换系统中。所以与其他系统的兼容性设计是比较重要的。本系统与外部系统交互其实涉及两个方面。数据的进和数据的出。保证外部系统能很好地与本系统交互。流程可以参考下图: 系统集成方案图 如图中所示,对于数据的进入,有两个方案:1.操作人员可以通过本系统常规的数据导入菜单把原有系统 中数据导入,在数据加工环节可以选择是否设置比对或其他过滤条件,最后数据在本系统中呈可用状态;2.本系统提供数据导入接口,以供其他系统用于推送数据。 对于数据的出,也就是数据的使用,在3.3.7中的数据应用中描述的,外部系统可利用本系统提供的Web Service、轻量级RPC、DBlink等方式从本系统获取数据。 另外需要提到的是数据如何进如《数据仓库》,第三方数据交换平台的数据最终是要进入《数据仓库》的。对于进数据仓库可以有四个方案: 1. 《数据仓库》调用《第三方数据交换平台》的数据输出接口 2. 《第三方数据交换平台》调用《数据仓库》的数据抽取接口(如果提供) 3. 《第三方数据交换平台》的数据库使用dblink连接《数据仓库》,向其推送数据 4. 《数据仓库》使用dblink连接《第三方数据交换平台》从其拉数据。 3.3.14 数据使用反馈设计 从上面对整个系统的设计可以看出,数据是以数据交换项这个对象作为宿主的,它的生命周期只有在《第三方数据交换平台》中才能很好控制。那系统如何得知加工好的数据在其他系统的使用情况呢。 这部分内容将讲述系统是如何实现数据使用反馈功能的。 针对不同的使用情况我们把数据使用反馈功能设计为两种反馈机制: 1、 通过WEB界面填写反馈信息 WEB界面填写反馈信息示意图 数据使用方在数据使用过程中,可以通过第三方数据交换平台提供的WEB界面提交使用情况的反馈。此种方案适用于使用方系统不方便调用API的情况,纯人工操作的一种方式。 2、 系统提供反馈信息回写API,以供其他系统调用。 API回写反馈信息示意图 数据使用方系统在数据使用过程中计算出需要反馈的数据信息,通过第三方数据交换平台提供的反馈API接口提交使用情况的反馈。此种方案需要其他系统嵌入调用本系统API的代码,具体文档在本系统开发结束阶段会提供给使用方。 4. 系统功能设计 4.1 概述 在系统功能上,我们把平台分为四部分。 第一部分是数据交换,处理和第三方进行业务数据交换的工作,保证第三方的业务数据能完整的通过平台进行交换,并按原始数据条目进行保存,数据交换的途径,内容,文件格式,频率等可根据实际情况灵活定制。 第二部分是数据加工,即在交换的原始数据的基础上,对数据进行分类,匹配,过滤等操作,将交换的数据加工成业务部门可以直接进行应用的形式,加工的过程分配置型自动处理和人工干预处理两部分。 第三部分是数据的应用,平台提供交换数据和加工数据的基本查询以及数据导出接口,而涉及到和各种实际业务结合的应用,则不在平台处理范围内。 第四部分是系统的设置和管理部分,包括系统层级设置,权限设置,代码表设置等。 4.2 数据交换部分 数据交换部分的功能主要包括自定义交换项目设置,管理和日常监控。 4.2.1 数据交换流程 数据交换流程示意图 4.2.2 交换项目设置 包括交换项目的新建,编辑以及删除功能: 4.2.2.1 交换项目的新建 【功能描述】 新建一个交换项目,并以向导形式提供数据交换的各项内容的设置。设置项包括: 1、交换项目的名称 2、交换项目的描述 3、交换内容 4、信息交换数据源 5、 数据更新范围 6、 数据更新方式 7、 错误数据处理方式 8、 交换部门 9、 数据访问权限 【交换项目名称设置】 定义交换项目名称,手工录入 【交换项目描述】 定义交换项目的详细描述,或额外备注,作为交换项目名称的补充,手工录入 【交换部门设置】 定义交换项目对应的数据交换部门。 交换部门在系统设置中进行维护,在设置时进行选择。 【交换内容设置】 定义此数据交换项目的具体字段,以逐项新增的方式,提供动态的交换内容字段的设置。 设置过程中调用地税方数据标准库,如新增一个交换字段内容为工商登记号,如在地税方数据标准中有对工商登记号的数据标准,则字段名称,字段数据类型,字段长度,约束条件等均继承地税方数据标准中的定义。如交换字段内容在地税方数据标准中未定义,则手工设置以上内容。 【交换数据源设置】 定义此数据交换项目的交换数据源,并根据数据源类型,提供该数据源的详细内容的设置功能。 数据源类型分为: 数据库直连方式、FTP文件服务器方式、手工文件导入方式 数据库直连方式: 设置交换数据库类型,系统支持oracle,sybase,sqlserver,mysql等常见数据库,及相关设置,如选择oracle,系统将提供ip,端口,sid,user,password等相关项目的设置,设置完成后提供连接测试功能,保证数据库能顺利连通。 数据库连通后,指定交换方式,数据表或者sql语句,并确定和交换内容的对应规则。 FTP文件服务器方式: 设置交换FTP服务器的IP,端口,用户名,口令以及数据所在目录,设置完成后提供连接测试功能,保证FTP服务器能顺利连通。 FTP服务器连通后,指定交换文件的类型(txt,tsv,csv,excel...)和文件名称规则,并确定和交换内容的对应规则。 手工文件导入方式: 设置交换方式为手工文件导入,可指定交换文件的类型(txt,tsv,csv,excel...)和文件名称规则,并确定和交换内容的对应规则。 交换文件格式定义: 如果交换数据源是FTP文件服务器方式或手工文件导入方式,则需要定义交换文件的格式,如分割符设置,标题行设置,文本字段符号等。 【数据更新范围设置】 定义每次数据更新的范围: 1、增量更新 2、全部更新 在交换方提供的数据为增量数据时,使用增量更新,交换的数据将在原有数据的基础上新增,不处理原来已经交换过的数据。 在交换方提供的数据为全部数据的时候,使用全部更新,每次交换前将先清空原有的交换数据,再从数据源将全部数据更新过来。 【数据更新方式设置】 定义每次数据更新的方式: 1、新增 2、关键字段覆盖 新增方式:即每次数据更新都是新增,而不管数据与原来数据的关系。 关键字段覆盖:也就是启用关键字处理,在处理增量数据的时候,如果遇到现有数据中存在相同关键字或关键字组,就更新现有数据;不存在的话就新增,仅在数据更新范围为增量更新时启用。 数据更新范围与数据更新方式两项设置主要定义了数据在进行交换时,如何处理与原有交换数据之间的关系,因为根据业务的不同,不同的数据有着不同的更新频率和数据量,对于高频率,海量数据的交换,我们不可能每次都进行全部的更新,比较适宜的做法是每次只交换新增或者变更的数据,当然,这也要根据交换数据源本身的情况来进行选择,如果交换数据源无法进行新增或者变更数据的判断,那么也只能进行整体更新,因此这里提供了数据更新范围和更新方式的组合方式设置,以适应数据交换的各种情况。 【错误数据处理方式设置】 定义在交换过程中,如发现交换数据源中的数据格式有问题,无法进行交换时的处理方式: 1、忽略错误数据,只交换正确部分的数据,并将错误数据在日志中进行记录 2、发现错误就停止交换,并进行日志记录 【数据访问权限设置】 定义交换数据的访问权限,分为: 1、核心机密数据 2、敏感信息数据 3、公共数据 分别对应不同的数据安全级别和访问权限。 公共数据对所有用户开放,核心机密数据和敏感信息数据不公开,且对应不同的数据访问权限。只有拥有对应的数据访问权限,才能访问到这些非公共数据(对于数据访问权限,一方面可以在前端通过权限控制来实现,另一方面,为保证数据库端的安全,可以对非公开数据进行加密存储) 【交换项目设置完成】 系统自动根据交换项目的设置,动态创建此数据交换项目的相关数据存储表和数据字典。 4.2.2.2 交换项目的编辑 【功能描述】 在交换项目设置完成以后,可以通过此功能来进行编辑,编辑内容参照交换项目的新建章节。 【说明】 在交换项目运行过程中,不能进行项目的编辑,以免对交换数据带来影响。 编辑过程中如果涉及到交换内容的变更,则对应的原始数据字典也要同时变更。 4.2.2.3 交换项目的删除 【功能描述】 将定义好的交换项目删除。 【说明】 交换项目删除提供两次确认,防止误操作,交换项目删除后,此交换项目对应的调度,日志,数据加工规则和交换数据将一并删除,避免系统长时间运行后出现过多的冗余数据,如果需要保留数据,则在操作前先进行数据备份。 4.2.3 交换项目调度 【功能描述】 即数据交换周期的管理,数据交换项目建立以后,设置数据交换项目的运行方式和执行频率。 【说明】 运行方式分为手动执行和自动执行。 如果交换项目数据源为手工文件导入,则调度方式只能为手动执行,执行时选定交换用的数据文件,系统将根据交换项目的设置,进行数据交换。 如果交换项目数据源为其他方式,则可设置手动执行和自动执行两种方式,手动执行即根据交换项目的设置,进行一次数据交换;自动执行需要设置交换项目自行执行的开始时间,结束时间和执行频率(天,周,月,年等)。 4.2.4 交换项目的监控 数据交换项目的监控,包括总体运行情况一览和项目日志管理。 4.2.4.1 总体运行情况一览 【功能描述】 监控数据交换项目面上的情况,可以查看启用的数据交换项目哪些是正常运行的,最后一次交换时间是什么时候,交换的数据记录数量等;哪些数据交换项目运行异常,异常发生时间等。 【查询条件】 交换项目名称(可模糊),交换部门,是否启用,运行正常/不正常,最后一次运行时间 【查询结果】 数据交换项目名称,交换部门,是否启用,运行情况(正常/不正常),异常发生时间,最后运行时间,交换数据记录数,错误数据数量。 【说明】 查询结果受操作人员权限影响。 4.2.4.2 日志管理 【功能描述】 主要针对出现异常的项目,查看具体的错误日志,是交换数据源连接异常,还是交换数据内容异常,异常的具体情况如何,便于管理人员和技术人员分析异常原因。日志管理提供查看,导出,清空等日志管理常用操作。 【查询条件】 交换项目名称(可模糊),交换部门,有无错误日志,最后一次运行时间 【查询结果】 交换项目名称,交换部门,有无错误日志,最后一次运行时间 向下钻取可查看具体交换项目的日志。 【操作】 导出日志,清空日志。 【说明】 查询结果受操作人员权限影响。 4.2.5 数据交换的一些原则 数据交换部分的功能以灵活定义为原则,系统理论上考虑各种情况,并提供操作内容的支撑,但实际应用中,会有一些业务上的限制,但系统本身不会为了业务上的限制而降低灵活性,这些限制应该通过管理要求来加以控制。例如来源不同的同类型数据的处理和利用,省局和某部门进行了全省某数据的交换,同时,某地市也和当地的同样部门建立了全市的数据交换,这时,业务上使用什么数据并不是由交换系统来决定,而是应该由管理要求来决定。 4.3 数据加工部分 数据加工部分最主要的功能是将交换数据和地税现有的数据进行匹配,分为自动匹配和人工干预匹配。在匹配过程中又同时涉及到数据的分类和过滤。 4.3.1 数据加工流程 数据加工流程示意图 4.3.2自动匹配 4.3.2.1 交换项目查询功能 【功能描述】 此功能根据条件查询交换项目列表。默认查询条件是已导入数据的交换项目 【说明】 查询功能是设置加工配置的前置功能,先查询出交换项目列表信息(包括交换项目的基本信息,已设置的规则组数量统计)。提供两个功能入口:开始配置、修改配置。选择具体的某个交换项目进行配置,对未设置规则组的交换项目只能进行开始配置功能,已设置规则组的交换项目只能进行修改配置功能。 4.3.2.2 地税方匹配数据源设置 【功能描述】 让操作员手工输入与交换数据进行匹配的匹配数据表表名,设置完成后需要加载匹配数据表和原始数据表的数据结构并保存。默认是地税户管清查表。 【说明】 是实现三方数据交换平台基本思想,只要数据之间有关系就可以进行数据交换匹配的实现前提。不仅仅局限于第三方的数据与地税数据进行对比,只要三方数据导入进平台系统,平台既可以把它看作原始数据进行交换,也可以把它看作是匹配的数据源与其他的三方数据进行匹配。 4.3.2.3 定义交换数据最终数据表结构 【功能描述】 此功能显示原始数据表和匹配数据表的所有字段结构信息,让操作员去选择原始数据和匹配数据有哪些字段是有效、可利用。 【说明】 双方的数据由于原来是保存在不同的部门下,而且不同的部门信息化程度不一样,无法避免的有数据定义混乱,双方字段名称相同,数据光看表结构肯定无法让人理解其字段含义,所以需要此功能来统一规划数据结构。需要有一套标准化、规格化、命名体系来重定义数据结构,解决字段命名不合理,字段名重复等问题。 4.3.2.4 定义交换数据匹配规则 【功能描述】 定义原始数据和匹配数据之间的联系。通过新增、追加、删除匹配规则等一系列操作形成一个有优先级顺序规则组列表。 【说明】 匹配规则: 1. 原始表字段等于匹配表字段 字段值一一对应关系,比如地税基础表中的工商登记号=国土地块信息表中的工商登记号、地税基础表中的企业名称=工商数据表中的企业名称等。 2. 原始数据表过滤 原始表字段+过滤条件,原始数据中只有一部分数据需要比对,或者某个规则只适用于这个范围的原始数据。比如原始数据中只需要匹配某个乡镇的数据,乡镇代码= “32048309”、只需要匹配今年的数据,年份=2012、只需要匹配税号是“3204000083”开头等。 3. 匹配数据表过滤 匹配表字段+过滤条件,原始数据只与匹配表中某部分数据进行匹配。比如原始数据内容比较少,只有常州市的数据,而匹配表包含全省数据,为提高处理效率,可设置匹配表地区=“常州”。 4. 原始表字段等于匹配表字段截取 原始表字段=匹配表字段部分,比如地税表中有区号,但是匹配表没有提供区号这个字段,但是匹配表中有个字段是由区号+编号信息组成,就可以使用这条规则截取匹配表的字段提取区号。 5. 原始表字段截取等于匹配表字段 原始表字段部分=匹配表字段,规则原理等同上述第四条规则。 规则组概念:可定义一条或多条规则来满足数据的自动匹配关系。 如:规则一,定义地税方登记信息中的工商登记号码=工商原始登记数据的工商登记号码;规则二,工商原始登记数据中的登记号码前6位=320400;规则三...... 这样一系列规则,规则与规则之间为逻辑与的关系。这样一套规则设置完成后,可定义为一个规则组,每个规则组可以包含上述的一条或者多条规则。每个项目可以设置一套或者多套规则组,如果是多套规则组,则需要进行优先关系的设置。如进行自动匹配时,某条交换数据套用第一套规则,与地税方的数据建立了匹配关系,那么在第二套规则启用的时候,这条数据就不参与自动匹配了。也就是说如果存在多套规则组,排在后面的规则组在匹配时使用的数据是前面的规则未匹配上的数据。 4.3.2.5 定义交换数据加工规则 【功能描述】 数据加工是指在数据匹配后,对比对后的数据进行加工、完善、补全等一系列措施。而定义交换数据加工规则其实就是定义了如何对该比对数据进行加工、完善、补全的描述。 【说明】 加工规则: 1. 截取字段生成新字段 举例,数据需要按地市下发数据,而最终数据表中没有地市这个字段,但是有乡镇代码字段,乡镇代码字段=地市编号+序号,系统可以根据这条规则截取乡镇代码的前6位,保存成地市字段。 2. 字段翻译 在利用比对数据的时候,无法避免遇到下列状况:有数据状态字段的值一般都是0、1、2、3;管理机构字段一般都保存的是机构代码;操作员难以理解0、1、2这些数值代表什么含义,机构代码代表是具体哪个机构。字段翻译可以通过基础数据字典表查找,把这些字段值翻译成能让人容易理解的具体说明。 3. 补充关联信息 举例,地税户管基础表包含的数据不够全面,也有数据保存在其他表中,但是和基础表都有税务管理码这个字段,利用该规则可以通过税务管理码作为关联字段,把其他表的信息作为一个新字段补充道最终数据表中。 4. 计算生成新字段 例如在导入的原始数据(国土数据),国土数据只有该企业的厂房面积,而匹配数据(地税数据)只有该企业面积单位税额。在数据利用时,操作员很关心该纳税总额(厂房面积×单位税额),该规则可以自动帮操作员计算出总税额,并保存在最终数据表中,操作员不必导出数据后人工进行计算得到总税额。 4.3.2.6 设置自动匹配任务 【功能描述】 为该交换项目的自动匹配任务设置任务启用的时间、周期。 【说明】 自动匹配任务启用时间精确到小时。 处理类型分为一次、每日、每周、每月、每年。 4.3.2.7 修改数据加工配置 【功能描述】 对已配置过匹配数据源、匹配规则、加工规则等的交换项目,需要进行最终数据表结构调整,规则修改,匹配任务时间修改。上述配置修改都由此功能来实现。 【说明】 在交换项目查询出的列表中,对已配置过的交换项目可以选择此功能进行修改。操作员可以分步骤修改匹配数据源、匹配规则、加工规则、任务时间,也可跳过前面几个步骤直接修改过任务时间。 4.3.3 手工匹配 4.3.3.1 交换项目查询 【功能描述】 此功能根据条件查询交换项目列表。默认查询条件是已完成自动匹配的交换项目 【说明】 查询功能是手工匹配的前置功能,先查询出交换项目列表信息(包括交换项目的基本信息,已匹配上的记录总数、未匹配上的记录总数)。操作员选择操作某个交换项目,再针对该交换项目进行手工匹配。 4.3.3.2 未匹配原始数据查询 【功能描述】 根据条件查询该交换项目所有未成功匹配的数据。 【说明】 查询结果列表显示原始数据的所有信息。对于未成功匹配的数据,操作员面临两种选择:一种认为此这条原始数据不可为,标记为垃圾数据;还有一种是可利用的进行手工匹配流程。 4.3.3.3 匹配数据源查询 【功能描述】 默认查询该交换项目设置的匹配数据源表的所有记录。可根据查询条件,模糊过滤数据。 【说明】 由操作员手工选择某一条原始数据,查询匹配数据源,根据条件过滤查询出与这条原始数据匹配的一条匹配数据。 4.3.3.4 手工匹配关系确认 【功能描述】 手工确立原始数据与匹配数据的对应关系,固化并保存此次人工匹配规则关系。 【说明】 1. 预先加载此交换项目的最终数据表结构信息,把原始数据表和匹配数据按照最终数据表结构信息插入到最终数据表中。 2. 加载此交换项目的加工规则,把新插入最终数据表 这条记录按照加工规则处理一遍,保证手工匹配进入最终表的数据与自动匹配进入最终表的数据结构保持一致。 3. 记录原始数据和匹配数据的两条记录主键值的对应关系。把此对应关系与交换项目关联起来保存到数据库中。下次自动匹配处理程序会读取这个固化关系库,节省手工匹配操作。 4.3.4手工撤销匹配 3.3.4.1 交换项目查询 【功能描述】 此功能根据条件查询交换项目列表。默认查询条件是已完成自动匹配的交换项目 【说明】 查询功能是手工撤销匹配的前置功能,先查询出交换项目列表信息(包括交换项目的基本信息,已匹配上的记录总数、未匹配上的记录总数)。操作员选择操作某个交换项目,再针对该交换项目进行已匹配记录查询。 3.3.4.2 已匹配记录查询 【功能描述】 根据条件查询该交换项目所有已匹配的原始数据 【说明】 在列出原始数据的同时,可同时展开与这条原始数据相对于的匹配数据和最终数据表信息。由操作员人工审核这条已匹配的记录是否正确。 3.3.4.3 撤销匹配关系 【功能描述】 操作员审核发现这条数据(包括自动匹配和人工匹配时发生匹配错误)与实际情况不符合,可回退这条数据的状态。 4.3.5 数据匹配综合管理 4.3.5.1 自动匹配管理 【功能描述】 此功能设置交换项目的自动匹配状态。 【说明】 针对按固定周期交换数据的交换项目进行设置,每当有新的交换数据导入进平台,检查此交换项目的自动匹配状态,若自动匹配状态为启用,则在导入数据完成后直接由任务调度引擎自动根据在匹配设置时,设置的任务时间周期参数去检查时否应该执行匹配任务。若不启用则需操作员去手工开启数据匹配任务。 4.3.5.2 交换项目匹配情况概览 【功能描述】 此功能主要查询交换项目匹配情况的相关信息。 【说明】 按数据交换项目查询数据匹配的情况一览,如数据是否进行了匹配关系设置,是否进行过数据自动匹配,何时进行的最后一次匹配,自动匹配结果(匹配到多少记录,未匹配到多少记录),对匹配到的记录和未匹配到的记录可以进行查询。 4.4 数据应用部分 本部分主要是数据的简单查询,以及数据输出接口,包含: 1、 数据字典查询 2、 交换项目情况查询 3、 按交换项目的简单数据查询 4、 单户明细信息查询 5、 数据输出接口 6、 成果展示 数据查询以及数据输出接口除了可以查询本级数据外,也可以查询上级部门交换,匹配并分发的数据。 4.4.1 数据字典查询 【功能描述】 主要针对通过交换项目建立的交换数据字典的查询,在数据交换项目新建的时候,系统会根据对交换内容的定义,自动创建该交换项目使用的交换数据表,并创建对应的数据字典,在交换内容发生变更的时候,同样会更新交换数据表结构以及对应的数据字典。 本功能提供对这部分自动创建的交换数据表的数据字典查询,便于各方面的相关人员及时全面掌握数据交换的内容细节,为交换数据的管理和利用提供帮助。 【查询条件】 交换项目名称(可模糊),交换部门 【查询结果】 符合条件的交换项目列表,并可向下钻取查询具体交换项目的数据字典。 【操作】 数据字典导出 【说明】 查询结果受操作人员权限影响。 4.4.2 交换项目情况查询 【功能描述】 查询符合条件的交换项目列表,并可向下钻取查询具体交换项目的设置情况。 【查询条件】 交换项目名称(可模糊),交换部门 【说明】 查询结果受操作人员权限影响。 4.4.3 按交换项目的简单数据查询 【功能描述】 按交换项目提供的数据查询 【查询条件】 交换内容 【查询结果】 符合条件的交换数据,字段为交换项目定义的内容字段。 【说明】 例如,系统建立了一个和工商的数据交换项目,交换内容为工商注销企业信息,那么对应在本功能中会有针对此交换项目的查询功能,按交换内容(即字段)进行筛选和查询,显示相关的信息,因为是业务系统,因此,这里能查询到的数据为已经加工过的数据,而不是原始交换数据。 4.4.4 单户明细信息查询 【功能描述】 按地税方的登记户管,对交换并加工后的数据进行单户明细信息查询,即查询与地税方的单一户管相匹配的所有的交换数据。便于数据利用人员全面的了解某一户企业的第三方数据情况。 【查询条件】 纳税人识别号,纳税人管理码,纳税人名称(可模糊) 【查询结果】 显示交换项目列表,可向下钻取,查看该企业在该交换项目下的交换数据。 4.4.5 数据输出接口 系统将提供数据的多种输出接口,可以导出系统中的原始数据或者加工后的数据,为其他系统提供数据支撑。 系统前端会提供类似Excel导出,文本导出等文件性的数据输出接口,供人工使用。 系统也会提供应用方数据库直接写入功能,操作人员在本系统提供的web界面上指定其他系统的数据库连接方式后,可以定制数据推送任务,直接写入其他系统数据库。 应用端会提供FTP文件输出或其他数据输出渠道,供其他第三方软件调用。 数据库端也可通过权限配置开放给其他系统进行dblink直连,达到数据输出的目的。 4.4.6 对于异地数据交换的说明 由于系统是省,地市,区县,三级节点式部署,系统并不显式的提供同级部署之间的互相访问和数据利用,也就是说两个地市级的节点之间不存在系统级别的互相访问,但实际情况中会有需要采用异地数据来进行工作的需要。如何来实现异地数据之间的交换和利用,这里分两种情况: 1、上级节点中考虑了这部分数据的交换,比如常州和无锡需要进行某一项数据的交换利用,而这一项数据的交换是通过省级部署来实现的,那么常州要利用无锡的数据只需要省局开放相应的数据访问权限即可实现数据的异地访问。 2、上级节点中未考虑数据的交换,我们可以利用系统的数据输出接口和交换功能来实现数据的异地交换。例如,常州将这部分数据通过数据输出接口导出,然后在无锡新建交换项目,将这部分数据导入即可,如网络条件允许,甚至可以做到自动交换。 4.4.7 成果展示 本功能主要提供系统应用成果的全面展示,分为两部分: 1、 系统自动生成或采集的交换情况 2、 人工录入的数据应用成果 4.4.7.1 系统自动生成或采集的交换情况 【功能描述】 系统自动生成或采集的交换情况,加工情况一览。通过此功能,可以看到系统共建立了多少交换项目,每个交换项目交换了多少数据,交换频率如何,数据匹配情况,匹配了多少数据,自动匹配了多少,手动匹配了多少,匹配率如何。如果系统存在下级部署的节点,则还能监控下级节点的数据交换,加工和应用情况。方便上级机关及时了解下级的数据交换和利用情况。 【查询条件】 无 【查询结果】 汇总表形式展示各层级交换项目数量,向下钻取,查看该层级具体的交换项目情况,显示交换项目名称,交换部门,交换数据量,交换频率,交换数据量,自动匹配记录数,手工匹配记录数,匹配率 4.4.7.2 人工录入的数据应用成果 【功能描述】 由使用人员录入其他一些通过此系统进行数据应用方面的成果,并加以展示。分为,数据成果录入和成果展示 【成果录入】 手工选择交换项目名称,录入应用内容,应用成果。 【成果展示】 查询展示录入的应用成果。 4.4.8数据利用反馈展现 本功能主要提供数据利用反馈的全面展示,这里分为两部分描述: 1、 数据利用反馈方式 2、 数据利用反馈的报表查询 4.4.8.1 数据利用反馈方式 【功能描述】 数据利用反馈主要是指的由本系统加工好的数据在其他系统中的使用情况反馈。在功能设计上,我们提出两种方案,可供选择: 1、 接口回写方式 系统暴露利用反馈的接口,所有的利用反馈相关数据都在外部系统(风险管理平台)中生成,以一定周期回写数据到本系统。 2、人工录入方式 系统提供利用反馈信息采集web界面,以供数据使用者以人工录入的方式填写反馈信息。 4.4.8.2 数据利用反馈报表查询 【功能描述】 数据利用反馈的综合展现 【查询条件】 交换项目名称(可模糊),数据来源部门 4.5 数据上传下发 4.5.1 数据上传 【功能描述】 市级交换平台系统向省级交换平台上传交换项目数据,以及定时上传市级平台使用情况统计信息等。 【说明】 系统采用省级、市级二级节点部署方案,省级节点无法直接访问到市级节点的数据,但是在实际的工作过程中,省级需要查看市级节点的系统利用率,以及利用情况等等。数据上传是由市级节点主动发起,向省级节点上传本节点交换项目的统计信息,以及整个节点平台交换项目数量,匹配情况等。 4.5.2 数据下发 【功能描述】 省级交换平台向市级交换平台以交换项目为单位下发该交换项目的原始数据或最终比对好的数据。 【说明】 有些交换项目是由省级创建,并且原始数据是通过省级才能采集到,但数据真正的利用者却是市级的管理员。省级的管理员可以统一匹配好数据,把匹配完的最终数据下发给各个市级节点。如果全省数据过于庞大,管理员可直接按照地市分割数据下发,有市级节点去匹配数据。 4.5.3系统全景图查询 【功能描述】 查询系统所有下级节点统计信息(交换项数量、已导入的交换项数量、已匹配的交换项目数量)列表。 【说明】 此功能省级和市级实现略有不同,省级先显示所有下级节点统计信息,然后展开查询每个子节点的所有交换项目列表,列表各项包括该交换项目状态,已匹配了多少条、未匹配多少条、数据合格率等等。市级直接显示本节点的所有交换项目列表。 4.6 系统设置和管理部分 4.6.1 层级管理 系统分为省,地市等多层部署,各级部署相对独立,上级可对下级的交换情况进行监控,但不参与管理,按照这样的思路,系统层级设置包含: 1、 系统级别设置(省级,地市级,区县级),以及系统隶属的税务机关设置。 2、 上级应用服务器设置,由于系统相对独立部署,因此下级服务器需要设置上级服务器信息,以便信息上报,实现集中监控。 4.6.1.1 系统级别设置 【功能描述】 设置本应用部署所在层级,和隶属的税务机关 【操作】 选择应用部署所在层级(省级,地市级,区县级) 选择系统所属税务机关(输入代码跳出,或选择) 4.6.1.2 上级应用服务器设置 【功能描述】 设置顶端服务器信息,从顶端服务器读取应用树之后,设置本级部署的上级服务器 【操作】 设置顶端服务器信息,即数据库IP,端口,设置完成后系统将自动从顶端服务器获取应用树。 然后从应用树上选择本级部署的上级服务器,设置完上级服务器后,系统将自动将本级部署信息传至上级服务器,再逐级汇总到顶端服务器,更新应用树。 4.6.2 岗位设置 【功能描述】 一个岗位应该是包含一种或一种以上的角色。系统提供岗位管理界面,用于管理用户功能权限。 【用户创建和管理】 主要用来设置系统的操作人员,工号,姓名,登录口令,所在税务机关,所属岗位(可复选),是否启用等。 【岗位创建和管理】 系统提供岗位定制界面,选择相应菜单保存即可。然后和操作人员对应的方式来进行处理,也就是系统通过设置岗位这一权限概念,将零散的功能点权限进行分组,然后为操作人员定义岗位,从而实现操作人员和系统功能权限的对应。 4.6.3 权限管理 【功能描述】 权限管理部分首先是人员的管理,然后在系统级别上分为功能权限管理和数据权限管理。功能权限主要针对各类前端的操作功能,数据权限主要针对交换和加工数据的查询和访问。 功能权限的机制即采用岗位设置来控制,上一节已对岗位设置详细介绍。 数据权限管理设置操作人员可以操作的数据权限级别。数据权限分为两部分,一部分是数据的层级权限,例如某操作人员是属于金坛市的,那么他的数据访问层级默认也就在金坛市范围,超出此范围的数据,他是没有办法查到的;另一部分是数据访问权限,访问权限和数据的安全按级别有关,根据数据的安全级别,我们把数据分为核心机密数据,敏感信息数据和公共数据三类,例如系统和某部门进行了一些敏感信息数据的交换,这些数据原则上是保密的,可以对这部分数据进行数据访问权限的设置,未达访问权限的人员是无法访问这部分数据,同时,这一权限也扩展到数据字典的查询,如果没有这部分数据的查询权限,则同样没有这部分数据的数据字典的查询权限。 4.6.4 代码表设置 【功能描述】 设置系统使用的相关代码表,如交换部门设置,等等。 4.6.5 交换项目设置备份和恢复 【功能描述】 查询符合条件的交换项目列表,并可向下钻取查询具体交换项目的设置情况,并可将具体设置情况逐个导出或批量导出进行备份。 可将导出的交换项目设置导入系统进行恢复。 【查询条件】 交换项目名称(可模糊),交换部门 【说明】 查询结果受操作人员权限影响。

下载文档到电脑,查找使用更方便

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享文档获得金币 ] 3 人已下载

下载文档