金稅三期工程省級應用集中優(yōu)化實施計劃方案

1、 .金稅三期工程省級應用集中優(yōu)化實施方案一、概述根據(jù)總局稅收信息化工作領導小組進一步推進和優(yōu)化金稅三期工程的要求，優(yōu)化實施工作組組織金稅三期架構組、業(yè)務組、蒙、六省市試點單位國地稅局和省地稅局，中軟公司、神州數(shù)碼公司、甲骨文公司、稅友公司、方欣公司和中創(chuàng)公司等各項目組共132人，于2014年2月9日至2月22日在省地稅局桃源樓南海稅務信息處理中心集中工作，研究金稅三期省級應用集中和全國數(shù)據(jù)集中實施方案。本次會議分為總體組、數(shù)據(jù)組、關鍵技術組、用戶體驗組、系統(tǒng)部署和運維組，通過反復研究，形成了總體優(yōu)化實施意見。金稅三期優(yōu)化實施階段將根據(jù)金稅三期省級應用集術分析報告中提出的優(yōu)化建議，充分考慮風險性

2、、合理性和前瞻性等方面的因素，優(yōu)化調整現(xiàn)在的全國統(tǒng)一集中部署方案為省級集中部署方案，調整項目的架構、解決現(xiàn)存問題、分析管控省級集中過程中的重點問題并根據(jù)總局的時間要求在年底實現(xiàn)3+2省市的上線工作。同時嚴格監(jiān)管優(yōu)化實施階段的工程質量、流程，強化甲方項目管控能力，規(guī)避質量風險，保證時間進度，控制項目成本。二、優(yōu)化原則（一）總體原則1.遵循金稅三期的架構規(guī)和標準，并根據(jù)省級應用集中和總局數(shù)據(jù)大集中的需要進行優(yōu)化調整。2. 金稅三期必須成為一個整體進行優(yōu)化，不同的子項目不能夠各自為政、畫地為牢。優(yōu)化工作需要進一步明確各子項目在總體架構中的位置和職責，按總體架構要求進行子項目的設計開發(fā)工作。3. 簡化

3、金稅三期目前過于復雜的體系結構，對各系統(tǒng)的應用分布和數(shù)據(jù)庫分布進行合理化歸并，最大程度地提高金稅三期系統(tǒng)的穩(wěn)定性。4. 以稅務基層工作人員和納稅人的體驗為優(yōu)化重點，重點關注系統(tǒng)的易用性和穩(wěn)定性。5. 嚴格管控數(shù)據(jù)規(guī)，同時充分考慮各地業(yè)務的差異，適度放開業(yè)務流程限制。（二）應用架構方面1. 優(yōu)化金稅三期應用集成設計，全面采用服務化的集成手段。2. 各項目邊界合理歸位，遵循“高聚、低耦合”的應用設計基本原則，調整應用分布與功能邊界，簡化核心征管系統(tǒng)核心部分，提供模塊插件化接入服務。3. 主要稅收業(yè)務都必須提供補償業(yè)務。4. 簡化系統(tǒng)初始化配置的復雜程度，降低上線和運維的難度。（三）數(shù)據(jù)架構方面1.

4、 對金稅三期的數(shù)據(jù)結構進行重新梳理設計和全面優(yōu)化，建立全國統(tǒng)一的規(guī)數(shù)據(jù)模型，納入總局統(tǒng)一的配置管理，并由甲方嚴格管控數(shù)據(jù)結構的變化和數(shù)據(jù)庫的日常維護。2. 簡化金稅三期工程的數(shù)據(jù)鏈路，原則上生產(chǎn)系統(tǒng)只保留一份數(shù)據(jù)，如果需要增加副本，必須經(jīng)過充分論證。3. 金稅三期各系統(tǒng)必須將所有數(shù)據(jù)全部結構化并存放在生產(chǎn)數(shù)據(jù)庫中，不能僅以XML文件進行存放。XML結構化一般情況下實時處理，大數(shù)據(jù)量XML文件可異步處理。生產(chǎn)系統(tǒng)以結構化數(shù)據(jù)為主要處理對象，XML文件作為原始憑證按照電子檔案管理規(guī)的要求進行流轉和保存。4. 在核心征管系統(tǒng)中恢復必要的查詢功能，以實現(xiàn)操作員可以完整查詢到自己錄入的數(shù)據(jù)。三、應用架構

5、（一）調整容1. 完善總局、省局應用部署模式，對于交互頻度高、直接與納稅人發(fā)生聯(lián)系的業(yè)務在省局集中處理，總局根據(jù)管理和決策的需要采取存儲、調用等各種方法分類處理數(shù)據(jù)集中需求。調整完成后，管理決策系統(tǒng)、外部信息交換系統(tǒng)、業(yè)務工作門戶、應用集成平臺、數(shù)據(jù)交換平臺、IA系統(tǒng)和行政管理平臺兩級部署，其他應用系統(tǒng)部署在省局。2. 總局和省局之間通過異步數(shù)據(jù)交換的方式實現(xiàn)數(shù)據(jù)共享。省局國地稅分開部署，國地稅間實時交互通過應用集成平臺實現(xiàn)，批量數(shù)據(jù)通過外部信息交換平臺實現(xiàn)。3. 優(yōu)化應用集成設計，合并目前架構中的稅庫銀前置（核心征管自建）、應用集成平臺、遺留前置、核心征管前置和個稅前置，統(tǒng)一為面向渠道服務的

6、應用集成平臺和面向部應用系統(tǒng)間服務的應用集成平臺。應用系統(tǒng)間的集成優(yōu)先采用服務方式。4. 核心征管系統(tǒng)增加查詢功能，提供生產(chǎn)類查詢。5. 前置系統(tǒng)不再作為單獨系統(tǒng)考慮，作為核心征管或個稅部部件合并部署。6. 大廳系統(tǒng)不再作為單獨系統(tǒng)考慮，分別歸并到核心征管和個稅合并部署。7. 原跨層級數(shù)據(jù)交換平臺改名為數(shù)據(jù)交換平臺，為可選系統(tǒng)，可根據(jù)實際業(yè)務選擇跨層數(shù)據(jù)交換平臺、GoldenGate、ETL等交換平臺工具。（二）省級集中應用架構設計應用架構的優(yōu)化建議如下圖所示，包含金稅三期的總體應用架構和核心征管系統(tǒng)應用架構。圖3.1 金稅三期總體應用架構圖（三）部署模型以下為金稅三期系統(tǒng)部署模型。1.總局部

7、署模型圖3.2 總局部署模型2.省局部署模型圖3.3 省局部署模型四、集成架構（一）應用系統(tǒng)之間關系1. 金稅三期各新建系統(tǒng)之間的關系（1）決策1包1）各省可根據(jù)本省實際情況選擇以生產(chǎn)庫或者分發(fā)庫作為數(shù)據(jù)源向決策1包同步生產(chǎn)數(shù)據(jù)，投放數(shù)據(jù)中應包含代碼和權限等數(shù)據(jù)。同時對同步數(shù)據(jù)實施Oracle 系統(tǒng)級增量識別方案，即實施OGG三個增量識別字段，以便于決策系統(tǒng)進行增量數(shù)據(jù)識別。2）在稅收核算方面，決策一包采用核心征管數(shù)據(jù)直接進行核算，為避免核算加工影響核心征管前臺應用，可以采用同一數(shù)據(jù)庫不同用戶的方式訪問核心征管數(shù)據(jù)。為滿足實時核算的需求（由基層用戶決定核算啟動的時間）和提高核算加工的效率要求，

8、需要核心征管在涉與核算的相關業(yè)務表中，對每一類業(yè)務日期同步增加記賬用和歸集用兩類字段，以滿足核算的需要。（2）個稅系統(tǒng)核心征管和個稅的邊界切分需要考慮法人和自然人兩類納稅主體，同時兼顧后續(xù)稅制改革的前瞻性變化，技術實現(xiàn)的“高聚低耦合”和用戶體驗。房產(chǎn)稅、契稅、車船稅等業(yè)務擁有一致的業(yè)務流程和業(yè)務管理規(guī)定，法人和自然人僅僅作為兩類納稅主體，因此該部分業(yè)務建議保持現(xiàn)狀。開票、退稅、票證等征收業(yè)務，需要和外圍系統(tǒng)如TIPS、POS、銀行端查詢繳稅等緊密銜接，同時也要和銷號、國庫對帳、會計核算等緊密銜接，不宜單獨作為一部分進行切分，因此該部分業(yè)務也建議保持現(xiàn)狀。按照這種模式，從技術上可以保障稅制改革的

9、前瞻性變化，同時核心征管系統(tǒng)和個稅系統(tǒng)的業(yè)務邊界切分在現(xiàn)狀的基礎上只需要做細微的調整，實現(xiàn)了高聚低耦合，確保了系統(tǒng)的穩(wěn)定性和用戶的良好體驗。（3）納稅服務系統(tǒng)1）省局數(shù)據(jù)集中后，對于納稅服務系統(tǒng)需要的部分實時性要求不高的數(shù)據(jù)查詢接口和數(shù)據(jù)需求，改為直接由納稅服務系統(tǒng)直接訪問省局查詢庫，減少納稅服務系統(tǒng)對其他系統(tǒng)的依賴性和耦合度。2）核心征管系統(tǒng)向納稅服務系統(tǒng)提供的接口服務應以實時接口為主，盡量改進用戶體驗；3）由網(wǎng)絡發(fā)票系統(tǒng)在各省部署的前置系統(tǒng)提供異地發(fā)票查驗向的全國路由；2. 金稅三期新建系統(tǒng)和總局保留軟件之間的關系；在金稅三期與保留軟件進行數(shù)據(jù)同步時提供緩存機制或者增加日志，方便日后對賬；

10、同時改進數(shù)據(jù)提取方式，如：發(fā)票驗舊業(yè)務等。3. 金稅三期和各省特色軟件之間的關系。金三系統(tǒng)為各省特色軟件提供其所需的業(yè)務接口，特色軟件依照金三接口規(guī)進行本地特色軟件改造，通過應用集成平臺（渠道）訪問金三系統(tǒng)提供的接口服務。各省特色軟件可通過訪問本省查詢庫實現(xiàn)特色軟件查詢類需求。（二）各省國地稅應用之間關系國地稅之間網(wǎng)絡連通，實現(xiàn)數(shù)據(jù)共享。對于國地稅之間需要數(shù)據(jù)交換的情況，由一方完成業(yè)務辦理后，采用數(shù)據(jù)交換的方式同步到另外一方。（三）總局業(yè)務和省局應用之間關系對于各省需要總局參與辦理的業(yè)務，由業(yè)務組再征求總局各業(yè)務司的意見，根據(jù)總局各司局的回復意見進行處理，有需要再進行部署。（四）跨省應用各省涉

11、與跨省業(yè)務的數(shù)據(jù)，在完成本地保存的同時通過異步方式上傳到總局，使用方明確的數(shù)據(jù)由總局直接轉發(fā)到對應省局；使用方不明確或不固定的，在總局建表保存，并由總局提供實時數(shù)據(jù)服務。五、服務體系描述（一）服務架構圖描述規(guī)金稅三期省級集中系統(tǒng)全面采用服務化的集成手段，其中，核心征管系統(tǒng)服務體系架構見下圖。1. 應用集成關系說明納稅服務系統(tǒng)、省級特色軟件等渠道系統(tǒng)通過相應的協(xié)議，接入到應用集成平臺（渠道）。應用集成平臺（渠道）負責將各應用系統(tǒng)的接口服務注冊到該平臺上。應用集成平臺（渠道）通過E協(xié)議直接調用核心征管系統(tǒng)的接口服務。個稅系統(tǒng)、外部交換系統(tǒng)、稅庫銀系統(tǒng)和應用集成平臺（部）的關系類似。應用集成平臺（部

12、）通過相關協(xié)議，與總局集成平臺交互，完成跨省業(yè)務協(xié)作。100 / 100圖5.1 核心征管系統(tǒng)服務架構圖2. 應用集成平臺功能說明應用集成平臺核心功能組成如下圖。圖5.2 應用集成平臺核心功能主要功能有通訊協(xié)議適配、流量控制、消息格式轉換和系統(tǒng)接入管理、服務管理、交易路由和交易流水等。通訊協(xié)議適配支持應用集成平臺各種標準協(xié)議適配接入，如：WebService、E、JMS、MQ、Hessian、FTP等，并且能夠支持自定義開發(fā)適配器的方式來實現(xiàn)各種系統(tǒng)的集成整合。流量控制：支持按系統(tǒng)和按服務的流量設置和控制，防止系統(tǒng)的高并發(fā)請求和隔離系統(tǒng)故障。接入系統(tǒng)管理：應用集成平臺面對多種不同的系統(tǒng)，提供統(tǒng)

13、一的接入管理機制，提供系統(tǒng)和服務的統(tǒng)一接入、注冊與策略管理，支持同步/異步方式的接入，能夠控制不同系統(tǒng)和服務的訪問權限。交易路由：應用集成平臺提供完備的路由機制，提供路由策略的配置、路由服務的查找與調用，支持自定義路由參數(shù)(包括地域、系統(tǒng)、交易以與各類自定義業(yè)務參數(shù)等）和規(guī)則的路由機制。應用集成平臺置的路由策略包括：按機關匹配、全匹配、任意、正則表達式、匹配開頭。服務管理：應用集成平臺提供服務的統(tǒng)一注冊、管理和運行時調度以與出現(xiàn)時的統(tǒng)一管理。交易流水管理：應用集成平臺提供交易流水的采集、存儲、檢索等功能。提供對各類交易執(zhí)行流水信息的記錄、監(jiān)控與管理，能夠完整的記錄一筆業(yè)務的各類關鍵性執(zhí)行線索信

14、息，從而為沖證與對賬提供依據(jù)。管理監(jiān)控：應用集成平臺支持用戶監(jiān)控交易處理情況，根據(jù)交易流水監(jiān)控當前服務交易情況，與時處理和發(fā)現(xiàn)各種異常。（二）服務設計原則1. 跨應用系統(tǒng)的所有服務都應發(fā)布在應用集成平臺上，應用系統(tǒng)間不得直接互相調用；2. 服務的職責應劃分清晰，做到“高聚、松耦合”；3. 服務的粒度應適中，有利于保持穩(wěn)定。4. 服務必須是無狀態(tài)的。5應用系統(tǒng)部使用和對外提供的服務要保持一致，采用一樣的服務接口。（三）服務接口描述規(guī)各系統(tǒng)提供的服務接口應提供詳盡的文檔說明，說明容遵循如下規(guī)：服務整體按樹狀層級展現(xiàn)，建議分兩層目錄，第一層目錄按業(yè)務域進行分類，第二層目錄為具體的服務中文名稱，然后就

15、是每個服務重要屬性的描述。示例如下：登記接口服務自然人信息查詢服務IDC00.SB.ZRRXXCX.GSCX.zrrxxcx服務中文名稱自然人信息查詢輸入登記序號輸出自然人、自然人件種類代碼、自然人件、登記序號、性別、居住地址、聯(lián)系服務功能描述根據(jù)納稅人識別號查詢自然人信息，此服務通過調用個稅系統(tǒng)提供的遠程服務實現(xiàn)事務處理說明xxx異常處理說明xxx靈活就業(yè)人員銀行信息查詢服務IDC00.DJ.YHXX.ZGCX.getYhxx服務中文名稱靈活就業(yè)人員銀行信息查詢輸入登記序號輸出社保經(jīng)辦機構、社保編碼、銀行行別代碼、銀行營業(yè)網(wǎng)點代碼、銀行賬號服務功能描述根據(jù)登記序號查詢靈活就業(yè)人員的銀行明細信

16、息事務處理說明xxx異常處理說明xxx申報接口服務納服申報狀態(tài)查詢服務IDC00.SB.SBTY.ZGCZ.nfsbztcx服務中文名稱納服申報狀態(tài)查詢輸入djxh登記序號，skss 稅款所屬期起，skssqz稅款所屬期止，yzpzzlDm應征憑證種類輸出sbztDm申報狀態(tài)代碼，sbfs申報方式，djxh登記序號，skss 稅款所屬期起，skssqz稅款所屬期止，zsxmDm征收項目，zspmDm征收品目，yzpzzlDm應征憑證種類，swjgDm稅務機關服務功能描述外圍廠商如網(wǎng)報查詢某筆申報的當前狀態(tài)（狀態(tài)包括：未申報、申報已繳款、申報未繳款、申報已作廢等），實際業(yè)務邏輯通過調用核心征管專

17、有業(yè)務服務PDS_NSFW001_getNfsbztcx實現(xiàn)。事務處理說明xxx異常處理說明xxx六、數(shù)據(jù)架構（一）調整容1. 對金稅三期各系統(tǒng)目前的數(shù)據(jù)庫進行合并，同時邏輯上要保持各業(yè)務域的獨立。2. 在省級設立生產(chǎn)庫、查詢庫、分發(fā)庫、集成平臺庫和決策支持庫，由分發(fā)庫負責向總局、各地市和本級數(shù)據(jù)倉庫提供數(shù)據(jù)。原則上在省國、地稅局各只建立一個分發(fā)庫。3. 重新梳理主數(shù)據(jù)容，取消主數(shù)據(jù)數(shù)據(jù)庫。4. 調整應用系統(tǒng)間的數(shù)據(jù)共享策略，單筆或小量的數(shù)據(jù)共享以服務為主，實施數(shù)據(jù)消費保障方案；批量數(shù)據(jù)的共享需求在滿足數(shù)據(jù)一致性和實時性的要求，綜合考慮更新頻度、訪問頻度、數(shù)據(jù)量和實時性等因素，采用合適的技術手

18、段實現(xiàn)。5. 總局部署“組織和自然人數(shù)據(jù)庫”（合并在總局集成平臺庫中），主要采用異步方式處理跨省業(yè)務。（二）省級集中數(shù)據(jù)架構設計數(shù)據(jù)架構的優(yōu)化建議如下圖所示，其中包含金稅三期的總體數(shù)據(jù)架構和核心征管系統(tǒng)數(shù)據(jù)架構。圖6.1 金稅三期總體數(shù)據(jù)架構圖圖6.2 金稅三期總體數(shù)據(jù)流向圖（三）數(shù)據(jù)模型（ER圖）設計要求1. 數(shù)據(jù)模型設計文檔包括數(shù)據(jù)庫概要設計文檔、使用Powerdisgner或DataModel軟件的模型文檔和數(shù)據(jù)字典等三個部分。模型文檔與數(shù)據(jù)字典要同步維護，與時更新。2. 數(shù)據(jù)表、數(shù)據(jù)項的命名應符合金稅三期標準規(guī)則，與業(yè)務術語名稱保持一致性，表名稱、數(shù)據(jù)項名稱應保持可讀性。3. 同一數(shù)據(jù)

19、項出現(xiàn)在不同表中，數(shù)據(jù)項的屬性如類型、長度等應保持一致性。4. 數(shù)據(jù)結構設計原則上要滿足遵循第三式要求，只有在為了提高程序效率情況下適當考慮冗余。七、重點關注的關鍵技術問題（一）核心框架方面1現(xiàn)狀和問題分析金稅三期核心征管軟件服務器端基于中軟Sword平臺中的核心框架開發(fā)實現(xiàn)。核心框架采用J2EE技術開發(fā)，涵蓋了系統(tǒng)服務器端開發(fā)的各個方面，提供了各種功能組件，使開發(fā)者盡可能少的考慮底層技術問題，將更多的精力放在業(yè)務功能的開發(fā)上。核心框架的功能、性能和開發(fā)規(guī)性直接決定了金稅三期核心征管軟件的性能、穩(wěn)定性、可靠性和用戶體驗。從目前已上線單位的反映和雙軌測試環(huán)境實際體驗來看，金稅三期的核心框架還存在

20、一些不足。以下是存在的問題與對應的原因分析：（1）穩(wěn)定性和健壯性方面1）持久層缺少執(zhí)行超時時間、結果集最大記錄條數(shù)等默認參數(shù)設置，如個別業(yè)務邏輯的SQL性能較差，如果未設置執(zhí)行超時，可能會引發(fā)系統(tǒng)大面積阻塞和宕機。2）框架部缺少安全性檢查機制。如緩存組件的注銷方法現(xiàn)允許未經(jīng)授權的代碼調用，應實施調用安全性檢查。3）缺少終止指定會話的機制。如當某管轄大量納稅人的稅務機關進行批量申報操作造成服務器壓力過大時，運維人員無法終止該請求的執(zhí)行，造成其他業(yè)務無常運行。4）跨域調用故障定位困難。如發(fā)票發(fā)售業(yè)務中發(fā)票域需調用申報域提供的已申報校驗服務，但因為執(zhí)行日志分散在各運行實例中，跨域調用故障問題的定位比

21、較困難。（2）性能優(yōu)化方面1）框架層面的執(zhí)行性能可進一步優(yōu)化。如申報計稅業(yè)務會多次通過部服務管理器調用其他基礎業(yè)務服務（計算申報期限和繳款期限等），框架功能會有一定的性能消耗，存在進一步壓縮空間。2）依賴數(shù)據(jù)庫實現(xiàn)業(yè)務邏輯中的狀態(tài)檢查。如目前稅款征收業(yè)務每次進行扣款操作前均需查詢數(shù)據(jù)庫以檢查納稅人是否簽署了三方協(xié)議，增加了數(shù)據(jù)庫壓力。3）依賴數(shù)據(jù)庫實現(xiàn)業(yè)務的操作互斥檢查。如征收開票前的鎖票動作是通過檢查數(shù)據(jù)庫指定表中的相關記錄狀態(tài)信息實現(xiàn)，增加了數(shù)據(jù)庫壓力且性能較差。（3）項目管控方面1）部分業(yè)務邏輯的實現(xiàn)代碼質量不佳，性能較差，資源占用過多，此類代碼發(fā)布到生產(chǎn)環(huán)境容易引發(fā)故障。如部分開發(fā)人員

22、編寫的SQL執(zhí)行效率較差，曾引發(fā)數(shù)據(jù)庫資源占用過高問題。主要是由代碼審查不足，測試不充分引起。2）用例設計評審不充分，不能正確使用框架提供的功能。如部分批量數(shù)據(jù)處理使用循環(huán)方式，未使用框架的并行處理方式。2調整目標核心框架是金稅三期核心征管軟件的基礎，通過對現(xiàn)存問題的分析，在保證系統(tǒng)正確性和穩(wěn)定性的前提下，有必要對核心框架的組件進行完善，為業(yè)務系統(tǒng)提供必要的功能，不斷提高系統(tǒng)的穩(wěn)定性和健壯性，優(yōu)化系統(tǒng)性能，提升用戶體驗。3優(yōu)化方案為了達到以上目標，解決目前核心框架存在的各種不足，采用以下調整方案：（1）穩(wěn)定性和健壯性方面1）在持久層增加關鍵參數(shù)默認值配置增加執(zhí)行超時的默認配置，各應用域根據(jù)自身

23、業(yè)務特點配置默認的執(zhí)行超時時間，同時提供手工設置超時時間以滿足復雜查詢需執(zhí)行較長時間的需求。提供結果集最大記錄行數(shù)默認參數(shù)，各應用域根據(jù)自身業(yè)務特點設置允許最大結果集行數(shù)參數(shù)，在結果集處理過程中檢查結果是否超過設置值；同時提供手工設置該參數(shù)以滿足類似大數(shù)據(jù)導出記錄行數(shù)較多的需求。2）優(yōu)化核心框架部基礎對象訪問方式和調用機制調整框架部運行依賴的基礎信息對象的訪問方式，調整對象結構和可見性圍，保證只有合規(guī)的邏輯可以訪問相關對象。增加Java安全策略配置，保證系統(tǒng)調用安全性。在關鍵系統(tǒng)功能中增加調用檢查點，且支持配置開或關。3）提供終止指定會話的機制提供會話執(zhí)行跟蹤機制：框架收集會話執(zhí)行服務器的路徑

24、和執(zhí)行線程信息。提供會話運行終止功能：根據(jù)會話的相關執(zhí)行信息，查找運行指定會話的服務器與執(zhí)行線程，并向執(zhí)行線程發(fā)送終止執(zhí)行的控制消息?？蚣芟嚓P功能組件中增加執(zhí)行狀態(tài)檢查功能，根據(jù)執(zhí)行線程接收到的控制消息，判斷是否終止執(zhí)行。4）完善日志組件執(zhí)行日志采集異步化：采用異步方式采集執(zhí)行日志，保證執(zhí)行日志數(shù)據(jù)的采集動作對業(yè)務運行影響最小化。執(zhí)行日志存儲異步化：根據(jù)執(zhí)行日志數(shù)據(jù)庫的產(chǎn)品特性，采用異步化的方式持久化調用日志數(shù)據(jù)，如MongoDB數(shù)據(jù)的異步寫入功能。與運維管理系統(tǒng)結合，聯(lián)合完成跨應用的綜合分析定位。（2）性能優(yōu)化方面1）優(yōu)化部服務組件優(yōu)化部服務注冊表的查詢機制，如使用更優(yōu)化的Hash算法替代J

25、ava默認實現(xiàn)方式以提高查找效率。優(yōu)化部服務調用機制，如優(yōu)化ASM生成的動態(tài)服務代理類代碼質量。根據(jù)環(huán)境配置信息，動態(tài)整合服務的攔截處理方法和服務調用方法，將解析調用轉為按需硬調用。優(yōu)化服務版本化管理機制，目前不同版本的服務注冊成不同的服務條目，造成服務條目過多，應采用適當機制縮減部服務的條目數(shù)量，提高服務查找和管理性能。2）提供狀態(tài)緩存服務組件提供狀態(tài)數(shù)據(jù)管理平臺，通過算法將數(shù)據(jù)庫中的相關狀態(tài)數(shù)據(jù)映射到應用服務器的存狀態(tài)位上。提供狀態(tài)數(shù)據(jù)訪問客戶端，業(yè)務邏輯調用功能客戶端訪問和更新狀態(tài)數(shù)據(jù)緩存中的狀態(tài)信息。3）提供應用級鎖管理組件提供鎖管理服務器，用于應用層的鎖信息存儲，并提供鎖的檢查和管理

26、功能。提供鎖數(shù)據(jù)訪問客戶端，用于業(yè)務邏輯與鎖服務器進行通訊。（3）項目管控方面1）框架開發(fā)者提供詳細的開發(fā)指導手冊，加強開發(fā)人員的技術培訓，保證開發(fā)人員能正確使用框架提供的功能；提供代碼掃描工具，提高代碼質量。2）完善代碼審查制度，強化制度落實與執(zhí)行。3）加強軟件測試，提高自動化測試的覆蓋率，同時加強邊界測試。（二）應用集成平臺方面1現(xiàn)狀和問題分析在省級應用集中，應用集成平臺定位在既要承擔金三部系統(tǒng)之間的應用集成，同時還要承擔各省的渠道系統(tǒng)接入到部系統(tǒng)的應用集成（原來是由前置軟件負責），在總局和各省局國地稅也要分別部署，這將對應用集成平臺的功能性、可靠性、穩(wěn)定性提出了更高的要求。應用集成平臺采

27、用服務代理模式，不部署業(yè)務服務，業(yè)務服務部署在提供服務的系統(tǒng)上，應用集成平臺作為代理負責轉發(fā)業(yè)務服務請求，所提供服務的業(yè)務邏輯由提供服務的系統(tǒng)執(zhí)行。而服務容器是指將業(yè)務邏輯處理部分封裝為獨立的服務部署在應用集成平臺上，應用集成平臺可作為服務容器直接接收并執(zhí)行服務。目前，應用集成平臺采用服務代理模式，實現(xiàn)了平臺與業(yè)務邏輯的解耦，業(yè)務邏輯變化和部署不影響平臺，平臺輕量，不直接處理業(yè)務邏輯。在目前的全國應用集中，在總局部署了一套應用集成平臺，它提供總局新建系統(tǒng)間的應用集成，如征管和個稅、納服和征管的待辦事宜集成、征管和網(wǎng)絡發(fā)票；在各省國稅和地稅也分別部署了一套應用集成平臺，負責提供省特色系統(tǒng)和總局遺

28、留系統(tǒng)接入到核心征管的應用集成。另外，核心前置也部署在總局，承擔了納服、稅庫銀等渠道軟件的應用接入；而部署在各省局國地稅的核心前置負責國地稅大廳的應用接入；這些核心前置和應用集成平臺的本身功能差不多，只是接入系統(tǒng)與其服務不一樣，并且在核心前置上部署了業(yè)務預處理服務。從目前3個已上線省市的應用來看，并基于省級應用集中的考慮，應用集成平臺在如下幾個方面存在不足：（1）異常故障性保障和隔離：在出現(xiàn)異常時的處理和故障隔離還需要完善。1）異常處理機制：目前對于JMS消息處理方式，如果在目標系統(tǒng)網(wǎng)絡一直出現(xiàn)異常故障下，JMS消息會一直連續(xù)發(fā)送到目標系統(tǒng)，這會無故消耗系統(tǒng)資源，可能會影響系統(tǒng)其他業(yè)務運行。2

29、）故障保障隔離：在E/WebSerivce等同步模式下，目前的流量控制在線程數(shù)足夠時可以起到故障隔離，如果高并發(fā)服務請求過多導致線程不足而服務處理很慢時，這時可能會造成系統(tǒng)堵塞，并且由于缺少服務優(yōu)先級控制，可能會導致高優(yōu)先級業(yè)務服務也無法處理。（2）界面化配置：目前應用集成平臺的參數(shù)配置基本上都是通過DML數(shù)據(jù)庫腳本在系統(tǒng)升級或打補丁時執(zhí)行生效，而沒有提供界面在生產(chǎn)環(huán)境由系統(tǒng)管理員進行配置。1）靜態(tài)參數(shù)配置：雖然很多靜態(tài)參數(shù)作為版本信息是可以通過DML腳本進行初始化配置，但有些靜態(tài)參數(shù)可能在具體環(huán)境有差異，這就最好需要提供界面來配置，如：各種協(xié)議的IP端口地址等信息。2）動態(tài)參數(shù)配置：對于需要

30、根據(jù)系統(tǒng)運行情況調整的參數(shù)，目前也是通過DML腳本執(zhí)行，如流量配置、接入配置等。（3）擴展性功能：目前業(yè)務需求功能的變化，完全是由服務具體來實現(xiàn)，應用集成平臺沒有提供服務編排等功能，這樣就無法實現(xiàn)只需平臺級的定制而無需業(yè)務服務變化修改。同時，作為服務提供系統(tǒng)方和服務消費系統(tǒng)方，在使用應用集成平臺方面以與各方相互協(xié)作配合方面，主要出現(xiàn)如下的問題：（1）規(guī)性：在應用集成平臺規(guī)還不是很完善和執(zhí)行協(xié)調不到位。1）服務梳理劃分：服務劃分太細會造成交互頻繁，增加系統(tǒng)壓力。2）超時控制：未結合征管與其他接入系統(tǒng)的整個鏈路時間進行配置，易出現(xiàn)系統(tǒng)間配置參數(shù)不匹配而引起的服務異常，如網(wǎng)報系統(tǒng)配置超時時間為5S，

31、征管系統(tǒng)配置超時時間為10S，應用集成平臺配置超時時間為30S，此種情況將出現(xiàn)應用集成平臺在征管系統(tǒng)未有正確返回時因超時而斷開請求。（2）協(xié)同性：在各方系統(tǒng)集成時，由于同時存在前置和應用集成平臺，在選擇接入時容易困惑；同時選擇了不恰當?shù)募煞绞胶徒尤敕绞?，比如應該應用集成而使用了?shù)據(jù)集成、本地特色應用和渠道系統(tǒng)過多使用異步方式協(xié)議、集成調用的次數(shù)較多。通過這些問題分析，應用集成平臺在功能性、可靠性、穩(wěn)定性還需要完善，并且還需要加強應用集成平臺規(guī)的執(zhí)行完善和各集成方的協(xié)調配合。2調整目標（1）簡化規(guī)應用集成：盡量簡化應用集成，規(guī)應用集成方式和同步異步接入方式。（2）提高配置易用性：增加靈活配置功

32、能界面，動態(tài)滿足系統(tǒng)變化要求，如：系統(tǒng)壓力大時動態(tài)配置流量以限流等。（3）加強故障處理和可靠性：在系統(tǒng)出現(xiàn)異常故障時，應用集成平臺需限制系統(tǒng)的故障圍而不至于系統(tǒng)故障蔓延，提供系統(tǒng)在可承受壓力圍正常運行的保障機制，盡量減緩或限制系統(tǒng)壓力，同時保障關鍵服務可被優(yōu)先執(zhí)行。如流量控制和優(yōu)先級控制。（4）增強服務擴展性：在業(yè)務發(fā)生變化時，應用集成平臺可根據(jù)已有服務編排組合成新的服務，以動態(tài)滿足適應業(yè)務變化，如增加服務編排功能。3優(yōu)化方案為了實現(xiàn)上述目標，應用集成平臺具體改進措施如下：（1）簡化規(guī)應用集成渠道系統(tǒng)改為統(tǒng)一接入到應用集成平臺，前置軟件將去掉。合理選擇系統(tǒng)之間的集成方式，特別注意選擇好應用集成

33、的同步異步接入方式。（2）故障隔離有兩種方案，利用weblogic工作管理器分別控制請求和響應線程數(shù)和優(yōu)先級，或自主研發(fā)隊列機制增加分組、優(yōu)先級功能。1）基于weblogic工作管理器定制開發(fā)：根據(jù)業(yè)務需求預先在工作管理器中定義不同的線程組，來自不同渠道、針對不同服務的請求會使用不同的線程組，同時對后面不同系統(tǒng)的服務的調用也使用不同的線程組。使任何服務的擁堵不會蔓延。優(yōu)點：技術明確，風險可控；工作量可控，通過配置+資源適配器的定制開發(fā)。缺點：使用weblogic優(yōu)先級的應用案例不多，需要驗證具體使用策略；和weblogic耦合緊密，完全依賴weblogic；服務請求方發(fā)起請求時須指定業(yè)務組件實

34、例的級別。2）自主研發(fā)隊列機制增加分組和優(yōu)先級處理：通過隊列和連接適配器控制服務在請求和響應按照不同分組和不同級別執(zhí)行。優(yōu)點：完全自主，按照JCA規(guī)；服務請求方無需關心優(yōu)先級，通過應用集成平臺本身配置實現(xiàn)。缺點：技術上有難度，存在技術風險；工作量大，需要保障穩(wěn)定性和性能。建議先采用方案1過渡，最終過渡為方案2。（3）配置管理完善超時配置功能界面等，完善現(xiàn)有功能界面。增加流量配置功能界面等，根據(jù)需求增加功能界面。（4）服務監(jiān)控完善服務的運行狀態(tài)、運行效率、運行是否有錯誤等的監(jiān)控。若有問題與時告警，降低運維壓力。（5）服務編排針對現(xiàn)有服務提供XML報文容的輸入輸出處理，也能夠把多個服務按照一定規(guī)則

35、串接組合起來。編排后的服務作為一個新的服務暴露出來，且對原來的服務代碼無須修改。應用集成平臺需支持服務編排功能，但是此功能實現(xiàn)優(yōu)先級低，在遇到有需要業(yè)務場景時使用。除了上述應用集成平臺具體改進措施，還需要加強應用集成平臺規(guī)的執(zhí)行完善和各集成方的協(xié)調配合。（1）需要不斷完善和遵照執(zhí)行的應用集成平臺規(guī)有：1）GT3-HX-ZJ-應用集成平臺接口規(guī)2）GT3-HX-ZJ-應用集成平臺接入規(guī)3）GT3-HX-ZJ-應用集成平臺數(shù)據(jù)定義規(guī)4）GT3-HX-ZJ-應用集成平臺數(shù)據(jù)交換規(guī)（2）各業(yè)務系統(tǒng)需要對服務高度抽象梳理，對各種系統(tǒng)消費方提供的服務盡量保持一致，并盡量減少系統(tǒng)之間減少次數(shù)。（3）各方協(xié)調

36、配置好超時時間。（三）工作流方面1. 存在問題工作流系統(tǒng)是金稅三期基礎軟件平臺中的重要組成部分。金稅三期系統(tǒng)采用了中創(chuàng)公司提供的工作流軟件InforSuite Flow，該軟件已在多個大型信息系統(tǒng)項目中應用，它是遵循WFMC規(guī)、支持采用XPDL形式XML進行流程定義的工作流中間件，為工作流自動化與流程再造提供基礎平臺，為金稅三期工程提供基礎的、統(tǒng)一的流程管理平臺。該工作流產(chǎn)品結構如圖所示：圖7.1 InforSuite FS產(chǎn)品架構InforSuite Flow工作流軟件提供了統(tǒng)一的BS流程建模平臺，可以用于累積業(yè)務流程模型，并可便于服用業(yè)務模型。流程建模平臺功能眾多，包含了流程分級定義、下發(fā)

37、、逐級個性化擴展定義同一業(yè)務流程等特色功能。在金稅三期中使用工作流工具的目的是增強征管系統(tǒng)的適應性，有效支持業(yè)務由職能導向轉變?yōu)榱鞒虒颍山Y果監(jiān)督轉變?yōu)檫^程監(jiān)督。工作流軟件被用于支撐金稅三期工程核心征管、個稅、行政辦公、納稅服務、管理決策等多個項目，各項目對InforSuite Flow工作流軟件進行了集成，并分別對工具相關功能進行了封裝或個性化擴展，構建了各自的工作流框架。目前核心征管系統(tǒng)的各個應用域分別有對應的工作流域，工作流域主要涵蓋了工作流服務框架與工作流引擎和工作流數(shù)據(jù)庫。簡單來說，核心征管系統(tǒng)的工作流的部署方式是“多實例多數(shù)據(jù)庫”。個人稅收管理系統(tǒng)則采用了“多實例單數(shù)據(jù)庫”的工作

38、流部署方式，個稅系統(tǒng)各應用域嵌了工作流服務框架與工作流引擎，但共享一個數(shù)據(jù)庫。圖7.2 金稅三期核心征管系統(tǒng)工作流架構概要示意圖金稅三期系統(tǒng)用戶最常用的功能就是打開待辦任務列表或在辦任務列表，在辦理流程性事務時大量的使用到推送功能，而這兩者都是由工作流系統(tǒng)來承載、實現(xiàn)的，對于前臺辦稅的納稅人而言，辦事是否便捷、稅務機關服務是否高效優(yōu)質，很大程度上是由工作流框架和工作流引擎的功能、性能和開發(fā)規(guī)性直接決定的，稅務系統(tǒng)部用戶的用戶體驗也與之息息相關。從目前已上線單位的反映和雙軌測試環(huán)境實際體驗來看，目前金稅三期工作流系統(tǒng)存在以下突出問題：一是初始化配置特別復雜。當前，工作流配置方面主要存在的問題有三

39、點：一是相關的初始化配置非常復雜，工作量大：初始化配置極為繁瑣，耗時很長。金三系統(tǒng)在工作流配置上有著數(shù)倍于大集中系統(tǒng)的工作量：流程類工作建模中需要額外維護職能樹，工作流節(jié)點的角色對應關系、表單路徑、回調服務與關聯(lián)流程等容；非流程類稅務事項也需要額外維護角色與稅務事項對應關系以與職能樹相關的容。整個金三系統(tǒng)的流程類工作流建模工作量復雜度可以表達為如下： O（流程環(huán)節(jié)節(jié)點數(shù)職能樹數(shù)目稅務機關崗位數(shù)目角色表單路徑回調服務關聯(lián)流程操作機關），對于非流程類事項，其不涉與具體的工作流配置，而是使用特定的角色對應的功能模塊進行實現(xiàn)，因此其復雜度同理表達如下： O（非流程類事項數(shù)職能樹數(shù)目稅務機關崗位數(shù)目角色

40、）；二是因配置而產(chǎn)生的運行出錯概率極高，難以在配置時校驗配置的合法性，降低了初始化工作的效率；三是排查問題的難度大。初始化工作流的配置工作包含了工作流圖繪制以與每個節(jié)點的推送規(guī)則、標簽規(guī)則、事件規(guī)則、時間期限的配置等工作。二是健壯性不佳，待辦事宜可能丟失、延遲，偶有出現(xiàn)事務不完整問題，錯誤處理機制不完備。在總局集中版本運行期間，遇到過較多的由于JMS消息延時所產(chǎn)生的阻塞問題，造成“待辦門戶無法與時展現(xiàn)待辦任務、甚至一直收不到”，或者是“待辦任務點擊異常后任務消失或者仍然存在，再次點擊仍然異常”、“在流程監(jiān)控能看到某任務，但在待辦事宜中卻找不到對應任務”等現(xiàn)象；發(fā)生過一次點擊后，業(yè)務數(shù)據(jù)、流程數(shù)

41、據(jù)處理結果不一致的情況，且錯誤處理機制未能與時解決此類事務不一致的問題。三是易用性不佳，部分功能不人性化。部分單位的同一部門、同一崗位的人員數(shù)量較多（下屬區(qū)局的大廳集中辦公，約有幾百人），推送時選擇下一環(huán)節(jié)辦理人員時需拖拽查找，無法通過輸入拼音首字母或稅務人員代碼來快速定位；部分流程結束后，系統(tǒng)自動觸發(fā)了關聯(lián)流程，此時，無法手工選擇關聯(lián)流程推送人員。四是部分功能缺失，或尚待改進完善。未實現(xiàn)批量審批，例如出口退稅，影響基層工作效率；當操作員離職轉崗且未辦結當前任務時，缺少功能來進行轉辦，亦缺少相應監(jiān)控預警功能；缺少流程圖反向查找功能，當流程圖配置好發(fā)布以后，目前沒有一個好的功能來查詢某流程圖的原

42、始流程圖存在于BS設計器中何處，以方便檢索、基于原流程圖進行修改；未能實現(xiàn)流程定義在不同系統(tǒng)環(huán)境和不同上線單位之間的導入和導出；跨系統(tǒng)定制流程圖支持度不高，目前金三新建系統(tǒng)采用統(tǒng)一的建模工具建模并制作相關規(guī)則，再為其他系統(tǒng)進行數(shù)據(jù)同步，由于在引擎的流程圖模型管理中針對建模庫無實例數(shù)據(jù)的流程圖采用的是覆蓋操作，會導致目標方流程圖的歷史版本丟失，需要引擎解決；流程分支變量配置不便，繪制流程圖時，往往需要用到分支變量，但目前對業(yè)務用例的參數(shù)管理不夠，會導致繪制時不知道哪些參數(shù)在當前業(yè)務流程中可以使用，也不知道該如何使用；缺少供核心以外的應用系統(tǒng)發(fā)布工作流程模型的應用功能；缺少融合查詢功能，因目前工作

43、流系統(tǒng)是多應用、多數(shù)據(jù)庫實例部署，操作員無法便捷的查找到可能分散在不同應用域的某個流程之狀態(tài)，無法在單一功能里實現(xiàn)各應用域流程的統(tǒng)一查詢與管理，增加了操作員的負擔、增加了引起誤解的可能。五是職責分工不合理；文檔材料不完備，系統(tǒng)出現(xiàn)過宕機事故，管理方面存在不足。初始化建模工作量大且復雜，較難配置，從現(xiàn)實出發(fā)，要明確劃分乙方公司與省級以下用戶之間的職責圍；各乙方公司未給出回調服務、關聯(lián)流程等工作流配置的完整說明文檔；2014年1月出現(xiàn)過工作流系統(tǒng)宕機的情況.通過對典型業(yè)務場景的分析，工作流系統(tǒng)的穩(wěn)定性、功能性和易用性問題對目前金稅三期應用系統(tǒng)的外部用戶體驗造成了不小的影響。在省級集中部署后，這個問

44、題會更加突出。省級集中并不能自動的同時解決系統(tǒng)的穩(wěn)定性、功能性和易用性等問題。在我們對金稅三期各應用系統(tǒng)和數(shù)據(jù)庫簡化合并部署的前提下，減少了系統(tǒng)間的耦合度，可能可以提升部分方面的性能，但穩(wěn)定性問題、功能性問題和易用性問題將更加突出。2. 原因分析通過分析，造成前述問題的主要原因有以下三方面：一是技術方面。（1）待辦事宜的集成方式復雜。金稅三期系統(tǒng)的待辦事宜的集成選擇了“推”模式，各應用系統(tǒng)將待辦任務推送給工作門戶。選擇這種方案的初衷在于用戶體驗比較好。具體技術實現(xiàn)時，首先由總局部署的工作流引擎發(fā)起推送待辦的事件，然后工作流框架將其轉換為JMS消息，發(fā)送到ESB，然后傳遞到省級集成平臺，最后落地

45、到省級集成平臺庫，由門戶來進行展現(xiàn)。產(chǎn)生JMS消息延時并導致待辦信息無法與時展現(xiàn)的主要原因有三：異步消息機制存在延遲，有時候消息隊列堵塞，造成任務無法在規(guī)定時間到達省局門戶；網(wǎng)絡鏈路距離長，延時大，網(wǎng)絡可能出現(xiàn)丟包；當應用了多JMS隊列且先后發(fā)出多個有先后順序要求的JMS消息時，無法保障整體先進先出，目前的實現(xiàn)僅能保證每個隊列先進先出。（2）事務完整性保障機制不佳，系統(tǒng)錯誤處理機制不完善。為保證JMS消息（被推送的任務）的可靠性，目前通過開發(fā)待辦事宜對賬程序將業(yè)務工作門戶中的待辦任務數(shù)據(jù)與各應用系統(tǒng)工作流數(shù)據(jù)庫數(shù)據(jù)進行對賬，待辦事宜對賬程序通過E接口調用工作流對賬服務的E服務查詢應用系統(tǒng)的工作

46、流待辦事宜數(shù)據(jù)，但有效性未得到驗證。目前沒有完整有效的保障事務完整性的機制，在存在跨域調用時，沒有使用JTA、XA數(shù)據(jù)源、多階段提交等方式在事中保障事務完整性，也沒有構建充足的自動化補償功能在事后恢復事務完整性。（3）工作流框架和工作流引擎功能不足，未能與時根據(jù)需要完善相關功能。二是業(yè)務方面。總局的流程規(guī)與各上線單位實際操作存在差異，加上廠商和上線單位理解上的差異，導致系統(tǒng)中配置的工作流程過多而且過于復雜。三是實施管理方面。（1）開發(fā)配置工作與用戶配置工作未能合理劃分，導致均需要用戶進行配置，增加用戶工作量，而且出錯率高，效果不好。（2）需求分析存在不足。部分業(yè)務需求在實現(xiàn)時，設計出來的邏輯較

47、為復雜，在程序實現(xiàn)時涉與到多次跨域調用，客觀上導致未能良好的保證工作流與業(yè)務數(shù)據(jù)的一致性、事務的完整性。（3）業(yè)務應用與工作流框架功能分工落實不嚴，存在個別業(yè)務應用沒有充分利用工作流框架的功能而自行實現(xiàn)部分工作流功能。3. 調整目標工作流系統(tǒng)的優(yōu)化直接關系到金稅三期主體業(yè)務功能的正常運轉，關系到構建和諧征納關系，關系到落實“兩個減負”，因此需要重視對系統(tǒng)功能性與非功能性需求（或稱質量服務需求）的滿足，要做到運行質量（易用性、健壯性、穩(wěn)定性、效率等）與發(fā)展質量（可測試性、可維護性、可擴展性、可伸縮性、兼容性）并重，其中需要特別重視確保系統(tǒng)的健壯性、穩(wěn)定性，具體目標如下：（1）優(yōu)化工作流相關功能實

48、現(xiàn)；（2）提升系統(tǒng)運行效率，優(yōu)化工作流應用架構。（3）增強健壯性，完善錯誤處理機制；（4）增強易用性，改善用戶體驗。提供合理的默認值，記憶用戶選擇，支持全鍵盤操作等，降低用戶的學習和適應難度；（5）增強可維護性，完善配置功能，合理切分工作職責。4. 優(yōu)化方案為了達到以上目標，解決目前工作流系統(tǒng)存在的各種問題，提升用戶體驗，需要從技術、業(yè)務和管理三方同時采取措施進行調整優(yōu)化。一是技術方面。（1）優(yōu)化應用架構以配合工作流的相關工作機制。首先要確定是否繼續(xù)使用JMS消息傳遞待辦任務。若繼續(xù)使用，則需設計、完善異步消息完整性、可靠性保障機制并進行穩(wěn)定性、完整性驗證，需要將JMS消息服務器細分, 按業(yè)務

49、/區(qū)域/消息量等規(guī)則部署多個消息服務器，確保消息始終保持發(fā)送時的先后順序；若不保留，則改用實時調用。實時調用的優(yōu)點在于結構簡單、排錯簡單、可靠性較高且更為可控，任務可以實時在門戶展現(xiàn)，缺點在于需要量化的驗證性能是否能滿足省級集中需求；保留JMS的優(yōu)缺點基本與實時調用的優(yōu)缺點相反。其次，可以將工作流引擎庫與生產(chǎn)庫合并。在生產(chǎn)系統(tǒng)調用工作流引擎API的時候，改為外部傳入數(shù)據(jù)庫連接的模式，使得工作流引擎與生產(chǎn)系統(tǒng)保持在一個數(shù)據(jù)庫事務中。這樣可以部分的減少事務不一致的可能性，更好的提高外部用戶的體驗，缺點在于可能對數(shù)據(jù)庫的壓力較大，需要進行量化驗證。再次，應完善系統(tǒng)對事務不一致的處理機制、提高程序健壯

50、性、完善異常處理能力、完善補償用例的實現(xiàn)。在功能用例實現(xiàn)時，應遵循的原則如下：事務嵌套、跨應用調用不超過一層。經(jīng)分析，工作流應用有兩種架構部署方案，分述如下：第一種是采用嵌入式，嵌入業(yè)務應用工程中，不單獨部署。此種選擇的風險點有：可能遇到jar包沖突問題；在現(xiàn)有需現(xiàn)方式下，并不能徹底解決事務不一致問題，需測試驗證。第二種是仍然采用單獨部署工作流域。選擇該方案時時，仍然會存在跨域調用。因此，為了保證數(shù)據(jù)在多個參與的數(shù)據(jù)源中的一致性,需要用到JTA來控制事務,參與的數(shù)據(jù)源也需要支持X/Open協(xié)議(兩階段提交)。據(jù)了解，地稅網(wǎng)絡發(fā)票系統(tǒng)與核心征管系統(tǒng)之間的跨域調用使用了JTA來保證事務一致性，此外

51、國稅系統(tǒng)也有應用的案例。該方案有如下兩點需要注意：一是JTA分布式事務提交需要框架支持；二是兩階段提交會影響性能，特別是兩個事務處理時間比較長的情況下可能會有性能壓力，需要進行基準性能測試以確定特定硬件配置條件下是否能滿足性能需求；對于跨域調用，除使用JTA來控制事務外，還應開發(fā)業(yè)務手動補償用例以與自動化補償方式，對不一致事務采用補償機制解決，此方式的風險在于需要開發(fā)的補償用例過多，容易遺漏；并完善后臺監(jiān)控的功能，在發(fā)生不一致時，保存完整的不一致現(xiàn)場，以便于后臺運維處理。第四，清理工作流域相關的數(shù)據(jù)同步機制。避免使用數(shù)據(jù)同步機制來實現(xiàn)少量數(shù)據(jù)的交互，改為采用實時同步調用方式?？蓮V泛參考目前的省

52、級集中系統(tǒng)的類似場景與其解決方案。 （2）優(yōu)化工作流框架，包括功能完善、錯誤處理機制的完善、事務完整性保障機制的完善、配置功能完善。首先是增加模擬運行功能，實現(xiàn)在流程發(fā)布之前，流程能夠自動模擬運行，減少人工測試工作量。工作流應該可以提供配置驗證或提供較為人性化的提示功能，包括：驗證主工作流是否配置正確；驗證各選項是否配置正確；驗證關聯(lián)選項是否配置正確等。其次是增加工作流配置信息變更、發(fā)布、導入導出功能。工作流配置信息變更的維護工作目前需要各單位根據(jù)工作流配置變更單進行維護，應開發(fā)一個發(fā)布功能，可以生成相關sql或者dmp文件，隨版本發(fā)布各個環(huán)境，以此減少配置的工作量、保證與java代碼版本的一

53、致性，并減少由于人工維護造成的數(shù)據(jù)質量問題。再次是提供融合查詢功能。無論使用單引擎單數(shù)據(jù)庫、多引擎單數(shù)據(jù)庫或多引擎多數(shù)據(jù)庫的部署方式，均應在門戶向用戶提供融合查詢，一次查詢即可查找到各業(yè)務域的工作流轉情況。第四是建立、完善健壯性自動沖正（補償）機制。增加自動沖正（補償）功能，完善、建立自動化的錯誤、異常處理機制，排除因異常處理不嚴謹所導致的數(shù)據(jù)不一致問題，保障業(yè)務數(shù)據(jù)和工作流引擎數(shù)據(jù)的一致性。第五是完善基礎控件，智能化展現(xiàn)操作界面。優(yōu)化備選人員的顯示順序?？蛇x的方案如下：1）支持歷史記憶功能。包括：根據(jù)上一次本流程本環(huán)節(jié)推送時，默認選擇上次選擇的辦理人員。根據(jù)歷史選擇的次數(shù)，選擇次數(shù)較多的排名

54、靠前。2）支持用戶設置常用備選人。包括：每個用戶在每個流程和環(huán)節(jié)可以設置常用的備選人，常用備選人排名靠前，如果不設置，則按普通排序。3）支持手工輸入人員編號和人員，支持系統(tǒng)默認填充，支持模糊查詢。第六是支持無紙化、支持新舊工作流并存、允許操作人員選擇關聯(lián)流程的啟動環(huán)節(jié)之處理人員等。除了上述六點，還需要在架構調整前，按各種候選調整方案編制各種可能引發(fā)故障的測試場景，并依此進行充分驗證，根據(jù)結果進行測試和持續(xù)改進，提升其穩(wěn)定性和效率，并提交評估報告給甲方（總局與省級稅務局）供決策。工作流與權限是密不可分的，兩者具有天然的相關性，應充分采集各省稅務機關關于工作流權限配置方面的意見，兼顧靈活性、特殊性

55、與普遍性，完善、簡化工作流權限配置模型。舉例而言，至少有兩個問題需要完善：一是工作流配置規(guī)則中絕對層級判斷需要設置為對應的機關與其設部門。對絕對層級判斷時，應默認設置為其對應的機關與其設部門。二是機關設部門的權限默認與所屬機關保持一致。在工作流配置中，應默認使得機關設部門的權限與所屬機關保持一致，如果需要額外調整（部分崗位需要設置為本部門），可允許進行設置修改。相關配置方式應簡潔明了。（3）優(yōu)化工作流引擎。首先是研究工作流引擎與其數(shù)據(jù)庫實例的參數(shù)優(yōu)化。適當?shù)呐渲霉ぷ髁饕媾c其數(shù)據(jù)庫實例的參數(shù)，可以極大的降低工作流操作的平均響應時間、提升吞吐量，對整體性能和用戶體驗有明顯提升。其次是分離工作流數(shù)

56、據(jù)庫里的歷史數(shù)據(jù)與活動數(shù)據(jù)。參考數(shù)據(jù)組成果，結合工作流系統(tǒng)實際，制定工作流庫歷史數(shù)據(jù)剝離規(guī)則和實施策略，確保工作流庫性能。 二是業(yè)務方面。可以從以下三方面進行調整：（1）清理、拆解復雜的業(yè)務流程，重做相關需求分析，簡化設計。部分業(yè)務需求在分析時，設計出來的邏輯較為復雜，在程序實現(xiàn)時涉與到多次跨域調用，違反了“高聚”、“單一責任”的基本設計原則，客觀上導致未能良好的保證工作流與業(yè)務數(shù)據(jù)的一致性、事務的完整性。應對此類特殊的業(yè)務需求重新進行需求分析，針對工作流系統(tǒng)的特點進行優(yōu)化，力求保證需求點實現(xiàn)時的原子性，實現(xiàn)高度功能聚，必要時征求各上線單位的業(yè)務意見以對業(yè)務需求點進行簡化或拆解，從而保證事務完

57、整性、數(shù)據(jù)一致性。（2）清理工作流的不合理使用。一方面避免人為的增加工作流框架的負擔，另一方面也減少可能遇到的問題。應嚴格界定需要使用工作流的場景。對于“即辦類”或“單節(jié)點”業(yè)務，應避免使用工作流來實現(xiàn)。（3）保持靈活性。在工作流相關的業(yè)務設計中，應從全國實際情況出發(fā)，保持業(yè)務涉與的靈活性。如，部分地市縣區(qū)局的流程和其他縣區(qū)局流程不一致，需要重新畫，需要將允許自行繪制工作流的最小單位設為縣區(qū)局。三是管理方面?？梢詮囊韵氯矫孢M行調整：（1）完善工作流系統(tǒng)相關的開發(fā)、運維制度。首先要建立完善的質量保證制度、變更管理制度和版本控制制度，嚴格執(zhí)行流程，切實做好質量保證工作。其次要制定設計、開發(fā)、測試規(guī)并嚴格執(zhí)行。各乙方項目組應參考業(yè)界主流的開發(fā)規(guī)編制、完善適合本項目實際情況的設計、開發(fā)、測試規(guī)手冊并持續(xù)改進。在編制過程中應參考的現(xiàn)行軟件行業(yè)中主要適用的國家標準或行業(yè)標準如下：GB/T 8566-2007 信息技術 軟件生存周期過程 SJ/T 11375-2007 軟件構