CN101145150A - 一种批量文件处理方法及*** - Google Patents

Abstract

本发明公开了一种批量文件处理方法，及其应用一种银行风险信息批量文件查询方法及***，涉及数据处理领域，用来解决银行机构发来的大批量查询请求文件不能快速有效处理的问题。所述方法包括：定时搜索是否有查询请求文件；多进程并行获取所述查询请求文件；对应每个查询请求文件，一次性检索各类风险信息表，查看是否有与查询请求文件匹配的不良信息；生成包含所述不良信息的查询结果文件。所述***包括：数据库，文件共享空间，定时轮询模块，多个数据检索模块，以及文件收发子***。本发明不但实现了自动化要求，而且还具有快速、稳定、安全、支持大量机构并发处理等特点，起到了规范入网机构***发卡的征信流程、较好地避免发卡风险的作用。

Description

一种批量文件处理方法及***

技术领域

本发明涉及数据处理领域，特别是涉及一种批量文件处理方法，及其应用——一种银行风险信息批量文件查询方法及***。

背景技术

在银行业务领域，当用户办理银行***时，银行机构(以下简称机构)启动征信***，根据用户的信用度进行发卡。因此，首先要通过查询风险信息共享平台存储的风险信息共享文件，对***申请人的申请资料进行信用度审核。其中，所述风险信息指标识不良申请人相关记录的信息；所述风险信息共享平台是提供给各个入网机构使用的一个公共平台，其存储的所有数据供机构共享。当在上述风险信息中查询到所述申请人的信息时，该申请人即为不良持卡人。因此，机构获取风险信息的目的主要在于避免将***发给非法人员，使得非法人员使用***进行欺诈。

传统的风险信息共享文件的查询方式是：当机构办事人员人工通过Internet网络上载查询请求文件时，***采用单进程方式对风险信息共享文件进行查询，即每次只响应一个查询请求；所述风险信息共享文件以数据表的形式存储，分为11类风险信息表，查询时采用单表查询方式，逐个对每个表进行查询。查询结束后，向机构返回查询结果。

上述查询方式，能够对各个机构发来的文件进行查询，实现机构对***申请人的信用评估。但是，当大批量的查询请求文件需要处理时，由于风险信息共享平台采用单进程及单表的方式，逐个对每个请求进行11类表的查询，就会影响批量文件的处理速度，由于请求处理时间延长而造成查询结果不能及时反馈给机构的问题，从而影响机构端的处理效率。

而且，这种处理模式需要机构端人工通过Internet网络登录风险信息共享平台，手工上载查询请求文件，待***处理完成后，再手工下载查询结果文件，全部流程都需要人工干预，而无法做到整个流程的完全自动化。机构端如果等待查询结果，可能影响机构的发卡效率；如果不等待查询结果，可能增加机构的发卡风险。并且，通过Internet公网传递这些文件，易受网络攻击，存在极大的不安全性。

发明内容

本发明所要解决的技术问题是提供一种批量文件处理方法，以解决大批量待处理文件不能快速有效处理的问题。

本发明的另一个目的是将上述技术构思应用于银行业务处理中，提供一种银行风险信息批量文件查询方法及***，用于快速处理银行机构发来的大批量查询请求文件。

为解决上述技术问题，本发明提供了一种批量文件处理方法，用于对接收的批量文件进行处理，包括：

搜索步骤，定时搜索是否有待处理文件；

文件获取步骤，多进程并行获取所述待处理文件；

检索步骤，对应每个待处理文件，一次性检索多个匹配信息表，查看是否有与待处理文件匹配的信息；

文件生成步骤，生成处理结果文件。

其中，在所述检索步骤中执行以下一次性检索：所述多个匹配信息表采用类似的数据结构，执行一条联合了各个匹配信息表的查询语句。

其中，在所述搜索步骤中执行以下搜索：将接收的待处理文件相关信息记录在文件信息表中；定时搜索所述文件信息表。

优选的，还包括：实时更新所述文件信息表中的文件处理状态。

其中，所述处理结果文件包括：记录处理结果的结果反馈文件，以及记录所述匹配信息的报告文件。

本发明还提供了一种银行风险信息批量文件查询方法，用于处理至少一个银行机构发来的查询请求文件，包括：

定时搜索是否有查询请求文件；

多进程并行获取所述查询请求文件；

对应每个查询请求文件，一次性检索各类风险信息表，查看是否有与查询请求文件匹配的不良信息；

生成查询结果文件。

优选的，还包括：预定义报文接口；对应报文，发送方主动请求接收方接收数据文件；对应报文，发送方向接收方发送所述数据文件。

优选的，还包括：预定义报文接口；对应报文，接收方发送查询请求，发送方返回查询结果；对应报文，接收方主动请求发送方发送数据文件；对应报文，发送方向接收方发送所述数据文件。

其中，银行机构既可以作为发送方，也可以作为接收方；所述数据文件包括查询请求文件和查询结果文件。

优选的，在所述发送方向接收方发送所述数据文件的步骤中还包括：验证所述数据文件的传输一致性。

本发明还提供了一种银行风险信息批量文件查询***，用于处理至少一个银行机构***发来的查询请求文件，其特征在于，包括：

数据库，用于存储记录查询请求文件相关信息的查询文件信息表，以及各类风险信息表；

文件共享空间，用于存放接收的查询请求文件及查询结果文件；

定时轮询模块，用于定时搜索所述数据库中的查询文件信息表，轮询到查询请求文件，则触发数据检索模块；

多个数据检索模块，用于并行从所述文件共享空间获取所述查询请求文件；对应每个查询请求文件，一次性检索所述数据库中的各类风险信息表，查看是否有与查询请求文件匹配的不良信息；生成查询结果文件，并存放于文件共享空间。

优选的，还包括：文件收发子***，用于与银行机构***自动传输所述查询请求文件及查询结果文件，并将查询请求文件的相关信息记入所述数据库中的查询文件信息表。

其中，所述定时轮询模块和数据检索模块部署在中间件上。

与现有技术相比，本发明具有以下优点：

首先，通过部署多个数据检索模块，实现多进程的并发执行，可以同时响应多个文件查询请求，极大地提高了风险信息共享平台的处理能力。而且，定时轮询模块和数据检索模块采用异步调用方式，当数据检索模块遇到比较大的查询请求文件需要比较长的处理时间时，由于多个数据检索模块可以同时处理多个查询请求文件，所以不会阻塞定时轮询模块的运行。

其次，由于各类风险信息表的设计采用了类似的数据结构，因此在处理一条文件查询请求，需要检索各类风险信息表时，采用一条联合了各类风险信息表的查询语句，进行一次查询即可完成检索目的，避免进行多次单表查询。由于定时轮询模块和数据检索模块部署在中间件上，而各类风险信息表存放在数据库中，这种多表同时检索的方式减少了中间件与数据库服务器间的网络调用，从而提高查询效率。

再次，本发明采用流传输方式，通过预定义报文接口，实现银行机构与风险信息共享平台间批量文件的自动收发。机构可以自动向风险信息共享平台上传查询请求文件，风险信息共享平台自动处理完查询请求后，还可以自动将查询结果文件发送给机构，便于机构能够在获得该查询结果后自动启动其征信***用于发卡评估。同时，流传输方式中加入了对文件一致性的验证，很好地保证了文件在传输过程中不被篡改。而且，这种自动收发功能是在专网上传递，绕开了Internet公网，因此能够保证数据传递过程中的安全性。

附图说明

图1是本发明所述一种银行风险信息批量文件查询方法的步骤流程图；

图2.1是本发明流传输方式中的文件查询流程图；

图2.2是本发明流传输方式中的文件发送流程图；

图2.3是本发明流传输方式中的文件索取流程图；

图3.1是本发明采用流传输方式的实施例一的文件处理流程图；

图3.2是本发明采用流传输方式的实施例二的文件处理流程图；

图4是本发明所述一种银行风险信息批量文件查询***的结构图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

本发明的应用环境是：当用户在各个银行机构申请***时，银行的征信***需要获取申请人的信用评估，才能决定是否可以向申请人发卡，以免将***错发给非法人员，造成欺诈行为。而在提供文件共享的风险信息共享平台中存有不良持卡人或单位的相关记录，称为风险信息，银行机构通过查询所述风险信息判断申请人是否为存有记录的不良持卡人或单位。因此，所述风险信息共享平台需要处理各个机构发送来的大批量风险信息查询请求文件，所述文件记录***申请人的相关信息。针对上述银行业务需求，本发明提供了一种快速处理大批量文件的方法，以下内容将以上述银行业务应用为例进行说明。

本发明的核心思想是：采用多进程方式并行处理机构发来的多个查询请求文件，并且通过一条查询语句即可同时检索各类风险信息表，实现***的快速、自动化处理。

参照图1，是本发明所述一种银行风险信息批量文件查询方法的步骤流程图。

步骤101，定时搜索是否有查询请求文件。所述查询请求文件记录了待查询人员(单位)的身份信息，如主要包括待查询人员的证件类型和证件号码，由各机构向风险信息共享平台发送。共享平台存储有查询文件信息表，记录了查询请求文件名称、上传时间、机构、文件路径、处理状态、反馈文件名称、路径、风险报告文件名称、路径，当收到查询请求文件时存储在本地，并将文件相关信息记录在查询文件信息表中。按照预定时间间隔，定时搜索所述查询文件信息表，若发现有新的文件记录，则需要处理接收的文件查询请求。除上述本发明所述的搜索方法外，还可以通过其他公知的现有技术实现本步骤中的定时搜索功能。

步骤102，多进程并行获取查询请求文件。当搜索到多个新的查询请求文件时，采用多进程处理方式，同时从本地获取存储的查询请求文件，加快了***处理速度。

步骤103，对应每个查询请求文件，一次性检索各类风险信息表，查看是否有与查询请求文件匹配的不良信息。所述不良信息即为记录在风险信息表中的内容，在本实施例中，所述风险信息表分为11类，分别为不良持卡人信息、不良持卡单位信息、欺诈嫌疑申领人信息、信用额度信息、其他社会信用信息、可疑商户信息、风险商户信息、可疑营销人员信息、可疑营销代理机构信息、不良委外催收人员信息、不良委外催收机构信息。对于每个文件查询请求，都需要在所述11类风险信息表中进行检索，如果匹配到了待查询人员的身份信息，说明该人员是一个不良持卡人。

本发明中，在实现多进程处理的基础上，为了进一步提高***处理能力，对风险信息表的检索也做了改进。在设计所述11类风险信息表时，采用类似的数据结构，如定义相同或相近的数据字段等方法，使得针对一条文件查询请求需要在11类风险信息表中查询时，采用一条联合了11类风险信息表的查询语句，进行一次查询即可直接完成检索目的，避免进行多次单表查询，极大地加快了处理速度。当然，也可以通过其他公知的技术方法提高多个表的检索效率。

步骤104，生成包含所述不良信息的查询结果文件。当检索到待查询人员(单位)的不良信息后，生成一个查询结果反馈文件，说明哪些人员(单位)是不良持卡人，同时还要针对每个被查询到的不良持卡人分别生成风险报告，风险报告需要在全部11类风险信息中查找所述不良持卡人的不良行为，并将所有查询到的不良行为存放在风险报告中返回给机构，机构可以通过风险报告查看所述不良持卡人的欺诈恶劣程度，以决定给所述不良持卡人的处理。

所述查询结果文件包括查询结果反馈文件和风险报告文件。其中，所述查询结果反馈文件对应所述查询请求文件，记录了待查询人员(单位)的身份信息，如证件类型和证件号码，同时根据查询到是否为不良持卡人的情况在每个人员的身份信息后给出是否命中标志，Y表示命中，即是不良持卡人；N表示未命中，即是合法持卡人。所述风险报告文件记录了不良持卡人的所有不良行为。

优选的，在上述批量文件处理流程中，对应所述查询文件信息表中的处理状态、反馈文件名称、路径、风险报告文件名称、路径字段，将查询请求文件的处理状态及处理完成后生成的查询结果反馈文件、风险报告文件的相关信息记录在查询文件信息表中，便于整个处理流程的管理。其中，所述的处理状态分为未处理、正在处理、成功处理、失败处理，在整个批量文件处理流程中，当查询请求文件的处理状态发生转换时，需要及时更新所述查询文件信息表中的处理状态记录，方便机构随时了解查询请求文件的处理进度。

风险信息共享平台通过多进程处理并配合一次性检索功能，能够快速、有效地处理多个机构发来的批量文件，及时向机构反馈查询结果，因而与风险信息共享平台有密切关系的机构征信***，也相应提高了对申请人发卡评估的处理效率。

为配合上述风险信息共享平台对批量文件的快速处理，优选的，本发明改进了现有技术通过人工方式手动上送和下载文件的方法，实现了机构与风险信息共享平台之间的业务处理自动化，机构自动上送查询请求文件，经过风险信息共享平台按照上述方法高效自动处理后，将查询结果文件自动发送到机构。

本发明采用流传输方式实现批量文件的自动收发。流传输方式将文件内容看做可在网络上进行不间断传输的一串串数据流，故可提供断点续传、文件压缩等功能，能够保证文件传输过程中的高效性和正确性。流传输方式采用预定义报文接口方式，提供了文件的主动查询、主动发送、主动接收、被动发送、被动接收等功能：当机构需要向共享平台发送查询请求文件时，可以采用主动发送功能，将文件发往共享平台；当机构需要从共享平台上获取查询结果文件时，可以采用主动查询功能，首先查询所述文件是否生成，若查询到，再通过主动接收功能下载查询结果文件；同时，也可以等待共享平台在生成查询结果文件后，通过被动接收功能自动向机构下发。由此可见，流传输方式可以根据机构的不同情况，采用不同的处理方式达到机构要求。

报文类型	信息流向	说明	报文种类
				请求文件传输类报文
8000	发送方→接收方	文件发送请求	发送方请求接收方接收文件
				8010	接收方→发送方	对8000文件发送请求的应答	接收方接收文件准备完毕
8100	接收方→发送方	文件索取请求	接收方请求发送方发送文件
				8110	发送方→接收方	对8100文件索取请求的应答	发送方可以发送文件
文件传输通知类报文
				8200	发送方→接收方	文件发送通知(可能有多个)	发送方将数据文件发送给接收方
8300	发送方→接收方	文件发送成功结束的通知	发送方文件发送结束

报文类型	信息流向	说明	报文种类
				8310	接收方→发送方	对8300文件发送结束通知的应答	接收方文件接收结束
文件查询类报文
				8400	接收方→发送方	查询文件请求	接收方向发送方发出的查询文件请求
8410	发送方→接收方	对8400查询文件请求的应答(可能有多个)	发送方回复查询结果发送结果文件

表1是本发明流传输方式采用的预定义报文接口列表

参照表1，是本发明流传输方式采用的预定义报文接口列表，文件以报文形式传输，针对不同功能采用不同的报文接口，文件传输双方通过预定义报文接口达到识别所传输报文的目的。如表1所示，报文共分为三类：请求文件传输类报文，包括文件发送请求报文(8000报文)、文件发送请求应答报文(8010报文)、文件索取请求报文(8100报文)、文件索取请求应答报文(8110报文)；文件传输通知类报文，包括数据传送报文(8200报文)、文件发送结束通知报文(8300报文)、文件发送结束通知应答报文(8310报文)；文件查询类报文，包括文件查询请求报文(8400报文)和文件查询请求应答报文(8410报文)。其中，请求文件传输类报文用于文件传输请求，文件传输通知类报文用于数据文件的传输，文件查询类报文用于发起文件查询请求。上述三类报文在报文发起后，对方都会按照网络协议的规范进行相应的报文应答。图中所述的发送方和接收方并不特指，即机构和共享平台都可以既作为文件的发送方，也可以作为接收方，根据不同的功能设置而定，没有一个固定的概念，下面内容再详述。

根据上述报文类型，文件在发送方和接收方之间的传输分为三种类型：文件查询、文件发送、文件索取，下面将依次进行说明。参照图2.1，是本发明流传输方式中的文件查询流程图，实现了文件的主动查询功能。

步骤211，发送查询请求(8400报文)，将查询请求文件名发送到共享平台，请求查询文件的处理进度；

步骤212，返回应答(8410报文)，共享平台应答机构的查询请求，将查询结果文件名发送给机构，告知机构文件的处理状态。根据处理状态，返回的8410报文可能有多条，如文件已成功处理完毕，就会返回查询结果反馈文件名和风险报告文件名，其中的查询结果反馈文件记录了文件的处理状态。

在文件查询流程中，8400和8410报文传输的是文件名，并没有传输具体的数据文件，因为数据文件由表1所述的文件传输通知类报文传输，由文件发送流程和文件索取流程实现。参照图2.2，是本发明流传输方式中的文件发送流程图。

步骤221，发送方将文件发送请求报文(8000报文)传送至接收方。

步骤222，接收方向发送方返回应答报文(8010报文)。

步骤223，发送方将文件内容放入数据传送报文(8200报文)中发送至接收方。根据数据文件的数据量，可发送多条8200报文。

步骤224，数据传送结束后，发送方向接收方发送文件结束通知报文(8300报文)。

步骤225，接收方验证文件后发送结束应答报文(8310报文)给发送方。

由于文件收发方所处的角度不同，所述流程首先由文件发送方发起，那么对于文件发送方是主动发送过程，对于文件接收方是被动接收过程，所以上述流程实际包含主动发送和被动接收两个功能。

参照图2.3，是本发明流传输方式中的文件索取流程图；

步骤231，接收方将索取文件的请求报文(8100报文)传至发送方，报文中包含了索取文件名。

步骤232，发送方按所述索取文件名查找到对应文件后，向接收方发送应答报文(8110报文)。

步骤233，发送方将文件内容放入数据传送报文(8200报文)中发给接收方。如上所述，根据数据文件的数据量，可发送多条8200报文。

步骤234，数据传送结束后，发送方向接收方发送文件结束通知报文(8300报文)。

步骤235，接收方验证文件后发送结束应答报文(8310报文)给发送方。

由于文件收发方所处的角度不同，而该流程首先由文件接收方发起，那么对于文件接收方是主动接收过程，对于文件发送方是被动发送过程，所以上述流程实际包含主动接收和被动发送两个功能。

优选的，在8310报文中加入了对文件一致性的验证，很好地保证了文件在传输过程中不被篡改。所述验证方法是：在待传输的文件末尾会有一个计算MAC的密钥和一个MAC值。文件接收方收到这两个信息后，会根据预定义规则用计算MAC的密钥重新计算一遍MAC值，并将这个计算出的MAC值和收到的MAC值进行比较，比较结果一致说明文件内容的传输是安全的，没有被篡改；若不一致说明文件内容被篡改了，不能再使用。其中，可以运用现有技术的多种公知方法实现所述预定义规则。在流传输方式的传输结束通知报文(8310报文)中会通过应答码反映文件是否通过了MAC校验，当应答码为00时表示文件传输成功；当应答码为DD时表示文件MAC校验错。

由上所述，本发明实际定义了两种方法供机构选择：一种是如果机构不想过分依赖共享平台，而不被动等待平台生成好查询结果文件后发送给机构，可以每隔一段时间就来主动查询一下，待查到后马上获取查询结果文件；另一种方式是机构不发送查询请求，只是被动等待平台自动下发查询结果文件。下面通过具体的例子将流传输方式与批量文件的处理结合起来，说明上述流传输方式的运用。参照图3.1，是本发明采用流传输方式的实施例一的文件处理流程图。

步骤311，机构向共享平台发送查询请求文件。此时，机构作为文件发送方，共享平台作为文件接收方，采用图2.2所示的文件发送流程，按照预定义报文接口方式，实现机构的主动发送和共享平台的被动接收功能。

机构何时向共享平台发送查询请求文件，将根据机构自己的设计原则来定。机构可以设置自动触发程序，待查询请求文件生成后，自动触发向共享平台发送的命令；也可以定时轮询发送，按照预定义时间间隔，到固定的文件夹轮询是否有新的查询请求文件，若是则自动将文件发送。

步骤312，共享平台处理所述查询请求文件。共享平台按照图1.1所述的方法对机构发来的查询请求文件进行处理，检索11类风险信息表，生成查询结果文件和风险报告文件。

步骤313，机构主动索取查询结果文件。机构首先按照图2.1所示的文件查询流程，定时查询文件是否处理完，若处理完，再按照图2.3所示的文件索取流程，自动向共享平台索取查询结果文件。此时，机构作为文件接收方，共享平台作为文件发送方，实现了机构的主动查询、主动接收(文件索取)和共享平台的被动发送功能。

图3.2是本发明采用流传输方式的实施例二的文件处理流程图。

步骤321，机构向共享平台发送查询请求文件。

步骤322，共享平台处理所述查询请求文件。

上述两个步骤的描述如上所述，不同之处在于：

步骤323，共享平台发送查询结果文件。此时，机构作为图2.2所示的文件接收方，共享平台作为文件发送方，采用文件发送流程，机构被动等待共享平台处理完后将查询结果文件自动下发给机构，从而实现机构的被动接收和共享平台的主动发送功能。

本发明采用的预定义报文接口方式，便于机构能够在获得该查询结果后自动启动其征信***用于发卡评估，提高了共享平台和机构端的处理效率。而且，这种自动收发功能是在专网上传递，绕开了Internet公网，避免网络攻击，因此能够保证数据传递过程中的安全性。除上述预定义报文接口方式外，还可以针对不同应用需求，设计不同的报文接口，实现流传输功能。

参照图4，本发明还提供了一种银行风险信息批量文件查询***的结构图，用于处理至少一个银行机构***409发来的查询请求文件。如图所示，包括文件共享空间401、数据库402和风险文件处理组件403，其中所述风险文件处理组件403包括定时轮询模块404和数据检索模块405。

文件共享空间401，用于存放接收的查询请求文件及查询结果文件。所述查询请求文件由机构***409发送，记录了待查询人员(单位)的身份信息，如主要包括待查询的人员的证件类型和证件号码；所述查询结果文件包括查询结果反馈文件和风险报告文件。其中，所述查询结果反馈文件对应所述查询请求文件，记录了待查询人员(单位)的身份信息，如证件类型和证件号码，同时根据查询到是否为不良持卡人的情况在每个人员的身份信息后给出是否命中标志，Y表示命中，即是不良持卡人；N表示未命中，即是合法持卡人；所述风险报告文件记录了不良持卡人的所有不良行为。

数据库402，用于存储记录查询请求文件相关信息的查询文件信息表，以及各类风险信息表。其中，所述查询文件信息表记录了查询请求文件名称、上传时间、机构、文件路径、处理状态、反馈文件名称、路径、风险报告文件名称、路径；所述风险信息表分为11类，分别为不良持卡人信息、不良持卡单位信息、欺诈嫌疑申领人信息、信用额度信息、其他社会信用信息、可疑商户信息、风险商户信息、可疑营销人员信息、可疑营销代理机构信息、不良委外催收人员信息、不良委外催收机构信息。

定时轮询模块404，用于在预先设定的时间间隔上，定时搜索所述数据库402中的查询文件信息表，若发现表中有未处理记录，即轮询到查询请求文件，则发送消息触发所述数据检索模块405。

数据检索模块405，受到定时轮询模块404的触发后，用于从所述文件共享空间401获取所述查询请求文件；对应每个查询请求文件，一次性检索所述数据库402中的各类风险信息表，查看是否有与查询请求文件匹配的不良信息，所述不良信息即为记录在风险信息表中的内容；生成包含所述不良信息的查询结果文件，并存放于文件共享空间401。

对于每个文件查询请求，都需要在所述11类风险信息表中进行检索，当检索到待查询人员(单位)的不良信息后，说明该人员(单位)是一个不良持卡人，数据检索模块405生成一个查询结果反馈文件，说明哪些人员(单位)是不良持卡人，同时还要针对每个被查询到的不良持卡人分别生成风险报告，并将所有查询到的不良行为存放在风险报告中返回给机构，机构可以通过风险报告查看所述不良持卡人的欺诈恶劣程度，以决定给所述不良持卡人的处理。

在银行业务应用中，还采用了Java2企业版(J2EE，Java 2 EnterPriseEdition)中间件技术实现查询请求的快速、自动化处理。所述中间件即为企业应用提供通用的基础服务，提供了诸如事务、安全、负载均衡等基础功能，每个应用模块可以直接使用这些基础功能，而不需要各自区编码实现，企业应用部署、运行在中间件上。如图所示，J2EE容器406即为所述J2EE中间件，除部署容器的基础服务407外，还将风险文件处理组件403部署在J2EE中间件上。由于容器的基础服务407提供了诸如事务、安全、负载均衡等基础功能，因此文件处理组件403可以专注于查询请求文件的解析、数据检索、风险报告、查询结果反馈文件的生成。所述定时轮询模块404即利用J2EE容器406的时间服务功能来实现定时轮询，加快了模块的轮询速度。

本发明中，在J2EE容器406中部署了多个数据检索模块405，可以并发运行，大大提高了***的处理能力。而且，所述定时轮询模块404与数据检索模块405采用异步调用方式，当数据检索模块遇到比较大的查询请求文件需要比较长的处理时间时，也不会阻塞自动轮询模块的运行。

上述数据检索模块405的一次性检索是指，在设计11类风险信息表时采用了类似的数据结构，当针对一条查询请求需要在11类风险信息表中查询时，采用一条联合了这11类风险信息表的查询语句，进行一次结构化查询语言(SQL，Structured Query Language)的查询即可完成检索目的，避免进行多次SQL查询，减少了J2EE容器与数据库服务器间的网络调用，从而提高查询效率。

数据检索模块405还会随时更新数据库402中查询文件信息表的处理状态，如未处理、正在处理、成功处理、失败处理，便于机构随时了解查询请求文件的处理进度。

上述批量文件处理***通过在J2EE中间件上部署多个数据检索模块，并提供一次性检索功能，提高了***的处理能力，从而提高了机构***的处理效率。

在机构***409与上述批量文件处理***之间传输文件时，优选的，本发明改进了现有技术通过人工方式手动上送和下载文件的方法，提供了文件收发子***408，实现批量文件的自动收发。如图所示，所述文件收发子***408采用上面内容所述的流传输方式，与机构***409自动进行文件传输，将接收的查询请求文件放入文件共享空间401，将文件信息记入数据库402中的查询文件信息表，并将文件共享空间401中的查询结果文件自动传输给机构***409。

如前所述，流传输方式采用预定义报文方式，提供了文件的主动查询、主动发送、主动接收、被动发送、被动接收等功能，可以根据机构***的不同情况，采用不同的处理方式达到机构***要求。所述机构***与批量文件处理***间的自动传输方式，便于机构***能够在获得该查询结果后自动启动其征信***用于发卡评估，提高了批量文件处理***和机构***的处理效率。而且，这种自动收发功能是在专网上传递，绕开了Internet公网，避免网络攻击，因此能够保证数据传递过程中的安全性。

下面将结合图4所示的***结构图，列举一优选实施例全面说明风险信息批量文件的处理流程。

步骤1，机构***通过流传输方式，将风险信息查询请求文件自动上送到文件收发子***；

步骤2，文件收发子***将接收到的文件信息记入数据库的查询文件信息表中，同时将机构***上送的查询请求文件写入文件共享空间；

步骤3，批量文件处理***的定时轮询模块利用J2EE容器的时间服务组件，定期搜索数据库中的查询文件信息表；

步骤4，当时间服务轮询到需要处理的文件信息后，通知数据检索模块启动，为加快数据检索效率，该模块可有多个一起进行并行处理；

步骤5，接收到定时轮询模块的调用通知后，数据检索模块首先到文件共享空间获取查询请求文件；

步骤6，根据查询请求文件中的内容到数据库中去检索11类风险信息表，并记录待查询信息是否在数据库中有匹配信息；

步骤7，数据检索模块处理完查询请求文件中的所有记录后，将更新查询文件信息表中对应文件的状态记录，便于用户了解查询请求文件是否已被成功处理；

步骤8，数据检索模块根据检索结果，生成查询结果反馈文件和风险报告文件，并将它们存放在文件共享空间；

步骤9，文件收发子***发现文件共享空间出现新文件后，从文件共享空间获取该文件；

步骤10，文件收发子***通过流传输方式，自动将查询结果反馈文件和风险报告文件发送给机构***。

综上所述，本发明所述的批量文件处理方法及***，不但实现了自动化要求，而且还具有快速、稳定、安全、支持大量机构并发处理等特点，起到了规范入网机构***发卡的征信流程、较好地避免发卡风险的作用。

以上对本发明所提供的一种银行批量文件处理方法及***，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本发明的限制。

Claims (13)

1.一种批量文件处理方法，用于对接收的批量文件进行处理，其特征在于，包括：

搜索步骤，定时搜索是否有待处理文件；

文件获取步骤，多进程并行获取所述待处理文件；

检索步骤，对应每个待处理文件，一次性检索多个匹配信息表，查看是否有与待处理文件匹配的信息；

文件生成步骤，生成处理结果文件。

2.根据权利要求1所述的方法，其特征在于，在所述检索步骤中执行以下一次性检索：所述多个匹配信息表采用类似的数据结构，执行一条联合了各个匹配信息表的查询语句。

3.根据权利要求1所述的方法，其特征在于，在所述搜索步骤中执行以下搜索：

将接收的待处理文件相关信息记录在文件信息表中；

定时搜索所述文件信息表。

4.根据权利要求3所述的方法，其特征在于，还包括：实时更新所述文件信息表中的文件处理状态。

5.根据权利要求1所述的方法，其特征在于，所述处理结果文件包括：记录处理结果的结果反馈文件，以及记录所述匹配信息的报告文件。

6.一种银行风险信息批量文件查询方法，用于处理至少一个银行机构发来的查询请求文件，其特征在于，包括：

定时搜索是否有查询请求文件；

多进程并行获取所述查询请求文件；

对应每个查询请求文件，一次性检索各类风险信息表，查看是否有与查询请求文件匹配的不良信息；

生成查询结果文件。

7.根据权利要求6所述的方法，其特征在于，还包括：

预定义报文接口；

对应报文，发送方主动请求接收方接收数据文件；

对应报文，发送方向接收方发送所述数据文件。

8.根据权利要求6所述的方法，其特征在于，还包括：

预定义报文接口；

对应报文，接收方发送查询请求，发送方返回查询结果；

对应报文，接收方主动请求发送方发送数据文件；

对应报文，发送方向接收方发送所述数据文件。

9.根据权利要求7或8所述的方法，其特征在于：银行机构既可以作为发送方，也可以作为接收方；所述数据文件包括查询请求文件和查询结果文件。

10.根据权利要求7或8所述的方法，其特征在于，在所述发送方向接收方发送所述数据文件的步骤中还包括：验证所述数据文件的传输一致性。

11.一种银行风险信息批量文件查询***，用于处理至少一个银行机构***发来的查询请求文件，其特征在于，包括：

数据库，用于存储记录查询请求文件相关信息的查询文件信息表，以及各类风险信息表；

文件共享空间，用于存放接收的查询请求文件及查询结果文件；

定时轮询模块，用于定时搜索所述数据库中的查询文件信息表，轮询到查询请求文件，则触发数据检索模块；

多个数据检索模块，用于并行从所述文件共享空间获取所述查询请求文件；对应每个查询请求文件，一次性检索所述数据库中的各类风险信息表，查看是否有与查询请求文件匹配的不良信息；生成查询结果文件，并存放于文件共享空间。

12.根据权利要求11所述的***，其特征在于，还包括：文件收发子***，用于与银行机构***自动传输所述查询请求文件及查询结果文件，并将查询请求文件的相关信息记入所述数据库中的查询文件信息表。

13.根据权利要求11所述的***，其特征在于：所述定时轮询模块和数据检索模块部署在中间件上。

Images