Telfort20融合计费项目总体设计方案V020

ProductversionConfidentialitylevel

Telfort20融合计费产品版本密级

项目总体设计方案秘密

Totalpages：

V020共214页

HuaweiTechnologiesCo.Ltd.

华为技术有限公司

Telfort2.0项目总体技术方案

PreparedbyTelfort2.0分析设计组Dateyyyy-mm-dd

拟制日期

ReviewedbyDateyyyy-mm-dd

评审人日期

ApprovedbyDateyyyy-mm-dd

批准日期

AuthorizedbyDateyyyy-mm-dd

签发日期

HUAWGI

HuaweiTechnologiesCo.,Ltd.

华为技术有限公司

Allrightsreserved

版权所有侵权必先

Revisionrecord修订记录

DateRevisionCRSectionChangeDescriptionAuthor

日期VersionID/Number修改描述作者

修订Defect修改

版本ID章节

CR号

2008-09-120.10根据各专题的写作与检视结果，初Telfort2.0分析

稿合并完成

设计组

2008-10-040.20根据客户CR修正部分描述。Telfort2.0分析

1.DC模块将被客户的CACS替换

2.FM将被KPN系统替换设计组

部分功能的修改

1、帐户优惠方案的修改

2、接触管理的修改与批注（与

IPCC部分信息未达成一致）

3、MDS方案修改

4、Realtimecharing

5、修改订单落地方案，增加设计

方案与增加订单查询及订单修

改

6、补充SCP与Rating&Billing

集成方案（语音计费、VMS计

费与AOC等业务）

7、预付费生命周期管理

增加功能分解：

1、扫描件的存储与管理

DistributionLIST分发记录

CopyHolder'sName&RoleIssueDate

No.持有者与角色分发日期

1<PDTR&DRepresentative开发代表》yyyy-mm-dd

2<SE系统工程师〉yyyy-mm-dd

3<SEExtendedTeammembersSE扩展构成员〉yyyy-mm-dd

4<Others其它〉yyyy-mm-dd

Catalog目录

Telfort2.0项目总体技术方案1

HuaweiTechnologiesCo.,Ltd1

Revisionrecord修订记录2

DistributionLIST分发记录2

1项目背景10

1.1Telfort现状介绍10

1.1.1TelfortMobile10

1.1.2Telfortinternet11

1.2目标业务12

1.3目标用户数13

1.4实施阶段13

2系统总体描述（0级视图）14

2.1系统总体构架14

2.1.1服务操纵层15

2.1.2计费帐务层15

2.1.3客户服务层16

2.1.4版本配套关系16

2.2系统外部接口描述（暂不写作，将引用架构与接口有关交付内容）16

2.3系统物理组网（暂不写作，将引用物理部署内容）17

2.3.1系统总体物理组网17

3系统方案设计（1级视图）17

3.1Rating&Billing与PC产品定义配合17

3.1.1业务需求描述17

3.1.2系统功能分解分配17

3.1.3接口说明18

3.1.4性能要求18

3.2Rating&Billing与帐务管理提供已批价CDR、Bill配合18

3.2.1业务需求描述18

3.2.2系统功能分解分配19

3.2.3接口说明19

3.2.4性能要求19

3.3Rating&Billing与CC资料接口20

3.3.1业务需求描述20

3.3.2系统功能分解分配21

3.3.3接口说明23

3.3.4性能要求23

3.4预付费与后付费互转23

3.4.1业务需求描述23

3.4.2系统功能分解分配24

3.4.3接口说明25

3.4.4性能要求26

3.5Rating&Billing支持帐户级优惠26

3.5.1业务需求描述26

3.5.2系统功能分解分配26

3.5.3接口说明28

3.5.4性能要求28

3.6预付费用户的实时销帐28

3.6.1业务需求描述28

3.6.2系统功能分解分配30

3.6.3接口说明32

3.6.4性能要求32

3.7后付费用户的信控处理方式32

3.7.1业务需求描述32

3.7.4性能要求34

3.8.1业务需求描工34

3.8.3接口说明36

3.8.4性能要求36

3.9.1业务需求描述36

3.9.3:键计费业务流程37

3.9.5性能要求40

3.10MDS与RATING的配合40

3.11.2］统功能分解分配42

3.11.3业务流程说明45

3.11.4接口说明46

3.11.5性能要求47

3.12营销方案设计47

3.12.1业务需求描述47

3.12.4接口说明57

3.13.1业务需求描述59

3.13.2设计思路59

3.13.3系统功能分解分配60

1.扩展用户自定义条件，增加合同期，当合同期不一致时能够使用不一致的优惠；62

3.13.4业务流程说明64

3.13.5接口说明65

3.13.6性能要求65

3.14NumberPorting流程65

3.14.1业务需求描述65

NumberPorting*施程分成下歹U3个流程65

3.14.2系统功能分解分配65

Ecare需要调用接口部件封装的罚金杳询接口，显示用户需要缴纳的罚金72

NP.NPMS.FR.001系统管理支持NPMS链接入口73

3.14.3COIN消息定义79

3.14.4PortIn订单流程定义83

1）活动1：0L0Validate请求85

1）活动1：TransitOperator请求87

2）活动2：TransitOperator应答88

1）活动1：Ready2Release请求88

1）活动1：老号码废弃89

2）活动2：PortIn号码服务开通89

3）活动3：Portin号码合同生效90

4）活动4：计费激活90

1）活动1：发送同步原始运营商请求90

1）活动1：TransitOperator同步请求91

2）活动2：TransitOperator同步应答91

1）活动1：0L0握手同步请求接口92

3.14.5PortOut订单流程定义93

1、资源有效性校验94

2、用户有效性校验94

3、业务数据有效性校验94

1）活动1：TransitOperator请求95

2）活动2：TransitOperator应答96

（ReadyToRelease在DNO侧做了什么情况需要现场确认），96

COIN有关消息：10997

COIN有关消息：107,10897

1）活动1：TransitOperator同步请求97

2）活动2：TransitOperator同步应答98

1）活动1：号码销户98

2）活动2：资源管理状态更新98

3）活动3：计费通知98

COIN有关消息：11098

3.14.6Porting请求修改与取消处理方式99

3.14.7Porting准备/同步通知接收处理102

3.14.8Porting请求的状态定义104

3.14.9Porting请求的超时处理方式107

3.14.10SP/ESP的Porting处理方式107

3.14.11Phasel的架构方案108

（4）NPMS修改程序或者配置从华为的通道读取数据，进行处理110

3.14.12寸：斐111兑9]110

3.14.13性能要求119

3.15.1业务需求描述119

3.15.2系统功能分解分配121

3.15.3业务流程说明131

3.15.5性能要求135

3.16扫描件存储与检索136

3.16.1系统架构示意图137

3.16.2业务处理流程139

3.16.3OSMS系统介绍140

3.16.4内部接口140

3.17资源管理方案141

3.17.2Voucher管理流程146

3.18.1业务需求描述148

3.18.2设计思路149

3.18.3系统功能分解分配149

3■18•5JZIIi'll"月■■■•>>■■••>■■•>>■■•>■■>•>>>>•>>>>•>>>>•>>>>•■■>>>>>>>>>>>>>>>>>>>>■••>>•••>>•••>>•••>■•••>••••>••••>■•••>••••>••■•>•153

3.18.6性能要求154

3.20IPCC与CCBS集专180

3.20.1数据库建库说明180

3.20.2工号、权限统一管理180

3.20.4客户接触信息记录与查询（刘波、荀礼勇）186

3.20.5知识库方案（内外网知识库）188

3.21BI与CCBS集成专题189

3.21.1传输方式190

3.21.5接口单元编码191

3.21.6文件命名规则191

3.21.7接口文件格式-数据文件191

3.22Telecommanager方案193

3.22.1实现思路193

3.22.2设计方案193

3.22.3内部接口194

3.23帐户优惠方案设计194

3.23.1业务需求描述194

3.23.2设计思路195

3.23.3系统功能分解分配195

3.23.4业务流程说明195

3.23.5接口说明196

3.23.6性能要求196

3.24收入保障（与Ectel讨论以后再补充）196

3.25VASRealRimeCharging&Provisioning解决方案196

3.25.1业务需求描述203

3.25.2设计思路204

3.25.3系统功能分解205

3.25.4业务流程说明206

3.25.5接口说明206

3.25.6性能要求206

4系统内部各部件的接口汇总说明（待完全定稿后汇总）207

4.1系统内部各部件的接口说明207

4.1.1CC/POS部件接口说明207

4.1.2E-care/E-shop部件接口说明207

4.1.3订单接口说明207

4.1.4品口说明207

4.1.5INV部件的接口说明207

4.1.6Rating&Billing接口说明207

4.1.7MDS部件接口说明207

4.1.8PRO部件接口说明207

4.1.9IPCC部件的接口说明207

4.1.11报表部件的接口说明208

5系统包需求及其需求分解208

6附录：计费与服务开通接口上下文环境209

6.1.1InterfaceContextDiagram210

6.2.1InterfaceContextDiagram212

6.3Real-timecharingDomain（需要根据DA决议修改）213

6.3.1InterfaceContextDiagram213

Keywords关键词：Telfort.CCBS、CBS、总体设计方案

Abstract摘要：本文档要紧描述Telforl2.0融合计费项目的系统构成、部件部署、关键

业务流程与方案、内外部接口说明，与系统整体的需求包与需求分解。在结合Telfort2.0的

外部系统环境进行方案分析与设计的基础上，本文档侧重在Huawei解决方案内部的设计说

明，Huawe懈决方案与Telfort外部系统的方案将在与局方的系统架构与接口文档中进行说

明。

Listofabbreviations缩略语清单:

Abbreviations缩略语Fullspelling英文全名Chineseexplanation中文解释

TF2.0Telfort2.0projectTelfort2.0项目

CCBSCustomCare&BillingSystem综合客户管理系统，包含Custom

Care、Billing&BillFormatting>AR、

DC、PC、PRM、Mediation、

Provision>Inventory

BOSSBusiness&Operation业务运营支撑系统，是中国移动的

SupportingSystem称谓。文中指CCBS。

CCCustomCare客户关怀管理模块

ARAccountReceivable应收款管理模块

DCDebtCollection催欠管理模块

PCPricingCatalogue产品目录管理模块

BFBillFormatting帐单格式化模块

ProProvision服务开通模块

MDMediation采集预处理模块

InvInventory资源管理模块

DWHDataWarehouse数据仓库

CBSConvergenceBillingSystem融合计费系统，包含预付费与后付

费

OCSOnlineChargingSystem在线计费系统

EBITDAEarningsBeforeInterest,利息、税收与折旧、摊销前收入

Taxes,Depreciationand

Amortization

TTMTimetoMarket上市时间

TCOTotalCostofOwnership总拥有成本

SMESmallMediumEnterprises中小企业

ESPEnhancedServiceProvider增强服务提供商

1项目背景

1.1Telfort现状介绍

Telfort是于1997年在荷兰成立的一家独立移动运营商，他将自己定位于移动市场的挑

战者。在2005年Telfort被荷兰最大的固定/移动运营商KPN收购。收购后两家的网络架构进

行了整合，Telfort将会把其网络迁移到KPN。今天Telfort已经成为KPN整体品牌卜•的挑战品

牌。Telfort将作为,关注价格，细分市场的增强服务提供商（ESP）,这是KPN对Telfort品牌与

历史定位。

同时，K.PN在2006年收购了荷兰的Internet服务提供商荷兰Tiscali（internationalTiscali

group的一部分），并重新进行品牌包装交由Telforl管理与运营。因此，Telfort同时包含Mobile

与Inlernel业务。

为提高Telforl的EBITDA,同时也为了支撑其在Mobile与Iniernet业务的融合与对应组织

结构与人员进行调整，Telfort需要在其IT支撑系统上进行改造，目标包含有：

•Fastertimetomarket（TTM）

•LowerTCOofIT

本次的支撑系统范围为融合的CRM&Billing系统，也就是Telfort2.0项目。（注：在此

前;有Telfort1.0项目，只涵盖预付费业务部分，目前尚未实施，将被同时包含在Telfort2.0

中，因此Telfort2.0是个预付费融合、Mobile/Internel融合的CRM&Billing解决方案）

1.1.1TelfortMobile

目前的Telforl移动基础设施的特点是：

•大量的应用

•众多专有接口

•一个复杂的系统架构

•系统支离破碎，数据冗余在多个系统，数据复制不总是完全正确复制

复杂系统的堆栈含有大量的冗余功能，比如不一致的系统（大致相同的功能）是用于消

费者与企业的部分，这导致了卜列结果:

成本高

需要较多人力（操作，质量保证，投诉处理）

系统保护复杂

产品的灵活性低，响应市场时间长

开发新产品/服务时需要复杂的，定制的接口开发

没有E2E服务保证

收入保障流程复杂

客户操作复杂，很难实施有效的客户的自助服务

Telfort当前移动业务支撑系统架构如下（由欧洲厂商C叩gimini等提供管理服务）：

Sct)|j<rtoigarPayments&Collection

OPTA

SiSAHAiCRIa-VouehM

PWICW)

InventoryMat

Sales&

Channel

•Customer

Interface5加5

FAfWOO

RetailBilling

F""一MxeflPtCRI■■■1H"

►CENDF1S

Ava”ACO

卡加：HPMS：C»

：CSCWR；,

SupplierPartner

Billing

C0V(Cfl1

,•.JSPAnalyticalCRM

WholcMloBilling►ADC?

ESP-GW

—-VolJeN"1•Telfort

1.1.2Telfortinternet

由于历史的原因荷兰Tiscali的CustomerCare与billing系统被外包给Tiscaliservices管理,

Tiscaliservices的平台为多个国家服务，外包合同将在09年6月份结束，开发商为：

•Billing:Geneva

•CRM:Siebel

GreenISPApplicationArchitecture(eTOMmapping)

OperationalFulfillmentAssuranceBilling

VISP

tiscali.

ifnove

Telfort.

Wholesale

AOL>>

&OI.CON

ABEL

^SiSi

城kpn

COIN.mm

rnn

FatrmivFrMKUonwn*0.6

1.2目标业务

Telfort2.0需要支撑的(要紧)业务包含如下，其中，移动业务中包含预付费与后付费

业务，关于Internet业务，仅仅包含后付费业务：

•MobileVoiceservices(PrepaidandPostpaid)

oVoice

oVoiceRoaming

oVoiceMail

•MobileDataservices(PrepaidandPostpaid)

oGPRS

oGPRSRoaming

oWAP/WAPPush

oSMS

oSMSpremium

oMMS

oSMSRoaming

oMMSRoaming

oContentService

•InternetAccessservices(ADSL,VDSL)(Postpaidonly)

•InternetVoIPservices(Postpaidonly)

•InternetValueAddedservices(Postpaidonly)

oeMail

oHomepage

oDomainregistration

oKeyman/F-secure

另外，从客户的角度看，Telforl2.0需要支持如下类型客户:

•Consumer

•Business(SMEonly),关于具有复杂组织结构、特殊网络业务类型的集

团客户不在支持的范围之内。

再有，由于Telfort本身作为KPN的一个增强服务提供商，因此原则上针对其它ESP、

MVNO业务的支持不在Telfort2.0范围之内，但由于考虑到网络与系统的变迁方便，针对话

单处理、服务开通部分可能会涉及我们的Mediation与Provision,需要参考更全面的方案设计

内容。

1.3目标用户数

整个系统需要支撑到Telfort今后5年的业务进展(即从2009年到2013年)，在这个过程

中，系统需支撑的用户数估计如下表所示：

200820092010201120122013

Subscriberseoyeoyeoyeoyeoyeoy

Activeprepaidsubscribers920,000930,000940,000940,000940,000940,000

RegisteredPrepaid1,150,01,150,01,160,01,170,01,170,01,170,0

subscribers000000000000

1,000,01,100,01,175,01,225,01,250,0

875,000

Activepostpaidsubscribers0000000000

Activeinternetcustomers383,000459,700505,650556,200611,800674,000

ActiveSubscribers2,178,02,389,72,545,62,671,22,776,82,864,0

(Total)000050000000

Activevoipsubscribers120,000140,000170,000200,000240,000288,000

注：其中的Activevoipsubscribers已包含在Activeinternetcustomers't1了。

其他更全面的信息请参见RFQ材料中的《RFQA5SizingfinalvLl.pdf》。

1.4实施阶段

按照业务与网络情况考虑，整个项目将会分三个阶段实施：

・第一阶段（phase1）：MobilePostpaidService支持，在迁移旧有后付费用户与业务

系统功能的同时，Telfort2.0需要支持新进展的移动后付费用户。如今，Telfort2.0

将与原有的预付费系统、Iniernel系统共存。

•第二阶段（Phase2）：在支持后付费的基础上，迁移预付费。如今，所有的移动

用户将由Telfort2.0支持，但与旧有的Internet系统共存。

•第三阶段（phase3）：迁移Internet用户，并支持新增Internet用户。这是系统的最

终演进结果与目标架构。

2系统总体描述（0级视图）

2.1系统总体构架

我司提供的融合计费解决方案共有CCBS、OCS、IPCC、BI与外协几个产品构成，在逻

辑上分为三层，如下图所示：

BOSSNMSBusinessInteligence

客户服务层

计费帐务层

服务控制层

Network

CCBS产品提供・BI产品提供1PCC产品提供OCS产品提供口外协•提供

2.1.1服务操纵层

服务操纵层各部件的功能如下：

>Provision部件将为客户服务层提供网络的服务开通接口。

>Mediation部件负责采集网络设备上的话单，同时也负责漫游结算话单的解码工

作。

>SCP部件负责话音类业务的呼叫操纵，并触发到CBS进行计费处理。

>UVC部件负责充值卡管理与对应的充值流程。

2.1.2计费帐务层

计费帐务层由CCBS国内海外计费帐务统一版本完成。

CBS实现对预付费用户的业务使用进行预算与实时扣费。对后付费用户的业务使用进行

批价（全触发模式后需要实时批价）、出话单、累帐出帐。

在计费帐务处理后，将由帐单格式化、帐务管理、欠费催缴模块完成后续的帐单生成、

缴费销帐、与欠费催缴功能。

收入保障使用的是外协Ectel的产品，包含对非法使用情况的分析、一致性的分析与处

理准确性的校验功能等。

注1：关于话音类业务，由核心网经Camel协议触发到SCP,再由SCP转换成DCC协议到

CBS进行计费处理。关于其它增值类业务，由增值业务平台使用DCC协议直接触发到CBS

进行计费处理。

注2：考虑到核心网与其它业务系统的性能与业务能力的改造，同时结合我们的分阶段

实施步骤，在总体上未使用全触发的方案，即预付费使用实时接口触发，后付费使用话单方

式进行计费。但后付费的数据业务需要通过DCC到CBS进行鉴权

注3：由于Telfort项目的特殊性，后付费的缴费是使用Telfort的财务系统支持，因此这

里使用“AccountManagement”的说法，没有使用海外通常的"AccountReceivable"，以保

证与客户交流的一致性。

注4：欠费催缴己经明确使用原有的CACS系统，不再由我司提供。

注5：E-CARE/E-SHOP可能要与portal捆绑在一起单独招标

2.1.3客户服务层

客户服务层要紧由CCBS与IPCC两个产品共同提供，覆盖Telfort2.0所有客户服务渠

道的日常功能，包含产品管理、资源管理、业务受理、业务变更、综合查询、投诉建议等功

能。

在业务受理流程中，客户服务层一方面将通过服务操纵层的Provision子系统对网络进

行服务开通，另一方面也将更新计费帐务层的客户资料、信用度数据、产品定购数据等信息。

同时计费帐务层也为客户服务层提供具体的资费规则定义、用户实时状态等信息。

2.1.4版本配套关系

CCBS产品各部件版本配套关系如下，将基于此版本进行开发:

配套产品版本

个人业务受理（包含缴费、

TopEngCC&BMV200R003C01B43

产品管理）

资源管理TopEngBOSSIMV200R003C01B190

订单管理TopEngBOSSGPV200R003C02B200

客户管理;营销管理

渠道管理;合作伙伴管理TopEngBOSSBCV2OOROO3CO2BI10

系统管理

E-careTopEngBOSSE-CareV3OOROO1CO2BO1

InterfaceTopEngBOSSINTV300R001C04B01

Rating/BillingTopEngCCBSCHGV300R001C0IB07

TopEngMediationV100R002C07B392+TopEngMediation

Mediation

V1OOROO2CO7B392E32FD8O

SystemMonitoringTopEngSystemMonitoringV200R003C02B201

ProvisionTopEngProvisionV100R002C20BQ41

2.2系统外部接口描述（暂不写作，将引用架构与接口有关交付内容）

系统外部接口总图如下（将根据架构与接口组的最终输出调整）：

2.3系统物理组网(暂不写作，将引用物理部署内容)

2.3.1系统总体物理组网

3系统方案设计(1级视图)

3.1Rating&Billing与PC产品定义配合

3.1.1业务需求描述

先在测试床进行测试资费配置，在测试床进行资费验证以后,进行生产库公布资费配置,

如今配置的资费政策(tariff_plan),同步到营业的计费资费接口表(billing_plan),供产品管理

进行产品定义。

3.1.2系统功能分解分配

Rat.001计费资费同步到营业PC资费接口表

•Rating&Billing部件

■计费资费政策(TARIFF_PLAN)的变动通过定时启动后台进程方式进行

差异同步，要紧同步资费ID与资费名称的变动，到营业资费接口表

(B1LLING_PLAN)。

TARIFF_PLANBILLING_PLAN差异检查字段缺省处理设置

Tariff_plan_idItemid是

Tariff_plan_nameItemnamesubstr(tariff_plan_name.1.

32)

PlantypePlantype

NetworkedGSM

Isbaseplan1

Status1

StatusdateSysdate

Region999

3.1.3接口说明

内部接口

接口名称接口类型接口提供方接口使用方接口说明

资费同步接表接口计费账务产品管理计费账务TARIFF_PLAN的资费ID与

□名称到产品管理的BILLING_PLAN的

同步处理。

外部接口

无

3.1.4性能要求

无

3.2Rating&Billing与帐务管理提供已批价CDR、Bill配合

3.2.1业务需求描述

计费账务通过表方式提供未销帐的后付费账单，账务处理与账务管理共用同一个数据

库，后付费账单通过数据库接口表的方式提供。

计费账务提供账单明细费用项与GLCODE参照表的保护。

已经批价话单(CDR)使用表接口方式提供给账务管理，不作格式转换。

3.2.2系统功能分解分配

批价话单提供方式

计费账务已批价话单(CDR)使用表接口方式提供，不作格式转换。

后付费账单提供方式

计费账务提供月结出帐与立即出帐的后付费账单，账务管理直接访问计费账务账单表

(BILL)与明细账单表(BILLITEM),账务管理读取计费的账单进行销帐处理并将结果生成

到账务管理的账单表，

GLCODE处理方式

计费账务提供明细费用项与GLCODE参照表(帐单项定义表Acctltem_def)的保护。

3.2.3接口说明

内部接口

接口名称接口类型接口提供方接口使用方接口说明

批价话单表接口计费账务账务管理使用表接口方式提供，不作格式转换

后村费账单表接口计费账务账务管理账务管理直接访问计费账务账单表

接口

(BILL)与明细账单表(BILLITEM)

表接口计交账务账务管理

GLCODE计费账务提供明细费用项与GLCODE

处理方式

参照表(帐单项定义表Acclltem_def)

的保护

外部接口

无

3.2.4性能要求

无

3.3Rating&Billing与CC资料接口

3.3.1业务需求描述

营业受理产生资料的变更，需要向计费账务进行资料同步方式。由于对业务的实时性要

求的不一致，使用不一致的同步方式。关于预付费的激活处理与资费变动时，使用实时同步

方式，营业直接调用计费账务的实时客户资料刷新的socket接口，同时能够在资料同步触发

器中标识出已经使用了实时接口。

其他业务使用触发器异步处理方式，但是需要营业支持区分资料变动的操作类型支持不

一致的优先级与处理类型。新增操作类型，使用2为字符标识，第一位定义为批量类型，第

二位定义受理方式，具体说明如下：

第一位：批量类型

1一单笔受理，对应优先级高

2一批量受理，对应优先级低

第二位：受理方式

I一普通受理，更新营业数据库，通过触发器同步到计费

2一实时受理，先更新计费，再更新营业数据库，不需要进行同步计费

3一反向同步，计费已经更新，反向同步到营业，营业进行相应操作，不再同步到计费。

操作类型举例：

营业单笔普通受理，标志为11,使用触发器同步方式到计费，同步优先级高。

营业批量普通受理，标志为21,使用触发器同步方式到计费，同步优先级低。

批量反向同步处理,，标志为23,触发器特殊处理，不生成同步数据，只生成核对数据，

且同步优先级低。

计费账务进行预付费用户的生命周期管理过程中，预付费用户状态变动，需要由计费账

务反向同步资料到营业。

3.3.2系统功能分解分配

CC2RAT.001营业到计费的触发器资料同步接口

•Rating&Billing部件

■通过表触发器方式进行资料同步。客户资料上增加资料同步触发器，触发

到计费账务的资料增量接口表custinfo中，再同步到计费账务数据库，由

计费的客户资料管理程序刷新进行增量的数据库与共享内存的资料刷新。

■由于存在普通受理、批量后台受理、实时资料同步、反向同步等资料同步

方式，需要在触发器中增加受理的操作类型标识。从而区分批量受理类型，

确定资料处理优先级，通过区分受理方式，决定资料同步方向。

■具体实现方式：实现方式使用数据库package全局变量方式（2位字符方批注[ul]:假如某个操作没有设置全局变量，就会使用

上一笔操作的全局变量？

式）。

有无风险？

•CC部件

■营业受理时进行数据库操作时，先设置数据库package全局变量，Rating

提供的触发器检查此全局变量，进行相应的处理。

•Rating&Billing部件

■在同步资料表上增加操作类型字段，触发器进行不一致推断处理。

■计费资料同步触发器改造：支持营业不一致受理类型，生成不一致接口数

据。

1.推断批量处理类型，设置同步优先级。

2.推断受理方式，确定同步方向。

A:普通受理业务，生成到计费同步数据。

B:实时受理业务，不生成同步数据。

C:反向同步业务，不生成同步数据。

营业到计费账务的socket实时资料同步接口

•Rating&Billing部件

■关于预付费的激活、预付费的修改资费，计费账务提供sockect方式的资料

增量同步接口，计费账务