Siebel学习资料

Siebel Fundamental (1) Overview
SIEBEL应用概述

Siebel CRM是围绕客户关系管理这个主题建立起来的一系列应用的总和，和一些国内公司的CRM/CALL CENTER产品不一样，Siebel应用远远不是只是接一些电话然后记录下来并进行处理这么简单。Siebel应用是通过统一协调管理各个联系客户的渠道（touchpoint），如email，电话，传真或者web以至于现场客户服务，从客户信息管理，销售机会管理，服务管理，主动地根据客户信息进行销售（upsales , cross sales）等，提供给公司一个全局的统一的客户视图，并提供给客户一个统一的公司视图，而建立起来的面向多个行业的客户关系管理解决方案。

Siebel的应用包含多个模块，分别面对不同的使用人员，主要分为面向客户的应用，面向雇员的应用和面向合作伙伴的应用。
下面的表格是这些应用的一个例子：
面向客户的应用:Siebel eSales,Siebel eServices,
面向雇员的应用:Siebel call center,Siebel Sales,SiebelCustomer Order Management, Siebel Employee Relationship Management(ERM)
面向合作伙伴的应用:SiebelPartnerRelationship Management(PRM),
.。。。。。。。。。另外，Siebel还针对20个行业做了很多行业定制的工作，这些定制的数据模型和术语都和那个行业相关。
如：Siebel Communications, Siebel Consumer Sector, Siebel Life Science等。

Siebel应用里基础的业务实体Siebel应用里有一些业务实体贯穿于整个应用中，这些业务实体主要是Accounts，Contacts，Opportunities，Orders，Service Requests，Households，Activities，Assets。
Accounts（公司）：公司外的业务实体，可以是潜在的客户，竞争对手等。
Contacts（联系人）：和公司有生意往来的人，一般都有一个名称，职位，电话号码。
Opportunities（机会）：一个可以带来利润（revenue）的事情，一般会和一个account相联系，并且会有一个完成日期。Orders（订单）：客户购买的一个产品或服务，一般有一个订单号，订单状态，并且和一个account相联系。
Service Requests（服务请求）：一个客户请求，可能请求一些产品信息或服务信息。
Household（集体成员）：有某种经济联系的一些人的集合，他们可能有共同的采购行为或者兴趣。一般有一个名称，一种成员类型（如妻子，孩子，小组成员等），集合体的联系人，并且有专门的用于负责这些人的雇员。
Activities（活动）：一个需要完成的事件，一般有起始日期和预计完成日期，优先级别，和负责的雇员。
Assets（资产）：一个已经被采购的产品，一般有一个资产号码，一个产品代码，和产品当前使用状态（如在用，废弃等）。

Siebel Fundamental (2) Architecture Overview
SIEBEL技术体系概述

Siebel在被Oracle收购之前本身没有太多技术平台产品，所以Siebel的技术体系主要是建立在第三方技术平台之上，Siebel的主要体系架构是典型的web server/Applications Server/Database Server的三层架构。下图是Siebel的一个简化的架构图：

Siebel应用的技术主要包含三个部分：
1. Web Server：从浏览器接受请求，并把请求发给Siebel Server，
从Siebel Server得到结果，再发回给浏览器。
2. Siebel Server：是Siebel应用的主要技术部件，不但用于支持完成和客户端的交互（从数据库取得数据并返回给Web Server，从Web Server接受请求并处理），还需要处理工作流和业务自动化流程，以及一些批量执行的任务（熟悉Oracle Applications的用户可以大致认为和Concurrent Manager执行的任务一样）
3. Siebel Gateway Name Server：类似于一个动态注册表，用于跟踪所有Siebel进程的状态。如果有Server起来或关闭，都会在Name Server更新状态。
4. Siebel File System：用于存放Siebel应用用到各种文件。
Siebel 技术体系架构有一些明显的特点：
1. 满足多渠道的访问的需求，无论是对于浏览器用户；对于通过手机访问的用户；还是对于暂时无法访问网络的用户但是又需要访问一些特定信息的用户；甚至对于需要专门访问的DBA管理用户，都在技术结构上提供了不同的访问模式。
2. Siebel的技术架构另一个重要的特点是能够跨多种产品和底层技术平台，如可以使用多个不同厂家的Web服务器（流行的如Apache，IIS），可以使用不同厂家的关系数据库（Oracle，DB2，SQLSERVER）等，这都要求Siebel能够在不同的技术框架上提供一个虚拟的访问层。
多渠道访问的架构设计
Siebel从架构层就包含了多渠道访问的思想，如下图：
访问渠道主要包含：
1. Siebel Web Client/ Siebel Wireless Web Client：标准三层架构访问模式，客户端没有任何Siebel软件，而只有浏览器（或手机浏览器）。PC客户通过浏览器和Web Sever并最终通过SWSE和Siebel Server交互。而手机用户通过WAP Server并一样通过SWSE和Siebel Server交互。绝大部分用户都使用这种访问模式。
2. Siebel Handheld Client/ Siebel Mobile Web Client：这种方式的访问方式和三层架构不一样，这种方式要求在本机按照类似于一套mini版本的Siebel应用，访问本机的数据库和File System。使用这种方式的时候，联机的时候本机数据库可以和中心数据库进行同步，而脱机的时候仍然可以访问自己机器上已经同步的内容，适合于经常没有网络连接的环境（如机场，火车站等）但又需要访问Siebel应用的场景。
3. Siebel Dedicated Web Client：这种客户端能够直接访问数据库，即使在Siebel Server已经被关闭的情况下，一样可以访问Siebel应用，原因是这种客户端本身就安装有Siebel Server的部件，不需要通过中心的Siebel Server来访问数据。
Siebel架构里中立于技术平台产品的设计
Siebel应用为了屏蔽底层技术的影响，而对维护人员提供统一的界面，主要在以下的部件里来提供中立于底层技术产品的设计。1. Siebel Web Server Extensions（SWSE）：Siebel是通过在第三方的Web Server上加入一个插件，称为SWSE来和Siebel Server进行统一的通讯。从而能够独立于Web服务器而提供和Siebel Server统一的接口。
2. Siebel Server的AOM(Application Object Manager)，AOM里包含Data Manager，用于针对不同的关系数据库生成包含该类型数据库特点的SQL语句，这样就可以在AOM之上提供屏蔽下面特定数据库技术的，中立的数据访问层。

Siebel Fundamental (3) Security and Acess Control

SIEBEL安全架构
Siebel应用的安全主要包含用户的认证，数据传输的加密，数据存储的加密，以及应用，数据访问控制。用户的认证主要指用什么方式来校验用户和密码；数据传输的加密主要指的是Web传输的加密，SWSE和Siebel Server的通讯加密；数据存储的加密是Siebel可以选择加密数据库的某些关键字段，但是并不影响Siebel应用的用户，由Siebel应用在存储和使用的时候自动加密解密；而应用，数据的访问控制则是Siebel里比较复杂的，和一个企业的组织结构相关的话题。
用户认证Siebel的用户认证方式较多，可以直接使用数据库用户密码认证，企业目录用户认证，SSO认证等。
如下图：

数据库认证：Siebel可以使用数据库用户/密码来验证用户的登录，对于这种认证方式的好处是不需要额外的安全基础措施（如LDAP），但是如果使用这种方式，就需要在数据库级别为每个用户创建用户和密码。

AD/LDAP认证：Siebel应用也可以使用工业标准的目录服务器来认证用户，比如微软的AD或其他符合LDAP规范的服务器，如果企业本身已经有目录服务器，则Siebel应用可以很好地集成目录服务器的认证机制。

使用web-SSO验证：Siebel应用提供了可配置的配合web-SSO单点登录基础设施的框架，可以使用多种SSO服务器提供的认证功能。 Siebel Security Adapter SDK：使用Siebel提供的SDK可以开发出不属于以上所提到的几种方式的用户认证方式。

Siebel组织架构
Siebel应用的应用／数据访问控制和Siebel应用的组织架构设计相关，所以首先需要介绍Siebel应用界面的一些基础概念：Screen，View以及Siebel组织结构的基本概念Division，organization，position，responsibility和employee。

Screen（屏幕）是指Siebel应用里一组相关的功能或主题提供的一个tab，如下图：
accounts就是一个screen，而View则是完成该主题里一个特定的任务的具体菜单项，如Accounts List则是一个View，而通过这个View能够看见的东西则称之为数据（data）。视图和数据的权限是完全分开控制的。比如两个call center话务员Mary和Lisa，她们可能具有相同的职责（所以他们能够看见相同的View），但是每个人只能看见自己的那份数据（data是由他们的ID控制）。而他们的Manager则可以看见Mary和Lisa两个人的数据（数据由organization组织架构决定）。

Division和Organization和我们平常所见的公司结构图里的分支和部门是一样的概念，其实建立Division和Organization的方法一样，只不过要在建Division的时候选择一个checkbox指定该Division为Organization。但是Organization和Division也有区别，他们都可以用于来设置公司组织架构的层次，但是如果希望不同的Organization不能够互相看见对方的数据进行数据的控制，需要对数据进行控制的话，则要使用Organization。

职位也是一个公司组织结构图上的一个小方块，用于组成公司的上下级汇报关系，一般一个职位只有一个雇员，当然有时候一个职位可以有多个雇员。而且因为职位远要比雇员要稳定（雇员很可能离职），所以职位的访问控制在企业的很多场景里提供了恰当的数据访问控制方式，，而且使用职位进行访问控制比之使用雇员进行权限控制有更大的稳定性。
Responsibility则是企业里某次功能的集合，这个集合通常赋予一个工作岗位，（从Siebel应用的角度来说，就是一组View的集合）。

应用／数据访问控制
Siebel提供的两种主要的访问控制方式在View级别和Data（record）级别：

1.
View级别的访问控制：一个企业通常按照功能进行工作的区分，分配给一个用户的功能决定了他能够访问Siebel应用的功能（在Siebel应用里称之为View，类似于一般应用的菜单），一个用户通过授予他的职责从而能够访问的功能的集合，这种应用的授权方式是通过View来进行的。如一个销售代表通常能够看见My Contact View，My Opportunities View等，而一个Call Center Agent却只能看见My Service Request View。这些都是通过Responsibility授权而得到View的权限的例子。

2.
记录（数据）级别的访问控制：记录级别的访问控制使用户能够Siebel使用三种数据访问控制，position，organization，access group：当一条记录被赋予position，organization，access group权限时，只有那个职位，组织，或访问组的雇员能够看到该数据。下面只通过position来说明数据的这种访问控制，同样对于Organization也是类似的。Position Access Control也有好几种，我们只选取其中一种来说明：
single-position access control:如报价信息，一个使用某种职位登录的雇员只能看见该职位能够看见的报价信息（一个更高职位的雇员可能可以看见更高的折扣，所以每个职位的报价信息是不一样的）。不同类型的数据可以采取不同的数据访问控制方式，如客户相关数据可能更倾向于采取position相关的权限控制。
能够使用什么控制方式和Business Component（BC）相关，是由该 BC的View Mode决定，比如一个想使用position access control的View必须是该View对应的BC里ViewMode的OwnerType里有position一项，我们会在后续的文章里介绍BC。

Siebel Fundamental (4) Applications Data Structure
应用数据的存储和展现
一般而言，一个应用都包含了关系数据库里的数据以及处理该数据的应用界面。一个简单的应用可能是使用一些可视化的工具把数据库里的数据拖动到应用里就可以完成数据的存储展现以及操作的工作，这样出来的应用展示和数据是紧密耦合的，而Siebel应用则使用了更加复杂的通过在中间增加几个层次从而能够把数据的展现和数据的存储隔离开，并且在这个隔离层里引入了可使用Siebel Tools进行展现和下层数据间的匹配关系。这样提供了很强的容易进行进行客户化的方法。使界面的显示定制和数据存储都更加灵活。这个隔离层就是我们要介绍的Business Object（BO），Business Component（BC）相关的一些概念，当然BO和BC的引入的另一个非常重要的优点是可以使关系数据以一种具有业务含义的方式组织和展现出来给不同层次的用户。

Siebel应用数据的层次
在Siebel应用里数据在多个层次上使用了不同的定义方式，每一个层次侧重于数据的不同的特征，主要分为数据用户界面层定义（UI），业务逻辑层定义（Business Layer，可以认为是业务含义层）以及数据存储层定义，如图：

UI展示层主要定义用户界面接口，它包含的主要对象是我们以前已经交代过的Screen，View以及Applet（View里当前显示的部分就是一个Applet，而不是JAVA里applet的含义，可以是当前View的数据的列表或者当前某一条记录的详细的FORM展示），展示层也分为两个部分，展现部分是一个HTML的模板，它的定制可以通过一个HTML编辑器进行CSS，公司图片等各种HTML元素的客户化，而UI定义层则和逻辑层和数据层一样，都是使用Siebel Tools进行定义。数据存储层定义主要定义数据存储的逻辑结构，主要以表和列的形式来体现，在这层同时还屏蔽了不同厂商数据库的差别，从而对业务层提供一个统一的数据视图，一个典型的例子就是，在Siebel的数据结构完全不使用特定关系数据库的约束方式，而是在Siebel Tool里进行各种关系的建立，比如主键约束使用了自己的一个rowid，而不是使用关系数据库的通常的主键的定义，Siebel Tools的输出是一个*.srf(Siebel Repository File，也就是被编译后的UI/BOBC/DATA的定义文件)文件，由AOM来使用。
业务逻辑层是Siebel应用里最重要的一个部分，主要包含Business Object（BO）和Business component(BC)，在这一层需要把下层的关系数据以一种业务容易理解的形式（如账户信息BC）提供给上层消费者。熟悉BIEE的用户可能会发现，Siebel应用也使用了类似于BIEE里结构分层的定义方式（物理层，逻辑业务层，展现层等），这种特点还是比较Siebel的：）
。
数据结构层次
整个Siebel的数据的层次结构分为三个层次，每一个层次都对应了下一个层次的相应的元素，一个层次的改动不影响另一个层次的稳定性，一张表现他们层次的经典图如下：可以看到，一个BC其实对应的就是一个逻辑的表（可以是一个基表也可以是几个关联的表的一个逻辑的表），BC里的field就是对应了数据表的列，多个相关主题的BC则组成了BO前面的文章已经交代了View，Screen等屏幕元素，这些屏幕元素和BC,BO也存在一定关系，从BO和BC的观点来重新定义这些概念就是，View其实对应的就是一个BO，而Applet则对应着一个BC，所谓Control则是屏幕上对应于关系数据字段的显示。多个相关的View则组成了一个Screen，而多个相关的Screen则组成了一个Siebel应用（如Call Center应用）。
需要注意的是一个BO需要有个一个主要的BC（该BC表示了自己关注的业务实体），如下图：

Siebel Fundamental (5) Business component & Business Object
Business Component（BC）和Business Object（BO）
个人觉得Siebel应用架构的一个成功的地方就是在应用里引入了BC，BO的概念，从而使得几千张关系数据表能够按照业务的含义组织成业务对象，对于业务人员而言具有了业务上的含义，而不仅仅是从技术人员的观点来对待数据（就是关系表而已）。

Link：BC之间的关系
对于关系表之间的关系,如主外键关系，从业务的BO观点来看则是BC之间的关系（请注意，不是严格的一对一，并非是一个关系表的外键一定会组成BC间的关系）。因为一个BO总是由一个主要的BC以及和它相关的一些BC组成，而主要的BC总是以一定的关系和附属的BC关联，这种关系就称之为Link，如下图：
我们已经交代过一个View展现的就是一个BO，而BO是由一个Master BC和相关的一些子BC组成，如果不存在Link，则子BC的所有数据都会展现出来，而建立了Link之后，就只有和Master BC选定的记录相关联的数据才会展现出来。这些关系可能是：

1：1关系：一对一的关系很多是用在Extension表上，Extension表的后缀名通常为_X（Extension表是Siebel里常见的一种表，一般Siebel业务的基础数据存储在Base表中，然后把一些扩展的数据和一些可以客户化的字段（attribute字段）放在Extension表中，从而给不同行业，不同场景提供了一个扩充性很强的数据模型。）

1：M关系：一对多的BC关系一般用于Master-Detail的业务场景，比如一个Account以及该Account已经购买的产品就是一个Master-Detail关系。这种关系类似于关系表的主键外键关系，这种关系在Extension表上也存在，通常后缀名称是_XM。

M：M关系：多对多的关系是通过一个叫做交集表（Intersection Table）体现出来的，两个BC之间没有主外键关系，但是每个BC和该交集表有主外键关系，如下图：
多对多的关系通常表达的是值对（value pair）的关系，如上图表示的是公司-行业的值对组合。
Party Business Component
Party BC大概是Siebel里最基础的BC了，Party BC包含了个人相关实体，组织相关的实体，以及访问控制组等为了一定的目的建立起来的一些组织。如下图：
Party BC基表是S_Party，但是和一般的BC不一样的是，作为基表的S_Party本身存储很少的数据，主要是Party的名称，Party的类型（是contact，employee还是account等），而更多Party相关的数据都存储在Extension表里，如S_CONTACT，S_USER等（比较特殊的是这些Extension表的结尾并不是使用*_X来命名）；此外，这些extension表的extension表（如S_CONTACT_X）本身也算是S_PARTY的Extension表，这个也是Party BC的一些特殊的地方。下图是一个很好的表达了Party的访问控制组的图：
rowid为1的行的party类型是User List，所以这一行数据相关的信息应该存储在S_USERLIST extension表里；而rowid为2的行的类型是Access Group，所以该行数据的额外信息应该是在表S_PARTY_GROUP extension表里等等。这个就是一个Siebel里的一个扩展性非常强的数据模型的一个例子。
—————————-
Siebel,在Oracle的白皮书中,初识结构。
Siebel,在Oracle的白皮书中有写到：Siebel architectrue supports a mixture of clients.
与以往的c/s(client/server),b/s(browser/server)不同的是，Siebel 支持多种结构，比如我们用vb,vc,delphi,pb等开发工具开发的一下应用程序，我们会需要在客户短安装一个客户端程序，这也就是我们所谓的胖客户端。然后对于用过oracle erp的人来讲，我们经常看到ebs是只通过一个浏览器就能够连接上我们的系统去做相应的业务操作而不需要安装任何客户端程序的，这也就是我们所谓的瘦客户端，b/s结构。那么我们的Siebel是哪种结构呢？
我们刚刚讲到Siebel是多种结构的，那么我们先来看看它是如何支持多结构的。
1。Siebel Wireless Webclient ->wap server ->siebel gateway server->siebel server(enterprise)->database server/siebel file system.
2. Siebel Web Client browser->web server->siebel gateway server->siebel server(enterprise)->database server/siebel file system.
3.dedicated web client->database server/siebel file system.
大概来讲解一下这几种方式：
1。第一种就是直接用browser来连接我们服务器的。这种情况我们就是在客户端什么都不用装，只要在客户端浏览器上输入服务器的地址就能进入我们siebel系统去进行相应的业务操作:比如在ie 上输入http://127.0.0.1/callcenter_enu?… l登入页面输入sadmin /sadmin即可登陆系统。
2。第二种也就是通过我们安装的siebel web client 选择开始－>程序->siebel client web->siebel call center enu.然后登陆我们界面。
那么我们第一种与第二种有什么不同呢？主要是在第一种里面我们是siebel在web server中扩展了一个wap，然后再是wap server 与gateway server 再与siebel server通讯，而我们第二种方式是siebel client与siebel server再与siebel server 通讯。
3.第三种呢是直接与siebel database通讯。这种方式主要是我们通过siebel tools连接到数据库种做相应的操作。

 

文章来源：http://www.oraebs.com/?cat=7