服务保障系统设计实现论文.doc

湖南大学毕业论文 第 I 页

毕业设计（论文）

设计（论文）题目： 服务保障系统的设计与实现

学生姓名
学生学号
专业班级
指导老师
院长 (系主任)

5月30日

湖南大学毕业论文

毕业论文 第 IV 页
服务保障系统的设计与实现

摘 要
随着电信市场竞争的加剧，客户已经成为各类电信运营企业的竞争对象。为切实加强对客户的服务及管理工作，适应电信市场竞争的新形势，留住客户，电信运营商迫切需要一套快速响应及业务支撑系统，来确保为客户提供高质量的服务。
服务保障系统的建设可以实现电信跨专业、面向服务、闭环的电子化流程管理，以电子工单的形式达到管理手段的规范化和标准化，提高运维效率和对客户的服务质量。
本设计主要依据湖南电信的需求，采用J2EE+WebLogic+Oracle的模式开发一套服务保障系统。首先，本文介绍了服务保障系统的业务流程，其中详细描述普通电话和IC卡故障每一类障碍的处理流程，同时比较宽带故障和电话故障的异同。然后，本文提出了系统的总体设计方案，将流程归纳为4种子流程，并将系统划分为故障受理，派测，查修，审核4个主要功能模块。最后，本文从流程控制，数据结构，功能模块，与10000号系统接口四个方面详细阐述了如何实现服务保障系统。
本设计最大的特点是采用流程配置文件，Sql Map框架等多种方式实现了系统的通用性和可扩展性，使得故障处理流程的增加和修改十分灵活，只需配置相关数据而无需修改代码。

关键字：电话和IC卡故障，宽带故障，故障受理，派测，查修，审核

Design and Implement of Service Assuring System

Abstract
With the competition of telecommunication market intensifying, the customer has become competition objects of each kind of telecommunication enterprises. In order to effectively enhance customer service and management, enable it to meet the new competitive situation of telecommunication market, and retain customers, the enterprise needs a set of rapid response and operational support system to ensure to provide high-quality service for customers.
The construction of Service Assuring System can realize the goal of telecommunication inter-professional, service-oriented, closed-loop electronic workflow management, normalize management measures through electronic forms and improve operating efficiency and customer service quality.
According to the requirements of Hunan telecommunication, this design developed Service Assuring System using J2EE+WebLogic+Oracle. Firstly, this article introduces the operational process in Service Assuring System, including a detailed description of how to deal with each kind of obstacles contained in ordinary telephone and IC fault and a simple comparison between wideband and telephone fault. Then, this article presents a total design which divides the system into four principal modules: fault accepting, measuring, repairing and verifying. Finally, this article elaborates how to realize Service Assuring System from four aspects, which are process control, data structure, function modules and interface with 10000.
The biggest feature of the design is realizing system interoperability and scalability through configuration files, SQL Map framework and other methods.

Key Words: telephone and IC fault, wideband fault, fault accepting, measuring, repairing, verifying
目 录
1．绪论 1
1.1 系统建设背景 1
1.1.1 遵照集团ITSP电信战略发展规划 1
1.1.2 配合湖南电信MBOSS转型规划 1
1.2 系统现状 1
1.2.1综合化集中维护支撑系统现状 2
1.2.2 97系统112子系统现状 3
1.2.3 10000系统96112子系统现状、IC卡子系统现状 3
1.3 系统建设目标 3
2．技术背景 5
2.1 J2EE概述 5
2.1.1 J2EE框架 5
2.1.2 J2EE核心技术 5
2.2 XML 7
2.2.1 XML简介 7
2.2.2使用dom4j和XPath解析XML 9
3．系统业务流程 11
3.1 电话和IC卡故障流程 11
3.2.1无障碍 11
3.2.2配线架障碍 11
3.2.3线路障碍 12
3.2.4电缆障碍 13
3.2.5机房障碍 14
3.2.6IC卡话机障碍 15
3.2 宽带故障流程 16
4．系统总体设计 17
4.1 总体流程和功能模块 17
4.2 设计原则 17
5．系统详细设计 20
5.1 流程控制设计 20
5.2 数据库设计 21
5.3 功能模块设计 22
5.3.1取故障单列表 22
5.3.2故障受理 23
5.3.3故障派测 25
5.3.4故障查修 27
5.3.5故障审核 29
5.4 与10000系统接口设计 33
结论 35
致谢 36
参考文献 37
附录A 数据库主要表结构 39

毕业论文 第 43 页
1．绪论
1.1 系统建设背景
1.1.1 遵照集团ITSP电信战略发展规划
企业信息化是中国电信九大发展战略之一，实现企业信息化是中国电信提升运营和管理水平，提高企业核心竞争力的重要保证。ITSP是中国电信的五年信息化规划[1]，全集团的信息化工作都要遵循ITSP 制订的转型规划，逐步过渡到信息化的技术架构远景和组织架构远景。
通过企业信息化战略规划（ITSP）的实施，中国电信将建设企业先进的信息化体系CTG－MBOSS，全面支撑企业的运营和管理。根据ITSP 的定义，中国电信的企业信息化体系（CTG－MBOSS）将由管理支撑系统（MSS）、业务支撑系统（BSS）和运营支撑系统（OSS）组成。
湖南电信服务保障系统将立足于ITSP 规划蓝图的服务保障域，重点关注服务问题的解决和服务质量的管理，以综合化集中维护支撑系统为基础，整合全网的故障调度流程，构建综合故障处理平台。
1.1.2 配合湖南电信MBOSS转型规划
湖南电信根据集团ITSP规划制定了符合本省特点的IT 三年滚动规划，在未来的三年中，湖南电信将启动MBOSS 总体转型计划，进行四条主线的改造，建成五大核心系统，服务保障系统为五大核心系统之一。
此外，根据湖南电信MBOSS的总体转型计划，原有的97系统将进行拆分，以其中面向客户的订单受理功能为基础发展为CRM系统，面向网络的服务开通和号线管理功能发展为服务开通系统，112电话故障管理作为97系统中相对独立的一个子系统，应实现系统的平滑过渡。
因此，提出建设服务保障系统。
1.2 系统现状
湖南电信服务保障系统的现状是：故障处理分布在不同的系统中，没有形成企业级的综合故障处理平台，如图1.1所示：

图1.1 湖南电信服务保障域现状图
1.2.1综合化集中维护支撑系统现状
湖南电信综合化集中维护支撑系统（IOSS 系统）于2004 年7 月完成在全省14 个地市及省中心的推广应用，分省级和本地网级建设，其主要目的是实现湖南省电信运维从面向网络和网元的维护向面向市场和客户的维护的转变，系统以实现流程化的运维调度控制为主要目标。
系统采用J2EE 分布式体系结构，采用JAVA 开发。并采用了bea 的工作流产品来进行工单流程的管控。
系统功能主要以电子工单为核心，包括故障管理、大客户信息管理及其网络资源信息管理、大客户视图管理、知识库管理、割接管理、统计报表、系统管理和维护管理等。
系统实现了对故障的闭环处理，即故障的“一点受理、综合分析、并行处理、评估反馈”，对内部SLA 进行有效管理，有效地支撑了对大客户的服务支撑。
系统目前存在的问题：故障范围只涉及到电信网络层面的故障，不能支撑所有故障流程及故障环节，如112系统及96112系统中的外线故障等。
1.2.2 97系统112子系统现状
112 障碍管理是内嵌在97 系统里的一个相对独立的子系统，可分为受理、派测、测试、查修、消障、管理等六大模块，主要是对电话故障的处理。
系统使用的服务器主要是HP 小型机，采用ＵＮＩＸ服务器操作系统，Oracle
数据库，使用PowerBuilder 开发，C/S 结构。
112系统目前存在的问题：系统采用C/S 两层结构。由于两层架构缺少业务逻辑层，业务逻辑分散在客户端和数据库服务器，对于业务流程的改变及新产品的开发无法提供有力的支持，在实现系统调用、平台迁移及系统整合时有较大难度。
根据MBOSS 转型计划，原有的97 系统将进行拆分，以其中面向客户的订单受理功能为基础发展为CRM 系统，面向网络的服务开通和号线管理功能发展为服务开通系统，112 作为相对独立的一个子系统，其故障处理功能将整合到综合化集中维护支撑系统中。
1.2.3 10000系统96112子系统现状、IC卡子系统现状
96112 障碍管理是10000 系统的一个子系统，分为障碍受理、障碍派测、障碍测试、障碍查修、障碍审核消障等六大模块，主要是进行ADSL、以太网等数据故障的处理。
IC卡障碍管理也是10000号系统的一个子系统，主要进行IC卡话机障碍的处理。
湖南电信14个本地网共采用了三个不同公司开发的10000系统，系统主要使用UNIX 和WINDOWS 服务器操作系统，Oracle 和SqlServer 数据库，开发语言有VB、DELPHI 和C++。
96112系统和IC卡系统目前存在的问题：
1. 全省采用三个厂商产品，共有四个版本。由于版本多，导致升级维护困难，对业务支撑不能全省同步。
2. 系统模块按照紧耦合设计，流程调度固化在程序代码中，流程配置不灵活、扩展性不强，维护和升级难度大。
1.3 系统建设目标
湖南电信服务保障系统作为服务保障域的支撑系统，将在现有IOSS 系统处理业务故障和网络故障的基础之上，增加普通电话故障、宽带故障及IC 卡故障的处理功能，构建成一个企业级的综合故障处理平台,更有效地支撑前台服务和实现后台流程化的运维调度控制，并进一步推动综合化集中维护这一长远目标的实现。

2．技术背景
2.1 J2EE概述
为快速设计和开发企业级的应用程序，Sun 公司推出了一种全新概念的模型——Java 2 Platform, Enterprise Edition（J2EE），它与传统的互联网应用程序模型相比有着不可比拟的优势。
2.1.1 J2EE框架
J2EE平台使用了一个多层的分布式应用程序模型[2-3]。它克服了传统两层应用（C/S结构）难于升级和扩展的不足，把客户端从复杂的业务逻辑中分离出来。J2EE应用程序的逻辑根据其实现的不同功能被封装到不同的组件中，组成J2EE应用程序的大量应用程序组件根据其所属的层被安装到不同的机器中。图2.1描述了一个分布式J2EE应用程序，它可以分为如下四层：
运行在客户端机器的客户组件
运行在J2EE服务器中的Web层组件
运行在J2EE服务器中的业务逻辑层组件
运行在EIS服务器中的企业信息系统（EIS）层软件
2.1.2 J2EE核心技术
J2EE提供了一个框架，实现这个框架的引擎工具由第三方厂商完成。最常用的J2EE技术是：JSP，Servlet，EJB，JDBC，JNDI。
1. JSP
JSP(Java Server Page)是一种实现普通静态HTML和动态页面输出混合编码的技术。从这一点来看，非常类似Microsoft ASP、PHP等技术。借助形式上的内容和外观表现的分离，Web页面制作的任务可以比较方便地划分给页面设计人员和程序员，并方便地通过JSP来合成。在运行时态，JSP将会被首先转换成Servlet，并以Servlet的形态编译运行，因此它的效率和功能与Servlet相比没有差别，一样具有很高的效率。

图2.1 J2EE框架图
2. Servlet
Servlet是Java平台上的CGI技术。Servlet在服务器端运行，动态地生成Web页面。与传统的CGI和许多其它类似CGI的技术相比，Java Servlet具有更高的效率并更容易使用。对于Servlet，重复的请求不会导致同一程序的多次转载，它是依靠线程的方式来支持并发访问的。
3. EJB
EJB定义了一组可重用的组件：Enterprise Beans。开发人员可以利用这些组件，像搭积木一样建立分布式应用。在装配组件时，所有的Enterprise Beans都需要配置到EJB服务器(一般的Weblogic、WebSphere等J2EE应用服务器都是EJB服务器)中。EJB服务器作为容器和低层平台的桥梁管理着EJB容器，并向该容器提供访问系统服务的能力。所有的EJB实例都运行在EJB容器中。EJB容器提供了系统级的服务，控制了EJB的生命周期。EJB容器为它的开发人员代管了诸如安全性、远程连接、生命周期管理及事务管理等技术环节，简化了商业逻辑的开发。EJB中定义了三种Enterprise Beans：
(1) Session Beans
(2) Entity Beans
(3) Message-driven Beans
4. JDBC
JDBC(Java Database Connectivity，Java数据库连接)API是一个标准SQL(Structured Query Language，结构化查询语言)数据库访问接口，它使数据库开发人员能够用标准Java API编写数据库应用程序。JDBC API主要用来连接数据库和直接调用SQL命令执行各种SQL语句。利用JDBC API可以执行一般的SQL语句、动态SQL语句及带IN和OUT参数的存储过程。Java中的JDBC相当与Microsoft平台中的ODBC(Open Database Connectivity)。
5. JNDI
由于J2EE应用程序组件一般分布在不同的机器上，所以需要一种机制以便于组件客户使用者查找和引用组件及资源。在J2EE体系中，使用JNDI(Java Naming and Directory Interface)定位各种对象，这些对象包括EJB、数据库驱动、JDBC数据源及消息连接等。JNDI API为应用程序提供了一个统一的接口来完成标准的目录操作，如通过对象属性来查找和定位该对象。由于JNDI是独立于目录协议的，应用还可以使用JNDI访问各种特定的目录服务，如LDAP、NDS和DNS等。
2.2 XML
2.2.1 XML简介
XML，或称为可扩展标记语言（Extensible Markup Language），是一种可以用来创建自己的标记的标记语言[4]。它由万维网协会（W3C）创建，用来克服 HTML（即超文本标记语言（Hypertext Markup Language），它是所有网页的基础）的局限。和 HTML 一样，XML 基于 SGML — 标准通用标记语言（Standard Generalized Markup Language）。
1. XML文件的整体结构
XML文件包括三部分：XML声明、处理指示（可选）、XML元素。XML文档的一个基本要求是形式良好的(well formed)，一个形式良好的XML文档要包含这三个部分。下面是一个完整的XML文档（catalog.xml）：
<?xml version="1.0" encoding="gb2312" ?>
<?xml-stylesheet type="text/xsl" href="mystyle.xsl"?>
<catalog>
  <cd country="USA">
    <title>Empire Burlesque</title>
    <artist>Bob Dylan</artist>
    <price>10.90</price>
  </cd>
  <cd country="UK">
    <title>Hide your heart</title>
    <artist>Bonnie Tyler</artist>
    <price>9.90</price>
  </cd>
  <cd country="USA">
    <title>Greatest Hits</title>
     <artist>Dolly Parton</artist>
     <price>9.90</price>
   </cd>
</catalog>
2. 处理指示，元素，标记和属性
处理指示：用来给处理XML文件的应用程序提供信息的，处理指示应遵循的格式是：<?处理指示名 处理指示信息?>
元素：XML文件内容的基本单元，一个元素包含一个起始标记，一个结束标记以及标记之间的数据内容，其形式是：<标记>数据内容</标记>
标记：除了注释和CDATA部分外，所有左尖括号<和右尖括号>之间的内容都称为标记。标记区分大小写，要有正确的结束标记（不过当一对标记之间没有任何文本内容时，可以不写结束标记，而是在开始标记的最后惯以“/”来确认），要正确嵌套。其基本形式为：<标记名 属性=“属性值”>
属性：一个元素开始标记中的名称-值对，属性名不能重复，名称与取值之间用“=”分隔，且取值用引号引起来。
2.2.2使用dom4j和XPath解析XML
1. Xpath简单语法
XPath是一种在xml文档中查找信息的语言，XPath使用路径表达式在xml文档中进行导航。以上面的xml文档为例，介绍XPath的简单语法[5]：
选择元素：一个斜线（/）表示绝对路径，两个斜线（//）表示文件中所有符合模式的都会被选出来，即使处于树中不同的层级。例如：选择catalog底下的cd中的所有price元素 ：/catalog /cd/ price，选择文件中所有cd元素（在树中的任何层级都会被选出来）：//cd
选择若干路径：通过在路径表达式中使用“|”运算符选取若干路径，例如：选择所有title和artist元素：//title | //artist
选择属性：属性都是以@开头，例如：选择文件中所有叫做country的属性：//@country，选择含有country这个属性的cd元素：//cd[@country]，选择country属性值为UK的cd元素：//cd[@country=’UK’]
2. 使用dom4j和Xpath解析XML
dom4j 是一种解析 XML 文档的开放源代码 XML 框架，与 W3C DOM API 相比，使用 dom4j 所包含的解析器的好处是 dom4j 拥有本地的 XPath 支持[6-8,20]。DOM 解析器不支持使用 XPath 选择节点。
使用dom4解析xml（以选取某一节点为例）的代码如下：
import dom4j.*;
import dom4j.io.*;

class readxml{
//定义xml对应的文档
public static Document catalogXmlObj = null;
//初始化xml
public void initXml(){
……
SAXReader reader = new SAXReader();
catalogXmlObj = reader.read(new File("catalog.xml"));
……
}

//取catalog.xml中某一节点
public void getNode(String xpathExpression){
……
initXml();
//假设 xpathExpression =” //cd[@country=’UK’]”
//取节点
Node node = catalogXmlObj.selectSingleNode(xpathExpression);
……

}
}

3．系统业务流程
3.1 电话和IC卡故障流程
电话和IC卡故障包括无障碍，配线架障碍，线路障碍，电缆障碍，机房障碍5种类型，IC卡故障还包括IC卡话机障碍。
3.2.1无障碍
1. 流程图

图3.1 电话无障碍流程图
2. 流程描述
(1) 系统通过10000号接口自动受理电话/IC卡故障单，或由牵头部门测量台在系统中人工创建电话/IC卡故障单。
(2) 测量台的人登录系统，查看待派测故障单，然后逐一对故障进行测量定位，如果是无障碍，则派测时选择无障碍，该故障单也自动销单。
3.2.2配线架障碍
1. 流程图
见图3.2
2. 流程描述
(1) 系统通过10000号接口自动受理电话/IC卡故障单，或由牵头部门测量台在系统中人工创建电话/IC卡故障单。
(2) 测量台的人登录系统，查看待派测的故障单，然后逐一对故障进行测量定
位，如果是配线架障碍，则派给测量台自己。
(3) 测量台的人查修好故障后，填写相应查修结果，直接审核销单。

图3.2 电话配线架障碍流程图
3.2.3线路障碍
1. 流程图
见图3.3
2. 流程描述
(1) 系统通过10000号接口自动受理电话/IC卡故障单，或由牵头部门测量台在系统中人工创建电话/IC卡故障单。
(2) 测量台的人登录系统，查看待派测的故障单，然后逐一对故障进行测量定位，如果是线路障碍则派往营销中心。
(3) 营销中心内勤班的人登录系统，将待查修的故障单派发给营销中心相应的外勤人员查修。
(4) 外勤人员查修好故障后，电话回单给测量台，告知处理情况。
(5) 测量台的人根据外勤人员的回复，确认故障是否处理好，然后填写相应查修结果，审核销单。

图3.3 电话线路障碍流程图
3.2.4电缆障碍
1. 流程图
见图3.4
2. 流程描述
(1) 系统通过10000号接口自动受理电话/IC卡故障单，或由牵头部门测量台在系统中人工创建电话/IC卡故障单。
(2)测量台的人登录系统，查看待派测的故障单，然后逐一对故障进行测量定位，如果是电缆障碍则派往线路维护安装中心。
(3)线维内勤班的人登录系统，将待查修的故障单派发给线维相应的外勤人员查修。
(4)外勤人员查修好故障后，电话回单给测量台，告知处理情况。
(5)测量台的人根据外勤人员的回复，确认故障是否处理好，然后填写相应查修结果，审核销单。
注：电缆障碍一般由线路障碍的外勤人员现场查修时发现，然后告知测量台，测量台再走上述流程将该故障派往线维查修。

图3.4 电话电缆障碍流程图
3.2.5机房障碍
1. 流程图
见图3.5
2. 流程描述
(1) 系统通过10000号接口自动受理电话/IC卡故障单，或由牵头部门测量台在系统中人工创建电话/IC卡故障单。
(2) 测量台的人登录系统，查看待派测的故障单，然后逐一对故障进行测量定位，如果是机房障碍则派往监控中心。
(3) 监控中心的人登录系统，查看待查修的故障单，然后对故障进行查修。查修好故障后，填写好相关查修结果，从系统中回单给测量台
(4) 测量台的人根据收到的回单信息，确认故障是否修好，然后审核销单。

图3.5 电话机房障碍流程图
3.2.6IC卡话机障碍
1. 流程图
见图3.6
2. 流程描述
(1) 系统通过10000号接口自动受理电话/IC卡故障单，或由牵头部门测量台在系统中人工创建电话/IC卡故障单。
(2) 测量台的人登录系统，查看待派测的故障单，然后逐一对故障进行测量定位，如果是IC卡话机障碍则派往公话中心。
(3) 公话中心内勤班的人登录系统，将待查修的故障单派发给公话中心相应的外勤人员查修。
(4) 外勤人员查修好后，电话回单给公话中心内勤班，告知处理结果。
(5) 内勤班的人根据外勤人员的回复结果，填写相应信息，从系统中回单给测量台。
(6) 测量台的人根据收到的回单信息，确认故障是否修好，然后审核销单。

图3.6 IC卡话机障碍流程图
3.2 宽带故障流程
宽带故障（ADSL和以太网）均包括无障碍，线路障碍，机房障碍，网络障碍4种类型，ADSL故障还包括电缆障碍。宽带故障流程与电话故障流程相似，有以下2点不同：
1. 障碍的牵头部门为宽带内勤班，由宽待内勤班的人对障碍进行派测和审核。
2. 线路障碍和电缆障碍的外勤人员查修完故障后，先电话回单给各自的内勤班，再由内勤班的人从系统中回单给牵头部门，而非外勤人员直接电话回单给牵头部门。
4．系统总体设计
4.1 总体流程和功能模块
根据电话，IC卡和宽带的各种障碍类型的处理流程，可将故障处理设定为以下4种子流程（见图4.1）：
子流程1：故障派测后初始环节为查修（如机房障碍）
子流程2：故障派测后初始环节为查修派发（如线路障碍，电缆障碍，IC卡话
机障碍）
子流程3：故障派测后初始环节为审核（如配线架障碍）
子流程4：故障派测后直接销单（如无障碍）
同时，根据故障处理的过程，系统总体可划分为故障受理，派测，查修，审核四个主要功能模块。
故障受理：包括从10000号受理和牵头部门在系统中人工受理故障。受理过程是生成故障单，自动分发到牵头部门并启动故障处理流程的过程。
故障派测：根据故障类型及测量后的测量结果，故障根据规则自动派往相应的查修部门。
故障查修：查修部门首先通过系统接受需查修故障单，对需要查修派发的故障单，按照相应规则（如线路障碍按局向和交接箱匹配到具体的查修人）派发给外勤人员查修。无需查修派发的，查修部门查修完后，直接对该故障单进行回单。
故障审核：当查修部门查修完故障回单给牵头部门时，牵头部门需确认故障能够是否修复，如果修复，则审核销单，如果未修复，而且是原查修部门的原因，则可退单给原查修部门重新查修，如果未修复，而且发现需要其他的查修部门查修，则可将故障单转派至其他查修部门。
4.2 设计原则
1. 系统采用多层结构，模块化设计，各层次相对独立运行，能够支持湖南电信公司的各种电信业务，各类电信客户。系统设计时不能只考虑当前提出的电话，IC卡，宽带故障处理流程，而要考虑将来可能出现的新的业务的故障流程，能快速，灵活的定制出新的故障处理流程，来支持服务保障系统的运营，同时新故障处理流程的引入只需配置相关数据，修改或增加部分层次中的部分模块，而不会影响原有功能的正常实现。

图4.1 故障总体流程图
2. 系统采用分布式开放结构，充分考虑与其他系统的接口。各个接口采用独立的模块完成，接口模块的运行状态不会影响本系统的稳定运行。
3. 采用与平台无关的设计，保证操作系统无关性，浏览器无关性，数据库无关性，应用服务器无关性。

5．系统详细设计
5.1 流程控制设计
为满足现有故障处理流程，同时灵活化流程控制，系统采用template.xml和tache.xml两个配置文件来对故障处理流程进行配置，图5.1和图5.2分别展示了文件的部分内容：
template.xml 是流程模板文件,其主要作用是根据故障业务类别和测量类型来决定新生成的故障子单的流程（即派测后所处的初始环节）。tache.xml是环节文件,其主要作用是根据子单的流程模版id,当前所处的环节和动作代码来决定子单的下一环节，这两个文件共同决定了某种障碍类型在系统中的流程。
以电话机房设备障碍为例，当派电话机房障碍时会根据业务类别（P0）和机房障碍（03）从template.xml中取得子单的流程模板id为child_flow_001,初始环节为C(查修环节),查修好该故障,进行查修回单时,会根据流程模板id (child_flow_001),当前环节(C),和查修回单动作代码(C9)从tache.xml中取得子单下一环为S(审核环节),对该子单进行审核(S0)后,会从tache.xml中取得下一环节为Z(销单),意味着机房障碍流程完毕。
文件中所用到的代码及含义如下表所示：
表5.1 静态代码及含义表
测量类型代码
测量类型
环节代码
环节
动作代码
动作
01
无障碍
P
派测
P0
派测提交
06
配线架障碍
Z
销单
S6
正常销单
02
末端障碍
S
审核
C9
查修回单
14
电缆障碍
Cf
查修派发
S0
审核提交
03
机房障碍
C
查修
S4
退单
11
IC卡话机障碍

S5
转派

C1
查修派发

图5.1 template.xml文件片断图

图5.2 tache.xml文件片断图
5.2 数据库设计
根据故障处理流程及需记录的故障处理过程中的相关信息，主要设计了以下6个表（具体表结构见附录A）：
(1) 分发规则表（isa_distribute_rule）
(2) 工位局向表（isa_worktype_branch）
(3) 故障主单表（isa_fault_ticket）
(4) 子单表（isa_fault_child_ticket）
(5) 环节表（isa_process_tache）
(6) 操作记录表（isa_process_rec）
分发规则表和工位局向表主要是对障碍的收单工位和部门进行配置，一是决定受理故障后分发到什么牵头部门进行派测（如电话是测量台，宽带是宽带内勤班），二是决定派某种障碍类型后的查修部门（如派电缆障碍由线路维护安装中心查修），其他四个表主要是记录和故障处理有关的信息。
同时为了障碍查询统计的需要，对应故障主单表，子单表，环节表和操作记录表分别建了历史表（表结构相同），故障处理完后会将各当前表的信息全部写入历史表，方便业务部门对处理过的故障进行统计分析。
5.3 功能模块设计
5.3.1取故障单列表
1. 页面显示

图5.3 故障单列表页面
页面说明：
(1) 页面分为两个区域，左边是系统的菜单树，右边是待操作的故障单列表。点击某个菜单项，右边就会显示相应的待操作的故障单列表。
(2) 上图是待派侧的故障单列表页面，其他故障单列表页面（如故障派修，子单审核等）同该页面，只是列表显示的字段信息根据需要而不同。
2. 功能描述
操作员进入服务保障系统后，点击左边菜单树上的任务项（如故障派测），右边就会根据操作员拥有的工位权限显示其可以操作的故障单列表，点击某条记录的服务号（超链接），就会进入该故障单的详细操作页面（派测页面）。
3. 实现方法
取故障单列表：根据任务项和操作员拥有的工位从子单表中取出处于相应环节且收单工位属于该操作员拥有的工位之一的故障单(此处采用Sql Map[9]框架,灵活控制待操作的故障单列表)。
以取派测列表为例，方法为getRepairFaultTicket()：从子单表中取出环节代码为P，收单工位属于该操作员拥有的工位之一的故障单。
5.3.2故障受理
1. 页面显示

图5.4 故障受理页面
页面说明：
(1) 按业务类别受理故障，包括电话，IC卡，ADSL，以太网四种业务类别。
(2) 页面分为三个区域，“受理信息”、“客户资料”、“受理现象”。 “受理信息”和“受理现象”为操作员填写区，“客户资料”为资料显示区。
2. 功能描述
(1) 操作员输入申告号码，选择业务类别，点击go按钮，客户资料区显示相关信息，可选故障现象显示所选业务类别对应的故障现象等。
(2) 操作员选择故障现象，填入联系人，联系电话，备注，点提交按钮生成故障单。
3. 实现方法
(1) 取客户资料（getCardInfo()）：根据申告号码和业务类型从卡片表中取得客户姓名，客户地址，客户标示，客户等级（SLA等级），电话状态。
(2) 取本单状态（getCurrStatus()）：如果申告号码已在系统中申告了故障单，则从当前表中取出该故障单的状态，申告次数，故障现象代码，联系人，联系电话，备注，故障来源，受理时间，受理