ESB平台服务管理系统需求规格说明书

1、XXXX银行ESB平台服务管理系统需求规格说明书（业务监控系统分册）营运中心规划处ESB小组二九年五月版本修改记录变更版本修订日期原因与修改情况描述位置修订人审核人目 录第三章 业务监控系统53.1 系统概述53.1.1 业务系统现状53.1.2 系统建设目标53.1.3 系统实施范围63.1.4 系统功能架构73.1.5 系统逻辑架构73.1.6 与其他系统的关系83.2 业务需求分析93.2.1 业务总体需求93.2.2 业务流程93.3 系统功能及信息分析113.3.1 标准代码管理123.3.1.1 需求描述123.3.1.2 用例视图123.3.1.3 用例描述133.3.1.4 信

2、息结构153.3.1.5 信息描述153.3.2 业务信息管理173.3.2.1 需求描述173.3.2.2 用例视图183.3.2.3 用例描述183.3.2.4 信息结构223.3.2.5 信息描述223.3.3 业务流程管理243.3.3.1 需求描述243.3.3.2 用例视图253.3.3.3 用例描述253.3.3.4 信息结构323.3.3.5 信息描述333.3.4 业务进程管理343.3.4.1 需求描述343.3.4.2 用例视图343.3.4.3 用例描述353.3.4.4 信息结构363.3.4.5 信息描述363.3.5 进程预警管理373.3.5.1 需求描述373

3、.3.5.2 用例视图373.3.5.3 用例描述383.3.5.4 信息结构413.3.5.5 信息描述413.3.6 用户权限管理423.3.6.1 需求描述423.3.6.2 用例视图433.3.6.3 用例描述433.3.6.4 信息结构453.3.6.5 信息描述463.3.7 进程监控展示473.3.7.1 需求描述473.3.7.2 浏览权限483.3.8 数据统计分析483.3.8.1 统计口径483.3.8.2 报表类型483.3.8.3 用例视图493.3.8.4 统计权限503.3.9 需求内容说明503.3.9.1 功能需求说明503.3.9.2 角色需求说明513.4

4、 接口设计需求513.5 柜台前移系统接入需求513.5.1 报文解析阶段513.5.2 映射解析阶段513.6 系统非功能需求523.6.1 用户界面523.6.2 语种要求523.6.3 性能要求523.6.3.1 并发用户数523.6.3.2 页面完全展现时间533.6.3.3 数据库检索速度和容量533.6.3.4 资源使用率533.6.4 灵活性533.6.5 可扩展性533.6.6 可靠性543.6.7 安全性543.6.8 可维护性543.6.9 规范性55第三章 业务监控系统3.1 系统概述3.1.1 业务系统现状随着XXXX银行（以下简称：行内）业务系统建设的逐步完善，业务工

5、作对IT系统的依赖程度也越来越高，由于行内IT系统的进一步集成，系统中的业务流程已由原来分段单系统处理、跨系统人工流转的方式，变为业务流程跨系统自动实现流转。当一项业务发生时，业务流程在多个系统中自动实现流转，关注该业务进程的领导及相关业务人员无法通过快捷的、直观的方式了解当前业务进程位置、状态及异常原因等。若建立一个时时的、端到端的业务流跟踪监控系统，将可为领导及相关业务人员及时关注业务进程提供一个形象直观的技术平台，并自动实现业务流程异常报警、实现多维信息统计等功能，进而为业务人员优化业务流程和领导决策提供依据。在此需求的基础上，规划处提出了建设业务监控系统，满足业务发展的要求。3.1.2

6、 系统建设目标业务监控系统作为ESB平台服务管理系统（在建）三个主要组成部分之一，建设目标是建立一个基于映射转化（而非基于报文解析）的可配置、可管理的监控系统。该监控系统是通过建立核心数据库，实现业务流进程跟踪监控、异常预警和数据统计三大功能。业务监控系统是一个架构稳定灵活、接口实现方便的接入平台，只有被监控系统接入才能发挥其功能。该系统建成的同时，将同步实现对柜台前移系统通过报文解析进而转化为基于映射的接入；并且随着ESB平台上接入系统的增加，将逐一实现对被监控系统核心业务流程的监控。被监控业务流接入时，监控系统仅需前台配置，无需后台代码更改，形成对业务流程的跟踪监控、异常预警和数据统计功能

7、。由于需接入的业务系统自身功能各不相同，核心业务流各有差异，在该系统建设过程中，同步制定一套统一的基础信息与进程中信息（或进程报文）通信格式，形成一套制定基础信息与监控信息格式的规范，为被监控系统的接入方式做好基础架构，对后继业务系统接入提供统一的方法和流程。核心信息数据库业务流跟踪根据预定规则，自动跟踪各业务流进程，并适时动态显示，方便各级领导和工作人员及时关注业务流的进程状态，以便合理的做出工作安排。业务流进程跟踪业务流发生异常时，系统能自动给相关技术和业务人员通过短信或邮件的方式发出预警提醒，方便相关人员第一时间了解业务流异常。业务、技术异常预警异常预警数据统计根据各业务流的基础信息，可

8、对业务流涉及的业务按照多维度、全视角进行统计分析，并为业务状态预测提供基础信息。业务数据统计系统目标示意图3.1.3 系统实施范围在现有基本技术监控基础上，由原来仅监控ESB平台报文运行状态，转变为业务全流程跟踪监控。该系统既是ESB平台的一部分，又是区别于具体业务系统的一个独立的监控系统。通过对被监控系统的理解和分析，确定出被监控系统的核心业务流信息、基础信息数据和监控点反馈信息数据，实现对业务流跟踪监控、异常预警和数据统计分析；并与技术监控系统部分功能融合，实现业务流异常的业务原因及技术原因的预警，为方便后继系统的接入，系统应制定标准接口，以便具体接入时，业务监控系统本身无需再做代码改造。

9、3.1.4 系统功能架构为实现端到端的业务进程跟踪监控，该系统功能模块主要包括：标准代码管理、业务信息管理、业务流程管理、业务进程管理、进程预警管理、用户权限管理、系统接口和安全及审计管理等，核心模块为业务信息管理、业务流程管理和业务进程管理。系统功能架构示意图3.1.5 系统逻辑架构业务监控系统在获取具体业务流的基础信息和进程信息的基础上，通过控制流程驱动和预警管理机制实现业务流跟踪时时动态图和数据统计；在发生异常时，通过与外部系统的接口实现邮件或短信提醒，进而通过人工干预，恢复业务流程的正常运转。业务监控系统逻辑图3.1.6 与其他系统的关系该系统建成后，需与ESB平台、注册服务系统、具体

10、业务系统、OA系统、邮件服务系统等进行数据交互，具体与上述各系统关系如下：l 业务监控系统与ESB平台：业务监控系统接受ESB平台转发的各类监控所需的信息或报文；l 业务监控系统与注册服务系统：对于部分基础代码，需将注册服务系统数据作为业务监控系统的元数据，注册服务系统满足业务监控系统直接调用。l 业务监控系统与具体业务系统：业务监控系统在与具体业务系统约定信息及报文内容的基础上，通过固定接口，接收具体业务系统发送的信息或报文；l 业务监控系统与OA系统：当发生异常预警时，业务监控系统将通过OA系统向预警提示人员发送短息；l 业务监控系统与邮件服务系统：当发生异常预警时，业务监控系统将通过邮件

11、服务系统向预警提示人员发送邮件。业务监控系统与其他系统关系示意图3.2 业务需求分析3.2.1 业务总体需求业务监控系统的业务流程端到端跟踪监控的实现是在配置业务流程信息的前提下，对业务流进程信息进行管理，即在业务流程中，每次业务流经不同作业处理点（被监控点）时，应向业务监控系统发送状态消息（具体消息通过报文或消息的方式约定），实际操作过程中，该系统可灵活的添加或减少作业处理点，通过对业务流程信息的管理实现具体业务端到端的业务流程跟踪监控；当系统业务流异常时，根据预先配置的预警规则，通过短信或邮件方式提醒预警提示人员；被监控系统每形成一条业务流时，应向监控系统发送业务基础信息，监控系统将以此自

12、动生成一条监控信息和业务流程，并且该基础信息为业务流程含义展示和统计汇总提供数据。3.2.2 业务流程当业务系统生成一条具体业务流时，在初始点及各监控点应向监控系统发送消息，具体业务流程消息发送的方式为：在业务流起始时，向业务监控系统发送一条基础信息，监控系统据此自动生成一条业务流跟踪监控流程；在业务流程中，每一作业处理点（即：监控点）接收到一条需处理作业时，向业务监控系统发送一条已接收到该作业的状态消息，当该作业处理点完成作业后，向下一作业处理点发送时，同步应向业务监控系统发送一条该作业处理结果的状态消息（状态消息可为：该作业内容更改并成功向下一作业处理点发送，或作业处理成功并向下一作业点发

13、送，或拒绝作业返回至上一或几作业处理点，或流程结束）；当在某监控点或流转中，由于系统技术原因发生异常，应向监控系统发送系统技术异常消息（如：无法发出、系统延时、系统无法接收等），以上发送的各类消息可在具体添加被监控系统时，约定消息内容。业务系统发送至监控系统的消息内容应包括：该具体作业流程的唯一标识代码（全流程不变），本处理点名称代码，本节点所处系统代码；收发作业标识，收发类型（七种：1.正常接收；2.正常发送至下一作业处理点；3.退回上一或几作业处理点；4.作业流程终止并退出；5.技术延时异常;6.技术异常，系统终止;7.作业流程终止并退出，该类内容可在监控系统实现维护），内容更改标识，具体

14、更改内容代码，更改后的具体内容。业务监控进程示意图3.3 系统功能及信息分析通过对业务需求的分析，要实现业务流程端到端的跟踪监控、异常预警和数据统计功能，本系统主要功能模块包括：标准代码管理、业务信息管理、业务流程管理、业务进程管理、进程预警管理、用户及权限管理、进程跟踪展示、数据统计分析等部分，对于每一部分具体功能及信息分析逐一展开，具体如下：3.3.1 标准代码管理3.3.1.1 需求描述为使整个系统内容规范、一致，便于与被监控系统定义业务信息、进程信息的内容，以及部分元数据与服务注册系统进行同步，本系统需建立标准代码管理，独立维护本系统所使用的标准代码，当与服务注册系统实现对接后，服务注

15、册系统作为本系统部分标准代码源信息，通过接口向本系统提供标准代码信息，本系统可关闭服务注册系统提供源数据部分的代码添加、修改功能，仅保留具体内容本系统是否可见功能。形成标准代码的目的是为保证系统间的标准信息格式定义一致，以及对业务及业务进程基础信息进行统计和分析提供便捷。本系统涉及到的主要标准代码包括：系统类别代码、系统代码、业务种类、业务流代码。3.3.1.2 用例视图标准代码管理用例图3.3.1.3 用例描述用例名称：标准代码管理描述：该部分代码内容虽各不相同，但在代码管理上是一致的，应包括代码添加、代码修改、代码删除、代码浏览、代码查询等功能，下面分别对各详细用例进行描述。l 代码添加用

16、例名称：代码添加描述：用户填写代码详细信息，包括代码、名称、备注等，系统提供校验代码是否重复、是否符合约定格式、名称不能为空等功能，提交后在数据库中形成一条正确的新数据；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：代码、名称、备注等需填写的详细信息；输出：对应的相关数据库表中增加一条正确记录。l 代码修改用例名称：代码修改描述：用户选中要修改的一条代码，可对代码、名称、备注等进行修改，系统对修改部分除提供与代码添加同样校验功能外，还应提供该代码是否已被引用等校验功能，对于已被引用和约定使用的代码，原则上不得进行修改，修改后系统更新数据库；参与者/角色：代码维护员；先决条件：以

17、合法身份登陆系统 ；输入：填入需变动内容；输出：对应的相关数据库表中一条记录数据发生变化。l 代码删除用例名称：代码删除描述:用户选中要删除的代码，系统应校验该代码是否已经被引用，若被引用应待引用记录全部删除后，方可进行删除，对于不能删除又需用户不可见的代码，提供客户端是否隐藏（即客户端不可见，不可在引用）功能；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：无；输出：对应的相关数据表中一条记录被删除或发生变化。l 代码浏览用例名称：代码浏览描述：用户登陆后，系统根据用户选择显示代码详细信息；参与者/角色：所有用户；先决条件：以合法身份登陆系统输入：无输出：代码详细信息。l 代码

18、查询用例名称：用户登录后，输入代码、名称等条件，进行代码查询，理论上各个字段都可以作为查询条件，并支持字母和汉字的模糊查询；描述：系统通过用户输入条件，查询相关记录；参与者/角色：所有用户；先决条件：以合法身份登陆系统；输入：查询条件输出：代码详细条目信息。3.3.1.4 信息结构标准代码主要包括：行内信息系统类别代码、信息系统代码、业务种类代码和业务流代码，前三类代码应与行内其他系统保持一致，待服务注册系统建成后，通过数据库订阅等方式实现数据同步，本系统无须再修改，仅对其在本系统是否可见做调整，业务流代码是根据各业务系统的具体业务种类不同而形成不同业务流代码，作为具体业务流程的依据。标准代码

19、管理信息结构图3.3.1.5 信息描述系统类别代码表序号字段名类 型长 度备注1系统类别名称2系统类别代码唯一标识3是否可见4备注系统代码表序号字段名类 型长 度备注1信息系统名称2信息系统代码唯一标识3所属系统类别代码4是否可见5备注业务种类代码表序号字段名类 型长 度备注1业务种类名称2业务种类代码唯一标识3所属信息系统代码4是否可见5备注业务流代码表序号字段名类 型长 度备注1业务流名称2业务流代码唯一标识3所属业务种类代码4是否可见5备注3.3.2 业务信息管理3.3.2.1 需求描述当业务系统发起一笔被监控的业务流程时，发起系统应根据系统接入时的约定，通过消息方式向监控系统发送该笔业

20、务信息，作为监控系统自动建立一条具体业务流程的起始依据，并且为业务进程监控提供业务信息。本系统可人工修改此类基础消息（具体业务流程结束后，该类基础信息不得修改）。在该具体业务流程运行中，某流程中合法用户对初始业务信息内容发生更改，本系统应能自动对已入库的数据进行修正；并且本系统可根据业务流状态，自动变更存储位置，即当具体业务流程未结束时，应一直存于进程中业务信息数据表，结束（包括取消、正常完成及合法终止）进程后，此基础信息应存于已完成业务信息表，已完成业务信息表中内容为统计汇总功能提供数据。具体业务进程中的业务信息应包括：唯一标识（作为具体业务流程唯一标识）、发起系统、发起单位、目标系统、目标

21、单位、业务种类、涉及额度、付出金额单位、付出金额账户、收取金额单位、收取金额账户，过账依据，过账经办单位、过账经办人等，对于与固定字段无法对应的业务信息，应与预留字段对应，对于各预留字段，根据对应情况，逐步约定各预留字段对填入信息的要求。被监控系统在被接入前，双方应确定以上具体信息格式，对各字段应按照服务注册系统业务属性要求进行约定，并确定以上内容在被监控系统标准名称（即在原系统所使用的称谓），方便在浏览和统计时，依数据原本意义展现此类基础信息。3.3.2.2 用例视图业务基础信息管理用例图3.3.2.3 用例描述业务信息字段名称对照管理用例名称：业务信息字段名称对照管理描述：由于监控系统获取

22、各被监控系统业务信息后，按统一模式命名字段名称并进行存储和管理，该模式字段名称对各业务系统在一定程度上，都有一定不易读性，为在查询浏览及汇总统计时，提高业务信息的可读性，需按业务系统本意还原各字段名称。需对将原来各字段名称与统一字段名称进行对应转换，具体需转换的字段主要包括：业务种类、涉及额度、付出金额单位、付出金额账户、收取金额单位、收取金额账户，过账依据，过账经办单位、过账经办人及预留字段。对该类对照表可进行增加、删除、修改、查询及浏览功能，当在业务信息字段名称对照中，某项内容为空、无记录或者被删除时，应按照通用字段名称展示，下面对各用例进行详细描述。l 业务信息字段名称对照添加用例名称：

23、业务信息字段名称对照添加描述：用户选定业务流后，可添加业务信息字段名称对照信息，提交后在数据库中形成信息；参与者/角色：核心信息维护员；先决条件：以合法身份登陆系统；输入：用户输入选择业务流名称或代码，添加具体名称；输出：业务信息字段名称对照表中增加一条正确记录。l 业务信息字段名称对照修改用例名称：业务信息字段名称对照修改描述：用户选中要修改的一条数据，可对内容进行修改可更改具体名称以及从事设置为空，修改后系统更新数据库；参与者/角色：核心信息维护员；先决条件：以合法身份登陆系统 ；输入：填入需变动内容；输出：业务信息字段名称对照表中一条记录数据发生变化。l 业务信息字段名称对照删除用例名称

24、：业务员信息字段名称对照删除描述:用户选中要删除的对照记录，可进行删除；参与者/角色：核心信息维护员；先决条件：以合法身份登陆系统；输入：无或查询条件；输出：业务信息字段名称对照表中一条记录被删除。l 业务信息字段名称对照浏览用例名称：业务基础信息对照浏览描述：用户登陆后，系统根据用户选择显示字段名称对照详细信息；参与者/角色：所有用户；先决条件：以合法身份登陆系统输入：无或查询条件；输出：业务信息字段名称对照内容详细信息。l 业务信息字段名称对照查询用例名称：业务信息字段名称对照查询描述：可按系统代码名称或业务流代码名称等输入查询条件，查询相关记录，并支持按照字母或汉字的模糊查询；参与者/角

25、色：所有用户；先决条件：以合法身份登陆系统；输入：查询条件输出：业务信息字段名称对照内容条目信息。业务信息管理用例名称：业务信息管理描述：业务信息是具有清晰业务含义的数据内容，不但是动态监控描述的信息源，同时也是本系统提供统计汇总功能的唯一源数据，业务信息应包括：唯一标识、发起系统、发起单位、目标系统、目标单位、业务种类、涉及额度、付出金额单位、付出金额账户、收取金额单位、收取金额账户，过账依据，过账经办单位、过账经办人等，若涉及其他重要信息可在预留字段中约定。根据具体情况，对该类进程中业务信息可进行修改、查询及浏览功能，对已完成业务信息内容仅可查询和浏览，不得修改，下面对各用例进行详细描述。

26、l 业务信息修改用例名称：业务信息修改描述：业务信息修改只对业务进程中的业务信息有效（但系统要设计对已完成进程的业务信息修改的功能，以便为后期前台维护提供便捷），用户选中要修改的业务信息，可对其中涉及额度、付出金额单位、付出金额账户、收取金额单位、收取金额账户，过账依据，过账经办单位、过账经办人以及预留字段内容等数据进行修改，修改后系统更新数据库；参与者/角色：信息管理员；先决条件：以合法身份登陆系统；输入：选中要修改的业务信息内容，修改具体要调整的名称；输出：基础信息表中一条记录发生变化。l 业务信息浏览用例名称：业务信息浏览描述：此部分针对进程中业务信息，系统根据用户选择显示代码详细信息；

27、参与者/角色：有权限用户；先决条件：以合法身份登陆系统输入：无输出：详细基础信息l 业务信息查询用例名称：业务信息查询描述：输入系统代码（名称）、业务流代码（名称）条件或相关基础信息内容，查询相关记录，并支持按照字母或汉字的模糊查询；参与者/角色：有权限用户；先决条件：以合法身份登陆系统输入：查询条件输出：业务信息条目信息3.3.2.4 信息结构业务基础信息管理信息结构图3.3.2.5 信息描述业务信息字段名称对照表序号字段名类 型长 度备注1对照表ID唯一标识2所属业务流代码必填3业务种类标称4涉及额度标称5付出金额单位标称6付出金额账户标称7收取金额单位标称8收取金额账户标称9过账依据标称

28、10过账经办单位标称11过账经办人标称12预留字段1-3013备注业务信息表序号字段名类 型长 度备注1具体业务流标识ID唯一标识2所属业务流代码必填3发起系统代码必填4发起单位必填5目标系统代码6目标单位7业务种类8涉及额度9付出金额单位10付出金额账户11收取金额单位12收取额度账户13过账依据14过账经办单位15过账经办人16业务流状态代码17预留字段1-3018备注3.3.3 业务流程管理3.3.3.1 需求描述监控系统能自动发挥监控功能的基础在于监控业务流的建立，即在被监控系统发起一笔新业务时，监控系统通过业务系统按约定内容向监控系统发送的信息（该消息可为业务系统自动发出，也可通过E

29、SB平台已获得信息解析得到），监控系统能自动形成一个约定的监控流程。该监控流程需在业务系统发起前一次性约定，具体过程中可根据业务要求灵活配置被监控业务流的方向和监控点名称、数量，可增加或删除监控点及相对处理时间等基本信息，业务流基础信息管理就是在监控系统中，通过配置监控点及监控点状态信息和业务流程状态信息，建立各类业务流程。3.3.3.2 用例视图业务流程信息用例图3.3.3.3 用例描述业务流监控点配置用例名称：业务流监控点配置描述：根据不同的业务流代码或名称，可增加或删除该业务流下的业务流程和监控点，对于已存在的业务流程可对其内部监控点数量及各监控点上下级关系进行调整，保证业务流的灵活配置

30、，但同一业务流下，不同监控流程的监控点代码不得相同，系统应具有校正功能。一条业务流下，可有一条或多条业务流程，对未被引用的业务流（其中监控点代码也未与其他被监控做出使用约定）可选择删除，对于已被使用的业务流，可对其实施整体进程中停用（该具体业务流程处于普通用户不可见状态），下面对各用例进行详细描述。l 业务流监控点添加用例名称：业务流监控点添加描述：用户选定业务流后，添加新的监控点代码、名称，并可选择上、下级监控点代码或名称（可多选），提交后在数据库中生成新的代码信息；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：用户选择业务流名称或代码，添加监控点代码、名称，选择上级监控点名

31、称或代码；输出：业务流监控配置点表中增加一条正确记录。l 业务流监控点修改用例名称：业务流监控点修改描述：用户选中一条要修改监控点的业务流，然后选中要修改的监控点，可对该监控点的代码、名称等进行修改，原则上，对于已被使用或已约定使用的代码不得进行修改，可修改名称或备注等信息，系统对于已被使用的代码应提供校验功能，并有提醒功能，修改后系统更新数据库；参与者/角色：代码维护员；先决条件：以合法身份登陆系统 ；输入：填入需变动内容；输出：业务流监控点配置表中一条记录数据发生变化。l 业务流监控点删除用例名称：业务流监控点删除描述:用户选中业务流中要删除监控点记录，若该监控点在实际已发生业务流中被引用

32、，不能删除，仅能将该监控点状态改为隐藏，该监控点在普通用户客户端变为不可见状态；若该监控点未被引用，也未与其他系统做出使用约定，可进行删除；若该监控点已被其他监控点设为上级监控点，系统应提醒具体引用的下级监控点名称，待下级监控点将其移除，方可隐藏或删除；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：无或查询条件；输出：业务流监控点配置表中一条记录被改动状态或被删除。l 业务流监控流程浏览用例名称：业务流流程浏览描述：用户登陆后，根据用户选择业务流，显示监控流程详细信息，此处为一条完成的业务流程，而非简单的监控点罗列；参与者/角色：所有用户；先决条件：以合法身份登陆系统输入：无或

33、查询条件；输出：业务流流程详细信息。l 业务流监控流程查询用例名称：业务流流程查询描述：用户输入条件，可按所属业务、监控点名称等，查询相关记录，结果应按一条完成的业务流程显示，而非简单的监控点罗列；参与者/角色：所有用户；先决条件：以合法身份登陆系统；输入：查询条件输出：业务流流程详细信息。监控点处理状态代码配置用例名称：监控点处理状态配置描述：在每条进程中的业务流，从业务层面上，具体监控点处理作业时，应向监控系统提交该监控点处理状态，具体在业务流监控图中体现为点位信息，即监控点的代码、名称、数量等，通过红、黄、绿三色（红色表示异常，黄色表示延时，绿色表示正常处理，具体状态可根据业务要求前台配

34、置）表达该监控点的处理状态，每监控点处理的状态包括：已接收需处理的作业，已正常完成处理作业发送下一作业处理点，已改动完成处理作业发送下一作业处理点，从技术层面上，应包括系统正常处理，系统异常情况等，为保证各监控点监控状态的灵活配置，需建立监控点状态灵活配置机制，即建立监控点状态配置表，统一规定处理状态。l 监控点处理状态代码添加用例名称：监控点处理状态代码添加描述：用户登陆后，选择监控点处理状态代码配置，添加新的监控点处理状态代码、名称，提交后在数据库中形成代码信息；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：监控点处理状态代码名称及备注；输出：监控点处理状态代码表中增加一条

35、正确记录。l 监控点处理状态代码修改用例名称：监控点处理状态代码修改描述：用户选中一条要修改的监控点状态，可对该监控点的代码、名称等进行修改，修改后系统更新数据库，已被引用或虽未被引用但已与其他系统约定的代码不得修改，修改时，系统应具有是否被引用校验功能，并有提醒功能；参与者/角色：代码维护员；先决条件：以合法身份登陆系统 ；输入：填入需变动内容；输出：监控点处理状态代码表一条记录数据发生变化。l 监控点处理状态代码删除用例名称：监控点处理状态代码删除描述:用户选中一条监控点代码状态信息，删除该信息，若该状态代码已在发生的实际业务流中被引用，不得删除，系统应有校验和提醒功能，若该状态代码未被引

36、用也未与其他系统约定使用，可进行删除；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：无或查询条件；输出：监控点处理状态代码表中一条记录被改动状态或被删除。l 监控点处理状态代码浏览用例名称：监控点处理状态代码浏览描述：选择监控点处理状态代码，显示该代码详细信息；参与者/角色：所有用户；先决条件：以合法身份登陆系统输入：无或查询条件；输出：监控点处理状态代码详细信息。l 监控点处理状态代码查询用例名称：监控点处理状态代码查询描述：输入条件，查询相关记录，并支持按照字母或汉字的模糊查询；参与者/角色：所有用户；先决条件：以合法身份登陆系统；输入：查询条件输出：监控点处理状态详细信息

37、。业务流进程状态代码管理用例名称：业务流进程状态代码管理描述：业务流进程状态代码是描述一条业务流进程状态信息，同时能够描述某个监控点处理该业务流状态，业务流进程状态分为正常、异常、终止、结束（从技术层面描述该条业务进程的状态）；在监控图上，进程体现为箭头，监控点体现为圆点，具体通过颜色代表不同状态（例如：红表示异常，黄表示延时，绿表示正常处理）。由此判断其他系统发送的该业务流进程状态。l 业务流进程状态代码添加用例名称：业务流进程状态代码添加描述：用户填入状态代码和名称并提交后，数据库中形成代码信息；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：业务流进程状态代码和名称；输出：

38、业务流进程状态代码表中增加一条正确记录。l 业务流进程状态代码修改用例名称：业务流进程状态修改描述：用户选中一条要修改的业务流进程状态，可对内容进行修改，修改后系统更新数据库，原则上已被引用或已与其他系统约定使用的代码不可修改代码，系统应具有校验和提醒功能；参与者/角色：代码维护员；先决条件：以合法身份登陆系统 ；输入：填入需变动内容；输出：业务流进程状态代码表一条记录数据发生变化。l 业务流进程状态代码删除用例名称：业务流进程状态代码删除描述:用户选中要删除的业务流状态记录，若该状态代码已被引用或已约定使用，不得进行删除，系统应具有校验和提醒功能，其他情况，方可删除；参与者/角色：代码维护员

39、；先决条件：以合法身份登陆系统；输入：无或查询条件；输出：业务流进程状态代码表中一条记录被改动状态或被删除。l 业务流进程状态代码浏览用例名称：业务流进程状态代码浏览描述：选择业务流进程状态代码，显示该代码详细信息；参与者/角色：所有用户；先决条件：以合法身份登陆系统输入：无或查询条件；输出：业务流进程状态代码详细信息。l 业务流进程状态代码查询用例名称：业务流进程状态代码查询描述：输入条件，查询相关记录，并支持按照字母或汉字的模糊查询；参与者/角色：所有用户；先决条件：以合法身份登陆系统；输入：查询条件输出：业务流进程状态代码详细信息。3.3.3.4 信息结构业务流程信息结构图3.3.3.5

40、 信息描述业务流监控点配置表序号字段名类 型长 度备注1监控点名称2监控点代码联合主键，唯一标识3所属业务流代码4监控点位置5上级监控点代码可空、可多6下级监控点代码系统自动填充7相对完成时间可空8该条数据状态可空9备注监控点处理状态代码表序号字段名类 型长 度备注1监控点状态代码2监控点状态名称3备注业务流进程状态代码表序号字段名类 型长 度备注1业务流状态代码2业务流状态名称3备注3.3.4 业务进程管理3.3.4.1 需求描述监控系统能对被监控系统业务流进行监控的核心是对处于处理中的业务进程进行消息反馈，反馈内容应包括：所属具体业务流标识ID、该消息所属业务流代码、所属业务流状态代码、所

41、属监控点代码、监控点处理状态代码，具体改动业务信息代码，具体改动内容（即进程中对核心信息的改动）等，在被监控系统接入业务监控系统时，需双方约定反馈内容的消息格式，发送方式，监控系统通过ESB平台统一接受各被监控系统发送的进程消息，并保存该类消息，作为进程中业务流跟踪和历史数据查询的基础。根据业务信息、业务进程消息的具体内容，业务进程可分为：进行中业务进程和已结束的业务进程，两种不同的业务进程应有不同的存储数据表格，以便更好的实现时时业务流跟踪和历史业务流程信息查询，业务流程中要体现该业务进程的基础信息、监测点数量、已完成作业监测点的处理时间点，当前业务进程的状态。可人工改变业务进程信息和状态，

42、但不可添加或删除业务流程，根据业务要求，对于不同系统发起的业务流程应有不同的浏览查看权限。3.3.4.2 用例视图业务进程用例图3.3.4.3 用例描述业务进程管理用例名称：业务进程管理描述：业务进程是描述一条业务进程当前状态，为动态实时跟踪监控提供数据，该内容由被监控系统发送消息自动完成，管理员仅能对系统原因产生的数据进行必要的修改，不得进行增加、删除功能，其他有权用户可以查询自己负责相关监控点的状态消息。l 业务进程修改用例名称：业务进程修改描述：用户选中要修改的进程信息，修改具体信息内容，对于已结束进程的信息不得修改；参与者/角色：核心信息维护员；先决条件：以合法身份登陆系统；输入：无或

43、查询条件；输出：业务进程管理表中一条记录发生变化。l 业务进程浏览用例名称：业务进程浏览描述：选择一条业务进程信息，显示该条进程详细信息；参与者/角色：有权用户；先决条件：以合法身份登陆系统输入：无或查询条件；输出：业务进程详细信息。l 业务进程查询用例名称：业务进程查询描述：输入条件，查询相关记录，支持模糊查询；参与者/角色：有权用户；先决条件：以合法身份登陆系统；输入：查询条件输出：业务进程详细信息。3.3.4.4 信息结构业务进程管理信息结构图3.3.4.5 信息描述业务进程管理表序号字段名类 型长 度备注1业务进程管理ID自增ID2所属监控点代码3监控点状态代码4所属业务流代码5所属业

44、务流状态代码6所属具体业务流标识ID7监控点处理时间点8备注3.3.5 进程预警管理3.3.5.1 需求描述本系统应有预警规则配置，当系统出现异常时，通过配置好的规则自动实行异常预警，对于异常预警级别设置为三级：正常、超时、失败，但在级别划分上能根据具体工作进行前台层级配置，且能体现层级结构，并根据各个级别能设定预警发送信息。3.3.5.2 用例视图进程预警管理用例图3.3.5.3 用例描述进程预警配置管理用例名称：进程预警配置管理描述：通过进程预警配置管理，当业务进程异常时，业务监控系统能够通过OA系统或邮件服务器，自动向相关预警提醒人员发送短信或者邮件。实际情况中，可以按照业务流程、监控点

45、等进行预警提醒人员配置，当业务流程发生异常时，按照预先配置发送消息（业务进程异常情况及可能的原因），提示相关工作人员。对于预警配置的要求，具体为：如果把某工作人员配置为某业务进程预警提醒人员时，整个业务进程任何一个节点出现异常时都将向该人发送消息；如果将某预警提醒人员配置到某业务流程的某一个或几个监控点时，只有处于其预警配置位置发生异常时，系统才向该预警配置人员发送消息，一个预警提示人员可以关注多个业务流程或多个监控点，一个业务流程监控点可配置多人预警提示人员关注；系统应该灵活的实现配置，对于预警提示人员及其手机号码和邮件，应该首先在用户表中补充约定，供预警配置管理选择使用，并且在预警配置管理

46、中可以维护该预警提示人员的手机号码、邮箱等信息，做到便于信息更新方便，对于各类预警提示人员应分监控类型，及业务监控、业务监控、全部监控三类。代码维护员可以在配置业务流程、监控点及进程预警配置界面下都可以维护进程预警配置信息，在具体配置预警信息时，查找相关业务流名称、监控点名称、预警提示人员名称时，支持字母和汉字的模糊查询。具体预警提示内容针对性要强，应该包括被提示人员的具体姓名，发起系统的名称业务流的名称、所处监控点的名称、发生异常的原因等，例如：XXX您好，由XXX系统发起的XX业务正处于XXX阶段，可能由于XXX原因，引起业务进程异常，请您及时处理或检查，业务监控系统提醒。l 进程预警配置

47、添加用例名称：进程预警配置添加描述：代码维护员选择添加人员，并可维护预警提示人员的手机号码、电子邮箱等个人信息，也可不选择预警提示人员名称单独添加手机号码和邮箱，并且一个业务流或监控点可以填入多个预警提示用户，并选择用户类型（默认是全部）；提交后，业务进程预警配置表中增加一条信息，对于监控人员类型亦同；参与者/角色：信息维护员；先决条件：以合法身份登陆系统；输入：选择用户姓名，维护预警提示人员信息；输出：进程预警配置表中增加一条正确记录。l 进程预警配置修改用例名称：进程预警配置修改描述：用户选中一条要修改的进程预警配置，可对手机号码、邮箱、备注等内容进行直接修改，对预警提示人员名称选择变动，

48、修改后系统更新数据库，对于监控人员类型亦同；参与者/角色：信息维护员；先决条件：以合法身份登陆系统 ；输入：填入或选择需变动内容；输出：业务进程预警配置表一条记录数据发生变化。l 进程预警配置删除用例名称：进程预警配置删除描述:用户选中要删除的一条预警信息或者一条预警信息中具体预警提示人员进行删除，对于监控人员类型亦同，若该人员类型已被引用，需清除后方可删除，并需提醒功能；参与者/角色：信息维护员；先决条件：以合法身份登陆系统；输入：无或查询条件；输出：进程预警配置表中一条记录被删除。l 进程预警配置浏览用例名称：进程预警配置浏览描述：选择一条预警信息，可浏览包括该预警信息所处系统、业务流、监

49、控点、预警提示人员所在部门及个人预警信息等全部详细内容，对于监控人员类型亦同；参与者/角色：有权用户；先决条件：以合法身份登陆系统输入：无或查询条件；输出：一条预警内容详细信息。l 进程预警配置查询用例名称：进程预警配置查询描述：可以按业务流或监控点下所有预警信息，也可按照预警提示人员查询所有提示该人员的业务流或监控点信息，输入条件，查询相关记录，并支持按照字母或汉字的模糊查询，对于监控人员类型亦同；参与者/角色：有权用户；先决条件：以合法身份登陆系统；输入：查询条件输出：业务进程配置详细信息。3.3.5.4 信息结构进程预警配置管理信息结构图3.3.5.5 信息描述进程预警配置表序号字段名类

50、 型长 度备注1预警发送信息ID2监控点所属业务流代码3监控点所属系统代码4用户ID5监控人员类型代码6备注监控人员类型表序号字段名类 型长 度备注1监控人员类型代码2监控人员类型名称3备注3.3.6 用户权限管理3.3.6.1 需求描述由于被监控系统涉及各业务系统核心内容，并提供统计分析功能，且部分内容的保密要求很高，因而应对各功能模块及具体实例的增加、删除、修改、查看、浏览功能根据不同用户可单独前台配置，并且应能设置常用权限组合，进行整体配置。对于预警提示人员，应在添加用户时，自动实现该用用户对该业务流全流程的浏览、查看功能。为方便以后该系统与门户平台、统一认证集成，用户信息应包含用户账号

51、、用户名称，所在部门信息、职务信息等。在逐一配置用户权限的同时，可实现权限组合与用户的部门或职务的映射整体配置，实现批量权限维护。系统管理员可实现维护用户信息、角色信息、部门职级等基础信息，可按照组合权限和单一权限（当重叠时取交集）配置用户权限，用户能维护（账号除外）个人姓名、所在部门、职级、手机号码、邮箱、登录密码（做强密码要求）等个人基本信息。3.3.6.2 用例视图用户及权限维护用例图3.3.6.3 用例描述用例名称：用户权限管理描述：用户权限管理主要包括：用户信息维护、密码维护、部门职级维护、角色维护、用户权限维护等主要功能，管理员可以实现用户及权限的添加、修改、删除、浏览及查看功能，个人用户仅能对个人基本信息维护。l 用户权限添加用例名称：用户权限添加描述：根据用户权限要求可实现部门、用户等基本信息的添加、系统，系统应具有默认初始密码，在部门、职级、用户账号添加时，提供校验代码是否重复、是否符合约定格式、名称不能为空等功能，提交后在数据库中形成一条正确的新数据；参与者/角色：代码维护员；先决条件：以合法身份登陆系统；输入：需添加部分的详细信息；输出：对应的相关数据库表中增加一条正确记录。l 用户权限修改用例名称：用户权限修改描述：管理员根据