CN111211973B

CN111211973B - 发票领域的消息处理方法、装置及存储介质

Info

Publication number: CN111211973B
Application number: CN202010040251.8A
Authority: CN
Inventors: 陈杰; 张俭恭; 张勇; 王微
Original assignee: Baiwang Co ltd
Current assignee: Baiwang Co ltd
Priority date: 2020-01-15
Filing date: 2020-01-15
Publication date: 2022-06-21
Anticipated expiration: 2040-01-15
Also published as: CN111211973A

Abstract

本申请公开了一种发票领域的消息处理方法、装置及存储介质，方法包括：推送消息；拉取消息；回放服务；数据对账；所述推送消息包括：根据接口消息是否实时，将接口消息分单向和双向两类，单向消息将存储在推送中心，由消息发送方主动拉取；双向消息，由推送中心发送到指定接口上，推送中心提供给消息发送方获取失败消息列表的功能；客户端根据推送中心提供的api，调用推送服务；为消除网络抖动，推送中心提供补偿机制。本申请提供的发票领域的消息处理方法，解决了多子系统(即客户端)情景中，系统复杂性大的问题，优化了系统配置，减少了开发和后期维护的工作量。

Description

发票领域的消息处理方法、装置及存储介质

技术领域

本申请涉及计算机技术领域，具体涉及一种发票领域的消息处理方法、装置及存储介质。

背景技术

通常情况下，消息推送主要由子系统自行开发。当子系统A需要邮件发送功能时，其引入邮件发送功能的依赖包，配置邮件发送账号的信息。当子系统A需要短信通知功能时，其与短信服务提供商进行对接，封装自己的接口。当子系统A需要接口通知功能时，需要引入HttpClient依赖包，同时配置接收方的地址参数等信息。当接收方的地址信息由改动，子系统A可能需要暂停服务进行修改，同时子系统A需要自行实现以上消息推送的补偿机制。

当系统的子系统B需要邮件发送、短信发送、接口通知等功能时，有两种方案：方案一：自行开发，即开发与子系统A相同功能；方案二：集成子系统A，即对子系统A的功能进行二次开发。方案一需要消耗人力成本，方案二需要考虑子系统A和子系统B业务层面的关系是否允许依赖，同时二次开发增加了系统的复杂性，系统A的功能修改将直接影响系统B。现有技术的多子系统(即客户端)情景中，系统复杂性大，系统配置差，开发和后期维护的工作量过大。

发明内容

本申请的目的是提供一种发票领域的消息处理方法、装置及存储介质。为了对披露的实施例的一些方面有一个基本的理解，下面给出了简单的概括。该概括部分不是泛泛评述，也不是要确定关键/重要组成元素或描绘这些实施例的保护范围。其唯一目的是用简单的形式呈现一些概念，以此作为后面的详细说明的序言。

根据本申请实施例的一个方面，提供一种发票领域的消息处理方法，包括：

推送消息；

拉取消息；

回放服务；

数据对账。

进一步地，在所述推送消息之前，所述方法还包括注册的步骤，所述注册的步骤，包括：

客户端将信息注册到推送中心。

进一步地，所述推送消息包括：

根据接口消息是否实时，将接口消息分单向和双向两类，单向消息将存储在推送中心，由消息发送方主动拉取；双向消息，由推送中心发送到指定接口上，推送中心提供给消息发送方获取失败消息列表的功能；

客户端根据推送中心提供的api，调用推送服务；

为消除网络抖动，推送中心提供补偿机制。

进一步地，所述补偿机制，包括：

接口返回500状态码；

接口返回4XX状态码；

接口返回其他非2XX状态码。

进一步地，所述拉取消息，包括：

提供客户端拉取单向消息或拉取失败的消息的功能；

对于接口信息的拉取，指定待拉取接口的信息，匹配尚未拉取的消息，返回待拉取的消息列表；消息拉取成功后，不可再次拉取。

进一步地，所述回放服务，包括：

提供客户端回放失败消息的功能，客户端指定接口和回放时间段，推送中间将此段时间内，指定接口失败的消息进行再次推送。

进一步地，所述数据对账，包括通过WEB页面可查询消息推送的结果，并对失败的消息进行重试。

根据本申请实施例的另一个方面，提供一种电子装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现上述的发票领域的消息处理方法。

根据本申请实施例的另一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以实现上述的发票领域的消息处理方法。

本申请实施例的其中一个方面提供的技术方案可以包括以下有益效果：

本申请实施例提供的发票领域的消息处理方法，解决了多子系统(即客户端)情景中，系统复杂性大的问题，优化了系统配置，减少了开发和后期维护的工作量。

本申请的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者，部分特征和优点可以从说明书中推知或毫无疑义地确定，或者通过实施本申请实施例了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本申请的一个实施例的发票领域的消息处理方法流程图；

图2示出了本申请一个实施例的一种发票领域的消息处理系统的结构框图；

图3示出了本申请的另一实施例的发票领域的消息处理方法。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，下面结合附图和具体实施例对本申请做进一步说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本申请所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本申请的一个实施例，提供一种发票领域的消息处理方法，包括：

注册的步骤；

推送消息；

拉取消息；

回放服务；

数据对账。

所述注册的步骤，包括：

客户端将信息注册到推送中心。

所述推送消息包括：

客户端根据推送中心提供的api，调用推送服务；

为消除网络抖动，推送中心提供补偿机制。

所述补偿机制，包括：

接口返回500状态码；

接口返回4XX状态码；

接口返回其他非2XX状态码。

所述拉取消息，包括：

提供客户端拉取单向消息或拉取失败的消息的功能；

所述回放服务，包括：

所述数据对账，包括通过WEB页面可查询消息推送的结果，并对失败的消息进行重试。

本实施例还提供一种电子装置，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现上述的发票领域的消息处理方法。

本实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以实现上述的发票领域的消息处理方法。

本实施例提供的发票领域的消息处理方法，解决了多子系统(即客户端)情景中，系统复杂性大的问题，优化了系统配置，减少了开发和后期维护的工作量。

如图1所示，本申请的另一个实施例提供了一种发票领域的消息处理方法，包括以下步骤：

步骤01、注册的步骤

推送服务提供客户端注册自身服务的功能，客户端根据自己的实际情况将接口的地址，特征值，请求方式，加密信息，签名信息等注册到推送中心。在基于发票业务的推送场景下，特征值可以是税号、appkey、租户id以及组织机构id等。

邮件/短信消息的推送无需预先注册服务。

步骤02、推送消息

根据接口消息是否实时，将接口消息分单向和双向两类，单向消息将存储在推送中心，由消息发送方主动拉取。双向消息，由推送中心发送到指定接口上，推送中心提供给消息发送方获取失败消息列表的功能。

客户端根据推送中心提供的api，调用推送服务。

为消除网络抖动，推送中心提供补偿机制。为不影响正常接口消息队列的消费，返回码状态异常的消息将被放入异常处理队列。补偿机制如下：

*接口返回500状态码：根据补偿机制进行重试，重试后仍失败的消息存入数据库

*接口返回4XX状态码：消息直接存入数据库

*接口返回其他非2XX状态码：消息直接存入数据库

步骤03、拉取消息

提供客户端拉取单向消息或拉取失败的消息的功能。对于接口信息的拉取，指定待拉取接口的信息，系统匹配尚未拉取的消息，返回待拉取的消息列表。消息拉取成功后，不可再次拉取。

步骤04、回放服务

步骤05、数据对账

用户通过WEB页面可查询消息推送的结果，并对失败的消息进行重试。

补偿机制说明

推送中心可以根据接口的配置信息进行补偿，若接口未进行配置，则使用默认补偿机制。

推送失败重试机制配置，配置的粒度是接口。

首次时间间隔，指从推送失败开始，多久后进行第一次重试，默认为5分钟，支持自定义，必须为1-60之间的数字，单位为小时、分钟、秒、毫秒

间隔时间均差，指下一次重试推送间隔与本次重试推送间隔的差，设置后，从第二次开始，每次的间隔时间以均差递增。比如：首次间隔为5分钟，均差为5分钟时，第二次的间隔时间为10分钟，第三次的间隔时间为15分钟，第四次的间隔时间为20分钟。9：00第一次重试，9：10第二次重试，9：25第三次重试，9：45第四次重试。必须为1-60之间的数字，单位为小时、分钟、秒、毫秒，必须与首次时间间隔的时间单位一致。

重试次数：默认为3次，可选范围为3-10次。

默认的补偿机制为：首次时间间隔5分钟，间隔时间均差为5分钟，重试次数为3次。

本实施例提供的发票领域的消息处理方法，

支持多类型的消息处理；

支持客户端对接口消息的维护；

提供消息补偿机制；

失败消息提供拉取或回放机制；

对消息类型包括但不限于短信/邮件/接口；

客户端对接口消息的修改可即时生效，不影响客户端的正常业务；

推送中心对失败的消息提供默认的补偿机制；

补偿机制实行后仍失败的消息，推送中心提供给客户端拉取消息内容的方式；

补偿机制实行后仍失败的消息，推送中心提供给客户端回放一段时间内失败消息的方式，这部分失败的消息将由推送中心再次进行推送。

如图2所示，本实施例还提供一种发票领域的消息处理系统，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现上述的发票领域的消息处理方法。

如图3所示为另一实施方式的发票领域的消息处理方法的流程图。

本实施例充分利用企业间商业往来的开票行为数据，在进行ETL处理后储存到数据仓库；通过对开票金额、发票红冲、发票作废、开票时间、经营性现金流稳定性、收入增长数据及行为的分析发现影响企业信用风险的因子，将经营性现金流稳定性与收入增长作为主成分因子通过判别分析预测企业未来信用风险程度。所述信用评估体系能够客观地评估企业经营活动的情况，因为该体系的数据源于企业经营活动中的发票数据，具有实时性和时序性。本发明实例中建立的风险评估模型将经营性现金流稳定性与收入增长作为主成分因子通过判别分析预测企业未来信用风险程度，符合真实业务的应用场景。

需要说明的是：

术语“模块”并非意图受限于特定物理形式。取决于具体应用，模块可以实现为硬件、固件、软件和/或其组合。此外，不同的模块可以共享公共组件或甚至由相同组件实现。不同模块之间可以存在或不存在清楚的界限。

在此提供的算法和显示不与任何特定计算机、虚拟装置或者其它设备固有相关。各种通用装置也可以与基于在此的示教一起使用。根据上面的描述，构造这类装置所要求的结构是显而易见的。此外，本申请也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请的内容，并且上面对特定语言所做的描述是为了披露本申请的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例的虚拟机的创建装置中的一些或者全部部件的一些或者全部功能。本申请还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本申请进行说明而不是对本申请进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述实施例仅表达了本申请的实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims

1.一种发票领域的消息处理方法，其特征在于，包括：

推送消息；

拉取消息；

回放服务；

数据对账；

在所述推送消息之前，所述方法还包括注册的步骤，注册的步骤包括：

客户端将信息注册到推送中心；所述信息包括接口的地址、特征值、请求方式、加密信息和签名信息；所述特征值为税号、appkey、租户id或组织机构id；

所述推送消息包括：

客户端根据推送中心提供的api，调用推送服务；

推送中心提供补偿机制；

若补偿机制实行后仍失败，则推送中心提供给客户端回放一段时间内失败消息的方式，这部分失败的消息将由推送中心再次进行推送；

其中，推送中心根据接口的配置信息进行补偿，推送失败重试机制配置，配置的粒度是接口；

返回状态码异常的消息被放入异常处理队列；

所述补偿机制，包括：

接口返回500状态码：根据补偿机制进行重试，重试后仍失败的消息存入数据库；

接口返回4XX状态码：消息直接存入数据库；

接口返回其他非2XX状态码：消息直接存入数据库。

2.根据权利要求1所述的方法，其特征在于，所述拉取消息，包括：

提供客户端拉取单向消息或拉取失败的消息的功能；

3.根据权利要求1所述的方法，其特征在于，所述回放服务，包括：

4.根据权利要求1所述的方法，其特征在于，所述数据对账，包括通过WEB页面可查询消息推送的结果，并对失败的消息进行重试。

5.一种电子装置，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现如权利要求1-4中任一所述的方法。

6.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行，以实现如权利要求1-4中任一所述的方法。