1.本发明涉及智慧工程用多银行管理系统领域，特别涉及一种用于智慧工程的多银行流水获取方法。
背景技术：
：：2.智慧工程将更多的监控技术植入各行各业，并被普遍互联，形成物联网，再与互联网整合，实现项目管控，在银行管理方面也是如此，目前银行客户的账单对账流程是，业务经理把客户打款凭证上传到系统中，财务拿着凭证和银行账户中的打款信息进行对比确认，这个本来是财务确认收款的流程，但是业务经理和客户都要参与进来，对于客户的体验和业务经理的效率都有影响，因此，如何提升银行业务的运转效率就变成了急需解决的问题。技术实现要素：3.为此，需要提供一种效率高、安全性好的用于智慧工程的多银行流水获取方法。4.为实现上述目的，发明人提供了一种用于智慧工程的多银行流水获取方法，包括，中间件系统、业务系统、银行系统和代理系统，中间件系统，用于业务系统和银行系统之间的数据传输；代理系统，用于内外网数据传输；还包括中间件系统拉取数据步骤：业务系统发起请求，统一入参后，到达中间件系统；中间件系统创建异步多线程，并同时处理若干个银行系统获取动作；每个银行系统分别设有适配器，适配器对银行系统的参数进行组装，转换成银行系统需要的参数格式、参数值和参数内容，通过适配器拼接好参数数据后，发送给策略执行器进行逻辑处理，处理后通过若干种方式发送请求到银行系统；银行系统返回数据后，在策略执行器中进行逻辑处理，然后回传给适配器，进行反向参数解析，参数解析后返回给对应的线程，线程等待所有的银行系统数据获取完毕之后一次性将数据返回给业务系统，业务系统对获取的数据进行处理。5.作为本发明的一种优选方式，还包括新增银行系统，新增银行系统包括步骤：增加适配器，适配器适配对应银行系统的参数结构和参数格式；根据银行系统的接口设置策略执行器，设置的策略执行器用于处理对应银行系统的业务逻辑。6.作为本发明的一种优选方式，银行系统包括前置机，所述前置机设于内网环境中，内网环境通过前置机与银行系统连接，在前置机上增加代理系统，通过代理系统对外暴露接口进行数据传输，对暴露的接口增加ip白名单进行请求限制和在nginx中进行限流。7.作为本发明的一种优选方式，在中间件系统发送请求时，中间件系统将发送请求的参数信息存储到数据库中，并根据银行系统的返回值，对请求进行标志成功或失败；若银行系统返回失败，则触发重试机制，重新发送请求，当第二次重试请求失败之后触发第三次重试请求，直到重试次数达到最大可重试次数时，放弃重试，该请求进入到失败列表中，业务系统提供失败请求列表，用于手动触发重试操作，进行人为干预；中间件系统的日志表包括关联明细表，当中间件系统向若干个银行系统发送请求时，根据请求任务内容拆分到对应的关联明细表，若银行系统返回信息错误，则由关联明细表针对错误的信息独立发起重试。8.作为本发明的一种优选方式，若中间件系统未能成功发送请求，则在重新发送请求时，从中间件系统的日志表中查找最近一次的参数数据，将最近一次的参数数据的起始时间作为重新发送请求的起始时间。9.作为本发明的一种优选方式，所述中间件系统使用completablefuture接口创建异步多线程。10.作为本发明的一种优选方式，所述策略执行器进行逻辑处理包括rsa签名，aes加密。11.作为本发明的一种优选方式，还包括钉钉告警，当中间件系统调用银行系统接口出错或者本地服务器宕机时，则给钉钉推送告警信息，提醒开发及时处理异常情况，其中钉钉告警信息包含异常堆栈信息、请求参数、告警时间和银行系统名称信息。12.作为本发明的一种优选方式，所述中间件系统包括重试接口，所述重试接口用于传递不同的参数进行重试工作，重新获取银行系统信息。13.作为本发明的一种优选方式，还包括步骤：与银行系统约定密钥，使用aes对称加密方法，用于数据的加密解密。14.区别于现有技术，上述技术方案所达到的有益效果有：业务系统的请求保持统一，有效的提升了业务开发效率；方便了业务需求的扩展，可满足不同系统间数据拉取的需求；保证了数据的准确性和及时性。附图说明15.图1为具体实施方式所述数据对接交互流程图。16.图2为具体实施方式中不同系统的出入参统一处理流程图。17.图3为具体实施方式中新增银行系统流程图。18.图4为具体实施方式所述前置机工作流程图。具体实施方式19.为详细说明技术方案的技术内容、构造特征、所实现目的及效果，以下结合具体实施例并配合附图详予说明。20.如图1和图2所示，本实施例提供了一种用于智慧工程的多银行流水获取方法，包括，中间件系统、业务系统和代理系统，中间件系统，用于业务系统和其他系统之间的数据传输；代理系统，用于内外网数据传输；还包括中间件系统拉取数据步骤：业务系统发起请求，统一入参后，到达中间件系统；中间件系统创建异步多线程，并同时处理若干个银行系统获取动作；每个银行系统分别设有适配器，适配器对银行系统的参数进行组装，转换成银行系统需要的参数格式、参数值和参数内容，通过适配器拼接好参数数据后，发送给策略执行器进行逻辑处理，处理后通过若干种方式发送请求到银行系统；银行系统返回数据后，在策略执行器中进行逻辑处理，然后回传给适配器，进行反向参数解析，参数解析后返回给对应的线程，线程等待所有的银行系统数据获取完毕之后一次性将数据返回给业务系统，业务系统对获取的数据进行处理。21.在上述实施例的具体实施过程中，如图1为中间件系统拉取数据的整个过程，业务系统发送请求使用了统一的入参，比如时间范围、系统类型等信息，业务系统发送的请求到达中间件系统之后，为了提升系统之间的对接效率，本实施例启用了异步多线程进行系统对接，针对不同的银行，每个银行创建了一个独立的线程进行对接；当所有银行数据都返回的之后，组装整体数据返回给业务系统；异步多线程是指线程的执行是异步的，互相直接不会等待，在本实施例中，开启了多个线程，异步去处理数据，等待所有线程结束之后，将所有的线程数据合并统一返回给业务系统；具体的，中间件系统利用java8的completablefuture接口创建异步多线程，利用completablefuture对于任务的编排能力，通过allof方法，实现多个线程请求的等待，实现多任务请求数据组合后统一返回；同时处理多家银行系统获取动作。每个银行系统都有一个适配器，适配器对银行系统需要的参数进行组装，有的银行系统需要json，有的银行系统需要xml，转换成银行系统需要的参数格式，以及不同的参数值，如：对应的key值和默认参数内容，如：银行账号等默认信息，其中参数格式例如：{ꢀꢀꢀꢀꢀparent:xxꢀꢀꢀꢀꢀchildren:ꢀꢀ{ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀitem:xxxꢀꢀꢀꢀ}}通过适配器拼接好参数数据之后，发送给策略执行器进行逻辑的处理，如：rsa签名，aes加密等，通过不同的方式发送请求到银行系统，银行系统返回数据之后，在策略执行器中进行解密等逻辑处理，然后回传给适配器，进行反向参数解析，参数解析之后返回给对应的线程，线程等待所有的银行数据获取完毕之后一次性对数据进行返回，返回给业务系统，业务系统对获取的数据进行处理。在本实施例中，策略执行器是指一段采用了设计模式中的策略模式写的代码，不同银行通过不同策略执行逻辑。22.在上述实施例中，涉及到扩展性设计，其中涉及的术语定义如下：开闭原则：软件实体应该对扩展开放，对修改关闭。即一个软件实体应该通过扩展来实现变化，而不是通过修改现有的代码来实现变化。23.系统的可扩展性设计：一个具有可扩展性的架构设计是应当符合开闭原则的，即对扩展开放，对修改关闭为了实现系统的可扩展性，需要对系统中不变与变化的部分进行分析变化的部分：（1）不同的系统，其接口地址、调用方式、调用逻辑不同；（2）不同的系统，其请求参数、响应数据的数据结构不同；（3）以后可能会需要引入新的系统；不变：业务开发人员不会关心每个系统的请求参数、响应数据结构是什么。业务系统调用中间件系统时，无论其调用哪个系统接口，其请求参数、响应数据是固定的。24.因此，根据不同的系统拆分成不同的调用策略类，并通过适配器模式转化请求参数和响应数据。后期如果接入新的系统，只需要新增调用策略、新增适配器，老代码无需改动，遵循开闭原则。策略类：解决了不同系统，不同的调用逻辑和调用方法，每个系统使用各自的策略类执行各自的逻辑；适配器类：解决了参数的翻译问题，业务的入参翻译成系统可识别的入参，系统的出参翻译成业务可识别的出参。25.例如：业务系统发送请求输入参数为：系统type，时间段[starttime，endtime]；通过系统参数找到对应的银行系统的适配器，将数据进行重新的封装，比如银行系统中时间段对应的参数key值为：begindate，enddate，那么我们需要将starttime对应到begindate中，endtime对应到enddate中，并对银行系统中的默认参数进行处理，组装成银行识别的数据结构；封装好的数据传递给对应银行系统的策略类，进行数据的加密加签处理，并利用httpclient或者webservice等方式与银行系统进行通信。银行系统返回数据之后进行对应的逆向操作。不同系统的出入参统一处理流程如图2所示。[0026]在一些实施例中，还包括新增银行系统，新增银行系统包括步骤：增加适配器，适配器适配对应银行系统的参数结构和参数格式；根据银行系统的接口设置策略执行器，设置的策略执行器用于处理对应银行系统的业务逻辑。[0027]具体的：新增一个银行系统接入的步骤只有简单的两步，第一步是增加一个适配器，适配对应银行系统的参数结构和格式，如xml格式，第二步增加一个策略，处理对应银行系统的业务逻辑；优点为：对于其他银行的对接没有任何的影响，测试需要关注的就是当前银行系统的对接是否正确，业务系统代码不需要做任何更改。[0028]适配器是一种设计模式，不同的银行系统新建不同的适配器，适配器的主要功能就是翻译参数，业务参数都是通过key-value传递的，传递给银行系统的格式是不一样的，有的需要xml格式，有的需要key-value格式。还有就是组装参数，不同的银行参数key值是不同，需要传递的数据也是不同的。通过配置文件，配置不同的默认传递的参数，如：默认银行类型、账号信息等，在适配器中不止转换业务传递的数据，也会对默认参数进行封装。[0029]执行策略，也就是不同的银行的逻辑处理，比如银行系统一次性可获取的数据条数是有限制的，有的是固定值99条，有的根据银行返回的值判断是否还有数据需要获取。针对不同的银行系统处理方案不同。还有就是对参数和返回值进行加密和解密处理。还有根据业务传递的参数，对数据进行过滤处理等，如图3所示。[0030]在某些实施例中，如图4所示，为了进一步的提高本方法的安全性，涉及到安全性的设计，具体的，基于api接口方式的安全性设计：为了防止数据被破解，与银行进行约定密钥，使用aes对称加密算法，实现数据的加密解密，为了防止数据篡改，利用rsa签名算法对数据进行加签和验签。基于前置机方式的安全性设计：在对接银行系统遇到前置机的问题，银行系统提供的前置机必须在内网环境中，暴露出来的接口也是没有任何加密处理的，完全是明文的参数传递。面对这样的设计，本实施例设计了代理系统，通过代理系统打通内外网环境，同时保证数据的安全性；内网环境只对公网环境暴露指定接口；设置ip白名单，只有指定的ip可以访问到内网环境；内外网的数据传输参数使用了对称加密和签名算法；同时应对数据攻击，在ngnix中做了限流的处理；ip白名单就是一种授权方式，只有指定的ip可以访问服务器，其他的不可以，从而防止恶意的访问；前置机的整体方案如图4所示。[0031]在一些实施例中，为了解决本方法运行过程中的异常情况，在本实施例中，进行了容错性设计，具体的：不同的系统之间通信会产生各种问题，比如网络波动，服务器异常等，造成数据拉取失败的问题，总的来说会对以下两种异常进行处理，第一种情况：中间件系统发起请求成功，但是银行系统因为各种原因报错了，返回错误error信息；第二种情况：中间件系统未能成功发起请求。[0032]针对第一种情况：在中间件系统发起请求的时候，中间件系统会将发起请求的参数信息存储到数据库中，根据银行系统最终返回值的情况，对请求进行标志成功或者失败；若银行系统返回为失败，触发重试机制，重新发起请求，当第二次重试请求失败之后触发第三次重试请求，直到重试次数达到最大可重试次数时，放弃重试。该请求进入到失败列表中，银行系统提供了一个失败请求列表，可以手动触发重试操作，进行人为干预。[0033]由于中间件系统支持多个系统之间同时拉取数据，可能有的系统数据是成功的，有的系统数据是失败的，中间件系统的日志表设计的时候做了一个关联明细表，当对多个银行系统发起请求的时候，会根据请求任务内容拆分到关联明细表，若银行系统返回信息错误，则由关联明细表针对错误的信息独立发起重试。例如：发送的请求包含单任务请求和多任务请求，无论是单任务还是多任务请求都是通过一个请求实现的，这个请求是主请求；主请求进入到中间件系统的时候，中间件系统会对请求任务内容进行拆分，例如一个请求抓取多个银行的流水信息，中间件系统就会拆分成不同的请求发送到不同的银行系统中，主请求的状态由多个子请求的状态决定，比如子请求a是成功的，子请求b是失败的，那么主请求是失败的，在重试的时候，我们只会重试子请求b，不会重发请求a。[0034]针对第二种情况：针对定时任务类型的处理，定时任务就是在某个或者间隔的时间范围内发起的数据拉取请求。在下次发起请求的时候，会从请求日志表中查找参数为最近的那一条数据，如果最近的那一条数据时间和发起该请求的起始时间有差距的时候，使用最近的那一条数据起始时间作为重新发送请求的起始时间，例如：设置每半个小时拉取一次数据，10:00拉取数据，拉取的是9:30‑ꢀ10:00的数据，请求发起成功，记录到了日志表中，日志表中有一条10:00点的数据，日志表中记录的内容包含：起始时间：9:30，终止时间：10:00以及请求的参数信息；如果，10:30网络断掉了，没有发起拉取数据的请求，这个时候日志中没有10:30的记录；11:00的时候拉取的应该是10:30ꢀ‑11:00的数据，实际上应该拉取的是10:00-11:00的数据；因为利用的是增量数据处理，为了防止数据遗漏，所以这里做了一个日志对比，对于没有抓取到的数据进行了补充处理；这样保证在因为网络等原因没有发起请求的时候，二次请求补发上一次未执行的请求，保证数据能够完整。[0035]在不同的实施例中，除了进去容错性设计，还做了钉钉告警处理，能够在第一时间获取异常信息，具体的：当中间件调用银行系统接口出错或者本地服务器宕机的时候，及时给钉钉推送告警信息，提醒开发及时处理异常情况。钉钉告警信息包含了异常堆栈信息，请求参数，告警时间和系统名称等重要信息，有利于排查问题及异常重试。[0036]需要说明的是，尽管在本文中已经对上述各实施例进行了描述，但并非因此限制本发明的专利保护范围。因此，基于本发明的创新理念，对本文所述实施例进行的变更和修改，或利用本发明说明书及附图内容所作的等效结构或等效流程变换，直接或间接地将以上技术方案运用在其他相关的
技术领域：
：，均包括在本发明的专利保护范围之内。当前第1页12当前第1页12
背景技术：
：：2.智慧工程将更多的监控技术植入各行各业，并被普遍互联，形成物联网，再与互联网整合，实现项目管控，在银行管理方面也是如此，目前银行客户的账单对账流程是，业务经理把客户打款凭证上传到系统中，财务拿着凭证和银行账户中的打款信息进行对比确认，这个本来是财务确认收款的流程，但是业务经理和客户都要参与进来，对于客户的体验和业务经理的效率都有影响，因此，如何提升银行业务的运转效率就变成了急需解决的问题。技术实现要素：3.为此，需要提供一种效率高、安全性好的用于智慧工程的多银行流水获取方法。4.为实现上述目的，发明人提供了一种用于智慧工程的多银行流水获取方法，包括，中间件系统、业务系统、银行系统和代理系统，中间件系统，用于业务系统和银行系统之间的数据传输；代理系统，用于内外网数据传输；还包括中间件系统拉取数据步骤：业务系统发起请求，统一入参后，到达中间件系统；中间件系统创建异步多线程，并同时处理若干个银行系统获取动作；每个银行系统分别设有适配器，适配器对银行系统的参数进行组装，转换成银行系统需要的参数格式、参数值和参数内容，通过适配器拼接好参数数据后，发送给策略执行器进行逻辑处理，处理后通过若干种方式发送请求到银行系统；银行系统返回数据后，在策略执行器中进行逻辑处理，然后回传给适配器，进行反向参数解析，参数解析后返回给对应的线程，线程等待所有的银行系统数据获取完毕之后一次性将数据返回给业务系统，业务系统对获取的数据进行处理。5.作为本发明的一种优选方式，还包括新增银行系统，新增银行系统包括步骤：增加适配器，适配器适配对应银行系统的参数结构和参数格式；根据银行系统的接口设置策略执行器，设置的策略执行器用于处理对应银行系统的业务逻辑。6.作为本发明的一种优选方式，银行系统包括前置机，所述前置机设于内网环境中，内网环境通过前置机与银行系统连接，在前置机上增加代理系统，通过代理系统对外暴露接口进行数据传输，对暴露的接口增加ip白名单进行请求限制和在nginx中进行限流。7.作为本发明的一种优选方式，在中间件系统发送请求时，中间件系统将发送请求的参数信息存储到数据库中，并根据银行系统的返回值，对请求进行标志成功或失败；若银行系统返回失败，则触发重试机制，重新发送请求，当第二次重试请求失败之后触发第三次重试请求，直到重试次数达到最大可重试次数时，放弃重试，该请求进入到失败列表中，业务系统提供失败请求列表，用于手动触发重试操作，进行人为干预；中间件系统的日志表包括关联明细表，当中间件系统向若干个银行系统发送请求时，根据请求任务内容拆分到对应的关联明细表，若银行系统返回信息错误，则由关联明细表针对错误的信息独立发起重试。8.作为本发明的一种优选方式，若中间件系统未能成功发送请求，则在重新发送请求时，从中间件系统的日志表中查找最近一次的参数数据，将最近一次的参数数据的起始时间作为重新发送请求的起始时间。9.作为本发明的一种优选方式，所述中间件系统使用completablefuture接口创建异步多线程。10.作为本发明的一种优选方式，所述策略执行器进行逻辑处理包括rsa签名，aes加密。11.作为本发明的一种优选方式，还包括钉钉告警，当中间件系统调用银行系统接口出错或者本地服务器宕机时，则给钉钉推送告警信息，提醒开发及时处理异常情况，其中钉钉告警信息包含异常堆栈信息、请求参数、告警时间和银行系统名称信息。12.作为本发明的一种优选方式，所述中间件系统包括重试接口，所述重试接口用于传递不同的参数进行重试工作，重新获取银行系统信息。13.作为本发明的一种优选方式，还包括步骤：与银行系统约定密钥，使用aes对称加密方法，用于数据的加密解密。14.区别于现有技术，上述技术方案所达到的有益效果有：业务系统的请求保持统一，有效的提升了业务开发效率；方便了业务需求的扩展，可满足不同系统间数据拉取的需求；保证了数据的准确性和及时性。附图说明15.图1为具体实施方式所述数据对接交互流程图。16.图2为具体实施方式中不同系统的出入参统一处理流程图。17.图3为具体实施方式中新增银行系统流程图。18.图4为具体实施方式所述前置机工作流程图。具体实施方式19.为详细说明技术方案的技术内容、构造特征、所实现目的及效果，以下结合具体实施例并配合附图详予说明。20.如图1和图2所示，本实施例提供了一种用于智慧工程的多银行流水获取方法，包括，中间件系统、业务系统和代理系统，中间件系统，用于业务系统和其他系统之间的数据传输；代理系统，用于内外网数据传输；还包括中间件系统拉取数据步骤：业务系统发起请求，统一入参后，到达中间件系统；中间件系统创建异步多线程，并同时处理若干个银行系统获取动作；每个银行系统分别设有适配器，适配器对银行系统的参数进行组装，转换成银行系统需要的参数格式、参数值和参数内容，通过适配器拼接好参数数据后，发送给策略执行器进行逻辑处理，处理后通过若干种方式发送请求到银行系统；银行系统返回数据后，在策略执行器中进行逻辑处理，然后回传给适配器，进行反向参数解析，参数解析后返回给对应的线程，线程等待所有的银行系统数据获取完毕之后一次性将数据返回给业务系统，业务系统对获取的数据进行处理。21.在上述实施例的具体实施过程中，如图1为中间件系统拉取数据的整个过程，业务系统发送请求使用了统一的入参，比如时间范围、系统类型等信息，业务系统发送的请求到达中间件系统之后，为了提升系统之间的对接效率，本实施例启用了异步多线程进行系统对接，针对不同的银行，每个银行创建了一个独立的线程进行对接；当所有银行数据都返回的之后，组装整体数据返回给业务系统；异步多线程是指线程的执行是异步的，互相直接不会等待，在本实施例中，开启了多个线程，异步去处理数据，等待所有线程结束之后，将所有的线程数据合并统一返回给业务系统；具体的，中间件系统利用java8的completablefuture接口创建异步多线程，利用completablefuture对于任务的编排能力，通过allof方法，实现多个线程请求的等待，实现多任务请求数据组合后统一返回；同时处理多家银行系统获取动作。每个银行系统都有一个适配器，适配器对银行系统需要的参数进行组装，有的银行系统需要json，有的银行系统需要xml，转换成银行系统需要的参数格式，以及不同的参数值，如：对应的key值和默认参数内容，如：银行账号等默认信息，其中参数格式例如：{ꢀꢀꢀꢀꢀparent:xxꢀꢀꢀꢀꢀchildren:ꢀꢀ{ꢀꢀꢀꢀꢀꢀꢀꢀꢀꢀitem:xxxꢀꢀꢀꢀ}}通过适配器拼接好参数数据之后，发送给策略执行器进行逻辑的处理，如：rsa签名，aes加密等，通过不同的方式发送请求到银行系统，银行系统返回数据之后，在策略执行器中进行解密等逻辑处理，然后回传给适配器，进行反向参数解析，参数解析之后返回给对应的线程，线程等待所有的银行数据获取完毕之后一次性对数据进行返回，返回给业务系统，业务系统对获取的数据进行处理。在本实施例中，策略执行器是指一段采用了设计模式中的策略模式写的代码，不同银行通过不同策略执行逻辑。22.在上述实施例中，涉及到扩展性设计，其中涉及的术语定义如下：开闭原则：软件实体应该对扩展开放，对修改关闭。即一个软件实体应该通过扩展来实现变化，而不是通过修改现有的代码来实现变化。23.系统的可扩展性设计：一个具有可扩展性的架构设计是应当符合开闭原则的，即对扩展开放，对修改关闭为了实现系统的可扩展性，需要对系统中不变与变化的部分进行分析变化的部分：（1）不同的系统，其接口地址、调用方式、调用逻辑不同；（2）不同的系统，其请求参数、响应数据的数据结构不同；（3）以后可能会需要引入新的系统；不变：业务开发人员不会关心每个系统的请求参数、响应数据结构是什么。业务系统调用中间件系统时，无论其调用哪个系统接口，其请求参数、响应数据是固定的。24.因此，根据不同的系统拆分成不同的调用策略类，并通过适配器模式转化请求参数和响应数据。后期如果接入新的系统，只需要新增调用策略、新增适配器，老代码无需改动，遵循开闭原则。策略类：解决了不同系统，不同的调用逻辑和调用方法，每个系统使用各自的策略类执行各自的逻辑；适配器类：解决了参数的翻译问题，业务的入参翻译成系统可识别的入参，系统的出参翻译成业务可识别的出参。25.例如：业务系统发送请求输入参数为：系统type，时间段[starttime，endtime]；通过系统参数找到对应的银行系统的适配器，将数据进行重新的封装，比如银行系统中时间段对应的参数key值为：begindate，enddate，那么我们需要将starttime对应到begindate中，endtime对应到enddate中，并对银行系统中的默认参数进行处理，组装成银行识别的数据结构；封装好的数据传递给对应银行系统的策略类，进行数据的加密加签处理，并利用httpclient或者webservice等方式与银行系统进行通信。银行系统返回数据之后进行对应的逆向操作。不同系统的出入参统一处理流程如图2所示。[0026]在一些实施例中，还包括新增银行系统，新增银行系统包括步骤：增加适配器，适配器适配对应银行系统的参数结构和参数格式；根据银行系统的接口设置策略执行器，设置的策略执行器用于处理对应银行系统的业务逻辑。[0027]具体的：新增一个银行系统接入的步骤只有简单的两步，第一步是增加一个适配器，适配对应银行系统的参数结构和格式，如xml格式，第二步增加一个策略，处理对应银行系统的业务逻辑；优点为：对于其他银行的对接没有任何的影响，测试需要关注的就是当前银行系统的对接是否正确，业务系统代码不需要做任何更改。[0028]适配器是一种设计模式，不同的银行系统新建不同的适配器，适配器的主要功能就是翻译参数，业务参数都是通过key-value传递的，传递给银行系统的格式是不一样的，有的需要xml格式，有的需要key-value格式。还有就是组装参数，不同的银行参数key值是不同，需要传递的数据也是不同的。通过配置文件，配置不同的默认传递的参数，如：默认银行类型、账号信息等，在适配器中不止转换业务传递的数据，也会对默认参数进行封装。[0029]执行策略，也就是不同的银行的逻辑处理，比如银行系统一次性可获取的数据条数是有限制的，有的是固定值99条，有的根据银行返回的值判断是否还有数据需要获取。针对不同的银行系统处理方案不同。还有就是对参数和返回值进行加密和解密处理。还有根据业务传递的参数，对数据进行过滤处理等，如图3所示。[0030]在某些实施例中，如图4所示，为了进一步的提高本方法的安全性，涉及到安全性的设计，具体的，基于api接口方式的安全性设计：为了防止数据被破解，与银行进行约定密钥，使用aes对称加密算法，实现数据的加密解密，为了防止数据篡改，利用rsa签名算法对数据进行加签和验签。基于前置机方式的安全性设计：在对接银行系统遇到前置机的问题，银行系统提供的前置机必须在内网环境中，暴露出来的接口也是没有任何加密处理的，完全是明文的参数传递。面对这样的设计，本实施例设计了代理系统，通过代理系统打通内外网环境，同时保证数据的安全性；内网环境只对公网环境暴露指定接口；设置ip白名单，只有指定的ip可以访问到内网环境；内外网的数据传输参数使用了对称加密和签名算法；同时应对数据攻击，在ngnix中做了限流的处理；ip白名单就是一种授权方式，只有指定的ip可以访问服务器，其他的不可以，从而防止恶意的访问；前置机的整体方案如图4所示。[0031]在一些实施例中，为了解决本方法运行过程中的异常情况，在本实施例中，进行了容错性设计，具体的：不同的系统之间通信会产生各种问题，比如网络波动，服务器异常等，造成数据拉取失败的问题，总的来说会对以下两种异常进行处理，第一种情况：中间件系统发起请求成功，但是银行系统因为各种原因报错了，返回错误error信息；第二种情况：中间件系统未能成功发起请求。[0032]针对第一种情况：在中间件系统发起请求的时候，中间件系统会将发起请求的参数信息存储到数据库中，根据银行系统最终返回值的情况，对请求进行标志成功或者失败；若银行系统返回为失败，触发重试机制，重新发起请求，当第二次重试请求失败之后触发第三次重试请求，直到重试次数达到最大可重试次数时，放弃重试。该请求进入到失败列表中，银行系统提供了一个失败请求列表，可以手动触发重试操作，进行人为干预。[0033]由于中间件系统支持多个系统之间同时拉取数据，可能有的系统数据是成功的，有的系统数据是失败的，中间件系统的日志表设计的时候做了一个关联明细表，当对多个银行系统发起请求的时候，会根据请求任务内容拆分到关联明细表，若银行系统返回信息错误，则由关联明细表针对错误的信息独立发起重试。例如：发送的请求包含单任务请求和多任务请求，无论是单任务还是多任务请求都是通过一个请求实现的，这个请求是主请求；主请求进入到中间件系统的时候，中间件系统会对请求任务内容进行拆分，例如一个请求抓取多个银行的流水信息，中间件系统就会拆分成不同的请求发送到不同的银行系统中，主请求的状态由多个子请求的状态决定，比如子请求a是成功的，子请求b是失败的，那么主请求是失败的，在重试的时候，我们只会重试子请求b，不会重发请求a。[0034]针对第二种情况：针对定时任务类型的处理，定时任务就是在某个或者间隔的时间范围内发起的数据拉取请求。在下次发起请求的时候，会从请求日志表中查找参数为最近的那一条数据，如果最近的那一条数据时间和发起该请求的起始时间有差距的时候，使用最近的那一条数据起始时间作为重新发送请求的起始时间，例如：设置每半个小时拉取一次数据，10:00拉取数据，拉取的是9:30‑ꢀ10:00的数据，请求发起成功，记录到了日志表中，日志表中有一条10:00点的数据，日志表中记录的内容包含：起始时间：9:30，终止时间：10:00以及请求的参数信息；如果，10:30网络断掉了，没有发起拉取数据的请求，这个时候日志中没有10:30的记录；11:00的时候拉取的应该是10:30ꢀ‑11:00的数据，实际上应该拉取的是10:00-11:00的数据；因为利用的是增量数据处理，为了防止数据遗漏，所以这里做了一个日志对比，对于没有抓取到的数据进行了补充处理；这样保证在因为网络等原因没有发起请求的时候，二次请求补发上一次未执行的请求，保证数据能够完整。[0035]在不同的实施例中，除了进去容错性设计，还做了钉钉告警处理，能够在第一时间获取异常信息，具体的：当中间件调用银行系统接口出错或者本地服务器宕机的时候，及时给钉钉推送告警信息，提醒开发及时处理异常情况。钉钉告警信息包含了异常堆栈信息，请求参数，告警时间和系统名称等重要信息，有利于排查问题及异常重试。[0036]需要说明的是，尽管在本文中已经对上述各实施例进行了描述，但并非因此限制本发明的专利保护范围。因此，基于本发明的创新理念，对本文所述实施例进行的变更和修改，或利用本发明说明书及附图内容所作的等效结构或等效流程变换，直接或间接地将以上技术方案运用在其他相关的
技术领域：
：，均包括在本发明的专利保护范围之内。当前第1页12当前第1页12
再多了解一些
本文用于创业者技术爱好者查询，仅供学习研究，如用于商业用途，请联系技术所有人。
