基于ESB的业务集成业务梳理

Posted 2022-03-25 数通畅联

 企业服务总线ESB在实际项目中一般有两个重要的应用模式，一是数据总线，二是服务总线：数据总线包括数据集成和文件传输，主要实现数据的抽取同步、清洗转换、加工汇总，典型应用场景就是ODS、数仓的数据汇聚；服务总线包括应用集成和API管理，主要满足跨系统的业务集成，最佳实践是通过API管理注册业务系统服务，满足服务治理、代理、鉴权、导出、统计分析、服务监控的需求，而应用集成以支持MDM、IDM产品之间的数据同步分发、统一认证为主。

ESB服务总线的典型应用之一就是完成基于服务的业务集成，通过ESB实现业务系统的凭证集成，同时对凭证相关的基础数据进行同步集成，以满足系统对接的需要。基于项目的实际开发情况对业务场景进行梳理，一方面总结ESB在业务集成项目的中应用方式，同时也可以不断积累ESB实际经验，为ESB升级优化提供借鉴。

1总体说明

本次只分析基于ESB的应用集成实现，主要业务需求是通过ESB实现二级子集团和集团的财务凭证对接，同时为了满足凭证对接的准确性，对于凭证涉及的基础数据也要进行同步。

1.1建设内容

1.对部门、人员、客商、项目档案等四类主数据主数据进行集成，由二级子集团的财务系统推送至集团财务系统；

2.建立主数据中间库，部门、人员、客商、项目档案以及产成品信息、原辅料包材信息等六类主数据从源头推送到ESB后，在ESB中将数据存储到中间库；

3.凭证集成，将二级子集团的新增/删除凭证通过ESB集成流程推送至集团财务系统；

4.凭证回调，集团财务接收二级子集团凭证并成功写入后，通过ESB的回调接口将写入结果回写对应的二级子集团。

1.2业务架构 

业务架构图如下： 

整体业务流程主要分为主数据集成和凭证集成两部分： 

1.主数据集成： 

1)主数据集成为单向流向，只从二级子集团流向集团财务，主要是为了保证凭证单据的关联和辅助核算； 

2)由各二级子集团提供源头数据，通过ESB集成接口将数据发送至集团财务； 

3)同时ESB将主数据在中间库进行存储，主要是为了后续主数据管理的建设需要； 

4)目前涉及的主数据类型主要有四类：分别是部门、人员、客商和项目档案； 

5)产品信息、原辅料信息数据由于信息中心需要，所以也要有二级子集团推送，但暂时只落地中间库存储，不推送集团财务。 

2.凭证集成： 

1)凭证集成也是单向流向，数据从二级子集团流向集团财务； 

2)凭证的操作包含新增、删除，由于集成对接的都是正式凭证，财务系统不允许修改，所以凭证没有修改； 

3)由于凭证数据和处理过程相对复杂，为了提升集成响应效果，凭证新增采用异步的方式，即财务接到数据后先返回正在处理标识，处理完成后再通过ESB给二级子集团返回处理成功的日志。 

1.3集成架构 

集成架构图如下： 

本次项目的集成访问主要是各二级子集团的财务系统和集团财务系统，通过ESB进行打通，实现数据同步，同时在数据库中建立中间表，用于对主数据进行留存。其中二级子集团财务系统、集团财务系统和ESB为双向交互，二级子集团推送数据至ESB，同时也接收ESB返回的凭证处理结果；集团财务接收ESB推送的主数据和凭证数据，同时将凭证处理结果推送给ESB。中间库只做单向写入，通过ESB写入主数据信息。 

1.4部署架构 

部署架构图如下： 

本次部署采用K8S云平台部署，采用5台服务器的高可用部署（3 Master + 2 Worker），除常规部署keepalived、haproxy 、NFS、Redis外，私有镜像库部署在Worker1和Worker2上，ESB开发环境部署在Master1上，测试环境集群部署在Master1和Master3上，生产环境集群部署于Worker1和Worker2上，具体部署信息参见上图。 

2业务流程 

主要业务流程包括两个内容，一是主数据集成，二是凭证集成，而主数据集成又分成中间库集成和财务集成。 

2.1主数据存储 

业务流程图如下： 

  

1.中间库存储首先需要在中间库为每类主数据建立对应数据表，并基于ESB设计器的服务向导为每类主数据开发服务； 

2.二级子集团的业务系统为源头，源头系统进行新增、修改、启用、禁用等操作时将数据封装、加密发送到ESB的集成服务； 

3.ESB获取源数据后，首先按照加解密规则进行解密，并进行数据转换，此转换过程目前只涉及客商主数据： 

1)如果主数据类型为客商主数据，首先获取供应商的企业社会信用代码或企业名称； 

2)调用天眼查接口，通过企业社会信用代码或企业名称查询企业信息； 

3)通过企业信息对源数据的行政区域编码、行政区域名称、注册地址、是否存续进行覆盖； 

4)再将转换后的数据推送至同步中间库的子流程。 

4.同步中间库子流程获取数据后，根据入参判断是哪个类型主数据，然后进行分支，不同类型主数据调用不同的主数据写入服务写入中间库。 

2.2主数据集成 

业务流程图如下： 

  

1.主数据集成主要是将二级子集团推送的主数据写入集团财务系统； 

2.来源和中间库存储相同，也是由子集团发送数据到ESB，ESB获取数据后进行解密、转换操作，此过程和中间库集成是相同流程； 

3.由于集团财务提供有主数据接收接口，所以ESB集成流程中只需要直接调用财务的接收服务即可实现主数据写入。 

2.3凭证集成 

凭证集成可以分成三部分：分别是凭证导入、凭证删除、凭证回调，其中凭证导入是二级子集团新增凭证推送集团财务，凭证删除是二级子集团将删除凭证标识推送财务，凭证回调是集团财务将凭证导入的结果回写二级子集团。 

2.3.1凭证导入 

凭证导入是二级子集团新增凭证推送集团财务，业务流程图如下： 

  

1.以二级子集团作为源头，新增凭证时数据以JSON的格式推送至ESB的凭证接收服务； 

2.ESB获取数据后进行解密操作，并以解密后的数据为入参，调用集团财务的凭证导入接口进行凭证写入。 

2.3.2凭证删除 

凭证删除是二级子集团将删除凭证标识推送财务，业务流程图如下：

  

1.以二级子集团作为源头，删除凭证时将凭证的标识信息以JSON的格式推送至ESB的凭证删除服务； 

2.ESB获取数据后进行解密操作，并以解密后的数据为入参，调用集团财务的凭证修改接口进行凭证写入； 

3.由于对接时正式凭证，财务不能进行凭证修改，所以只对接凭证删除操作，发送删除信息时，财务进行凭证状态的修改处理。 

2.3.3凭证回调 

凭证回调是集团财务将凭证导入的结果回写二级子集团，业务流程图如下： 

  

1.凭证回调是以集团财务作为源头，当集团财务接收二级子集团推送的凭证数据后，立即返回一个正在处理的标识，然后异步进行数据写入； 

2.财务完成凭证写入后需要通知二级子集团，所以需要调用ESB的回调接口返回处理结果； 

3.由于二级子集团比较多，并且每一个集团的接口地址都不相同，所以需要在ESB中封装一个包装服务，在包装服务中根据财务推过来的子集团信息，分支判断调用不同子集团的接口进行回写。 

3接口设计 

根据实际业务需求，ESB设计规划为两个工程，分别是主数据集成和业务集成，主数据集成包括各类主数据的写入服务、集成流程、中间库写入流程；业务集成包括凭证导入、凭证删除和凭证回调的集成流程。 

3.1服务分类 

  

3.2主数据集成 

主数据集成包括Rest服务、集成流程和主数据写入子流程三部分，具体清单内容如下： 

  

1.六类主数据的写入服务均为Rest服务，通过ESB设计器的服务向导生成，根据实际数据的情况进行调整，主要调整Update操作； 

2.由于主数据传输支持多条传输，所以对于主数据服务需要调整为支持DataSet操作的方式，以支持多条操作； 

3.天眼查服务主要是对天眼查的接口进行封装，主要用于对供应商主数据进行数据校验和丰富； 

4.主数据集成采用ESB的应用集成建立，主流程为Http流程，由源头系统调用，采用推送的方式推送JSON格式的主数据； 

5.主数据写入中间库时，根据入参的属性判断该数据属于哪类主数据，再在中间库写入子流程中进行分支判断，调用不同的主数据写入中间库接口实现中间库写入。 

3.3凭证集成 

凭证集成主要包括凭证导入、凭证删除、凭证回调三个集成流程，另外考虑到凭证回调涉及到不同的子集团，所以对于凭证回调需要建立服务进行回调的判断和处理。具体接口清单如下： 

  

1.凭证集成均通过ESB的应用集成实现，在集成流程中主要进行解密操作，无需进行额外的数据转换； 

2.凭证推送采用单条推送，每次只推送一条凭证，但由于凭证中涉及多个分录、辅助核算，为了提升响应效率，采用异步的方式，需要通过凭证回调接口异步返回推送结果； 

3.在集团财务将结果回调给子集团时，由于凭证来源于多个不同的子集团，所以ESB需要根据财务的入参判断单据来源于哪个子集团，再根据子集团的接口地址进行调用回写。 

4技术要点 

本次的业务集成相对简单，无论是主数据集成还是业务集成，系统都提供了标准的接口，对接相对简单，业务数据的处理大部分也由业务系统完成，所以ESB的开发相对容易一些。但是由于涉及到数据安全性以及完整性的问题，所以也有一些技术点需要实现。 

4.1加密解密 

由于二级子集团和集团是在不同的网络环境下，需要采用外网交互，所以对于ESB和二级子集团的交互，需要进行数据加密，而ESB和财务都在集团网络下，内网交互采用明文的形式。所以二级子集团调用ESB接口是需要对数据进行加密处理，ESB获取数据后先进行解密，再将解密后的数据发给财务。 

1.加密规则：对称加密DES 数据加解密； 

2.加密模式：DES加密，CBC模式+PKCS5Padding填充； 

3.加密密钥：1a2b3C4d5e6h7g8=； 

4.IV向量：12345678。 

ESB产品底层预置有加密规则，但是由于ESB加解密的密钥和IV是相同值，和本次规则不一致，所以手动在工程中进行了方法扩展，扩展代码如下： 

  

  

  

1.密钥和IV向量通过静态变量固定； 

2.加解密的过程中注意用Base64进行转码处理； 

3.注意DES加密的IV向量长度，DES采用64比特进行分组，所以IV向量的长度是8个字符，密钥是16个字符，否则会出现“block”异常。 

4.2token认证 

为了提升接口调用的安全性，对于ESB提供的接口需要提供token认证机制，基于ESB的安全认证实现，通过在应用集成开启token机制，如图所示： 

在ESB的应用管理中配置的各个二级子集团信息： 

对每个应用分别生成公钥和私钥： 

基于公钥进行加密，生成系统的密码： 

根据密码获取token： 

4.3天眼查接口 

天眼查接口主要是用于查询供应商信息，以补足二级子集团推送客商时数据不准确以及部分信息缺失的情况，由于天眼查接口需要提供给ESB集成客商主数据时使用，同时为了后续集成需要，所以对天眼查接口通过ESB进行封装，对外发布成服务。 

本次使用天眼查接口主要是用于补充客商信息： 

1.以统一社会信用代码作为第一条件进行校对，当查询到的名称与提供的名称一致时，校验成功并入库，并覆盖其他信息（行政区域编码、行政区域名称、注册地址）； 

2.当统一社会信用代码为空时，以客商全称作为查询条件进行校对，当可以查询到对应的社会信用代码时，校验成功并入库，并覆盖其他信息（行政区域编码、行政区域名称、注册地址）； 

3.当以上条件均不满足时，不进行入库，并返回错误信息： 

1)“此统一社会信用代码对应的客户名称不准确，请查证后重新填写”； 

2)“此客商名称无法查询到统一社会信用代码，请查证后重新填写”； 

3)“统一社会信用代码和客商全称为空，请补充完整后重新填写”。 

5分析总结 

本次项目的主要内容是业务集成，其中主数据集成也是为了支持凭证集成的需求，所以本次主数据集成只进行同步，同时落地中间库进行存储，也是为了后续主数据的建设提供支持。 

5.1产品应用 

ESB平台在实际项目中的应用主要是数据总线和服务总线，数据总线是完成数据集成的需要，如结合DAP、MDM构建数据中台，通过ESB实现数仓的数据汇聚，服务总线是以服务为基础实现的业务系统对接，如本次的主数据集成和凭证集成，都是通过ESB的API注册、应用集成快速配置和生成集成流程，满足接口对接的需求。 

本次由于主数据在中间库落地，而中间库是开发ESB流程时建立的，所以也使用到ESB的服务向导针对数据表开发了接收服务，从而基于ESB应用集成实现主数据的中间库落地。 

5.2项目总结 

本次项目总体来说相对简单，无论是业务场景还是数据的处理，ESB的工作量都不大，所以无论是开发、测试的过程都比较快，ESB主要是处理过程就是数据加解密、字段映射和天眼查数据丰富，对于数据加解密、token密钥生成等操作由于产品底层都预置了相关算法和机制，所以可以通过ESB快速进行扩展，并且也已经把加解密、token密钥生成纳入到了的ESB升级计划中，后续可以直接在SMC中通过配置自动生成或者进行加解密处理，使用产品更加易用和方便。通过项目推动产品完善，项目需求是产品升级的重要推送，而完善的产品也能加快项目交付的效率，二者相辅相成、相互支撑，有效支持公司的发展。 

5.3个人总结 

本次ESB的集成由于涉及的内容较少，开发的工作也相对简单，所以主要负责整体的把控和交互，对于实际的开发工作参与较少，但是对于项目中实际的业务场景也是比较全面的进行了梳理，对于接口集成的测试工作也参与了大部分，可能出现的问题、需要优化的内容有比较清晰的了解，特别是对数据加密、token认证更多的进行了了解，因为之前项目中并未了解这方面内容，所以借助本次项目加以了解，也便于后续项目的开展。 

ESB作为公司的核心产品之一，无论是数据中台还是集成底座方案都有应用到，所以它在核心产品中是非常重要的，并且也有很多项目是直接单独使用ESB产品的，所以充分了解ESB的功能以及实际应用非常重要，特别是ESB在不同行业、项目，不同场景下的具体应用，只有做到熟练掌握，才能为后续项目的实施起到积极的作用。