一次主从表集成流程开发过程

主从表即从表数据依赖于主表，一般最后查询数据时把主表与从表进行关联查询。主表：在数据库中建立的数据表，其中存在主键用于与其它表相关联，并且作为在主表中的唯一性标识。从表：以主表的主键值为外键的表，可以通过外键与主表进行关联查询。从表与主表通过外键进行关联查询。主表可用于存储主要信息，从表用来存储扩展信息。

使用主从表可以很大程度地节约系统资源，一条主表数据对应多条从表数据，如不采用主从表形式，主表数据就会有大量的重复，通常有多少从表数据就会有多少条主表数据，很大程度地浪费系统资源，且这种浪费是可以避免的。通过主键及外键生成主从表，以外键做约束，实现一对多的数据形式。本篇文档记录的就是以主从表作为源头及目标进行数据同步的集成流程开发过程。

▎整体介绍

主从表的数据同步与其他数据同步不同之处在于，主从表的数据在数据查询时需要将主表数据以及与之关联的从表数据一并获取，并不是单独获取某一条数据；数据接收方亦是如此，接收数据时一并将主从数据进行存储。

1.整体说明

在正式开始介绍本次工作前，先对本次工作环境进行介绍，本次工作是在 ESB 基础样例中进行，ESB 基础组件样例工程的默认生成主要针对项目实施人员以及企业服务总线初学者，便于上述人员对 ESB 基本功能进行了解，主要功能包括常规数据的映射及转换、数据适配器的相关操作、协议适配器的相关操作并结合 SMC 管理控制进行应用集成及服务流程的监控统计等等，同时也便于项目实施人员进行默认样例生成并进行常规功能使用方法的反查。本次工作就是基础样例中的数据映射及转换部分。

2.集成架构

本次功能的数据来源表为账户分组表及账户实体表（HR）；用户分组表及用户实体表（OA），这两部分互为数据的源头，为对方提供需同步的数据，并作为接收方接收对方同步来的数据，集成架构图如下：

各类数据源头及目标系统如下：

3.功能需求

本次工作是在原有 ESB 基础样例应用集成部分的流程基础上进行调整与优化，将原有的数据获取服务及数据接收服务调整为主从表服务，同时将服务接口对应的出参或入参调整为动/静态模型的格式；在此基础上，调整原有的集成流程，对通过 Rest/Web 服务查询得到数据进行相应的格式转换、字段映射等处理，将经过转换后的数据传输到目标服务的对应接口中，将数据写入至目标数据库中；同时在数据同步过程中，无论是数据获取或是数据接收，处理的数据皆为主从格式数据。

▎需求分析

本次需要完成的工作分为两部分，一是模拟业务系统的数据表相关服务的开发；二是对应的数据同步流程的调整开发。在本章节中，将对本次工作的需求进行分析，明确工作目标、理清工作思路。

1.前期准备

在获取本次需求之后，从需求中提取出本次工作的具体实现目标：主从数据的同步、传输过程中使用动静态模型对数据传输的格式进行约束。针对上述关键点，首先根据需求撰写开发前的设计文档，并与领导确认思路是否正确，保证工作开展方向正确，其次完成模拟业务系统的数据表的设计及创建，完成后续服务的创建的前期准备工作，最后根据设计的数据表，创建约束数据格式的动静态模型；这些准备工作的完成可以保障后续的工作顺利开展。

2.工作目标

根据前文中的需求进行分析，得出本次开发工作需要达成的目标为：主从数据的同步，即在同步主表数据的同时会将其对应的从表数据一并完成同步操作，同时对主表以及从表进行写入操作。同时在达成此目标的过程中，还有其他的一些需求，如在数据传输过程中需要使用动静态模型对数据格式进行控制，同时由于源头及目标系统的服务不同，需要考虑 JSON 及 XML 格式数据间的相互转换操作。

3.实现思路

本次工作开展需要创模拟业务系统数据表的相关服务的创建、约束数据格式的动静态模型的创建以及主从格式数据同步的集成流程的创建，实现思路如下：

1.根据主从格式的数据创建动静态模型，动静态模型需创建主从形式，主模型需以 list 形式保存从模型；

2.用户数据表的服务为 REST 服务，使用的数据模型为动态模型，在服务的更新接口中获取传来的 JSON 格式数据直接转为动态模型并完成后续的数据存储操作，在查询接口中将根据条件获取到的数据转换为动态模型并输出；

3.账户数据表的服务为 WEB 服务，使用的数据模型为静态模型，在服务中配置接口对应的入参、出参为静态模型，在接口中进行对应的映射转换操作完成数据的处理；

4.根据创建完成的服务，在管理控制台中完成场景的创建并生成集成流程，在集成流程中根据数据的格式进行格式转换、字段映射等处理，实现主从数据的同步操作。

▎实现步骤

明确具体工作目标，同时根据工作目标完成对实现思路的梳理，可以开始着手开展开发工作，在本章节中，将对本次开发工作的实现步骤进行阐述，具体分成模型、服务及流程三部分进行描述。

1.模型创建

本次开发工作中使用到的模型分为动态模型以及静态模型，动态模型的创建步骤如下：

在 SMC 管理控制台服务工程中的服务模型中，点击新建，如图：

在模型详情中填入模型的基本信息，同时在模型样例中填入希望创建的模型格式的 JSON 数据，如图：

静态模型的创建步骤如下：

在 ESB 设计器中右击 SM 模型，点击新建服务模型，如图：

在服务模型向导中填入模型的基础信息，完成模型的创建，如图：

在主模型中点击选择模型，选择从属模型，完成主从模型的创建，如图：

2.服务创建

在 ESB 设计器中，基于数据表创建服务，模式选择主从表模式，如图：

填写服务的基本信息，如图：

在 WEB 服务中，将相关接口的入参出参设置为对应的静态模型，如图：

在接口中完成数据的转换操作即可完成服务的创建。

3.集成流程

在管理控制台 API 服务中，导入创建完成的服务，如图：

在对应的接口中完成入参、出参的配置，如图：

在场景配置中创建场景并完成基本信息的录入，如图：

在映射参数中点击解析，完成参数的映射，如图：

在设计器中创建对应的集成流程，并完成相关调整，如图：

▎功能测试

在完成开发之后，需要对开发成果进行功能上的测试，验证开发成果是否满足最初需求，开发过程中是否有考虑不全面之处，在本章节中将对本次开发成果进行整体验证，查看是否有缺漏之处。

1.预期效果

在本次功能开发的最终目标是实现主从数据的同步操作，当调用集成流程时能够将主从数据一并同步至目标数据表中；同时由于本次开发功能分为触发、推送以及定时三种类型，在调用触发流程时，输入分组 CODE 将分组及分组之下的所有实体进行同步；推送则是将需要同步的数据以 JSON 格式作为集成流程的入参进行同步；定时集成流程按照设定的定时策略批量同步数据。

2.触发流程

以账户到用户为例，在管理控制台中输入分组 code 值，点击调用，如图：

通过上图的相应输出可以看出，流程执行成功，也可在流程日志中进行查看，如图：

在目标数据库中查看分组及分组对应的实体是否同步成功，如图：

实体效果如图：

3.推送流程

以账户到用户为例，在管理控制台中输入希望同步的 JSON 数据，点击调用，如图：

通过上图的相应输出可以看出，流程执行成功，也可在流程日志中进行查看，如图：

在目标数据库中查看分组及分组对应的实体是否同步成功，如图：

实体效果如图：

4.定时流程

在集成流程中配置定时流程的定时策略，由于本次是测试功能，所以将定时策略配置为间隔 1 分钟，如图：

启动定时流程，等待一分钟，在流程监控中查看流程是否被调用，如图：

在目标数据库中查看分组及分组对应的实体是否同步成功，如图：

实体效果如图：

▎工作总结

本次主从表数据同步的集成流程的开发工作，本人从得到最初的需求开始，到后续的动静态模型的创建、使用以及服务及流程的调整，从中收获颇多，在此将对本次工作中的收获及心得进行总结。

1.工作收获

通过本次的开发工作，本人对于动态模型、静态模型的创建以及使用有了进一步的理解，明确在流程中如何通过动/静态模型对数据的格式进行控制，同时对于主从数据如何通过动静态模型进行格式控制也有了一定程度的掌握；除此之外，对于主从格式的数据在同步过程中，如何对主表以及从表数据一并操作也有了更深层次的掌握。在正式的项目开发工作中，可以通过动静态模型对数据进行规范化处理，将转换为驼峰命名的方式去进行后续的其他操作；如后续的工作中涉及主从数据的处理，也能够根据本次工作得到的经验去更快地完成工作。

2.能力提升

通过本次工作，对于同步过程中的数据格式处理理解得更加深刻，对于 ESB 设计器中的 JAVA 转换组件、映射组件等数据格式转换组件的使用更为熟练；同时由于本次使用到的服务为 REST/WEB 两种服务，对于这两种服务相互间的数据同步需要对哪些位置进行调整也有了进一步的掌握，可以提高后续此类工作的完成效率。

3.总结归纳

本次功能开发完成后，可以通过本样例去反查动静态模型的使用、主从数据同步过程中数据的处理以及 REST/WEB 两种服务之间 JSON/XML 格式的数据如何进行转换，使不熟悉这些操作的使用者快速地了解并掌握；也可以让项目实施人员通过本样例去快速地修改成需要的流程。

本次开发的功能与以往开发的同步流程不同，在本次开发的流程中，较以往的同步流程有了更多的数据格式转换，同时也应用了更多的模型使用，通过创建样例反查本次开发的功能，可以使企业服务总线的初学者更快地掌握各种数据格式的转换方式，也可以使项目实施人员快速地进行转换、映射组件以及动静态模型使用方法的反查。