CN102447798B - 一种充值复机方法和装置 - Google Patents

Abstract

本发明公开了一种充值复机方法，包括：A、用当前时间点T3减去M，得到稽核开始时间点T1，用T3减去N，得到结束时间点T2，M大于N，M和N均为预先设定的时长；B、确定在T1到T2这一时间段内进行了充值的用户，并针对每个用户A，分别确定其是否满足复机条件但还未复机，如果是，则为用户A复机；C、等待M-N的时长后，重复执行步骤A和步骤B。本发明同时公开了一种充值复机装置。应用本发明所述的方法和装置，能够提升用户体验。

Description

一种充值复机方法和装置

技术领域

本发明涉及业务支撑技术，特别涉及一种充值复机方法和装置。

背景技术

业务支撑运营系统(BOSS)是每个电信运营商的核心业务支撑系统。近年来，随着支撑的用户数和话单量的成倍增长以及实时业务的不断扩展，BOSS系统逐渐暴露出账务处理不灵活、无法进行实时优惠计算、无法为用户提供实时准确的查询服务以及无法进行实时信控等问题，相应地，越来越多的运营商开始对BOSS系统的架构进行全面的改造。

实时账务系统即为一种改造后的BOSS系统，该系统能够提供话单级的实时出账，包括实时优惠计算和分账等，以及基于此进行的相关查询和实时信控等。其中，实时信控为实时账务系统的最重要组成部分，而充值复机又是实时信控的最重要组成部分。

现有充值复机过程如下：

1)用户A充值后，更新BOSS域中的用户A的账本资金，并记录用户A的资金变化明细。

本步骤中，在用户A的原有账本资金的基础上加上用户A充值的金额。

举例说明：假设月初1号的时候，用户A的账本资金为0元，2号的时候充值了100元，那么用户A的账本资金将为100元，之后用户A消费了120元，导致欠费停机，为了复机，又充值了200元，那么用户A的账本资金将为100+200＝300元，也就是说，账本资金与用户A的消费情况无关。

资金变化明细用于记录各用户的账本资金的变化情况，比如某年某月某日某时用户A充值了200元。

2)将账本资金上发到内存数据库(TT)域，更新TT域中的用户A的账本资金，并将用户A加入到信控队列中；

实时信控程序对信控队列中的各用户依次进行处理，以用户A为例，确定用户A是否满足复机条件，如果是，则产生复机告警，并下发给BOSS域。

3)BOSS域中的二级信控进行复机处理，如修改用户A的停复机状态(修改为复机状态)，并产生复机工单，发送给营业数据库(CRM)域。

4)CRM域进行复机处理，如修改用户A的停复机状态，并产生开通工单，发送给开通系统。

5)开通系统向本地归属位置寄存器(HLR)发送开通指令；相应地，HLR对用户A执行开通操作，从而实现复机。

可以看出，现有充值复机过程分布在多个域实现，数据分散，流程复杂，无论哪个环节出现问题，均会影响到复机的及时性，即导致复机延迟或失败。

可能出现的问题主要包括：

1)程序异常

充值复机过程关联到多重程序逻辑，包括账本资金上发、实时信控和二级信控等；如果账本资金上发出现异常，将导致账本资金无法上发到TT域，进而导致后续无法进行实时信控；如果实时信控出现异常，将导致后续无法产生复机告警；如果二级信控出现异常，将导致后续无法产生复机工单。

2)应用部署所在的主机、数据库异常

充值复机过程“横跨”BOSS域、TT域和CRM域；如果BOSS域中负责账本资金上发的主机出现异常宕机的情况，将导致账本资金无法上发到TT域，进而导致后续无法进行实时信控；如果TT出现HUNG的情况，同样将导致账本资金无法上传到TT域，进而导致后续无法进行实时信控；如果二级信控所部署在的BOSS中间件主机出现异常宕机的情况，将导致二级信控无法产生复机工单；如果CRM出现异常瘫痪的情况，将导致无法产生开通工单。

现有技术中，针对由上述原因所引起的用户无法及时复机的问题，通常只能采取被动防御的方式，即只有当接收到用户的投诉后，才能被动地进行修复处理，这样无疑降低了用户体验。

发明内容

有鉴于此，本发明的主要目的在于提供一种充值复机方法，能够提升用户体验。

本发明的另一目的在于提供一种充值复机装置，能够提升用户体验。

为达到上述目的，本发明的技术方案是这样实现的：

一种充值复机方法，包括：

A、用当前时间点T3减去M，得到稽核开始时间点T1，用所述T3减去N，得到结束时间点T2，所述M大于N，所述M和N均为预先设定的时长；

B、确定在T1到T2这一时间段内进行了充值的用户，并针对每个用户A，分别确定其是否满足复机条件但还未复机，如果是，则为用户A复机；

C、等待M-N的时长后，重复执行步骤A和步骤B。

一种充值复机装置，包括：

计算模块，用于用当前时间点T3减去M，得到稽核开始时间点T1，用所述T3减去N，得到结束时间点T2，所述M大于N，所述M和N均为预先设定的时长，并将所述T1和T2发送给复机模块；

所述复机模块，用于确定在T1到T2这一时间段内进行了充值的用户，并针对每个用户A，分别确定其是否满足复机条件但还未复机，如果是，则为用户A复机；等待M-N的时长后，通知所述计算模块重复执行自身功能。

可见，采用本发明的技术方案，自动地挑选出充值一定时长后满足复机条件但还未复机的用户，为其开辟绿色通道，使其复机成功，从而确保了用户复机的及时性，提升了用户体验。

附图说明

图1为本发明充值复机方法实施例的流程图。

图2为本发明充值复机方法较佳实施例的流程图。

图3为本发明充值复机装置实施例的组成结构示意图。

具体实施方式

针对现有技术中存在的问题，本发明中提出一种新的充值复机方案，旨在建立一种机制，自动地挑选出充值一定时长后满足复机条件但还未复机的用户，为其开辟绿色通道，使其复机成功。

为使本发明的技术方案更加清楚、明白，以下参照附图并举实施例，对本发明所述方案作进一步地详细说明。

图1为本发明充值复机方法实施例的流程图。如图1所示，包括以下步骤：

步骤11：用当前时间点T3减去M，得到稽核开始时间点T1，用T3减去N，得到结束时间点T2，M大于N。

M和N均为预先设定的时长，通常，M的取值为10分钟，N的取值为5分钟。也就是说，假设当前时间点为T3，那么稽核开始时间点T1＝T3-10，结束时间点T2＝T3-5。

步骤12：确定在T1到T2这一时间段内进行了充值的用户，并针对每个用户A，分别确定其满足复机条件但还未复机，如果是，则为用户A复机。

步骤13：等待M-N的时长后，重复执行步骤11。

步骤12～13中，首先确定在T1到T2这一时间段内哪些用户进行了充值，确定出的用户可能为1个，也可能为多个。所述充值包括本地营业预缴、异地营业预缴、缴费卡充值、手机充值卡充值，以及银行现金充值等。

之后，针对确定出的每个用户A，分别确定其是否满足复机条件但还未复机，如果是，则说明用户A按照现有复机方式未复机成功，需要立即按照本发明所述复机方式为其复机。当所有用户均已处理完毕后，休息5分钟，然后重复执行步骤11及后续步骤。

可以看出，本发明所述方案中，通过对时间进行切分，即T1、T2、T3、T4、....、Tn-1、Tn，Tn-Tn-1＝5分钟，在时间点T3对T1～T2时间段内进行了充值且满足复机条件但未复机的用户进行复机，在时间点T4对T2～T3时间段内进行了充值且满足复机条件但未复机的用户进行复机，依次类推，一方面能够保证用户在充值后的前5分钟内按照现有复机方式进行复机(即如果现有复机方式能够成功复机，则无需采用本发明所述复机方式，不和现有复机方式抢占资源)，另一方面又能保证当现有复机方式不能成功复机的情况下，在10分钟之内按照本发明所述复机方式使用户及时复机。假设用户A在时间点t进行了充值，那么则有T1＜t＜T2，用户A从充值到复机的时长为T3-t，T3-T2＜T3-t＜T3-T1，即5分钟＜T3-t＜10分钟。

本发明所述复机方式可为：针对用户A，将用户A的复机所需信息，如用户A的手机号码、所在地区、账单明细表等加入到预先设置的紧急复机表中；开通系统会实时扫描该紧急复机表，并根据扫描到的复机所需信息为用户A复机，如何复机为现有技术，不再赘述。

图2为本发明充值复机方法较佳实施例的流程图。如图2所示，包括以下步骤：

步骤21：用当前时间点T3减去10，得到稽核开始时间点T1，用T3减去5，得到结束时间点T2。

假设本较佳实施例中的M的取值为10分钟，N的取值为5分钟。

步骤22：确定在T1到T2这一时间段内进行了充值的用户。

本步骤中，从BOSS域中获取所有用户的资金变化明细，根据获取到的所有用户的资金变化明细确定在T1到T2这一时间段内进行了充值的用户。依据之前的介绍，每个用户的资金变化明细中均会记录有该用户在何时进行了充值等信息，所以根据该信息可以很容易地确定出在T1到T2这一时间段内进行了充值的用户。

步骤23：针对每个用户A，分别获取其账单明细表。

本步骤中，如果TT域的状态正常，则可通过查询代理接口从TT域中获取用户A的账单明细表。查询代理的工作机制如下：查询代理作为客户(Client)端，通过插座(Socket)方式访问作为服务器(Server)端的微软数据库(MDB)，进而通过MDB访问TT域，并将访问结果，即用户A的账单明细表返回给查询代理。

但是，如果TT域的状态异常，则不能再按照上述方式获取用户A的账单明细表。为此，可在每天的指定时间点，如凌晨0点，将所有用户的账单明细表从TT域中导出到BOSS域中进行备份，这样，当TT域的状态异常时，即查询代理无法获取用户A的账单明细表，返回错误时，可自动从BOSS域中备份的所有用户的账单明细表找到用户A的账单明细表，从而实现无缝切换，无需人工干预。

另外，为了防止由于二级信控所部署在的BOSS中间件主机出现异常宕机的情况而影响本发明所述方案的实现，可将所有用户的账单明细表保存在BOSS域中除二级信控所部署在的BOSS中间件主机以外的其它主机上，如计费主机。

步骤24：根据获取到的账单明细表确定用户A的实际可用金额是否大于0，如果是，则认为用户A满足复机条件，并执行步骤25，否则，结束流程。

用户A的账单明细表可包括：用户A的账本资金、用户A的实际消费费用(备份的话截止到凌晨0点)以及用户A的账户欠费金额等信息。实际消费费用以及账户欠费金额的具体含义为本领域公知，不再赘述。

本步骤中，计算用户A的实际可用金额，用户A的实际可用金额＝用户A的账本资金-用户A的实际消费费用-用户A的账户欠费金额(如果无欠费，则为0)，如果计算结果大于0，则认为用户A满足复机条件，后续执行步骤25，否则，认为用户A不满足复机条件，结束流程。

步骤25：确定用户A是否处于停机状态，如果是，则执行步骤26，否则，结束流程。

本步骤中，如果CRM域的状态正常，则可根据从CRM域中获取到的用户A的停复机状态确定用户A是否处于停机状态，否则，可默认用户A处于停机状态。

步骤26：为用户A复机，结束流程。

后续，在等待5分钟之后，可重复执行步骤21。

如果用户A满足复机条件但处于停机状态，则说明按照现有复机方式未复机成功，需要按照本发明所述复机方式为用户A复机，即将用户A的复机所需信息加入到预先设置的紧急复机表中，开通系统实时扫描该紧急复机表，并根据扫描到的复机所需信息为用户A复机。

另外，为了防止由于用户A的停复机状态等信息的不全，导致后续无法对用户A进行正常信控等，可在为用户A复机之后，进一步修改BOSS域和CRM域中与用户A相关的信息，如修改BOSS域中用户A的停复机状态，修改CRM域中用户A的停复机状态、产生开通工单、修改用户A的复机变化表等，如何修改均为现有技术，不再赘述。

特殊地，如果CRM域的状态异常(可通过常驻程序去探测CRM域的状态是否异常，并进行记录，如正常则记为flag＝1，否则记为flag＝0)，则可暂不对CRM域进行修改，而是先将待修改的信息保存到临时表中，等到CRM域修复后再进行修改。

基于上述方法，图3为本发明充值复机装置实施例的组成结构示意图。如图3所示，包括：

计算模块31，用于用当前时间点T3减去M，得到稽核开始时间点T1，用T3减去N，得到结束时间点T2，M大于N，M和N均为预先设定的时长，并将T1和T2发送给复机模块32；

复机模块32，用于确定在T1到T2这一时间段内进行了充值的用户，并针对每个用户A，分别确定其是否满足复机条件但还未复机，如果是，则为用户A复机；等待M-N的时长后，通知计算模块31重复执行自身功能。

通常，M的取值为10分钟，N的取值为5分钟。

其中，复机模块32中可具体包括：

第一处理单元321，用于根据从BOSS域中获取到的所有用户的资金变化明细确定在T1到T2这一时间段内进行了充值的用户，并发送给第二处理单元322；

第二处理单元322，用于针对在T1到T2这一时间段内进行了充值的每个用户A，分别进行如下处理：获取用户A的账单明细表，根据所述账单明细表确定用户A的实际可用金额是否大于0，如果是，则认为用户A满足复机条件，并进一步确定用户A是否处于停机状态，如果是，则为用户A复机；等待M-N的时长后，通知计算模块31重复执行自身功能。

所述第二处理单元322中又可进一步包括(为简化附图，未图示)：

第一处理子单元，用于获取用户A的账单明细表，包括：用户A的账本资金、用户A的实际消费费用以及用户A的账户欠费金额；用用户A的账本资金减去用户A的实际消费费用和用户A的账户欠费金额，将计算结果作为用户A的实际可用金额，当计算结果大于0时，通知第二处理子单元执行自身功能；

第二处理子单元，用于当CRM域的状态正常时，根据从CRM域中获取到的用户A的停复机状态确定用户A是否处于停机状态，否则，默认用户A处于停机状态；当用户A处于停机状态时，通知第三处理子单元执行自身功能；

第三处理子单元，用于将用户A的复机所需信息加入到紧急复机表中，以便开通系统根据复机所需信息为用户A复机；等待M-N的时长后，通知计算模块31重复执行自身功能。

当TT域的状态正常时，第一处理子单元从TT域中获取用户A的账单明细表，否则，从BOSS域中获取用户A的账单明细表；BOSS域中保存有在每天的指定时间点，从TT域中导出到BOSS域中进行备份的所有用户的账单明细表。

图3所示装置实施例的具体工作流程请参照图2和3所示方法实施例中的相应说明，此处不再赘述。

总之，采用本发明的技术方案，自动地挑选出充值一定时长后满足复机条件但还未复机的用户，为其开辟绿色通道，使其复机成功，从而确保了用户复机的及时性，提升了用户体验。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (10)

1.一种充值复机方法，其特征在于，该方法包括：

A、用当前时间点T3减去M，得到稽核开始时间点T1，用所述T3减去N，得到结束时间点T2，所述M大于N，所述M和N均为预先设定的时长；

B、确定在T1到T2这一时间段内进行了充值的用户，并针对每个用户A，分别确定其是否满足复机条件但还未复机，如果是，则为用户A复机；

C、等待M-N的时长后，重复执行步骤A和步骤B；

其中，所述针对每个用户A，分别确定其是否满足复机条件但还未复机，如果是，则为用户A复机包括：获取用户A的账单明细表；根据所述账单明细表确定用户A的实际可用金额是否大于0，如果是，则认为用户A满足复机条件，并进一步确定用户A是否处于停机状态，如果是，则为用户A复机；

该方法进一步包括：在每天的指定时间点，将所有用户的账单明细表从内存数据库TT域中导出到BOSS域中进行备份；

所述获取用户A的账单明细表包括：如果所述TT域的状态正常，则从所述TT域中获取用户A的账单明细表，否则，从所述BOSS域中获取用户A的账单明细表。

2.根据权利要求1所述的方法，其特征在于，所述M的取值为10分钟，所述N的取值为5分钟。

3.根据权利要求1所述的方法，其特征在于，所述确定在T1到T2这一时间段内进行了充值的用户包括：

根据从业务支撑运营系统BOSS域中获取到的所有用户的资金变化明细确定在T1到T2这一时间段内进行了充值的用户。

4.根据权利要求1所述的方法，其特征在于，将所有用户的账单明细表保存在所述BOSS域中除二级信控所部署在的BOSS中间件主机以外的其它主机上。

5.根据权利要求1所述的方法，其特征在于，所述确定用户A是否处于停机状态包括：

如果营业数据库CRM域的状态正常，则根据从所述CRM域中获取到的用户A的停复机状态确定用户A是否处于停机状态；否则，默认用户A处于停机状态。

6.根据权利要求1所述的方法，其特征在于，所述用户A的账单明细表包括：用户A的账本资金、用户A的实际消费费用以及用户A的账户欠费金额；

所述用户A的实际可用金额＝用户A的账本资金-用户A的实际消费费用-用户A的账户欠费金额。

7.根据权利要求1～6中任一项所述的方法，其特征在于，所述为用户A复机包括：

将用户A的复机所需信息加入到紧急复机表中；开通系统实时扫描所述紧急复机表，并根据扫描到的复机所需信息为用户A复机。

8.根据权利要求1～6中任一项所述的方法，其特征在于，所述为用户A复机之后，进一步包括：

修改BOSS域和CRM域中与用户A相关的信息；其中，如果所述CRM域的状态异常，则先将待修改的信息保存到临时表中，等到所述CRM域修复后再进行修改。

9.一种充值复机装置，其特征在于，包括：

计算模块，用于用当前时间点T3减去M，得到稽核开始时间点T1，用所述T3减去N，得到结束时间点T2，所述M大于N，所述M和N均为预先设定的时长，并将所述T1和T2发送给复机模块；

所述复机模块，用于确定在T1到T2这一时间段内进行了充值的用户，并针对每个用户A，分别确定其是否满足复机条件但还未复机，如果是，则为用户A复机；等待M-N的时长后，通知所述计算模块重复执行自身功能；

所述复机模块包括：

第一处理单元，用于根据从业务支撑运营系统BOSS域中获取到的所有用户的资金变化明细确定在T1到T2这一时间段内进行了充值的用户，并发送给第二处理单元；

所述第二处理单元，用于针对在T1到T2这一时间段内进行了充值的每个用户A，分别进行如下处理：获取用户A的账单明细表，根据所述账单明细表确定用户A的实际可用金额是否大于0，如果是，则认为用户A满足复机条件，并进一步确定用户A是否处于停机状态，如果是，则为用户A复机；等待M-N的时长后，通知所述计算模块重复执行自身功能；

所述第二处理单元包括：

第一处理子单元，用于获取用户A的账单明细表，包括：用户A的账本资金、用户A的实际消费费用以及用户A的账户欠费金额；用用户A的账本资金减去用户A的实际消费费用和用户A的账户欠费金额，将计算结果作为用户A的实际可用金额，当计算结果大于0时，通知第二处理子单元执行自身功能；

所述第二处理子单元，用于当营业数据库CRM域的状态正常时，根据从所述CRM域中获取到的用户A的停复机状态确定用户A是否处于停机状态，否则，默认用户A处于停机状态；当用户A处于停机状态时，通知第三处理子单元执行自身功能；

所述第三处理子单元，用于将用户A的复机所需信息加入到紧急复机表中，以便开通系统根据所述复机所需信息为用户A复机；等待M-N的时长后，通知所述计算模块重复执行自身功能；

其中，当内存数据库TT域的状态正常时，所述第一处理子单元从所述TT域中获取用户A的账单明细表，否则，从所述BOSS域中获取用户A的账单明细表；所述BOSS域中保存有在每天的指定时间点，从所述TT域中导出到所述BOSS域中进行备份的所有用户的账单明细表。

10.根据权利要求9所述的装置，其特征在于，所述M的取值为10分钟，所述N的取值为5分钟。

Images