订单业务数据的处理方法、系统、计算机设备和存储介质
技术领域
本申请涉及订单数据处理技术领域,特别是涉及一种订单业务数据的处理方法、装置、系统、计算机设备和存储介质。
背景技术
在开票业务的业务数据处理领域,一般采用的数据处理流程包括:统一接收上游系统发送的数据流,按照统一的业务处理规则对接收到的数据流进行数据处理,得到开票数据,进而实时将处理得到的开票数据推送到开票系统。例如,传统的开票流程如图1所示。其中,数据处理服务中,按照统一的数据处理规则对所有的订单业务数据进行数据处理。如,对源数据进行定制的维度处理,将源数据转换成汇总数据,例如折扣的分摊、订单的拆分和合并、开票业务数据补全等等。
不同业务类型的订单业务数据,其数据处理的方式有差别,传统的业务数据处理方式无法适应业务数据处理要求。另外,新增业务类型时,需要修改数据处理服务中的数据处理规则,这就意味需要重新启动整套数据处理架构,因此传统的业务数据处理方式拓展性差。
发明内容
基于此,有必要针对上述技术问题,提供一种能够满足各种业务类型的数据处理方式的需求以提高订单业务数据处理的业务拓展性的订单业务数据的处理方法、装置、系统、计算机设备和存储介质。
一种订单业务数据的处理方法,该方法包括:获取订单业务数据,识别订单业务数据的业务类型;获取业务类型的第一配置信息,第一配置信息包括订单处理规则信息;根据订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息。
在其中一个实施例中,一种订单业务数据的处理方法还包括:接收待处理业务数据,待处理业务数据包括订单业务数据;按照预设的第二配置信息对待处理业务数据进行处理,得到各种业务类型的待处理业务数据,第二配置信息用于指示按照各种业务类型对待处理业务数据进行数据拆分;将各种业务类型的待处理业务数据存储到不同的数据库;获取订单业务数据,识别订单业务数据的业务类型,包括:接收数据处理任务指示时,按照数据处理任务指示从对应数据库中获取订单业务数据,并根据对应数据库识别订单业务数据的业务类型。
在其中一个实施例中,第一配置信息还包括任务启动数量,根据订单处理规则信息对订单业务数据进行数据处理,包括:根据任务启动数量启动多条任务;采用多条任务并根据订单处理规则信息对订单业务数据进行数据处理。
在其中一个实施例中,订单处理规则信息包括订单拆分规则信息和订单汇总规则信息,根据订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息,包括:获取订单业务数据中的订单信息;根据订单信息确定订单拆分规则信息时,将订单业务数据按照订单拆分规则信息进行拆分处理,得到多条开票数据信息;根据订单信息确定订单汇总规则信息时,将订单业务数据按照订单汇总规则信息进行汇总处理,得到汇总后的开票数据信息。
在其中一个实施例中,订单处理规则信息还包括验证信息,一种订单业务数据的处理方法还包括:采用验证信息对订单业务数据进行验证处理;若验证处理的结果指示订单业务数据未验证通过,将订单业务数据反馈到订单业务数据的发送方。
在其中一个实施例中,一种订单业务数据的处理方法还包括:将开票数据信息发送到消息中间件;通过消息中间件将开票数据信息发送到开票系统。
优选地,一种订单业务数据的处理方法还包括:获取第三配置信息,采用第三配置信息对消息中间件中的队列进行配置,第三配置信息用于指示配置消息中间件中的队列的数量,队列用于接收开票数据信息。
一种订单业务数据的处理装置,该装置包括:识别模块,用于获取订单业务数据,识别订单业务数据的业务类型;获取模块,用于获取业务类型的第一配置信息,第一配置信息包括订单处理规则信息;处理模块,用于根据订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息。
一种订单业务数据的处理系统,处理系统包括数据处理模块、数据存储模块、消息中间件以及任务调度平台;数据处理模块用于接收上游系统发送的待处理业务数据,并根据业务类型将待处理业务数据进行分类,得到多个业务类型的业务数据,并将多个业务类型的业务数据发送到数据存储模块;数据存储模块包括多个数据库,各数据库用于存储各业务类型的业务数据;任务调度平台用于配置各业务类型的配置信息以及生成各业务类型的调度任务,并向数据处理模块发送各业务类型的配置信息以及调度任务;数据处理模块还用于获取订单业务数据,识别订单业务数据的业务类型,从各业务类型的配置信息中获取业务类型的第一配置信息,第一配置信息包括订单处理规则信息,并根据业务类型的调度任务以及根据订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息,将开票数据信息发送到消息中间件;消息中间件用于按照消息队列的方式接收开票数据信息,并将开票数据信息发送到开票系统。
一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行计算机程序时实现上述任一实施例方法的步骤。
一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现上述任一实施例方法的步骤。
上述订单业务数据的处理方法、装置、系统、计算机设备和存储介质,数据处理系统在获取到订单业务数据时,识别订单业务数据的业务类型,进而根据识别结果获取该业务类型的第一配置信息,通过第一配置信息中的订单处理规则信息对该业务类型的订单业务数据进行数据处理,从而得到订单业务数据的开票数据信息。因此,数据处理系统在对不同业务类型的订单业务数据进行开票信息处理时,能够针对订单业务数据的业务类型获取与之匹配的配置信息,进而采用该配置信息对订单业务数据进行数据处理,从而满足各种业务类型的数据处理方式的需求。另外,不同业务类型可分配不同的配置信息,数据处理系统在业务数据处理时只要获取匹配的配置信息就可执行对应的业务数据处理,从而能够提高数据处理系统的业务拓展性。
附图说明
图1为一个实施例中传统的开票流程的流程示意图;
图2为一个实施例中一种订单业务数据的处理方法的应用环境图;
图3为一个实施例中一种订单业务数据的处理方法的流程示意图;
图4为一个实施例中采用超限拆分规则逻辑的订单业务数据的处理方法的流程示意图;
图5为一个实施例中采用汇总的处理逻辑的订单业务数据的处理方法的流程示意图;
图6为一个实施例中一种订单业务数据的处理系统的结构示意框图;
图7为一个实施例中一种订单业务数据的处理系统的具体组成结构的结构示意图;
图8为一个实施例中数据存储模块204的配置示意图;
图9为一个实施例中一种订单业务数据的处理系统处理订单业务数据的局部流程的流程示意图;
图10为一个实施例中一种订单业务数据的处理系统的订单业务数据处理逻辑的流程示意图;
图11为一个实施例中一种订单业务数据的处理系统的配置信息的界面显示示意图;
图12为另一个实施例中一种订单业务数据的处理系统的配置信息的界面显示示意图;
图13为一个实施例中一种订单业务数据的处理系统的配置信息的界面显示示意图;
图14为一个实施例中一种订单业务数据的处理系统的汇总任务的配置信息的界面显示示意图;
图15为一个实施例中一种订单业务数据的处理装置的结构框图;
图16为一个实施例中计算机设备的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
本申请提供的一种订单业务数据的处理方法,应用于如图2所示的应用环境中。数据处理系统102用于执行本申请的一种订单业务数据的处理方法。具体地,数据处理系统102从数据库104中获取订单业务数据,识别订单业务数据的业务类型。同时,获取业务类型的第一配置信息,第一配置信息包括订单处理规则信息。其中,第一配置信息可以是由终端106进行配置,并由终端106发送到数据处理系统102中。进一步地,数据处理系统102根据第一配置信息中的订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息。在进一步的实施例中,数据处理系统102还可将开票数据信息发送到下游的开票系统108中,以由开票系统108基于开票数据信息对订单业务数据进行开票处理。因此,实现了基于业务类型的配置信息对订单业务数据进行数据处理,满足了各业务类型的数据处理需求。
在一个实施例中,如图3所示,提供了一种订单业务数据的处理方法,以该方法应用于图2中的数据处理系统102为例进行说明,包括以下步骤:
S102,获取订单业务数据,识别订单业务数据的业务类型。
在本实施例中,订单业务数据按照业务类型存储在数据库中。当数据处理系统接收到订单业务数据处理指令时,按照订单业务数据处理指令从数据库中读取订单业务数据,并且识别订单业务数据的业务类型。具体地,数据库为多个,各数据库用于存储不同业务类型的业务数据。订单业务数据处理指令用于指示数据处理系统从指定数据库中获取订单业务数据进行数据处理。数据处理系统根据订单业务数据处理指令从对应的数据库中获取订单业务数据。在对订单业务数据的业务类型进行识别时,可以在对应的数据库的相关信息中读取出订单业务数据的业务类型。
S104,获取业务类型的第一配置信息,第一配置信息包括订单处理规则信息。
在本实施例中,当数据处理系统识别出订单业务数据的业务类型时,获取业务类型的第一配置信息。第一配置信息可以是人工基于不同业务类型进行信息配置后将配置得到的第一配置信息发送到数据处理系统。具体地,人工针对多种业务类型配置多种配置信息,各配置信息与对应的业务类型关联。当数据处理系统识别出订单业务数据的业务类型时,可直接根据业务类型读取到第一配置信息。其中,第一配置信息中包含订单处理规则信息。订单处理规则信息用于指示按照预先设定的信息处理规则对业订单业务数据进行数据处理。此处的订单处理规则可以是人工进行配置。因此,对于不同业务类型的业务数据,可以通过人工配置的方式实现对不同业务类型的业务数据进行不同的数据处理,从而提高数据处理系统在业务数据处理方面的拓展性。
S106,根据订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息。
在本实施例中,数据处理系统根据订单处理规则信息对订单业务数据进行数据处理。订单处理规则信息可以是根据业务类型的开票规则设置。如订单处理规则信息包括凭证效验规则、明细行汇总规则、折扣分摊规则、超限拆分规则、汇总合并规则中的一个或多个。通过订单处理规则信息对订单业务数据进行数据处理,可得到该订单业务数据对应的开票数据信息,从而可以将该开票数据信息发送到开票系统进行开票处理。因此可实现按照不同业务类型开具与业务类型匹配的发票。
上述订单业务数据的处理方法,数据处理系统在获取到订单业务数据时,识别订单业务数据的业务类型,进而根据识别结果获取该业务类型的第一配置信息,通过第一配置信息中的订单处理规则信息对该业务类型的订单业务数据进行数据处理,从而得到订单业务数据的开票数据信息。因此,数据处理系统在对不同业务类型的订单业务数据进行开票信息处理时,能够针对订单业务数据的业务类型获取与之匹配的配置信息,进而采用该配置信息对订单业务数据进行数据处理,从而满足各种业务类型的数据处理方式。另外,不同业务类型可分配不同的配置信息,数据处理系统在业务数据处理时只要获取匹配的配置信息就可执行对应的业务数据处理,从而能够提高数据处理系统的业务拓展性。
在一实施例中,S102之前,还包括:接收待处理业务数据,待处理业务数据包括订单业务数据;按照预设的第二配置信息对待处理业务数据进行处理,得到各种业务类型的待处理业务数据,第二配置信息用于指示按照各种业务类型对待处理业务数据进行数据拆分;将各种业务类型的待处理业务数据存储到不同的数据库。S102包括:接收数据处理任务指示时,按照数据处理任务指示从对应数据库中获取订单业务数据,并根据对应数据库识别订单业务数据的业务类型。
在该实施例中,数据处理系统接收上游系统发送的数据流,数据流中包含待处理业务数据,待处理业务数据中包含订单业务数据。在对待处理业务数据进行存储处理时,数据处理系统获取预设的第二配置信息,第二配置信息用于指示按照各种业务类型对待处理业务数据进行数据拆分。此外,第二配置信息可以是人工输入的用于配置数据存储处理的信息。因此,数据处理系统按照第二配置信息对待处理业务数据进行处理,可以得到各种业务类型的待处理业务数据。也即是,按照第二配置信息可以将接收到的待处理业务数据按照业务类型的维度进行拆分。进一步地,将拆分得到的各种业务类型的待处理业务数据存储到不同的数据库,实现不同业务类型的订单业务数据的分库存储。
参见图1所示,传统对数据流的存储方式中,只是提供了订单接收服务。订单接收服务用于将接收到的原始数据存放的源数据池中,并且源数据池采用单库单表的方式存储接收到的源数据。当数据量达到一定的量级时,单库单表的方式将造成数据库的存储压力,导致对订单业务数据的存储不能满足正常业务需求。该实施例中,数据处理系统通过配置化的方式对接收到的源数据进行分类处理,将不同业务类型的订单业务数据进行分库存储,提高了数据存储的拓展性,解决了订单业务数据的存储问题。
在一实施例中,第一配置信息还包括任务启动数量。S106包括:根据任务启动数量启动多条任务;采用多条任务并根据订单处理规则信息对订单业务数据进行数据处理。
在该实施例中,对于不同业务类型的订单业务数据的处理,还可配置多条任务。具体地,在第一配置信息中配置任务启动数量,数据处理系统根据任务启动数量启动多条任务,各任务均用于执行该订单业务数据的数据处理。其中,多条任务的数量与任务启动数量相同,因此可通过配置的方式控制启动的任务数量。再者,多条任务可以是并发的方式执行根据订单处理规则信息对订单业务数据的数据处理,因此可加快订单业务数据的处理效率。
在一实施例中,订单处理规则信息包括订单拆分规则信息和订单汇总规则信息。S106包括:获取订单业务数据中的订单信息;根据订单信息确定订单拆分规则信息时,将订单业务数据按照订单拆分规则信息进行拆分处理,得到多条开票数据信息;根据订单信息确定订单汇总规则信息时,将订单业务数据按照订单汇总规则信息进行汇总处理,得到汇总后的开票数据信息。
在该实施例中,对订单业务数据的处理可分为订单拆分处理以及订单汇总处理,此时订单处理规则信息中包含订单拆分规则信息和订单汇总规则信息。其中,按照订单业务数据中的订单信息决定采用订单拆分处理规则信息或订单汇总规则信息对订单业务数据进行数据处理。订单信息可以包括订单号、订单明细等信息。
具体地,订单拆分规则信息包括折扣分摊规则与超限拆分规则。折扣分摊规则的分摊逻辑如下:
折扣分摊配置为discountAmount(折扣总金额),discountRate(折扣率),订单业务数据通过saleOrg(销方编码)查询得到对应的discountAmount,discountRate。订单业务数据数据中的discountDataAmount(实际折扣金额)根据amount(不含税金额)取值逻辑为:
当amount*discount Rate<discountAmount;
discountDataAmount=amount*discount Rate;
discountAmount=discountAmount-discountDataAmount;
当amount*discount Rate>discountAmount;
discountDataAmount=discountAmount;
discountAmount=0。
超限拆分规则逻辑如下:
拆分任务参数为shareItemCount(最大明细行);通过saleOrg(销方编码)获取销方配置表最大限额vatSingleLimit。当折扣金额不为空或为0时,shareItemCount不变,以配置为准;折扣金额不为空且不为0时,shareItemCount=shareItemCount/2取整。每行明细因为折扣的存在,票面行数翻倍,从而避免超出票面限行要求。具体的超限拆分规则逻辑还可参见图4所示。如图4所示,按最大明细行拆分规则如下:
当shareItemCount(最大明细行)能被itemCount(明细数量)整除时,invNum(发票数量)=itemCount(明细数量)/shareItemCount(最大明细行);
当shareItemCount(最大明细行)不能能被itemCount(明细数量)整除时,invNum(发票数量)=itemCount(明细数量)/shareItemCount(最大明细行)+1。
此时,按折扣分摊:shareZkje(拆分后票的折扣)=invAmount(拆分后不含税金额)/orderAmount(订单总的不含税金额)*discountDataAmount(总折扣金额);最后一张票折扣金额则用总折扣金额减去之前分摊的所有折扣金额。
具体地,订单汇总规则信息可按照明细行进行汇总。如,对订单业务数据对应的orderItem(订单明细数据)数据按照:‘cmmdtyCode’商品编码的维度对,‘cmmdtyAmount’商品金额,‘cmmdtyNum’商品数量,‘taxAmount’税额,此方式进行累加,得到合计后的‘cmmdtyCode’商品编码,‘cmmdtyAmount’商品金额,‘cmmdtyNum’商品数量,taxAmount’税额,并将合计后的明细保存到orderItemMerge(明细汇总数据)中,orderItemMerge与orderItem是多对一的关系。
例如,订单业务数据为成品油的订单业务数据,汇总的处理逻辑如图5所示。汇总维度包括saleOrg(销方编码),buyerOrg(购方编码),taxRate(税率),isCpy(成品油标记),invoiceType(发票类型),znxbj(正逆向标记),bizType(业务类型),isShareZk(是否分摊过折扣)。如图5所示,得到的待汇总数据可以按照汇总维度查询且可按mergeAmount(合计金额)及mergeItemNum(明细行汇总后的明细数量)正序排序得到查询表。汇总的时候按照顺序累加,然后再进行超行超限判断,提高汇总效率。
在一实施例中,订单处理规则信息还包括验证信息。S104之后,还包括:采用验证信息对订单业务数据进行验证处理;若验证处理的结果指示订单业务数据未验证通过,将订单业务数据反馈到订单业务数据的发送方。
例如,采用验证信息对订单业务数据进行验证处理可以是,对订单业务数据中的头金额和orderItem中的明细金额、税额合计是否一致进行验证。orderItem实时数据接收无法一次性接收完成,故采用定时任务的方式进行验证处理。验证不通过的订单业务数据通过消息中间件推送给上游系统,也即是推送回订单业务数据的发送方。验证通过的则进入下一步的数据处理步骤。下一步的数据处理步骤包括S106。因此,可提高订单业务数据的数据处理的准确性。
在一实施例中,S106之后,还包括:将开票数据信息发送到消息中间件;通过消息中间件将开票数据信息发送到开票系统。优选地,通过消息中间件将开票数据信息发送到开票系统之前,还包括:获取第三配置信息,采用第三配置信息对消息中间件中的队列进行配置,第三配置信息用于指示配置消息中间件中的队列的数量,队列用于接收开票数据信息。
在该实施例中,将开票数据信息发送到消息中间件,通过消息中间件将开票数据信息发送到开票系统的方式能够对开票数据信息发送的开票系统进行解耦。同时,设置第三配置信息,通过第三配置信息对消息中间件中的队列进行配置,可增加消息中间件的队列,实现对队列进行配置管控,控制因数据流量造成的消息中间件中队列的压力,通过业务分担流量,将流量分解到不同的队列进行发票处理。因此,降低了系统因集中并发造成的压力,保障了系统运行的稳定性。
应该理解的是,虽然流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,附图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些子步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
本申请还提供一种订单业务数据的处理系统。如图6所示,处理系统200包括数据处理模块202、数据存储模块204、消息中间件208以及任务调度平台206。
数据处理模块202用于接收上游系统300发送的待处理业务数据,并根据业务类型将待处理业务数据进行分类,得到多个业务类型的业务数据,并将多个业务类型的业务数据发送到数据存储模块204。数据存储模块204包括多个数据库,各数据库用于存储各业务类型的业务数据。任务调度平台206用于配置各业务类型的配置信息以及生成各业务类型的调度任务,并向数据处理模块202发送各业务类型的配置信息以及调度任务。数据处理模块202还用于获取订单业务数据,识别订单业务数据的业务类型,从各业务类型的配置信息中获取业务类型的第一配置信息,第一配置信息包括订单处理规则信息,并根据业务类型的调度任务以及根据订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息,将开票数据信息发送到消息中间件208。消息中间件208用于按照消息队列的方式接收开票数据信息,并将开票数据信息发送到开票系统108。
在一具体实现过程中,一种订单业务数据的处理系统如图7所示。数据处理模块202包括订单服务模块以及数据处理服务模块。订单服务模块中的订单接收服务实时接收上游系统的包含订单业务数据的数据流,并通过路由服务将订单业务数据通过数据处理规则的校验和处理后,发送到数据存储模块204的不同业务类型的数据库中。数据存储模块204包括多种数据库,如源数据池a、源数据池b、源数据池c……汇总池a、汇总池b、汇总池c……。其中,源数据池a、源数据池b、源数据池c……用于存储上游系统发送的不同业务类型的订单业务数据。汇总池a、汇总池b、汇总池c……用于存储数据处理服务模块处理后得到的开票数据信息。其中,数据存储模块204可以包括Mysql数据库和Redis数据库。如图8所示,DB表示数据库,REDIS表示Redis数据库,数据存储模块204采用懒加载的形式提供查询服务。
数据处理模块202中的数据处理服务模块用于提供数据处理服务以及推送开票服务,通过规则配置中路由配置和定时任务进行横向业务拓展。
任务调度平台206用于配置各业务类型的配置信息以及生成各业务类型的调度任务,并向数据处理模块202的数据处理服务模块发送各业务类型的配置信息以及调度任务。如图9所示,任务调度平台206为统一任务调度平台,利用统一任务调度平台和路由服务,利用统一任务调度平台可以设置JOB服务,JOB服务内的订单处理规则信息可以根据业务水平拓展。此时,数据存储模块204的数据存储通过路由规则支持水平拓展。
此外,开票数据信息支持发布订阅,推送开票数据信息到消息中间件,将开票数据信息提供给下游系统的消费方。如图7所示,通过消息中间件解耦,消息中间件中队列支持新增,根据路由配置对队列进行配置管控,控制因数据流量造成队列压力,可以通过业务分担流量,将流量分解到不同的队列进行发票接收处理。
此外,一种订单业务数据的处理系统还包括控制模块。控制模块用于控制数据处理模块202推送到消息中间件的开票数据信息的并发数控制和/或控制数据处理模块202推送开票数据信息的开启和关闭。例如,采用zookeeper提供推送主题的并发数控制及开关控制,同时提供系统降级方案。
此外,一种订单业务数据的处理系统还包括开票系统。开票系统包括开票池。开票池用于提供页面查询数据。页面查询数据可以人为点击实时开票,也可以通过RPA机器人去模拟人为操作。
上述一种订单业务数据的处理系统,具备以下技术效果:
1.通过事件编排触发方式,解决了集中计算瓶颈;
2.良好扩展能力,业务的增长无需重新进行开发,通过配置完成业务上线。
3.服务性能大大提升,通过规则配置、统一调度调度平台配置调整服务并发执行,大大提升了服务的处理能力。
4.串行服务的处理效率提升,对于业务无法并行的业务,通过消息队列降低了耦合度,利用队列进行缓冲,降低了系统因集中并发造成的压力,保障了系统运行的稳定性。
5.折扣分摊、拆分、汇总等逻辑算法很好的解决了数据处理的压力,提高了数据处理的能力。
6.利用RPA机器人技术模拟人为进行开票,提升了开票效率,降低了人力成本。
以下提供一具体实现方式,以对上述订单业务数据的处理系统进行补充说明:
上述订单业务数据的处理系统的订单业务数据处理逻辑参见图10所示。其路由规则配置以及数据处理规则配置如图11、图12、图13所示。其数据处理模块202中的汇总任务的配置如图14所示。汇总任务的配置中可配置:
参数1:成品油明细行数;
参数2:分摊过折扣订单的最大明细行数;
参数3:未分摊过折扣订单的最大明细行数;
参数4:每次处理条数;
参数5:单汇总合并条件查询最大条数。
本申请还提供一种订单业务数据的处理装置,如图15所示,该装置包括识别模块10、获取模块20以及处理模块30。识别模块10,用于获取订单业务数据,识别订单业务数据的业务类型;获取模块20,用于获取业务类型的第一配置信息,第一配置信息包括订单处理规则信息;处理模块30,用于根据订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息。
在其中一个实施例中,一种订单业务数据的处理装置还可以包括存储模块,用于接收待处理业务数据,待处理业务数据包括订单业务数据;按照预设的第二配置信息对待处理业务数据进行处理,得到各种业务类型的待处理业务数据,第二配置信息用于指示按照各种业务类型对待处理业务数据进行数据拆分;将各种业务类型的待处理业务数据存储到不同的数据库。识别模块10具体用于接收数据处理任务指示时,按照数据处理任务指示从对应数据库中获取订单业务数据,并根据对应数据库识别订单业务数据的业务类型。
在其中一个实施例中,第一配置信息还包括任务启动数量,处理模块30具体用于根据任务启动数量启动多条任务;采用多条任务并根据订单处理规则信息对订单业务数据进行数据处理。
在其中一个实施例中,订单处理规则信息包括订单拆分规则信息和订单汇总规则信息,处理模块30具体用于获取订单业务数据中的订单信息;根据订单信息确定订单拆分规则信息时,将订单业务数据按照订单拆分规则信息进行拆分处理,得到多条开票数据信息;根据订单信息确定订单汇总规则信息时,将订单业务数据按照订单汇总规则信息进行汇总处理,得到汇总后的开票数据信息。
在其中一个实施例中,订单处理规则信息还包括验证信息,一种订单业务数据的处理装置还可以包括验证模块,用于采用所述验证信息对订单业务数据进行验证处理;若验证处理的结果指示订单业务数据未验证通过,将订单业务数据反馈到订单业务数据的发送方。
在其中一个实施例中,一种订单业务数据的处理装置还包括发送模块,用于将开票数据信息发送到消息中间件;通过消息中间件将开票数据信息发送到开票系统。
优选地,一种订单业务数据的处理装置还包括配置模块,用于获取第三配置信息,采用第三配置信息对消息中间件中的队列进行配置,第三配置信息用于指示配置消息中间件中的队列的数量,队列用于接收开票数据信息。
关于订单业务数据的处理装置的具体限定可以参见上文中对于订单业务数据的处理方法的限定,在此不再赘述。上述订单业务数据的处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中,提供了一种计算机设备,该计算机设备可以是支持数据处理系统运行的服务器,其内部结构图可以如图16所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中,该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部设备连接,以接收外部设备上的订单业务数据。该计算机程序被处理器执行时以实现一种订单业务数据的处理方法。
本领域技术人员可以理解,图16中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
在一个实施例中,提供了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器执行计算机程序时实现以下步骤:获取订单业务数据,识别订单业务数据的业务类型;获取业务类型的第一配置信息,第一配置信息包括订单处理规则信息;根据订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息。
在其中一个实施例中,处理器执行计算机程序时实现以下步骤:接收待处理业务数据,待处理业务数据包括订单业务数据;按照预设的第二配置信息对待处理业务数据进行处理,得到各种业务类型的待处理业务数据,第二配置信息用于指示按照各种业务类型对待处理业务数据进行数据拆分;将各种业务类型的待处理业务数据存储到不同的数据库;处理器执行计算机程序实现上述的获取订单业务数据,识别订单业务数据的业务类型步骤时,具体实现以下步骤:接收数据处理任务指示时,按照数据处理任务指示从对应数据库中获取订单业务数据,并根据对应数据库识别订单业务数据的业务类型。
在其中一个实施例中,第一配置信息还包括任务启动数量,处理器执行计算机程序实现上述的根据订单处理规则信息对订单业务数据进行数据处理步骤时,具体实现以下步骤:根据任务启动数量启动多条任务;采用多条任务并根据订单处理规则信息对订单业务数据进行数据处理。
在其中一个实施例中,订单处理规则信息包括订单拆分规则信息和订单汇总规则信息,处理器执行计算机程序实现上述的根据订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息步骤时,具体实现以下步骤:获取订单业务数据中的订单信息;根据订单信息确定订单拆分规则信息时,将订单业务数据按照订单拆分规则信息进行拆分处理,得到多条开票数据信息;根据订单信息确定订单汇总规则信息时,将订单业务数据按照订单汇总规则信息进行汇总处理,得到汇总后的开票数据信息。
在其中一个实施例中,订单处理规则信息还包括验证信息,处理器执行计算机程序时实现以下步骤:采用验证信息对订单业务数据进行验证处理;若验证处理的结果指示订单业务数据未验证通过,将订单业务数据反馈到订单业务数据的发送方。
在其中一个实施例中,处理器执行计算机程序时实现以下步骤:将开票数据信息发送到消息中间件;通过消息中间件将开票数据信息发送到开票系统。
优选地,处理器执行计算机程序时实现以下步骤:获取第三配置信息,采用第三配置信息对消息中间件中的队列进行配置,第三配置信息用于指示配置消息中间件中的队列的数量,队列用于接收开票数据信息。
在一个实施例中,提供了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现以下步骤:获取订单业务数据,识别订单业务数据的业务类型;获取业务类型的第一配置信息,第一配置信息包括订单处理规则信息;根据订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息。
在其中一个实施例中,计算机程序被处理器执行时实现以下步骤:接收待处理业务数据,待处理业务数据包括订单业务数据;按照预设的第二配置信息对待处理业务数据进行处理,得到各种业务类型的待处理业务数据,第二配置信息用于指示按照各种业务类型对待处理业务数据进行数据拆分;将各种业务类型的待处理业务数据存储到不同的数据库;计算机程序被处理器执行实现上述的获取订单业务数据,识别订单业务数据的业务类型步骤时,具体实现以下步骤:接收数据处理任务指示时,按照数据处理任务指示从对应数据库中获取订单业务数据,并根据对应数据库识别订单业务数据的业务类型。
在其中一个实施例中,第一配置信息还包括任务启动数量,计算机程序被处理器执行实现上述的根据订单处理规则信息对订单业务数据进行数据处理步骤时,具体实现以下步骤:根据任务启动数量启动多条任务;采用多条任务并根据订单处理规则信息对订单业务数据进行数据处理。
在其中一个实施例中,订单处理规则信息包括订单拆分规则信息和订单汇总规则信息,计算机程序被处理器执行实现上述的根据订单处理规则信息对订单业务数据进行数据处理,得到开票数据信息步骤时,具体实现以下步骤:获取订单业务数据中的订单信息;根据订单信息确定订单拆分规则信息时,将订单业务数据按照订单拆分规则信息进行拆分处理,得到多条开票数据信息;根据订单信息确定订单汇总规则信息时,将订单业务数据按照订单汇总规则信息进行汇总处理,得到汇总后的开票数据信息。
在其中一个实施例中,订单处理规则信息还包括验证信息,计算机程序被处理器执行时实现以下步骤:采用验证信息对订单业务数据进行验证处理;若验证处理的结果指示订单业务数据未验证通过,将订单业务数据反馈到订单业务数据的发送方。
在其中一个实施例中,计算机程序被处理器执行时实现以下步骤:将开票数据信息发送到消息中间件;通过消息中间件将开票数据信息发送到开票系统。
优选地,计算机程序被处理器执行时实现以下步骤:获取第三配置信息,采用第三配置信息对消息中间件中的队列进行配置,第三配置信息用于指示配置消息中间件中的队列的数量,队列用于接收开票数据信息。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限,RAM以多种形式可得,诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。
以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。