6.ctg-mboss crm2.0渠道服務(wù)總線功能技術(shù)_v0.99

1、目錄1文檔說明編制說明1適用范圍1閱讀指南2起草. 3解釋權(quán)3. 32綜述.1驅(qū)動力3CSB 概念4CSB 定義42.2.2CSB 集成類型52.2.3SOA 與 EAI 的異同53CSB 應(yīng)用體系架構(gòu)綜述8省內(nèi)交互服務(wù)9省 CRM 與CRM 交互服務(wù)124CSB 平臺體系架構(gòu).1通用模型14CSB 服務(wù)提供模塊14功能描述CSB 服務(wù)邏輯模塊15功能描述CSB 服務(wù)配置模塊18功能描述CSB 服務(wù)模塊20功能描述文

2、件交換模塊21功能描述215CSB 平臺技術(shù)要求25.3.1總體技術(shù)要求28支持協(xié)議及標準30性能要求31主要性能指標315.3.2性能指標要求35.7可用性33可擴展性33安全性33指標346CSB 實施說明36.4服務(wù)設(shè)計原則35CSB 平臺技術(shù)應(yīng)用說明35CSB 建設(shè)模式41實例417附錄一規(guī)范編制. 428附錄二ESB 相關(guān)介紹48.4IBM Message Broker42Oracle Service BUS49TIP(The Integration Platform)51其他579附錄三SOA 管控建議

3、5910附錄四術(shù)語定義6111附錄五 參考文檔6212附錄六 命名規(guī)則6312.4服務(wù)編碼規(guī)則63服務(wù)名稱規(guī)則64服務(wù)命名規(guī)則65名稱空間命名規(guī)則661文檔說明1.1 編制說明是在中國電信信息化戰(zhàn)略規(guī)劃（ITSP）2.0 的總體指導(dǎo)下結(jié)合第二階段的“主動服務(wù)，優(yōu)化管理”的目標，為了實現(xiàn) IT 服務(wù)支撐的流程化、標準化、規(guī)范化,引入了 IT 系統(tǒng)的整合技術(shù) SOA。由于 CSB 在中國電信的和作用，CSB 的引入時機，CSB 平臺的選型依據(jù)，CSB 的實施方法等問題，缺乏系統(tǒng)而準確的論述，因而急需一份規(guī)范以指導(dǎo)的 CSB 建設(shè)。下圖所示 CSB 規(guī)范文檔在總體規(guī)范中的。圖

4、表 1-1： CSB 規(guī)范文檔在總體規(guī)范中的1.2 適用范圍作為中國電信 CTG-MBOSS 規(guī)范的重要組成部分，結(jié)合 CTG-MBOSS的總體框架和各目標系統(tǒng)的規(guī)劃，統(tǒng)一考慮 CRM 域內(nèi)部各系統(tǒng)，與其他域系統(tǒng)如 OSS、EDA、MSS、Billing 及樞紐系統(tǒng)的集成關(guān)系和服務(wù)要求，適用于中國電信集團公司下屬?。ㄊ校╇娦殴緦?CSB 的規(guī)劃和建設(shè)。1.3 閱讀指南第 2 章節(jié)對 CSB 概念進行了具體的定義，并闡述了 CSB 的集成類型，分析了 SOA 與 EAI 的異同點。第 3 章節(jié)闡述 CSB 的應(yīng)用體系架構(gòu)，強調(diào) CSB 必須承擔和 CRM，接入和 CRM 之間的服務(wù)交互，并列舉

5、了省 CRM 提供給和的服務(wù)列表。第 4 章節(jié)對 CSB 平臺的體系架構(gòu)進行了具體的圖示與描述，并詳細描述了服務(wù)提供層，服務(wù)邏輯層，服務(wù)配置層，服務(wù)層，文件交換的功能。第 5 章節(jié)對 CSB 的總體技術(shù)要求及性能指標性能要求上做出了詳細明確的闡述，并從可用性，可靠性，可擴展性，安全性對 CSB 平臺功能進行具體的說明。第 6 章節(jié)對 CSB 與服務(wù)實施原則進行了具體的闡述。附錄一規(guī)范編制。附錄二 ESB 相關(guān)介紹， IBM Message Broker ， Oracle AquaLogicService BUS，普元 TIP。附錄三 SOA 管控建議。附錄四 術(shù)語定義。附錄五定義了服務(wù)編碼規(guī)則

6、，服務(wù)名稱規(guī)則，服務(wù)命名規(guī)則，名稱空間命名規(guī)則。在中，對于規(guī)范要求的剛性程度采用以下級別：必須：表示該條目是必須，原則上不能這樣的要求。不允許（不可以）：標識該條目絕對。應(yīng)該（建議）：表示在某些特定條件下存在忽視該條目的理由，但是忽視或該條目時必須仔細衡量。不應(yīng)該（不建議）：表示在某些特定條件下存在所描述行為可接受或有效的理由，但實現(xiàn)該行為時必須仔細衡量?？蛇x（可以）：標識該條目確實可選。某些廠商可能出于市場或其它原因?qū)崿F(xiàn)該選項，另一廠商可能出于類似理由不實現(xiàn)該選項。1.4 起草起草為中國電信公司。1.5 解釋權(quán)的解釋權(quán)屬于中國電信公司。1.6的屬于中國電信公司。2綜述2.1 驅(qū)動力近幾年在中

7、國電信企業(yè)信息化戰(zhàn)略規(guī)劃（ITSP）1.0指導(dǎo)下,信息化建設(shè)取得了顯著成果，對企業(yè)運營的總體支撐能力日益增強。與此同時，技術(shù)體系方面存在著關(guān)鍵應(yīng)用系統(tǒng)支撐能力不足、數(shù)據(jù)質(zhì)量不高、系統(tǒng)間互聯(lián)互通不暢等問題；中國電信企業(yè)信息化戰(zhàn)略規(guī)劃（ITSP）2.0 提出技術(shù)體系應(yīng)繼續(xù)按照“模塊化、松耦合、可配置”的技術(shù)思路；遵循“數(shù)據(jù)與功能分離，功能與流程分離，應(yīng)用與展現(xiàn)分離，生產(chǎn)與分析分離”的技術(shù)原則，保證以相對穩(wěn)定的技術(shù)架構(gòu)去適應(yīng)不斷變化的企業(yè)需求。在 CRM 域內(nèi)存在多個系統(tǒng)，例如 10000 號、網(wǎng)廳、CRM系統(tǒng)，缺乏統(tǒng)一的交換點，CRM 域內(nèi)各系統(tǒng)之間存在網(wǎng)狀連接。各個功能重復(fù)、系統(tǒng)維護難、需求支持

8、難、管控難、投資大，協(xié)同難、客戶體驗不統(tǒng)一等問題。目前 CRM 域各系統(tǒng)已經(jīng)初步形成各種基礎(chǔ)構(gòu)件（例如管理、用戶信息保存）等，但是在使用基礎(chǔ)構(gòu)件組一個業(yè)務(wù)邏輯的時候，基本是采用硬編碼的方式，而不是基于流程技術(shù)和規(guī)則技術(shù)進行動態(tài)集成，導(dǎo)致系統(tǒng)不能很好的支持各種差異化需求（例如對特定的受理場景增加默認處理規(guī)則），不能很好的融入一些新的功能點（例如進行業(yè)務(wù)布點，例如推薦信息按需推送），難以對業(yè)務(wù)規(guī)則等通用的邏輯進行有效管理, 系統(tǒng)不能敏捷的對新需求做出反應(yīng);TMF( 電信管理) 所提出的 eTOM （ 增強的電信運營模型） 中的實現(xiàn)域（Fulfillment），為了提升管理子功能域，為各的、銷售、服

9、務(wù)提供支撐能力，需要專屬的平臺去支持實現(xiàn)域（Fulfillment）支撐流程。通過引入 SOA 的架構(gòu)可以有效解決目前 CRM 域內(nèi)存在的問題，采用 SOA 架構(gòu)可以重用現(xiàn)有服務(wù)，或者擴充服務(wù)，減少重復(fù)開發(fā)。采用 SOA 的服務(wù)分析方法對 CRM 域內(nèi)的主要業(yè)務(wù)流程進行分析，發(fā)現(xiàn)大量可復(fù)用的業(yè)務(wù)服務(wù)，需要建設(shè) CRM 域的服務(wù)總線去承載。通過引入 CSB 的概念后能實現(xiàn)應(yīng)用的規(guī)范化接入，應(yīng)用的集成由點對點接入轉(zhuǎn)換為松耦合的總線型接入，通過規(guī)范化的服務(wù)封裝標準對應(yīng)用服務(wù)進行封裝，發(fā)布到服務(wù)總線，通過服務(wù)總線的通入、消息處理和路由，結(jié)合流程集成平臺，實現(xiàn)服務(wù)在應(yīng)用間的集成和協(xié)作。2.2 CSB 概

10、念2.2.1 CSB 定義企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）是實現(xiàn) SOA 基礎(chǔ)架構(gòu)的關(guān)鍵組件， 它為 SOA 提供了一個底層的通訊架構(gòu)，用于實現(xiàn)服務(wù)請求者和服務(wù)調(diào)用者之間交互。企業(yè)服務(wù)總線在 SOA 架構(gòu)中實現(xiàn)服務(wù)間的智能化集成與管理中介，它提供了服務(wù)管理的方法和在分布式異構(gòu)環(huán)境中進行服務(wù)交互的功能，它支持異構(gòu)環(huán)境中的服務(wù)、消息以及基于的交互，并且具有適當?shù)姆?wù)級別和可管理性。SOA 是面向服務(wù)的體系結(jié)構(gòu)，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）通過這些服務(wù)之間定義良好的接口起來。接口是采用中立的方式進行定義的，它于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言, 這

11、使得構(gòu)建在各種這樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進行交互。服務(wù)總線是CRM 域內(nèi)所有服務(wù)的中心，CRM 業(yè)務(wù)服務(wù)層甚至業(yè)務(wù)流程層提供的服務(wù)都可以在CSB 上進行，從而對 CRM 域內(nèi)的所有服務(wù)進行統(tǒng)一管理和；解耦域內(nèi)各個子系統(tǒng)之間的調(diào)度。本次 CRM 規(guī)范中新引入的 CSB 為 ESB 在 CRM 域內(nèi)的應(yīng)用，主要功能是負責連通性和服務(wù)中介。2.2.2 CSB 集成類型SOA 是面向服務(wù)的體系結(jié)構(gòu)。是一個組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）通過這些服務(wù)之間定義良好的接口和契約起來。ESB 是邏輯上與 SOA 所遵循的基本原則保持一致的服務(wù)集成基礎(chǔ)架構(gòu)，它提供了服務(wù)管理的方

12、法和在分布式異構(gòu)環(huán)境中進行服務(wù)交互的功能。因此 CSB 的集成類型是服務(wù)的集成。服務(wù)集成：基于中間件技術(shù)建立應(yīng)用系統(tǒng)之間的連接，處理應(yīng)用之間的服務(wù)請求，進行通信協(xié)議、消息格式和消息內(nèi)容的轉(zhuǎn)換，并提供路由服務(wù)，實現(xiàn)服務(wù)請求和信息在應(yīng)用之間安全而有效的傳輸。支持多種服務(wù)集成方式，比如 JCA、Web 服務(wù)、Messaging、Adaptor 等；服務(wù)總線集成的對象是服務(wù)，所有集成的服務(wù)由服務(wù)目錄統(tǒng)一管理，服務(wù)被加入到服務(wù)目錄時，產(chǎn)生入站服務(wù)和出站服務(wù)。入站服務(wù)包括端口器和入站服務(wù)目的地，出站服務(wù)包括出站服務(wù)目的地和端口目的地。對于服務(wù)使用者來說，它看到的是端口器，調(diào)用消息發(fā)給端口器，由端口器將消息

13、路由到入站服務(wù)目的地，服務(wù)總線再將消息路由到出站服務(wù)目的地，出站服務(wù)目的地將消息路由到端口目的地，端口目的地將消息到正在使用的協(xié)議的總線調(diào)度模塊，由調(diào)度模塊調(diào)用相應(yīng)服務(wù)。2.2.3 SOA 與 EAI 的異同SOA 和 EAI 的相同點:1. 在技術(shù)層面有統(tǒng)一的數(shù)據(jù)和接口定義，可以方便整合各個異構(gòu)系統(tǒng)。2.都兼容各組件技術(shù)（,EJB），調(diào)用技術(shù)(RMI)。3.提供將簡單服務(wù)或者操作編排組織成更復(fù)雜的服務(wù)或者操作。4.支持各種通訊協(xié)議轉(zhuǎn)換、消息格式轉(zhuǎn)換。從技術(shù)角度上講，兩者是很類似的。SOA 和 EAI 的區(qū)別：1.SOA 提供了開放的規(guī)范和標準：數(shù)據(jù)定義 SDO，接口定義 SCA，服務(wù)編排 B

14、PEL;EAI 的規(guī)范和標準都是各個 EAI 平臺廠商私有的。2.SOA 服務(wù)調(diào)用時可以動態(tài)綁定服務(wù)。對于 EAI 來說，調(diào)用是設(shè)計時靜態(tài)綁定的。3.SOA 提供的服務(wù)接口是開放的，可以在 SOA 平臺以外異構(gòu)的接口調(diào)用 SOA 平臺上的服務(wù),如可以使用 EJB 接口調(diào)用 SOA 平臺上的服務(wù)。EAI 的接口是私有的，只能在 EAI 平臺內(nèi)部調(diào)用，EAI 只提供一種標準的接口來調(diào)用異構(gòu)系統(tǒng)的功能。4.從設(shè)計思想角度，SOA 旨在基于分布式的高可復(fù)用性服務(wù)集合來構(gòu)建企業(yè)應(yīng)用系統(tǒng)；EAI 只提供連接，流程編排，在設(shè)計思想方式上不做任何限制。5.SOA 的服務(wù)分為業(yè)務(wù)服務(wù)，基礎(chǔ)服務(wù)兩個層次；EAI

15、中的適配器相當于封裝已有系統(tǒng)的基礎(chǔ)服務(wù)。SOA 強調(diào)服務(wù)的復(fù)用性，實現(xiàn)異構(gòu)服務(wù)接口的互聯(lián)互通。EAI 強調(diào)集成異構(gòu)系統(tǒng)，把各個已有系統(tǒng)的異構(gòu)接口封裝為統(tǒng)一的接口。EAI 不強調(diào)服務(wù)復(fù)用，但也可以用 SOA 的思想配以 EAI 平臺來設(shè)計開發(fā)企業(yè)應(yīng)用。6.在設(shè)計層面，SOA 將應(yīng)用系統(tǒng)劃分為高可復(fù)用的服務(wù)組成的集合。服務(wù)提供層，服務(wù)邏輯層，服務(wù)配置層，服務(wù)層幾個層次。設(shè)計思路更強調(diào)從上到下，即從業(yè)務(wù)到技術(shù)。EAI 提供接口封裝技術(shù)，自動流程的編排。適配器相當于基礎(chǔ)服務(wù)。設(shè)計思路一般是從下而上，即從技術(shù)到業(yè)務(wù)。技術(shù)層面，SOA 是舊的組件技術(shù)和 EAI 技術(shù)的組合和升級。所以實施 SOA 項目，最

16、主要的還是在設(shè)計層面上如何把業(yè)務(wù)系統(tǒng)劃分為粒度合適，高聚合低耦合，復(fù)用性好又兼顧性能的服務(wù)集合。7.在技術(shù)層面，SOA 提供了開放的數(shù)據(jù)接口標準，方便異構(gòu)系統(tǒng)的互通互連，和 EAI功能相同，但更開放更靈活。ESB 是 SOA 的應(yīng)用的重要組件，ESB 服務(wù)總線是 EAI 總線的升級版，CSB 與 EAI之間主要有以下主要區(qū)別：圖表 2-1： CSB 與 EAI 差異CSBEAI概念面向服務(wù)，服務(wù)重用，重視標準和開放性應(yīng)用集成，面向接口，靠適配器完成數(shù)據(jù)轉(zhuǎn)換，目標為解決特定的問題CSB CRM 域內(nèi)各子系統(tǒng)之間的服務(wù)集成,并承擔與 公司 DEP 的服務(wù)集成在企業(yè)內(nèi)部各功能域之間的集成技術(shù)CSB

17、主要進行服務(wù)集成,量級輕,采用統(tǒng)一的接口數(shù)據(jù)格式與標準，支持服務(wù)組件架構(gòu)（SCA）主要進行應(yīng)用集成，量級重，接口數(shù)據(jù)格式和標準不統(tǒng)一，不支持服務(wù)組件架構(gòu)（SCA）運維CSB 平臺重視服務(wù)管控，服務(wù)重用可配置化平臺無服務(wù)概念，只有接口，無法進行管控，應(yīng)用整合需要開發(fā)適配器33.1CSB 應(yīng)用體系架構(gòu)綜述圖表 3-1： CSB 應(yīng)用體系架構(gòu)針對目前情況，CRM2.0 新引入 CSB，提供對服務(wù)的管理能力，包括生命周期、版本管理、質(zhì)量保證以及安全認證等，提供對異構(gòu)數(shù)據(jù)的封裝轉(zhuǎn)換能力，支持服務(wù)請求的查找、透明路由等，細化總線支持的接術(shù)標準。從業(yè)務(wù)功能層面主要包括以下幾個方面：必須承擔省 CRM 與DE

18、P 平臺進行交互的CSB（DEP 平臺）的服務(wù)交互：支持 CRM 系統(tǒng)把涉及與服務(wù)(3.3 省 CRM 與CRM 交互服務(wù))必須在 CSB上，CSB 能夠結(jié)合 CRM 提供的服務(wù), 通過路由、協(xié)議轉(zhuǎn)換、數(shù)據(jù)轉(zhuǎn)換的等基礎(chǔ)功能，按照<<中國電信級 CRM樞紐 - CEP 協(xié)議>>的要求，為DEP 提供相應(yīng)的全網(wǎng)服務(wù)。必須承擔省 CRM 與接入的服務(wù)交互：支持 CRM 系統(tǒng)把涉及與接入進行交互的服務(wù)(3.2 省內(nèi)交互服務(wù))必須在 CSB 上(這里的接入包括門戶或是其他的外部接入，如淘寶等) , CSB 能夠結(jié)合 CRM 提供的服務(wù), 通過路由、協(xié)議轉(zhuǎn)換、數(shù)據(jù)轉(zhuǎn)換的等基礎(chǔ)功能,

19、 按照<< CTG-MBOSS CRM2.0 客戶接觸門戶分冊 >>要求, 為接入渠道提供相關(guān)的服務(wù)。CRM 域內(nèi)不同子系統(tǒng)之間的服務(wù)請求者對服務(wù)提供者的調(diào)用，可以通過 CSB 來進行；由 CSB 提供智能路由、協(xié)議轉(zhuǎn)換、數(shù)據(jù)轉(zhuǎn)換、應(yīng)用適配，傳輸加密，流量控制等功能?？梢詫?CRM 系統(tǒng)對外系統(tǒng)提供的服務(wù)到 CSB 上，如提供給 OSS、Billing、MSS、ODS 等系統(tǒng)的服務(wù)。省內(nèi)其他業(yè)務(wù)域系統(tǒng)，通過 EAI/ESB 進行應(yīng)用的整合，由 EAI/ESB 將這些系統(tǒng)對 CRM 系統(tǒng)提供的能力，包裝成服務(wù)，到 CSB 上。如服務(wù)開通的服務(wù)、費用、帳務(wù)的服務(wù)等，供 CR

20、M 域內(nèi)的子系統(tǒng)使用。CRM 業(yè)務(wù)服務(wù)層甚至業(yè)務(wù)流程層提供的服務(wù)都可以在 CSB 上進行，從而對 CRM 域內(nèi)的所有服務(wù)進行統(tǒng)一管理和；解耦域內(nèi)各個子系統(tǒng)之間的調(diào)度。實現(xiàn)對所有服務(wù)的管控，包括對服務(wù)調(diào)用權(quán)限的定義和控制以及對服務(wù)全生命周期的管理，即管理每個服務(wù)從需求提出-開發(fā)-發(fā)布-部署上線-維護更新-下線的全過程。3.2 省內(nèi)交互服務(wù)名稱服務(wù)描述服務(wù)提供者參見CustInfoMaintain完成 的建立、修改、客戶群關(guān)聯(lián)、客戶關(guān)系關(guān)聯(lián)、客戶群組關(guān)聯(lián)、客戶歸并等 的操作。CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)CustPasswordMgr為客戶提供客戶 及 密

21、碼的 修改和 重置等功能。CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)CustAuthenticate根據(jù)客戶 、證件類型、證件號碼、業(yè)務(wù)號碼，對接入客戶進行識別驗證，返回識別驗證結(jié)果。CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)CustInfoQry根據(jù)輸入條件客戶的相關(guān)信息CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)CustPointsInfoQry根據(jù)獲取的客戶標識信息，按時段 信息， 信息包括當月新增 、當月可用、當月已用 等。CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)Cu

22、stPointExchange根據(jù)兌換規(guī)則進行兌換并兌換日志，兌換結(jié)果反饋CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)CustPointTransfer根據(jù)業(yè)務(wù)規(guī)則，客戶把自己擁有的部分或全部 轉(zhuǎn)贈給其他客戶CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)MarketResInfoQry根據(jù)、操作員和屬性信息（屬性編碼或者屬性名稱）， 信息CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)MktResMantain根據(jù)輸入的號碼信息占用/預(yù)占移動號碼CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)

23、EqptMaintNetworkQ ry根據(jù)省、地市、終端品牌或者售后網(wǎng)點的名稱關(guān)鍵字模糊 所在位置的售后網(wǎng)點信息，返回售后網(wǎng)點信息包括售后網(wǎng)點名稱、售后網(wǎng)點地址、業(yè)務(wù)受理范圍、營業(yè)時間、聯(lián)系 、附近標志性建筑、公交線路等信息。CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)OrderCreate根據(jù)獲取的訂單信息，進行訂單校驗，如果校驗通過，新增訂單 ，并啟動訂單處理流程，返回訂單保存結(jié)果。CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)OrderCancel用于獲取 樞紐轉(zhuǎn)發(fā)CRM 系統(tǒng)的撤單申請或省 CRM 本身發(fā)起的撤單申請，根據(jù)獲取的撤

24、單原因及訂單編號，進CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)行撤單審核、撤單校驗和訂單撤銷處理竣工操作，并啟動撤單處理流程，生成撤單 ， 返回保存結(jié)果。OrderUntreat用于獲取 樞紐轉(zhuǎn)發(fā)CRM 系統(tǒng)的退單申請，包括退單規(guī)則驗證和退單處理，并啟動退單處理流程，返回保存結(jié)果。CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)OrderChargeCalcul ate根據(jù)獲取的訂單信息，計算與訂單操作相關(guān)的 費用， 返回 費用信息CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)OrderInfoQry根據(jù)受理時間段

25、、業(yè)務(wù)號碼、受理操作員、客戶編碼等條件訂單，返回訂單信息(包括訂單狀態(tài)等)CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)pleteNotice向省訂單竣工/起租信息CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)OrderActionValid根據(jù)客戶標識、 實例標識和業(yè)務(wù)操作類型對即將受理的訂單進行可行性驗證，返回驗證結(jié)果CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)OrderChargeWriteO ff根據(jù)獲取的訂單信息和支付信息，對 費用進行銷帳， 返回銷帳結(jié)果。CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中

26、的 章節(jié)CustQuestionAccep t根據(jù)獲取的客戶問題信息，生成客戶問題受理單（按照不同的問題類型，形成投訴建議、故障申告、服務(wù)請求問題單），返回保存結(jié)果CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)CustQuestionQry根據(jù)通過問題單號等 條件對問題單的處理過程和結(jié)果進行 ，返回 情況CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)CustAppraiseRetur n根據(jù)客戶接觸后獲取的客戶評價，客戶問題單的客戶評CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范圖表 3-2：省內(nèi)交互服務(wù)列表3.3 省 CRM

27、 與CRM 交互服務(wù)服務(wù)名稱服務(wù)描述服務(wù)提供者參見CustInfoMaintain完成 的建立、修改、 、客戶群關(guān)聯(lián)、客戶關(guān)系關(guān)聯(lián)、客戶群組關(guān)聯(lián)、客戶歸并等 的操作。CRMCTG-MBOSS CRM2.0 技術(shù)規(guī)范中的 章節(jié)CustInfoQry根據(jù)輸入條件客戶的相關(guān)信息CRMCTG-MBOSS CRM2.0 技術(shù)規(guī)范中的 章節(jié)CustPointsInfoQ ry根據(jù)獲取的客戶標識信息， 按時段信息，信息包括當月新增、當月可用、當月已用CRMCTG-MBOSS CRM2.0 技術(shù)規(guī)范中的 章節(jié)價結(jié)果中的 章節(jié)MarketEvent

28、Manage管理維挽活動信息，包括新增、修改等CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)MarketInfoDeal獲取下發(fā)的工單信息，進行活動執(zhí)行。CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)MarketResResp接收 對省公司在商機轉(zhuǎn)化過程中提出的 申請反饋。CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)SellingNetworkQry用于 營業(yè)網(wǎng)點信息，根據(jù)地市、區(qū)縣 或者營業(yè)廳的名稱關(guān)鍵字模糊 所在位置的營業(yè)廳信息，返回營業(yè)廳信息包括營業(yè)廳名稱、營業(yè)廳地址、業(yè)務(wù)受理范圍、營業(yè)時間、 、附近標志性建

29、筑、公交線路等信息CRMCTG-MBOSSCRM2.0 技術(shù)規(guī)范中的 章節(jié)圖表 3-3：省 CRM 與CRM 交互服務(wù)等。CustPointExchan ge根據(jù)兌換規(guī)則進行 兌換并 兌換日志，兌換結(jié)果反饋CRMCTG-MBOSS CRM2.0 技術(shù)規(guī)范中的 章節(jié)OrderCreate根據(jù)獲取的訂單信息，進行訂單校驗，如果校驗通過， 新增訂單 ，并啟動訂單處理流程，返回訂單保存結(jié)果。CRMCTG-MBOSS CRM2.0 技術(shù)規(guī)范中的 章節(jié)OrderCancel用于獲取 樞紐轉(zhuǎn)發(fā)CRM 系統(tǒng)的撤單申請或省 CRM 本身發(fā)起的撤單申請，根據(jù)獲取的撤

30、單原因及訂單編號，進行撤單審核、撤單校驗和訂單撤銷處理竣工操作，并啟動撤單處理流程， 生成撤單 ，返回保存結(jié)果。CRMCTG-MBOSS CRM2.0 技術(shù)規(guī)范中的 章節(jié)OrderUntreat用于獲取 樞紐轉(zhuǎn)發(fā)CRM 系統(tǒng)的退單申請，包括退單規(guī)則驗證和退單處理， 并啟動退單處理流程，返回保存結(jié)果。CRMCTG-MBOSS CRM2.0 技術(shù)規(guī)范中的 章節(jié)OrderInfoQry根據(jù)受理時間段、業(yè)務(wù)號碼、受理操作員、客戶編碼等條件 訂單，返回訂單信息(包括訂單狀態(tài)等)CRMCTG-MBOSS CRM2.0 技術(shù)規(guī)范中的 章節(jié)pleteNotice

31、向省訂單竣工/起租信息CRMCTG-MBOSS CRM2.0 技術(shù)規(guī)范中的 章節(jié)MarketResResp接收 對省公司在商機轉(zhuǎn)化過程中提出的 申請反饋。CRMCTG-MBOSS CRM2.0 技術(shù)規(guī)范中的 章節(jié)4CSB 平臺體系架構(gòu)4.1 通用模型一個通用的 CSB 架構(gòu)，根據(jù)其功能的不同劃分成以下幾個層次：服務(wù)提供層、服務(wù)邏輯層、服務(wù)配置層，管理層，文件交換層，如圖 5-1 所示：圖表 4-1：CSB 參考模型4.2 CSB 服務(wù)提供模塊4.2.1 功能描述服務(wù)提供層提供 CSB 平臺和應(yīng)用系統(tǒng)的連接功能。CSB 平臺作為連接各種應(yīng)用的核心平臺，通過它的服務(wù)

32、提供層來實現(xiàn)與其它應(yīng)用系統(tǒng)的通信，并這些系統(tǒng)的。1. 協(xié)議適配必須支持協(xié)議轉(zhuǎn)換，將其他應(yīng)用系統(tǒng)的協(xié)議轉(zhuǎn)化為CSB標準的接入?yún)f(xié)議。并將請求數(shù)據(jù)至邏輯層做相應(yīng)處理。服務(wù)配置流量控制協(xié)議適配服務(wù)提供傳輸加密認證鑒權(quán)管理服務(wù)編排消息路由服務(wù)中介消息分發(fā)服務(wù)邏輯服務(wù)豐富消息組合數(shù)據(jù)轉(zhuǎn)換服務(wù)發(fā)現(xiàn)文件交換服務(wù)編排管理配置文件交換服務(wù)質(zhì)量管理配置目錄管理路由規(guī)則配置數(shù)據(jù)轉(zhuǎn)換配置日志審計權(quán)限管理容器 服務(wù)服務(wù)服務(wù)配置2. 認證鑒權(quán)必須提供對服務(wù)的權(quán)限控制的能力，根據(jù)需要可在不同級別上進行，如服務(wù)調(diào)用、服務(wù)中介的操作。3. 傳輸加密可以采用數(shù)字簽名、加密或同時使用兩種加密方式。4. 流量控制可以控制目標服務(wù)的請求

33、數(shù)量，防止對目標服務(wù)造成過大，可以動態(tài)調(diào)標服務(wù)的請求數(shù)量。4.3 CSB 服務(wù)邏輯模塊4.3.1 功能描述服務(wù)邏輯層是 CSB 服務(wù)總線邏輯處理的具體實現(xiàn)層，服務(wù)邏輯層包含的具體功能包括：1. 消息路由是基于一定的規(guī)則將數(shù)據(jù)或消息到合適的目標系統(tǒng)，是一種尋址功能，路由的規(guī)則存放在配置表中。動態(tài)路由通過條件轉(zhuǎn)移語句（或服務(wù)調(diào)用）分析消息，從而檢索某個數(shù)據(jù)元素或多個數(shù)據(jù)元素的數(shù)值。不同的業(yè)務(wù)服務(wù)目的地被賦予這個條件檢查的不同數(shù)值組合，允許將消息動態(tài)到多項業(yè)務(wù)服務(wù)。根據(jù)業(yè)務(wù)服務(wù)需求，轉(zhuǎn)換可用于一個或多個此類目的地。Ø 消息路由應(yīng)該支持以下幾種方式1) 基于內(nèi)容的動態(tài)路由服務(wù)請求者將請求消息

34、給 CSB，CSB 平臺根據(jù)消息內(nèi)容和事先定義好的路由規(guī)則決定應(yīng)調(diào)用的服務(wù)。圖表 4-2：基于內(nèi)容的路由示意圖2) 靜態(tài)路由這種路由方式主要用在請求/應(yīng)答的傳輸模式下，客戶端向 CSB請求時，CSB，CSB 查找要對服務(wù)進行。這種情況下，服務(wù) B 必須已在服務(wù)目錄中進行到相應(yīng)服務(wù)后，對服務(wù)進行調(diào)用。圖表 4-3：基于服務(wù)的路由示意圖2. 可以有消息組合功能： 從一個或多個應(yīng)用程序獲取多個消息并將其合并為單個信息，以作為新消息。入站消息可以來自應(yīng)用程序或可以為來自一組應(yīng)用程序的異步響應(yīng)消息，而這些應(yīng)用程序從消息拆分器模式（在下面描述）實現(xiàn)接收請求。3.可以有消息分發(fā)功能：將數(shù)據(jù)從一個應(yīng)用系統(tǒng)轉(zhuǎn)發(fā)

35、到另一個或者多個應(yīng)用系統(tǒng)，無需修改消息有效負載的格式或內(nèi)容。4.應(yīng)該有數(shù)據(jù)格式轉(zhuǎn)換功能：提供不同的數(shù)據(jù)模型間的轉(zhuǎn)換能力，系統(tǒng)間數(shù)據(jù)的差異性，負責在不同種類的系統(tǒng)和應(yīng)用之間進行數(shù)據(jù)的轉(zhuǎn)換，統(tǒng)一數(shù)據(jù)中的內(nèi)容和語法，并且負責維護在不同系統(tǒng)之間的數(shù)據(jù)結(jié)構(gòu)。它能在分布式的企業(yè)應(yīng)用系統(tǒng)中對和接收的數(shù)據(jù)進行設(shè)計，使得輸入的數(shù)據(jù)根據(jù)自定義的格式或規(guī)則進行合并、校驗、轉(zhuǎn)化、分解為輸出的數(shù)據(jù)，這樣，每個應(yīng)用系統(tǒng)都可以保留各自原有的數(shù)據(jù)，且不同應(yīng)用系統(tǒng)之間可以實現(xiàn)數(shù)據(jù)共享。在多個應(yīng)用系統(tǒng)之間實現(xiàn)數(shù)據(jù)轉(zhuǎn)換有兩種方式：一是在兩個應(yīng)用之間直接定義數(shù)據(jù)關(guān)系，二是引入通用數(shù)據(jù)模型，建立通用數(shù)據(jù)模型和各個應(yīng)用系統(tǒng)的數(shù)據(jù)模型之間

36、的轉(zhuǎn)換，而不是直接在應(yīng)用系統(tǒng)之間進行轉(zhuǎn)換。現(xiàn)有的 ESB 平臺在實現(xiàn)數(shù)據(jù)轉(zhuǎn)換時多是采用上述第二種轉(zhuǎn)換方式，實現(xiàn)通用數(shù)據(jù)模型和各個應(yīng)用系統(tǒng)的數(shù)據(jù)模型之間的轉(zhuǎn)換，而不是直接在應(yīng)用系統(tǒng)之間進行轉(zhuǎn)換。這樣做的好處在于：被集成的應(yīng)用系統(tǒng)之間是松耦合的關(guān)系，當某一應(yīng)用系統(tǒng)發(fā)生改變時只需要改變該系統(tǒng)的數(shù)據(jù)模型與通用數(shù)據(jù)模型之間的轉(zhuǎn)換關(guān)系、傳輸協(xié)議特定格式與 ESB 統(tǒng)一消息模型的轉(zhuǎn)換、各服務(wù)間數(shù)據(jù)模型的轉(zhuǎn)換。5.可以有服務(wù)編排功能：每個服務(wù)均可以承擔服務(wù)提供者和服務(wù)使用者兩種，服務(wù)使用者通過服務(wù)總線的接口獲取相應(yīng)的服務(wù)；ESB 提供服務(wù)編排的能力； 服務(wù)編排是指可以通過開發(fā)或者第流程配置的方式實現(xiàn)服務(wù)組合，

37、形成新的服務(wù)的過程。6.應(yīng)該有面向服務(wù)的中介功能：為了支持服務(wù)請求者和提供者之間的交互所必需的服務(wù)虛擬化和面向服務(wù)的連接，ESB 提供了中介流。中介流（通常簡稱為中介）包括通過某個接出點接收來自請求者的入站請求消息，處理請求消息，然后使用某個接入點向提供者出站消息。如果適用的話，中介還可以包括接收相關(guān)的入站響應(yīng)消息，處理相關(guān)的響應(yīng)消息，以及向請求者出站響應(yīng)消息。ØØØ7.應(yīng)該提供位置透明性的服務(wù)路由和服務(wù)。應(yīng)該支持多種消息傳遞型式(請求/響應(yīng)，單路請求，發(fā)布/訂閱等等) 。應(yīng)該支持廣泛使用的傳輸協(xié)議(例如 HTTP)等等 ?？梢杂蟹?wù)發(fā)現(xiàn)功能：服務(wù)提供者可以組織到

38、可執(zhí)行的目錄中。使用者可以搜索這樣的目錄來查找所需服務(wù)的提供者。8.應(yīng)該支持服務(wù)豐富功能：將請求消息在 CSB 平臺上進行消息的豐富，構(gòu)造新的符合服務(wù)提供者要求的消息，對豐富后的消息調(diào)用相應(yīng)的服務(wù)。4.4 CSB 服務(wù)配置模塊4.4.1 功能描述1. 服務(wù)配置應(yīng)該包括系統(tǒng)運行參數(shù)、業(yè)務(wù)功能參數(shù)的配置，如服務(wù)的并發(fā)數(shù)，優(yōu)先級，可用性，重試性，超時的配置等和原有服務(wù)的配置（對于新的服務(wù)在總線上配置）。2.服務(wù)Ø必須提供服務(wù)組件的服務(wù)和服務(wù)發(fā)布功能，實現(xiàn)服務(wù)接口、服務(wù)運行與服務(wù)參數(shù)等各種服務(wù)信息的和發(fā)布。Ø應(yīng)該建立服務(wù)目錄和服務(wù)庫，對這些服務(wù)以及服務(wù)的元數(shù)據(jù)進行定義和，以便進行服

39、務(wù)的查找、發(fā)布、和管理。Ø3.建議支持服務(wù)批量發(fā)布、Web 界面發(fā)布和 API 方式發(fā)布等多種發(fā)布方式。權(quán)限管理ØØØØØØ必須提供組織、用戶、及的動態(tài)維護；必須支持對組織的分級管理，支持對組織級別及層次的動態(tài)定義；所擁有的權(quán)限必須包括能夠管理的數(shù)據(jù)范圍和操作權(quán)限的集合；操作權(quán)限集合應(yīng)該包括使用權(quán)限(如：增加、刪除、修改等)和兩類；當所擁有權(quán)限，支持將其擁有的權(quán)限進行轉(zhuǎn)賦；必須支持一個用戶可以擁有多個；ØØØ必須支持自動生成用戶的初始，并提供的修改功能；不允許以明文的方式用戶；必須支持自動或人工

40、生成賬號，賬號不能重復(fù)，用戶在組織間調(diào)整時，無需調(diào)整用戶的賬號；Ø應(yīng)該支持設(shè)置賬號有效期及其到期后設(shè)置該賬號狀態(tài)為“無效”，刪除用戶時，只需將該用戶置為“無效”狀態(tài)；4.數(shù)據(jù)轉(zhuǎn)換配置Ø應(yīng)該具有配置不同數(shù)據(jù)格式轉(zhuǎn)換的能力，能夠?qū)碜圆煌瑧?yīng)用系統(tǒng)的數(shù)據(jù)進行識別和。Ø建議以圖形化方式定制不同的數(shù)據(jù)轉(zhuǎn)換邏輯，實現(xiàn)數(shù)據(jù)格式的轉(zhuǎn)換和數(shù)據(jù)內(nèi)容的整理；5.路由規(guī)則配置Ø建議動態(tài)路由通過條件轉(zhuǎn)移語句（或服務(wù)調(diào)用）分析消息，從而檢索某個數(shù)據(jù)元素或多個數(shù)據(jù)元素的數(shù)值。Ø允許將消息動態(tài)到多項業(yè)務(wù)服務(wù)，不同的業(yè)務(wù)服務(wù)目的地被賦予這個條件檢查的不同數(shù)值組合配置。6.服務(wù)質(zhì)

41、量管理配置Ø建議針對不同的服務(wù)請求者提供不同質(zhì)量的服務(wù)響應(yīng)的能力，例些服務(wù)的請求需要在事務(wù)中完成，有些服務(wù)的交互需要保證其可靠性，完整性。Ø建議支持參與者或系統(tǒng)管理員他們的服務(wù)質(zhì)量需求，包括：請求的、消息內(nèi)容的加密和、服務(wù)交互的自動審計以及應(yīng)該如何傳遞他們的請求（例如，進行優(yōu)化以提高速度或降低成本）。Ø建議設(shè)置服務(wù)級別協(xié)議 (SLA)，SLA 定義了業(yè)務(wù)和服務(wù)所期望服務(wù)的精確級別和質(zhì)量。用戶可以根據(jù) SLA 的指標配置觸發(fā)提示的規(guī)則。一個提示可以配置多級嚴重性，包括正常、提示、輕微、和嚴重。每個業(yè)務(wù)或服務(wù)可以組合多個提示情況，而每個提示可以基于下列參數(shù)。1). 成

42、功率，失敗率2). 消息數(shù)3). 錯誤數(shù)4). 故障切換/重試次數(shù)5). 驗證錯誤數(shù)6). 響應(yīng)時間，最小響應(yīng)時間，最大響應(yīng)時間Ø 用戶可設(shè)置 SLA 提示，向運行團隊通知業(yè)務(wù)和質(zhì)量有關(guān)的問題。服務(wù)的狀況，或與提供的服務(wù)7. 服務(wù)編排管理配置可以將一個或多個服務(wù)進行編排而形成的組合服務(wù)，組合服務(wù)也可被其它服務(wù)調(diào)用。4.5 CSB 服務(wù)模塊4.5.1 功能描述CSB服務(wù)、容器、日志審計的功能。CSB平臺可模塊主要包括服務(wù)以支持以一定間隔(不大于15分鐘)向系統(tǒng)提供告警與指標數(shù)據(jù)。服務(wù)告警信息、指標可以支持JMS、SNMP或者等。服務(wù)信息可以提供給統(tǒng)一平臺。1.服務(wù)服務(wù)必須包括服務(wù)、操作

43、等級別的調(diào)用 / 失敗次數(shù)、平均響應(yīng)時間等信息。2.容器Ø應(yīng)該對服務(wù)容器的指標進行，例如服務(wù)容器運行狀態(tài)、服務(wù)容器消耗、服務(wù)容器所包含服務(wù)的數(shù)量、當前服務(wù)容器中的請求數(shù)量等。Ø3.應(yīng)該對于登錄及越權(quán)調(diào)用服務(wù)的行為進行。日志審計日志是系統(tǒng)運行過程中，在某一時刻對系統(tǒng)某一運行狀態(tài)的，其主要目的是對系統(tǒng)自身的運行狀態(tài)、過程與性能進行跟蹤、分析與調(diào)測。Ø應(yīng)該進程的處理情況，包括每個步驟的處理成功與否，方便事后跟蹤查找出錯原因。Ø建議各應(yīng)用系統(tǒng)到 CSB 平臺的數(shù)據(jù)傳輸情況，日志內(nèi)容，包括數(shù)據(jù)源 IP，數(shù)據(jù)目的 IP，文件名稱、大小，服務(wù)調(diào)用開始時間，服務(wù)調(diào)用功能

44、結(jié)束時間等相關(guān)信息。ØØ應(yīng)該保留的日志信息供。建議對系統(tǒng)的參數(shù)設(shè)置、操作的日志。4.6 文件交換模塊4.6.1 功能描述在實施過程中，建議文件交換組件與其他組件分別部署以避免性能影響。與DEP 的批量信息交互可以由 CSB 承擔。省內(nèi)的批量文件交換建議由 CSB 承擔。1. 可以進行目錄管理目錄管理格式是文件交換所使用的 FTP 協(xié)議的目錄結(jié)構(gòu)及文件命名規(guī)則等約定。批量數(shù)據(jù)文件由 CSB 平臺提供統(tǒng)一的 FTP 服務(wù)器和空間。FTP 用戶根據(jù)系統(tǒng)對目錄的需要設(shè)置。目錄結(jié)構(gòu)如下圖所示：應(yīng)答目錄上傳目錄緩存目錄交互業(yè)務(wù)分類目錄1上傳目錄省內(nèi)交互目錄請求歸檔應(yīng)答歸檔應(yīng)答目錄上傳目

45、錄緩存目錄目錄管理交互省內(nèi)歸檔上傳目錄省內(nèi)交互目錄圖表 4-4：管理目錄各類目錄及文件名編碼規(guī)則及權(quán)限如下表所示：序號目錄/文件類型編碼規(guī)則說明1目錄管理CSBCSB 具有權(quán)限及其所有子目錄的權(quán)限；業(yè)務(wù)分類目錄2緩存目錄目錄緩存目錄回復(fù)目錄回復(fù)目錄目錄序號目錄/文件類型編碼規(guī)則說明2業(yè)務(wù)目錄業(yè)務(wù)功能編碼業(yè)務(wù)功能說明參見中國電信級 CRM樞紐 CEP 協(xié)議主數(shù)據(jù)的說明，業(yè)務(wù)系統(tǒng)擁有全部子目錄權(quán)限。3交互headquarters4省內(nèi)交互province5上傳目錄upload6目錄download7回復(fù)目錄reply8應(yīng)答目錄response9緩存目錄mqsiarchive10請求歸檔hqreqa

46、rchive只有 CSB 具有權(quán)限；11應(yīng)答歸檔hqresparchive只有 CSB 具有權(quán)限；12省內(nèi)歸檔provincearchive只有 CSB 具有權(quán)限；13交互請求文件機構(gòu)編碼 +業(yè)務(wù)功能編碼 +日期 + 序號 + “.xml”機構(gòu)編碼參見CEP 協(xié)議主數(shù)據(jù)說明；業(yè)務(wù)功能編碼參見CEP 協(xié)議主數(shù)據(jù)說明； 協(xié)議編碼參見主數(shù)據(jù)說明；日期格式為 YYYYMMDD；序號由系統(tǒng)自動產(chǎn)生，三個字節(jié)字符串。14交互應(yīng)答正確文件機構(gòu)編碼 +業(yè)務(wù)功能編碼 +日期 +序號 +“.xml.ok”在請求文件名稱的基礎(chǔ)上加上“.ok”的后綴。15交互應(yīng)答錯誤文件機構(gòu)編碼 +業(yè)務(wù)功能編碼 +協(xié)議編碼 +日期

47、+序號 +“.xml.err”在請求文件名稱的基礎(chǔ)上加上“.err”的后綴。圖表 4-5：目錄文件命名規(guī)則及權(quán)限2. 可以進行文件交換文件交換由發(fā)起方、落地方、CSB 平臺及CRM樞紐按照目錄及文件的約定進行文件的上傳、遷移、與備份。省公司系統(tǒng)發(fā)起接收處理流程：序號目錄/文件類型編碼規(guī)則說明16省內(nèi)交互數(shù)據(jù)文件From+業(yè)務(wù)功能編碼+to+ 業(yè)務(wù)功能編碼+數(shù)據(jù)說明+日期+序號+.后綴省內(nèi)系統(tǒng)間文件交換不采用 CEP 協(xié)議，采用文件名中定義傳輸者接收者的方式表示需要傳送到的目的系統(tǒng)。數(shù)據(jù)說明是對文件內(nèi)容進行簡要說明，由傳輸和接收雙方系統(tǒng)進行約定，例如：custinfo、 res 等。數(shù)據(jù)說明后綴

48、按照雙方系統(tǒng)的約定格式，例如 txt、xml、gzip、bin 等。17省內(nèi)交互數(shù)據(jù)文件成功文件From+業(yè)務(wù)功能編碼+to+ 業(yè)務(wù)功能編碼+數(shù)據(jù)說明+日期+序號+.后綴+.ok由數(shù)據(jù)接收方向數(shù)據(jù)發(fā)起方給出的處理成功標志文件，文件名由省內(nèi)交互數(shù)據(jù)文件+.ok。18省內(nèi)交互數(shù)據(jù)文件失敗文件From+業(yè)務(wù)功能編碼+to+ 業(yè)務(wù)功能編碼+數(shù)據(jù)說明+日期+序號+.后綴+.err由數(shù)據(jù)接收方向數(shù)據(jù)發(fā)起方給出的處理失敗標志文件，文件名由省內(nèi)交互數(shù)據(jù)文件+.err。省內(nèi)方CSB平臺樞紐接收方1、方上傳文件2、CSB遷移文件3、傳輸至樞紐4、DEP遷移文件5、接收方文件6、接收方處理文件7、應(yīng)答文件上傳到DE

49、P9、CSB應(yīng)答文件8、DEP遷移文件11發(fā)起方應(yīng)答文件10、CSB遷移文件12發(fā)起方處理應(yīng)答文件圖表 4-6：省公司系統(tǒng)-公司系統(tǒng)1)發(fā)起方系統(tǒng)在生成請求文件后將請求文件 FTP 到 CSB 該業(yè)務(wù)分類-交互-上傳目錄。2)CSB 自動定時掃描，將請求文件遷移到發(fā)起方上傳目錄的子目錄緩存目錄中。3)CSB 把發(fā)起方請求文件通過 FTP 上傳到DEP 平臺該機構(gòu)目錄-該業(yè)務(wù)分類目錄-上傳目錄下，同時備份至 CSB 平臺“請求歸檔目錄”中。4)DEP 自動定時掃描，將發(fā)起方上傳目錄的請求文件遷移到接收方的目錄。在遷移完成后同時將請求文件備份到發(fā)起方上傳目錄的子目錄緩存目錄中。5)接收方系統(tǒng)目錄的請求文件并刪除請求文件（防止下次重復(fù)處理）。6)接收方系統(tǒng)進行業(yè)務(wù)處理后按照應(yīng)答文件的規(guī)則生成應(yīng)答正確文件或應(yīng)答錯誤文件。7)接收方系統(tǒng)把應(yīng)答文件放在落地方目錄的子目錄的回復(fù)目錄。8) DEP 自動定時掃描，將接收方系統(tǒng)回復(fù)目錄的應(yīng)答文件遷移到發(fā)起方的應(yīng)答目錄。在遷移完成后同時將應(yīng)答文件備份到落地方目錄的子目錄緩存目錄中。9) CSB 自動定時掃描，DEP 平臺該機構(gòu)目錄-該業(yè)務(wù)分類目錄-目錄下-回復(fù)目錄下的應(yīng)答文件，并刪除 DEP 平臺上