CN111901308B - 信息交互方法 - Google Patents

Abstract

本发明公开了一种信息交互方法，涉及通信技术领域，用于解决现有系统之间对接困难的问题，该方法包括以下步骤：接收交互请求；根据所述交互请求确定调用的业务接口；对所述交互请求进行报文解析，并根据所述业务接口对解析后的报文进行格式及协议转换，得到转换后的交互请求；通过所述业务接口转发所述格式转换后的交互请求；接收所述交互请求的响应结果，将所述响应结果转换为预设格式并存储。本发明通过对交互请求进行统一数据处理，进而解决了多个接口对接困难的问题。

Description

信息交互方法

技术领域

本发明涉及通信技术领域，尤其涉及一种信息交互方法。

背景技术

随着通信技术的发展，信息化系统也越来越多，以旅游行业信息化系统为例，目前的旅游行业信息化系统已由原有的单一票务系统发展出了多种不同系统，例如电商交易系统、资讯服务系统、线下票务系统、停车场系统等。

目前，同一景区的不同系统通常由不同的软件供应商提供技术支持，对于不同供应商提供的系统，由于设计思路不一致，会存在系统接口不同的问题，随着业务量的提升，当需要进行增加新的系统或对系统进行修改时，为了满足多个旅游信息化系统的全面协同，所有系统都需要各自的供应商进行系统对接的定制开发。此外，由于对接系统的接口协议不同(如socket、webservice、https等等)、所使用的代码语言不同(如java、delphi、.net等)、系统的建设年代不同，导致返回的结果存在差异，对系统维护造成了巨大麻烦。当景区需要对系统维护时，需要景区协调多个不同的对接供应商进行排查、解决问题，系统维护的效率低。

发明内容

为了克服现有技术的不足，本发明的目的之一在于提供一种信息交互方法，其通过对交互请求及响应结果进行统一处理，降低了业务对接的难度。

本发明的目的之一采用以下技术方案实现：

一种信息交互方法，包括以下步骤：

接收交互请求；

根据所述交互请求确定调用的业务接口；

对所述交互请求进行报文解析，并根据所述业务接口对解析后的报文进行格式及协议转换，得到转换后的交互请求；

通过所述业务接口转发所述格式转换后的交互请求；

接收所述交互请求的响应结果，将所述响应结果转换为预设格式并存储。

进一步地，所述交互请求的格式为预设请求格式。

进一步地，根据所述交互请求确定调用的业务接口，包括以下步骤：

验证接口调用权限；

若验证通过，则识别所述交互请求所需调用的业务接口；

若验证失败，则返回失败结果。

进一步地，所述验证接口调用权限步骤，包括：

根据所述交互请求的私钥签名，通过公钥验证所述接口调用权限。

进一步地，对所述交互请求进行报文解析，并根据所述业务接口进行报文格式及协议转换，包括以下步骤：

当报文解析成功时，根据所述业务接口进行报文格式及协议转换；

当报文解析失败时，返回错误信息或重新进行报文解析。

进一步地，通过所述业务接口转发所述格式转换后的交互请求，包括以下步骤：

调用系统编码，根据所述系统编码匹配所述交互请求的转发链路；

根据所述链路，通过所述业务接口转发所述交互请求。

进一步地，所述系统编码包括路由表及业务逻辑，当所述交互请求包含业务信息时，通过所述路由表进行报文解析；

当所述交互请求不包含业务信息时，根据所述业务逻辑进行报文解析。

进一步地，还包括以下步骤：若未接收到所述响应结果，则按预设规则进行重试。

进一步地，所述交互请求为数据对接请求时，具体包括以下步骤：

接收所述数据对接请求；

根据所述数据对接请求确定业务接口；

对所述数据对接请求进行报文解析，根据所述业务接口进行所述数据对接请求的报文格式及协议转换；

对转换后的所述数据对接请求进行转发；

接收返回数据，并将所述返回数据进行打包；

将打包后的所述返回数据推送至消息存储中心。

进一步地，所述消息存储中心为云端kafka消息中心。

相比现有技术，本发明的有益效果在于：

本发明的信息交互方法通过对业务交互信息进行统一处理，接收请求与接收请求的响应结果都只需通过一个处理接口就可实现对接，解决了不同系统间对接时接口过多的问题，避免了数据丢失问题的出现，降低了系统维护的难度，且保证了数据的格式统一。

附图说明

图1是实施例一的信息交互方法的流程图；

图2是实施例一的转发交互请求方法的流程图；

图3是实施例二的数据对接请求处理方法的流程图。

具体实施方式

以下将结合附图，对本发明进行更为详细的描述，需要说明的是，以下参照附图对本发明进行的描述仅是示意性的，而非限制性的。各个不同实施例之间可以进行相互组合，以构成未在以下描述中示出的其他实施例。

实施例一

实施例一提供了一种信息交互方法，旨在通过对交互请求进行格式转换及相应结果获取，以实现上下游业务的交互。

本实施例中，处理交互请求及响应结果通过一个信息交互系统完成，上下游业务系统只需与该信息交互系统完成接口的对接，就可以实现信息的交互，无需每个业务系统之间再进行接口的对接，减少了业务系统的接口对接数量，降低了维护难度。

请参照图1所示，一种信息交互方法，包括以下步骤：

S110、接收交互请求；

为了加快交互请求的处理速度，提高处理效率，本实施例中通过预设请求格式以限定交互请求的格式，对于旅游业务系统而言，限定交互请求的发送格式也是常规的技术手段；预设请求格式本实施例不作具体限定，例如JSON格式等数据交换格式都可以作为预设请求格式。

S120、根据所述交互请求确定调用的业务接口；

上述的业务接口指的是下游业务系统的接口，例如发送交互请求的请求方是票务平台，那么调用的业务接口就是某一景区的售票业务接口。

为了防止业务接口被恶意第三方调用，本实施例中还提出了一种接口调用权限的验证方法，具体地，包括以下步骤：

验证接口调用权限；

若验证通过，则识别所述交互请求所需调用的业务接口；

若验证失败，则返回失败结果。

上述的验证过程可以通过私钥签名实现，即，根据所述交互请求的私钥签名，通过公钥验证所述接口调用权限。公钥和私钥的生成方式及验证方法是常见的技术手段，本实施例不对此作过多赘述；当然，除了私钥签名的验证方式外，也可以通过其他身份验证方式实现接口调用权限的验证。

S130、对所述交互请求进行报文解析，并根据所述业务接口对解析后的报文进行格式及协议转换，得到转换后的交互请求；

上述的报文指的是是网络中交换与传输的数据单元。报文包含了交互请求的完整数据信息；报文解析的具体过程是常见的技术手段，通过报文解析就可以获得交互请求的具体请求内容。

S130具体包括以下步骤：

当报文解析成功时，根据所述业务接口进行报文格式及协议转换；

当报文解析失败时，返回错误信息或重新进行报文解析。

上述的格式及协议转换可以使用一些开源的转换方法实现，具体方法可以根据实际上下游业务格式及协议进行选择，本实施例不对此作具体限定。

通过上述的报文格式及协议转换解决了不同编程语言开发，或系统架构不同的旅游业务系统之间的格式及协议转换，避免了因为系统不同导致无法进行交互的问题。

S140、通过所述业务接口转发所述格式转换后的交互请求；

请参照图2所示，S140具体包括以下步骤：

S1401、调用系统编码，根据所述系统编码匹配所述交互请求的转发链路；

S1401中的系统编码包括路由表及业务逻辑。路由表用于确定转发链路，转发链路指的是网络数据传输的具体连接路径；业务逻辑主要是一些解析逻辑，可以对交互请求根据下游业务系统的业务逻辑进行进一步地解析，此外业务逻辑也可以包括一些加密方法，以保证信息的保密性。系统编码的设置保证了信息传输的高效性。

具体地，当所述交互请求包含业务信息时，通过所述路由表进行报文解析；

当所述交互请求不包含业务信息时，根据所述业务逻辑进行报文解析。

需要说明的是，路由表和业务逻辑是有同时运作的，路由表保存了所有系统的通信接口和链路，业务逻辑决定了下游业务系统通信接口；此外，当交互请求涉及多个业务接口时，例如交互请求为一笔涉及多个下游业务系统的订单时，业务逻辑会根据订单类型对信息进行判断，确定订单信息需要下发的多个业务系统。同时，对多个业务系统的返回信息分别返回给上游业务系统，以便上游业务系统能够准确知道下游业务系统通信的结果，实现了一对多的通信，并分别返回信息。相比于现有技术上游业务系统分别对接下游业务系统，当订单信息需要分别发送给多个业务系统时，由上游系统自行拆分信息，并分别发送给下游业务系统，业务逻辑加快了处理效率且只需一个接口就可实现上下游业务系统的通信。

S1402、根据所述链路，通过所述业务接口转发所述交互请求。

S1402中的交互请求转发对象通常为下游业务系统，例如景区售票系统，酒店房间预订系统等。

S150、接收所述交互请求的响应结果，将所述响应结果转换为预设格式并储存。

上述接收响应结果时，对于需要获得响应结果的请求方，可以对响应的报文进行解析，并按照请求方的格式重新转换报文，并将转后后的报文返回请求方，请求方即发送交互请求的发送方。

需要说明的是，一些请求方是不需要响应结果的，但在S150中仍然会接收响应结果并进行存储，以保证上下游数据的交互，并且在数据丢失时可以定位出具体的某一组丢失数据。

S150中使用预设格式可以便于响应结果的判别，例如预设格式为固定的“code”：10000,代表请求异构系统业务处理成功；10001，代表异构系统业务处理失败；20000，代表请求异构系统网络不通；20001，代表请求异构系统网络超时。

需要说明的是，若未接收到所述响应结果，则按预设规则进行重试。预设规则可以根据实际情况进行设定，例如过若干秒重新接收一次响应结果。

通过本实施例提供的信息交互方法可以在不进行定制开发的前提下，实现业务系统之间的调用请求，同时实现上下游业务系统之间通信仅通过信息交互系统进行，避免因某一业务系统瘫痪导致系统整体瘫痪。

实施例二

实施例二主要对当交互请求为数据对接请求时处理过程进行了解释和说明。

在实际业务需求中，除了上下游业务系统的交互请求，还包括数据对接请求，例如当有新系统加入时，就需要进行数据对接，以实现数据同步。

请参照图3所示，所述交互请求为数据对接请求时，具体包括以下步骤：

S210、当所述交互请求为数据对接请求时，根据所述数据对接请求确定业务接口；

S220、对所述数据对接请求进行报文解析，根据所述业务接口进行所述数据对接请求的报文格式及协议转换；

S230、对转换后的所述数据对接请求进行转发；

S210-S230过程的具体解释和说明请参照实施例一中S110-S140步骤的相关解释和说明。

S240、接收返回数据，并将所述返回数据进行打包；

上述的返回数据与实施例一的响应结果不同，返回数据指的是业务系统返回的系统数据。

数据打包是常见的现有技术，本实施例不对数据打包的具体过程作过多赘述。

S250、将打包后的所述返回数据推送至消息存储中心。

本实施例中，上述的消息存储中心是一个云端kafka消息中心。

将数据打包并推送至消息存储中心后，业务系统就可以从该消息存储中心获取所需的数据。

通过本实施例提供的数据交互方法，可以解决多业务系统环境下数据平台难以从各业务系统获取到一致数据的难点，实现了各业务系统按照统一格式向同一数据仓库提供数据，数据平台从唯一的数据源获取数据的模式，保证了多旅游业务系统之间数据的一致性。

对本领域的技术人员来说，可根据以上描述的技术方案以及构思，做出其它各种相应的改变以及形变，而所有的这些改变以及形变都应该属于本发明权利要求的保护范围之内。

Claims (8)

1.一种信息交互方法，其特征在于，通过信息交互系统，实现上游业务系统与下游业务系统的信息交互，包括以下步骤：

接收上游业务系统发送的交互请求；

根据所述交互请求确定调用的业务接口，其中，所述业务接口是下游业务系统的接口；

对所述交互请求进行报文解析，并根据所述业务接口对解析后的报文进行格式及协议转换，得到转换后的交互请求；

通过所述业务接口转发所述格式转换后的交互请求，包括：调用系统编码，根据所述系统编码匹配所述交互请求的转发链路，根据所述转发链路，通过所述业务接口转发所述交互请求，其中，所述系统编码包括路由表及业务逻辑，当所述交互请求包含业务信息时，通过所述路由表进行报文解析，当所述交互请求不包含业务信息时，根据所述业务逻辑进行报文解析；

当所述交互请求涉及多个下游业务接口时，所述业务逻辑会根据交互请求的类型对所述交互请求进行判断，确定所述交互请求需要下发的多个业务系统，同时，将多个所述业务系统的返回信息分别返回给上游业务系统，以便上游业务系统能够准确知道下游业务系统通信的结果；

接收所述交互请求的响应结果，将所述响应结果转换为预设格式并存储。

2.如权利要求1所述的信息交互方法，其特征在于，所述交互请求的格式为预设请求格式。

3.如权利要求1所述的信息交互方法，其特征在于，根据所述交互请求确定调用的业务接口，包括以下步骤：

验证接口调用权限；

若验证通过，则识别所述交互请求所需调用的业务接口；

若验证失败，则返回失败结果。

4.如权利要求3所述的信息交互方法，其特征在于，所述验证接口调用权限步骤，包括：

根据所述交互请求的私钥签名，通过公钥验证所述接口调用权限。

5.如权利要求1所述的信息交互方法，其特征在于，对所述交互请求进行报文解析，并根据所述业务接口进行报文格式及协议转换，包括以下步骤：

当报文解析成功时，根据所述业务接口进行报文格式及协议转换；

当报文解析失败时，返回错误信息或重新进行报文解析。

6.如权利要求1所述的信息交互方法，其特征在于，还包括以下步骤：若未接收到所述响应结果，则按预设规则进行重试。

7.如权利要求1所述的信息交互方法，其特征在于，所述交互请求为数据对接请求时，具体包括以下步骤：

接收所述数据对接请求，并根据所述数据对接请求确定业务接口；

对所述数据对接请求进行报文解析，根据所述业务接口进行所述数据对接请求的报文格式及协议转换；

对转换后的所述数据对接请求进行转发；

接收返回数据，并将所述返回数据进行打包；

将打包后的所述返回数据推送至消息存储中心。

8.如权利要求7所述的信息交互方法，其特征在于，所述消息存储中心为云端kafka消息中心。

Images