IPOC集成底座关键点梳理

企业的信息化建设是伴随企业发展不断延伸、不断升级的过程,而随着信息化体量的不断增大,复杂繁多的业务系统往往又成为信息化建设的瓶颈。为了消除瓶颈,更便捷地打通系统的关联,针对企业实际业务建立集成底座平台则是非常有效的方式。通过集成底座打通各业务系统,实现系统的对接,对于整体的信息化建设以及后续多系统的数据整合都是非常必要的。

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

总体说明

由于项目和工作需要,最近开始接手集成底座POC的环境,所以对集成底座的内容进行了梳理,针对集成底座的方案模式、实现方式、业务流程等进行了明确,并与相关项目结合,明确了后续项目的实施方式。

1.背景介绍

最近接手了公司集成底座POC的相关环境,所以基于POC环境以及最近几个集成底座项目的实施情况,对集成底座的相关内容进行了梳理。集成底座是基于公司IDM、MDM、ESB三款核心产品组合而成的解决方案,主要是用于搭建企业信息化集成底座,满足业务系统集成的需要,实现业务系统的统一认证、主数据治理,从而为后续深度的信息化建设和系统升级提供全面的支撑。

2.集成架构

集成底座主要包括:IDM统一身份认证平台、MDM基础数据管理平台、ESB企业服务总线三款核心产品,并通过UMC云管理平台进行部署维护。整体架构图如下:

各个业务系统作为源头提供基础数据,包括组织、岗位、人员等,基础数据通过ESB同步至MDM主数据平台进行管理维护,并进行数据清洗,保证基础数据的准确性、唯一性,MDM将治理后的组织、岗位、用户(人员的部署属性)分发至IDM平台进行管理,用于支持统一认证和统一权限等业务,同时将各类基础数据分发至其他下游业务系统。IDM接收MDM分发的数据后,将用户数据分发到下游系统用于保证各系统用户的一致性,以实现统一认证,同时IDM支持手动建立虚拟用户,并将虚拟用户分发下游系统完成统一认证。

3.产品清单

1.IDM统一身份认证平台:基于5A(统一用户、统一认证、统一授权、统一审计、统一应用管控)管控的安全平台,搭建企业的统一认证中心,实现访问入口的统一,从访问层面打通系统关联。

2.MDM基础数据管理平台:实现企业主数据的全生命周期管理,实现基础数据同源,保证各业务系统基础数据的一致性、完整性和准确性。

3.ESB企业服务总线:实现IDM、MDM以及上下游系统打通的集成工具,通过服务治理、服务集成实现对各业务系统API的管理,并基于API建立集成流程,实现系统间服务对接,满足主数据实例、统一认证的集成需要。

4.需求说明

对于集成底座内部而言,MDM的作用主要是满足集成底座各系统集成时的基础数据同步,主要包括组织、岗位、人员的统一治理,为IDM的统一认证、统一权限等提供支持。

在实际项目中,MDM也可能会作为主数据治理平台进行主数据治理,如客户、供应商、会计科目、产品、物料等。通过ESB实现从不同业务系统同步到MDM,再由MDM统一进行分发,保证各个系统具有同源、唯一的标准主数据。

1.数据同步:以HR为源头,将组织、岗位、人员数据同步至IDM平台的基础数据管理中;

2.权限同步:在IDM平台配置SMC的功能菜单以及角色信息,通过手动同步的方式将权限数据同步至SMC,权限同步主要是角色(标注角色、实际角色)同步以及组织、人员、角色权限同步。

3.数据同步:以ERP为源头,将客户、供应商、银行账号数据同步至MDM平台的基础数据管理中,并在同步完毕后将成功信息回调至财务系统中;

4.以财务为源头,将会计科目、核算项目的数据同步至MDM平台的基础数据管理中,并在同步成功后信息回调至财务系统中;

5.数据分发:以MDM为源头,将组织、人员、物料、产品对ERP和财务系统进行数据的下发,下发至财务系统和ERP后回写相应的分发日志;

6.ERP的客户、供应商、银行账号同步至MDM中后,将数据下发至财务系统中,并在分发完毕后回写相应的分发日志;

7.单据推送:收款单或付款单通过ESB进行数据的映射写入到财务系统的应收单或者应付单中,最后将成功或失败的信息回写给ERP系统;

8.凭证集成:收款单和付款单在ERP系统中,生成凭证,通过数据映射将凭证信息同步至财务系统中,待同步完毕后,将成功或失败的信息回写给ERP系统。

场景规划

对于集成底座,主要是实现IDM+MDM+ESB方案组合的落地,主要包括两方面内容:一方面是IDM认证的对接实现,另一方面是数据在MDM和IDM中的业务流转,通过集成底座,实现各个系统单点的实现,以及完成对接系统主数据的统一。

1.统一用户

通过IDM平台实现用户的统一管理,用户不同于人员,一般用户是人员的部分属性,用户和人员之间存在交叉,但也存在差异,一般企业内部人员都是用户,但是由于系统访问、业务处理的需要,会建立一些虚拟用户或测试用户,如收银员、置业顾问、测试管理员等,所以通过IDM统一进行用户管理,并将需要实现统一认证的用户下发到不同的系统。

2.统一认证

统一认证主要通过IDM平台实现,基于IDM的统一用户,IDM提供了CAS、OAuth等不同的认证方式,能够支持不同系统、不同场景下的认证需要,支持移动端、PC端、桌面端等使用需求。在集成底座方案中,IDM、MDM、ESB产品的统一认证采用了CAS认证形式。在进行其他系统集成时,建议采用OAuth认证,减少对业务系统的侵入。

3.统一权限

IDM的统一权限是IDM 5A管控中的一部分,通过在IDM平台配置其他系统的页面、控制器、接口等资源,由IDM平台对相关资源进行授权操作,再由ESB将权限数据分发到不同的系统,从而实现在IDM平台集中管理权限。

4.数据治理

通过MDM实现组织、岗位、人员等人力相关主数据的统一管理,源头系统将基础数据通过ESB推送至主数据平台,主数据平台进行集中清洗、管理、维护,保证数据的准确性,同时结合MDM内置的BPM工作流以及ESB应用集成流程,实现将基础数据分发到下游系统,从而实现各系统集成基础数据的一致。

5.业务集成

主要基于ESB的业务集成,通过ESB+MDM预置样例的演示说明ESB对业务集成、单据对接的便捷支持。

1.通过ESB设计器创建ESB+MDM预置样例,演示样例的内容,以及实现的相关业务场景;

2.支持通过ESB实现系统间业务单据的传输、财务单据、凭证的集成等;

3.基于ESB设计器的服务开发,以及ESB相关组件的快速介绍,配置式开发,支持代码扩展、断点调试;

4.在单据集成的过程中,和MDM的主数据治理进行结合,通过MDM保证不同系统间基础数据的一致,从而保证业务单据关联的准确性。

预置数据

为了保证本次预置样例的功能可以正常使用和测试,需要在数据库按照规范预置一些数据,下面由数据表定义、数据表结构、命名规范化、数据规范化等方面进行介绍。

1.数据资源

数据结构主要是指在服务生成或者组件操作时读取的数据库,而本章主要对用到的数据库表进行介绍,并对表结构进行说明,数据库表清单如下:

2.角色清单

3.命名规范

1.数据表的命名规范

(1)采用英文字母(区分大小写)和数字、下划线组成,命名简洁明确,多个单词用下划线“_”分隔;

(2)首字母全部小写命名,禁止出现大写;

(3)表名称不应该取得太长(一般不超过三个英文单词);

(4)表的名称一般使用名词或者动宾短语;

2.表字段的命名规范

(1)禁止使用数据库关键字,如:name,time,datetime,password等;

(2)采用英文字母(区分大小写)和下划线'_'组成,命名简洁明确,多个单词用下划线“_”分隔;

(3)采用字段的名称必须是易于理解,一般不超过三个英文单词;

(4)在命名表的列时,尽量不要直接引用表的名称。例如,在名employe的表中避免使用名为employee_lastname的字段;

(5)不要在列的名称中包含数据类型;

(6)表中字段是另外一张表的主键,则尽量引用另一张表的主键字段,体现关联关系;

3.数据动态模型属性的命名规范

(1)属性定义时见名知意,每个不同的动态模型加上前缀(一般为当前模型的小写缩写);

(2)属性命名加上前缀后采用驼峰命名法,如:userId。

4.数据规范

(1)保证id的唯一性,本次方案采用大写UUID的生成策略,便要保证每个数据都是单独生成的;

(2)保证数据的完整性,每个表中不为空的重要数据都要预制完善,不影响操作;

(3)保证表中数据的关联,例如当人员表的组织ID关联组织表时,预置数据时便需要将两个字段保持一致。

服务模型

本章主要对设计器端的预置基础样例进行整体设计说明,包括SM模型的创建、WS服务的创建以及具体流程的编排,其中重点包含服务工程与映射转换组件与各个场景的合理编排,具体内容如下。

1.SM模型

ESB企业服务总线的模型主要包括两类,动态模型以及JavaBean静态模型对象,JavaBean对象是在设计器配置,可以基于数据库、XML以及SQL等方式进行配置,而动态模型则是通过SMC管理控制进行创建,并在设计器端引用使用即可。

> > > >动态模型

动态模型是通过SMC平台配置JSON数据来生成数据模型,可以流程内进行调用进行数据格式的映射转换等操作,本次IPOC集成底座工程设计的动态模型如下:

> > > >静态模型

静态模型是通过设计器创建JavaBean对象生成对应的Java实体类,可以流程内进行调用进行数据格式的映射转换等操作,本次IPOC集成底座工程设计的静态模型如下:

2.WS模型

本次WS服务创建主要包含两类服务,WebService以及RestServcie,本次服务创建包括基础数据、业务单据、统一权限部分,服务的创建直接基于数据库创建即可。

> > > >Rest模型

> > > >Web服务

基础数据管理

MDM作为基础数据管理平台,主要是通过数据建模、数据维护、数据质量、数据分析等进行基础数据的维护,保证各个系统基础数据的同源。在集成底座的方案中,MDM除了对组织、岗位、人员等基础数据进行内部集成与统一外,在实际项目中可能会基于实际需求进行其他类主数据的治理。

1.功能作用

对于集成底座内部而言,MDM的作用主要是满足集成底座各系统集成时的基础数据同步,主要包括组织、岗位、人员的统一治理,为IDM的统一认证、统一权限等提供支持。

在实际项目中,MDM也可能会作为主数据治理平台进行主数据治理,如客户、供应商、会计科目、产品、物料等,通过ESB实现从不同业务系统同步到MDM,再由MDM统一进行分发,保证各个系统具有同源、唯一的标准主数据。

2.集成场景

MDM的集成场景也是同步、分发两部分,同步主要是源头系统同步基础数据到MDM,分发是MDM将清洗后标准主数据分发给下游系统。集成流程如图:

1.源头系统将基础数据推送至ESB平台,ESB通过数据转换构建标准入参,在调用MDM的接收接口将数据写入MDM平台;

2.MDM接收数据后根据分发需要进行任务生成(自动或手动),再将任务ID发送到ESB或业务系统;

3.在实际项目中,可能两种方式并存,如果发送至ESB则由ESB进行MDM的数据获取与转换,在分发下游系统(如分发IDM);

4.如果MDM将任务ID直接发送业务系统,则由业务系统自行完成MDM的数据获取与写入工作。

3.流程实现

ESB流程图参考如下:

1.源头系统同步MDM:

注:为了实现源头系统的异步返回,可以通过MQ组件进行异步处理,先直接给源头系统返回值,再通过MQ写入MDM。

2.MQ实现MDM写入:

3.MDM分发下游系统:

身份认证平台

IDM平台主要实现5A管控,在集成底座方案中,IDM平台主要完成统一用户和统一认证,为了验证产品和相关功能,在POC环境中也添加的统一权限的处理。

1.功能作用

在集成底座方案中,IDM主要是满足5A的需要,一般会根据实际项目需要选择5A中部分内容实现,但至少要包含统一用户和统一认证。

1.统一用户:将MDM平台的人员同步到IDM作为用户信息,同时支持在IDM平台手动建立虚拟用户、测试账户等,并通过ESB平台将用户信息分发到下游业务系统,从而保证各系统用户的一致性,为统一认证的实现提供支持。

2.统一认证:IDM提供CAS、OAuth方式的认证机制,同时产品预置有认证接口,可以针对不同的业务系统提供标准的认证模式,从而快速实现业务系统的单点登录,提供统一访问入口,提高系统访问的便捷性,同时支持不同级别的安全加密策略,保证系统访问的安全性。

3.统一授权:统一授权主要是对业务系统功能权限的统一管理,在IDM平台将业务系统的控制器、接口等资源进行注册,配置相应的角色权限,再将权限下发业务系统,从而控制下游系统的权限。

4.统一审计:主要是基于IDM平台的监控、统计、分析等功能实现安全管控,包括对登录用户、登录IP、访问情况、同步分发情况等进行监控分析。

5.统一应用管控:在IDM平台中注册业务系统信息,配置业务系统的访问策略、访问地址、认证策略等,从而实现业务系统的集中配置。

2.集成场景

IDM的集成场景主要是同步、分发,一般从MDM分发组织、岗位、用户到IDM,IDM分发用户到下游系统,集成场景如下:

1.IDM的组织、岗位、人员数据来源于MDM平台,MDM平台通过推送任务ID到ESB企业服务总线,ESB基于任务ID调用MDM的获取数据接口获得数据;

2.ESB将获取的主数据进行转换处理,再调用IDM的接收接口同步至IDM平台;

3.IDM基于推送的数据将需要分发的数据生成任务(如人员),并通过内置的BPM将任务ID推送给下游系统;

4.下游系统获取任务ID后,调用IDM接口查询数据,再将查询到的数据写入系统中;

注意:根据实际项目情况,有时IDM分发需要先将任务ID分发给ESB,ESB通过调用IDM接口获取数据,再将转换后的数据直接推送下游系统。

3.流程实现

ESB流程图参考如下:

1.MDM基础数据分发IDM平台:

2.IDM用户分发的BPM流程:

3.IDM用户分发流程:

企业服务总线

在集成底座方案中,ESB一般是作为服务总线存在,通过ESB的API管理进行各业务系统的服务注册以及参数配置等,再基于应用集成配置集成场景,进而通过ESB设计生成集成流程实现数据的同步分发。

1.功能作用

ESB企业服务总线根据功能一般可以作为服务总线和数据总线:

1.服务总线:包括应用集成和API管理,主要满足跨系统的业务集成,最佳实践是通过API管理注册业务系统服务,满足服务治理、代理、鉴权、导出、统计分析、服务监控的需求,而应用集成以支持MDM、IDM产品之间的数据同步分发、统一认证为主,集成底座就是典型的服务总线模式;

2.数据总线:数据总线包括数据集成和文件传输,主要实现数据的抽取同步、清洗转换、加工汇总,典型应用场景就是ODS、数仓的数据汇聚。在数通畅联的方案体系中,数据中台方案ESB应用的就是数据总线模型。

2.集成场景

在集成底座方案中ESB主要是通过API管理、应用集成、服务治理等方式实现业务系统、MDM平台、IDM平台的集成,包括基础数据集成以及统一认证等,所以ESB的应用集成更多是ESB中API的注册,以及集成场景配置。

3.流程实现

服务注册:

参数配置:

集成场景:

心得体会

集成底座是基于公司IDM、MDM、ESB三款核心产品形成的组合方式,是基于实际项目的经验积累的实施模式和策略,它和数据中台相辅相成,共同构建了目前主推的技术解决方案,同时也涵盖了公司的全线核心产品。

1.产品方案

集成底座的方案主要面向企业进行基础的信息化建设,通过主数据治理和统一认证打通业务系统的壁垒,一方面实现业务系统的初步互联互通,实现统一的登录入口和访问页面,将各个业务系统逐步整合;另一方面通过主数据治理实现各业务系统基础数据的贯通,实现基础数据的一致,为后续业务的深入集成、数据治理、数据分析奠定基础,也就是数据中台的解决方案。所以说集成底座和数据中台二者相辅相成,共同支撑企业的信息化建设

2.业务总结

最近也参与了多次集成底座的项目,根据实际项目以及公司内部POC的情况总结,相比于内部POC,实际项目中的集成场景会相对于更复杂一些,因为在项目中不仅需要考虑集成底座产品的整合,更多的是要和业务系统集成,要更多考虑业务系统的实际情况,包括集成模式的选择(推送、推拉)以及数据的处理(格式转换、字段映射、数据计算等),所以目前集成底座的相关产品已经在预置接口,通过预置数据和接口自动实现集成底座内部产品的集成。

3.个人总结

通过最近参与集成底座的项目,在项目中不断深入了解产品,同时将方案和内部POC的验证进行结合,这些项目工作在磨练工作经验的同时,对于集成底座在实际项目的使用以及后续项目中如何快速推进落地的策略有了更多的认知,在后续实施集成底座项目时可以有更多的发挥空间。同时伴随着产品不断预置集成场景,后续的项目和实施交付也会变得更加容易。

在后续的工作中,集成底座方案会在更多的项目中应用。在应用过程中要加强思考,从项目实施、培训、交付等多个角度思考,不断结合实际业务,不断深化对集成底座的了解,为后续工作提供更多的帮助。

本文由@数通畅联原创,欢迎转发,仅供学习交流使用,引用请注明出处!谢谢~

举报
评论 0