SaaS模式、技术与案例详解——第9章 SaaS平台基础组件分析与设计
本章导读语】
所有真正杰出的设计一旦被设计好，看起来都是那么的简单和显而
易见。但是在获得杰出设计的过程中，需要付出令人难以置信的努力
________Michael Abrash《波斯王子：时之沙开发秘话》
任何系统都是由一个个模块组成的，软件系统里有许多模块是公用的，成熟的软件公司会充分利用软件的复用技术来降低开发量，避免重复开发。但要做到软件的复用开始设计时要充分分析有哪些组件是公用的，如何划分并设计这些组件？做到组件真正的松偶合并不容易。SaaS平台应该抽取出这些公用的组件进行统一管理和调用而不是在每个系统中在考虑。
9.1 统一权限控制组件分析与设计
9.1.1 权限控制体系中的基本概念
l 身份与主题
身份（Principal）描述的是用户以及和用户相关的社会关系的属性，例如角色、群组、职位等等。
主题（Subject）是身份的集合，描述的是一个用户所具有的所有身份。
下图表示用户的身份：
图9-1 用户身份关系图
l 资源与资源域
资源是系统中的一种存在，包括具体资源和抽象资源。
具体资源，是实实在在的资源，例如系统模块、页面中的按钮、等等。
抽象资源，可以说是一种描述性资源，例如表达式资源等。
资源域（Resource Domain）是系统中资源的类别，是对多样性资源的一种划分方式。
一个资源域可以包含多种类型的资源，资源的类型在.net中可以用代表该资源的类来表示，同一种类型的资源是以资源的标识来加以区分的。
一个资源在系统中的是以“资源域－资源类型－资源标识”来唯一标识和定位的。
资源域的一个例子：
图9-2 资源域实例图
l 操作
操作（Action），描述的是对某种资源可能的行为，对于某种资源往往可能有多种操作，例如对于文档资源，可能的操作为查看（view）、编辑（edit）、删除（delete）、移动（move）等。
如果对于某种资源的操作较多，可能会出现某些操作之间有包含关系，而某些操作之间没有包含关系的情况。例如上面对于文档的几种操作中，一般拉来说，编辑应该包含查看，而删除应该包含编辑等等，而编辑和移动之间就不一定有包含关系。
对于操作之间的包含关系，可以通过下面的树形结构来说明：
图9-3 资源操作图
l 许可与权限
许可（Permission）描述的是对系统中资源的操作，“通常一个许可包含一个目标（’由这个权限控制的操作将对谁执行？’）和一个操作（’如果这个权限允许的话，对这个目标将执行什么操作？’）”。
许可＝资源＋操作。
权限，可以认为是对许可的一种更为常用的说法，在实际的程序设计中，权限往往被附加上了身份的描述。
权限＝[身份＋]资源＋操作。
l 允许权限与拒绝权限
² 允许权限，明确允许身份A能够对资源B进行C操作，例如允许小王对工程管理模块进行管理操作。
² 拒绝权限，明确拒绝身份A能够对资源B进行C操作，例如不允许小王对工程管理模块进行管理操作。
² 如果一个系统中没有明确允许身份A能够对资源B进行C操作，那么并不代表系统就拒绝了身份A能够对资源B的C操作。
图9-4 允许权限与拒绝权限示意图
l 传播权限与阻止权限
² 传播权限，明确允许或拒绝身份A能够对资源B进行C操作，并将该描述已资源B为祖先向下传播，即身份A对资源B及B的子孙资源都能够进行C操作。
² 阻止权限，即在传播源的子孙（某些）节点阻止祖先传播权限在那些节点的传播，即一旦在某节点阻止了祖先在该点的传播权限，则该阻止自动往下传播。
图9-5 传播权限与阻止权限图
图9-6 基于角色的权限控制模型图
l 各种权限类型的联系与区别
² 从概念上说，允许权限与拒绝权限是一对，而传播权限和阻止权限是一对。
² 允许/拒绝权限是资源点上权限的横向描述，而传播/阻止权限是资源点上权限的纵向描述。
² 拒绝权限与阻止权限的区别：如果在某个节点设置了对某个集合身份（例如群组）的拒绝权限，则该集合身份下的人，无论他们有多少其他身份，也无论这些其他身份是否设置了允许权限，最终都会因为拒绝权限而拒绝。而阻止权限与此不同，例如我们设置了对传播权限的一个阻止权限，同时在该节点又设置了允许权限，则我们先计算自身的拒绝与允许权限，然后才计算传播与阻止权限，因此阻止权限并不能阻止该节点的关联的允许或拒绝权限。
9.1.2 权限控制模型
l 主体-客体权限控制模型
² 出现于早期的应用之中。在这里，主体相当于系统的访问者，客体相当于系统的资源。
² 主体对于客体是否能够访问，一般是通过一个矩阵实现的。
² 优点：授权关系明确，直截了当，存取都很容易。
² 缺点：不能适应变化。
图9-7 主体-客体权限控制模型图
l 基于任务的权限控制模型
² 任务是工作流程中的一个逻辑单元，一个流程一般包含一到多个任务。
² 所谓基于任务，简单的说，就是主体在不同的任务中被许可的权限可能是不一样的，即使是在一个任务中，那么权限也会随着任务生命周期的不同而有所不同。
² 因为权限随着任务和任务状态的不同而不同，所以这是一种动态的权限控制模型。
² 优点：适合于与用例图环境关联紧密或者需要动态授权的应用系统，例如工作流引擎的权限控制。
² 缺点：只适应于某些应用系统，绝大多数系统更为需要的是静态权限控制模型。
l 基于角色的权限控制模型
² 以角色为桥梁，将用户和资源连接起来，用户对某个资源是否能够访问，取决于该用户所对应的角色是否能够对某个资源访问。
² 优点：适应变化。
² 缺点：用户只能通过角色与资源打交道，那么为了某些特殊的用户，系统中不得不创建一些特殊的角色，这些角色实际上已经弱化为用户了。
l 综合权限控制模型
² 以角色为桥梁，将用户和资源连接起来，用户对某个资源是否能够访问，取决于该用户所对应的角色是否能够对某个资源访问。
² 以群组为扩展，将某一组织或者群体下的用户统一授权，用户对某个资源是否能够访问，取决于该用户所对应的群组是否能够对某个资源访问。
² 优点：授权方面、灵活。
² 缺点：权限控制较难，计算复杂，运算效率低。
图9-8 综合权限控制模型图
9.1.3 权限控制策略
l 权限的优先级策略：对于同一个资源，拒绝权限>允许权限>继承权限。
l 组织结构分级管理策略，即组织机构中某个部门的管理员，只能对本部门及本部门的子孙部门的人员进行授权。
l 权限的传播与阻止策略，该策略主要应用于树形资源的授权，目前尚未考虑组织结构这中树形结构对权限的影响。
l 超级管理员策略：系统中一直存在一个超级管理员帐号，用于进行最高级。
权限计算过程
图9-9 权限计算过程图
9.1.4 权限控制体系功能结构
图9-10 权限控制总体功能结构
l 以资源域为中心统一管理、配置资源及相关信息
² 资源域是系统中某类或某几类资源的集合。
² 提供资源域管理界面，通过该界面可以建立新的资源域，并向域中加入某类或多类资源，还可以配置资源的权限描述类。
l 相当灵活的授权方式
² 以身份为中心授权：以身份为中心设置对哪些资源能够进行哪些访问等等，入口分散在人员、群组、组织机构的管理中。
² 以资源为中心授权：以资源为中心，授予哪些身份对该资源可以进行哪些访问等等，该方式又分为两种：
（1） 资源集中授权：权限控制中心将各种资源域的资源以一系列树的方式集中在一起显示并进行授权。
（2） 资源分散授权：任意一种资源，只要将资源标识（ID）、资源对象类（class全名）传给权限控制体系，则控制中心会弹出通用的授权界面，设置哪些身份对该资源可以进行哪些访问等等。
l 资源的权限描述可以通过可插拔的权限描述类来实现
² 权限描述类，主要负责描述该资源对外提供哪些操作以及其他一些信息等等。
² 在我们的体系中，每种资源都可以使用自己编写的权限描述类，也可以更换权限描述类。
l 对于某种资源可能的操作，可以定义这些操作之间的包含关系。
l 支持树形资源的授权，并支持权限的继承与传播。
权限控制中心，在计算权限结果时，如果最终拒绝该请求，则会给出为什么不允许访问：是明确拒绝，还是因为不能计算出是否被拒绝而出于安全考虑才不允许访问的？如果是后者，对于关联资源的权限判断将很有帮助。
l 尊重业务逻辑判断，支持业务对访问请求的优先判断
在系统资源服务接口中定义了checkPermission方法，做为业务自身实现该接口操作后，在对某个请求进行访问控制时，我们现将控制权交给实现了该接口的业务自身，并传给业务足够的请求信息，业务自身对该请求进行业务逻辑判断后，可能会形成三种结果：
² 明确拒绝该请求，如果业务自身明确拒绝该请求，则权限控制体系将直接拒绝该请求，不再交给权限体系自身进行判断。
² 明确允许该请求，如果业务自身明确允许该请求，则权限控制体系将直接允许该请求，不再交给权限体系自身进行判断。
² 不确定是否允许访问，如果业务自身不知道是否允许或拒绝该请求，则权限控制体系会将控制权转交给权限判断中心进行进一步判断。
9.1.4 权限存储
权限的动作存储我们用位来表示，把所有可能的权限按一定的顺序排列，如添加、浏览、修改、删除...，用户的权限值为固定长度的字符串，如100010100001....01，从右起每一位对应一种操作权限，如果有这种权限，则此位的值为1，反之，则为0。
举例如下：
权限排列表：添加、浏览、修改、删除，用户A有添加和浏览的的权限，则其权限值为0011，用户B有浏览和修改的权限则其权限值为0110，用户C有浏览和删除的权限则其权限值为1010，这样设计的好处为：当权限表中增加别的权限时，不会影响用户表或角色表，大大节省存储空间，并且提高查询效率；
实际上数据库中表示二进制数据的方法是用数字类型字段来存储。
如表9-1的几个关键字段ResourceCode（资源标识号码）表示页面的标识，是统一权限识别资源的依据；GroupIndex（分组索引号）表示资源按每2的64次方分组，每组从0、1、2…、63重复计算，ResourceBit(资源位)表示资源按2的n次幂存放，每组中从1、2、4、…、5994291104030130176（2的64次方）分别存放。
表9-1 菜单功能资源表
如表9-2角色资源表中的几个关键字段ResourceIndex、ResourceBit与上面意义就不一样了。ResourceIndex表示某个角色所有权限组中应该有哪几组，而不一定是从0、1排列，可能只有其中的几组数字，ResourceBit是在该组范围内的权限的并集集合，这是通过计算而得到，我们可以通过SQL语句的求和函数很灵活地计算出来，SQL语句如下：
“select GroupIndex，sum(ResourceBit) as bit from Resource where ID in(ResourceIDs) group by GroupIndex”
表9-2 角色资源表
9.1.5应用场景
l 用户身份资源
下面次序图描述了获取用户身份的各种场所，通过集合求和并排拆的方法求得用户的身份集合。
图9-11 权限计算过程图
l 用户权限
下面此次序图描述了获取用户权限的综合应用，用户权限包括应用资源、菜单、操作对象、对象的属性及对象的记录。
图9-12 用户权限图
9.1.6 权限控制设计
l 权限控制与认证总体结构设计
图9-13 权限控制与认证总体结构设计
权限控制是基于用户的角色的权限控制方式，首先给角色分配资源，然后指定资源所允许的允可权限，再给用户分配角色。
权限认证是用户登录系统时验证用户身份的合法性，系统获取合法用户的资源权限并生成主菜单及子菜单，同时展现缺省的有权限的页面及树形菜单。当用户访问某个资源时验证该资源权限，对有可访问的资源进行控件权限的处理及行权限、列权限的控制。
l 权限控制用例设计
图9-14 权限控制用例图
9.1.7 业务功能组件
图9-15业务功能组件
l 用户管理
系统管理员登录用户门户，进入用户管理模块，创建用户、修改用户、删除用户、查询用户并给用户分配角色。
l 组织机构管理
系统管理员登录用户门户，进入组织机构管理模块，创建组织机构、修改组织机构、删除组织机构、查询组织机构并给组织机构分配角色。
l 角色管理
系统管理员登录用户门户，进入角色管理模块，创建角色、修改角色、删除角色、查询角色并给角色分配资源权限及允可权限。
l 资源管理
系统管理员登录用户门户，进入资源管理模块，创建资源、修改资源、删除资源、查询资源。
l 操作管理
系统管理员登录用户门户，进入操作管理模块，选择资源，创建操作、修改操作、删除操作、查询操作。
l 资源权限管理
系统管理员登录用户门户，进入角色管理模块，选择角色并给角色分配资源权限。
l 操作权限管理
系统管理员登录用户门户，进入角色管理模块，选择角色，选择资源并给角色分配操作权限。
l 行权限管理
系统管理员登录用户门户，进入行权限管理模块，选择资源，输入行权限条件。
l 用户登录
用户身份验证，保存用户信息，打开系统主页。
l 菜单展现
读取用户角色，通过角色找出用户的所有有权限的资源并保存，按资源类别通过菜单或者树展现出。
l 页面权限处理
通过页面标识查看是否该页是否在该用户的资源权限缓存库里，不在则没有权限，有则打开该页。
l 控件权限处理
读取页面所有的控件，通过角色对控件的权限分配识别是用户对控件的处理类别，通过处理类别来处理该控件。
l 行权限处理
读取页面的查询条件子句并组装成查询语句，通过查询语句从数据表中读取有权限的数据。
l 列权限处理
读取页面网格控件的每列，看该列所对应的控件是否在权限表中，在权限表中即表示不允许展现该就隐藏掉。
9.1.8 业务实体组件
l 对象关系图
图9-16业务功能组件
User用户。
UserRole用户所拥有的角色
Organize组织机构
Role角色
RoleResource角色所拥有的资源
Resource资源
RoleRow角色的行权限
RoleAction角色的操作权限
9.1.9 任务时序图
图9-17任务时序图
图9-18 任务时序图
9.1.10 实体类设计
图9-19 类图
9.1.11 数据模型设计
l E-R关系图
图9-20 E-R关系图
l 主要数据实体说明
表9-3 用户登录表
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
| ID |
int |
4 |
10 |
N |
自动增加（P） |
| UserId |
varchar |
10 |
Y |
用户名 |
|
| UserPass |
varchar |
100 |
Y |
用户密码 |
|
| UserType |
int |
4 |
N |
用户类型 |
表9-4 用户表
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
||||||
| ID |
int |
4 |
10 |
N |
自动增加（P） |
||||||
| UserId |
varchar |
10 |
Y |
用户登录名 |
|||||||
| UserPass |
varchar |
100 |
Y |
用户密码 |
|||||||
| UserTopID |
int |
4 |
N |
上级用户ID |
|||||||
| Name |
varchar |
用户姓名 |
|||||||||
| UserComment |
varchar |
用户描述 |
|||||||||
| DefaultPage |
varchar |
缺省首页 |
|||||||||
| IsEnable |
bit |
1 |
是否启用 |
||||||||
| |
varchar |
电子邮箱 |
|||||||||
| 电话 |
varchar |
电话 |
|||||||||
| 手机 |
int |
4 |
手机 |
||||||||
表9-5 组织机构表
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
| ID |
int |
4 |
10 |
N |
自动增加（P） |
| ParentID |
int |
4 |
父机构ID |
||
| OrgName |
varchar |
50 |
N |
机构名 |
|
| Comment |
varchar |
机构描述 |
表9-6 用户组织机构表
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
| ID |
int |
4 |
10 |
N |
自动增加（P） |
| UserID |
int |
4 |
用户ID |
||
| OrgID |
int |
50 |
N |
机构ID |
表9-7 角色表
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
| ID |
int |
4 |
10 |
N |
自动增加（主键） |
| RoleName |
varchar |
20 |
Y |
角色名 |
|
| RoleCommand |
varchar |
100 |
Y |
角色描述 |
|
| IsEnable |
bit |
1 |
是否启用 |
||
| RoleOrder |
int |
4 |
顺序 |
表9-8 Resource资源表
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
| ID |
int |
4 |
10 |
N |
自动增加（主键） |
| ParentID |
int |
4 |
父资源ID |
||
| ResourceName |
varchar |
20 |
Y |
资源名 |
|
| ResourceUrl |
varchar |
资源的URL |
|||
| IsEnable |
bit |
1 |
是否启用 |
||
| ResourceOrder |
int |
4 |
资源顺序号 |
||
| ResourceLevel |
int |
4 |
资源级别 |
||
| ResourceType |
int |
4 |
资源类型 |
||
| ImageUrl |
varchar |
资源图片文件 |
|||
| ResourceTable |
varchar |
资源物理表 |
|||
| ResourceCode |
varchar |
资源标识号 |
|||
| GroupIndex |
int |
4 |
资源组 |
||
| ResourceBit |
int |
4 |
资源位 |
表9-9 ResourceAction资源操作表
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
| ID |
int |
4 |
N |
自动增加（主键） |
|
| ResourceID |
int |
4 |
资源ID |
||
| ActionName |
varchar |
20 |
Y |
操作名 |
|
| ActionCode |
varchar |
20 |
操作标识码 |
||
| ParentID |
int |
4 |
父 |
表9-10 UserRole用户角色表
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
| ID |
int |
4 |
10 |
N |
自动增加（主键） |
| UserID |
int |
4 |
用户ID |
||
| RoleID |
int |
4 |
角色ID |
表9-11 OrgRole组织机构角色表
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
| ID |
int |
4 |
10 |
N |
自动增加（主键） |
| OrgID |
int |
4 |
组织机构ID |
||
| RoleID |
int |
4 |
角色ID |
表9-12 RoleResource角色资源（功能）表
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
| ID |
int |
4 |
N |
自动增加（主键） |
|
| RoleID |
int |
4 |
角色ID |
||
| ResourceIndex |
int |
4 |
资源组 |
||
| ResourceBit |
bigint |
8 |
资源组内的位集合 |
表9-13：RoleAction角色操作表
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
| ID |
int |
4 |
N |
自动增加（主键） |
|
| RoleID |
int |
4 |
角色ID |
||
| ResourceActionID |
int |
4 |
资源组 |
||
| VisibleEnabled |
smallint |
2 |
|||
| VisibleNoEnabled |
smallint |
2 |
|||
| NoVisible |
smallint |
2 |
表9-14：RowResource行权限
| 字段名称 |
类型 |
长度 |
精确度 |
是否为空 |
描述 |
| ID |
int |
4 |
10 |
N |
自动增加（主键） |
| RoleID |
int |
角色ID |
|||
| SQLWhere |
varchar |
20 |
Y |
Where子句 |
|
| ResourceID |
int |
4 |
9.2系统配置组件
9.2.1 需求分析
系统在运行时会有许多特性依靠参数的不同而表现出不同的行为，通过系统配置管理，将参数保存至系统参数表中，而不是以Hard Code的方式写死，在需要的时候可以进行修改，从而在业务运行中实现灵活配置。
系统中的配置不能在代码中进行硬编码，系统管理员或开发人员根据需要，将配置保存至数据库中，以便以后的管理。
表9-15描述了系统配置组件中角色所完成的功能操作：
表9-15：角色功能操作表
| 角色名称 |
操作 |
| 开发人员或系统管理员 |
添加，删除，修改系统配置分类和配置内容 |
l 流程定义
图9-21 系统配置流程图
l 业务场景描述及规则
1. 配置参数必须属于某一个分类，所以首次创建参数时，必须要先创建配置分类；为了便于管理，分类一般和功能模块相对应。
2. 在创建或修改参数时，应先选择配置的参数的分类，然后填写或修改参数的内容，并保存。
3. 参数在误修改后，可以通过恢复默认值的功能进行恢复。
l 业务数据说明
表9-16 角色功能操作表
| 业务名称 |
涉及数据项 |
备注 |
| 分类管理 |
分类名称 |
|
| 参数管理 |
分类名称 |
参数必须属于某一分类 |
| 参数名称 |
||
| 参数描述 |
||
| 类型 |
用于对参数值进行类型检查和转换 |
|
| 参数值 |
||
| 参数默认值 |
参数的初始值 |
|
| 是否缓存 |
不缓存的参数每次访问时直接从数据库读取 |
9.2.2 功能设计
1. 分类管理
如图9-22是分类管理的用例图：
图9-22 用例图
下面我们对分类管理进行详细描述如表9-17：
表9-17 分类管理功能描述表
| 名称 |
系统配置.分类管理 |
| 编号 |
ATR-2001 |
| 用例描述 |
管理员/开发人员对系统配置的分类进行管理 |
| Actors |
管理员/开发人员 |
| 前置条件 |
管理员/开发人员登录门户 进入系统配置栏目 |
| 主要路径 |
点击系统配置栏目树下的分类管理，列出所有已存在的分类列表 选中某一分类，在列表上方的详细信息区域将显示选中的详细信息 编辑详细信息，点击“保存”将数据保存至数据库 点击“删除”，系统提示是否真的要删除，该操作也将把该分类下的所有配置都删除掉，用户确定后，数据将从数据库中删除，界面进行刷新 点击“添加”将新增一个配置分类 |
| 可选路径 |
在参数配管理页面也将提供分类管理链接，跳转至本页面 |
| 补充说明 |
配置分类详细信息和列表的字段： 分类名称，描述 |
2. 参数管理
如图9-23是参数管理的用例图：
图9-23 用例图
下面我们对分类管理进行详细描述如表9-18：
表9-18 参数管理功能表
| 名称 |
系统配置.参数管理 |
| 编号 |
ATR-2002 |
| 用例描述 |
管理员/开发人员对系统配置参数进行管理 |
| Actors |
管理员/开发人员 |
| 前置条件 |
1． 管理员/开发人员登录门户 2． 进入系统配置栏目 |
| 主要路径 |
点击系统配置栏目树下的参数管理 选中下拉框中某一分类，点击“查询”按钮，在列表中列出分类下的所有参数信息，也可以在参数名称查询文本框中输入名称的一部分查询，以减少查询的数据量 选中某一条参数，在列表的下方详细信息区域显示参数的详细信息 在详细信息中编辑参数信息，然后点击“保存”将数据保存至数据库 点击“删除”，系统提示是否真的要删除，用户确定后，当前选中的数据将从数据库中删除，界面进行刷新 点击“添加”将新增一个参数配置 点击“恢复默认值”将当前参数值恢复为原始的默认值 |
| 补充说明 |
参数详细信息和列表的字段： 分类名称，参数名称，参数描述，参数类型，参数值（缺省与默认值相同，可修改），默认值（必添项），是否缓存 |
9.2.3 总体结构设计
系统配置管理面向开发人员和管理人员，提供对系统配置参数增删改查。对于开发人员，主要涉及对参数的读取并应用到系统中；对于管理人员，提供对参数的管理功能。
l 业务工作流
业务工作流包括添加分类、删除分类、修改分类、获取分类、添加参数、删除参数、修改参数、获取参数。
l 业务功能组件
1. 分类管理
为了方便系统配置参数的管理，对参数按照功能模块进行分类管理，因此在对参数进行管理之前，首先要能对分类进行管理，包括分类的添加、删除、修改和读取。
2. 参数管理
系统配置管理的主要任务就是参数管理，管理员负责对参数的管理，开发人员负责读取参数的设定值，并应用到系统中使之生效，因此该组件包括参数的添加、删除、修改和读取。
9.2.4 业务实体组件
系统配置管理组件的对象关系图如图9-24所示：
图9-24 对象关系图
SysConfigCatalog表示系统配置分类实体，存储配置分类信息；ParamType表示参数类型实体，存储具体参数的类型，主要用于检查输入参数类型的合法性；SysParameter表示参数详细信息实体，存储参数的详细信息。
9.2.5 任务时序图
l 分类管理
l 参数管理
9.2.6 数据模型设计
系统配置管理组件的数据结构如图9-26所示：
图9-26 E-R关系图
SysConfigCatalog：配置分类表
SysConfigParams：参数信息表
ParamType：参数类型表
9.3日志管理组件
实现对系统日志的管理，包括对业务操作人员的登陆情况、行为情况等，是管理者能过更深入了解用户的行为和系统的运行状况。
9.3.1 日志记录
记录系统运行时出现的异常，以及访问系统的用户所做的操作，为以后查找问题和跟踪用户操作提供依据。
表9-19描述了日志管理组件中角色所完成的功能操作：
表9-19 日志管理角色功能操作表
| 角色名称 |
操作 |
| 开发人员 |
记录异常以及业务操作的信息 |
l 业务场景描述及规则：在可能出现异常和重要业务操作的地方，记录信息；日志分为错误（Error）、警告（Warn）、调试（debug）和信息（info）四个级别，每个级别都可以通过配置文件设置日志是否记录；日志也可以根据配置文件设置各个级别分别记录至文件或数据库。
l 业务数据说明
表9-20 日志管理数据项表
| 业务名称 |
涉及数据项 |
备注 |
| 日志记录 |
操作人 |
|
| 时间 |
||
| 模块名称 |
||
| 接口名称 |
||
| 日志级别 |
||
| 日志的内容 |
9.3.2 日志检索
为管理员或开发人员提供了解系统运行时出现问题的手段，以便跟踪、查找和定位问题的所在。
表9-21描述了组件中角色所完成的功能操作：
表9-21 日志检索角色功能操作表
| 角色名称 |
操作 |
| 开发人员或管理员 |
查看日志的内容 |
l 流程定义
图9-27 日志检索流程图
l 业务场景描述及规则
1. 日志分为错误（Error）、警告（Warn）、调试（debug）和信息（info）四个级别，每个级别都可以通过配置文件设置日志是否记录；
2. 日志也可以根据配置文件设置各个级别分别记录至文件或数据库。
3. 记录至文件中日志不提供界面显示，只针对记录至数据库中的日志，提供按模块，接口，时间段，操作人进行日志的检索；如果要查看文件中的日志，需要登陆到服务器上，直接查看。
l 业务数据说明
表9-22 日志检索数据项表
| 业务名称 |
涉及数据项 |
备注 |
| 检索日志 |
操作人 |
|
| 时间段 |
||
| 模块名称 |
管理员登录时有此输入项 |
|
| 接口名称 |
一般用户没有此输入项 |
|
| 日志级别 |
同上 |
9.3.3 日志查看
如图9-28是日志查看的用例图：
图9-28 用例图
下面我们对日志查看进行详细描述如表9-23：
表9-23 日志查看功能描述表
| 名称 |
日志管理.日志查看 |
| 编号 |
ATR-3001 |
| 用例描述 |
管理员/开发人员对系统配置的分类进行管理 |
| Actors |
管理员/开发人员 |
| 前置条件 |
管理员/开发人员登录门户 进入日志管理的日志查看栏目 |
| 主要路径 |
输入查询条件，点击“查询”，显示查询结果 |
| 补充说明 |
查询条件有： 时间段，功能模块，日志级别（信息，错误，警告，调试） 查询结果列表的字段： 日志级别，功能模块名称，日志内容，日期 |
9.3.4 数据模型设计
日志管理组件的数据结构如图9-29所示：
图9-29 日志管理E-R关系图
9.4多语言组件
当SaaS系统应用到全球时，由于各国语言的不同，必须要把系统界面的文字转化为本国语言，这里我们用统一的多语言组件来实现。
在用户第一次访问站点时为其会使用默认语言展示页面。用户在选择其他语言显示页面之后，系统会记录下用户的使用习惯，当用户下次重新回来，访问站点时，服务器将根据用户喜好语言来进行展示。
具体实现方式上来讲，用户打开页面，服务器读取COOKIE中的当前使用语言信息初始化页面，展现给用户。对于第一次登录系统的用户，会以默认语言展现。
从使用范围来讲，各个系统都应该提供多语言支持。
9.4.1 需求分析与设计
l 流程定义
多语言展现流程如下：用户访问SaaS系统中的页面，向服务器发送页面请求，服务器读取COOKIE信息得到当前语言，根据当前语言和页面链接，从资源管理模块中获取页面中所有具有该语言标识的所有控件列表；找到页面中的相应控件，根据资源管理模块提供的该控件所需要展现的属性，更新之，在页面生成完毕后推送给客户端。
图9-30 多语言流程图
l 业务场景描述及规则
多语言模块提供一个页面基类，需要使用功能的页面需要继承此基类。该基类根据数据库中所保存的资源包信息更新子类展现。
l 业务数据说明
表9-24 业务数据表
| 业务名称 |
涉及数据项 |
备注 |
| 语言种类 |
语言主键 |
自定义语言编号与COOKIE中记录保持一致。 |
| 语言编码 |
目前需要支持三种语言： |
|
| 描述 |
语言描述 |
|
| 页面资源表 |
编号（ID） |
|
| 语言编号 |
||
| 页面链接 |
||
| 控件名称 |
||
| 控件属性 |
||
| 控件代码集名称 |
||
| 值 |
9.4.2 改变当前使用语言
用户切换到其他语言，页面中需要多语言展现部分被重新初始化，并展现给用户。
l 流程定义
多语言展现流程如下：用户切换当前语言种类，页面更改COOKIE中的语言种类，POSTBACK回到服务器，服务器根据COOKIE中的内容向用户展现相应语言界面。
图9-31 多语言切换流程图
l 业务场景描述及规则
多语言模块为语言切换提供一个客户端控件，该控件被点击后，先更改客户端的COOKIE信息，然后向服务器端提交数据。
l 在数据库中插入多语言数据
INSERT INTO RESOURCE.[RESSTRING] VALUES(‘S_ATR_Default.aspx_label1’,0，’【标签】’,’Test’);
INSERT INTO RESOURCE.[RESSTRING]VALUES(‘S_ATR_Default.aspx_label1’,1,’【LABEL1】’,’Test’);
INSERT INTO RESOURCE.[RESSTRING] VALUES(‘S_ATR_Default.aspx_label1’,2,’【XXXXX1】’,’Test’);
l 数据模型设计
图9-32 多语言数据模型
数据库中NAME字段和LANG字段为主键，必添字段，不可重复字段
9.4.3 多语言使用
l 对于客户端控件、脚步和文字使用如下标识
alert(‘<%=GetResourceString("S_ATR_Default.aspx_label1") %>’);
请注意：由于使用的是两种解析体系，所以需要使用两种类型的标识符号。
l 对于服务器端控件使用如下标识
请注意：由于使用的是两种解析体系，所以需要使用两种类型的标识符号。
l 获知当前用户所使用的语言
基类中提供LangTYPE枚举类型属性CultrueID，可以取得当前用户使用语言，如下：
protected void Page_Load(object sender， EventArgs e)
{
Microsoft.CommModule.BasePage.MultiLang.multiLang mtlCurrentCultrue = this.CultrueID;
}
l 用户切换语言选择时需要更新的COOKIE
///
/// 在 COOKIE 中设置语言符号标识，并发送到客户端
///
/// 语言标识
private static void SetLanguageIdinCookie(int LanguageID)
{
HttpCookie cookie = new HttpCookie("Preferences");
cookie["LanguagePref"] = LanguageID.ToString();
cookie.Expires = DateTime.Now.AddYears(1);
HttpContext.Current.Response.Cookies.Add(cookie);
}
9.5报表管理组件
对于SaaS系统中涉及到的查询统计的相关功能，采用SQL Server Reporting Service实现，Reporting Service提供了强大的报表开发工具，能够灵活的定义报表内容和样式。
9.5.1 需求分析
表9-25描述了报表组件中角色所完成的功能操作：
表9-25 报表组件角色功能操作
| 角色名称 |
操作 |
| 报表管理员 |
l 创建报表项目 l 设计报表 l 发布报表 |
业务场景描述及规则：
1. 报表管理员使用SQL Server Business Intelligence Development Studio工具创建或打开报表项目。
2. 定义数据源。.
3. 添加报表文件。
4. 设计报表样式。
5. 完成后将报表发布到报表服务器上。
l 报表目录管理
报表目录是在SP中组织报表的逻辑结构，它具有树型层次结构，方便报表归类管理和查询。
表9-26描述了报表目录中角色所完成的功能操作：
表9-26 报表目录角色功能操作
| 角色名称 |
操作 |
| 报表管理员 |
l 创建报表目录 l 修改报表目录 l 删除报表目录 l 为报表目录分配访问权限 |
业务场景描述及规则：
l 创建报表目录
1. 报表管理员登录进SP，进入报表管理模块。
2. 在报表目录树中选择一个报表目录，进行目录管理。
3. 选择添加报表目录。
4. 输入报表目录信息。
5. 保存报表目录信息。
l 修改报表目录
1. 报表管理员登录进SP，进入报表管理模块。
2. 在报表目录树中选择一个报表目录，进行目录管理。
3. 输入报表目录信息。
4. 保存报表目录信息。
l 删除报表目录
1. 报表管理员登录进SP，进入报表管理模块。
2. 在报表目录树中选择一个报表目录，进行目录管理。
3. 选择删除报表目录。
4. 确认后将报表目录和目录中的报表删除（并不删除Reporting Services上的报表）。
l 为报表目录分配访问权限
1. 报表管理员登录进SP，进入报表管理模块。
2. 在报表目录树中选择一个报表目录，分配目录访问权限。
3. 管理员查找要进行授权的角色。
4. 管理员选择角色是否可以访问这个目录。同时这个目录的子目录也继承了这个权限，即用户有权限看到一个报表目录的话，也可以看到它的子目录。
5. 保存权限配置。
下面分析业务数据说明如表9-26：
表9-26 报表目录的业务数据
| 业务名称 |
涉及数据项 |
备注 |
| 报表目录 |
目录名称 |
|
| 父目录 |
||
| 目录说明 |
||
| 排序号 |
报表管理
管理员创建好报表目录后，可以在其中添加报表，并提供报表的基本信息。这些报表链接到Reporting Services上的实际报表。
表9-27描述了组件中角色所完成的功能操作：
表9-27 报表管理的角色与操作关系
| 角色名称 |
操作 |
| 报表管理员 |
l 添加报表 l 修改表表 l 删除报表 l 为报表目录分配访问权限 |
业务场景描述及规则：
l 创建报表
1. 报表管理员登录进SP，进入报表管理模块。
2. 在报表目录树中选择一个报表目录。
3. 选择添加报表。
4. 输入报表信息。
5. 保存报表信息。
l 修改报表
1. 报表管理员登录进SP，进入报表管理模块。
2. 在报表目录树中选择一个报表目录。
3. 从此目录的报表列表中选择一个报表。
4. 修改报表信息。
5. 保存报表信息。
l 删除报表
1. 报表管理员登录进SP，进入报表管理模块。
2. 在报表目录树中选择一个报表目录。
3. 从此目录的报表列表中选择一个报表删除。
4. 确认后将目录中的这个报表删除（并不删除Reporting Services上的报表）。
l 为报表目录分配访问权限
1. 报表管理员登录进SP，进入报表管理模块。
2. 在报表目录树中选择一个报表目录。
3. 从此目录的报表列表中选择一个报表，进行授权管理。
4. 管理员查找要进行授权的角色。
5. 管理员选择角色是否可以访问和订阅这个报表。默认情况下，继承所在目录的访问权限。即用户有权限看到一个报表目录的话，也可以看到它其中的报表。
6. 管理员选择角色不可以看到的报表字段。默认情况下，可以看到所有字段的内容。
下面分析业务数据说明如表9-28：
表9-28 报表管理的业务数据
| 业务名称 |
涉及数据项 |
备注 |
| 报表 |
名称 |
|
| 说明 |
||
| 所在目录 |
||
| 报表路径 |
实际的报表在报表服务器上的完整路径 |
l 查看报表
管理员配置好报表之后，用户可以在相应的门户中查看报表内容。
表9-29描述了查看报表的角色所完成的功能操作：
表9-29 查看报表的业务数据
| 角色名称 |
操作 |
| 报表管理员 报表用户 |
l 按目录检索报表 l 查找报表 l 查看报表 l 打印报表 l 导出报表 l 订阅报表 |
9.5.2 慨要设计
l 报表目录管理
如图9-33是报表目录的用例图：
图9-33 报表目录用例图
如表9-30是报表目录的功能描述：
表9-30 报表目录功能详细描述据
| 名称 |
报表管理.创建报表目录 |
| 用例描述 |
报表管理员创建报表目录 |
| Actors |
报表管理员 |
| 前置条件 |
登录用户门户 具有报表管理权限 |
| 主要路径 |
报表管理员登录用户门户 进入报表管理模块 创建报表目录 |
l 报表管理
如图9-34是报表管理的用例图：
图9-34 报表管理用例图
下面我们对报表管理进行详细描述如表9-31：
表9-31 报表管理功能详细描述据
| 名称 |
报表管理。制作报表 |
| 编号 |
|
| 用例描述 |
报表管理员制作报表 |
| Actors |
报表管理员 |
| 前置条件 |
报表管理员有权限在Reporting Srvice中发布报表 |
| 主要路径 |
报表管理员使用SQL Server Business Intelligence Development Studio开发报表 将报表发布到Reporting Service上 |
| 结果 |
在Reporting Service中增加了若干报表 |
l 查看报表
如图9-35是报表管理的用例图：
图9-35 查看报表用例图
下面我们对查看报表进行详细描述如表9-32：
表9-32 查看报表功能详细描述据
| 名称 |
报表管理.查看报表 |
| 编号 |
|
| 用例描述 |
报表管理员和报表读者查看报表内容 |
| Actors |
报表管理员、报表读者 |
| 前置条件 |
登录用户门户 具有报表目录和报表的访问权限 |
| 主要路径 |
报表管理员登录用户门户 进入报表模块 选择报表目录 选择报表查看 |
| 结果 |
查看报表内容 |
9.5.3 报表管理总体结构设计
图9-36 报表管理总体结构
在个人Portal中有报表管理模块，在其中维护报表目录结构和报表。这里的报表链接到Reporting Service上的实际报表。Reporting Service中的报表中嵌入权限认证组件，通过这个组件判断HTTP用例图中的用户是否有权限访问报表。
下面我们来看看报表管理的业务工作流如图9-37：
图9-37 报表管理业务工作流
9.5.4 业务功能组件
报表管理模块中包括几类功能组件：报表目录组件、报表组件、报表权限管理组件、报表权限验证插件。
l 报表目录组件
完成的功能包括：报表目录的创建、报表目录的删除、报表目录的修改。
l 报表组件
完成的功能包括：报表的创建、报表的删除、报表的修改。
l 报表权限管理组件
完成的功能包括：获取有权限访问的目录、获取有权限访问的报表、验证用户对某个报表目录是否有访问权限、验证用户对某个报表是否有访问权限。
报表目录的授权：指定哪些角色可以访问这个目录。子目录继承对父目录的权限定义，以低权限为准。如某用户属于2个角色，一个角色定义了他对目录a有权限，另一个角色定义他禁止访问目录a，则此用户无权访问目录a。
报表的授权：包括那些角色可以访问报表、可以访问报表的那些字段。对于访问权限，继承目录的访问权限，并且还可以指定其中哪些角色禁止访问报表。
l 报表权限验证插件
报表权限验证组件嵌入在Reporting Services上的报表中，根据传入的用户身份信息验证用户是否有权限访问当前报表，获取可以访问的报表字段，报表中可以获得这些信息来控制显示的内容。
9.5.5 业务实体组件
l 对象关系图
如果以OO的方式实现业务实体组件，则以对象关系图的方式描述业务对象之间的关系。
图9-38 报表管理对象关系图
l 任务时序图
报表访问流程如图9-39：
图9-39 报表管理任务时序图
9.5.6 数据模型设计
简要E-R关系图如图9-40：
图9-40 报表管理任务时序图
主要数据实体说明
报表目录：是组织报表的逻辑结构，方便报表的分类、检索。它具有树形层次结构。一个报表属于某一个报表目录，一个报表目录中有多个报表。
表9-33 报表目录
| 名称 |
类型 |
必需 |
说明 |
| 目录ID |
整形 |
是 |
目录的唯一标识 |
| 目录名称 |
字符串 |
是 |
|
| 目录备注 |
字符串 |
否 |
|
| 目录级别 |
整形 |
是 |
目录在目录层次中所处的级别 |
| 父目录ID |
整形 |
是 |
父目录的目录ID |
报表：报表存在于报表目录中，它链接到Reporting Services中的实际报表。用户可以通过名称和备注来检索报表。
表9-34 报表
| 名称 |
类型 |
必需 |
说明 |
| 报表ID |
整形 |
是 |
报表的唯一标识 |
| 报表名称 |
字符串 |
是 |
|
| 报表备注 |
字符串 |
否 |
|
| 报表路径 |
字符串 |
是 |
报表在Reporting Services中的实际路径 |
9.6 搜索引擎组件
在门户页面上提供一个简单的搜索表单，对全站内容进行搜索。
9.6.1 需求分析
表9-35描述了搜索引擎组件中角色所完成的功能操作：
表9-35 搜索引擎角色功能操作
| 角色名称 |
操作 |
| 门户会员 |
输入关键字进行搜索 |
业务场景描述及规则：
1. 用户输入要搜索的关键词进行搜索。
2. 列出网站内包含所搜索的关键字的网页、Word文档、Excel文档、PDF文档的链接，用户点击结果条目，访问搜索结果。
3. 如果结果条目过多，以分页方式显示。It should show in multipage if items too many。
4. 在搜索结果页面上，用户可以进一步选择在哪类分类条目下重新搜索。
l 标签搜索
在门户的某栏目页面上提供一个标签搜索表单，对某栏目下的内容进行搜索，查找包含指定标签的内容。
表9-36描述了标签搜索中角色所完成的功能操作：
表9-36 标签搜索角色功能操作
| 角色名称 |
操作 |
| 门户会员 |
输入标签关键字进行搜索 |
业务场景描述及规则：
1. 用户输入要搜索的标签关键词进行搜索。
2. 列出本栏目下内包含所搜索的标签关键字的网页的链接，用户点击结果条目，访问搜索结果。
3. 如果结果条目过多，以分页方式显示。
l 搜索管理
管理员可以对Sharepoint的搜索服务进行配置，如配置搜索关键字、同义词、干扰词等，以提供更好的搜索结果。
使用搜索关键字和最佳匹配，可以提供两个有助于用户获得所需搜索结果的重要功能：使用搜索关键字，可以创建组织内的重要术语的词汇表。当用户在搜索查询中键入关键字时，已经为该关键字创建的定义将显示在搜索结果页的顶端。Search使用最佳匹配，可以在显著位置显示以编辑身份选择的搜索结果。最佳匹配是与搜索关键字相关联的网页、文档或外部网站的URL。当用户在搜索查询中键入具有最佳匹配的关键字时，最佳匹配URL（包括每个URL的标题和说明）将显示在搜索结果页的显著位置上。如果网站管理员希望宣传特定网页，则最佳匹配特别有用。因为最佳匹配URL显示在搜索结果页的显著位置上，所以最终用户查看它们的可能性更大。
表9-37描述了搜索管理中角色所完成的功能操作：
表9-37 搜索管理角色功能操作
| 角色名称 |
操作 |
| 系统管理员 |
配置关键词和同义词 配置关键词最佳匹配 配置干扰词 |
业务场景描述及规则：
l 配置关键词和同义词
1. 管理员进入Sharepoint搜索配置功能页面。
2. 在“管理关键字”页上，单击“添加关键字”。
3. 在“关键字短语”框中，键入要添加到搜索词汇表中的单词、缩写或短语。
4. 如果存在与关键字可互换使用的单词或短语，请在“同义词”框中键入它们。各个单词或短语之间用分号隔开。
图9-41 配置关键词和同义词
5. 在“定义”框中键入关键字在词汇表中的定义。
6. 在“发布”部分，单击要应用于该关键字的每个日期旁边的日历。如果未输入日期，则会将当前日期用作“开始日期”。
7. 搜索同义词时，在搜索结果上可以给出同义词建议。
l 为关键字创建最佳匹配
1. 管理员进入SharePoint搜索配置功能页面。
2. 在“网站集管理”部分，单击“搜索关键字”。
3. 在“管理关键字”页上，如果要向现有的关键字中添加最佳匹配，请将指针悬停在该关键字的名称上，然后单击“编辑”。
4. 如果要创建与最佳匹配相关联的新关键字，请单击“添加关键字”，然后在“关键字短语”框中键入该关键字。
5. 在“最佳匹配”部分，单击“添加最佳匹配”，然后在“URL”框中键入最佳匹配页的地址。
6. 键入要显示在搜索结果页上的标题和说明，然后单击“确定”。
7. 如果该关键字有多个最佳匹配，请选择它们的列出顺序，然后单击“确定”。
8. 在网站的下次计划更新过程中，关键字和最佳匹配将添加到搜索索引中。
l 配置干扰词
1. 管理员登录搜索服务器。
2. 进入搜索服务程序目录，打开干扰词文件，添加或修改干扰词，保存文件。
3. 重起搜索服务使新的干扰词配置生效。搜索引擎将会在搜索索引中去掉干扰词，忽略用户输入的干扰词。
9.6.2 慨要设计
站内搜索用例图如图9-42：
图9-42 站内搜索用例图
下面我们对站内搜索进行详细描述如表9-38：
表9-38 站内搜索角色功能操作表
| 名称 |
站内搜索.搜索 |
| 编号 |
|
| 用例描述 |
会员在门户上搜索 |
| Actors |
会员 |
| 前置条件 |
|
| 主要路径 |
访问会员门户 输入搜索条件搜索 |
| 结果 |
列出搜索结果 |
9.7 工作流组件
企业在进行业务处理时，政府在进行公文审批时，都是以流程形式而进行的，在信息化的过程中，企业、政府也将这些业务处理、公文审批的过程信息化了，早期通常是通过程序硬编码的方式来处理这些业务、公文的流转，随着业务、公文的复杂的处理情况不断出现以及需求的不断变更，这种硬编码的方式显然已无法应对，这个时候工作流管理系统应运而生，掀起了一股工作流管理系统的热潮。
9.7.1 工作流慨念
工作流（Workflow）就是“业务过程的部分或整体在计算机应用环境下的自动化”，它主要解决的是“使在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者促使此目标的实现”。
简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。一个工作流包括一组任务（或活动）及它们的相互顺序关系，还包括流程及任务（或活动）的启动和终止条件，以及对每个任务（或活动）的描述。
工作流在大多数的实际应用中的情况可以这样来简单地描述：在网络、服务器和多台计算机客户端的硬件平台上，业务过程按照预先设定的规则并借助应用程序和人对相关数据的处理而完成。例如，在日常办公中，当撰写好某份报告之后，可能需要将其提交给领导进行审阅或批示；审批意见可能需要汇集并提交给另外一个人，以便对报告进行进一步的修改。这样，可能会形成同一篇文档在多个人之间的顺序或同时传递。对于这样的情况，我们可以使用工作流技术来控制和管理文档在各个计算机之间自动传递，而非手工传递。这就可以称之为工作流。
类似的关于文档的自动化处理只是工作流技术的一种简单应用。事实上，工作流技术在现实生活中能够完成更多更复杂的任务。如企业（或机构）内部的各种数据或信息的自动处理，多种业务流程的整合，企业（或机构）之间的数据交换，借助Internet技术实现跨地域的数据传输和处理等等。
工作流的特点：
1. 图形化、可视化设计流程图
2. 支持各种复杂流程
3. 组织结构级处理者指定功能
4. B/S结构，纯浏览器应用
5. 强大的安全性特色
6. 表单功能强大，扩展便捷
7. 灵活的外出、超时管理策略
8. 处理过程可跟踪、管理
9. 丰富的统计、查询、报表功能
10. 与MAIL系统集成
正因为工作流有以上特点，所以工作流在企业管理软件中广泛使用。企业实施工作流管理所带来的好处是非常明显的，这包括提高企业运营效率、改善企业资源利用、提高企业运作的灵活性和适应性、提高工作效率、集中精力处理核心业务、跟踪业务处理过程、量化考核业务处理的效率、减少浪费、增加利润、充分发挥现有计算机网络资源的作用。实施工作流将达到缩短企业运营周期、改善企业内（外）部流程、优化并合理利用资源、减少人为差错和延误，提高劳动生产率等目的。
9.7.2 工作流系统的主要组成部分
l 过程定义工具
过程定义工具被用来创建计算机可处理的业务过程描述。它可以是形式化的过程定义语言或对象关系模型，也可以是简单地规定用户间信息传输的一组路由命令。
l 过程定义
过程定义（数据）包含了所有使业务过程能被工作流执行子系统执行的必要信息。这些信息包括起始和终止条件、各个组成活动、活动调度规则、各业务的参与者需要做的工作、相关应用程序和数据的调用信息等。
l 工作流执行子系统（WES）和工作流引擎
工作流执行子系统也称为（业务）过程执行环境，包括一个或多个工作流引擎。工作流引擎是WFMS的核心软件组元。它的功能包括：解释过程定义；创建过程实例并控制其执行；调度各项活动；为用户工作表添加工作项；通过应用程序接口（API）调用应用程序；提供监督和管理功能等。工作流执行子系统可以包括多个工作流引擎，不同工作流引擎通过协作共同执行工作流。
l 工作流控制数据
指被WES和工作流引擎管理的系统数据，例如工作流实例的状态信息、每一活动的状态信息等。
l 工作流相关数据
指与业务过程流相关的数据。WFMS使用这些数据确定工作流实例的状态转移，例如过程调度决策数据、活动间的传输数据等。工作流相关数据既可以被工作流引擎使用，也可以被应用程序调用。
l 工作表和工作表处理程序
工作表列出了与业务过程的参与者相关的一系列工作项，工作表处理程序则对用户和工作表之间的交互进行管理。工作表处理程序完成的功能有：支持用户在工作表中选取一个工作项，重新分配工作项，通报工作项的完成，在工作项被处理的过程中调用相应的应用程序等。
l 应用程序和应用数据
应用程序可以直接被WFMS调用或通过应用程序代理被间接调用。通过应用程序调用，WFMS部分或完全自动地完成一个活动，或者对业务参与者的工作提供支持。与工作流控制数据和相关数据不同，应用数据对应用程序来讲是局部数据，对WFMS的其他部件来说是不可见的。
9.7.3 工作流五大接口
l 接口１
许多不同厂商提供的工具可以进行工作流流程的分析、建模、描述和归档等工作。这些工具需要识别公共的流程交换格式，以支持在这些不同的产品之间传送工作流程流程定义。接口1便定义了这样的交换格式。此外，接口1还定义了设计环境与运行环境之间交换的规范，以使不同的建模工具产生的流程定义可以输入到不同的工作流产品的运行环境中。
为了提供一个访问和描述工作流定义的公共方法，需要引入一个工作流元数据模型（meta－data Model），这个模型确定了流程定义中用到的一般的实体，这些实体都有不同的属性，不同厂商开发的工具可以根据公共的交换形式向工作流运行环境传送这些模型，传送可以通过API实现，也可以通过批量（Batch）传送实现。
元模型
元模型提供了流程定义交换中用到的基本的实体及其属性，这些都是工作流流程的组成部分，这些实体包括：
² 工作流流程定义
² 工作流流程活动
² 过渡信息（Transition Information）
² 工作流参与者
² 组织模型
² 工作流应用程序
² 工作流相关类型
² 工作流相关数据
² 系统和环境数据
² 数据类型和表达式
流程定义的交换
在不同的系统之间传递流程定义数据可能需要不同的机制，但在所有的情况下，流程定义数据的表达必须是一致的，这些表达包括一些公共的对象、关系及其属性。
l 接口２与接口３
工作流管理系统必须提供同用户之间交互的通道，以便用户参与到系统的运行中。接口2主要完成这方面的功能。
WfMC在关于接口2的规范中定义了工作流管理系统必须提供的类型、数据结构、API和错误代码，并以C语言头文件的形式提供。接口2所提供的功能大致可以分为一下五个方面：
1、会话的建立和与撤销；
2、获取工作流流程定义及状态；
3、工作流流程实例的操作，如创建、挂起、终止流程，获取和设置流程属性等；
4、工作流活动实例的操作，如获取和设置活动的属性，改变活动的状态等；
5、工作列表（worklist）及工作项（workitem）的操作，如获取工作列表，处理工作项等。
通过这些功能，用户可以完成与工作流管理系统之间交互的所有任务：登录系统、打开自己的工作列表、处理自己的工作任务、将完成的任务提交给系统、将自己的任务转交给其他用户等等。
具体的函数声明不再详述，可以到WfMC的网站（http：//www.wfmc.org）去下载有关规范。
工作流系统在运行过程中有时需要调用外部应用程序，以完成系统不能完成的工作（比如，发送Email或传真，扫描文件等），或者与其他系统集成到一起。此时可以通过接口3来完成。
接口3的功能同接口2的功能大部分是相同的，因此，这两个接口有融合的趋势。接口3主要规定了调用外部应用程序的函数规范，以及外部应用程序返回数据的格式。
l 接口４
在企业级的工作流系统中，流程往往需要跨越多个服务器或系统，比如应用于跨国公司或大型集团公司的工作流系统经常会有这种的需求，此时就需要服务器或系统之间进行通讯，交换流程控制信息和流程定义等数据，以实现流程跨地域运行。WfMC在规范中以C函数的形式提供了这些控制的定义，其中包括以下几个方面的功能：
1、创建流程实例；
2、获取流程实例状态；
3、获取和设置流程实例属性；
4、启动或终止流程实例；
5、改变流程实例的状态；
6、改变流程实例的属性；
7、更新流程实例。
服务器或系统之间信息交换的格式有多种，例如：文件、数据库表、E-mail或直接通过网络传送的数据流等等。
l 接口５
此接口提供给用户管理和监控系统的运行状态、查看系统运行的历史记录的功能。WfMC在此接口的规范中定义了各种审计信息的数据格式，这些格式包括：
1、流程实例（Process Instance）审计信息：包括创建、启动流程实例和子流程实例的审计数据；流程实例状态变化的审计数据；流程实例属性变化的审计数据；
2、活动实例（Activity Instance）审计信息：包括活动实例状态变化的审计数据；活动实例属性变化的审计数据；
3、工作项（Workitem）审计信息：包括工作项状态变化的审计数据；工作项分配合重新分配的审计数据；工作项属性变化的审计数据；
4、远程操作审计信息：包括开始和停止会话（Session）的审计数据；远程创建流程实例和远程改变流程实例状态的审计数据；远程获取和设置流程实例属性的审计数据；会话管理的审计数据；
5、流程定义审计信息；
6、扩展的审计信息及专用的审计信息。
这些审计数据在系统运行时刻由系统自动记录在数据库或文件中，可通过系统提供的API进行统计和查询，或者通过系统工具导出到系统外部。
另外，此接口还要提供系统管理与流程控制的功能，如：系统流程数据的备份和恢复，用户管理，流程管理等等。
9.7.4 工作流元素
工作流元素包括流程、活动、数据项、决策状况、参与者、动元等，图9-43是工作流元素的应用。
图9-43 工作流元素
流程复杂：多部门会签、独立的会签流程、并发和顺序、数据在主流程和会签流程之间的交换流转过程的动态计算（条件分支）等。
人员动态计算：根据部门和职位计算、根据用户选择分配等。
图9-44 复杂的工作流
9.7.5 工作流WorkFlow技术构架
图9-45 工作流技术构架设计
WorkFlow主要是由html和脚本生成，数据传输是靠XMLHTTP（即AJAX）来完成的，而初始化、提交流程都需要调用它的WebService接口，为了调用方便及性能考虑，现采用了由表单发送请求到一个指定的页面，再由页面调用WebService接口来初始化或提交流程信息，并返回是否成功的结果给表单，然后表单再进行相应的业务处理。
l 逻辑架构
WorkFlow主要是由工作流定义、工作流引擎、工作流监控组成。逻辑结构上分为数据信息存储、业务逻辑处理、用户界面展现，见图9-46：
图9-46 工作流逻辑构架图
建模工具
建模操作：拖拽、粘贴、上传、下载、存储等。
调试仿真：单步跟踪、断点设置、数据修改等。
建模操作
图形化操作：拖拽、缩放、复制、粘贴、属性对话框等。
登录。
持久化操作：上传、下载、本地XML文件存储和打开。
其他：打印等。
调试仿真：：动态调试、单步跟踪、断点设置、数据的实时查看和修改。
l 设计流程图
图9-47 工作流流程图
Ttyu.Net工作流开发架构支持微软.Net平台，符合工作流国际标准（WfMC），具备工作流中间件所需要的各种必要特性，并具备中国企业文化特色，能够支持各行业应用对工作流技术的要求，也可以作为企业应用二次开发工具或应用集成平台。
Ttyu.Net工作流平台融入了新一代管理软件关注的重点思想，所有功能模块应用将权限体系、工作流引擎体系、表示逻辑体系、管理控制逻辑体系、扩展及个性化接口体系充分结合，从架构的设计上优化企业个性化业务系统实施成本，并通过流程管理工具，为企业实施个性化的企业流程，通过记录、监督、跟踪、回访、分析企业日常事务，持续改善企业管理流程，Ttyu.Net工作流平台开源的开发架构设计过程中充分分析了管理行为中人的特性，基于Ttyu开发的企业流程应用系统提供了事中监督、事后回访、全程跟踪的体系架构，E8工作流引擎功能设计中也充分考虑了流程和环节模型特性、环节行为人群体特性和中国特色，流转过程中基于权限体系提供了人为因素中“主动/被动”异常的解决思路，解决快速实施企业业务流程需求的同时，又提供了人性“非理想”状态下的异常解决方案和防范控制解决方案。
l 面向框架的技术构架
面向框架的编程方法在提高软件开发效率、保障产品质量、降低开发及维护成本方面具有无可比拟的优势。Ttyu.Net开发架构支持微软VS2005（SP1）开发环境，支持SQLServer2005。Ttyu.Net开发框架源码包括主界面、菜单结构、界面样式表定义、用户界面皮肤、站点地图、应用表单母版页、基础控件包等等；已实现应用功能包括组织结构管理、用户管理、授权控制、待办事项、出差授权、信息发布、在线短信息、查看流程图、流程发起、流程跟踪等等功能。
图9-48 面向框架的工作流功能
Ttyu.Net是基于Micrsoft .Net Framework开发的二次开发架构，有大量可重用的模块、组件、控件和代码，为企业积累可重用开发成果的同时又可以节约开发成本和维护成本。这些组件包括引擎开发架构、业务对象模型、服务架构、业务数据接口、组织结构开发接口模型、组织结构对象模型、企业流程控制台等，技术架构图如下：
图9-49 工作流技术构架
l 可视化流程建模工具
流程设计工具提供了丰富的流程图形元素，流程管理人员可在设计界面中采用拖拽方式直观地设计出复杂的业务流程。该设计工具可以实现串行、并行、循环、会签等流程逻辑关系，支持普通环节、机构环节、普通会签和机构会签环节，支持流程嵌套和流程衔接设计，支持动态设置环节参与者，支持为流程路向设置复杂判断条件，支持特殊权限如流程退回、撤销、跳转、指定时限、指定下一环节接收人、允许上传附件等，可以定义各种复杂流程逻辑。当流程设计完毕后，它还可以即时进行流程校验，方便流程调试和优化。
图9-50 可视化流程建模工具
l 工作流引擎
引擎为流程实例提供运行环境，并解释执行流程实例的软件部件、应用控制和运行的中心，负责解释、控制并协调各种复杂流程的执行。Ttyu.Net工作流可以为企业数据库应用提供事务完整性、安全性、扩展性、冗余与动态负荷分派。
启动流程视图展示逻辑如下图所示：
图9-51 工作流引擎
Ttyu.Net2005开发架构提供异步服务框架，提供异步处理调度逻辑，方便用户实现异步处理需求，如：超时提醒、告警提示、自动处理、自动启动流程等业务需求，具体实现跟业务需求有关，Ttyu.Net开发版提供服务引擎扩展的源代码。引擎服务扩展安装后成为一个windows服务，服务启动后服务引擎调度执行服务处理类，服务处理类继承于服务处理父类，可以根据具体服务类配置调度属性，根据调度属性决定服务执行模式。Ttyu.Net2005开发架构提供支持移动应用的开发框架，方便实现移动终端通过GPRS或CDMA网络接入工作流应用平台，达到随时随地管控业务流程，重要信息第一时间提醒并在线批示解决的目标。
图9-52 工作流应用平台
9.7.6 工作流扩展
Ttyu.Net工作流开发包是支持.Net开发工具的源代码程序包，因此微软.Net能做到的，Ttyu.Net工作流开发包都可以做得到，这给程序员提供了无限的灵活扩展能力。
l 工作流引擎扩展
服务引擎扩展异步服务运行架构，提供异步处理调度逻辑，方便用户实现异步处理需求，如：超时提醒、告警提示、自动处理、自动启动流程等业务需求，具体实现跟业务需求有关，Ttyu.Net开发版提供服务引擎扩展的源代码。引擎服务扩展安装后成为一个windows服务，服务启动后服务引擎调度执行服务处理类，服务处理类继承于服务处理父类，可以根据具体服务类配置调度属性，根据调度属性决定服务执行模式。
l 开发架构扩展
工作流应用开发架构包含了历年来工作流引擎架构的最佳实践，企业进行二次开发时不需要再做多少修改，Ttyu.Net开发版提供了工作流应用开发架构的源代码，企业可以根据自身的需求和特性进行扩展，包括：流程应用架构、工作流表单母板页、应用系统布局、站点地图扩展属性等等。
l Office Server产品开发扩展
Office SharePoint Server作为企业EIP门户，工作流应用系统可以集成，通过各种Webparts技术、SSO技术、Features技术、KPI和仪表盘技术将流程应用信息有效的与工作流应用系统集成起来。
l 商业智能（BI）应用扩展
企业开发者可以在工作流基础上开发商业智能应用，将工作流及业务数据作为数据源头，设计和生成数据仓库，并结合Office Server产品、Reporting Service或其它数据仓库工具，为企业用户提供商业智能应用，实现企业愿景。
企业开发者可以以Ttyu.Net工作流平台为基础，在开发包基础上通过二次开发与企业ERP、CRM、财务、HR等软件系统实现应用级别上的集成，实现信息系统互联互通，解决历史遗留的信息孤岛问题。
9.7.7 数据模型设计
工作流数据模型主要包括TB_Work（工作表单）、TB_WorkFlow（工作流）、TB_Templet（工作流模板）、TB_ShenHe（工作流审批执行情况）、TB_AuditingMan（工作流审批人）、Dept（部门）、TB_ChildNode（工作流子结点）组成，如图9-53：
图9-53 工作流数据模型关系图
9.8 自定义表单组件
在软件系统中，由于应用环境的变化，用户常常需要使用一些根据一定业务规则设计出来的表单，但是程序设计时往往不能够预先清楚在系统交付后，用户在日积月累的应用中所需要的各式各样的表单形式，因为需要不断的开发新的表单以对应用户的需要。
通过规纳一般性要求，统一变化。自定义表单使得用户在系统交付后的使用过程中，通过系统预先设计好的通用程序来生成具体的表单。
自定义表单的用途比较广泛，在OA的自定义工作流程中、CMS功能扩展、自定义调查中都将涉及到。为什么要使用自定义表单呢？试想一下，如果某个系统中没有自定义表单功能，而要实现增加功能或系统扩展，会怎么样？这时只能依靠界面设计师与程序员配合再做一个表单及编写代码来处理表单，处理表单的代码是枯燥而机械重复的，因为这样的代码无非是一些增、删、改、插，对一般的程序员来说，似乎太简单了；对一个项目来讲，如果客户需要的表单很多，可想而知，这样的代码将会有多少重复的，虽然生成代码的工具不少，可以减少一些工作量，但也会让整个系统变的更庞大，维护也不是那么方便，假如客户要加个数据项或改个什么的，整个项目又得重新编译。诚然，开发一套自定义表单系统是需要耗费不稍精力，占用一些项目时间，但有了这个平台之后，对以后的其他项目开发或者系统本身的功能扩展还是有很大帮助的。
上面列举了一些自定义表单的种种好处，我们应该怎么实现它呢。自定义表单就是将上面的情况进行抽象，通过表单的定义自动创建/修改自定义数据表、动态生成数据表操作的SQL语句并执行。当然首先要知道一般的自定义表单系统包含哪些功能。
9.8.1 自定义表单技术构架
自定义表单技术构架由客户端、应用层、数据层组成。客户端是表单的用户界面表现，主要由Web页面组成，一般有HTML Form、XFDL Form、JSPForm、Aspx From等；应用层是表单的业务逻辑的实现部分，是表单的核心层；数据层是表单存储的物理层，表单数据信息以么样的格式么样的存储方式保存。自定义表单技术构架如图9-54所示：
图9-54 自定义表单技术构架图
l 表单定义管理
表单界面设计：这一步是很关键也是较难实现，简单的做法是做一个表单模板，那么表单中的数据项说明、编辑框、数据验证就都可以用内部变量来代替，系统可提供自动生成表单的功能，用户也可以自己手工修改。
表单存储表字段定义：定义表单中用到的数据项，包括字段名、字段类型、长度、默认值、编辑框类型、是否允许为空、是否自增长字段、分组名称、是否在列表中显示等信息。编辑框类型一般有：文本框、文本域、复选框、单选框、列表框、时间日期选择、文件上传框等。
表单数据验证定义：定义需要验证字段的规则，验证规则，可用正则表达式的方式来定义，系统内部可自带一些常用的验证规则，复杂的情况可能会出现各字段之间的值进行比较的情况。
表单字段关联/子表单管理：定义表/表单之间的关联信息，即主键外键信息。
表单字段编辑框行为定义：主要负责处理字段值发生变化时引发的其他编辑框事件，比如连动下拉框、从选择值中返回值并赋予其他字段编辑框、其他编辑框的隐藏等。
l 表单运行时呈现及提交
根据表单定义的布局及其他设置呈现表单，并一起生成验证、行为用到的JS代码。如果填写表单时，先填主表信息，然后填写从表信息，多个表单之间要进行跳转，保存的临时表单值可采用SESSION进行传递，最后一起提交，提交时先写入主表信息，并返回主键值（如果存在主从表的话），然后写从表数据。
l 表单数据管理
可根据字段配置信息显示表单的数据列表，并进行管理，这一步实现比较简单。
9.8.2 自定义表单结构
图9-55 自定义表单结构图
采用一个页面解析引擎，通过查找界面元素定义表（这个表后面有定义，也可以是xml定义），获得对应页面的元素信息，采用xslt来生成html界面。
上面提到的数据表（或者xml文件)用来管理页面元素和对应的数据表结构字段信息以及页面元素的表现。
自定义表单应该支持对Dreamweaver，FrontPage等流行网页编辑器编辑的html文件导入。将表单的制作从代码级别转化为可视化的用户界面，能更灵活的满足客户的需求。
表单模板引入了参考模板的概念，指的是将一些具有固定格式的文档做成html格式的表单，任何流程的表单在新建和编辑时，都可以在参考模板的基础上进行修改和再编辑。
参考模板：如果我们发起一个请假流程时，请假单就可以是一个参考表单。
自定义表单参考模板可以分为自定义JSP、定制表单、系统默认表单等，让用户按自己最熟悉的方式可以灵活地选择，如图9-56。
图9-56 可选择的三种自定义表单
l HTML模板
采用HTML模板方式。对于每一种样式的表单定义HTML模板；在模板中定义Web页面的HTML界面代码，在需要读到数据库数据的地方用特殊字符代替；当用户访问页面时，先从数据库中取得所有相关数据，然后根据指定的模板路径读入HTML文档内容，通过“模板标记解析器”用取得的数据替换掉模板中的特殊标记，然后将整个HTML文档显示出来。
图9-57 HTML模板
l XML+XSLT模板
采用XML描述数据，XSLT定义XML数据显示格式。通过XSLT来控制数据的显示；查询数据库返回XML格式数据，将XML保存到临时文件，通过XSLT来解析XML数据文件生成HTML代码，最终将HTML代码显示到前台页面中。
图9-58 XML+XSLT模板
9.8.3 在线表单编辑器
在线表单编辑器直接采用拖拉的方式在页面上摆放控件，设置控件的属性，事件。所见即所得。设计好的表单可以直接运行，如图9-59是一个有代表性的在线表单编辑器。
图9-59 在线表单编辑器
在线表单编辑器根据一定业务规则设计出来表单，其通用性决定它的用途是普遍意义的录入及查询。设计出来的表单没有严格意义的权限划分，因为它不属于受外因干扰的功能模块。
在线表单编辑器应该具有以下的特性：
l 在线表单编辑器也在页面上工作
不象其它的表单设计器都是EXE或一个大的控件等方式，在线表单编辑器就是用一个HTM的网页来实现的。可以直接在互联网下流畅地执行。
l 易于使用
对于使用在线表单编辑器的人员的几乎没有什么技术要求，只要通过界面操作便可设计好表单，即时的简明扼要的帮助，新建表单向导，生成SQL语句向导等等，使得无须培训便可开始使用。
l 快速生成编辑表单
无论是单表输入，还是一对多表，一对多多表输入；无论是用编辑框视图还是直接用表格输入；无论是简单的增加，修改，删除，还是复杂的多表同时编辑；都可用在线表单编辑器设计出来。
l 种类齐全的控件
不仅仅有最常见的label、textbox、combobox等最常见的控件，还应该有页签控件、spin、shape、checkboxlist、radiolist、dropdownlist、webgrid、tree、upload等等。
l 支持Ajax
l采用xmlhttp和后台进行交互，支持局部更新，异步调用。交互性能非常好。XML技
术在在线表单编辑器中几乎无所不在。
l 数据层和样式层分离
在线表单编辑器采用数据集作数据层，样式层采用HTML，CSS等标准的网页技术。
系统结构简单灵活，非常利于扩展。
l 多样的数据验证
除了判断不能为空，是否为数字，值的范围等常见的验证之外，还包含是否为电话号
码，是否为身份证号，是否包含汉字等等，几乎包含了所有能想到的验证。
l 可在页面上编辑数据库的表结构
内包含一个页面的编辑数据库的表结构的工具，可以用它直接在页面上新建表，编辑
字段，删除表，设置主键等常用操作。
l 活动可多个表单共存
当需要切换定制表单时，只需要选中该表单进行激活；当需要采用系统默认生成的表
单，点击取消激活后，编辑的表单都不会起作用。
9.8.4 数据项映射
数据项映射是指通过配置的方式，将流程数据项映射到业务数据库表，从而无须编程就能实现流程数据与业务数据的互通与同步。
数据项映射的意义是什么？有助于实现流程数据与业务数据的分离；有助于和第三方业务系统在数据库层面上实现集成；有助于平台与系统其他组分间的解耦。对自定义表单的意义尤其重要；有助于实现针对业务数据的统计和查询。100%用流程数据表达业务知识费时费力。
l 数据项映射的实现
数据项映射实现数据项与数据库字段的关联，图9-60体现这种关系：
图9-60 数据项映射关系
图9-61 数据项映射流程
定义Database Object类型数据项，指定流程执行期间可供使用的SQL语句，指定数据库表字段与普通Java数据类型的映射关系。
在流程关键环节定义DBObjectActlet动元，指定实际使用的SQL语句，指定普通Java数据类型与流程数据项的映射关系。
数据项映射的实现和表达式特性结合，实现SQL语句的条件执行；和Data Set类型的数据项结合，实现表格式数据的提取与展现。采用纯粹的O/R映射机制，数据项直接映射至业务数据表中实体
l 数据项映射功能要点
1. 面向标准SQL，易于掌握，且能对关系数据库实施精确控制。
2. 流程数据项的映射与绑定是可配置的，流程数据项可作为SQL语句执行所需的传入参数，并对业务数据库进行访问。如：根据用户通过表单输入的订单编号查询业务数据库。SQL查询结果可绑定到指定的流程数据项上。如：从数据库中查出一条订单记录并自动赋值给一组数据项供表单显示
3. 批量执行多条SQL语句，且执行顺序可调。
4. 内置的事务支持，无须配置，对使用者透明。
5. SQL语句在流程范围内可被复用。
9.9 内容管理组件
内容管理实现信息的采集、编辑、审批、发布等，实现大型信息门户的信息管理的能力。
9.9.1 需求分析
一个网站的运行需要经历规划、内容采编、展现设计（UI）和最终发布几个环节，下面将分别对这几个业务流程进行描述。
l 网站规划与管理
网站规划是需要确立站点的内容结构、运行结构。
首先需要根据网站定位和商业目标分析确定包含哪些子站点、频道，这些子站点、频道应该有什么样的内容，这些构成了网站的内容结构。
其次需要根据内容结构确定内容采编与发布等一些列工作规范，并建立相应的组织结构，分配工作角色。
一个门户网站在运行过程中会不断地根据市场变化进行调整，这些调整会涉及到子站点、频道的内容定位、展现形式等的调整。所以网站规划及其管理工作不是一次性，而是在运营过程中持续的。
l 内容采编与管理
在网站结构确定之后，后续分为两方面的工作，一个是对展现的控制，一个是内容的采编和管理。内容采编与管理的工作由内容编辑人员和内容审核人员承担，编辑人员的任务是通过系统将内容录入到系统中，审核人员的任务是通过系统对编辑录入的内容进行审核，通过审核的内容才能被发布到网站被用户阅读到。
l 展现控制
对于每个网站来说，把内容用什么形式展现给用户都是至关重要的。因此展现控制也是网站运行过程中的一项重要工作，这部分工作通常是由专业美术人员按照网站规划中的业务目标和内容的特点进行策划，确定首页、各频道页面的展现布局，并进行美术制作。然后再由版面制作人员进行相关的模版制作，确定各功能和内容块的布局，最终通过模块的布局把展现形式定义到系统中。再由发布功能把内容与展现相结合形成最终的站点。
展现控制是通过定义模板来实现的。模版即每一个站点、频道、文档显示的总体样式，站点、频道中一些固定不动的元素，如每一个频道中的频道头、频道尾、菜单等，模块中的栏目图标、背景等。网站是否美观，完全取决取决于模版设计，制作人员可以使用统一的模版来实现界面样式的风格统一化的管理，当然也可以通过局部应用自定义模板实现的个性化风格。
表9-39描述了内容管理组件中角色所完成的功能操作：
表9-39 内容管理角色功能操作表
| 角色名称 |
操作 |
| 站点管理员 |
确定站点结构和内容目录 |
| 采编人员 |
文字处理工作：对文档进行组织、编辑、修改、归类、保存，提出发布申请 |
| 内容审核员 |
确定文档是否可以发布。 |
| 界面管理员 |
界面及站点结构设计：编辑、制作界面模版，定制界面风格，定制模版内容 |
| 发布审批员 |
审核、确认、发布批准已提出的申请，发布并更新网页 |
| 系统管理员 |
负责系统基础信息和运行管理 |
各种角色在从录入到页面最终发布出来这一流程中的作用，如下图所示：
图9-62 内容管理流程图
9.9.2 总体架构设计
内容管理组件包括站点管理子模块、网上调查、调查管理模块、发布服务、模板管理、站点维护等内容，如图9-63：
图9-63 逻辑功能模块构成
系统技术结构
图9-64 系统技术结构
l 站点管理子模块
系统管理员在站点管理子模块中创建、修改、删除站点。
图9-65 站点管理子模块业务实体
l 网上调查模块
具有网上调查管理权限的管理员可通过此模块来管理网上调查主题，问题及选项，并生成引用代码。
图9-66 网上调查模块业务实体
l 站点维护模块
站点维护模块是内容管理日常工作的主要模块，包括站点配置、界面管理、采编发、发布管理几个子模块。
l 内容编辑与审批
图9-67 文档管理
图9-68 文档审批
l 频道发布审批
图9-69 频道发布审批
9.9.3 发布管理子模块
l 发布管理总体结构设计
图9-70发布管理总体结构设计图
l 发布管理业务功能组件
完成与发布管理相关的接作。实现发布服务器的添加、修改、删除、执行、预览以及任务调度的添加、修改、删除等功能。
图9-71发布管理业务功能
l 发布管理业务实体组件
图9-72 发布管理业务实体
9.9.4 发布服务模块
站点发布过程如图9-73：
图9-73 站点发布流程
9.10 广告管理组件
广告和宣传功能是门户的基本定位之一。随着互联网的大量普及，网络广告已经成为商家宣传产品，塑造品牌的有效手段。广告投放系统能够将广告投放计划和网站每个站点、频道的广告位置资源进行动态、智能的匹配，精确定位目标客户，同时记录曝光数量、点击数量等各种测量数据。充分利用网站的资源为广告投放计划服务，带来高点击率，并提供多种详实的统计报表，以量化广告成本和效益，为今后的广告与营销活动提供依据。广告管理功能包括：
l 广告资源管理
对于门户中的广告类型、广告位进行管理，并能够根据实际情况设置多种销售套餐，广告套餐的形式可以是对多种广告位组合、多种收费方式、和不同地区等属性进行组合设置折扣而进行销售的一种形式，对于该种套餐形式的广告资源，资源管理可以这些单条资源打成不同形式的广告资源包。
l 广告客户管理
对于广告客户信息、业务信息进行管理。
l 发布管理
按发布策略进行广告发布与投放，并配合个性化系统实现个性化广告。
l 结算管理
根据广告投放结果进行收费管理，包括各协作站点群利益分配。
9.10.1 广告资源管理
广告资源是可以销售的广告位资源，广告位分布在企业门户网站的各个页面上，广告客户可以选择感兴趣的广告位来发布广告，因此对广告资源的销售也就是对广告位的销售，产品管理的目标不但是为销售做准备，更是为今后怎样来发展广告客户，怎样来对广告产品进行丰富而提供依据，因此需要定义出可销售的广告产品，作为一个广告产品，是指在最终用户可见的页面上的某种表现形式，如，首页上的Banner，或某个页面上的图片，或者是嵌入在文字中的flash等。
在广告产品销售前，应该由站点的规划人员来定义出广告产品，就是根据站点、频道、页面展现形式来合理的安排出适当的位置作为广告投放的目标。
在规划完成后，需要在系统内对不同的广告产品进行定义，系统提供一些预定义的广告模式，如：横幅广告、文字广告、Flash广告等。每一种类型的广告都有一定的描述性元数据。不同的广告栏和广告类型组合。同时在定义一个广告的时候，根据每种不同类型的广告，需要结合广告展现的内容（如：具体的图片、Flash等）。广告内容可以由广告客户提供，也可以由门户制作团队提供广告创意和内容制作服务来完成。广告模版和广告内容结合在一起就是一个具体的广告。
广告定义人员可以在首次规划的基础上进行二次规划，即将多种广告资源按照不同条件组合起来形成广告套餐，显示套餐总价，然后设定不同的折扣率，以实现多种不同的广告套餐。
表9-40描述了广告资源中角色所完成的功能操作：
表9-40 广告资源管理的角色功能操作
| 角色名称 |
操作 |
| 广告位管理人员 |
l 定义广告的元数据 l 创建广告位 l 修改广告位 l 删除广告位 l 查询广告位 |
| 广告定义人员 |
l 定义广告套餐 l 创建套餐组合 l 修改套餐组合 l 删除套餐组合 l 查询套餐组合 |
业务场景描述及规则
l 查询广告位
广告位管理人员可以根据广告位编码，广告位名称，所属站点，所属频道，广告位类型，查询自己所管理的广告位信息。管理员可以查询4个门户网站中的所有广告位信息。
l 创建广告位
广告位管理人员可以在系统中创建新的广告位。创建广告位时需要指定广告位所属站点，所属频道、广告位编码，广告位名称，广告位性质，类型和尺寸规格，计费模式，资费标准，广告位状态等信息。
l 修改广告位属性
广告位管理人员可以修改已创建完毕的广告属性，对于正在被使用的广告位不能修改其属性。
l 删除广告位
广告管理人员可以删除各自管理范围内的广告位，但一个广告位的删除会影响到其它已经发布的广告历史的信息，所以系统中没有真正的删除广告位，而是采用软删除的方法，所谓的软删除实际上就是通过改变广告位在数据库中的状态，不显示给用户，而数据库中却存在，只不过状态为停用标记。
l 创建套餐组合
广告定义人员可以在系统中已创建的广告位上挑选出部分空闲广告位来进行包装，形成一个套餐，并定义折扣率，与总价相乘后形成套餐价格。
l 修改套餐组合
对于未销售的套餐，广告定义人员可以修改其套餐内容，定制新的价格以吸引客户。对于已销售套餐能进行修改。
l 删除套餐组合
广告位定义人员可以删除各自管理范围内的广告套餐，如同广告位删除一样，删除套餐同样也是进行软删除，对数据库中的广告套餐数据设置停用标识。
l 查询套餐组合
广告定义人员可以查询自己所能管理范围内的所有套餐，查看各个套餐的广告位属性，以及历史销售状况等。
9.10.2 广告客户管理
在完成了产品规划之后，可以联系客户进行广告销售，销售相关的过程统一称为客户管理。
当业务人员与客户确定了销售合同之后，此时客户应选择了相应的产品，也确定了费用。业务人员通过客户管理登记客户的信息，通过订单管理登记订单的信息，订单管理可以对广告进行投放前的一些设置。
表9-41描述了广告客户中角色所完成的功能操作：
表9-41 广告客户管理的角色功能操作
| 角色名称 |
操作 |
| 广告客户管理员 |
广告客户管理功能负责对广告客户信息进行维护，广告客户是广告内容与广告素材的提供者。 l 查询广告客户 l 创建广告客户 l 修改广告客户 l 删除广告客户 |
业务场景描述及规则
l 查询广告客户
广告客户管理员可以通过广告客户编号，名称，地域信息来查询广告客户信息，通过对广告客户信息的查询可以了解网站的客户资源及其省份分布，为营销提供基础数据。
l 创建广告客户
广告客户管理员可以通过获取广告客户编号，广告名称，区域，代理商，联系人，电话，备注等信息来创建广告客户信息，在创建广告客户信息的时候要注意广告客户编号不能重复，因为编号是广告客户的唯一的约束。同时在创建广告客户成功后系统会自动分配给此广告客户一个用户名，与密码，广告客户可以通过用户名密码来登录系统查看自己的业务数据。
l 修改广告客户信息
广告客户管理员可以通过广告客户编号，获取广告客户信息，并对其进行修改，在修改的时候广告客户编号不能修改，因为一旦广告客户的编号进行了修改会影响到直接与广告相关的业务信息。
l 删除广告客户
系统是通过对广告客户信息打删除标记来完成对广告客户的软删除，广告客户管理员在删除广告客户信息的时候，可以通过广告客户属性等来查看该客户是否进行过广告投放，如果广告客户曾经或者现在正在有广告投放，那么不能删除广告客户。
9.10.3 广告发布管理
在销售之后，广告需要发布到页面中，让最终用户看到，广告发布的可以包含两个流程，即广告发布流程和广告展现流程。
l 广告发布流程
广告客户提出广告需求后，广告销售人员可以在系统中查询可用的广告资源(广告位和时间安排)并进行广告排期预约。广告内容的准备可以发生在排期之前或者之后，广告内容准备好后提交到系统，进行内容审查。审查人员检查广告并对其进行批准。广告内容具备并且通过审查后，就可以对预约进行确认，进入实际生产发布队列。进入实际生产队列的广告就可以在预定的时间发布到门户上。
发布前准备：
图9-74 广告发布流程
新站点建立后，没有任何数据，需要录入频道信息、广告位信息、广告客户信息，作为录入广告订单中投放的前提条件。只有录入投放保存成功后，才能录入广告创意。
做好发布前的准备工作之后，接下来就进入了广告投放流程：
图9-75 广告投放流程
只有在订单中才能添加投放。一个订单可以完成多个投放。每个投放针对不同频道广告位的性质和广告代理商的访问类型等录入创意和定向。一个投放允许有多个创意并存。
l 广告展现流程
首先企业门户网站应该把广告系统生成的广告推送代码设置在相应的广告位页面上，当最终用户通过客户浏览器浏览网页时，首先设置在网站页面上的广告代码会向广告管理服务器发出展现广告的请求，广告管理服务器会根据请求中包含的广告位信息(如：广告位编号等)，对频道的广告位置资源进行动态、智能的匹配，按照地域定向精确定位目标客户，然后从广告Banner服务器中检索广告资源(如：图片、Flash等)，并交给广告管理服务器上的广告投放服务进行投放。同时记录曝光数量、点击数量等各种测量数据。
图9-76 广告展现流程
表9-42描述了广告展现中角色所完成的功能操作：
表9-42 广告展现的角色功能操作
| 角色名称 |
操作 |
| 广告发布管理员 |
l 广告订单管理 l 广告投放管理 |
业务场景描述及规则
l 广告订单管理
广告订单用于记录和控制广告销售与广告投放的行为。广告订单可以通过订单编号，日期，操作员来查询。广告订单的属性包括：订单编号、广告商、订单状态、订单日期。一个广告订单可以包含一个或多个广告投放。
l 广告投放管理
广告投放总管理员可以对把广告投放到企业门户的广告位。
各门户需要做的准备工作是：在广告管理系统中创建门户网站的广告位，分配广告位编号；同时，在本门户网站的网页上嵌入调用广告系统的代码。
对于广告销售人员，在投放广告前，首先可以查询企业门户中所有可用的空闲的公共的广告位，其中广告位是否为公共状态，可以由各网站人员来设置，一旦把广告位设置成公共状态，广告投放总管理员就可以统一调配广告位资源。具体在设置广告投放的时候，指定将广告投放到门户的广告位上即可。
用户浏览该门户网页的时候，由于网页中嵌入了调用广告系统的代码，浏览器会向ATR总广告系统请求广告。总广告系统将查询该广告位上投放的广告并按照系统定义的策略将广告内容推送给用户。
9.10.4 结算管理
对于发布到门户网站上的广告，计费数据的来源以广告平台的数据为准。广告访问数据每天定时生成并，每个广告位的计费方式可以选择以下三种模式中的一种：
1) 包时制：广告客户为广告在某个广告位在特定时间范围内的投放付费。例如，某电脑公司在门户首页的页首通栏广告位投放广告，投放时间为2005-1-1至2005-1-20，每天为该广告位付费10000元，则共计投放51天，总广告费为51万元。
2) CPM计费制：Cost Per Milli-impression)即每千人印象成本，是以一千人浏览广告为基本单位。例如：SAAS的B1广告位是5元/CPM，如果一个广告客户购买了1000CPM的广告投放，那么这个广告客户所投放的广告就应该被浏览100万次，广告客户所需要支付的广告费为5000元人民币。
3) CPC计费制：(Cost Per Thousand Click-Through)每千人点击成本的收费模式则是以点击的人数来计算，即是以一千人点击为一个基本单位。包时与CPM计费方式下的广告投放发布到门户网站上，即使满足了时间与访问印象数也可能不会被所有的用户所关注，而CPC模式则不同，只有真正对广告感兴趣的SAAS用户才能去点击广告，而CPC的计数方式是以用户实际点击为依据的，所以该计费模式是最有效的广告计费方式。
如果选择CPC与CPM计费模式，客户付费的依据为广告系统中广告跟踪功能所统计的广告印像数（对于CPM模式）或者广告点击数（对于CPC模式）来计费。对于按照投放时间进行计费的，直接按照实际投放时间进行计费。
对于CPC和CPM方式，客户在购买广告的时候指定在CPC/CPM广告位上需要投放的总映像数或者点击数。当用户通过客户端浏览器请求广告时，广告投放服务器进行广告推送至网站页面时，广告跟踪系统会自动记录广告浏览的印象数，而CPC计费方式，当用户请求广告并点击查看时，广告跟踪系统记录下此广告的点击数。在广告投放的执行过程中，当实际投放的总印象数或点击数达到预定的次数时即停止该广告的播放。
业务场景描述及规则
l 广告跟踪
通过记录记录发布广告的浏览数和点击数能够收集网站访客始自广告显示-点击-访问广告商站点过程中的广告访问数据，用于CPC和CPM模式下的计费。并且能够根据广告实际投放量数据实现对广告投放的控制，包括启动和停止广告投放。
l 广告计费
当一个广告推送到了门户广告位上的时候就可以进行广告计费，广告计费可以按照包时也可以按照基于广告显示次数的CPM（千人成本）计价法，或者基于广告所产生效果的CPC（每点击成本）来计算费用。
广告计费的主要功能包括：指定价格信息：在指定广告位属性的时候，需要指定每个广告栏的计费方式和具体价格。
费用计算：根据广告的实际投放情况计算资费。
表9-43 结算管理的计费方式
| 计费模式 |
资费计算方法 |
| 包时 |
小时(广告发布的有效时间)×广告位的每小时单价 |
| CPM |
每千人访问印象×广告位千次印象单价 |
| CPC |
每千人点击×广告位千次点击单价 |