集成底座项目典型数据下发方式对比说明

Posted 2022-04-18 数通畅联

随着企业信息化的不断发展、不断升级，越来越多的业务系统在满足企业业务发展的同时，往往又会成为信息化建设和业务操作上的瓶颈，无论是频繁进行业务系统切换，还是跨系统之间的基础数据的维护与打通，都难以应对企业业务的快速变化和发展，而为了更便捷地打通系统的关联，消除系统集间使用的瓶颈，针对企业实际业务建立集成底座平台则是非常有效的一种方式，通过集成底座打通各业务系统，实现系统的对接，从而满足在实际业务过程中系统间有效、快速、稳定对接。

通过集成底座构建企业信息化的基础框架，实现业务系统的集成和数据互通，实现对基础数据的统一管理和集成整合，打通各个系统的访问壁垒，实现便捷交互、快速切换，无论是对于信息化建设还是企业企业发展都是非常有利的。

1总体说明

集成底座主要包括：IDM统一身份认证平台、MDM基础数据管理平台、ESB企业服务总线三款核心产品，并通过UMC云管理平台进行部署维护。从架构规划上，集成底座更偏向于信息化层面，是基于信息化系统基础上的第一层集成，更多的是要打通系统间的访问壁垒，初步的完成基础数据的集成。

1.1集成架构

整体架构图如下：

由业务系统作为基础数据的源头，如组织、岗位、人员等人事类主数据由HR系统提供，这些基础数据通过ESB同步至MDM平台进行统一管理，并进行数据清洗，保证基础数据的准确性、唯一性。MDM再将治理后的组织、人员分发至IDM平台生成对应的群组和认证账号信息，并将账号数据下发到下游系统实现统一账号和统一认证，用于支持统一认证等业务。MDM将各类基础数据分发至下游业务系统，保证各系统基础数据的一致性。 

1.2业务流程 

对于集成底座项目的实施，主要针对实际项目中IDM、ESB、MDM产品的集成模式进行梳理，主要包括主数据同步、主数据分发、用户分发三部分内容。 

1.主数据同步： 

1)源头推送数据（或者推送查询标识）至ESB的集成流程； 

2)ESB的集成获取源头数据（或者通过查询标识从源头查询数据）后，在集成流程内部调用MDM的接口； 

3)生成主数据编码，并将数据写入MDM，同时生成任务和同步日志； 

4)ESB集成流程调用MDM的自动提交接口将任务提交至MDM的BPM工作流中，BPM工作流通过调用ESB的分发流程实现数据向下游系统的分发。 

2.主数据分发： 

1)通过ESB开发主数据分发的集成流程，提供给MDM的BPM工作流进行调用； 

2)集成流程的入参为MDM任务的taskId，通过taskId查询MDM的任务数据，并根据业务要求进行数据处理； 

3)处理后调用下游系统的数据接收接口将数据写入到下游系统中； 

4)下游系统完后数据写入后调用MDM的日志回写接口进行数据回写操作。 

3.账号分发： 

1)账号分发主要是通过IDM将登录用户信息分发至下游系统，实现各系统的统一认证和单点登录； 

2)账号分发涉及两种场景，一是业务系统的账号和人员信息是一致的，那么直接通过MDM分发人员至下游系统即可，IDM只需要管理认证信息，不需要对下游进行分发；二是业务系统的账号和人员是分开，那么MDM负责人员的分发，IDM则负责账号的分发； 

3)IDM账号分发主要是将IDM的账号信息通过任务的形式分发下游系统，和MDM的分发方式类似； 

4)在账号信息进入IDM平台，可以手动或自动的方式生成分发任务，再通过IDM内置的BPM工作流进行自动提交； 

5)在BPM工作流内调用ESB的IDM分发集成流程实现向下游系统的数据分发； 

6)IDM分发集成流程的入参为IDM任务的taskId，通过taskId查询IDM的任务数据，并根据业务要求进行数据处理； 

7)处理后调用下游系统的账号接收接口将数据写入到下游系统中； 

8)下游系统完后数据写入后调用IDM的日志回写接口进行数据回写操作。 

1.3下发方式 

集成底座的集成方式主要分为三种：推送模式、推拉模式、消息队列，三种方式适用于不同的业务场景中各有优缺点，在实际项目中需要根据集成模式、数据类型、业务场景、技术要求等不同的情况合理选择对应的下发方式。 

2推送方式 

推送方式是最直接的对接方式，即源头系统直接把数据推给下游系统，下游系统直接接收数据，在集成底座项目中，推送方式就是MDM或IDM将需要下发的数据封装成JSON格式直接推送给下游系统，下游系统获取数据后直接进行系统写入操作。 

2.1使用场景 

推送方式一般适用于数据量较小的情况，如实时小数据量推送，如果MDM每次分发都是推送单条或几条数据，就可以考虑推送的方式，保证数据集成的同时也不会对服务器造成太大压力，典型如组织、岗位、人员主数据。 

2.2业务流程 

1.对于集成底座而言，由于MDM、IDM等源系统提供的接口都是基于推拉模式的，所以如果实现推送方式，都是通过ESB进行二次封装处理的； 

2.MDM生成taskId后，将taskId发送给ESB，ESB基于taskId调用MDM的增量数据接口获取增量数据； 

3.ESB拿到数据后根据需要进行简单的转换处理，然后调用下游系统的数据接收接口进行数据推送； 

4.下游系统获取ESB发送的数据后进行数据处理，并写入到下游系统内部，写入完成后进行日志记录，并将写入结果同步返回给ESB； 

5.ESB获得下游系统的结果后，进行日志记录，并调用MDM的日志回写进行进行日志回写。 

2.3方案说明 

优点： 

1.下游系统可以直接拿到数据，不用再次调用MDM的接口，减少技术底座和业务系统的二次交互； 

2.在下游系统进行接口开发时，只需要按照对接标准，考虑接收数据进行数据处理即可，不需要考虑从MDM或IDM获取数据的逻辑。 

缺点： 

1.不利于对接标准的固化，如果对接业务系统时需要字段扩展，就需要进行标准变更； 

2.如果MDM的类别以及数据量较大时，同时下发不仅会造成MDM服务器的压力过大，也会造成ESB服务器的压力过大（因为是通过ESB进行数据下发）； 

3.在前期测试以及后续的运维过程中，每次测试都需要反复在MDM进行手动下发，再抓取数据进行判断，特别是远程联调时，需要反复操作，产生大量历史数据，还有降低测试效率；需要MDM和下游系统同时抓取数据进行分发，问题定位比较繁琐； 

4.如果MDM进行字段新增、修改操作等，可能需要根据ESB流程情况进行调整，增加后续变更的风险。 

3推拉方式 

推拉方式是将推送方式进行拆分，分成两步实现，先由源头系统下发标识或通知到下游系统，下游系统根据标识或通知主动从源头数据拉取数据。在集成底座方案中，推拉主要体现是由MDM或IDM分发taskId给下游系统，下游系统通过taskId调用MDM或IDM接口获取对应增量数据。 

3.1业务场景 

推拉模式一般适合于单次数据量较大的场景，如新系统上线时需要大批量推送数据，或者每次推送时都需要同时发送多大批量数据的情况，典型如物料主数据，特别是在生产制造业务中，每次物料调整可能都需要对BOM、工艺等数据进行关联推送的场景。 

3.2方案说明 

优点： 

1.MDM通过分支的方式发送taskId给不同的下游系统，便于下游系统按照统一标准进行接收，后续新系统接入是直接对照标准获取数据即可； 

2.MDM只发送taskId，起到削峰的作用，避免大批量发送数据造成服务器压力过大以及网络堵塞； 

3.MDM和下游系统解耦，每个系统只负责自己的内容，保证MDM能发送taskId，下游系统能接收即可，后续维护时便于进行问题的排查和定位； 

4.如果MDM后续进行字段新增、修改操作等，不需要调整ESB流程，通过taskId获取的数据会自动进行变更； 

5.测试比较方便，因为taskId是永久的，只要做一次任务，下游系统就可以独立进行测试而不需要每次由MDM进行分发测试； 

6.MDM只提供taskId，将后续新系统对接时入参格式变更带来的风险降到最低。 

缺点： 

1.需要下游系统进行二次操作，获取taskId后需要再调用一次MDM的接口获取数据； 

2.需要对接规范中定义好入参格式，如果后续MDM调整字段，需要及时变更对接标准规范。 

3.3业务流程 

1.首先由源头系统根据数据建立任务，并生成任务标识taskId； 

2.源头系统通过内置工作流等方式下发taskId，下发时可以考虑通过ESB代理下游系统，也可以直接发给下游系统接口； 

3.下游系统接收taskId后，直接调用源头的接口进行数据获取，也是可以采用代理或直接调用两种方式； 

4.下游系统获取数据后进行数据解析处理，写入系统数据库中； 

5.写入完成后生成对应的日志，进行日志记录并调用源头系统的日志接口进行日志回写。 

4消息队列 

消息队列的方式一般是采用消息队列中间件实现上下游系统的交互，源头系统将数据或消息发送至消息中间件中，下游系统通过监听消息中间件进行数据获取，再实现下游系统的写入。 

4.1使用场景 

消息队列的方式一般会采用MQ实现，这种方式更多的适用于小数据量，频度很高的推送场景，如业务单据对接的场景，一般每次都是单条数据，但是推送频率比价高。一般情况下主数据并发频度不高，而数据量的大小确实不定的，所以不建议采用MQ的方式。 

4.2方案说明 

优点： 

1.进一步解耦，源头和下游系统直接对接MQ，不直接进行交互，降低服务器压力； 

2.异步处理，无需进行等待，各系统只需要读写MQ实现数据读写； 

3.异步分发，系统接口无需考虑返回值的问题，只需要记录好日志。 

缺点： 

1.不适合单次大数据量，适合单次数据量小，但频次高，便于削峰解耦； 

2.考虑到使用性能和安全性，需要单独搭建MQ平台，最好是MQ集群； 

3.MQ不适合放大量的数据，所以有时还是需要采用推拉的方式，将taskId之类的通知或标识发送到MQ中，下游系统根据通知或标识再获取一次数据； 

4.下游系统需要考虑实时性问题，及时获取MQ中存入的数据； 

5.因为要对接多系统，采用发布/订阅的方式，要充分考虑MQ中数据的有效性（定时销毁会不会影响下游系统接收）。 

4.3集成流程 

1.首先源头系统生成标识信息或需要分发的数据，并将该标识或数据发送到MQ中； 

2.下游系统进行MQ的监听，监控到数据后直接从MQ中进行标识或数据获取； 

3.下游系统从MQ拿到数据后，如果是标识，则需要调用源系统接口获取数据（类似推拉方式），如果获取的是数据则直接进行数据处理（类似推送方式）； 

4.下游系统内部处理完成后再进行日志的记录与回写。 

5分析总结 

集成底座主要是解决企业信息化建设过程中系统对接的问题，通过主数据集成和统一认证解决多系统之间系统交互、集成的难题，而通过集成底座进行系统集成，最重要的内容之一就是基础数据的同步分发，对于不同的业务系统和业务场景如果设计集成模式是保证项目顺利建设的重要环节。 

5.1场景分析 

在进行集成底座项目建设的过程中，对于实际业务场景的分析至关重要，只有充分理解客户的实际业务，才能在实际实施过程中选择合适的对接方式。在实际实施过程中，要学会灵活分析，面对客户的实际业务，要从具体的使用情况分析，虽然推送、推拉、MQ等方式都有自己的使用场景，但是也要充分考虑客户业务场景的复杂性，基于实际业务灵活控制，甚至可以采用多种方式结合来处理。 

5.2实施总结 

对于集成底座的项目，选择合适的集成方式只是整个集成方案的一个环节，而为了保证项目实施的效果，制定标准化的集成规范也是非常重要的，集成底座的标准规范不仅包括主数据的同步分发规范，同时也包括了统一认证的标准。同时，对于集成过程中不同业务系统间的字段信息、唯一标识等信息也要做好统一和规范。 

5.3个人总结 

最近参与了多个集成底座的实施交付项目，通过项目实施的过程，除了验证集成底座的实施交付模式外，对于涉及具体的业务场景，主数据同步分发的方式，统一认证配置实现的过程中，也是在不断完善集成底座产品和方案的过程。在实际项目中根据实际业务梳理集成底座的实现方式，并整理出不同场景下，集成底座的具体处理过程，并结合最佳实践和标准的对接流程，可以有效的对集成底座需要完成的内容进行整合。 

对于个人而言，熟练掌握集成底座的实施模式，熟悉不同的实际业务应该如何进行产品的交互配置是非常有必要的，在实际项目过程中，能够基于最佳实践给客户提供建议，保证实施效果的同时也能更好促进客户的信息化建设。从个人发展来说，目前大部分的项目都是与集成底座和数据中台相关的项目，掌握集成底座的实施模式无论是对后续项目的推进还是个人项目能力的提升都是有帮助的。