Siebel UCM研究

已有 1143 次阅读 2008-12-25 17:27 |个人分类:Oracle|关键词:Siebel UCM 研究

UCM的核心是处于中间的的数据模型：
实际上Siebel的UCM仍然使用CRM里的数据模型，唯一的区别是增加了SDH表结构，SDH（Source，Data，History）表结构其实是包含里Source 表和History表，是为了完成主数据管理的功能所设计的。一个非常简单问题就是，因为在复杂的主数据管理中，数据可能接受来自多个企业系统的更新甚至删除，为了追踪这些改变，就必须设计表结构来存储更改前和更改后的数据，这样就可以显示一个客户数据的整个生命周期的变化，免得有人修改了之后死不认帐：）。

UCM的设计的另一个主要的问题就是解决UCM和别的系统之间的关系的问题，所有希望和UCM通讯的系统必须首先在UCM里注册和授权，注册的时候指定源系统的名称（在UCM里的代号以及和UCM之间的通信协议），而授权就是针对于与Business Object业务对象的读，改，新增，删除等权限！

当其他系统已经注册并且被授予正确的权限后，UCM里一个非常重要的事情就是存储ID的交叉引用关系，UCM内部以UUID来唯一标记一条记录，但是因为不同的源系统ID的存储格式并不一样，为了找到匹配的源系统相关记录，UCM里就必须存储UUID和各个源系统之间的ID匹配关系。而且更复杂的，有可能UCM里的一条记录由多个源系统的多个记录组成，所以存储他们之间的关系，才能让UCM能够找到正确的记录！

主数据管理的另一个很重要的课题就是数据质量的问题，数据在引入UCM之后，必须要经过清洗，除重（如大小写，缩写），该记录的状态才能够从Queued变为Source（可以被使用），数据质量即可以通过Siebel的SDQ选项来进行，也可以选用其他第三方的数据质量的工具进行（通过使用SDQ connector）。

一旦发现有可疑的重复记录，可以采用的选项是，要么把这些重复记录的信息汇集起来形成一条更加完整的信息（merge），要么作为一条新的记录被引入！在这个过程中，主数据管理一个很自然的问题是，如果不同的系统的同一个记录的字段有冲突，以谁为准呢？

解决这个问题在UCM里是通过survivorship存活规则来实现的，就是通过评分，当确认一条记录的重复可能性很高，就可以通过预先定义的规则（比如说系统A的数据优先级别比系统B数据优先级别高）；如果重复可能性不那么高，则可以通过规定人工介入的方式进行解决，而如果评分很底，则作为一条新的记录引入。

前面已经交代了SDH是Siebel客户数据模型针对主数据管理做得数据模型上的扩展，实际上在UCM的整个解决方案中，SDH还扮演了作为外部应用和UCM集成的一个必经的数据中转站的一个角色。

在UCM的设计里，UCM和外部系统的集成是很重要的一个方面，当一个已经注册的外部系统向UCM插入新的客户数据（或者更改已经存在的客户数据的时候），一般而言都需要把数据通过某种方式先放到SDH表里，这些记录在经过数据清洗和查重之后才会被更新到客户基础表里。

一般而言，其他系统和UCM的集成有两种主要的方式：

• 数据层次：这个对于大批量的数据而言是一个很好的方式，能够提供很快的性能。
• 业务层次：业务层次主要可以做增量性的修改或者实时的修改。

Siebel UCM通过Adapter（EAI）产品和各种应用产品集成，这种集成的消息格式一般都是XML文档，Siebel Adapter从一个源系统进来的其他应用系统的XML消息被和XML转换器转换成Siebel所需要的消息格式，然后通过XML解析的方式从消息里得出各种有用的信息，这些记录会被要求先进入SDH表里，供进一步的处理！这种是通过业务层次的和UCM的集成方式。 

而通过数据层次的集成方式则是通过接口表进行，可以使用各种合适的外部工具（如Oracle sqlldr或者sybase bcp或者任何能够把数据写入到UCM接口表的方式如insert into select*）根据接口表（又称为EIM接口表）的规定格式把数据导入到接口表，然后使用EIM模块来把接口表里的数据导入SDH表,最后调用批处理程序把SDH里的数据再导入到基础表。这种则是属于数据层次的集成方式，如下图所示：

当数据进行SDH表后，就需要启动数据清洗和各种数据质量检查等规定流程，然后这些记录才能够被真正写入到UCM的基础表里（这些基础表记录着企业的“主数据”）！基于数据层次的加载适合于非常大量的数据，比如初始化UCM的时候！我们通过一个小例子里描述这个过程：

比如我们有一条客户的数据需要合并到我们的客户主数据里，则首先需要通过非Siebel的方式（比如关系数据库的工具，或者命令等）把这条数据放入EIM接口表EIM_UCM_ORG（EIM接口表名都是以EIM_UCM_*命名），然后通过调用Siebel的EIM批次任务把这条记录放入SDH表S_UCM_ORG_EXT（UCM表名都是以S_UCM_*开始），最后调用Siebel的UCM Batch Manager把这条记录放入基础表S_ORG_EXT

我们再通过一个小例子来描述SDH里的数据的变化关系：如下图

由上图可见，当存活规则认为一条记录需要和基础表另一条已经存在的记录合并的时候，图的上半部分解释了数据在经过最终的转换后基础表的相应记录会被替换成新的合并后的记录。

图的下面的部分解释了这两条记录在SDH表的变化。即在替换前原来的记录A同时也在SDH表里，但是它的原来类型属性是Source（表明是由它产生的基础表的记录），而合并之后这条为A的记录类型会变化为History表明他曾经是生成基础表相应记录的记录；而新的合并记录A’原来在SDH表的状态是Queued，而完成清洗后替换了基础表的记录后就变为Source了（表明当前它是产生基础表相应记录的记录）。

实际上，CRMML也就是一个普通的XML文档，首先是header头部分，然后是body规定的内容部分。

Header部分主要包含的关键信息是消息来源系统，如

...System123...

这个表明了消息的来源，只有在UCM里注册的消息才会被UCM处理，而body部分则包含了对于UCM处理的操作请求的描述，如：

......Test...

则代表的是一个方法，表明需要UCM插入一个新的联系人信息，>......Test...则代表的是这个方法的参数；虽然没有XML schema（或者DTD）来规定CRMML的格式，但是有效的CRMML文档包含的的确是Siebel预先规定好的一些内容，这些内容就是由Siebel系统里预先定义的integration object预先定义的。

什么是Integration Object呢？

Siebel Integration Object其实并不是属于UCM里面的概念，而是属于传统Siebel集成平台里面的概念（Siebel EAI），UCM在和其他系统交互时也延用了Siebel EAI的这个概念。
举个例子来说，假如我自己用C/java语言编一个程序，则我在我自己本系统内部的处理并不会使用XML，比如我如果要选出一个客户的信息来处理，则我在自己程序里会声明一个java对象（或者一个C数据结构）来处理客户信息，这个对象里会包含这个客户的名称，ID等各种属性值的集合（Property Set）； 但是当我需要和其他系统交换客户信息的时候，一个很自然的交换方式是我先从数据库里选出客户的信息放在我这个java对象里（可能使用某种O/R mapping），然后我通过读取这个对象的属性值来构造出一个XML文档来传给别的系统来达到交换的目的，而别的系统如果要给我的系统传数据也可以给我一个这样的XML文档，然后我解析这个文档后把相应的属性值都赋值给我的java对象，最后通过O/R mapping把这个客户的数据存在数据库里。这个java对象就是类似于Siebel的Integration Object（当然这个只是一个简单的说明），Siebel的Integration Object的功能远要比这里说得更加丰富，但是完成的最基本功能则是一样的。如下图就是一个图解的integration object的说明：

Siebel里这些预定义的Integration Object规定了CRMML能够传递的文档数据，对应于外部系统能和UCM对应的操作和操作类型。