一种文件交互处理方法、装置及系统与流程

本发明涉及金融科技(fintech)的文件传输领域，尤其涉及一种文件交互处理方法、装置及系统。

背景技术：

随着计算机技术的发展，越来越多的技术(大数据、分布式、区块链(blockchain)、人工智能等)应用在金融领域，传统金融业正在逐步向金融科技(fintech)转变。目前，金融科技领域中，由于信息的处理愈发频繁，对各种文件的交叉分析、综合应用日益增多，文件之间的交互处理就显得越来越重要了。现有技术的文件交互开发流程中，文件交互的双方系统先沟通对齐双方的文件格式，发送方对文件进行打包，提供文件摘要、消息摘要算法(message-digestalgorithm，md5)等校验信息，再通过文件传输协议(filetransferprotocol，ftp)/安全文件传输协议(securefiletransferprotocol，sftp)/超文本传输协议(hypertexttransferprotocol，http)等协议将文件上传至sftp服务器中，再由接收方通过sftp协议将文件从sftp服务器中取出。

现有技术的这种交互方式不但需要开发一套完整的文件打包、传输模块，也无法实现配置与业务分离，从而加大了开发难度和实际使用的复杂度。

技术实现要素：

本申请实施例提供一种文件交互处理的方法、装置及系统，用以提供一种文件交互处理方法。

本申请实施例提供一种文件交互处理方法，具体包括：

获取第一渠道标识、第一文件的第一文件标识以及所述第一文件的第一哈希值；所述第一渠道标识用于指示第一文件接收方所对应的安全文件传输协议sftp服务器；

根据所述第一文件的第一文件标识以及所述第一文件的第一哈希值从文件传输协议fps服务器中下载所述第一文件；

根据所述第一渠道标识将所述第一文件存储至所述第一渠道标识对应的sftp服务器。

一种可能的实现方式，所述根据所述第一文件的第一文件标识以及所述第一文件的第一哈希值从文件传输协议fps服务器中下载所述第一文件，包括：

获取所述fps服务器中的第一文件的第二哈希值；

当所述第一哈希值等于所述第二哈希值时；

根据所述第一文件标识从文件传输协议fps服务器中下载所述第一文件。

一种可能的实现方式，所述根据所述第一渠道标识将所述第一文件存储至所述第一渠道标识对应的sftp服务器之后，还包括：

将推送完成消息反馈给所述第一文件发送方；所述推送完成消息用于通知所述第一文件发送方已完成将所述第一文件存储至所述第一渠道标识对应的sftp服务器。

本申请实施例提供一种文件交互处理系统，具体包括：

数据仓库，用于获取数据，对所述数据进行处理，将处理后的数据打包为第一文件，并将所述第一文件发送至fps服务器；

所述fps服务器，用于存储获取到的所述第一文件，并为所述第一文件分配第一文件标识，以及生成所述第一文件的第一哈希值；向所述数据仓库发送所述第一文件标识以及所述第一哈希值；

所述数据仓库，用于获取所述第一文件标识以及所述第一哈希值，确定第一文件接收方的第一渠道标识，并向批量文件交互系统cap发送所述第一渠道标识、所述第一文件标识以及所述第一哈希值；

cap系统，用于获取所述第一渠道标识、所述第一文件标识以及所述第一哈希值；所述第一渠道标识用于指示所述第一文件接收方所对应的sftp服务器；根据所述第一文件标识以及所述第一哈希值从fps服务器中下载所述第一文件；根据所述第一渠道标识将所述第一文件存储至所述第一渠道标识对应的sftp服务器；

所述sftp服务器，用于存储所述第一文件。

本申请实施例提供一种文件交互处理系统，具体包括：

批量文件交互系统cap，用于获取第二渠道标识；所述第二渠道标识用于指示第二文件发送方所对应的sftp服务器；根据所述第二渠道标识从所述sftp服务器获取第二文件；将所述第二文件发送至fps服务器；

所述fps服务器，用于存储获取到的所述第二文件，并为所述第二文件分配第二文件标识，以及生成所述第二文件的第三哈希值；向所述cap系统发送所述第二文件标识以及所述第三哈希值；

所述cap系统，用于将所述第二文件标识以及所述第三哈希值传递给消息通信队列端口；

接收文件系统，用于监听所述消息通信队列端口，从所述消息通信队列端口获取所述第二文件标识以及所述第三哈希值；根据所述第二文件标识以及所述第三哈希值从fps服务器中下载所述第二文件。

本申请实施例提供一种文件交互处理装置，具体包括：

获取单元，用于获取第一渠道标识、第一文件的第一文件标识以及所述第一文件的第一哈希值；所述第一渠道标识用于指示第一文件接收方所对应的安全文件传输协议sftp服务器；

处理单元，用于根据所述第一文件的第一文件标识以及所述第一文件的第一哈希值从文件传输协议fps服务器中下载所述第一文件；根据所述第一渠道标识将所述第一文件存储至所述第一渠道标识对应的sftp服务器。

一种可能的实现方式，所述处理单元，还用于：

获取所述fps服务器中的第一文件的第二哈希值；

当所述第一哈希值等于所述第二哈希值时；

根据所述第一文件标识从文件传输协议fps服务器中下载所述第一文件。

一种可能的实现方式，所述处理单元之后，还用于：

将推送完成消息反馈给所述第一文件发送方；所述推送完成消息用于通知所述第一文件发送方已完成将所述第一文件存储至所述第一渠道标识对应的sftp服务器。

本申请实施例提供一种计算机设备，包括程序或指令，当所述程序或指令被执行时，使得计算机执行上述任一种可能的设计中的方法。

本申请实施例提供一种存储介质，包括程序或指令，当所述程序或指令被执行时，使得计算机执行上述任一种可能的设计中的方法。

利用本发明提供的文件交互处理方法、装置及系统，具有以下有益效果：通过将环境信息映射为渠道标识，使得文件的开发方不需要关注具体的环境信息，即可实现配置与业务分离，降低了实际使用的复杂度。

附图说明

图1为现有技术的文件交互处理方法的技术架构示意图；

图2为本申请实施例提供的一种文件交互处理方法中的文件推送的技术架构示意图；

图3为本申请实施例提供的一种文件交互处理方法中的文件推送的流程示意图；

图4为本申请实施例提供的一种文件交互处理方法中的文件拉取的技术架构示意图；

图5为本申请实施例提供的一种文件交互处理方法中的文件拉取的流程示意图。

图6为本申请实施例提供的一种文件交互处理方法中的文件推送的替换方法的流程示意图。

具体实施方式

为了更好的理解上述技术方案，下面将结合说明书附图及具体的实施方式对上述技术方案进行详细的说明，应当理解本申请实施例以及实施例中的具体特征是对本申请技术方案的详细的说明，而不是对本申请技术方案的限定，在不冲突的情况下，本申请实施例以及实施例中的技术特征可以相互结合。

随着计算机技术的发展，越来越多的技术(大数据、分布式、区块链(blockchain)、人工智能等)应用在金融领域，传统金融业正在逐步向金融科技(fintech)转变。现有技术中，在金融机构(银行机构、保险机构或证券机构)在进行业务(如银行的贷款业务、存款业务等)开发过程中，文件交互的开发流程主要利用程序打包文件提供文件摘要、md5等校验信息，并通过ftp/sftp/http等协议进行文件传输的过程。

如图1所示，为现有技术的文件交互处理方法的技术架构示意图，当发送方a将文件传输给接收方b时，由双方先沟通对齐文件格式，再由发送方a对文件进行打包，提供md5文件与摘要文件，之后发送方a将文件上传至sftp服务器，接收方b通过sftp协议将文件从sftp服务器中取出。

这种文件交互处理方法需要开发一套完整的文件打包、传输模块，并需要开发ftp等协议的上传、下载功能，甚至需要提供完整的文件监控功能。同时对文件内容的控制能力不够，较难实现文件数据的灵活配置以及敏感数据的屏蔽功能。也无法实现配置与业务分离，导致环境信息与应用业务混杂在一起，从而增加了实际使用的复杂度。

面对愈来愈重要的文件交互流程，本申请实施例提供了一种文件交互处理方法，能够简化文件交互的开发流程，同时降低实际使用的复杂度，具体的技术方案如下。

图2为本申请实施例提供的一种文件交互处理方法中的文件推送的技术架构示意图。图2中所示的文件推送的技术架构包括应用系统201、应用202、分布式数据库(tencentdistributedmysql，tdsql)203、大数据仓库204、数据仓库205、数据文件206、文件交互系统207、批量文件交互系统(cap)208、文件存储系统(fps)209、sftp服务器群210、sftp服务器1211和sftp服务器2212。

其中，应用系统201包含应用202和分布式数据库203。

应用202是与分布式数据库203连接，用于将应用202中需传输的数据存储至分布式数据库203中。

分布式数据库203是与应用202、数据仓库205连接，用于将应用202中需传输的数据通过数据抽取、转换和装载(extract、transformationandloading，etl)进程推送至数据仓库205中生成数据表。

大数据仓库204包含数据仓库205和数据文件206，是与文件交互系统207连接，更具体的，是与批量文件交互系统208和文件存储系统209连接。

数据仓库205是与分布式数据库203、数据文件206和文件交互系统207连接，用于对已生成的数据表按照业务层面需求进行数据的加工处理。

可选的，发送已加工数据的字段给批量文件交互系统208，并接收批量文件交互系统208根据自身配置的字段列表，根据字段列表对已加工数据的字段进行筛选，并将筛选后的字段对应的数据表打包生成数据文件206。

可选的，将数据文件206发送至文件存储系统209，并接收文件存储系统209返回的数据文件206对应的文件标识和哈希值。

可选的，在数据文件206对应的文件标识和哈希值的基础上，加上要传输至的sftp服务器群210中的具体服务器的渠道标识，将这些信息一起发送给批量文件交互系统208，其中，渠道标识包括合作方的sftp地址、账号、密码等信息。

数据文件206是与数据仓库205连接，用于之后流程中生成的打包文件。

文件交互系统207包含批量文件交互系统208和文件存储系统209，是与大数据仓库204连接。

批量文件交互系统208是与大数据仓库204、文件存储系统209、sftp服务器群210连接，用于接收大数据仓库204中的数据仓库205发送的已加工数据的字段，根据自身配置的字段列表，反馈给数据仓库205，数据仓库205根据字段列表对已加工数据的字段进行筛选，并将筛选后的字段对应的数据表打包生成数据文件206。

可选的，接收数据仓库205发送的数据文件206对应的文件标识、哈希值和sftp服务器群210中的具体服务器的渠道标识。

可选的，根据文件标识和哈希值从文件存储系统209下载数据文件。

可选的，下载数据文件后，读取渠道标识中的具体信息，按照具体信息确定sftp服务器群210中的具体sftp服务器，再将数据文件推送至该服务器。

可选的，在将数据文件推送至sftp服务器群210后，将推送完成消息反馈给应用系统201。

文件存储系统209是与大数据仓库204、批量文件交互系统208连接，用于接收大数据仓库204中的数据文件206并存储，再发送数据文件206对应的文件标识和哈希值。

可选的，接收批量文件交互系统208发送的文件标识和哈希值。

sftp服务器群210包含sftp服务器1211、sftp服务器2212等。是与批量文件交互系统208连接，用于接收批量文件交互系统208推送的数据文件206，并存储至对应的具体sftp服务器。

当有内部文件要传输至外部时，具体的推送过程，下面将详细描述。

如图3所示，为本申请实施例提供的一种文件交互处理方法中的文件推送的流程示意图，具体步骤下面将详细描述。

步骤301:数据仓库获取数据，对所述数据进行处理。

具体的，第一文件的数据一般存储在应用系统的分布式数据库中，当需要传输第一文件时，先确定分布式数据库中第一文件的数据所在的数据表接口，再通过etl进程将数据表推送至数据仓库中，在数据仓库中对数据表按照业务层面需求进行加工处理。

之后数据仓库发送已加工处理后的数据字段给批量文件交互系统，由批量文件交互系统将自身配置的字段列表返回给数据仓库，数据仓库根据字段列表对已加工处理后的数据字段进行筛选，并生成筛选后的字段对应的数据表。

其中，这里的批量文件交互系统保存了每个渠道、每个业务的字段，通过这些字段信息，可控制文件打包过程中需要包含的字段列表。举例来说，例如待传输发送出数据仓库的数据表结构具有五个字段，包括：id、name、address、id_no和last_modified_datetime，其中，id是数据表结构中的序号字段、name是数据表结构中的姓名字段、address是数据表结构中的地址字段、id_no是数据表结构中的身份证号码字段，last_modified_datetime是数据表结构中的最后修改的时间字段。而在文件传输过程中，文件交互流程仅需要id、name以及last_modified_datetime，这时就可以在批量文件交互系统中配置id、name以及last_modified_datetime作为筛选的字段列表，再返回给数据仓库。批量文件交互系统以这种可灵活配置的方式实现了文件交互处理中对数据字段的调整、敏感字段的筛选等功能，从而保证了数据的可控性。

步骤302：将处理后的数据打包为第一文件，并将所述第一文件发送至fps服务器。

具体的，数据仓库将筛选后的字段对应的数据表打包为第一文件，并将第一文件发送至fps服务器。

由于内部文件的管理机制是统一存储在fps服务器，之后再上传至sftp服务器中，接下来阐述的内容即为如何将第一文件从fps服务器中获取到再上传至sftp服务器中。详细描述如下。

步骤303：所述fps服务器存储获取到的所述第一文件，并为所述第一文件分配第一文件标识，以及生成所述第一文件的第一哈希值；向所述数据仓库发送所述第一文件标识以及所述第一哈希值。

具体的，fps服务器接收第一文件并存储，并为第一文件分配第一文件标识，以及生成第一文件的第一哈希值。之后会发送第一文件标识以及第一哈希值给数据仓库。

其中，这里的fps服务器有两个功能，包括：1、接收并存储第一文件；2、返回第一文件标识以及第一哈希值。在第2点功能中，第一文件标识是一个64位的字符串，具有唯一性；第一哈希值是一个32位的字符串，记录着第一文件的第一哈希值，若文件有一点改动，例如一比特的变动，都会引起第一哈希值的改变，从而能够识别第一文件是否损坏。

步骤304：所述数据仓库获取所述第一文件标识以及所述第一哈希值，确定第一文件接收方的第一渠道标识，并向批量文件交互系统cap发送所述第一渠道标识、所述第一文件标识以及所述第一哈希值。

具体的，数据仓库在接收到fps服务器发送的第一文件标识和第一哈希值的基础上，根据第一文件的传输需求确定接收方所对应的sftp服务器群中的具体服务器的第一渠道标识，将第一渠道标识、第一文件标识以及第一哈希值一起发送给批量文件交互系统cap。

步骤305：cap系统获取所述第一渠道标识、所述第一文件标识以及所述第一哈希值。

所述第一渠道标识用于指示所述第一文件接收方所对应的sftp服务器；根据所述第一文件标识以及所述第一哈希值从fps服务器中下载所述第一文件；根据所述第一渠道标识将所述第一文件存储至所述第一渠道标识对应的sftp服务器。

具体的，cap系统接收到第一渠道标识、第一文件标识以及第一哈希值，根据第一文件标识以及第一哈希值从fps服务器中下载第一文件；根据第一渠道标识获取到第一文件接收方所对应的sftp服务器，从而将第一文件存储至第一渠道标识对应的sftp服务器。

通过这种方式，将传统文件交互流程中的环境信息映射为渠道标识，使得文件的开发方不需要关注具体的环境信息，即传输第一文件的接收方情况，就能够解耦应用系统与环境信息混合的问题；同时也实现了对环境信息的统一管理，当有环境信息发生变化时，能够做到及时更改。

进一步具体的，步骤305中根据所述第一文件标识以及所述第一哈希值从fps服务器中下载所述第一文件的详细内容如下描述。

获取所述fps服务器中的第一文件的第二哈希值；

当所述第一哈希值等于所述第二哈希值时；

根据所述第一文件标识从文件传输协议fps服务器中下载所述第一文件。

可选的，获取所述fps服务器中的第一文件的第二哈希值；

根据所述第一文件标识从文件传输协议fps服务器中下载所述第一文件。

当所述第一哈希值等于所述第二哈希值时；

确认第一文件完好，否则说明下载过程中出现网络状况等问题导致文件有损坏，需要重新下载第一文件。

步骤306:所述sftp服务器，用于存储所述第一文件。

具体的，sftp服务器接收并存储第一文件，等待接收方从中取出。

步骤307：将推送完成消息反馈给所述第一文件发送方；所述推送完成消息用于通知所述第一文件发送方已完成将所述第一文件存储至所述第一渠道标识对应的sftp服务器。

具体的，步骤306完成后，将推送完成消息反馈给第一文件发送方。这里的推送完成消息通知第一文件发送方已完成将第一文件存储至第一渠道标识对应的sftp服务器中，从而使发送方获知第一文件的处理状态，对第一文件有监控的作用，也确保交互流程的闭环管理。

上述的详细步骤描述是从内部文件要传输给外部系统的角度阐述的，本申请提供的是一种文件交互处理的方法，所以下面再从获取外部文件供内部系统使用的角度来阐述。

如图4所示，图4为本申请实施例提供的一种文件交互处理方法中的文件拉取的技术架构示意图。图4中所示的文件拉取的技术架构包括调度系统401、文件交互系统207、批量文件交互系统(cap)208、文件存储系统(fps)209、sftp服务器群210、sftp服务器1211、sftp服务器2212和接收文件系统402。

其中，调度系统401是与批量文件交互系统208连接，用于在指定的配置时间内，将发送方的渠道标识发送给批量文件交互系统208。

可选的，在成功拉取文件后，接收批量文件交互系统208反馈的拉取成功消息。

文件交互系统207包含批量文件交互系统208和文件存储系统209。

批量文件交互系统208是与调度系统401、文件存储系统209、sftp服务器群210和接收文件系统402连接，用于接收调度系统401发送的发送方的渠道标识，并读取其中的具体信息后，确定文件所在的sftp服务器群210中的位置，从中获取发送方上传的文件。

可选的，因为一般文件是以压缩包形式传输，所以通过配置，能够按照对应格式的将文件包解开，得到文件。

可选的，将文件上传至文件存储系统209，并接收文件存储系统209返回的文件标识和哈希值。

可选的，将文件标识和哈希值传递给配置在拉取渠道管理中的消息通信队列端口。

可选的，在成功拉取文件后，将拉取成功消息反馈给调度系统401。

文件存储系统209是与批量文件交互系统208、接收文件系统202连接，用于接收批量文件交互系统208上传的文件并存储，再发送文件标识和哈希值给批量文件交互系统208。

sftp服务器群210包含sftp服务器1211、sftp服务器2212等，是与批量文件交互系统208连接，用于接受批量文件交互系统208对sftp服务器群210的搜索，再从中获取发送方上传的文件。

接收文件系统402是与批量文件交互系统208、文件存储系统209连接，用于监听批量文件交互系统配置的消息通信队列端口中的文件标识和哈希值，在收到文件标识和哈希值后，调用文件存储系统的软件开发工具包(softwaredevelopmentkit，sdk)下载文件。

当需要获取外部文件供内部系统使用时，具体的拉取过程，下面将详细描述。

如图5所示，为本申请实施例提供的一种文件交互处理方法中的文件拉取的流程示意图，具体步骤下面将详细描述。

步骤501：批量文件交互系统cap获取第二渠道标识；所述第二渠道标识用于指示第二文件发送方所对应的sftp服务器；根据所述第二渠道标识从所述sftp服务器获取第二文件；将所述第二文件发送至fps服务器；

具体的，在步骤501之前，发送方会将第二文件上传至sftp服务器，开发人员将发送方上传的第二文件的拉取时间、拉取频率配置在调度平台中，在配置的拉取时间内，调度平台会运行拉取脚本，将上述发送方的第二渠道标识发送给cap系统。

cap系统在获取第二渠道标识后，根据第二渠道标识确定第二文件发送方所对应的sftp服务器，之后从中获取到发送方上传的第二文件。因为一般文件是以压缩包形式传输，所以cap系统通过配置，再按照对应格式将第二文件包解开，得到第二文件。之后将第二文件上传至fps服务器。

由于内部文件的管理机制是统一存储在fps服务器中，之后再由接收文件系统按需求根据文件标识和哈希值从文件存储系统中下载对应文件。接下来阐述的内容即为接收文件系统如何从fps服务器中获取到第二文件。详细描述如下。

步骤502：fps服务器存储获取到的所述第二文件，并为所述第二文件分配第二文件标识，以及生成所述第二文件的第三哈希值；向所述cap系统发送所述第二文件标识以及所述第三哈希值。

具体的，fps服务器接收第二文件并存储，为第二文件分配第二文件标识，以及生成第二文件的第三哈希值，再将第二文件标识和第三哈希值返回给cap系统。

步骤503：cap系统将所述第二文件标识以及所述第三哈希值传递给消息通信队列端口。

步骤504：接收文件系统监听所述消息通信队列端口，从所述消息通信队列端口获取所述第二文件标识以及所述第三哈希值；根据所述第二文件标识以及所述第三哈希值从fps服务器中下载所述第二文件。

具体的，获取所述fps服务器中的第二文件的第四哈希值；

当所述第三哈希值等于所述第四哈希值时；

根据所述第二文件标识从文件传输协议fps服务器中下载所述第二文件。

可选的，获取所述fps服务器中的第二文件的第四哈希值；

根据所述第二文件标识从文件传输协议fps服务器中下载所述第二文件。

当所述第三哈希值等于所述第四哈希值时；

确认第二文件完好，否则说明下载过程中出现网络状况等问题导致文件有损坏，需要重新下载第二文件。

进一步具体的，在步骤504之后，cap系统将拉取成功消息反馈给调度系统，形成闭环管理。

图6是另一种文件交互处理方法中的文件推送的替换方法的流程示意图，如图所示，在替换方案中，可以利用javasdk代替etl进程推送数据，即不需要将第一文件通过etl进程推送到数据仓库中，而是通过引入cap系统的第三方javasdk包，将发送方的第一文件的数据和第一文件接收方的第一渠道标识传入sdk，之后的过程和图3中文件推送的流程示意图是相同的。通过这种方式，可以简化图3中通过etl进程推送到数据仓库的环节。

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

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

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

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

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