CN104717625A - 一种信控处理的方法及装置 - Google Patents
一种信控处理的方法及装置 Download PDFInfo
- Publication number
- CN104717625A CN104717625A CN201310683596.5A CN201310683596A CN104717625A CN 104717625 A CN104717625 A CN 104717625A CN 201310683596 A CN201310683596 A CN 201310683596A CN 104717625 A CN104717625 A CN 104717625A
- Authority
- CN
- China
- Prior art keywords
- account
- ticket
- letter control
- user
- account information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/24—Accounting or billing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
Abstract
本发明公开了一种信控处理的方法及装置,用于解决因信控操作耗时长,并且占用累账处理线程的资源,大大降低了累账操作的处理效率,引发的话单积压,导致整个账务汇总速率低的问题。该方法为:采用第一进程对话单数据进行累账处理,并将生成的话单累账信息依次存储至信控队列中;采用第二进程依次读取信控队列表中的每条话单累账信息并进行信控处理。采用上述方法,可以提高累账操作的处理效率,缓解了话单挤压的问题,提高了累账和信控操作的处理效率。
Description
技术领域
本发明涉及通信账务处理技术领域,尤其涉及一种信控处理的方法及装置。
背景技术
目前,由于通用分组无线业务(General Packet Radio Service,GPRS)话单量爆炸式增长,当前账务处理话单的效率已经不能满足业务需要,在话单高峰时容易形成话单积压,不能实施的进行出账计算。
当前账务处理话单的处理流程如下:
步骤A:话单传输程序从计费主机取回批价后的话单文件;
步骤B:账务处理话单汇总程序对取回的话单文件进行处理,主要包括:费用累计、用户级优惠、账户级优惠以及分账等操作处理。
步骤C:分账后产生的实时分账账单触发一级信控,一级信控主要对用户账户的欠费情况进行监控。
步骤D:经过一级信控处理后生成告警信息表(I_EXPORT_ALARM),根据告警信息表中记载的用户账户信控情况对二级信控进行触发,其中,二级信控主要为信控结果执行,如对用户账户执行信控停开机操作。
现有的累账操作和信控操作的处理速度很难快速处理大量的话单数据,由于话单累账操作和信控操作串行的在一个进程中完成,并且信控操作往往比话单累账操作要耗费更多的时间,因此使得话单高峰时形成了话单积压,进而影响了出账计算的问题。通常在话单挤压时,靠增加话单累账线程数和暂停信控节点两种方法来解决话单积压问题,但是这两种方法都不能有效的解决话单累账效率低的问题。增加话单累账线程数可以缓解话单的积压问题,但是处理出大量话单累账信息后信控节点仍然无法加快其对话单累账信息的处理。暂停信控节点这种方法,通过暂停运行在一个进程中的信控节点方法,加快话单累账操作的速率,但与增加话单累账线程数存在相同的弊端,在话单累账操作后,仍然要面对大量话单累账信息等待信控节点处理。
发明内容
本发明实施例提供一种信控处理的方法及装置,用以解决现有技术中存在因信控操作耗时长,并且占用累账处理线程的资源,大大降低了累账操作的处理效率,引发的话单积压,导致整个账务汇总速率低的问题。
本发明实施例提供一种信控处理的方法及装置。
第一方面,一种信控处理的方法,该方法包括:
采用第一进程对话单数据进行累账处理,并将生成的话单累账信息依次存储至信控队列中;
采用第二进程依次读取信控队列表中的每条话单累账信息并进行信控处理。
结合第一方面,在第一种可能的实现方式中,将生成的话单累账信息依次存储至信控队列中,包括:
将生成的话单累账信息按照生成的时间顺序依次存储至信控队列中;或者,
将生成的话单累账信息按照用户业务优先级的顺序依次存储至信控队列中。
通过这种可能的实施方式,将生成的多条话单累账信息全部存储信控队列以便后续信控处理,平衡了两个进程中处理速度的不同,使得原有的串行处理累账和信控,变为并行处理成为可能。
结合第一方面以及上述任意一种可能的实现方式,在第二种可能的实现方式中,采用第二进程依次读取信控队列表中的每条话单累账信息并进行信控处理,包括:
采用第二进程依次读取信控队列中的每条话单累账信息;
若话单累账信息对应的用户账户为用户基本账户,则执行用户基本账户欠费监控;
若话单累账信息对应的用户账户为用户合户账户,则执行用户合户账户总欠费监控,其中,用户合户账户总欠费用于指示用户合户账户中所有账户的欠费总和。
结合第一方面以及第一方面的第一种可能的实现方式中任意一种可能的实现方式,在第三种可能的实现方式中,采用第二进程对一条话单累账信息并进行信控处理之后,进一步包括:
根据话单累账信息对应的用户账户所归属的信用等级判断是否对用户账户进行告警处理;
若是,则将对话单累账信息进行信控处理后生成的信控数据存储至告警信息表,并将话单累账信息从信控队列中删除;否则,直接将话单累账信息从信控队列中删除。
结合第一方面的第三种可能的实现方式,在第四种可能的实现方式中,将对话单累账信息进行信控处理后生成的信控数据存储至告警信息表,并将话单累账信息从信控队列中删除之后,进一步包括:
将告警信息表导出,采用第三进程根据告警信息表中记录的信控数据对应的用户账户进行相应的告警。
结合第一方面的第四种可能的实现方式,在第五种可能的实现方式中,采用第三进程对告警信息表中记录的信控数据对应的用户账户进行告警,包括:
若用户账户的余额大于零且低于设定阈值,则采用第三进程对用户账户进行缴费告警;或者,
若用户账户的余额小于等于零,则采用第三进程对用户账户进行欠费停机告警。
第二方面,一种服务器,该服务器包括:
累账单元,用于采用第一进程对话单数据进行累账处理,并将生成的话单累账信息依次存储至信控队列中;
信控单元,用于采用第二进程依次读取信控队列表中的每条话单累账信息并进行信控处理。
结合第二方面,在第一种可能的实现方式中,累账单元具体用于:
将生成的话单累账信息按照生成的时间顺序依次存储至信控队列中;或者,
将生成的话单累账信息按照用户业务优先级的顺序依次存储至信控队列中。
通过这种可能的实施方式,将生成的多条话单累账信息全部存储信控队列以便后续信控处理,平衡了两个进程中处理速度的不同,使得原有的串行处理累账和信控,变为并行处理成为可能。
结合第二方面以及上述任意一种可能的实现方式,在第二种可能的实现方式中,信控单元具体用于:
采用第二进程依次读取信控队列中的每条话单累账信息;
若话单累账信息对应的用户账户为用户基本账户,则执行用户基本账户欠费监控;
若话单累账信息对应的用户账户为用户合户账户,则执行用户合户账户总欠费监控,其中,用户合户账户总欠费用于指示用户合户账户中所有账户的欠费总和。
结合第二方面以及第二方面的第一种可能的实现方式中任意一种可能的实现方式,在第三种可能的实现方式中,告警单元,用于采用第二进程对一条话单累账信息并进行信控处理之后,根据话单累账信息对应的用户账户所归属的信用等级判断是否对用户账户进行告警处理;
若是,则将对话单累账信息进行信控处理后生成的信控数据存储至告警信息表,并将话单累账信息从信控队列中删除;否则,直接将话单累账信息从信控队列中删除。
结合第二方面的第三种可能的实现方式,在第四种可能的实现方式中,告警单元,还具体用于将对话单累账信息进行信控处理后生成的信控数据存储至告警信息表,并将话单累账信息从信控队列中删除之后,将告警信息表导出,采用第三进程根据告警信息表中记录的信控数据对应的用户账户进行相应的告警。
结合第二方面的第四种可能的实现方式,在第五种可能的实现方式中,告警单元,还具体用于:
若用户账户的余额大于零且低于设定阈值,则采用第三进程对用户账户进行缴费告警;或者,
若用户账户的余额小于等于零,则采用第三进程对用户账户进行欠费停机告警。
附图说明
图1为本发明实施例中的信控处理逻辑架构图;
图2为本发明实施例中的信控处理的流程图;
图3为本发明实施例中信控处理的详细流程图;
图4为本发明实施例中的服务器的结构示意图。
具体实施方式
为了给出提高信控处理效率,并且不占用累账处理线程的系统资源,加快累账处理以及信控处理的效率,进而解决话单积压,提高整个账务汇总效率的实现方案,本发明实施例提供了一种信控处理的方法及装置,以下结合说明书附图对本发明的优选实施例进行说明。
为了解决这个问题,本发明提供的方案将信控操作从汇总进程中分离出来,即实时累账过程中不需要依赖信控操作完成后才继续进行下一次实时累账过程,从而提升了出账计算速度。同时将信控操作从日账、月账过程中分离出来,以提升出账计算速度。解决现有的GPRS话单积压的问题,同时提高实时累账的处理效率,进一步提升出账计算速度从而减少出账时间。
参阅图1所示,具体的改进方法如下:
图1中虚线部分用于指示本发明提供的信控处理方法相比于现有技术的信控处理方法所要删除的点,阴影部分用于指示本发明提供的信控处理方法中增加的点。在账务内存数据库(Memory Database,MDB)中新增信控队列(CAbmZWMonitorQueue),并且提供信控队列表的查询、更新、插入和删除等接口操作。
将原本在汇总进程中的信控功能单独运行在一个进程(monitor)中,该进程(monitor)为常驻进程,称为信控进程,主要包括信控队列查询节点和信控队列处理节点,信控队列查询节点不断扫描信控队列中的话单累账信息,在发现存在话单累账信息时,将上述话单累账信息取出并封装好发送给进程(monitor)的下一个节点,即信控队列处理节点。
该信控队列处理节点收到信控队列查询节点发送的话单累账信息后,调用信控处理接口对该话单累账信息进行处理,生成信控数据。待正确生成信控数据后,信控队列处理节点从信控队列中删除上述话单累账信息。
对信控队列中的话单累账信息进行信控处理后,根据生成的信控数据判断是否需要进行告警处理,并将需要进行告警处理的信控数据导入告警信息表,再由除汇总进程和信控进程之外的另一个进程执行告警处理。
参阅图2所示,本发明提供的信控处理的流程包括以下步骤:
步骤200:服务器采用第一进程对话单数据进行累账处理,并将生成的话单累账信息依次存储至信控队列中。
具体的,将生成的话单累账信息按照生成的时间顺序依次存储至信控队列中;或者,将生成的话单累账信息按照用户业务优先级的顺序依次存储至信控队列中。其中,用户业务优先级用于指示不同等级的用户,其话单数据的处理优先级不同;例如,可以设定VIP用户的业务优先级高于普通用户的业务优先级,也可以设定使用通话业务的用户的业务优先级高于使用短消息业务的用户优先级。
在对话单数据进行累账处理时,具体可以采用以下方式:收到话单传输程序从计费主机取回的批价后的话单数据,根据批价后的话单数据进行费用累计,并根据相应的市场优惠对进行费用累计后的用户话费账单进行打折,接着,进行分账处理,从而生成话单累账信息。
其中,在执行分账处理时,需要根据具体情况执行不同的操作。
例如,若话单累账信息对应的用户账户为用户基本账户,则在执行分账处理时,可以看做将该用户基本账户的账单全部都分给该用户基本账户。
又例如,若话单累账信息对应的用户账户为用户合户账户,则在执行分账处理时,将用户合户账户中包含的所有用户基本账户的账单分给该用户合户账户中的主账户;如,用户合户账户中共有2个账户:主账户和副账户,在执行分账处理时,可以将副账户的账单分给主账户,由主账户承担该用户合户账户中所有账户的账单,即每次执行分账处理时,都将该用户合户账户中产生的话费金额累计在主账户。
步骤210:服务器采用第二进程依次读取信控队列表中的每条话单累账信息并进行信控处理。
具体的,采用第二进程中的信控队列查询节点依次读取信控队列中的每条话单累账信息进行信控处理时,读取信控队列中的话单累账信息的条数可以配置,如,一次读取1000条话单累账信息供第二进程中的下一个节点,即信控队列处理节点处理。
另一方面,在执行步骤210时,若话单累账信息对应的用户账户为用户基本账户,则执行用户基本账户欠费监控,即基于用户基本账户的话单累账信息生成相应的信控数据,并根据生成的信控数据判断用户基本账户是否欠费;若话单累账信息对应的用户账户为用户合户账户,则执行用户合户账户总欠费监控,其中,用户合户账户总欠费用于指示用户合户账户中所有账户的欠费总和,并根据生成的信控数据判断用户合户账户是否欠费。
进一步的,采用第二进程对一条话单累账信息并进行信控处理之后,还可以根据话单累账信息对应的用户账户所归属的信用等级判断是否对用户进行告警处理;若是,则将对话单累账信息进行信控处理后生成的信控数据存储至告警信息表,并将话单累账信息从信控队列中删除;否则,直接将话单累账信息从信控队列中删除;其中,该告警信息表存储在账户MDB中。
例如,用户账户所归属的信用等级决定了用户账户可以欠费的信用额度,若用户账户为普通用户,则在获知用户账户已欠费时,确定执行告警处理;而若用户账户为VIP用户,则在获知用户账户已欠费,但未超过信用额度时,确定不执行告警处理。
进一步地,确定需要对用户账户进行告警处理时,需要将相应的经信控处理后生成的信控数据存储至告警信息表,此类信控数据又可称为可疑信控数据,用于记录用户账户的欠费情况,如,信控数据中可以记录用户账户的余额,用户账户的业务订购情况,以及用户账户的信用等级等等,服务器可以根据信控数据中记录的信息判断需要对用户账户执行何种告警处理。
具体的,服务器将告警信息表导出,采用第三进程根据告警信息表中记录的信控数据对相应的用户账户进行相应的告警。
例如,若用户账户的余额大于零且低于设定阈值,则服务器采用第三进程对用户账户进行缴费告警。如,在用户账户中的余额只剩10元时,提醒用户尽快缴费,或者,在用户账户中的余额大于50元,但不足以支付下一个即将扣费的订购业务时,提醒用户尽快缴费。
又例如,若用户账户的余额小于等于零,则采用第三进程对用户账户进行欠费停机告警。如,若话单累账信息对应的用户账户为用户基本账户,则在用户基本账户中的小于等于零时,发出上述欠费停机告警,若话单累账信息对应的用户账户为用户合户账户,则在用户合户账户中的总余额小于等于零时,发出上述欠费停机告警。
另一方面,还可以根据用户账户的信用等级执行不同的告警处理,如,信用等级高的用户账户在账户余额小于等于零时,不会直接对该用户账户执行欠费停机操作,还需要判断其欠费金额是否达到了该用户账户对应的信用额度所规定的欠费金额,若是,则执行欠费停机操作,否则,可以不执行告警处理,仅仅发送一条提示短信。
下面采用一个具体的应用场景对上述实施例作出进一步详细说明。
参阅图3所示,信控处理的详细流程如下:
步骤300:服务器接收到批价后的新话单数据。
步骤310:服务器获取该新话单数据对应的用户账户的当前账单。
步骤320:服务器根据该用户账户的当前账单确定用户账户的当前余额和该当前余额所属的余额等级。
具体的,根据用户账户的当前账单,基于扣款规则明细表以及服务监控扣款规则明细表计算出的用户账户的当前余额和该当前余额所属的余额等级,其中,余额等级为该用户账户的当前余额归属为哪个余额区间,例如,第一余额等级用于指示用户账户的余额大于20元;第二余额等级用于指示用户账户的余额大于等于10元并且小于等于20元;第三余额等级用于指示用户账户的余额小于10元且大于0元;第四余额等级用于指示用户账户的余额小于等于0元。
步骤330:服务器根据新话单数据对相应的用户账户的当前账单进行累账处理。
步骤340:服务器根据累账处理后生成的用户账户的账单确定用户账户在累账后的余额和累账后的余额所属的余额等级。
具体的计算用户账户在累账后的余额和累账后的余额所属的余额等级的方法与步骤320相同。
步骤350:服务器判断账户的上述当前余额所属的余额等级和累账后的余额所属的余额等级是否为同一余额等级。
步骤360:服务器在判定不为统一余额等级时,将经过上述步骤300~步骤350处理后生成的信控数据导出至告警信息表。
步骤370:服务器对上述导入告警信息表的信控数据对应的用户账户执行相应的告警处理。
例如,若服务器获取用户账户的当前账单,确定用户账户的当前余额大于20元,当前余额所属的余额等级为第一余额等级;根据新话单数据对该用户账户的当前账单进行累账处理,并计算上述用户账户在累账后的余额为15元,累账后的余额所属的余额等级为第二余额等级,因此上述用户账户的当前余额属于第一余额等级,而累账后的余额属于第二余额等级,则将上述操作后的生成的信控数据导出至告警表,对应执行提醒余额不足20元的告警处理。
相同的,若当前余额等级属于第二余额等级,累账后的余额属于第三余额等级,则对应执行提醒余额不足10元的告警处理;若当前余额等级属于第三余额等级,累账后的余额属于第四余额等级,则对应的对用户账户执行欠费停机操作,并短信提醒余额不足的告警处理。
参阅表1和表2所示,本发明提供的信控处理方法对话单累账效率提升的效果如下:
表1
话单累账处理与信控未分离的话单累账处理结果:
GPRS话单名称 | 每秒处理话单数 |
S84001_20130116 | 654.698 |
S84001_20130117 | 699.075 |
S84001_20130118 | 660.461 |
S84001_20130119 | 731.906 |
S84001_20130120 | 767.596 |
S84001_20130121 | 711.35 |
S84001_20130122 | 689.778 |
S84001_20130123 | 678.199 |
表2
话单累账处理与信控分离后的话单累账处理结果:
GPRS话单名称 | 每秒处理话单数 |
S84001_20130116 | 1164.99 |
S84001_20130117 | 1215.69 |
S84001_20130118 | 1036.15 |
S84001_20130119 | 1570.05 |
S84001_20130120 | 1411.09 |
S84001_20130121 | 1149.51 |
S84001_20130122 | 1640.52 |
S84001_20130123 | 1284.53 |
可以看出,话单累账的处理速度提升了一倍左右,解决了大量话单积压的问题,通过也降低了系统运行的风险。
基于同一发明构思,根据本发明上述实施例提供的信控处理的方法,相应地,本发明另一实施例还提供了一种用于信控处理的服务器,该服务器结构示意图如图4所示,具体包括:累账单元400、信控单元410和告警单元420。
累账单元400,用于采用第一进程对话单数据进行累账处理,并将生成的话单累账信息依次存储至信控队列中;
信控单元410,用于采用第二进程依次读取信控队列表中的每条话单累账信息并进行信控处理。
累账单元400具体用于:
将生成的话单累账信息按照生成的时间顺序依次存储至信控队列中;或者,
将生成的话单累账信息按照用户业务优先级的顺序依次存储至信控队列中。
信控单元410具体用于:
采用第二进程依次读取信控队列中的每条话单累账信息;
若话单累账信息对应的用户账户为用户基本账户,则执行用户基本账户欠费监控;
若话单累账信息对应的用户账户为用户合户账户,则执行用户合户账户总欠费监控,其中,用户合户账户总欠费用于指示用户合户账户中所有账户的欠费总和。
告警单元420,用于采用第二进程对一条话单累账信息并进行信控处理之后,根据话单累账信息对应的用户账户所归属的信用等级判断是否对用户账户进行告警处理;
若是,则将对话单累账信息进行信控处理后生成的信控数据存储至告警信息表,并将话单累账信息从信控队列中删除;否则,直接将话单累账信息从信控队列中删除。
告警单元420,还具体用于将对话单累账信息进行信控处理后生成的信控数据存储至告警信息表,并将话单累账信息从信控队列中删除之后,将告警信息表导出,采用第三进程根据告警信息表中记录的信控数据对应的用户账户进行相应的告警。
告警单元420,还具体用于:
若用户账户的余额大于零且低于设定阈值,则采用第三进程对用户账户进行缴费告警;或者,
若用户账户的余额小于等于零,则采用第三进程对用户账户进行欠费停机告警。
综上所述,本发明实施例提供的方案,解决了话单积压的问题,降低了系统风险,将话单累账处理与信控分离开来,增加单独了信控处理进程,不仅提高了累账的速度,同时也缩短了整个累账与信控后总的出账时间。并且将话单累账和信控处理分别运行在两个不同进程中,更提高了话单累账与信控的可维护性。
本发明提供的信控处理方案将信控模块从汇总进程中分离,新增单独的信控处理进程,由汇总进程处理话单累账,信控列表中的数据由信控进程单独处理。在汇总或者日账触发信控时,不直接做信控处理,而是将账户账单插入账务MDB中的信控列表,有单独的进程去扫描信控列表并进行信控处理。这样可以将复杂的信控逻辑放在单独的进程中完成,提高了出账效率,减少了出账时间,并且将话单累账与信控分离后不影响用户费用查询,以及经分数据报表的生成。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
Claims (12)
1.一种信控处理的方法,其特征在于,所述方法包括:
采用第一进程对话单数据进行累账处理,并将生成的话单累账信息依次存储至信控队列中;
采用第二进程依次读取所述信控队列表中的每条话单累账信息并进行信控处理。
2.如权利要求1所述的方法,其特征在于,将生成的话单累账信息依次存储至信控队列中,包括:
将生成的话单累账信息按照生成的时间顺序依次存储至所述信控队列中;或者,
将生成的话单累账信息按照用户业务优先级的顺序依次存储至所述信控队列中。
3.如权利要求1或2所述的方法,其特征在于,采用第二进程依次读取所述信控队列表中的每条话单累账信息并进行信控处理,包括:
采用第二进程依次读取所述信控队列中的每条话单累账信息;
若所述话单累账信息对应的用户账户为用户基本账户,则执行用户基本账户欠费监控;
若所述话单累账信息对应的用户账户为用户合户账户,则执行用户合户账户总欠费监控,其中,所述用户合户账户总欠费用于指示用户合户账户中所有账户的欠费总和。
4.如权利要求1或2所述的方法,其特征在于,采用第二进程对一条话单累账信息进行信控处理之后,进一步包括:
根据所述话单累账信息对应的用户账户所归属的信用等级判断是否对所述用户账户进行告警处理;
若是,则将对所述话单累账信息进行信控处理后生成的信控数据存储至告警信息表,并将所述话单累账信息从信控队列中删除;否则,直接将所述话单累账信息从所述信控队列中删除。
5.如权利要求4所述的方法,其特征在于,将对所述话单累账信息进行信控处理后生成的信控数据存储至告警信息表,并将所述话单累账信息从信控队列中删除之后,进一步包括:
将所述告警信息表导出,采用第三进程根据所述告警信息表中记录的信控数据对应的用户账户进行相应的告警。
6.如权利要求5所述的方法,其特征在于,采用第三进程对所述告警信息表中记录的信控数据对应的用户账户进行告警,包括:
若所述用户账户的余额大于零且低于设定阈值,则采用第三进程对所述用户账户进行缴费告警;或者,
若所述用户账户的余额小于等于零,则采用第三进程对所述用户账户进行欠费停机告警。
7.一种服务器,其特征在于,所述服务器包括:
累账单元,用于采用第一进程对话单数据进行累账处理,并将生成的话单累账信息依次存储至信控队列中;
信控单元,用于采用第二进程依次读取所述信控队列表中的每条话单累账信息并进行信控处理。
8.如权利要求7所述的服务器,其特征在于,所述累账单元具体用于:
将生成的话单累账信息按照生成的时间顺序依次存储至所述信控队列中;或者,
将生成的话单累账信息按照用户业务优先级的顺序依次存储至所述信控队列中。
9.如权利要求7或8所述的服务器,其特征在于,所述信控单元具体用于:
采用第二进程依次读取所述信控队列中的每条话单累账信息;
若所述话单累账信息对应的用户账户为用户基本账户,则执行用户基本账户欠费监控;
若所述话单累账信息对应的用户账户为用户合户账户,则执行用户合户账户总欠费监控,其中,所述用户合户账户总欠费用于指示用户合户账户中所有账户的欠费总和。
10.如权利要求7或8所述的服务器,其特征在于,告警单元,用于采用第二进程对一条话单累账信息并进行信控处理之后,根据所述话单累账信息对应的用户账户所归属的信用等级判断是否对所述用户账户进行告警处理;
若是,则将对所述话单累账信息进行信控处理后生成的信控数据存储至告警信息表,并将所述话单累账信息从信控队列中删除;否则,直接将所述话单累账信息从所述信控队列中删除。
11.如权利要求10所述的服务器,其特征在于,所述告警单元,还具体用于将对所述话单累账信息进行信控处理后生成的信控数据存储至告警信息表,并将所述话单累账信息从信控队列中删除之后,将所述告警信息表导出,采用第三进程根据所述告警信息表中记录的信控数据对应的用户账户进行相应的告警。
12.如权利要求11所述的服务器,其特征在于,所述告警单元,还具体用于:
若所述用户账户的余额大于零且低于设定阈值,则采用第三进程对所述用户账户进行缴费告警;或者,
若所述用户账户的余额小于等于零,则采用第三进程对所述用户账户进行欠费停机告警。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310683596.5A CN104717625A (zh) | 2013-12-12 | 2013-12-12 | 一种信控处理的方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310683596.5A CN104717625A (zh) | 2013-12-12 | 2013-12-12 | 一种信控处理的方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN104717625A true CN104717625A (zh) | 2015-06-17 |
Family
ID=53416487
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310683596.5A Pending CN104717625A (zh) | 2013-12-12 | 2013-12-12 | 一种信控处理的方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104717625A (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105933859A (zh) * | 2016-03-31 | 2016-09-07 | 中国联合网络通信集团有限公司 | 一种移动用户个人信用预警方法及系统 |
CN107886424A (zh) * | 2017-11-28 | 2018-04-06 | 腾讯科技(深圳)有限公司 | 结算数据处理方法和装置、计算机设备和存储介质 |
CN108400931A (zh) * | 2018-02-26 | 2018-08-14 | 广东欧珀移动通信有限公司 | 多媒体消息发送方法、电子装置及计算机可读存储介质 |
CN111901771A (zh) * | 2020-09-07 | 2020-11-06 | 中国联合网络通信集团有限公司 | 信用额度设置方法、装置、计算机设备及存储介质 |
CN113676606A (zh) * | 2021-08-23 | 2021-11-19 | 中国联合网络通信集团有限公司 | 停机方法及设备 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101021801A (zh) * | 2006-11-30 | 2007-08-22 | 南京联创科技股份有限公司 | 流水线多进程之间基于消息队列的海量数据传输方法 |
US20110099109A1 (en) * | 2008-07-07 | 2011-04-28 | Marcus Karlsson | Real Time Correlation of Parallel Charging Events |
CN102722354A (zh) * | 2012-06-04 | 2012-10-10 | 南京中兴软创科技股份有限公司 | 面向计费业务的数据实时抽取和关键性指标实时分析方法 |
-
2013
- 2013-12-12 CN CN201310683596.5A patent/CN104717625A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101021801A (zh) * | 2006-11-30 | 2007-08-22 | 南京联创科技股份有限公司 | 流水线多进程之间基于消息队列的海量数据传输方法 |
US20110099109A1 (en) * | 2008-07-07 | 2011-04-28 | Marcus Karlsson | Real Time Correlation of Parallel Charging Events |
CN102722354A (zh) * | 2012-06-04 | 2012-10-10 | 南京中兴软创科技股份有限公司 | 面向计费业务的数据实时抽取和关键性指标实时分析方法 |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105933859A (zh) * | 2016-03-31 | 2016-09-07 | 中国联合网络通信集团有限公司 | 一种移动用户个人信用预警方法及系统 |
CN107886424A (zh) * | 2017-11-28 | 2018-04-06 | 腾讯科技(深圳)有限公司 | 结算数据处理方法和装置、计算机设备和存储介质 |
CN108400931A (zh) * | 2018-02-26 | 2018-08-14 | 广东欧珀移动通信有限公司 | 多媒体消息发送方法、电子装置及计算机可读存储介质 |
CN111901771A (zh) * | 2020-09-07 | 2020-11-06 | 中国联合网络通信集团有限公司 | 信用额度设置方法、装置、计算机设备及存储介质 |
CN113676606A (zh) * | 2021-08-23 | 2021-11-19 | 中国联合网络通信集团有限公司 | 停机方法及设备 |
CN113676606B (zh) * | 2021-08-23 | 2022-08-16 | 中国联合网络通信集团有限公司 | 停机方法及设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104717625A (zh) | 一种信控处理的方法及装置 | |
CN109885399A (zh) | 数据处理方法、电子装置、计算机设备及存储介质 | |
WO2019205791A1 (zh) | 为多个用户标识调整流量套餐的方法及装置 | |
CN103701934A (zh) | 一种资源优化调度方法及虚拟机宿主机优化选择方法 | |
CN104486138A (zh) | 流量监控方法、装置和监控服务器 | |
JP2012517639A (ja) | ユーザーのサービス量に基づいて、オンラインで料金を計算する方法及びシステム | |
CN101662773A (zh) | 支持降低通信欺诈风险的计算机实现方法和设备 | |
CN109472656B (zh) | 一种虚拟物品的展示方法、装置和存储介质 | |
CN106775936A (zh) | 一种虚拟机的管理方法及装置 | |
CN109543891A (zh) | 容量预测模型的建立方法、设备及计算机可读存储介质 | |
CN103796183A (zh) | 一种垃圾短信识别方法及装置 | |
CN106651368A (zh) | 防刷单的支付方式的控制方法及控制系统 | |
CN111290696A (zh) | 一种应用程序组件的流控方法及装置 | |
CN110072251B (zh) | 一种分析用户通讯行为与管理用户的方法及装置 | |
US20200074539A1 (en) | Debt resolution planning platform | |
CN105916125A (zh) | 一种话费余额提醒的方法及装置 | |
CN107148022A (zh) | 一种防蹭网提醒方法及相关设备 | |
CN110555691A (zh) | 聚合支付系统 | |
CN104137475B (zh) | 用于计费的方法和装置 | |
WO2010135881A1 (zh) | 实时累计赠送的预付费智能网业务的实现方法及系统 | |
CN105208534A (zh) | 事件通知方法及系统 | |
CN106503543A (zh) | 一种管理应用程序的方法和装置 | |
CN105848127B (zh) | 一种精确补单方法和装置 | |
CN107800650A (zh) | 一种调整运营管道资源占用的方法及装置 | |
CN105677478A (zh) | 资源管理的方法和装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20150617 |