CN111008082A

CN111008082A - 一种业务请求处理方法及装置

Info

Publication number: CN111008082A
Application number: CN201911083141.3A
Authority: CN
Inventors: 周文玲
Original assignee: Taikang Insurance Group Co Ltd
Current assignee: Taikang Insurance Group Co Ltd
Priority date: 2019-11-07
Filing date: 2019-11-07
Publication date: 2020-04-14

Abstract

本申请公开一种业务请求处理方法及装置，属于数据处理技术领域，该方法包括：目标系统若确定接收到的业务请求中携带业务对接系统的系统标识，则将业务请求存储在任务列表中，接收业务对接系统和每个子业务系统之间业务操作记录的比对结果，若确定比对结果中包含业务对接系统和该子业务系统之间不一致的业务操作记录，则根据不一致的业务操作记录对任务列表中的目标业务请求进行调整，确定调整后任务列表中目标业务请求产生的业务操作记录和该子业务系统的业务操作记录一致后，将任务列表中的目标业务请求提交给核心业务系统，这样，可降低工作人员直接对核心业务系统中的业务数据进行修改的概率，因此，对核心业务系统的侵入比较小、风险比较低。

Description

一种业务请求处理方法及装置

技术领域

本申请涉及数据处理技术领域，尤其涉及一种业务请求处理方法及装置。

背景技术

银行保险是由银行和保险公司合作，通过共同的销售渠道向客户销售保险的一种服务，在这种服务形式下，银行和保险公司之间是通过银保通系统进行对接的。

具体地，日间，客户在银行侧的保险业务系统发起业务请求时，银行侧的保险业务系统将业务请求发送给银保通系统，进而由银保通系统根据接收到的业务请求对保险公司核心业务系统中相应的业务数据实时地进行操作。日终，银保通系统获取银行侧保险业务系统当日的业务操作记录，将银行侧保险业务系统的业务操作记录和自身存储的当日的业务操作记录进行比对，若两者的业务操作记录不一致，则由工作人员对保险公司核心业务系统中的相关保单进行修改，使核心业务系统的业务操作记录与银行侧保险业务系统的业务操作记录一致，这样，直接由工作人员对保险公司核心业务系统中的业务数据进行修改，对核心业务系统的侵入比较大、风险比较高。

发明内容

本申请实施例提供一种业务请求处理方法及装置，用以解决现有技术中直接由工作人员对保险公司核心业务系统中的业务数据进行修改而存在的对核心业务系统的侵入比较大、风险比较高的问题。

第一方面，本申请实施例提供的一种业务请求处理方法，包括：

目标系统接收业务请求；

若确定所述业务请求中携带业务对接系统的系统标识，则将所述业务请求存储在任务列表中；

接收所述业务对接系统和每个子业务系统之间业务操作记录的比对结果；

若确定所述比对结果中包含有所述业务对接系统和所述子业务系统之间不一致的业务操作记录，则根据所述不一致的业务操作记录对所述任务列表中的目标业务请求进行调整，使调整后所述任务列表中目标业务请求产生的业务操作记录和所述子业务系统的业务操作记录保持一致，其中，目标业务请求是指携带所述子业务系统的系统标识的业务请求；

将所述任务列表中的目标业务请求提交给核心业务系统。

在一种可能的实施方式下，根据所述不一致的业务操作记录对所述任务列表中的目标业务请求进行调整，包括：

若所述不一致的业务操作记录为所述业务对接系统比所述子业务系统少保存的业务操作记录，则根据所述不一致的业务操作记录生成新的目标业务请求，将所述新的目标业务请求存储在所述任务列表中；

若所述不一致的业务操作记录为所述业务对接系统比所述子业务系统多保存的业务操作记录，则删除所述任务列表中与所述不一致的业务操作记录对应的目标业务请求。

在一种可能的实施方式下，还包括：

若确定所述比对结果中不包含所述业务对接系统和所述子业务系统之间不一致的业务操作记录，则将所述任务列表中的目标业务请求提交给所述核心业务系统。

在一种可能的实施方式下，还包括：

若确定所述业务请求中未携带所述业务对接系统的系统标识，则将所述业务请求提交给所述核心业务系统。

在一种可能的实施方式下，接收业务请求之后，还包括：

若根据预设的业务互斥规则确定所述业务请求请求的业务与所述任务列表中各业务请求请求的业务互斥，则拒绝所述业务请求。

在一种可能的实施方式下，将每个业务请求提交给所述核心业务系统之后，还包括：

若确定在第一预设时长内未接收到用于表示所述业务请求提交成功的消息，则发送用于表示所述业务请求提交失败的消息。

在一种可能的实施方式下，还包括：

对每个需要进行支付操作的业务请求，在将所述业务请求提交给所述核心业务系统之后，若确定在第二预设时长内未接收到所述业务请求对应的支付成功的消息，则发送用于表示所述业务请求存在支付异常的消息。

第二方面，本申请实施例提供的一种业务请求处理装置，包括：

接收模块，用于接收业务请求，以及用于接收所述业务对接系统和每个子业务系统之间业务操作记录的比对结果；

处理模块，用于若确定所述业务请求中携带业务对接系统的系统标识，则将所述业务请求存储在任务列表中；

调整模块，用于若确定所述比对结果中包含有所述业务对接系统和所述子业务系统之间不一致的业务操作记录，则根据所述不一致的业务操作记录对所述任务列表中的目标业务请求进行调整，使调整后所述任务列表中目标业务请求产生的业务操作记录和所述子业务系统的业务操作记录保持一致，其中，目标业务请求是指携带所述子业务系统的系统标识的业务请求；

提交模块，用于将所述任务列表中的目标业务请求提交给核心业务系统。

在一种可能的实施方式下，所述调整模块具体用于：

在一种可能的实施方式下，所述调整模块还用于：

若确定所述比对结果中不包含所述业务对接系统和所述子业务系统之间不一致的业务操作记录，则指示所述提交模块将所述任务列表中的目标业务请求提交给所述核心业务系统。

在一种可能的实施方式下，所述处理模块还用于：

若确定所述业务请求中未携带所述业务对接系统的系统标识，则指示所述提交模块将所述业务请求提交给所述核心业务系统。

在一种可能的实施方式下，还包括校验模块，所述校验模块用于：

在接收业务请求之后，若根据预设的业务互斥规则确定所述业务请求请求的业务与所述任务列表中各业务请求请求的业务互斥，则拒绝所述业务请求。

在一种可能的实施方式下，还包括异常处理模块，所述异常处理模块用于：

在将每个业务请求提交给所述核心业务系统之后，若确定在第一预设时长内未接收到用于表示所述业务请求提交成功的消息，则发送用于表示所述业务请求提交失败的消息。

第三方面，本申请实施例提供的一种电子设备，包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中：

存储器存储有可被至少一个处理器执行的指令，该指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述业务请求处理方法。

第四方面，本申请实施例提供的一种计算机可读介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述业务请求处理方法。

本申请实施例中，目标系统接收到业务请求后，若确定业务请求中携带业务对接系统的系统标识，则将业务请求存储在任务列表中而不立刻将业务请求发送给核心业务系统，接收到业务对接系统和每个子业务系统之间业务操作记录的比对结果时，若确定比对结果中包含有业务对接系统和该子业务系统之间不一致的业务操作记录，则根据不一致的业务操作记录对任务列表中的目标业务请求进行调整，确定调整后任务列表中目标业务请求产生的业务操作记录和子业务系统的业务操作记录一致后，将任务列表中的目标业务请求提交给核心业务系统进行处理，其中，目标业务请求是指携带该子业务系统的系统标识的业务请求，这样，可降低工作人员直接对核心业务系统中的业务数据进行修改的概率，因此，对核心业务系统的侵入比较小、风险比较低。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为现有技术提供的一种业务请求处理方法的应用场景图；

图2为现有技术提供的一种日间对业务请求进行处理的流程示意图；

图3为现有技术提供的一种日终对业务请求进行处理的流程示意图；

图4为本申请实施例提供的一种业务请求处理方法的应用场景图；

图5为本申请实施例提供的一种日间对业务请求进行处理的流程示意图；

图6为本申请实施例提供的一种日终对业务请求进行处理的流程示意图；

图7为本申请实施例提供的一种业务请求处理方法的流程图；

图8为本申请实施例提供的一种业务请求处理装置的结构示意图；

图9为本申请实施例提供的一种用于实现业务请求处理方法的电子设备的硬件结构示意图。

具体实施方式

为了解决现有技术中直接由工作人员对保险公司核心业务系统中的业务数据进行修改而存在的对核心业务系统的侵入比较大、风险比较高的问题，本申请实施例提供了一种业务请求处理方法及装置。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不互斥的情况下，本申请中的实施例及实施例中的特征可以相互组合。

参见图1，图1示出了现有技术中业务请求处理方法的应用场景图，包括n个子业务系统如保险公司部署在各个银行的保险业务系统、业务对接系统如银保通系统、核心业务系统和资金平台系统，其中，n为整数。

日间，客户在任一子业务系统发起业务请求时，子业务系统将业务请求发送给业务对接系统，进而由业务对接系统根据接收到的业务请求对核心业务系统中相应的业务数据实时地进行操作。

具体地，日间，可根据图2所示的流程对业务请求进行处理，该流程包括以下步骤：

S201：子业务系统向业务对接系统发送查询请求，查询请求中携带保单标识。

S202：业务对接系统根据查询请求中的保单标识从核心业务系统查询保单信息。

其中，保单信息至少包括投保者的身份标识、投保年限、保单的险种、保单状态如无效、有效、保单的受益人等信息。

S203：业务对接系统将查询到的保单信息发送给子业务系统。

S204：子业务系统根据接收到的保单信息向业务对接系统发送业务请求。

S205：业务对接系统根据预设的校验规则对业务请求进行校验，若校验不通过，则进入S206；若校验通过，则进入S207。

比如，某业务的发起条件是保单有效，那么，业务对接系统在接收到相关业务请求时，可校验业务请求对应的保单是否处于有效状态，若校验不通过，则可拒绝业务请求；若校验通过，则可执行后续流程。

S206：业务对接系统拒绝子业务系统的业务请求。

其中，业务对接系统在拒绝子业务系统的业务请求时，可携带拒绝业务请求的原因即校验不通过的原因。

S207：业务对接系统将业务请求提交给核心业务系统，并保存业务请求产生的业务操作记录。

其中，业务操作记录用于描述业务请求对相应保单请求执行的操作、发起业务请求的业务子系统的系统标识、业务请求的发起时间等信息。

S208：核心业务系统对业务请求进行处理。

S209：若业务请求涉及到支付操作，则核心业务系统调用资金平台系统的支付接口进行支付处理。

S210：支付成功时，核心业务系统向业务对接系统返回支付成功的消息。

S211：支付失败时，核心业务系统生成失败清单，以便工作人员进行处理。

上述流程中，客户在子业务系统中发起的业务请求在保险公司的核心业务系统中实时生效，但随着与业务对接系统进行对接的子业务系统越来越多，业务对接系统和保险公司核心业务系统直连对接的模式已难以满足子业务系统的业务需求。

日终，业务对接系统获取每个子业务系统当日的业务操作记录，将该子业务系统当日的业务操作记录和自身存储的当日业务操作记录进行比对，若两者的业务操作记录不一致，则由工作人员对核心业务系统中的相关保单进行修改，使业务对接系统的业务操作记录与该子业务系统的业务操作记录一致。

具体地，日终，可根据图3所示的流程对业务请求进行处理，该流程包括以下步骤：

S301：业务对接系统接收业务操作记录比对请求。

其中，业务操作记录比对请求可以是业务对接系统在设定时刻自动触发的，也可以是人工触发的。

S302：业务对接系统获取子业务系统当日的业务操作记录。

S303：业务对接系统比对业务对接系统当日的业务操作记录和子业务系统当日的业务操作记录，若，则结束本流程，若两者不一致，则进入S304。

S304：两者不一致时，工作人员手工删除核心业务系统中当日多出的业务操作记录或者手工补录核心业务系统中当日少了的业务操作记录。

这样，直接由工作人员手工对核心业务系统中的业务数据进行修改，对核心业务系统的侵入比较大、风险比较高。

为了解决上述图2和图3流程中存在的问题，本申请实施例提供一种业务请求处理方法，图4示出了该业务请求处理方法的应用场景图，包括，m个子业务系统如保险公司部署在各银行的保险业务系统、业务对接系统如银保通系统、目标系统、核心业务系统和资金平台系统，m为整数。

日间，目标系统接收到业务对接系统发送的业务请求时，将业务请求存储在任务列表中而不立刻将业务请求发送给核心业务系统。

具体地，日间，可根据图5所示的流程对业务请求进行处理，该流程包括以下步骤：

S501：子业务系统向业务对接系统发送查询请求，查询请求中携带保单标识。

S502：业务对接系统根据查询请求中的保单标识从核心业务系统查询保单信息。

S503：业务对接系统将查询到的保单信息发送给子业务系统。

S504：子业务系统根据接收到的保单信息向业务对接系统发送业务请求。

S505：业务对接系统根据预设的校验规则对业务请求进行校验，若校验不通过，则进入S506；若校验通过，则进入S507。

比如，保单贷款业务对贷款金额有限制，如贷款金额不能超过保单现价的80％，那么，业务对接系统在接收到保单贷款的相关业务请求时，可校验业务请求中携带的贷款金额是否超过保单现价的80％，若校验不通过，则可拒绝业务请求；若校验通过，则可执行后续流程。

S506：业务对接系统拒绝子业务系统的业务请求。

其中，业务对接系统在拒绝子业务系统的业务请求时，可携带拒绝业务请求的原因即校验不通过的原因如您申请的贷款金额超过上限。

S507：业务对接系统保存业务请求产生的业务操作记录，并将业务请求发送给目标系统。

S508：目标系统根据预设的业务互斥规则，判断任务列表中的业务请求是否会与接收到的业务请求发生互斥，若是，则进入S509；否则，进入S510。

S509：目标系统拒绝业务请求。

S510：目标系统将业务请求存储在任务列表中，并保存业务请求产生的业务操作记录。

另外，实际应用中，保险公司不仅可通过业务对接系统在各银行部署子业务系统，还可通过其它渠道如公众号开展业务，而通过其它渠道发起的业务请求不必经过业务对接系统就可直接到达目标系统，也就是说，目标系统会接收到通过各种渠道发送而来的业务请求。

上述图5介绍的是对通过业务对接系统发送的业务请求(这些业务请求中会携带业务对接系统的系统标识)的处理过程。对通过其它渠道发送的业务请求(这些业务请求中不携带业务对接系统的系统标识)，目标系统同样可根据预设的业务互斥规则，判断任务列表中的业务请求是否会与该业务请求发生互斥，若是，则拒绝该业务请求；否则，可直接将该业务请求提交给核心业务系统进行处理。

进一步地，目标系统若在第一预设时长内若接收到用于表示该业务请求提交成功的消息，可发送用于表示该业务请求提交失败的信息。而当该业务请求涉及支付操作时，目标系统还可判断是否在第二预设时长内接收到用于表示该业务请求所涉及的支付操作支付成功的消息，若否，还可发送用于表示该业务请求存在支付异常的信息，这样，便于及时发现出现异常的业务请求并进行处理，可有效减少客户投诉量，提升企业形象。

日终，目标系统接收业务对接系统发送的当日业务对接系统和每个子业务系统之间业务操作记录的比对结果，若确定比对结果中包含有业务对接系统和该子业务系统之间不一致的业务操作记录，则根据不一致的业务操作记录对任务列表中的目标业务请求进行调整，确定调整后任务列表中目标业务请求产生的业务操作记录和该子业务系统的业务操作记录一致后，将任务列表中的目标业务请求提交给核心业务系统进行处理，其中，目标业务请求是指携带子业务系统的系统标识的业务请求。

具体地，日终，可根据图6所示的流程对业务请求进行处理，该流程包括以下步骤：

S601：业务对接系统接收业务操作记录比对请求。

S602：业务对接系统获取子业务系统当日的业务操作记录。

S603：业务对接系统比对业务对接系统当日的业务操作记录和子业务系统当日的业务操作记录，将两者业务操作记录的比对结果发送给目标系统。

S604：目标系统确定比对结果中包含有业务对接系统和子业务系统之间不一致的业务操作记录时，根据不一致的业务操作记录对任务列表中的目标业务请求进行调整。

其中，目标业务请求中携带有子业务系统的系统标识。

具体实施时，若不一致的业务操作记录为业务对接系统比子业务系统少保存的业务操作记录，则根据不一致的业务操作记录生成新的目标业务请求，将新的目标业务请求存储在任务列表中；若不一致的业务操作记录为业务对接系统比子业务系统多保存的业务操作记录，则删除任务列表中与不一致的业务操作记录对应的目标业务请求。

S605：目标系统确定任务列表中目标业务请求产生的业务操作记录和子业务系统的业务操作记录一致后，将任务列表中的目标业务请求提交给核心业务系统。

S606：目标系统若确定任务列表中存在提交失败的目标业务请求，则发送用于表示该目标业务请求提交失败的消息。

具体实施时，对任务列表中的每个目标业务请求，目标系统在将该目标业务请求发送给核心业务系统之后，若确定在第一预设时长内未接收到用于表示该业务请求提交成功的消息，则可发送用于表示该业务请求提交失败的消息。

S607：核心业务系统对各目标业务请求进行处理。

S608：对涉及到支付操作的目标业务请求，核心业务系统调用资金平台系统的支付接口进行支付处理。

S609：目标系统若确定涉及到支付操作的某目标业务请求支付失败，则发送用于表示该目标业务请求存在支付异常的消息。

具体实施时，目标系统可解析每个目标业务请求以确定该目标业务请求是否涉及支付操作，若确定该目标业务请求涉及支付操作，则在将该目标业务请求提交给核心业务系统之后，还可判断是否在第二预设时长内接收到该目标业务请求对应的支付成功的消息，若未接收到，则可发送用于表示该目标业务请求存在支付异常的消息。

需要说明的是，不管从何种渠道发送而来的业务请求，目标系统在将业务请求发送给核心业务系统之后所触发的异常处理流程是相同的。

如图7所示，为本申请实施例提供的一种业务请求处理方法的流程图，该方法应用于图4中的目标系统，该方法的流程包括以下步骤：

S701：接收业务请求。

S702：根据预设的业务互斥规则判断业务请求请求的业务是否与任务列表中各业务请求请求的业务互斥，若是，则进入S703；若否，则进入S704。

S703：拒绝业务请求。

具体实施时，还可向客户发送用于表示该业务请求被拒绝的消息，消息中可携带校验不通过的原因。这样，不但客户可及时得知自己在子业务系统中请求办理的业务办理失败的原因，提升用户体验，而且可减轻核心业务系统的压力。

S704：判断业务请求中是否携带业务对接系统的系统标识，若否，则进入S705；若是，则进入S706。

实际应用中，保险公司不仅可通过业务对接系统在各银行部署子业务系统，还可通过其它渠道如公众号等开展业务，因此目标系统会接收到通过各种渠道发送的业务请求，而只有通过业务对接系统发送的业务请求才会涉及到业务对接系统和子业务系统之间业务操作记录的比对，因此，目标系统可仅将携带业务对接系统的系统标识的业务请求存储在任务列表中，而将不携带业务对接系统的系统标识的业务请求直接发送给核心业务系统进行处理。

S705：将业务请求提交给核心业务系统。

S706：将业务请求存储在任务列表中。

S707：接收业务对接系统和每个子业务系统之间业务操作记录的比对结果。

S708：判断比对结果中是否包含有业务对接系统和子业务系统之间不一致的业务操作记录，若是，则进入S709；否则，进入S710。

S709：根据不一致的业务操作记录对任务列表中的目标业务请求进行调整，使调整后任务列表中目标业务请求产生的业务操作记录和子业务系统的业务操作记录保持一致。

其中，目标业务请求是指携带子业务系统的系统标识的业务请求。

具体实施时，任务列表中的目标业务请求都将提交给核心业务系统，因此，保证调整后任务列表中目标业务请求产生的业务操作记录和子业务系统的业务操作记录保持一致，即可保证核心业务系统在处理目标业务请求后产生的业务操作记录和子业务系统的业务操作记录保持一致。

S710：将任务列表中的目标业务请求提交给核心业务系统。

具体实施时，若比对结果中不包含业务对接系统和子业务系统之间不一致的业务操作记录，则可认为业务对接系统和子业务系统之间的业务操作记录比对成功，此时，可将任务列表中的目标业务请求提交给核心业务系统，后续，由核心业务系统对任务列表中的目标业务请求进行相应处理。

在上述S705和S710中，将每个业务请求提交给核心业务系统之后，若确定在第一预设时长内未接收到用于表示该业务请求成功提交的消息，则可发送用于表示该业务请求提交失败的消息，这样，可及时发现未成功提交的业务请求，并转由人工进行处理，可尽可能地减少等到客户投诉其业务请求超期仍未得到处理时，相关人员才被动查找原因的情况。

另外，目标系统在将任一业务请求发送给核心业务系统之前，还可判断该业务请求是否涉及支付操作，若确定该业务请求涉及支付操作，则在上述S705和S710中，将每个业务请求提交给核心业务系统之后，若确定在第二预设时长内未接收到用于表示该业务请求涉及的支付操作支付成功的消息，则发送用于表示该业务请求存在支付异常的消息，这样，可及时发现未成功支付的业务请求，并转由人工进行处理，同样可减少等到客户投诉其业务请求超期仍未得到处理时相关人员才被动查找原因的情况。

下面以子业务系统为银行侧的保险业务系统、业务对接系统为银保通系统为例，对本申请实施例进行介绍。

日间，客户在银行侧的保险业务系统请求办理“满期金领取”业务，银保通系统接收到相应的业务请求后，调用目标系统的校验接口PRV_BASExpirationReceive进行校验，报文如下：

<？xml version＝\"1.0\"encoding＝\"UTF-8\"？>

<RCNL>业务受理渠道</RCNL>

<ProcessCode>保全业务代码</ProcessCode>

<OpType>请求操作类型</OpType>

</WebServiceParams>

</BusinessInput>

</WebServiceData>

若校验不通过，则目标系统向银保通系统返回业务请求被拒绝的消息，消息中可携带拒绝原因；若校验通过，则目标系统向银保通系统返回成功标识，银保通系统再调目标系统提交接口CMT_BASExpirationReceive将业务请求发送给目标系统，报文如下：

<？xml version＝\"1.0\"encoding＝\"UTF-8\"？>

<RCNL>业务受理渠道</RCNL>

<ProcessCode>保全业务代码</ProcessCode>

<OpType>请求操作类型</OpType>

<UserLoginName>操作人员对应BPM LDAP用户名</UserLoginName>

<UserName>操作人员姓名</UserName>

<UserId>操作人员编号</UserId>

</OptUserInfo>

</WebServiceParams>

<CEmail>客户电子邮件</CEmail>

<CMobi>客户手机号</CMobi>

<BSWAY>批单反馈方式</BSWAY>

</CustInfo>

<BILLID>保单对应工单号</BILLID>

<payStyle>退费领取方式</payStyle>

<ORCIDCardFlag>OCR识别身份证是否通过</ORCIDCardFlag>

<ORCBankCardFlag>OCR识别银行卡是否通过</ORCBankCardFlag><ORCFaceFlag>人脸识别是否通过</ORCFaceFlag>

<IDVerifyFlag>身份确认是否通过</IDVerifyFlag>

</BusinessInput>

</WebServiceData>

目标系统接收到业务请求后，判断任务队列中各业务请求请求的业务是否与该业务请求请求的业务互斥，若是，则拒绝该业务请求；若否，则将业务请求存储在任务列表中。

日终，银保通系统获取银行侧的保险业务系统当日的业务操作记录，比对自身当日存储的保险业务系统当日的业务操作记录和保险业务系统当日的业务操作记录。

若两者一致，则银保通系统向目标系统发送两者一致的消息，目标系统接收到该消息后，调用核心业务系统的满期提交接口，提交失败的情况将会进入目标系统的问题件处理流程，由人工进行处理，处理之后目标系统再次调用核心业务系统的满期提交接口。若涉及到支付操作，则在提交成功之后，目标系统还可调用资金平台系统的支付接口进行支付，如果支付成功，目标系统再调用核心业务系统的确认接口进行确认，流程结束；如果支付不成功，会进入到目标系统的支付问题件处理流程，由人工进行处理，比如修改账号信息等，处理之后目标系统再次调资金平台系统的支付接口进行支付，直至支付成功，再调用核心业务系统的确认接口进行确认，流程结束。

若两者一致，则分以下两种情况：

一、银行侧保险业务系统保存的业务操作记录多，银保通系统保存的业务操作记录少。

此时，银保通系统按照目标系统满期确认接口CMT_BASExpirationReceive要求的报文封装格式对保险业务系统比银保通系统少保存的业务操作记录进行封装，将封装后的报文提交至目标系统，目标系统自动启动满期领取的流程。

二、银行侧保险业务系统保存的业务操作记录少，银保通系统保存的业务操作记录多。

此时，银保通系统通过调用目标系统的Insert_ReconciliationFailInfo接口告知目标系统多余交易需删除，目标系统删除多余的交易，自动启动满期领取的流程。

本申请实施例中，通过引入目标系统，驱动线下办理环节自动化，可避免银保通系统和银行侧的保险业务系统的业务操作记录不一致情况下的人工干预操作，维持核心业务系统的稳定，并可对银保通系统保全业务建立异常自动处理机制，缩短异常处理时效，提升客户体验。

当本申请实施例中提供的方法以软件或硬件或软硬件结合实现的时候，电子设备中可以包括多个功能模块，每个功能模块可以包括软件、硬件或其结合。

具体的，参见图8所示，为本申请实施例提供的一种业务请求处理装置的结构示意图，包括接收模块801、处理模块802、调整模块803、提交模块804。

接收模块801，用于接收业务请求，以及用于接收所述业务对接系统和每个子业务系统之间业务操作记录的比对结果；

处理模块802，用于若确定所述业务请求中携带业务对接系统的系统标识，则将所述业务请求存储在任务列表中；

调整模块803，用于若确定所述比对结果中包含有所述业务对接系统和所述子业务系统之间不一致的业务操作记录，则根据所述不一致的业务操作记录对所述任务列表中的目标业务请求进行调整，使调整后所述任务列表中目标业务请求产生的业务操作记录和所述子业务系统的业务操作记录保持一致，其中，目标业务请求是指携带所述子业务系统的系统标识的业务请求；

提交模块804，用于将所述任务列表中的目标业务请求提交给核心业务系统。

在一种可能的实施方式下，所述调整模块803具体用于：

在一种可能的实施方式下，所述调整模块803还用于：

在一种可能的实施方式下，所述处理模块802还用于：

在一种可能的实施方式下，还包括校验模块805，所述校验模块805用于：

在一种可能的实施方式下，还包括异常处理模块806，所述异常处理模块806用于：

本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。各个模块相互之间的耦合可以是通过一些接口实现，这些接口通常是电性通信接口，但是也不排除可能是机械接口或其它的形式接口。因此，作为分离部件说明的模块可以是或者也可以不是物理上分开的，既可以位于一个地方，也可以分布到同一个或不同设备的不同位置上。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

参见图9所示，为本申请实施例提供的一种电子设备的结构示意图，该电子设备包括收发器901以及处理器902等物理器件，其中，处理器902可以是一个中央处理单元(central processing unit，CPU)、微处理器、专用集成电路、可编程逻辑电路、大规模集成电路、或者为数字处理单元等等。收发器901用于电子设备和其他设备进行数据收发。

该电子设备还可以包括存储器903用于存储处理器902执行的软件指令，当然还可以存储电子设备需要的一些其他数据，如电子设备的标识信息、电子设备的加密信息、用户数据等。存储器903可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器903也可以是非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)、或者存储器903是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器903可以是上述存储器的组合。

本申请实施例中不限定上述处理器902、存储器903以及收发器901之间的具体连接介质。本申请实施例在图9中仅以存储器903、处理器902以及收发器901之间通过总线904连接为例进行说明，总线在图9中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

处理器902可以是专用硬件或运行软件的处理器，当处理器902可以运行软件时，处理器902读取存储器903存储的软件指令，并在所述软件指令的驱动下，执行前述实施例中涉及的业务请求处理方法。

本申请实施例还提供了一种计算机可读存储介质，存储为执行上述处理器所需执行的计算机可执行指令，其包含用于执行上述处理器所需执行的程序。

在一些可能的实施方式中，本申请提供的业务请求处理方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在电子设备上运行时，所述程序代码用于使所述电子设备执行本说明书上述描述的根据本申请各种示例性实施方式的业务请求处理方法中的步骤。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本申请的实施方式的用于业务请求处理的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在计算设备上运行。然而，本申请的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本申请操作的程序代码，所述程序设计语言包括面向对象的程序设计语言诸如Java、C++等，还包括常规的过程式程序设计语言诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络包括局域网(LAN)或广域网(WAN)连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims

1.一种业务请求处理方法，其特征在于，包括：

目标系统接收业务请求；

将所述任务列表中的目标业务请求提交给核心业务系统。

2.如权利要求1所述的方法，其特征在于，根据所述不一致的业务操作记录对所述任务列表中的目标业务请求进行调整，包括：

3.如权利要求1所述的方法，其特征在于，还包括：

4.如权利要求1所述的方法，其特征在于，还包括：

5.如权利要求1-4任一所述的方法，其特征在于，接收业务请求之后，还包括：

6.如权利要求1-4任一所述的方法，其特征在于，将每个业务请求提交给所述核心业务系统之后，还包括：

7.如权利要求1-4任一所述的方法，其特征在于，还包括：

8.一种业务请求处理装置，其特征在于，包括：

9.一种电子设备，其特征在于，包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中：

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至7任一项权利要求所述的方法。

10.一种计算机可读介质，存储有计算机可执行指令，其特征在于，所述计算机可执行指令用于执行如权利要求1至7任一项权利要求所述的方法。