CN111858693A - 一种基于征信上报反馈信息解析可视化方法 - Google Patents

Abstract

本发明涉及信息技术领域，提供了一种基于征信上报反馈信息解析可视化方法。目的在于解决当前征信报文报错后，通过人行反馈报文无法直观地统计错误类型，查看具体错误的问题。主要方案包括，步骤1、获取人行反馈报文ENG文件，并保存到到系统指定路径；步骤2、通过人行的解析jar包将原始反馈报文ENG文件解密解压成txt文件；步骤3、将解密解压后的txt文件，按照人行反馈报文解析规范将txt报文按对应的长度和位置将信息提取出来，根据人行反馈报文规范解析成结构化数据，数据项包括但不限于数据名称，错误类型，错误描述等，然后存入oracle库中；步骤4、前端页面将库中的数据，按照业务人员的需求展现为直观的表格数据。

Description

一种基于征信上报反馈信息解析可视化方法

技术领域

本发明涉及信息技术领域，提供了一种基于征信上报反馈信息解析可视化方法。

背景技术

在商业银行，目前征信上报反馈报文展现运用较多的为xml定义解析规则和StringBuffer字符串处理方案，用StringBuffer和File工具类解析截取人行反馈报文，然后通过xml文件中定义的规则分析解析结果，将结果存入数据库中，然后通过前端页面作为展现窗口。

如下为一个标准的反馈报文的数据解析可视化运行机制：

如图1，首先导入人行报文到系统指定路径feedback下，通过系统融合通过人行的解析jar包将原始报文解密解压成txt文件，然后将解密解压后的txt文件，根据人行反馈报文规范，按照xml文件中的规则解析成结构化数据，存入库中，最后前端页面将库中的数据，按照业务人员的需求展现为直观的表格数据。

当txt报文按照xml规则文件的要求，解析数据时，会按照人行规范按长度截取txt报文中的记录，然后存入Oracle数据库中。

以上流程基本为征信上报反馈报文的数据解析处理流程，下面我讲解一下xml规则解析机制。

Xml规则解析方法如下：

xml中的规则来源与人行征信报送的接口规范。主要分为以下错误类型定义：

报文名定义：定义了报文名的命名规则；

报文头定义：定义了报文头的组成规则；

报文体定义：定义了报文体的组成规则。

具体规则参考人民银行征信上报接口规范文档。

2、当人行原始反馈报文解密解压为txt报文后，程序调用反馈报文代码类中的FeedbackSession.messageConfig方法，加载ecr_message_feedback.xml规则文件，将xml文件中所有的规则逐条检查，检查完成后开始解析为结构化数据。

在征信行业中，由于业务快速发展，系统版本的快速迭代上线，数据加工的口径也可能随时都会变化。此时只需要对应修改xml规则报文即可。

发明内容

本发明的目的在于解决当前的反馈报文错误由于人行规则繁杂，通过程序解析原始报文和实现可视化表格来解决查找定位问题不方便的痛点，急需一种可视化的解决方案。

本发明为解决上述技术问题，采用以下技术方案：

一种基于征信上报反馈信息解析可视化方法，包括以下步骤：

步骤1、获取人行反馈报文ENG文件，并保存到到系统指定路径；

步骤2、通过人行的解析jar包将原始反馈报文ENG文件解密解压成txt文件；

步骤3、将解密解压后的txt文件，根据人行反馈报文规范解析成结构化数据，存入库中；

步骤4、前端页面将库中的数据，按照业务人员的需求展现为直观的表格数据。

上述技术方案中，上述步骤1具体包括以下步骤：

步骤1.1：在系统中将人行反馈报文进行上传操作；

步骤1.2：将反馈人行报文文件jar包存储在征信上报应用服务器feedback文件夹下；

上述技术方案中，上述步骤2中：

步骤2.1：在BussinessFeedback类中融合人行解析工具的jar包；

Jar包中将MsgDeZiplmpl、MsgDezip、MsgdezipFactory三个接口整合到征信上报系统中；

BussinessFeedback类：作用是反馈接口的主调用类，是处理人行原始反馈文件的工具类，所有的处理逻辑，任务调度都通过BussinessFeedback来处理，是解析反馈报文的入口；

MsgDeZiplmpl接口：作用是实现解密解压的功能，能将人行的ENC文件(ENC文件是原始的人行反馈加密报文，文件后缀名为ENC)解密为txt文件；

MsgDezip接口：作用是抽象解密解压接口，让MsgDeZiplmpl可以被其他方法调用；

MsgdezipFactory接口：作用解密解压工厂类，作用是创造MsgDezip的实例，能使代码调用该接口。

步骤2.2：将服务器上的反馈报文ENC后缀名文件，通过MsgDeZiplmpl解密解压为同名的txt后缀名文件。

上述技术方案中，步骤3具体包括以下步骤：

步骤3.1：通过日终单元执行FeedbackUnit反馈报文处理单元；

FeedbackUnit是一个反馈报文日终批处理单元，每天会定时执行，当检测到反馈报文后，会调用BussinessFeedback类来处理反馈报文；

步骤3.2：程序通过读取解密解压后的txt文件，按照人行反馈报文解析规范将报txt报文按对应的长度和位置将信息提取出来，得到解析数据，解析数据包括数据项名称、类型、数据项描述及代码表信息；

步骤3.3：建立解析oracle数据库表，将得到解析数据存入对应的表中。

上述技术方案中，步骤4具体包括以下步骤：

步骤4.1：根据存在oracle数据库中的解析数据，生成可视化表格，展现业务人员想看到的内容；

步骤4.2：将表格数据展现在前端征信上报系统-反馈错误管理模块中。

因为本发明采用上述技术方案，因此具备以下有益效果：

(1)解决了业务人行需手工解读报文的繁琐方式。

(2)可以将反馈解析错误进行结构化解析到数据库，通过可视化表格展现给业务人员，业务人员无需学习关注解析方法，只需查看处理解析后的错误数据。

(3)对解析报文进行存储，可以追溯历史解析信息。

(4)可视化的表格展现的是oracle数据库中存储的解析后的反馈报文数据，可以根据业务人员需求对表格内容进行定制。

(5)数据统一存储，提高了征信数据的安全性及合规性。

附图说明

图1为本发明流程简图；

图2为反馈报文的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明，即所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，术语“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本发明提供了一种基于征信上报反馈信息解析可视化方法，包括以下步骤：

步骤1、获取人行反馈报文ENG文件，并保存到到系统指定路径；

步骤2、通过人行的解析jar包将原始反馈ENG报文解密解压成txt文件；

步骤3、将解密解压后的txt文件，根据人行反馈报文规范解析成结构化数据，存入库中；

步骤4、前端页面将库中的数据，按照业务人员的需求展现为直观的表格数据。

上述步骤1具体包括以下步骤：

步骤1.1：在系统中将人行反馈报文进行上传操作；

步骤1.2：将反馈人行报文文件jar包存储在征信上报应用服务器feedback文件夹下；

上述步骤2中：

步骤2.1：在BussinessFeedback类中融合人行解析工具的jar包；

Jar包中将MsgDeZiplmpl、MsgDezip、MsgdezipFactory三个接口整合到征信上报系统中；

BussinessFeedback类：作用是反馈接口的主调用类，是处理人行原始反馈文件的工具类，所有的处理逻辑，任务调度都通过BussinessFeedback来处理，是解析反馈报文的入口；

MsgDeZiplmpl接口：作用是实现解密解压的功能，能将人行的ENC文件(ENC文件是原始的人行反馈加密报文，文件后缀名为ENC)解密为txt文件；

MsgDezip接口：作用是抽象解密解压接口，让MsgDeZiplmpl可以被其他方法调用；

MsgdezipFactory接口：作用解密解压工厂类，作用是创造MsgDezip的实例，能使代码调用该接口。

步骤2.2：将服务器上的反馈报文ENC后缀名文件，通过MsgDeZiplmpl解密解压为同名的txt后缀名文件。

步骤3具体包括以下步骤：

步骤3.1：通过日终单元执行FeedbackUnit反馈报文处理单元；

FeedbackUnit是一个反馈报文日终批处理单元，每天会定时执行，当检测到反馈报文后，会调用BussinessFeedback类来处理反馈报文；

步骤3.2：程序通过读取解密解压后的txt文件，按照人行反馈报文解析规范将报txt报文按字段长度进行截取；解析方法如下举例：

反馈报文的结构由报文头和报文体两部分组成。每个报文必须包含且只包含一个报文头，报文头和报文体之间用一个空行区分，即报文头后加入两个回车换行符(“\r\n”)分隔。报文体中各个账户记录之间加入一个回车换行符(“\r\n”)分隔，如图2：

人行接口规范的描述如下表格，按照人行的接口规范里的数据项名称对应的长度和位置，可以通过程序将txt报文按对应的长度和位置将信息提取出来，将所有记录的信息提取后，我们可以得到数据项名称、类型、数据项描述及代码表等信息，这样就完成了数据解析步骤。

步骤3.3：建立解析oracle数据库表，将截取的数据依次存入对应的表中。

上述技术方案中，步骤4具体包括以下步骤：

步骤4.1：根据第三步解析完成后的数据存在oracle数据库中，业务人行可以提出可视化需求，只要是存在解析数据，我们就可以按照业务人员的需求做个性化的可视化表格，展现业务人员想看到的内容；

步骤4.2：将表格数据展现在前端征信上报系统-反馈错误管理模块中。例如业务人员A想看下表这些数据项：

期次号→

业务号→

发生日期→

金融机构代码→

姓名→

征件类型→

征件号码→

错误代码→

错误信息→

业务人员B只想看下表这些数据项：

期次号→

货款业务号→

错误字段→

错误信息代码→

错误信息→

错误表→

管户机构→

Claims (5)

1.一种基于征信上报反馈信息解析可视化方法，其特征在于，包括以下步骤：

步骤1、获取人行反馈报文ENG文件，并保存到到系统指定路径；

步骤2、通过人行的解析jar包将原始反馈报文ENG文件解密解压成txt文件；

步骤3、将解密解压后的txt文件，按照人行反馈报文解析规范将txt报文按对应的长度和位置将信息提取出来，根据人行反馈报文规范解析成结构化数据，数据项包括但不限于数据名称，错误类型，错误描述等，然后存入oracle库中；

步骤4、前端页面将库中的数据，按照业务人员的需求展现为直观的表格数据。

2.根据权利要求1所述的一种基于征信上报反馈信息解析可视化方法，其特征在于：上述步骤1具体包括以下步骤：

步骤1.1：在系统中将人行反馈报文进行上传操作；

步骤1.2：将反馈人行报文ENG文件存储在征信上报应用服务器feedback文件夹下。

3.根据权利要求1所述的一种基于征信上报反馈信息解析可视化方法，其特征在于：上述步骤2中：

步骤2.1：在BussinessFeedback类中融合人行解析工具的jar包；

Jar包中将MsgDeZiplmpl、MsgDezip、MsgdezipFactory三个接口整合到征信上报系统中；

BussinessFeedback类：作用是反馈接口的主调用类，是处理人行原始反馈文件的工具类，所有的处理逻辑，任务调度都通过BussinessFeedback来处理，是解析反馈报文的入口；

MsgDeZiplmpl接口：作用是实现解密解压的功能，jar包能将人行的ENC文件(ENC文件是原始的人行反馈加密报文，文件后缀名为ENC)解密解压为txt文件；

MsgDezip接口：作用是抽象解密解压接口，让MsgDeZiplmpl可以被其他方法调用；

MsgdezipFactory接口：作用解密解压工厂类，作用是创造MsgDezip的实例，能使代码调用该接口。

步骤2.2：将服务器上的反馈报文ENC后缀名文件，通过MsgDeZiplmpl解密解压为同名的txt后缀名文件。

4.根据权利要求1所述的一种基于征信上报反馈信息解析可视化方法，其特征在于：步骤3具体包括以下步骤：

步骤3.1：通过日终单元执行FeedbackUnit反馈报文处理单元；FeedbackUnit是一个反馈报文日终批处理单元，每天会定时执行，当检测到反馈报文后，会调用BussinessFeedback类来处理反馈报文；

步骤3.2：程序通过读取解密解压后的txt文件，按照人行反馈报文解析规范将报txt报文按对应的长度和位置将信息提取出来，得到解析数据，解析数据包括数据项名称、类型、数据项描述及代码表信息；

步骤3.3：建立解析oracle数据库表，将得到解析数据存入对应的表中。

5.根据权利要求1所述的一种基于征信上报反馈信息解析可视化方法，其特征在于：步骤4具体包括以下步骤：

步骤4.1：根据存在oracle数据库中的解析数据，生成可视化表格，展现业务人员想看到的内容；

步骤4.2：将表格数据展现在前端征信上报系统-反馈错误管理模块中。

Images