SIEBEL应用概述

原文地址:http://bbs.erp100.com/thread-44401-1-1.html

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应用里基础的业务实体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传输的加密,SWSESiebel 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应用界面的一些基础概念:ScreenView以及Siebel组织结构的基本概念Divisionorganizationpositionresponsibilityemployee

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

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

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

应用/数据访问控制
Siebel提供的两种主要的访问控制方式在View级别和Datarecord)级别:

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

2.记录(数据)级别的访问控制:记录级别的访问控制使用户能够Siebel使用三种数据访问控制,positionorganizationaccess group:当一条记录被赋予positionorganizationaccess group权限时,只有那个职位,组织,或访问组的雇员能够看到该数据。下面只通过position来说明数据的这种访问控制,同样对于Organization也是类似的。Position Access Control也有好几种,我们只选取其中一种来说明:
single-position access control:如报价信息,一个使用某种职位登录的雇员只能看见该职位能够看见的报价信息(一个更高职位的雇员可能可以看见更高的折扣,所以每个职位的报价信息是不一样的)。不同类型的数据可以采取不同的数据访问控制方式,如客户相关数据可能更倾向于采取position相关的权限控制。
能够使用什么控制方式和Business ComponentBC)相关,是由该  BCView Mode决定,比如一个想使用position access controlView必须是该View对应的BCViewModeOwnerType里有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连接到数据库种做相应的操作。
(您有什么疑问?请多指教。下一节siebel web client )的安装

=========

首先向大家介绍一下siebel 吧。

siebel 是一个crm (客户关系管理软件),但它不单单是一个软件而已,它可以为客户提供提供系统的客户关系解决方案。

这里我主要学习的是它的二次开发,对功能方面的一些东西还不算很了解,望大家原谅阿。

siebel 二次开发的工具是siebel tools

它的客户应用端程序是 web client .(siebel call center ,siebel sales ,siebel enployee relationship management administration,siebel markting ,等等)

siebel 7.7的 中文版的 bookshelf关于workflow的详细介绍。 目录: 第 1 章:本版本的最新资讯 第 2 章:Siebel Business Process Designer 概述 工作流程的一般原则 15 了解工作流程过程模块 16 了解工作流程规则模块 18 工作流程角色 20 第 3 章:工作流程过程简介 工作流程体系结构概述 21 工作流程的设计时体系结构 22 工作流程的模拟体系结构 23 工作流程的部署体系结构 25 工作流程的运行时体系结构 26 与其它 Siebel 组件的工作流程交互 29 第 4 章:计划工作流程过程 为工作流程过程计划收集信息 31 了解工作流程过程要求 32 植入的工作流程过程 32 在计划工作流程过程时考虑业务对象和业务服务 33 为业务对象定义主要业务组件 33 为工作流程过程启用业务服务 33 为工作流程过程定义测试和迁移策略 34 验证工作流程规则安装 34 验证工作流程规则安装的库设置 34 验证工作流程规则安装的工作流程设置 35 第 5 章:适用于开发人员:建立工作流程过程基本知识 开发工作流程过程的概述 37 Siebel Tools 和工作流程过程 38 使用 Siebel Tools 中的过程设计器 40 关于过程设计器的设计功能 40 字段说明:“工作流程过程”子视图 41 字段说明:“工作流程过程属性”子视图 42 字段说明:“工作流程步骤”子视图 43 过程设计器调色板项目 44 关于定义工作流程参数和步骤 45 复审现有流程定义 45 定义新的工作流程过程 46 工作流程过程和流程属性的命名惯例 47 修改现有流程定义 47 教程:使用 Siebel Tools 中的过程设计器 48 第 6 章:适用于开发人员:工作流程过程步骤 关于 Siebel Tools 中的工作流程过程 OBLE 57 绘制工作流程过程图 58 定义工作流程过程的步骤细节 59 删除工作流程步骤 59 删除工作流程过程 60 复制工作流程过程 60 关于流程属性 60 流程属性与属性集 61 定义流程属性 62 级联流程属性 63 定义工作流程过程步骤的字段说明 63 字段说明:“工作流程步骤”子视图 64 字段说明:“工作流程步骤分支”子视图 65 字段说明:“编制条件标准”对话框 68 关于“开始”步骤 70 定义“开始”步骤 70 为“开始”步骤定义“下一步”分支 70 定义分支、“决策”步骤和“用户交互”步骤的条件和值 71 关于“决策”步骤 72 定义“决策”步骤 73 定义决策分支 73 关于“决策”步骤的条件和值 74 关于“业务服务”步骤 74 字段说明:“业务服务”、“子流程”步骤和“等待”步骤的输入参数 75 字段说明:“业务服务”步骤、“子流程”步骤和“Siebel 操作”步骤的输出参数 76 定义“业务服务”步骤 77 为“业务服务”步骤定义输入参数 77 为“业务服务”步骤定义输出参数 77 关于“子流程”步骤 78 定义“子流程”步骤 78 为“子流程”步骤定义输入参数 79 为“子流程”步骤定义输出参数 79 为“子流程”步骤定义接收者 79 字段说明:“工作流程步骤接收者”子视图 80 字段说明:“子流程”子视图 81 关于“Siebel 操作”步骤 81 定义“Siebel 操作”步骤 82 定义“Siebel 操作”步骤的字段 82 定义 Siebel 操作搜索规范 83 定义“Siebel 操作”步骤的输出参数 83 字段说明:搜索规范 84 更新基于多值组的字段 85 关于“等待”步骤 85 定义“等待”步骤 85 关于“用户交互”步骤 86 定义“用户交互”步骤 87 定义“用户交互”的“下一步”分支 87 关于“用户交互”的“下一步”分支的条件和值 88 创建具有流程属性的替代视图名称 88 关于“停止”步骤 88 定义“停止”步骤 89 定义“停止”步骤的输入参数 89 关于“结束”步骤 90 定义“结束”步骤 90 第 7 章:适用于开发人员:了解如何设计工作流程过程 关于工作流程处理模式 93 关于 7.0 工作流程过程 94 关于长期运行的工作流程过程 94 关于交互工作流程过程 94 关于服务工作流程过程 95 建立长期运行的工作流程过程 95 将子流程分配给最终用户以创建协作型长期运行工作流程 95 建立交互工作流程过程 96 创建合成事件按钮以控制用户导航 96 关于交互工作流程过程的挂起和恢复 101 关于视图之间的前进和后退导航 102 使用工作流程持续性 102 关于工作流程持续性 103 启用工作流程持续性 103 处理事件 103 使用运行时事件 104 使用用户事件 105 关于工作流程用户事件业务服务 105 使用用户事件业务服务来生成用户事件 106 将长期运行的工作流程过程配置为等待用户事件 107 工作流程和全局实施 107 在多语言环境下配置工作流程 107 为多语言环境下运行的工作流程定义表达式 108 工作流程中的等待步骤和全局时间计算 108 处理错误 108 使用错误流程来处理错误 109 将用户定义的流程属性和属性集传递给错误流程 109 将错误流程分配给子流程 110 使用例外来处理错误 110 定义例外 110 恢复工作流程过程 111 工作流程过程实例的自动恢复 111 工作流程过程实例的手动恢复 111 调用工作流程过程 112 关于调用工作流程过程 112 从工作流程规则中调用工作流程过程 113 从脚本中调用工作流程过程 113 示例:从对象管理器中的脚本调用工作流程 114 示例:从脚本中调用工作流程以将字段值传递给流程属性 114 从运行时事件中调用工作流程过程 115 作为已配置的业务服务调用工作流程过程 116 在“工作流程过程管理器”中运行工作流程过程 117 在“应用程序对象管理器”中运行工作流程过程 118 在批处理模式下运行工作流程过程 118 第 8 章:适用于开发人员:测试工作流程过程 使用过程模拟器测试工作流程过程 121 关于过程模拟器和支持的模拟模式 122 使用验证工具来纠正工作流程过程中的错误 123 运行过程模拟器 124 测试涉及服务器组件的工作流程 125 第 9 章:适用于管理员:管理工作流程过程 关于部署工作流程过程 127 部署工作流程过程 128 将工作流程过程部署到移动客户机 129 限制移动客户机传送 129 在地区节点上部署工作流程过程 129 将工作流程过程从开发环境迁移到生产环境 130 导入或导出流程定义 130 在运行时客户机中管理工作流程过程 131 激活工作流程过程 132 停止工作流程过程实例 132 删除工作流程过程实例 132 从日志中清除工作流程过程实例 133 监控工作流程过程实例 133 关于工作流程过程监控 133 关于流程监控级别 134 设置监控级别 135 工作流程过程疑难解答 136 关于追踪和事件日志级别 136 提高工作流程管理服务器组件的追踪级别 136 Siebel 应用程序响应管理 (Siebel ARM) 137 Siebel 飞行数据记录器 (FDR) 文件 138 第 10 章:工作流程规则 关于计划工作流程规则 139 计划工作流程规则组 140 计划工作流程规则 140 在计划规则时确定要监控的内容 140 计划规则和条件 141 计划工作流程规则行为 141 计划工作流程规则的方案:30% 以上折扣通知 142 计划工作流程规则的方案:大量已打开的服务请求通知 143 定义工作流程规则的测试和迁移策略 144 关于创建工作流程规则 144 关于“工作流程规则”视图 144 定义工作流程规则行为 145 关于“工作流程规则行为”视图中的“行为”子视图 145 关于“工作流程规则行为”视图中的“参数”子视图 146 使用“发送寻呼”程序类型 146 使用“发送消息”程序类型 147 使用“消息广播”程序类型 147 使用“运行外部程序”程序类型 148 使用“数据库操作”程序类型 149 关于“接收者”子视图 150 创建工作流程规则行为 151 工作流程规则行为示例:创建“发送寻呼”行为 151 工作流程规则行为示例:创建带重复消息的“发送电子邮件”行为 152 工作流程规则行为示例:创建“发送消息广播”行为 154 工作流程规则行为示例:创建“数据库操作”行为 154 工作流程规则行为示例:创建“运行外部程序”行为 155 创建工作流程规则组 157 关于“工作流程组”子视图 157 关于“工作流程规则”子视图 158 创建工作流程规则 158 关于“规则列表”子视图 160 关于“条件”子视图 161 关于“行为”子视图 164 工作流程规则示例:创建“发送寻呼”工作流程规则 164 工作流程规则示例:创建“发送电子邮件”工作流程规则 165 关于使用 Siebel Tools 定制工作流程规则 166 Siebel Tools 和工作流程规则 166 工作流程规则视图中的 Siebel Tools 定义 167 关于工作流程规则对象 168 创建工作流程规则对象 168 工作流程规则和 Siebel Tools 视图 169 关于“工作流程规则列列表”视图 170 根据外键配置工作流程条件 171 关于“工作流程规则对象列表”视图 171 关于“工作流程规则组件列表”视图 172 关于“工作流程规则组件列”视图 173 定义工作流程规则列 174 定义工作流程规则组件 175 定义工作流程规则对象 175 修改规则列名称 176 在工作流程规则对象中添加规则列 176 将列与工作流程规则组件相关联 176 关于 Siebel Tools 中的验证工具 177 修改现有工作流程规则对象 177 关于工作流程规则程序 179 关于“程序列表”视图 179 关于“工作流程规则程序参数列表”视图 180 创建工作流程规则程序 183 创建工作流程规则程序参数的示例:发送商机电子邮件 184 为工作流程规则程序参数创建 SQL 语句 185 关于预定义的工作流程规则程序 185 使用预定义工作流程规则程序的示例:将服务请求结束日期更改为今天 185 使用预定义工作流程规则程序的示例:更改服务请求所有者 186 使用预定义工作流程规则程序的示例:将服务请求所有者更改为经理 187 使用预定义工作流程规则程序的示例:发送报价寻呼 188 使对象类型可在 Siebel 客户机中使用 189 关于工作流程规则服务器管理 189 创建数据库触发器 189 关于数据库触发器和数据库管理 190 运行生成触发器 190 运行 SQL 脚本文件 191 关于数据库触发器和远程用户 192 为电子邮件管理器设置 Siebel 服务器 192 将通讯资料设置为通过工作流程发送电子邮件 192 启动电子邮件管理器 193 为寻呼管理器设置 Siebel 服务器 194 电子邮件和寻呼管理器疑难解答 196 使用工作流程监控代理执行工作流程规则 197 使用工作流程监控代理 198 使用工作流程行为代理 203 使用 Siebel 服务器自动启动“工作流程代理”流程 204 关于工作流程规则和 Siebel 服务器任务追踪文件 204 在 Siebel 服务器管理中查看追踪文件 205 在 Siebel 服务器日志目录中查看追踪文件 205 关于追踪和事件日志级别 205 关于工作流程规则分析图表和报表 205 使用规则频率或趋势分析图表 206 使用工作流程规则报表 206 关于工作流程规则和 Siebel Marketing 206 使用工作流程规则程序执行商业活动 206 使用“发送商业活动电子邮件”工作流程规则程序 207 使用“创建电子邮件活动”工作流程规则程序 207 使用“分配给商业活动”工作流程规则程序 207 使用工作流程规则创建市场商业活动的方案 208 关于测试工作流程规则 211 测试新规则并监控结果 211 工作流程规则疑难解答 212 工作流程规则和追踪 213 将规则迁移到生产环境 213 预定义的程序 213 第 11 章:Siebel Workflow 参考资料 Siebel Workflow 术语 216 预定义的业务服务 218 对外通讯管理器业务服务 218 同步分配管理器请求业务服务 218 服务器请求业务服务 219 “工作流程工具”业务服务 221 在工作流程内传入和传出参数以及工作流程内部的数据处理 222 在工作流程内部处理数据 222 使用“工作流程过程管理器”业务服务在工作流程中传入和传出参数 224 脚本示例:以编程方式调用工作流程和构建输入属性集 225 脚本示例:为输入属性集定义属性集 225 脚本示例:构建属性集 225 脚本示例:将属性和子属性集汇编到输入属性集中 226 脚本示例:调用“工作流程过程管理器”业务服务并向其传递输入属性集 226 将参数从工作流程传递给全局变量(资料属性) 226 在工作流程过程中使用表达式 227 使用时间戳参数 227 索引
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值