CN116010062A - 基于组件的文件处理方法及系统 - Google Patents

Abstract

本申请实施例公开了一种基于组件的文件处理方法及系统，任务调度组件监测各业务文件的状态，将各业务文件的状态发送至消息中间件；处理任一业务文件所需的至少一个执行组件中的任一执行组件如果从消息中间件中获得上述任一业务文件的第一状态，对上述任一业务文件执行处理任务，得到处理结果；第一状态为上述任一业务文件的多个状态中与上述任一执行组件对应的状态，第一状态为任一业务文件的非目标状态；不同的执行组件的执行不同的处理任务；上述任一执行组件根据处理结果更新上述任一业务文件的状态；上述任一业务文件的状态为目标状态时，确定上述任一业务文件处理完成；对不同的业务文件进行处理所需的执行组件相同或不同。

Description

基于组件的文件处理方法及系统

技术领域

本申请涉及数据处理技术领域，更具体地说，涉及一种基于组件的文件处理方法及系统。

背景技术

目前，基于互联网的第三方交易平台依托巨量的用户，拥有强大的运营平台及良好的用户体验，成为基金公司争相接入的优质平台。基金公司与第三方交易平台之间采用文件进行交互，比如，第三方交易平台向基金公司提供交易文件，基金公司即时处理交易文件，并在约定的时间内生成相应的文件并上报给第三方交易平台。由于文件量较大，由基金公司的业务员手工对交易文件进行操作是不现实的，因此，有必要提供一种能够对交易文件进行自动化处理的方案。

发明内容

本申请的目的是提供一种基于组件的文件处理方法及系统，包括如下技术方案：

一种基于组件的文件处理方法，包括：

任务调度组件监测各业务文件的状态；

所述任务调度组件将所述各业务文件的状态发送至消息中间件；

处理任一业务文件所需的至少一个执行组件中的任一执行组件如果从所述消息中间件中获得所述任一业务文件的第一状态，对所述任一业务文件执行第一状态对应的处理任务，得到处理结果；所述第一状态为所述任一业务文件的多个状态中与所述任一执行组件对应的状态，所述第一状态为所述任一业务文件的非目标状态；不同的执行组件执行不同的处理任务；

所述任一执行组件根据所述处理结果更新所述任一业务文件的状态；所述任一业务文件的状态为目标状态时，确定所述任一业务文件处理完成；

对不同的业务文件进行处理所需的执行组件相同或不同。

上述方法，优选的，所述任一业务文件所需的至少一个执行组件包括如下几种执行组件中的至少一个：

下载组件、解析组件、下单组件、上报组件和生成组件；其中，

所述下载组件用于从第三方交易平台下载业务文件；

所述解析组件用于对所述下载组件下载的业务文件进行解析；

所述下单组件用于在所述业务文件为下单类业务文件的情况下，基于所述下单类业务文件执行下单逻辑；

所述上报组件用于向所述第三方交易平台上传需要上报的文件；

所述生成组件用于生成需要向所述第三方交易平台上报的文件。

上述方法，优选的，其中，

所述任一业务文件所需的至少一个执行组件包括所述下载组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件和所述解析组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件、所述解析组件和所述下单组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件、所述解析组件、所述下单组件和所述上报组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述生成组件和所述上报组件。

上述方法，优选的，所述任一业务文件的多个状态中存在至少一个状态与所述任一执行组件对应。

上述方法，优选的，所述任一执行组件还用于：

如果所述处理结果表征处理失败，重新对所述任一业务文件执行处理任务。

上述方法，优选的，所述任务调度组件还用于：

如果在预设时长内所述任一执行组件一直未对所述任一业务文件的状态进行更新，触发报警系统报警。

上述方法，优选的，所述下单组件对所述下单类业务文件执行下单逻辑时，用于：

对于所述下单类业务文件中的任一条下单记录，判断所述任一条下单记录是否已经执行过下单逻辑；

如果判断结果为是，禁止对所述任一条下单记录进行处理，如果判断结果为否，对所述任一条下单记录执行下单逻辑。

一种基于组件的文件处理系统，包括：任务调度服务器、消息中间件服务器和至少一执行服务器；每个执行服务器中设置有至少一执行组件，不同的执行服务器中设置不同的执行组件；其中，

所述任务调度服务器用于监测各业务文件的状态；所述任务调度服务器将所述各业务文件的状态发送至所述消息中间件服务器；

处理任一业务文件所需的至少一个执行组件中的任一执行组件所在的执行服务器如果从所述消息中间件服务器中获得所述任一业务文件的第一状态，通过所述任一执行组件对所述任一业务文件执行第一状态对应的处理任务，得到处理结果；根据所述处理结果更新所述任一业务文件的状态；所述任一业务文件的状态为目标状态时，确定所述任一业务文件处理完成；

所述第一状态为所述任一业务文件的多个状态中与所述任一执行组件对应的状态，所述第一状态为所述任一业务文件的非目标状态；不同的执行组件的执行不同的处理任务；对不同的业务文件进行处理所需的执行组件相同或不同。

上述系统，优选的，所述任一业务文件所需的至少一个执行组件包括如下几种执行组件中的至少一个：

下载组件、解析组件、下单组件、上报组件和生成组件；其中，

所述下载组件用于从第三方交易平台下载所述业务文件；

所述解析组件用于对所述下载组件下载的业务文件进行解析；

所述下单组件用于在所述业务文件为下单类业务文件的情况下，基于所述下单类业务文件执行下单逻辑；

所述上报组件用于向所述第三方交易平台上传需要上报的文件；

所述生成组件用于生成需要向所述第三方交易平台上报的文件。

上述系统，优选的，其中，

所述任一业务文件所需的至少一个执行组件包括所述下载组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件和所述解析组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件、所述解析组件和所述下单组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件、所述解析组件、所述下单组件和所述上报组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述生成组件和所述上报组件。

通过以上方案可知，本申请提供的一种基于组件的文件处理方法及系统，任务调度组件监测各业务文件的状态，将各业务文件的状态发送至消息中间件；处理任一业务文件所需的至少一个执行组件中的任一执行组件如果从消息中间件中获得上述任一业务文件的第一状态，对上述任一业务文件执行处理任务，得到处理结果；第一状态为上述任一业务文件的多个状态中与上述任一执行组件对应的状态，第一状态为任一业务文件的非目标状态；不同的执行组件的执行不同的处理任务；上述任一执行组件根据处理结果更新上述任一业务文件的状态；上述任一业务文件的状态为目标状态时，确定上述任一业务文件处理完成；对不同的业务文件进行处理所需的执行组件相同或不同。本申请通过设置任务调度组件、消息中间件和多个执行组件，基于业务文件的状态实现了业务文件的自动处理，从而提高业务文件的处理效率。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的基于组件的文件处理方法的一种实现流程图；

图2为本申请实施例提供的下单类业务文件的状态图的一种示例图；

图3为本申请实施例提供的基于组件的文件处理系统的一种结构示意图。

说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的部分，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例，能够以除了在这里图示的以外的顺序实施。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有付出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

如图1所示，为本申请实施例提供的基于组件的文件处理方法的一种实现流程图，可以包括：

步骤S101：任务调度组件监测各业务文件的状态。

每个业务文件具有多个状态，每个业务在同一时刻仅处于一个状态。

不同的业务文件的多个状态存在至少部分相同。也就是说，不同的业务文件的多个状态可能完全相同，也可能只有部分状态相同

可选的，任务调度组件可以从数据库中读取业务文件的状态。

步骤S102：任务调度组件将各业务文件的状态发送至消息中间件。

任务调度组件获得任一业务文件的状态后，可以以消息的形式将该任一业务文件的状态发送至消息中间件。

可选的，消息中间件维护有多个队列，不同的队列对应不同的执行组件，每个执行组件对应的队列中用于存储与该执行组件对应的状态。可选的，由于每个执行组件可以对至少一个业务文件进行处理，因此，任务调度器可以将上述任一业务文件的状态存储至对应的执行组件所对应的队列中。

步骤S103：处理任一业务文件所需的至少一个执行组件中的任一执行组件如果获得上述任一业务文件的第一状态，对上述任一业务文件执行第一状态对应的处理任务，得到处理结果。

其中，第一状态为上述任一业务文件的多个状态中与上述任一执行组件对应的状态，第一状态为上述任一业务文件的非目标状态；不同的执行组件执行不同的处理任务；对不同的业务文件进行处理所需的执行组件相同或不同。

对不同的业务文件进行处理所需的执行组件可能完全不同，或者，对不同的业务文件进行处理所需的执行组件存在部分不同，或者，对不同的业务文件进行处理所需的执行组件完全相同。

上述任一执行组件从其对应的队列中读取业务文件的状态，每读取到一个业务文件的状态，执行一次读取的状态对应的处理任务。因此，当上述任一执行组件从其对应的队列中读取到上述任一业务文件的第一状态时，对上述任一业务文件执行第一状态对应的业务处理。

步骤S104：上述任一执行组件根据处理结果更新上述任一业务文件的状态。

上述任一执行组件可以根据处理结果在数据库中更新上述任一业务文件的状态。

上述任一业务文件的状态为目标状态时，确定上述任一业务文件处理完成。

本申请实施例提供的基于组件的文件处理方法，通过设置任务调度组件、消息中间件和多个执行组件，基于业务文件的状态实现了业务文件的自动处理，从而提高业务文件的处理效率。

本申请研究发现，基金公司与第三方交易平台(比如，阿里余利宝，这是一种理财工具)等的业务文件的交互，基本为以下五种业务文件处理方式：下载、解析、下单、生成与报送。其中，

下载主要是基金公司侧的设备从第三方交易平台下载业务文件。

解析是指基金公司侧的设备对从第三方交易平台下载下来的业务文件进行解析，以存入本地数据库。

下单是指基金公司侧的设备在业务文件为下单类业务文件(比如，开户文件、申购文件、赎回文件等)的情况下，需要针对业务文件执行实际的下单处理逻辑，比如，开户逻辑、申购逻辑、赎回逻辑等。

生成主要是基金公司侧的设备根据与第三方交易平台的约定生成需要向第三方交易平台报送的文件。

报送主要是基金公司侧的设备向第三方交易平台上传需要上报的文件。

基于上述研究，本申请设计了如下五种组件：下载组件、解析组件、下单组件、上报组件和生成组件；其中，

下载组件用于从第三方交易平台下载业务文件。下载组件可以基于安全文件传送协议(SSH File Transfer Protocol，)从第三方交易平台下载业务文件，或者，下载组件可以通过深证通从第三方交易平台下载业务文件。

解析组件用于对下载组件下载的业务文件进行解析，以将解析到的业务数据存入本地数据库。

下单组件用于在业务文件为下单类业务文件的情况下，基于下单类业务文件执行下单逻辑。

生成组件用于生成需要向第三方交易平台上报的文件。

上报组件用于向第三方交易平台上传需要上报的文件。需要上报的文件可以是生成组件生成的文件，也可以是下单组件执行下单逻辑后生成的需要上报的文件。

另外，基金公司侧的设备与第三方交易平台交互的业务文件有多种类型，不同类型的业务文件需要的处理方式可能是不同的。比如，

有些业务文件只需要基金公司从第三方交易平台下载下来就可以了，例如，第三方交易平台提供的销售适当性文件或客户持仓情况文件等。其中，销售适当性文件明确了基金公司应尽的义务和责任；客户持仓情况用于基金公司进行对账、统计等处理，这类文件只需要基金公司下载下来就可以了。

有些业务文件可能需要基金公司从第三方交易平台下载下来后，进行解析以存入数据库即可，例如，基金投顾业务有向客户收取投顾服务费的要求，在投顾服务费由第三方交易平台计算的情况下，基金公司需要从第三方平台下载投顾服务费相关文件，并将其解析后存储到数据库种，以方便查看。

有些业务文件(比如，开户文件、申购文件、赎回文件等)则需要基金公司从第三方交易平台下载下来后，进行解析并执行下单逻辑，即对开户文件执行开户逻辑，对申购文件执行申购逻辑，对赎回文件执行赎回逻辑等。

有些业务文件需要基金公司单方面生成并上报给第三方交易平台。例如，基金投顾业务涉及一些组合信息数据，比如投顾业务中有哪些成分基金，这些信息是由基金公司配置的，需要基金公司生成相应文件并同步给第三方平台。这类业务文件就需要基金公司单方面生成并上报给第三方发平台。

但不管不同业务文件需要的处理方式是否相同，每个文件所需要的处理均是上述五种业务文件处理方式中的至少一种，因此，同一组件可以对不同类型的业务文件进行对应的处理。比如，下载组件可以从第三方交易平台下载各类文件，可以包括但不限于：销售适当性文件、客户持仓情况文件、投顾服务费相关文件、开户文件、申购文件等。

基于上述分析，本申请的任一业务文件所需的至少一个执行组件包括如下几种执行组件中的至少一个：下载组件、解析组件、下单组件、上报组件和生成组件。

可选的，上述任一业务文件所需的至少一个执行组件包括下载组件。

或者，

上述任一业务文件所需的至少一个执行组件包括下载组件和解析组件。

或者，

上述任一业务文件所需的至少一个执行组件包括下载组件、解析组件和下单组件。

或者，

上述任一业务文件所需的至少一个执行组件包括下载组件、解析组件、下单组件和上报组件。

或者，

上述任一业务文件所需的至少一个执行组件包括生成组件和上报组件。

如前所述，本申请针对每个业务文件均维护一组状态，比如，对于仅需要下载的业务文件，其状态可以包括：下载文件发送消息成功、下载文件发送消息失败、文件下载中、文件下载成功、文件下载失败等。对于下单类业务文件，其状态可以包括：下载文件发送消息成功、下载文件发送消息失败、文件下载中、文件下载成功、文件下载失败、解析文件发送消息成功、解析文件发送消息失败、文件解析中、文件解析成功、文件解析失败、交易成功、交易失败等。

每个业务文件在同一时刻只能处于其中一个状态，状态之间会存在跳转。如图2所示，为本申请实施例提供的下单类业务文件的状态图的一种示例图。下面结合下单类业务文件的处理流程以及图2说明下单类业务文件的处理流程。

任务调度组件基于下单类业务文件的处理流程监测到满足第一下单类业务文件(第一下单类业务文件可以为任一下单类业务文件)的下载条件时，向消息中间件发送第一下单类业务文件对应的下载指示消息，为便于叙述，将第一下单类业务文件对应的下载指示消息记为第一下载指示消息，第一下载指示消息可以存储在消息中间件中与下载组件对应的队列中。其中，满足第一下单类业务文件的下载条件可以包括：时间到达第一下单类业务文件的下载时间，即周期性下载第一下单类业务文件；或者，接收到第一下单类业务文件的下载指令，该下载指令可以由用户在客户端进行预设操作而触发生成。

任务调度组件可以在向消息中间件发送第一下载指示消息后，在数据库中增加第一下单类业务文件的对应记录，该记录中至少包含第一下单类业务文件的状态，其中，如果成功将第一下载指示消息发送给中间件，则第一下单类业务文件的状态为下载指示消息发送成功；如果，未成功将第一下载指示消息发送给中间件，则第一下单类业务文件的状态为下载指示消息发送失败。

下载组件在对应的队列中读取到第一下载指示消息后，针对第一下单类业务文件向第三方交易平台发送下载请求消息。如果针对第一下单类业务文件的下载请求消息发送成功，则下载组件将数据库中第一下单类业务文件的状态更新为下载请求消息发送成功(标记为11)，否则，下载组件将数据库中第一下单类业务文件的状态更新为下载请求消息发送失败(标记为12)。

在第一下单类业务文件的状态进入状态11后，下载组件开始下载第一下单类业务文件，同时下载组件将数据库中第一下单类业务文件的状态更新为文件下载中(标记为20)。

针对第一下单类业务文件的下载请求消息发送失败后，下载组件重新向第三方交易平台发送针对第一下单类业务文件的下载请求消息。如果针对第一下单类业务文件下载请求消息发送成功，则下载组件将数据库中第一下单类业务文件的状态由状态12更新为状态11，否则，下载组件不更新数据库中下单类业务文件的状态，即第一下单类业务文件状态保持状态12。

在第一下单类业务文件的状态进入状态20后，如果成功下载第一下单类业务文件，则下载组件将数据库中第一下单类业务文件的状态由状态20更新为文件下载成功(标记为21)，如果下载第一下单类业务文件失败，则下载组件将数据库中第一下单类业务文件的状态由状态20更新为文件下载失败(标记为22)。

在第一下单类业务文件的状态进入状态22后，下载组件重新向第三方交易平台发送针对单一下单类业务文件的下载请求消息。如果针对第一下单类业务文件的下载请求消息发送成功，则下载组件将数据库中第一下单类业务文件的状态由状态22更新为状态11，否则，下载组件将数据库中第一下单类业务文件的状态由状态22更新为状态12。

在第一下单类业务文件的状态进入状态21后，任务调度组件基于下单类业务文件的处理流程确定需要对第一下单类业务文件执行解析逻辑时，将第一下单类业务文件的状态21发送至消息中间件。具体的，任务调度组件可以以消息的方式将第一下单类业务文件的状态21写入消息中间件中与解析组件对应的队列中。

解析组件从对应的队列中读取到第一下单类业务文件的状态21时，对第一下单类业务文件进行解析，并将数据库中第一下单类业务文件的状态由21更新为文件解析中(标记为30)。如果解析成功，则将解析结果存储到数据库中，并将数据库中第一下单类业务文件的状态由30更新为文件解析成功(标记为31)，如果解析失败，将数据库中第一下单类业务文件的状态由30更新为文件解析失败(标记为32)。

在第一下单类业务文件的状态进入状态32后，解析组件重新对第一下单类业务文件进行解析，并将数据库中第一下单类业务文件的状态由32更新为文件解析中(标记为30)。如果解析成功，则将解析结果存储到数据库中，并将数据库中第一下单类业务文件的状态由30更新为文件解析成功(标记为31)，如果解析失败，将数据库中第一下单类业务文件的状态由30更新为文件解析失败(标记为32)。

在第一下单类业务文件的状态进入状态31后，任务调度组件基于下单类业务文件的处理流程确定需要对第一下单类业务文件执行下单逻辑时，将第一下单类业务文件的状态31发送至消息中间件。具体的，任务调度组件可以以消息的方式将第一下单类业务文件的状态31写入消息中间件中与下单组件对应的队列中。

下单组件从下单组件对应的队列中读取到第一下单类业务文件的状态31时，对数据库中的解析得到的第一下单类业务文件执行下单逻辑，在执行完下单逻辑后将第一下单类业务文件的状态由状态31更新为交易完成(标记为40)。交易完成包括执行成功或执行失败。

可选的，上述任一业务文件的多个状态中存在至少一个状态与上述任一执行组件对应。比如，在处理第一下单类业务文件所需的下载组件、解析组件和下单组件中，下载组件对应第一下单类业务文件的状态11和状态22，解析组件对应第一下单类业务文件的状态21和状态32，下单组件对应第一下单类业务文件的状态31。

在一可选的实施例中，如果上述任一执行组件对上述任一业务文件执行第一状态对应的处理任务，得到处理结果表征处理失败，则上述任一执行组件自动重新对上述任一业务文件执行第一状态对应的处理任务。

在一可选的实施例中，如果在预设时长内上述任一执行组件一直未更新上述任一业务文件的状态，触发报警系统报警。

如果在预设时长内上述任一业务文件的状态一直未更新，说明对上述任一执行组件可能出现问题了。此时，任务调度组件可以出发报警系统报警。可选的，任务调度组件向报警系统发送的触发信息中可以携带上述任一业务文件的标识，以便报警系统在报警时可以输出上述任一业务文件的标识，使得报警系统在报警时用户可以知道是针哪个业务文件的报警信息，方便故障定位。

之后，用户可以通过客户端访问数据库，从而在数据库中找到上述任一业务文件，进而手动对上述任一业务文件执行第一状态对应的处理任务，并更新上述任一业务文件的状态，具体更新原则参照上述任一业务文件对应的状态图。

通过人工介入，保证业务文件能够成功处理完成。

每个下单类业务文件中通常会包含多条下单记录，各条下单记录需要分别执行下单逻辑，即每条下单记录的处理与其它下单记录没有关系。而在实际应用场景中，可能存在第三方交易平台向基金公司提供的业务文件中存在遗漏记录的情况，这种情况下，第三方交易平台可能会重新向基金公司提供补全的业务文件，如果下单组件对第三方交易平台重新提供的下单类业务文件中的各条下单记录逐一执行下单逻辑，就会出现大量重复处理的情况，因为遗漏的下单记录通常是少数。基于此，为了避免不必要的重复处理，下单组件对下单类业务文件执行下单逻辑时，可以用于：

对于下单类业务文件中的任一条下单记录，判断上述任一条下单记录是否已经执行过下单逻辑。

可选的，下单组件在对下单类业务文件执行下单逻辑的过程中，每处理完一条下单记录，对该条下单记录进行标记(成功或失败)，以标识该条下单记录已处理完成。这样，当第三方交易平台重新向基金公司提供与之前提供的下单类业务文件同一标识的下单类业务文件时，在解析组件对该同一标识的下单类业务文件进行解析后，下单组件在对该同一标识的下单类业务文件执行下单逻辑时，对于该同一标识的下单类业务文件每条下单记录，可以先判断该条下单记录是否已经执行过下单逻辑。具体的，可以将具有同一标识的两个下单类文件进行比对，以识别出已执行过下单逻辑的下单记录和未执行过下单逻辑的下单记录，进而后续仅对未执行过下单逻辑的下单记录进行处理即可。

如果判断结果为是，禁止对上述任一条下单记录进行处理，如果判断结果为否，对上述任一条下单记录执行下单逻辑。

与方法实施例相对应，本申请实施例还提供一种基于组件的文件处理系统，本申请实施例提供的基于组件的文件处理系统的一种结构示意图如图3所示，可以包括：

任务调度服务器301，消息中间件服务器302和至少一个执行服务器303；每个执行服务器303中设置有至少一执行组件，不同的执行服务器中设置不同的执行组件。图3所示示例中，设置有多个执行服务器303，分为两个服务器组，分为下单服务器组和下载、解析、生成、报送服务器组；其中，

任务调度服务器301用于监测各业务文件的状态；所述任务调度服务器将所述各业务文件的状态发送至所述消息中间件服务器302。

任务调度服务器301中可以设置任务调度组件，任务调度服务器301通过任务调度组件监测各业务文件的状态，并将各业务文件的状态发送至所述消息中间件服务器。

处理任一业务文件所需的至少一个执行组件中的任一执行组件所在的执行服务器303用于如果从所述消息中间件服务器302中获得所述任一业务文件的第一状态，通过所述任一执行组件对所述任一业务文件执行第一状态对应的处理任务，得到处理结果；根据所述处理结果更新所述任一业务文件的状态；所述任一业务文件的状态为目标状态时，确定所述任一业务文件处理完成。

消息中间件服务器302中设置有消息中间件，消息中间件维护业务文件状态的方式可以参看前述方法实施例，这里不再赘述。

所述第一状态为所述任一业务文件的多个状态中与所述任一执行组件对应的状态，所述第一状态为所述任一业务文件的非目标状态；不同的执行组件的执行不同的处理任务；对不同的业务文件进行处理所需的执行组件相同或不同。

本申请实施例提供的基于组件的文件处理系统，通过设置任务调度组件、消息中间件和多个执行组件，基于业务文件的状态实现了业务文件的自动处理，从而提高业务文件的处理效率。

在一可选的实施例中，所述任一业务文件所需的至少一个执行组件包括如下几种执行组件中的至少一个：

下载组件、解析组件、下单组件、上报组件和生成组件；其中，下载组件、解析组件、上报组件和生成组件设置于下载、解析、生成、报送服务器组中，而下单组件设置在下单服务器组中。

所述下载组件用于从第三方交易平台下载所述业务文件；下载组件所在的服务器组(即下载、解析、生成、报送服务器组)可以通过文件代理服务器和防火墙从第三方交易平台的SFTP服务器下载业务文件。下载文件所在的服务器组可以直接与文件代理服务器交互，也可以通过共享盘与文件代理服务器交互。下载组件所在的服务器组将下载下来的业务文件存储到数据库中。

所述解析组件用于对所述下载组件下载的业务文件进行解析；解析组件所在的服务器组(即下载、解析、生成、报送服务器组)从数据库中读取待解析的业务文件进行解析，并将解析后的业务文件存储到数据库中。

所述下单组件用于在所述业务文件为下单类业务文件的情况下，基于所述下单类业务文件执行下单逻辑；下单组件所在的服务器组(即下单服务器组)从数据库中读取待执行下单逻辑的业务文件并执行下单逻辑

所述上报组件用于向所述第三方交易平台上传需要上报的文件；

所述生成组件用于生成需要向所述第三方交易平台上报的文件。

在一可选的实施例中，其中，

所述任一业务文件所需的至少一个执行组件包括所述下载组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件和所述解析组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件、所述解析组件和所述下单组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件、所述解析组件、所述下单组件和所述上报组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述生成组件和所述上报组件。

在一可选的实施例中，所述任一业务文件的多个状态中存在至少一个状态与所述任一执行组件对应。

在一可选的实施例中，所述任一执行组件所在的执行服务器303还用于：

如果所述处理结果表征处理失败，重新对所述任一业务文件执行处理任务。

在一可选的实施例中，所述任务调度服务器301还用于：

如果在预设时长内所述任一执行组件一直未对所述任一业务文件的状态进行更新，触发报警系统报警。

此外，任务调度服务器301向报警系统发送的触发信息中可以携带上述任一业务文件的标识，以便报警系统在报警时可以输出上述任一业务文件的标识，使得报警系统在报警时用户可以知道是针哪个业务文件的报警信息，方便故障定位。除此之外，任务调度服务器301还可以向客户端后台服务器发送上述任一业务文件的标识，从而在用户在客户端进行操作，通过客户端后台服务器访问数据库时，由客户端后台服务器根据上述任一业务文件的标识在数据库中找到上述任一业务文件，进而手动对上述任一业务文件执行第一状态对应的处理任务，并更新上述任一业务文件的状态，具体更新原则参照上述任一业务文件对应的状态图。

当然，客户端后台服务器中的上述任一业务文件的标识也可以不是任务调度服务器301发送给客户端后台服务器的，也可以是由用户在客户端输入的。具体实现方式本申请不做具体限定。

在一可选的实施例中，所述下单组件所在的执行服务器303对所述下单类业务文件执行下单逻辑时，用于：

对于所述下单类业务文件中的任一条下单记录，判断所述任一条下单记录是否已经执行过下单逻辑；

如果判断结果为是，禁止对所述任一条下单记录进行处理，如果判断结果为否，对所述任一条下单记录执行下单逻辑。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

应当理解，本申请实施例中，从权、各个实施例、特征可以互相组合结合，都能实现解决前述技术问题。

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

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种基于组件的文件处理方法，其特征在于，包括：

任务调度组件监测各业务文件的状态；

所述任务调度组件将所述各业务文件的状态发送至消息中间件；

处理任一业务文件所需的至少一个执行组件中的任一执行组件如果从所述消息中间件中获得所述任一业务文件的第一状态，对所述任一业务文件执行第一状态对应的处理任务，得到处理结果；所述第一状态为所述任一业务文件的多个状态中与所述任一执行组件对应的状态，所述第一状态为所述任一业务文件的非目标状态；不同的执行组件执行不同的处理任务；

所述任一执行组件根据所述处理结果更新所述任一业务文件的状态；所述任一业务文件的状态为目标状态时，确定所述任一业务文件处理完成；

对不同的业务文件进行处理所需的执行组件相同或不同。

2.根据权利要求1所述的方法，其特征在于，所述任一业务文件所需的至少一个执行组件包括如下几种执行组件中的至少一个：

下载组件、解析组件、下单组件、上报组件和生成组件；其中，

所述下载组件用于从第三方交易平台下载业务文件；

所述解析组件用于对所述下载组件下载的业务文件进行解析；

所述下单组件用于在所述业务文件为下单类业务文件的情况下，基于所述下单类业务文件执行下单逻辑；

所述上报组件用于向所述第三方交易平台上传需要上报的文件；

所述生成组件用于生成需要向所述第三方交易平台上报的文件。

3.根据权利要求2所述的方法，其特征在于，

所述任一业务文件所需的至少一个执行组件包括所述下载组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件和所述解析组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件、所述解析组件和所述下单组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件、所述解析组件、所述下单组件和所述上报组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述生成组件和所述上报组件。

4.根据权利要求1所述的方法，其特征在于，所述任一业务文件的多个状态中存在至少一个状态与所述任一执行组件对应。

5.根据权利要求1所述的方法，其特征在于，所述任一执行组件还用于：

如果所述处理结果表征处理失败，重新对所述任一业务文件执行处理任务。

6.根据权利要求5所述的方法，其特征在于，所述任务调度组件还用于：

如果在预设时长内所述任一执行组件一直未对所述任一业务文件的状态进行更新，触发报警系统报警。

7.根据权利要求2所述的方法，其特征在于，所述下单组件对所述下单类业务文件执行下单逻辑时，用于：

对于所述下单类业务文件中的任一条下单记录，判断所述任一条下单记录是否已经执行过下单逻辑；

如果判断结果为是，禁止对所述任一条下单记录进行处理，如果判断结果为否，对所述任一条下单记录执行下单逻辑。

8.一种基于组件的文件处理系统，其特征在于，包括：任务调度服务器、消息中间件服务器和至少一执行服务器；每个执行服务器中设置有至少一执行组件，不同的执行服务器中设置不同的执行组件；其中，

所述任务调度服务器用于监测各业务文件的状态；所述任务调度服务器将所述各业务文件的状态发送至所述消息中间件服务器；

处理任一业务文件所需的至少一个执行组件中的任一执行组件所在的执行服务器如果从所述消息中间件服务器中获得所述任一业务文件的第一状态，通过所述任一执行组件对所述任一业务文件执行第一状态对应的处理任务，得到处理结果；根据所述处理结果更新所述任一业务文件的状态；所述任一业务文件的状态为目标状态时，确定所述任一业务文件处理完成；

所述第一状态为所述任一业务文件的多个状态中与所述任一执行组件对应的状态，所述第一状态为所述任一业务文件的非目标状态；不同的执行组件的执行不同的处理任务；对不同的业务文件进行处理所需的执行组件相同或不同。

9.根据权利要求8所述的系统，其特征在于，所述任一业务文件所需的至少一个执行组件包括如下几种执行组件中的至少一个：

下载组件、解析组件、下单组件、上报组件和生成组件；其中，

所述下载组件用于从第三方交易平台下载所述业务文件；

所述解析组件用于对所述下载组件下载的业务文件进行解析；

所述下单组件用于在所述业务文件为下单类业务文件的情况下，基于所述下单类业务文件执行下单逻辑；

所述上报组件用于向所述第三方交易平台上传需要上报的文件；

所述生成组件用于生成需要向所述第三方交易平台上报的文件。

10.根据权利要求9所述的系统，其特征在于，

所述任一业务文件所需的至少一个执行组件包括所述下载组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件和所述解析组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件、所述解析组件和所述下单组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述下载组件、所述解析组件、所述下单组件和所述上报组件；或者，

所述任一业务文件所需的至少一个执行组件包括所述生成组件和所述上报组件。

Images