CN112036855A - 数据交互的处理方法、装置、设备及存储介质 - Google Patents

Abstract

本发明涉及大数据领域，应用于智慧医疗领域中，公开了一种数据交互的处理方法、装置、设备及存储介质，用于解决在医疗业务系统中数据处理效率低下，导致支付效率低下的问题。数据交互的处理方法包括：第一服务器通过第一接口获取用户的数据交互请求，通过第二服务器中的支付渠道列表配置数据交互请求的目标支付渠道，并通过第二接口向医疗业务系统返回目标支付渠道；第一服务器对支付请求进行处理，在医疗业务系统中显示支付结果；第一服务器在预置时段内判断支付结果是否为完成支付订单；若支付结果不为完成支付订单，则第一服务器采用分级处理方式关闭未完成的支付订单。此外，本发明还涉及区块链技术，数据交互请求可存储于区块链中。

Description

数据交互的处理方法、装置、设备及存储介质

技术领域

本发明涉及大数据领域，尤其涉及一种数据交互的处理方法、装置、设备及存储介质。

背景技术

随着互联网交易平台的快速发展，为用户提供一个快捷下单及退款退货服务是用户是否使用该交易平台的判定标准之一。在医疗业务场景下，现有的医疗业务系统可以实现与用户进行数据交互的目的，以用户在医疗业务系统中购买一系列的医用商品为例，医疗业务系统可以通过创建交易订单，然后通过交易订单生成支付订单，再将支付订单返回至医疗业务系统后，通过用户输入支付请求从而完成医用商品的购买。

在医疗业务场景下，用户利用现有的交易平台医疗业务系统进行医用商品的购买，用户通过建立订单与支付订单两个步骤才能完成商品购买，在此过程中会进行数据交互，过多的数据交互过程会降低数据处理效率，导致用户的支付效率低下。

发明内容

本发明的主要目的在于解决在医疗业务系统中数据处理效率低下，从而导致支付效率低下的问题。

本发明第一方面提供了一种数据交互的处理方法，包括：第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的目标支付渠道，并根据所述数据交互请求通过第二接口向所述医疗业务系统返回所述目标支付渠道；所述第一服务器获取所述用户通过所述目标支付渠道输入的支付请求，对所述支付请求进行处理，生成所述支付请求的支付结果，并在所述医疗业务系统中显示所述支付结果；所述第一服务器在预置时段内判断所述支付结果是否为完成支付订单；若所述支付结果不为完成支付订单，则所述第一服务器采用分级处理方式关闭未完成的支付订单。

可选的，在本发明第一方面的第一种实现方式中，所述第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的目标支付渠道，并根据所述数据交互请求通过第二接口向所述医疗业务系统返回所述目标支付渠道包括：所述第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的候选支付渠道；所述第一服务器基于所述候选支付渠道确定所述数据交互请求的目标支付渠道；所述第一服务器利用第三方支付平台调用所述目标支付渠道对应的支付链接，并通过第二接口向所述医疗业务系统返回所述目标支付渠道的支付链接，所述支付链接用于指示所述目标支付渠道的地址。

可选的，在本发明第一方面的第二种实现方式中，所述第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的候选支付渠道包括：所述第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，判断所述第一服务器中的配置开关是否为开启状态，所述配置开关用于控制第二服务器的页面显示；若所述配置开关为开启状态，则通过所述第一服务器的校验系统确定所述数据交互请求是否符合预置的交互规则；若所述数据交互请求符合校验系统中预置的交互规则，则所述第一服务器将所述数据交互请求发送到所述第二服务器中，并获取所述第二服务器中的支付渠道列表；所述第一服务器在所述支付渠道列表中查询符合预置展示规则的备选支付渠道，所述预置展示规则用于限定所述备选支付渠道的数量；所述第一服务器按照标准支付规则对所述备选支付渠道进行筛选，得到候选支付渠道。

可选的，在本发明第一方面的第三种实现方式中，所述第一服务器基于所述候选支付渠道确定所述数据交互请求的目标支付渠道包括：所述第一服务器判断数据交互请求是否为直接支付，当所述数据交互请求为直接支付时，所述第一服务器校验所述数据交互请求中的初始支付渠道是否为空数据；当所述数据交互请求中的初始支付渠道不为空数据时，所述第一服务器判断所述初始支付渠道是否为候选支付渠道；当所述初始支付渠道为候选支付渠道时，所述第一服务器将所述初始支付渠道作为目标支付渠道。

可选的，在本发明第一方面的第四种实现方式中，所述第一服务器利用第三方支付平台调用所述目标支付渠道对应的支付链接，并通过第二接口向所述医疗业务系统返回所述目标支付渠道的支付链接，所述支付链接用于指示所述目标支付渠道的地址包括：所述第一服务器按照预置的支付逻辑生成所述目标支付渠道的支付扩展字段，并通过第二接口向第三方支付平台发送所述支付扩展字段；所述第一服务器获取所述第三方支付平台利用所述支付扩展字段生成的支付订单，通过所述支付订单在所述第三方支付平台中调用对应的支付链接接口；所述第一服务器获取所述第三方支付平台采用所述支付链接接口调用的支付链接，并通过所述第二接口将所述支付链接返回至所述医疗业务系统，其中，所述支付链接用于指示所述目标支付渠道的地址。

可选的，在本发明第一方面的第五种实现方式中，所述第一服务器获取所述用户通过所述目标支付渠道输入的支付请求，对所述支付请求进行处理，生成所述支付请求的支付结果，并在所述医疗业务系统中显示所述支付结果还包括：所述第一服务器获取所述用户通过所述目标支付渠道输入的支付请求，将支付请求传输至所述第二服务器中，通过所述第二服务器调用第三方支付平台；所述第一服务器通过所述第三方支付平台生成的支付结果，并在所述医疗业务系统中异步执行显示操作，所述支付结果用于指示所述支付请求的完成情况，所述显示操作用于指示在所述医疗业务系统中显示所述支付结果。

可选的，在本发明第一方面的第六种实现方式中，所述若所述支付结果不为完成支付订单，则所述第一服务器采用分级处理方式关闭未完成的支付订单包括：若所述支付结果不为完成支付订单，则所述第一服务器判断所述支付订单的类别属性；当所述支付订单的类别属性为紧急属性时，所述第一服务器将所述支付订单输入至预置的延迟消息列队中，利用处理线程对所述预置的延迟消息队列中的支付订单进行关闭处理；当所述支付订单的类别属性为普通属性时，所述第一服务器采用预置的分布式定时器对所述支付订单进行关闭处理。

本发明第二方面提供了一种数据交互的处理装置，包括：配置模块，第一服务器用于通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的目标支付渠道，并根据所述数据交互请求通过第二接口向所述医疗业务系统返回所述目标支付渠道；生成模块，所述第一服务器用于获取所述用户通过所述目标支付渠道输入的支付请求，对所述支付请求进行处理，生成所述支付请求的支付结果，并在所述医疗业务系统中显示所述支付结果；判断模块，所述第一服务器用于在预置时段内判断所述支付结果是否为完成支付订单；处理模块，若所述支付结果不为完成支付订单，则所述第一服务器用于采用分级处理方式关闭未完成的支付订单。

可选的，在本发明第二方面的第一种实现方式中，所述配置模块包括：配置单元，所述第一服务器用于通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的候选支付渠道；确定单元，所述第一服务器用于基于所述候选支付渠道确定所述数据交互请求的目标支付渠道；调用单元，所述第一服务器用于利用第三方支付平台调用所述目标支付渠道对应的支付链接，并通过第二接口向所述医疗业务系统返回所述目标支付渠道的支付链接，所述支付链接用于指示所述目标支付渠道的地址。

可选的，在本发明第二方面的第二种实现方式中，所述配置单元具体用于：所述第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，判断所述第一服务器中的配置开关是否为开启状态，所述配置开关用于控制第二服务器的页面显示；若所述配置开关为开启状态，则通过所述第一服务器的校验系统确定所述数据交互请求是否符合预置的交互规则；若所述数据交互请求符合校验系统中预置的交互规则，则所述第一服务器将所述数据交互请求发送到所述第二服务器中，并获取所述第二服务器中的支付渠道列表；所述第一服务器在所述支付渠道列表中查询符合预置展示规则的备选支付渠道，所述预置展示规则用于限定所述备选支付渠道的数量；所述第一服务器按照标准支付规则对所述备选支付渠道进行筛选，得到候选支付渠道。

可选的，在本发明第二方面的第三种实现方式中，所述确定单元具体用于：所述第一服务器判断数据交互请求是否为直接支付，当所述数据交互请求为直接支付时，所述第一服务器校验所述数据交互请求中的初始支付渠道是否为空数据；当所述数据交互请求中的初始支付渠道不为空数据时，所述第一服务器判断所述初始支付渠道是否为候选支付渠道；当所述初始支付渠道为候选支付渠道时，所述第一服务器将所述初始支付渠道作为目标支付渠道。

可选的，在本发明第二方面的第四种实现方式中，所述调用单元具体用于：所述第一服务器按照预置的支付逻辑生成所述目标支付渠道的支付扩展字段，并通过第二接口向第三方支付平台发送所述支付扩展字段；所述第一服务器获取所述第三方支付平台利用所述支付扩展字段生成的支付订单，通过所述支付订单在所述第三方支付平台中调用对应的支付链接接口；所述第一服务器获取所述第三方支付平台采用所述支付链接接口调用的支付链接，并通过所述第二接口将所述支付链接返回至所述医疗业务系统，其中，所述支付链接用于指示所述目标支付渠道的地址。

可选的，在本发明第二方面的第五种实现方式中，所述生成模块具体用于：所述第一服务器获取所述用户通过所述目标支付渠道输入的支付请求，将支付请求传输至所述第二服务器中，通过所述第二服务器调用第三方支付平台；所述第一服务器通过所述第三方支付平台生成的支付结果，并在所述医疗业务系统中异步执行显示操作，所述支付结果用于指示所述支付请求的完成情况，所述显示操作用于指示在所述医疗业务系统中显示所述支付结果。

可选的，在本发明第二方面的第六种实现方式中，所述处理模块具体用于：若所述支付结果不为完成支付订单，则所述第一服务器判断所述支付订单的类别属性；当所述支付订单的类别属性为紧急属性时，所述第一服务器将所述支付订单输入至预置的延迟消息列队中，利用处理线程对所述预置的延迟消息队列中的支付订单进行关闭处理；当所述支付订单的类别属性为普通属性时，所述第一服务器采用预置的分布式定时器对所述支付订单进行关闭处理。

本发明第三方面提供了一种数据交互的处理设备，包括：存储器和至少一个处理器，所述存储器中存储有指令；所述至少一个处理器调用所述存储器中的所述指令，以使得所述数据交互的处理设备执行上述的数据交互的处理方法。

本发明的第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述的数据交互的处理方法。

本发明提供的技术方案中，第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的目标支付渠道，并根据所述数据交互请求通过第二接口向所述医疗业务系统返回所述目标支付渠道；所述第一服务器获取所述用户通过所述目标支付渠道输入的支付请求，对所述支付请求进行处理，生成所述支付请求的支付结果，并在所述医疗业务系统中显示所述支付结果；所述第一服务器在预置时段内判断所述支付结果是否为完成支付订单；若所述支付结果不为完成支付订单，则所述第一服务器采用分级处理方式关闭未完成的支付订单。本发明实施例中，通过将创建订单的步骤与支付订单的步骤结合成一个步骤，缩短了用户进行数据交互的操作路径，本方案可应用于智慧医疗领域中，提高了用户在医疗业务系统中进行数据交互的数据处理效率，进而提高了用户进行支付的支付效率，从而推动智慧城市的建设。

附图说明

图1为本发明实施例中数据交互的处理方法的一个实施例示意图；

图2为本发明实施例中数据交互的处理方法的另一个实施例示意图；

图3为本发明实施例中数据交互的处理装置的一个实施例示意图；

图4为本发明实施例中数据交互的处理装置的另一个实施例示意图；

图5为本发明实施例中数据交互的处理设备的一个实施例示意图。

具体实施方式

本发明实施例提供了一种数据交互的处理方法、装置、设备及存储介质，通过将创建订单与支付订单结合成一步，缩短了用户购买商品时的操作路径，提高用户在医疗业务系统中支付产品的支付效率。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”或“具有”及其任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为便于理解，下面对本发明实施例的具体流程进行描述，请参阅图1，本发明实施例中数据交互的处理方法的一个实施例包括：

用户可以在医疗业务系统上进行不同类别的数据交互，为便于理解，本申请实施例中以用户在医疗业务系统上进行医疗商品购买的数据交互场景为例。下文中所出现的交易订单指的用户与医疗业务系统之间进行交互的数据交互请求，也就是用户在医疗业务系统上需要购买某医疗商品的交互请求。

101、第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将数据交互请求发送至第二服务器，通过第二服务器中的支付渠道列表配置数据交互请求的目标支付渠道，并根据数据交互请求通过第二接口向医疗业务系统返回目标支付渠道；

可以理解的是，本发明的执行主体可以为数据交互的处理装置，还可以是终端或者服务器，具体此处不做限定。本发明实施例以第一服务器为执行主体为例进行说明。

在用户在医疗业务系统上购买商品的场景下，考虑到同一用户可能在同一时间下购买多个商品，现有技术中仅能通过先创建购买商品的交易订单，而后再根据交易订单唤起支付渠道页面并将支付渠道页面返回至医疗业务系统，待用户在医疗业务系统上进行支付后，即可以完成购买商品的操作。但由于用户需要进行提交交易订单以及唤起支付渠道两个操作，这样的操作需要进行“下单”与“支付”两个步骤，提高了用户下单的流失量，因此为了提高用户下单的效率，本申请直接将“下单”与“支付”合并成一步操作。

可以理解的是，这里的第一服务器指的是医疗业务系统中的购物商城，用户可以在购物商城中进行医疗商品的浏览、提交数据交互请求以及进行支付订单的操作；这里的第二服务器指的是医疗业务系统中的收银平台，收银平台用于获取用户进行支付订单的支付渠道；这里的第一接口为下单页接口，第二接口为创建订单接口。

102、第一服务器获取用户通过目标支付渠道输入的支付请求，对支付请求进行处理，生成支付请求的支付结果，并在医疗业务系统中显示支付结果；

第一服务器待确定数据交互请求对应的目标支付渠道之后，需要获取用户通过目标支付渠道输入的支付请求，这里的支付请求用于指示用户选择支付订单或放弃支付订单，在用户选择支付订单的情况下，支付请求中还携带有用户进行支付的支付信息，如：支付信息可以为用户输入的支付指纹，也可以为用户设置的支付密码。第一服务器将支付请求进行处理，生成支付请求的支付结果，这里的支付结果有两种结果：第一、交易订单支付成功；第二、交易订单支付失败，不论第一服务器获得哪种支付结果，均会将支付结果返回至医疗业务系统中，通知用户知晓，以便用户进行下一步操作。需要强调的是，为进一步保证上述数据交互请求的安全性，上述数据交互请求还可以存储于一区块链的节点中。

103、第一服务器在预置时段内判断支付结果是否为完成支付订单；

用户在医疗业务系统中进行商品的购买时，可能出现因医疗业务系统中的商品正在补仓或商品下架等原因，致使用户不能在医疗业务系统中直接购买此商品的情况，也就是说明用户不能进行支付订单的支付，即需要取消支付订单，因此，第一服务器需要在预置时段内判断支付结果是否为完成支付订单，这里的预置时段是通过分布定时器提前设置在医疗业务系统中的，预置时段的时间间隔可以为5分钟，也可以为3小时，本申请并不对预置时段的时间间隔进行限定。

104、若支付结果不为完成支付订单，则第一服务器采用分级处理方式关闭未完成的支付订单。

当第一服务器判断支付结果为未完成支付订单时，因支付订单未及时完成，下单的用户占用了购买该商品的购买名额，导致其他用户不能再购买该商品，因此，第一服务器会对未完成支付的支付订单进行关闭订单的处理，减少资源的浪费。第一服务器在进行未完成订单的关闭处理时，是采用分级方式对未完成订单进行处理的，未完成订单的属性不同，第一服务器处理的方式不同。

本发明实施例中，通过将创建订单的步骤与支付订单的步骤结合成一个步骤，缩短了用户进行数据交互的操作路径，本方案可应用于智慧医疗领域中，提高了用户在医疗业务系统中进行数据交互的数据处理效率，进而提高了用户进行支付的支付效率，从而推动智慧城市的建设。

请参阅图2，本发明实施例中数据交互的处理方法的另一个实施例包括：

201、第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将数据交互请求发送至第二服务器，通过第二服务器中的支付渠道列表配置数据交互请求的候选支付渠道；

具体的，第一服务器首先通过第一接口获取用户在医疗业务系统上提交的数据交互请求，判断第一服务器中的配置开关是否为开启状态，配置开关用于控制第二服务器的页面显示；若配置开关为开启状态，则通过第一服务器的校验系统确定数据交互请求是否符合预置的交互规则；若数据交互请求符合校验系统中预置的交互规则，则第一服务器将数据交互请求发送到第二服务器中，并获取第二服务器中的支付渠道列表；然后第一服务器在支付渠道列表中查询符合预置展示规则的备选支付渠道，预置展示规则用于限定备选支付渠道的数量；最后第一服务器按照标准支付规则对备选支付渠道进行筛选，得到候选支付渠道。

为了实现用户可以在医疗业务系统上进行医疗商品的购买，需要筛选出能够在医疗业务系统上进行交易的医药商品，比如：医疗业务系统上仅支持售卖非处方药和通用医疗器械(温度计)。在确定了医疗商品后，用户可以在多个医疗业务系统中进行筛选，选择需要购买的医疗商品，在用户确定购买的医疗商品后，第一服务器在后端进行创建交易订单及支付订单的操作。

第一服务器首先通过第一接口获取用户在医疗业务系统上提交的数据交互请求，这里的数据交互请求指的是用户在前端进行医疗商品的购买操作。考虑到商品性能和非事务性批量创建订单的特性，医疗业务系统采用内部多线程Thread Pool Executor技术进行并发创建订单，可以将多个医疗商品统一生成一笔交易订单，令用户在医疗业务系统中同一完成支付，提高用户购买医疗商品的效率，具体的，统一生成的交易订单中的医疗商品的数量可以为1个，也可以为50个，交易订单中的医疗商品的数量可以根据实际情况设定，在本申请中并不对交易订单中的医疗商品的数量进行限定。需要强调的是，为进一步保证上述数据交互请求的安全性，上述数据交互请求还可以存储于一区块链的节点中。

第一服务器获取到数据交互请求后，需要判断第一服务器与第二服务器之间的配置开关是否为开启状态，这里的配置开关用于控制第二服务器的页面显示，当配置开关为开始状态，第二服务器中进行的操作可以在医疗业务系统的显示界面中进行显示。然后第一服务器利用校验系统判断数据交互请求是否符合预置的交互规则，如：用户未在医疗业务系统上进行实名登录，不能直接获取用户的真实信息，则该数据交互请求不符合预置的交互规则，第一服务器不能进行后续操作。当第一服务器判定数据交互请求符合校验系统中预置的交互规则时，第一服务器将数据交互请求发送到第二服务器中，并获取第二服务器中的支付渠道列表，需要说明的是，第一服务器在获取支付渠道列表时的接口入参为：source：取paysource，bizline：取bizline，pajk默认为1。这里的支付渠道列表，支付渠道列表指的是可供进行商品购买的付费渠道，如：支付宝、微信、PayPal、贝宝等。在确定数据交互请求的支付渠道列表后，第一服务器需要利用预置展示规则在支付渠道列表中进行筛选，筛选出医疗业务系统支持的备选支付渠道，然后再按照标准支付规则对备选支付渠道进行筛选，筛选出该医疗商品对应进行购买的候选支付渠道。

202、第一服务器基于候选支付渠道确定数据交互请求的目标支付渠道；

具体的，第一服务器判断数据交互请求是否为直接支付，当数据交互请求为直接支付时，第一服务器校验数据交互请求中的初始支付渠道是否为空数据；当数据交互请求中的初始支付渠道不为空数据时，第一服务器判断初始支付渠道是否为候选支付渠道；当初始支付渠道为候选支付渠道时，第一服务器将初始支付渠道作为目标支付渠道。

第一服务器确定候选支付渠道后，第一服务器需要判断数据交互请求是否为直接支付，当数据交互请求为直接支付时，第一服务器才将可以进行支付订单的创建。第一服务器校验数据交互请求中的初始支付渠道是否为空数据，初始支付渠道为用户上一次进行医疗商品购买时所利用的支付渠道，若初始支付渠道为空数据，则按照预置的交易逻辑进行操作；若初始支付渠道不为空数据时，则判断初始支付渠道是否是候选支付渠道中的一个，若初始支付渠道是候选支付渠道中的一个，则第一服务器直接将初始支付渠道确定为目标支付渠道；若初始支付渠道不是候选支付渠道中的一个，则按照预置的交易逻辑进行操作，需要说明的是，预置的交易逻辑为本领域中惯用的交易逻辑，故在此并不赘述。

203、第一服务器利用第三方支付平台调用目标支付渠道对应的支付链接，并通过第二接口向医疗业务系统返回目标支付渠道的支付链接，支付链接用于指示目标支付渠道的地址；

具体的，第一服务器首先按照预置的支付逻辑生成目标支付渠道的支付扩展字段，并通过第二接口向第三方支付平台发送支付扩展字段；然后第一服务器获取第三方支付平台利用支付扩展字段生成的支付订单，通过支付订单在第三方支付平台中调用对应的支付链接接口；最后第一服务器获取第三方支付平台采用支付链接接口调用的支付链接，并通过第二接口将支付链接返回至医疗业务系统，其中，支付链接用于指示目标支付渠道的地址。

第一服务器待确定目标支付渠道后，第一服务器按照预置的支付逻辑生成目标支付渠道对应的支付扩展字段，并利用第二接口向第三方支付平台发送支付扩展字段，这里的第二接口指的是创建订单接口，第三方支付平台可以利用支付扩展字段生成支付订单，然后第一服务器再通过支付订单在第三方支付平台中调用对应的支付链接接口，其中，部分接口参数设定为：props参数传递：directpay；T channel：不能为空；channel Cap：不能为空；client Type：不能为空；parent Channel Cap：可为空。最后第一服务器获取第三方支付平台采用支付链接接口调用的支付链接，并通过第二接口将支付链接返回至医疗业务系统，其中，支付链接用于指示目标支付渠道的地址。

需要说明的是，交易订单包括多个医疗商品时，对应的支付订单中也存在多个需要支付的医疗商品，如果第一服务器使用循环调用单个第二接口，消耗的时段会很长，可能存在超过调用时段在对第二接口进行调用的情况，因此，在本申请中利用单独的线程池进行并发多线程创建订单，如果批量创建订单超过线程池的最大值，第一服务器使用大小为1000的阻塞队列(Linked Blocking Queue)进行排队等待池处理。

204、第一服务器获取用户通过目标支付渠道输入的支付请求，对支付请求进行处理，生成支付请求的支付结果，并在医疗业务系统中显示支付结果；

具体的，第一服务器获取用户通过目标支付渠道输入的支付请求，将支付请求传输至第二服务器中，通过第二服务器调用第三方支付平台；第一服务器通过第三方支付平台生成的支付结果，并在医疗业务系统中异步执行显示操作，支付结果用于指示支付请求的完成情况，显示操作用于指示在医疗业务系统中显示支付结果。

第一服务器待确定数据交互请求对应的目标支付渠道之后，需要获取用户通过目标支付渠道输入的支付请求，这里的支付请求用于指示用户选择支付订单或放弃支付订单，在用户选择支付订单的情况下，支付请求中还携带有用户进行支付的支付信息，如：支付信息可以为用户输入的支付指纹，也可以为用户设置的支付密码。

第一服务器将支付信息传输至第二服务器中，通过第二服务器调用第三方支付平台实现对支付请求的处理，生成支付请求的支付结果。这里的第三方支付平台用于指示买卖双方在互联网上进行相互交易的交易渠道，第三方支付平台可以为微信支付、支付宝支付或银行卡支付，本申请中并不对第三方支付平台进行限定。具体的，第三方支付平台对支付请求进行处理的过程为本领域中常用的技术手段，因此并不在此赘述。

可以理解的是，在用户选择支付订单的情况下，支付请求中还携带有用户进行支付的支付信息，如：支付信息可以为用户输入的支付指纹，也可以为用户设置的支付密码。这里的支付结果有两种结果：第一、交易订单支付成功；第二、交易订单支付失败，不论第一服务器获得哪种支付结果，均会将支付结果返回至医疗业务系统中，通知用户知晓，以便用户进行下一步操作。

205、第一服务器在预置时段内判断支付结果是否为完成支付订单；

用户在医疗业务系统中进行商品的购买时，可能出现因医疗业务系统中的商品正在补仓或商品下架等原因，用户不能在医疗业务系统中直接购买此商品的情况，也就是说明用户不能进行支付订单的支付，即需要取消支付订单，因此，第一服务器需要在预置时段内判断支付结果是否为完成支付订单，这里的预置时段是通过分布定时器提前设置在医疗业务系统中的，预置时段的时间间隔可以为5分钟，也可以为3小时，本申请并不对预置时段的时间间隔进行限定。

206、若支付结果不为完成支付订单，则第一服务器采用分级处理方式关闭未完成的支付订单。

具体的，若支付结果不为完成支付订单，则第一服务器判断支付订单的类别属性；当支付订单的类别属性为紧急属性时，第一服务器将支付订单输入至预置的延迟消息列队中，利用处理线程对预置的延迟消息队列中的支付订单进行关闭处理；当支付订单的类别属性为普通属性时，第一服务器采用预置的分布式定时器对支付订单进行关闭处理。

当支付结果为未完成支付订单时，第一服务器需要判断对应支付订单的类别属性。需要说明的是，第一服务器会将生成的支付订单(支付订单状态为：未完成)以消息列队(message queue，MQ)的形式发送到消息总线中，第一服务器会通过判断支付订单对应的消息对象的个性化特征确定每个支付订单的类别属性，支付订单的类别属性为：紧急属性或正常属性，将这两类需要进行关闭订单处理的关单任务持久化到消息列队的消息表中，然后第一服务器针对这两类不同的关单任务分别进行各自不同响应级别的处理。

对于紧急属性的支付订单，第一服务器会将其输入至预置的延迟消息列队中，然后在预置的延迟消息列队中利用处理线程不停的对该支付订单进行关闭处理。预置的延迟消息队列的特性：该队列中的任务是排队的；该队列中任务的过期时刻不超过当前时刻，一旦第一服务器进行到过期时刻，对应的任务即刻被处理线程取出，即可进行订单关闭操作。以关闭秒杀支付订单(紧急属性)为例，第一服务器首先将秒杀支付订单输入至预置的延迟消息列队中，当超过秒杀订单的过期时刻时，第一服务器及时取出秒杀订单并对秒杀订单进行关闭处理，以此达到了秒杀订单关闭支付的极速要求。进一步说明的是，第一服务器在进行关闭秒杀订单时，从达到过期时刻与在延迟消息列队中取出秒杀订单并进行关闭之间的时段控制在毫秒级别。

对于正常属性的支付订单，第一服务器直接利用预置的分布式定时器对该支付订单进行关闭处理。也就是说，第一服务器会提前设置一个处理时段，当支付订单生成或支付失败后的初始时刻至当前时刻之间的时间间隔大于处理时段时，第一服务器才对支付订单进行关闭处理，在处理时段内，第一服务器处于等待状态。进一步说明的是，处理时段可以为10分钟，也可以为1小时，在本申请中，并不对处理时段的时间进行限定。

本发明实施例中，通过将创建订单的步骤与支付订单的步骤结合成一个步骤，缩短了用户进行数据交互的操作路径，本方案可应用于智慧医疗领域中，提高了用户在医疗业务系统中进行数据交互的数据处理效率，进而提高了用户进行支付的支付效率，从而推动智慧城市的建设。

上面对本发明实施例中数据交互的处理方法进行了描述，下面对本发明实施例中数据交互的处理装置进行描述，请参阅图3，本发明实施例中数据交互的处理装置一个实施例包括：

配置模块301，第一服务器用于通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的目标支付渠道，并根据所述数据交互请求通过第二接口向所述医疗业务系统返回所述目标支付渠道；

生成模块302，所述第一服务器用于获取所述用户通过所述目标支付渠道输入的支付请求，对所述支付请求进行处理，生成所述支付请求的支付结果，并在所述医疗业务系统中显示所述支付结果；

判断模块303，所述第一服务器用于在预置时段内判断所述支付结果是否为完成支付订单；

处理模块304，若所述支付结果不为完成支付订单，则所述第一服务器用于采用分级处理方式关闭未完成的支付订单。

本发明实施例中，通过将创建订单的步骤与支付订单的步骤结合成一个步骤，缩短了用户进行数据交互的操作路径，本方案可应用于智慧医疗领域中，提高了用户在医疗业务系统中进行数据交互的数据处理效率，进而提高了用户进行支付的支付效率，从而推动智慧城市的建设。

请参阅图4，本发明实施例中数据交互的处理装置的另一个实施例包括：

配置模块301，第一服务器用于通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的目标支付渠道，并根据所述数据交互请求通过第二接口向所述医疗业务系统返回所述目标支付渠道；

生成模块302，所述第一服务器用于获取所述用户通过所述目标支付渠道输入的支付请求，对所述支付请求进行处理，生成所述支付请求的支付结果，并在所述医疗业务系统中显示所述支付结果；

判断模块303，所述第一服务器用于在预置时段内判断所述支付结果是否为完成支付订单；

处理模块304，若所述支付结果不为完成支付订单，则所述第一服务器用于采用分级处理方式关闭未完成的支付订单。

可选的，配置模块301包括：

配置单元3011，所述第一服务器用于通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的候选支付渠道；

确定单元3012，所述第一服务器用于基于所述候选支付渠道确定所述数据交互请求的目标支付渠道；

调用单元3013，所述第一服务器用于利用第三方支付平台调用所述目标支付渠道对应的支付链接，并通过第二接口向所述医疗业务系统返回所述目标支付渠道的支付链接，所述支付链接用于指示所述目标支付渠道的地址。

可选的，配置单元3011还可以具体用于：

所述第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，判断所述第一服务器中的配置开关是否为开启状态，所述配置开关用于控制第二服务器的页面显示；

若所述配置开关为开启状态，则通过所述第一服务器的校验系统确定所述数据交互请求是否符合预置的交互规则；

若所述数据交互请求符合校验系统中预置的交互规则，则所述第一服务器将所述数据交互请求发送到所述第二服务器中，并获取所述第二服务器中的支付渠道列表；

所述第一服务器在所述支付渠道列表中查询符合预置展示规则的备选支付渠道，所述预置展示规则用于限定所述备选支付渠道的数量；

所述第一服务器按照标准支付规则对所述备选支付渠道进行筛选，得到候选支付渠道。

可选的，确定单元3012还可以具体用于：

所述第一服务器判断数据交互请求是否为直接支付，当所述数据交互请求为直接支付时，所述第一服务器校验所述数据交互请求中的初始支付渠道是否为空数据；

当所述数据交互请求中的初始支付渠道不为空数据时，所述第一服务器判断所述初始支付渠道是否为候选支付渠道；

当所述初始支付渠道为候选支付渠道时，所述第一服务器将所述初始支付渠道作为目标支付渠道。

可选的，调用单元3013还可以具体用于：

所述第一服务器按照预置的支付逻辑生成所述目标支付渠道的支付扩展字段，并通过第二接口向第三方支付平台发送所述支付扩展字段；

所述第一服务器获取所述第三方支付平台利用所述支付扩展字段生成的支付订单，通过所述支付订单在所述第三方支付平台中调用对应的支付链接接口；

所述第一服务器获取所述第三方支付平台采用所述支付链接接口调用的支付链接，并通过所述第二接口将所述支付链接返回至所述医疗业务系统，其中，所述支付链接用于指示所述目标支付渠道的地址。

可选的，生成模块302还可以具体用于：

所述第一服务器获取所述用户通过所述目标支付渠道输入的支付请求，将支付请求传输至所述第二服务器中，通过所述第二服务器调用第三方支付平台；

所述第一服务器通过所述第三方支付平台生成的支付结果，并在所述医疗业务系统中异步执行显示操作，所述支付结果用于指示所述支付请求的完成情况，所述显示操作用于指示在所述医疗业务系统中显示所述支付结果。

可选的，处理模块304还可以具体用于：

若所述支付结果不为完成支付订单，则所述第一服务器判断所述支付订单的类别属性；

当所述支付订单的类别属性为紧急属性时，所述第一服务器将所述支付订单输入至预置的延迟消息列队中，利用处理线程对所述预置的延迟消息队列中的支付订单进行关闭处理；

当所述支付订单的类别属性为普通属性时，所述第一服务器采用预置的分布式定时器对所述支付订单进行关闭处理。

本发明实施例中，通过将创建订单的步骤与支付订单的步骤结合成一个步骤，缩短了用户进行数据交互的操作路径，本方案可应用于智慧医疗领域中，提高了用户在医疗业务系统中进行数据交互的数据处理效率，进而提高了用户进行支付的支付效率，从而推动智慧城市的建设。

上面图3和图4从模块化功能实体的角度对本发明实施例中的数据交互的处理装置进行详细描述，下面从硬件处理的角度对本发明实施例中数据交互的处理设备进行详细描述。

图5是本发明实施例提供的一种数据交互的处理设备的结构示意图，该数据交互的处理设备500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processing units，CPU)510(例如，一个或一个以上处理器)和存储器520，一个或一个以上存储应用程序533或数据532的存储介质530(例如一个或一个以上海量存储设备)。其中，存储器520和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对数据交互的处理设备500中的一系列指令操作。更进一步地，处理器510可以设置为与存储介质530通信，在数据交互的处理设备500上执行存储介质530中的一系列指令操作。

数据交互的处理设备500还可以包括一个或一个以上电源540，一个或一个以上有线或无线网络接口550，一个或一个以上输入输出接口560，和/或，一个或一个以上操作系统531，例如Windows Serve，Mac OS X，Unix，Linux，FreeBSD等等。本领域技术人员可以理解，图5示出的数据交互的处理设备结构并不构成对数据交互的处理设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

本发明还提供一种数据交互的处理设备，所述计算机设备包括存储器和处理器，存储器中存储有计算机可读指令，计算机可读指令被处理器执行时，使得处理器执行上述各实施例中的所述数据交互的处理方法的步骤。

进一步地，所述计算机可用存储介质可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据区块链节点的使用所创建的数据等。

本发明还提供一种计算机可读存储介质，该计算机可读存储介质可以为非易失性计算机可读存储介质，该计算机可读存储介质也可以为易失性计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在计算机上运行时，使得计算机执行所述数据交互的处理方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本发明所指区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层等。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种数据交互的处理方法，其特征在于，所述数据交互的处理方法包括：

第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的目标支付渠道，并根据所述数据交互请求通过第二接口向所述医疗业务系统返回所述目标支付渠道；

所述第一服务器获取所述用户通过所述目标支付渠道输入的支付请求，对所述支付请求进行处理，生成所述支付请求的支付结果，并在所述医疗业务系统中显示所述支付结果；

所述第一服务器在预置时段内判断所述支付结果是否为完成支付订单；

若所述支付结果不为完成支付订单，则所述第一服务器采用分级处理方式关闭未完成的支付订单。

2.根据权利要求1所述的数据交互的处理方法，其特征在于，所述第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的目标支付渠道，并根据所述数据交互请求通过第二接口向所述医疗业务系统返回所述目标支付渠道包括：

所述第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的候选支付渠道；

所述第一服务器基于所述候选支付渠道确定所述数据交互请求的目标支付渠道；

所述第一服务器利用第三方支付平台调用所述目标支付渠道对应的支付链接，并通过第二接口向所述医疗业务系统返回所述目标支付渠道的支付链接，所述支付链接用于指示所述目标支付渠道的地址。

3.根据权利要求2所述的数据交互的处理方法，其特征在于，所述第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的候选支付渠道包括：

所述第一服务器通过第一接口获取用户在医疗业务系统上提交的数据交互请求，判断所述第一服务器中的配置开关是否为开启状态，所述配置开关用于控制第二服务器的页面显示；

若所述配置开关为开启状态，则通过所述第一服务器的校验系统确定所述数据交互请求是否符合预置的交互规则；

若所述数据交互请求符合校验系统中预置的交互规则，则所述第一服务器将所述数据交互请求发送到所述第二服务器中，并获取所述第二服务器中的支付渠道列表；

所述第一服务器在所述支付渠道列表中查询符合预置展示规则的备选支付渠道，所述预置展示规则用于限定所述备选支付渠道的数量；

所述第一服务器按照标准支付规则对所述备选支付渠道进行筛选，得到候选支付渠道。

4.根据权利要求3所述的数据交互的处理方法，其特征在于，所述第一服务器基于所述候选支付渠道确定所述数据交互请求的目标支付渠道包括：

所述第一服务器判断数据交互请求是否为直接支付，当所述数据交互请求为直接支付时，所述第一服务器校验所述数据交互请求中的初始支付渠道是否为空数据；

当所述数据交互请求中的初始支付渠道不为空数据时，所述第一服务器判断所述初始支付渠道是否为候选支付渠道；

当所述初始支付渠道为候选支付渠道时，所述第一服务器将所述初始支付渠道作为目标支付渠道。

5.根据权利要求2所述的数据交互的处理方法，其特征在于，所述第一服务器利用第三方支付平台调用所述目标支付渠道对应的支付链接，并通过第二接口向所述医疗业务系统返回所述目标支付渠道的支付链接，所述支付链接用于指示所述目标支付渠道的地址包括：

所述第一服务器按照预置的支付逻辑生成所述目标支付渠道的支付扩展字段，并通过第二接口向第三方支付平台发送所述支付扩展字段；

所述第一服务器获取所述第三方支付平台利用所述支付扩展字段生成的支付订单，通过所述支付订单在所述第三方支付平台中调用对应的支付链接接口；

所述第一服务器获取所述第三方支付平台采用所述支付链接接口调用的支付链接，并通过所述第二接口将所述支付链接返回至所述医疗业务系统，其中，所述支付链接用于指示所述目标支付渠道的地址。

6.根据权利要求2所述的数据交互的处理方法，其特征在于，所述第一服务器获取所述用户通过所述目标支付渠道输入的支付请求，对所述支付请求进行处理，生成所述支付请求的支付结果，并在所述医疗业务系统中显示所述支付结果还包括：

所述第一服务器获取所述用户通过所述目标支付渠道输入的支付请求，将支付请求传输至所述第二服务器中，通过所述第二服务器调用第三方支付平台；

所述第一服务器通过所述第三方支付平台生成的支付结果，并在所述医疗业务系统中异步执行显示操作，所述支付结果用于指示所述支付请求的完成情况，所述显示操作用于指示在所述医疗业务系统中显示所述支付结果。

7.根据权利要求1-5中任一项所述的数据交互的处理方法，其特征在于，所述若所述支付结果不为完成支付订单，则所述第一服务器采用分级处理方式关闭未完成的支付订单包括：

若所述支付结果不为完成支付订单，则所述第一服务器判断所述支付订单的类别属性；

当所述支付订单的类别属性为紧急属性时，所述第一服务器将所述支付订单输入至预置的延迟消息列队中，利用处理线程对所述预置的延迟消息队列中的支付订单进行关闭处理；

当所述支付订单的类别属性为普通属性时，所述第一服务器采用预置的分布式定时器对所述支付订单进行关闭处理。

8.一种数据交互的处理装置，其特征在于，所述数据交互的处理装置包括：

配置模块，第一服务器用于通过第一接口获取用户在医疗业务系统上提交的数据交互请求，将所述数据交互请求发送至第二服务器，通过所述第二服务器中的支付渠道列表配置所述数据交互请求的目标支付渠道，并根据所述数据交互请求通过第二接口向所述医疗业务系统返回所述目标支付渠道；

生成模块，所述第一服务器用于获取所述用户通过所述目标支付渠道输入的支付请求，对所述支付请求进行处理，生成所述支付请求的支付结果，并在所述医疗业务系统中显示所述支付结果；

判断模块，所述第一服务器用于在预置时段内判断所述支付结果是否为完成支付订单；

处理模块，若所述支付结果不为完成支付订单，则所述第一服务器用于采用分级处理方式关闭未完成的支付订单。

9.一种数据交互的处理设备，其特征在于，所述数据交互的处理设备包括：存储器和至少一个处理器，所述存储器中存储有指令；

所述至少一个处理器调用所述存储器中的所述指令，以使得所述数据交互的处理设备执行如权利要求1-7中任意一项所述的数据交互的处理方法。

10.一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，其特征在于，所述指令被处理器执行时实现如权利要求1-7中任一项所述数据交互的处理方法。

Images