主数据分发流程开发总结

　　在企业中，由于开发时间或开发部门的不同，往往有多个异构的、运行在不同的软硬件平台上的信息系统同时运行，这些系统的数据源彼此独立、相互封闭，使得数据难以在系统之间交流、共享和融合，从而形成了＂信息孤岛＂。随着信息化应用的不断深入，企业内部、企业与外部信息交互的需求日益强烈，急切需要对已有的信息进行整合，联通＂信息孤岛＂，共享信息。
　　为消除各企业间的＂信息孤岛＂，需要对各企业的数据格式进行映射处理，保障数据在传输到目标企业时，与目标企业接口所规定的格式相同，目标企业可以直接接收存储，保障企业间实现数据互通，消除＂信息孤岛＂。在此过程中，企业服务总线通过拉取或是源头系统推送的方式从源头系统取得数据，将数据同步至主数据平台之中，由主数据平台统一进行数据的分发，将数据传输至下游系统之中，完成整体的数据集成。整体说明
　　主数据平台在进行数据分发时支持多种方式，可以根据下游系统开发的不同数据接口选择不同的分发方式。即使下游系统提供的接口不能直接地进行数据分发，也可以通过企业服务总线进行封装，完成数据的分发操作。
　　1.整体介绍
　　主数据平台可以将数据以JSON格式推送至下游系统提供的接口中；也可以推送taskId至下游系统，下游系统通过taskId在主数据平台提供的任务解析接口完成数据的获取；但也有下游系统提供的接口无法直接推送数据的情况，此时可以通过内部的企业服务总线进行协助，将下游系统的接口进行封装，并完成数据的分发。如此便可以针对不同的场景，使用不同的数据分发方式，完成数据集成操作。
　　2.功能架构
　　本篇文档记录的为上文中提到的第三种分发场景，由于下游系统提供的接口地址不能直接推送JSON或是taskId，所以在本次集成开发时，通过企业服务总线对下游系统的接口进行处理，主数据平台在进行数据分发时，调用企业服务总线开发的流程，将taskId推送至流程之中，经过流程的一系列处理，将数据推送至下游系统当中，完成数据的分发操作。
　　数据分发架构图如下所示：
　　3.功能需求
　　本次流程开发核心需求如下：
　　1.保障数据集成的整体流程畅通，源头系统与下游系统数据一致；
　　2.由于调用下游系统接口需要获取其系统的token，需考虑token的有效期；
　　3.为保障快速完成流程的开发，使数据集成工作落地，各业务系统应配合进行对其提供接口的测试，如出现问题双方配合快速进行调整；
　　4.主数据平台应记录数据分发日志，便于后续问题排查。需求分析
　　在得到需求之后，针对需求进行具体分析，明确工作目标，理清工作思路。本次工作主要目标是实现数据从主数据平台分发至下游系统，保障项目中各版块的数据一致性，提前扫清后续工作中因数据结构不一致而引发的问题。
　　1.需求说明
　　本次工作主要是对下游系统提供的接口进行处理，由于其提供的接口需要进行多次认证，同时接口接收的数据与常规的格式存在差异，所以需要对要分发的taskId进行处理，完成多次认证之后，将处理完成的taskId推送至目标接口当中，同时完成主数据平台的配置，使主数据平台可以对数据进行统一的分发操作，数据集成整体开发工作也就宣告结束。
　　2.实现思路
　　针对上文中给到的需求，对本次集成开发做出如下规划：
　　1.测试下游系统提供的接口，保障接口可以调用成功；
　　2.创建API服务、集成场景；
　　3.在设计器中生成对应的集成流程；
　　4.对生成的集成流程进行适配调整；
　　5.进行数据分发测试。
　　3.准备工作
　　本次开发工作需要进行的准备工作如下：
　　1.由于本次是对下游系统提供的接口进行封装操作，所以需要保障其提供的接口可用，故需对接口进行测试；
　　2.根据提供接口的业务系统，为其进行数据分发权限配置，使数据可分发，分发后下游系统可以完成数据查询；
　　3.由于本次需要对其他系统的接口进行测试，所以需要提前协调对应系统的人员进行时间安排，便于快速处理出现的问题。实施阶段
　　在明确具体实施需求，同时完成前期的接口准备之后，接下来正式进行集成开发工作，在本章节中，将对本次开发过程中时间占比较大的步骤进行介绍，梳理工作过程，以供后续回顾。
　　1.接口测试
　　在本次流程开发之中，主要围绕着下游系统提供的接口开展，因此必须要保证该接口调用无问题，便于后续开发工作的开展；所以第一步便是对接口进行测试，测试过程如下：
　　与提供该接口的业务系统人员协调时间，根据其提供的接口文档完成对接口的调用，如图：
　　在出现问题时，与其进行问题确认，快速进行问题修复，如下图，便是出现问题的情况：
　　接口测试是本次开发工作开始前所必须要进行的，如不对接口进行测试，在后续开发工作中如果出现报错，问题排查的难度将会提高。
　　2.创建服务
　　API服务采用注册或导入的方式生成，对场景创建过程中需要使用到的接口进行服务的注册，对服务中需要使用的接口进行入参、出参的配置，具体配置步骤如下：
　　注册主数据系统服务，填入对应的主数据服务地址，点击解析，如图：
　　打开主数据系统服务，配置接口出参信息，如图：
　　点击注册，配置下游系统服务的基本信息，如图：
　　点击新增，配置API接口，如图：
　　双击新增的API接口，配置接口入参，如图：
　　3.流程创建
　　在场景配置中点击新增，并填写相关基本信息，如图：
　　在映射参数中点击解析，如图：
　　在集成流程中可以看到配置完成的集成流程，如图：
　　在设计器中创建消息流程，选择应用服务集成，如图：
　　点击Next，点击刷新，选择需要的集成流程，如图：
　　调整生成出来的默认流程，完成集成开发，如图：
　　功能测试
　　在上个章节已经对流程的整体开发步骤进行了介绍，在本章节中，将对开发完成的流程进行功能测试，验证数据分发整体流程是否能够正常运转，并处理出现的问题。
　　1.权限分配
　　在进行数据分发时，由于分发的是taskId，下游系统需要通过taskId进行数据的获取，且主数据平台对于不同的系统可以分配不同的权限，对查询到的字段进行获取，因此在具体测试前，需要先对系统权限进行分配，具体步骤如下：
　　创建需要分配的应用系统，并完成相关参数配置，如图：
　　双击创建完成的应用系统，配置分发到该系统的数据，如图：
　　双击要分发的主数据，双击需要的字段，完成元数据关联配置，如图：
　　2.功能测试
　　分配权限之后，正式对分发功能进行测试，验证功能的可用性，测试过程如下：
　　选中要分发的数据，点击生成任务，如图：
　　在应用关联中选择要分发的目标系统，如图：
　　选择对应的分发流程，如图：
　　当下游系统接收到数据并完成日志回写后，效果如图：
　　3.问题总结
　　在进行流程开发以及功能测试的过程中，遇到了一些问题，在此对遇到的问题进行总结，以供后续回顾：
　　1.在前期进行接口测试时，测试不全面，导致后续在进行流程测试时，需要联系接口负责人进行调整，影响测试效率；
　　2.由于项目前期使用的域名发生了变化，下游系统使用的是旧域名，导致接口调用失败，最终导致分发流程执行失败；
　　3.下游系统调用接口时，查看接口文档不仔细，接口入参填写错误，导致数据获取为空。总结归纳
　　本次开发工作是项目工作的一部分，主要进行源头系统数据的映射转换处理，并存储到主数据平台后，进行数据分发时使用的分发流程的开发工作；在实际工作中，与到了一些问题，也有了一定的收获，在此将对近段时间的工作进行总结。
　　1.工作总结
　　本次进行的是分发流程的开发，在开发之前已经与下游系统完成约定，推送的数据为taskId，因此相较于数据同步流程的开发，数据分发流程的开发会轻松很多，缺少了很多字段处理的操作；本次进行数据接收的下游系统提供的接口中，进行了多次认证，因此占据流程开发较多的时间；在流程开发以及流程测试过程中，也出现了一些问题，问题大多数在下游系统接口产生，由于在开发前就进行了接口测试，因此并未影响到流程的开发工作。
　　2.后续规划
　　对于数据分发，在主数据平台中，可以推送JSON，也可以推送taskId，即使下游系统接口特殊，也可以结合企业服务总线，对接口进行封装，如果下游系统不想进行接收数据接口的开发，也可以通过主数据平台提供的数据查询接口获取数据，完成数据的集成操作；主数据平台的数据分发功能尚有不足之处，但结合企业服务总线，便足以应对各种数据集成场景，在后续将对主数据平台的不足之处加以优化，使集成场景更为完整。
　　3.总结归纳
　　数据分发流程的开发，如事先进行数据的约定，如本次的taskId，那么流程开发工作便会轻松许多，相较于数据同步流程，其减少了对于字段的处理，这极大的减少了流程开发的时间；但在开发之前，必须要对下游系统的接口进行测试，保证接口的可用性，在后续测试流程出现问题时就不必协调接口负责人进行接口调整，提高了测试的效率。
　　由于本次使用的是数据中台方案，所以在后续的工作中，数据分析平台将几乎占据工作的全部时间，与主数据平台的工作不同的是，数据分析平台涉及到对业务数据的分析处理，需要花费一定的时间对业务进行熟悉，了解整体业务逻辑之后，工作开展将会更为顺利。
　　本文由@数通畅联原创，欢迎转发，仅供学习交流使用，引用请注明出处！谢谢~