金税三期工程省级应用集中优化实施计划方案

1、 .金税三期工程省级应用集中优化实施方案一、概述根据总局税收信息化工作领导小组进一步推进和优化金税三期工程的要求，优化实施工作组组织金税三期架构组、业务组、蒙、六省市试点单位国地税局和省地税局，中软公司、神州数码公司、甲骨文公司、税友公司、方欣公司和中创公司等各项目组共132人，于2014年2月9日至2月22日在省地税局桃源楼南海税务信息处理中心集中工作，研究金税三期省级应用集中和全国数据集中实施方案。本次会议分为总体组、数据组、关键技术组、用户体验组、系统部署和运维组，通过反复研究，形成了总体优化实施意见。金税三期优化实施阶段将根据金税三期省级应用集术分析报告中提出的优化建议，充分考虑风险性

2、、合理性和前瞻性等方面的因素，优化调整现在的全国统一集中部署方案为省级集中部署方案，调整项目的架构、解决现存问题、分析管控省级集中过程中的重点问题并根据总局的时间要求在年底实现3+2省市的上线工作。同时严格监管优化实施阶段的工程质量、流程，强化甲方项目管控能力，规避质量风险，保证时间进度，控制项目成本。二、优化原则（一）总体原则1.遵循金税三期的架构规和标准，并根据省级应用集中和总局数据大集中的需要进行优化调整。2. 金税三期必须成为一个整体进行优化，不同的子项目不能够各自为政、画地为牢。优化工作需要进一步明确各子项目在总体架构中的位置和职责，按总体架构要求进行子项目的设计开发工作。3. 简化

3、金税三期目前过于复杂的体系结构，对各系统的应用分布和数据库分布进行合理化归并，最大程度地提高金税三期系统的稳定性。4. 以税务基层工作人员和纳税人的体验为优化重点，重点关注系统的易用性和稳定性。5. 严格管控数据规，同时充分考虑各地业务的差异，适度放开业务流程限制。（二）应用架构方面1. 优化金税三期应用集成设计，全面采用服务化的集成手段。2. 各项目边界合理归位，遵循“高聚、低耦合”的应用设计基本原则，调整应用分布与功能边界，简化核心征管系统核心部分，提供模块插件化接入服务。3. 主要税收业务都必须提供补偿业务。4. 简化系统初始化配置的复杂程度，降低上线和运维的难度。（三）数据架构方面1.

4、 对金税三期的数据结构进行重新梳理设计和全面优化，建立全国统一的规数据模型，纳入总局统一的配置管理，并由甲方严格管控数据结构的变化和数据库的日常维护。2. 简化金税三期工程的数据链路，原则上生产系统只保留一份数据，如果需要增加副本，必须经过充分论证。3. 金税三期各系统必须将所有数据全部结构化并存放在生产数据库中，不能仅以XML文件进行存放。XML结构化一般情况下实时处理，大数据量XML文件可异步处理。生产系统以结构化数据为主要处理对象，XML文件作为原始凭证按照电子档案管理规的要求进行流转和保存。4. 在核心征管系统中恢复必要的查询功能，以实现操作员可以完整查询到自己录入的数据。三、应用架构

5、（一）调整容1. 完善总局、省局应用部署模式，对于交互频度高、直接与纳税人发生联系的业务在省局集中处理，总局根据管理和决策的需要采取存储、调用等各种方法分类处理数据集中需求。调整完成后，管理决策系统、外部信息交换系统、业务工作门户、应用集成平台、数据交换平台、IA系统和行政管理平台两级部署，其他应用系统部署在省局。2. 总局和省局之间通过异步数据交换的方式实现数据共享。省局国地税分开部署，国地税间实时交互通过应用集成平台实现，批量数据通过外部信息交换平台实现。3. 优化应用集成设计，合并目前架构中的税库银前置（核心征管自建）、应用集成平台、遗留前置、核心征管前置和个税前置，统一为面向渠道服务的

6、应用集成平台和面向部应用系统间服务的应用集成平台。应用系统间的集成优先采用服务方式。4. 核心征管系统增加查询功能，提供生产类查询。5. 前置系统不再作为单独系统考虑，作为核心征管或个税部部件合并部署。6. 大厅系统不再作为单独系统考虑，分别归并到核心征管和个税合并部署。7. 原跨层级数据交换平台改名为数据交换平台，为可选系统，可根据实际业务选择跨层数据交换平台、GoldenGate、ETL等交换平台工具。（二）省级集中应用架构设计应用架构的优化建议如下图所示，包含金税三期的总体应用架构和核心征管系统应用架构。图3.1 金税三期总体应用架构图（三）部署模型以下为金税三期系统部署模型。1.总局部

7、署模型图3.2 总局部署模型2.省局部署模型图3.3 省局部署模型四、集成架构（一）应用系统之间关系1. 金税三期各新建系统之间的关系（1）决策1包1）各省可根据本省实际情况选择以生产库或者分发库作为数据源向决策1包同步生产数据，投放数据中应包含代码和权限等数据。同时对同步数据实施Oracle 系统级增量识别方案，即实施OGG三个增量识别字段，以便于决策系统进行增量数据识别。2）在税收核算方面，决策一包采用核心征管数据直接进行核算，为避免核算加工影响核心征管前台应用，可以采用同一数据库不同用户的方式访问核心征管数据。为满足实时核算的需求（由基层用户决定核算启动的时间）和提高核算加工的效率要求，

8、需要核心征管在涉与核算的相关业务表中，对每一类业务日期同步增加记账用和归集用两类字段，以满足核算的需要。（2）个税系统核心征管和个税的边界切分需要考虑法人和自然人两类纳税主体，同时兼顾后续税制改革的前瞻性变化，技术实现的“高聚低耦合”和用户体验。房产税、契税、车船税等业务拥有一致的业务流程和业务管理规定，法人和自然人仅仅作为两类纳税主体，因此该部分业务建议保持现状。开票、退税、票证等征收业务，需要和外围系统如TIPS、POS、银行端查询缴税等紧密衔接，同时也要和销号、国库对帐、会计核算等紧密衔接，不宜单独作为一部分进行切分，因此该部分业务也建议保持现状。按照这种模式，从技术上可以保障税制改革的

9、前瞻性变化，同时核心征管系统和个税系统的业务边界切分在现状的基础上只需要做细微的调整，实现了高聚低耦合，确保了系统的稳定性和用户的良好体验。（3）纳税服务系统1）省局数据集中后，对于纳税服务系统需要的部分实时性要求不高的数据查询接口和数据需求，改为直接由纳税服务系统直接访问省局查询库，减少纳税服务系统对其他系统的依赖性和耦合度。2）核心征管系统向纳税服务系统提供的接口服务应以实时接口为主，尽量改进用户体验；3）由网络发票系统在各省部署的前置系统提供异地发票查验向的全国路由；2. 金税三期新建系统和总局保留软件之间的关系；在金税三期与保留软件进行数据同步时提供缓存机制或者增加日志，方便日后对账；

10、同时改进数据提取方式，如：发票验旧业务等。3. 金税三期和各省特色软件之间的关系。金三系统为各省特色软件提供其所需的业务接口，特色软件依照金三接口规进行本地特色软件改造，通过应用集成平台（渠道）访问金三系统提供的接口服务。各省特色软件可通过访问本省查询库实现特色软件查询类需求。（二）各省国地税应用之间关系国地税之间网络连通，实现数据共享。对于国地税之间需要数据交换的情况，由一方完成业务办理后，采用数据交换的方式同步到另外一方。（三）总局业务和省局应用之间关系对于各省需要总局参与办理的业务，由业务组再征求总局各业务司的意见，根据总局各司局的回复意见进行处理，有需要再进行部署。（四）跨省应用各省涉

11、与跨省业务的数据，在完成本地保存的同时通过异步方式上传到总局，使用方明确的数据由总局直接转发到对应省局；使用方不明确或不固定的，在总局建表保存，并由总局提供实时数据服务。五、服务体系描述（一）服务架构图描述规金税三期省级集中系统全面采用服务化的集成手段，其中，核心征管系统服务体系架构见下图。1. 应用集成关系说明纳税服务系统、省级特色软件等渠道系统通过相应的协议，接入到应用集成平台（渠道）。应用集成平台（渠道）负责将各应用系统的接口服务注册到该平台上。应用集成平台（渠道）通过E协议直接调用核心征管系统的接口服务。个税系统、外部交换系统、税库银系统和应用集成平台（部）的关系类似。应用集成平台（部

12、）通过相关协议，与总局集成平台交互，完成跨省业务协作。100 / 100图5.1 核心征管系统服务架构图2. 应用集成平台功能说明应用集成平台核心功能组成如下图。图5.2 应用集成平台核心功能主要功能有通讯协议适配、流量控制、消息格式转换和系统接入管理、服务管理、交易路由和交易流水等。通讯协议适配支持应用集成平台各种标准协议适配接入，如：WebService、E、JMS、MQ、Hessian、FTP等，并且能够支持自定义开发适配器的方式来实现各种系统的集成整合。流量控制：支持按系统和按服务的流量设置和控制，防止系统的高并发请求和隔离系统故障。接入系统管理：应用集成平台面对多种不同的系统，提供统

13、一的接入管理机制，提供系统和服务的统一接入、注册与策略管理，支持同步/异步方式的接入，能够控制不同系统和服务的访问权限。交易路由：应用集成平台提供完备的路由机制，提供路由策略的配置、路由服务的查找与调用，支持自定义路由参数(包括地域、系统、交易以与各类自定义业务参数等）和规则的路由机制。应用集成平台置的路由策略包括：按机关匹配、全匹配、任意、正则表达式、匹配开头。服务管理：应用集成平台提供服务的统一注册、管理和运行时调度以与出现时的统一管理。交易流水管理：应用集成平台提供交易流水的采集、存储、检索等功能。提供对各类交易执行流水信息的记录、监控与管理，能够完整的记录一笔业务的各类关键性执行线索信

14、息，从而为冲证与对账提供依据。管理监控：应用集成平台支持用户监控交易处理情况，根据交易流水监控当前服务交易情况，与时处理和发现各种异常。（二）服务设计原则1. 跨应用系统的所有服务都应发布在应用集成平台上，应用系统间不得直接互相调用；2. 服务的职责应划分清晰，做到“高聚、松耦合”；3. 服务的粒度应适中，有利于保持稳定。4. 服务必须是无状态的。5应用系统部使用和对外提供的服务要保持一致，采用一样的服务接口。（三）服务接口描述规各系统提供的服务接口应提供详尽的文档说明，说明容遵循如下规：服务整体按树状层级展现，建议分两层目录，第一层目录按业务域进行分类，第二层目录为具体的服务中文名称，然后就

15、是每个服务重要属性的描述。示例如下：登记接口服务自然人信息查询服务IDC00.SB.ZRRXXCX.GSCX.zrrxxcx服务中文名称自然人信息查询输入登记序号输出自然人、自然人件种类代码、自然人件、登记序号、性别、居住地址、联系服务功能描述根据纳税人识别号查询自然人信息，此服务通过调用个税系统提供的远程服务实现事务处理说明xxx异常处理说明xxx灵活就业人员银行信息查询服务IDC00.DJ.YHXX.ZGCX.getYhxx服务中文名称灵活就业人员银行信息查询输入登记序号输出社保经办机构、社保编码、银行行别代码、银行营业网点代码、银行账号服务功能描述根据登记序号查询灵活就业人员的银行明细信

16、息事务处理说明xxx异常处理说明xxx申报接口服务纳服申报状态查询服务IDC00.SB.SBTY.ZGCZ.nfsbztcx服务中文名称纳服申报状态查询输入djxh登记序号，skss 税款所属期起，skssqz税款所属期止，yzpzzlDm应征凭证种类输出sbztDm申报状态代码，sbfs申报方式，djxh登记序号，skss 税款所属期起，skssqz税款所属期止，zsxmDm征收项目，zspmDm征收品目，yzpzzlDm应征凭证种类，swjgDm税务机关服务功能描述外围厂商如网报查询某笔申报的当前状态（状态包括：未申报、申报已缴款、申报未缴款、申报已作废等），实际业务逻辑通过调用核心征管专

17、有业务服务PDS_NSFW001_getNfsbztcx实现。事务处理说明xxx异常处理说明xxx六、数据架构（一）调整容1. 对金税三期各系统目前的数据库进行合并，同时逻辑上要保持各业务域的独立。2. 在省级设立生产库、查询库、分发库、集成平台库和决策支持库，由分发库负责向总局、各地市和本级数据仓库提供数据。原则上在省国、地税局各只建立一个分发库。3. 重新梳理主数据容，取消主数据数据库。4. 调整应用系统间的数据共享策略，单笔或小量的数据共享以服务为主，实施数据消费保障方案；批量数据的共享需求在满足数据一致性和实时性的要求，综合考虑更新频度、访问频度、数据量和实时性等因素，采用合适的技术手

18、段实现。5. 总局部署“组织和自然人数据库”（合并在总局集成平台库中），主要采用异步方式处理跨省业务。（二）省级集中数据架构设计数据架构的优化建议如下图所示，其中包含金税三期的总体数据架构和核心征管系统数据架构。图6.1 金税三期总体数据架构图图6.2 金税三期总体数据流向图（三）数据模型（ER图）设计要求1. 数据模型设计文档包括数据库概要设计文档、使用Powerdisgner或DataModel软件的模型文档和数据字典等三个部分。模型文档与数据字典要同步维护，与时更新。2. 数据表、数据项的命名应符合金税三期标准规则，与业务术语名称保持一致性，表名称、数据项名称应保持可读性。3. 同一数据

19、项出现在不同表中，数据项的属性如类型、长度等应保持一致性。4. 数据结构设计原则上要满足遵循第三式要求，只有在为了提高程序效率情况下适当考虑冗余。七、重点关注的关键技术问题（一）核心框架方面1现状和问题分析金税三期核心征管软件服务器端基于中软Sword平台中的核心框架开发实现。核心框架采用J2EE技术开发，涵盖了系统服务器端开发的各个方面，提供了各种功能组件，使开发者尽可能少的考虑底层技术问题，将更多的精力放在业务功能的开发上。核心框架的功能、性能和开发规性直接决定了金税三期核心征管软件的性能、稳定性、可靠性和用户体验。从目前已上线单位的反映和双轨测试环境实际体验来看，金税三期的核心框架还存在

20、一些不足。以下是存在的问题与对应的原因分析：（1）稳定性和健壮性方面1）持久层缺少执行超时时间、结果集最大记录条数等默认参数设置，如个别业务逻辑的SQL性能较差，如果未设置执行超时，可能会引发系统大面积阻塞和宕机。2）框架部缺少安全性检查机制。如缓存组件的注销方法现允许未经授权的代码调用，应实施调用安全性检查。3）缺少终止指定会话的机制。如当某管辖大量纳税人的税务机关进行批量申报操作造成服务器压力过大时，运维人员无法终止该请求的执行，造成其他业务无常运行。4）跨域调用故障定位困难。如发票发售业务中发票域需调用申报域提供的已申报校验服务，但因为执行日志分散在各运行实例中，跨域调用故障问题的定位比

21、较困难。（2）性能优化方面1）框架层面的执行性能可进一步优化。如申报计税业务会多次通过部服务管理器调用其他基础业务服务（计算申报期限和缴款期限等），框架功能会有一定的性能消耗，存在进一步压缩空间。2）依赖数据库实现业务逻辑中的状态检查。如目前税款征收业务每次进行扣款操作前均需查询数据库以检查纳税人是否签署了三方协议，增加了数据库压力。3）依赖数据库实现业务的操作互斥检查。如征收开票前的锁票动作是通过检查数据库指定表中的相关记录状态信息实现，增加了数据库压力且性能较差。（3）项目管控方面1）部分业务逻辑的实现代码质量不佳，性能较差，资源占用过多，此类代码发布到生产环境容易引发故障。如部分开发人员

22、编写的SQL执行效率较差，曾引发数据库资源占用过高问题。主要是由代码审查不足，测试不充分引起。2）用例设计评审不充分，不能正确使用框架提供的功能。如部分批量数据处理使用循环方式，未使用框架的并行处理方式。2调整目标核心框架是金税三期核心征管软件的基础，通过对现存问题的分析，在保证系统正确性和稳定性的前提下，有必要对核心框架的组件进行完善，为业务系统提供必要的功能，不断提高系统的稳定性和健壮性，优化系统性能，提升用户体验。3优化方案为了达到以上目标，解决目前核心框架存在的各种不足，采用以下调整方案：（1）稳定性和健壮性方面1）在持久层增加关键参数默认值配置增加执行超时的默认配置，各应用域根据自身

23、业务特点配置默认的执行超时时间，同时提供手工设置超时时间以满足复杂查询需执行较长时间的需求。提供结果集最大记录行数默认参数，各应用域根据自身业务特点设置允许最大结果集行数参数，在结果集处理过程中检查结果是否超过设置值；同时提供手工设置该参数以满足类似大数据导出记录行数较多的需求。2）优化核心框架部基础对象访问方式和调用机制调整框架部运行依赖的基础信息对象的访问方式，调整对象结构和可见性围，保证只有合规的逻辑可以访问相关对象。增加Java安全策略配置，保证系统调用安全性。在关键系统功能中增加调用检查点，且支持配置开或关。3）提供终止指定会话的机制提供会话执行跟踪机制：框架收集会话执行服务器的路径

24、和执行线程信息。提供会话运行终止功能：根据会话的相关执行信息，查找运行指定会话的服务器与执行线程，并向执行线程发送终止执行的控制消息。框架相关功能组件中增加执行状态检查功能，根据执行线程接收到的控制消息，判断是否终止执行。4）完善日志组件执行日志采集异步化：采用异步方式采集执行日志，保证执行日志数据的采集动作对业务运行影响最小化。执行日志存储异步化：根据执行日志数据库的产品特性，采用异步化的方式持久化调用日志数据，如MongoDB数据的异步写入功能。与运维管理系统结合，联合完成跨应用的综合分析定位。（2）性能优化方面1）优化部服务组件优化部服务注册表的查询机制，如使用更优化的Hash算法替代J

25、ava默认实现方式以提高查找效率。优化部服务调用机制，如优化ASM生成的动态服务代理类代码质量。根据环境配置信息，动态整合服务的拦截处理方法和服务调用方法，将解析调用转为按需硬调用。优化服务版本化管理机制，目前不同版本的服务注册成不同的服务条目，造成服务条目过多，应采用适当机制缩减部服务的条目数量，提高服务查找和管理性能。2）提供状态缓存服务组件提供状态数据管理平台，通过算法将数据库中的相关状态数据映射到应用服务器的存状态位上。提供状态数据访问客户端，业务逻辑调用功能客户端访问和更新状态数据缓存中的状态信息。3）提供应用级锁管理组件提供锁管理服务器，用于应用层的锁信息存储，并提供锁的检查和管理

26、功能。提供锁数据访问客户端，用于业务逻辑与锁服务器进行通讯。（3）项目管控方面1）框架开发者提供详细的开发指导手册，加强开发人员的技术培训，保证开发人员能正确使用框架提供的功能；提供代码扫描工具，提高代码质量。2）完善代码审查制度，强化制度落实与执行。3）加强软件测试，提高自动化测试的覆盖率，同时加强边界测试。（二）应用集成平台方面1现状和问题分析在省级应用集中，应用集成平台定位在既要承担金三部系统之间的应用集成，同时还要承担各省的渠道系统接入到部系统的应用集成（原来是由前置软件负责），在总局和各省局国地税也要分别部署，这将对应用集成平台的功能性、可靠性、稳定性提出了更高的要求。应用集成平台采

27、用服务代理模式，不部署业务服务，业务服务部署在提供服务的系统上，应用集成平台作为代理负责转发业务服务请求，所提供服务的业务逻辑由提供服务的系统执行。而服务容器是指将业务逻辑处理部分封装为独立的服务部署在应用集成平台上，应用集成平台可作为服务容器直接接收并执行服务。目前，应用集成平台采用服务代理模式，实现了平台与业务逻辑的解耦，业务逻辑变化和部署不影响平台，平台轻量，不直接处理业务逻辑。在目前的全国应用集中，在总局部署了一套应用集成平台，它提供总局新建系统间的应用集成，如征管和个税、纳服和征管的待办事宜集成、征管和网络发票；在各省国税和地税也分别部署了一套应用集成平台，负责提供省特色系统和总局遗

28、留系统接入到核心征管的应用集成。另外，核心前置也部署在总局，承担了纳服、税库银等渠道软件的应用接入；而部署在各省局国地税的核心前置负责国地税大厅的应用接入；这些核心前置和应用集成平台的本身功能差不多，只是接入系统与其服务不一样，并且在核心前置上部署了业务预处理服务。从目前3个已上线省市的应用来看，并基于省级应用集中的考虑，应用集成平台在如下几个方面存在不足：（1）异常故障性保障和隔离：在出现异常时的处理和故障隔离还需要完善。1）异常处理机制：目前对于JMS消息处理方式，如果在目标系统网络一直出现异常故障下，JMS消息会一直连续发送到目标系统，这会无故消耗系统资源，可能会影响系统其他业务运行。2

29、）故障保障隔离：在E/WebSerivce等同步模式下，目前的流量控制在线程数足够时可以起到故障隔离，如果高并发服务请求过多导致线程不足而服务处理很慢时，这时可能会造成系统堵塞，并且由于缺少服务优先级控制，可能会导致高优先级业务服务也无法处理。（2）界面化配置：目前应用集成平台的参数配置基本上都是通过DML数据库脚本在系统升级或打补丁时执行生效，而没有提供界面在生产环境由系统管理员进行配置。1）静态参数配置：虽然很多静态参数作为版本信息是可以通过DML脚本进行初始化配置，但有些静态参数可能在具体环境有差异，这就最好需要提供界面来配置，如：各种协议的IP端口地址等信息。2）动态参数配置：对于需要

30、根据系统运行情况调整的参数，目前也是通过DML脚本执行，如流量配置、接入配置等。（3）扩展性功能：目前业务需求功能的变化，完全是由服务具体来实现，应用集成平台没有提供服务编排等功能，这样就无法实现只需平台级的定制而无需业务服务变化修改。同时，作为服务提供系统方和服务消费系统方，在使用应用集成平台方面以与各方相互协作配合方面，主要出现如下的问题：（1）规性：在应用集成平台规还不是很完善和执行协调不到位。1）服务梳理划分：服务划分太细会造成交互频繁，增加系统压力。2）超时控制：未结合征管与其他接入系统的整个链路时间进行配置，易出现系统间配置参数不匹配而引起的服务异常，如网报系统配置超时时间为5S，

31、征管系统配置超时时间为10S，应用集成平台配置超时时间为30S，此种情况将出现应用集成平台在征管系统未有正确返回时因超时而断开请求。（2）协同性：在各方系统集成时，由于同时存在前置和应用集成平台，在选择接入时容易困惑；同时选择了不恰当的集成方式和接入方式，比如应该应用集成而使用了数据集成、本地特色应用和渠道系统过多使用异步方式协议、集成调用的次数较多。通过这些问题分析，应用集成平台在功能性、可靠性、稳定性还需要完善，并且还需要加强应用集成平台规的执行完善和各集成方的协调配合。2调整目标（1）简化规应用集成：尽量简化应用集成，规应用集成方式和同步异步接入方式。（2）提高配置易用性：增加灵活配置功

32、能界面，动态满足系统变化要求，如：系统压力大时动态配置流量以限流等。（3）加强故障处理和可靠性：在系统出现异常故障时，应用集成平台需限制系统的故障围而不至于系统故障蔓延，提供系统在可承受压力围正常运行的保障机制，尽量减缓或限制系统压力，同时保障关键服务可被优先执行。如流量控制和优先级控制。（4）增强服务扩展性：在业务发生变化时，应用集成平台可根据已有服务编排组合成新的服务，以动态满足适应业务变化，如增加服务编排功能。3优化方案为了实现上述目标，应用集成平台具体改进措施如下：（1）简化规应用集成渠道系统改为统一接入到应用集成平台，前置软件将去掉。合理选择系统之间的集成方式，特别注意选择好应用集成

33、的同步异步接入方式。（2）故障隔离有两种方案，利用weblogic工作管理器分别控制请求和响应线程数和优先级，或自主研发队列机制增加分组、优先级功能。1）基于weblogic工作管理器定制开发：根据业务需求预先在工作管理器中定义不同的线程组，来自不同渠道、针对不同服务的请求会使用不同的线程组，同时对后面不同系统的服务的调用也使用不同的线程组。使任何服务的拥堵不会蔓延。优点：技术明确，风险可控；工作量可控，通过配置+资源适配器的定制开发。缺点：使用weblogic优先级的应用案例不多，需要验证具体使用策略；和weblogic耦合紧密，完全依赖weblogic；服务请求方发起请求时须指定业务组件实

34、例的级别。2）自主研发队列机制增加分组和优先级处理：通过队列和连接适配器控制服务在请求和响应按照不同分组和不同级别执行。优点：完全自主，按照JCA规；服务请求方无需关心优先级，通过应用集成平台本身配置实现。缺点：技术上有难度，存在技术风险；工作量大，需要保障稳定性和性能。建议先采用方案1过渡，最终过渡为方案2。（3）配置管理完善超时配置功能界面等，完善现有功能界面。增加流量配置功能界面等，根据需求增加功能界面。（4）服务监控完善服务的运行状态、运行效率、运行是否有错误等的监控。若有问题与时告警，降低运维压力。（5）服务编排针对现有服务提供XML报文容的输入输出处理，也能够把多个服务按照一定规则

35、串接组合起来。编排后的服务作为一个新的服务暴露出来，且对原来的服务代码无须修改。应用集成平台需支持服务编排功能，但是此功能实现优先级低，在遇到有需要业务场景时使用。除了上述应用集成平台具体改进措施，还需要加强应用集成平台规的执行完善和各集成方的协调配合。（1）需要不断完善和遵照执行的应用集成平台规有：1）GT3-HX-ZJ-应用集成平台接口规2）GT3-HX-ZJ-应用集成平台接入规3）GT3-HX-ZJ-应用集成平台数据定义规4）GT3-HX-ZJ-应用集成平台数据交换规（2）各业务系统需要对服务高度抽象梳理，对各种系统消费方提供的服务尽量保持一致，并尽量减少系统之间减少次数。（3）各方协调

36、配置好超时时间。（三）工作流方面1. 存在问题工作流系统是金税三期基础软件平台中的重要组成部分。金税三期系统采用了中创公司提供的工作流软件InforSuite Flow，该软件已在多个大型信息系统项目中应用，它是遵循WFMC规、支持采用XPDL形式XML进行流程定义的工作流中间件，为工作流自动化与流程再造提供基础平台，为金税三期工程提供基础的、统一的流程管理平台。该工作流产品结构如图所示：图7.1 InforSuite FS产品架构InforSuite Flow工作流软件提供了统一的BS流程建模平台，可以用于累积业务流程模型，并可便于服用业务模型。流程建模平台功能众多，包含了流程分级定义、下发

37、、逐级个性化扩展定义同一业务流程等特色功能。在金税三期中使用工作流工具的目的是增强征管系统的适应性，有效支持业务由职能导向转变为流程导向，由结果监督转变为过程监督。工作流软件被用于支撑金税三期工程核心征管、个税、行政办公、纳税服务、管理决策等多个项目，各项目对InforSuite Flow工作流软件进行了集成，并分别对工具相关功能进行了封装或个性化扩展，构建了各自的工作流框架。目前核心征管系统的各个应用域分别有对应的工作流域，工作流域主要涵盖了工作流服务框架与工作流引擎和工作流数据库。简单来说，核心征管系统的工作流的部署方式是“多实例多数据库”。个人税收管理系统则采用了“多实例单数据库”的工作

38、流部署方式，个税系统各应用域嵌了工作流服务框架与工作流引擎，但共享一个数据库。图7.2 金税三期核心征管系统工作流架构概要示意图金税三期系统用户最常用的功能就是打开待办任务列表或在办任务列表，在办理流程性事务时大量的使用到推送功能，而这两者都是由工作流系统来承载、实现的，对于前台办税的纳税人而言，办事是否便捷、税务机关服务是否高效优质，很大程度上是由工作流框架和工作流引擎的功能、性能和开发规性直接决定的，税务系统部用户的用户体验也与之息息相关。从目前已上线单位的反映和双轨测试环境实际体验来看，目前金税三期工作流系统存在以下突出问题：一是初始化配置特别复杂。当前，工作流配置方面主要存在的问题有三

39、点：一是相关的初始化配置非常复杂，工作量大：初始化配置极为繁琐，耗时很长。金三系统在工作流配置上有着数倍于大集中系统的工作量：流程类工作建模中需要额外维护职能树，工作流节点的角色对应关系、表单路径、回调服务与关联流程等容；非流程类税务事项也需要额外维护角色与税务事项对应关系以与职能树相关的容。整个金三系统的流程类工作流建模工作量复杂度可以表达为如下： O（流程环节节点数职能树数目税务机关岗位数目角色表单路径回调服务关联流程操作机关），对于非流程类事项，其不涉与具体的工作流配置，而是使用特定的角色对应的功能模块进行实现，因此其复杂度同理表达如下： O（非流程类事项数职能树数目税务机关岗位数目角色

40、）；二是因配置而产生的运行出错概率极高，难以在配置时校验配置的合法性，降低了初始化工作的效率；三是排查问题的难度大。初始化工作流的配置工作包含了工作流图绘制以与每个节点的推送规则、标签规则、事件规则、时间期限的配置等工作。二是健壮性不佳，待办事宜可能丢失、延迟，偶有出现事务不完整问题，错误处理机制不完备。在总局集中版本运行期间，遇到过较多的由于JMS消息延时所产生的阻塞问题，造成“待办门户无法与时展现待办任务、甚至一直收不到”，或者是“待办任务点击异常后任务消失或者仍然存在，再次点击仍然异常”、“在流程监控能看到某任务，但在待办事宜中却找不到对应任务”等现象；发生过一次点击后，业务数据、流程数

41、据处理结果不一致的情况，且错误处理机制未能与时解决此类事务不一致的问题。三是易用性不佳，部分功能不人性化。部分单位的同一部门、同一岗位的人员数量较多（下属区局的大厅集中办公，约有几百人），推送时选择下一环节办理人员时需拖拽查找，无法通过输入拼音首字母或税务人员代码来快速定位；部分流程结束后，系统自动触发了关联流程，此时，无法手工选择关联流程推送人员。四是部分功能缺失，或尚待改进完善。未实现批量审批，例如出口退税，影响基层工作效率；当操作员离职转岗且未办结当前任务时，缺少功能来进行转办，亦缺少相应监控预警功能；缺少流程图反向查找功能，当流程图配置好发布以后，目前没有一个好的功能来查询某流程图的原

42、始流程图存在于BS设计器中何处，以方便检索、基于原流程图进行修改；未能实现流程定义在不同系统环境和不同上线单位之间的导入和导出；跨系统定制流程图支持度不高，目前金三新建系统采用统一的建模工具建模并制作相关规则，再为其他系统进行数据同步，由于在引擎的流程图模型管理中针对建模库无实例数据的流程图采用的是覆盖操作，会导致目标方流程图的历史版本丢失，需要引擎解决；流程分支变量配置不便，绘制流程图时，往往需要用到分支变量，但目前对业务用例的参数管理不够，会导致绘制时不知道哪些参数在当前业务流程中可以使用，也不知道该如何使用；缺少供核心以外的应用系统发布工作流程模型的应用功能；缺少融合查询功能，因目前工作

43、流系统是多应用、多数据库实例部署，操作员无法便捷的查找到可能分散在不同应用域的某个流程之状态，无法在单一功能里实现各应用域流程的统一查询与管理，增加了操作员的负担、增加了引起误解的可能。五是职责分工不合理；文档材料不完备，系统出现过宕机事故，管理方面存在不足。初始化建模工作量大且复杂，较难配置，从现实出发，要明确划分乙方公司与省级以下用户之间的职责围；各乙方公司未给出回调服务、关联流程等工作流配置的完整说明文档；2014年1月出现过工作流系统宕机的情况.通过对典型业务场景的分析，工作流系统的稳定性、功能性和易用性问题对目前金税三期应用系统的外部用户体验造成了不小的影响。在省级集中部署后，这个问

44、题会更加突出。省级集中并不能自动的同时解决系统的稳定性、功能性和易用性等问题。在我们对金税三期各应用系统和数据库简化合并部署的前提下，减少了系统间的耦合度，可能可以提升部分方面的性能，但稳定性问题、功能性问题和易用性问题将更加突出。2. 原因分析通过分析，造成前述问题的主要原因有以下三方面：一是技术方面。（1）待办事宜的集成方式复杂。金税三期系统的待办事宜的集成选择了“推”模式，各应用系统将待办任务推送给工作门户。选择这种方案的初衷在于用户体验比较好。具体技术实现时，首先由总局部署的工作流引擎发起推送待办的事件，然后工作流框架将其转换为JMS消息，发送到ESB，然后传递到省级集成平台，最后落地

45、到省级集成平台库，由门户来进行展现。产生JMS消息延时并导致待办信息无法与时展现的主要原因有三：异步消息机制存在延迟，有时候消息队列堵塞，造成任务无法在规定时间到达省局门户；网络链路距离长，延时大，网络可能出现丢包；当应用了多JMS队列且先后发出多个有先后顺序要求的JMS消息时，无法保障整体先进先出，目前的实现仅能保证每个队列先进先出。（2）事务完整性保障机制不佳，系统错误处理机制不完善。为保证JMS消息（被推送的任务）的可靠性，目前通过开发待办事宜对账程序将业务工作门户中的待办任务数据与各应用系统工作流数据库数据进行对账，待办事宜对账程序通过E接口调用工作流对账服务的E服务查询应用系统的工作

46、流待办事宜数据，但有效性未得到验证。目前没有完整有效的保障事务完整性的机制，在存在跨域调用时，没有使用JTA、XA数据源、多阶段提交等方式在事中保障事务完整性，也没有构建充足的自动化补偿功能在事后恢复事务完整性。（3）工作流框架和工作流引擎功能不足，未能与时根据需要完善相关功能。二是业务方面。总局的流程规与各上线单位实际操作存在差异，加上厂商和上线单位理解上的差异，导致系统中配置的工作流程过多而且过于复杂。三是实施管理方面。（1）开发配置工作与用户配置工作未能合理划分，导致均需要用户进行配置，增加用户工作量，而且出错率高，效果不好。（2）需求分析存在不足。部分业务需求在实现时，设计出来的逻辑较

47、为复杂，在程序实现时涉与到多次跨域调用，客观上导致未能良好的保证工作流与业务数据的一致性、事务的完整性。（3）业务应用与工作流框架功能分工落实不严，存在个别业务应用没有充分利用工作流框架的功能而自行实现部分工作流功能。3. 调整目标工作流系统的优化直接关系到金税三期主体业务功能的正常运转，关系到构建和谐征纳关系，关系到落实“两个减负”，因此需要重视对系统功能性与非功能性需求（或称质量服务需求）的满足，要做到运行质量（易用性、健壮性、稳定性、效率等）与发展质量（可测试性、可维护性、可扩展性、可伸缩性、兼容性）并重，其中需要特别重视确保系统的健壮性、稳定性，具体目标如下：（1）优化工作流相关功能实

48、现；（2）提升系统运行效率，优化工作流应用架构。（3）增强健壮性，完善错误处理机制；（4）增强易用性，改善用户体验。提供合理的默认值，记忆用户选择，支持全键盘操作等，降低用户的学习和适应难度；（5）增强可维护性，完善配置功能，合理切分工作职责。4. 优化方案为了达到以上目标，解决目前工作流系统存在的各种问题，提升用户体验，需要从技术、业务和管理三方同时采取措施进行调整优化。一是技术方面。（1）优化应用架构以配合工作流的相关工作机制。首先要确定是否继续使用JMS消息传递待办任务。若继续使用，则需设计、完善异步消息完整性、可靠性保障机制并进行稳定性、完整性验证，需要将JMS消息服务器细分, 按业务

49、/区域/消息量等规则部署多个消息服务器，确保消息始终保持发送时的先后顺序；若不保留，则改用实时调用。实时调用的优点在于结构简单、排错简单、可靠性较高且更为可控，任务可以实时在门户展现，缺点在于需要量化的验证性能是否能满足省级集中需求；保留JMS的优缺点基本与实时调用的优缺点相反。其次，可以将工作流引擎库与生产库合并。在生产系统调用工作流引擎API的时候，改为外部传入数据库连接的模式，使得工作流引擎与生产系统保持在一个数据库事务中。这样可以部分的减少事务不一致的可能性，更好的提高外部用户的体验，缺点在于可能对数据库的压力较大，需要进行量化验证。再次，应完善系统对事务不一致的处理机制、提高程序健壮

50、性、完善异常处理能力、完善补偿用例的实现。在功能用例实现时，应遵循的原则如下：事务嵌套、跨应用调用不超过一层。经分析，工作流应用有两种架构部署方案，分述如下：第一种是采用嵌入式，嵌入业务应用工程中，不单独部署。此种选择的风险点有：可能遇到jar包冲突问题；在现有需现方式下，并不能彻底解决事务不一致问题，需测试验证。第二种是仍然采用单独部署工作流域。选择该方案时时，仍然会存在跨域调用。因此，为了保证数据在多个参与的数据源中的一致性,需要用到JTA来控制事务,参与的数据源也需要支持X/Open协议(两阶段提交)。据了解，地税网络发票系统与核心征管系统之间的跨域调用使用了JTA来保证事务一致性，此外

51、国税系统也有应用的案例。该方案有如下两点需要注意：一是JTA分布式事务提交需要框架支持；二是两阶段提交会影响性能，特别是两个事务处理时间比较长的情况下可能会有性能压力，需要进行基准性能测试以确定特定硬件配置条件下是否能满足性能需求；对于跨域调用，除使用JTA来控制事务外，还应开发业务手动补偿用例以与自动化补偿方式，对不一致事务采用补偿机制解决，此方式的风险在于需要开发的补偿用例过多，容易遗漏；并完善后台监控的功能，在发生不一致时，保存完整的不一致现场，以便于后台运维处理。第四，清理工作流域相关的数据同步机制。避免使用数据同步机制来实现少量数据的交互，改为采用实时同步调用方式。可广泛参考目前的省

52、级集中系统的类似场景与其解决方案。 （2）优化工作流框架，包括功能完善、错误处理机制的完善、事务完整性保障机制的完善、配置功能完善。首先是增加模拟运行功能，实现在流程发布之前，流程能够自动模拟运行，减少人工测试工作量。工作流应该可以提供配置验证或提供较为人性化的提示功能，包括：验证主工作流是否配置正确；验证各选项是否配置正确；验证关联选项是否配置正确等。其次是增加工作流配置信息变更、发布、导入导出功能。工作流配置信息变更的维护工作目前需要各单位根据工作流配置变更单进行维护，应开发一个发布功能，可以生成相关sql或者dmp文件，随版本发布各个环境，以此减少配置的工作量、保证与java代码版本的一

53、致性，并减少由于人工维护造成的数据质量问题。再次是提供融合查询功能。无论使用单引擎单数据库、多引擎单数据库或多引擎多数据库的部署方式，均应在门户向用户提供融合查询，一次查询即可查找到各业务域的工作流转情况。第四是建立、完善健壮性自动冲正（补偿）机制。增加自动冲正（补偿）功能，完善、建立自动化的错误、异常处理机制，排除因异常处理不严谨所导致的数据不一致问题，保障业务数据和工作流引擎数据的一致性。第五是完善基础控件，智能化展现操作界面。优化备选人员的显示顺序。可选的方案如下：1）支持历史记忆功能。包括：根据上一次本流程本环节推送时，默认选择上次选择的办理人员。根据历史选择的次数，选择次数较多的排名

54、靠前。2）支持用户设置常用备选人。包括：每个用户在每个流程和环节可以设置常用的备选人，常用备选人排名靠前，如果不设置，则按普通排序。3）支持手工输入人员编号和人员，支持系统默认填充，支持模糊查询。第六是支持无纸化、支持新旧工作流并存、允许操作人员选择关联流程的启动环节之处理人员等。除了上述六点，还需要在架构调整前，按各种候选调整方案编制各种可能引发故障的测试场景，并依此进行充分验证，根据结果进行测试和持续改进，提升其稳定性和效率，并提交评估报告给甲方（总局与省级税务局）供决策。工作流与权限是密不可分的，两者具有天然的相关性，应充分采集各省税务机关关于工作流权限配置方面的意见，兼顾灵活性、特殊性

55、与普遍性，完善、简化工作流权限配置模型。举例而言，至少有两个问题需要完善：一是工作流配置规则中绝对层级判断需要设置为对应的机关与其设部门。对绝对层级判断时，应默认设置为其对应的机关与其设部门。二是机关设部门的权限默认与所属机关保持一致。在工作流配置中，应默认使得机关设部门的权限与所属机关保持一致，如果需要额外调整（部分岗位需要设置为本部门），可允许进行设置修改。相关配置方式应简洁明了。（3）优化工作流引擎。首先是研究工作流引擎与其数据库实例的参数优化。适当的配置工作流引擎与其数据库实例的参数，可以极大的降低工作流操作的平均响应时间、提升吞吐量，对整体性能和用户体验有明显提升。其次是分离工作流数

56、据库里的历史数据与活动数据。参考数据组成果，结合工作流系统实际，制定工作流库历史数据剥离规则和实施策略，确保工作流库性能。 二是业务方面。可以从以下三方面进行调整：（1）清理、拆解复杂的业务流程，重做相关需求分析，简化设计。部分业务需求在分析时，设计出来的逻辑较为复杂，在程序实现时涉与到多次跨域调用，违反了“高聚”、“单一责任”的基本设计原则，客观上导致未能良好的保证工作流与业务数据的一致性、事务的完整性。应对此类特殊的业务需求重新进行需求分析，针对工作流系统的特点进行优化，力求保证需求点实现时的原子性，实现高度功能聚，必要时征求各上线单位的业务意见以对业务需求点进行简化或拆解，从而保证事务完

57、整性、数据一致性。（2）清理工作流的不合理使用。一方面避免人为的增加工作流框架的负担，另一方面也减少可能遇到的问题。应严格界定需要使用工作流的场景。对于“即办类”或“单节点”业务，应避免使用工作流来实现。（3）保持灵活性。在工作流相关的业务设计中，应从全国实际情况出发，保持业务涉与的灵活性。如，部分地市县区局的流程和其他县区局流程不一致，需要重新画，需要将允许自行绘制工作流的最小单位设为县区局。三是管理方面。可以从以下三方面进行调整：（1）完善工作流系统相关的开发、运维制度。首先要建立完善的质量保证制度、变更管理制度和版本控制制度，严格执行流程，切实做好质量保证工作。其次要制定设计、开发、测试规并严格执行。各乙方项目组应参考业界主流的开发规编制、完善适合本项目实际情况的设计、开发、测试规手册并持续改进。在编制过程中应参考的现行软件行业中主要适用的国家标准或行业标准如下：GB/T 8566-2007 信息技术 软件生存周期过程 SJ/T 11375-2007 软件构