烟草资金监管平台架构设计说明书

编号：时间：2021年x月x日书山有路勤为径，学海无涯苦作舟页码：第86页 共86页厦门东南融通系统工程有限公司烟草资金监管平台架构设计说明书厦门东南融通系统工程有限公司版权所有厦门东南融通系统工程有限公司 版权所有东南融通。本文件未经东南融通的书面允许不得复制或分发。本文件中的任何部分都不得用于东南融通意愿以外的其他目的目 录1简介51.1目的51.2范围51.3术语61.4参考文档61.5文档组织方式62系统总体架构82.1产品特点82.2设计指导思想82.3系统逻辑架构102.4系统应用架构112.5系统物理架构132.6与业务系统的关系142.7与银行系统的关系142.7.1连接示意图142.7.2接口关系图153应用框架设计173.1技术框架173.2界面设计173.2.1登陆参考183.2.2首页参考193.2.3新增页面193.2.4修改页面193.2.5审批页参考203.2.6查询页参考213.3类设计213.4模块划分223.5功能菜单234基础功能设计264.1组织模型264.2权限控制274.2.1菜单权限控制274.2.2操作权限控制284.2.3数据权限控制294.3流程控制294.3.1流程功能概述304.3.2工作流的使用314.3.3工作流的集成314.3.4系统流程设计314.3.5流程处理框架324.3.6流程基本操作334.4规则处理384.4.1开发过程384.4.2规则定义394.4.3规则执行394.5消息服务394.5.1功能描述394.5.2邮件发送404.5.3短信发送404.5.4发送维护424.5.5接口类设计424.6通讯网关444.6.1连接方式444.6.2功能描述444.6.3技术框架464.6.4接口类设计464.7任务调度484.7.1功能描述484.7.2解决方案484.7.3应用示例494.7.4配置说明504.7.5任务清单514.8报表开发514.8.1报表设计514.8.2报表种类524.8.3报表清单534.8.4报表打印535数据同步设计546安全性设计566.1方案概述566.2权限控制566.3CA认证566.4登陆日志566.5操作痕迹566.6审批痕迹586.7Server端校验587性能设计608客户化设计618.1改变监管规则618.2改变业务流程618.3外围系统连接定制618.4改变数据库类型618.5改变组织数据来源619开发规范639.1Java编程规范639.2数据库设计规范649.3文件命名规范659.4页面样式规范669.5页面开发规范669.6后台程序规范689.7文档规范709.8序列号的获取719.9异常处理719.9.1JSP页面异常719.9.2Action 异常719.9.3DAO和Service层的异常729.9.4异常编程指导729.10错误消息729.11事务处理739.12目录结构739.13配置文件749.14开发指导759.15第三方软件7510环境搭建7810.1开发环境7810.2调试环境7810.3开发基础数据环境7910.4外部系统模拟环境79附录1: 开发软件和工具81附录2：公共资源管理82附录3：文档变更记录831 简介本文档为烟草资金监管平台的软件架构设计说明书。本文档与“烟草资金监管基础平台数据库设计说明书.doc”和“烟草资金监管系统数据库设计说明书.doc”一起构成本系统的概要设计文档体系。1.1 目的本文档为烟草资金监管平台的软件架构设计提供详细的说明,包括整个系统的架构、基础平台的技术实现、客户化方式和指导应用开发的相关规范等。本架构书为编制如下文档提供基本依据：n 程序设计书n 软件开发计划n 软件测试计划n 软件用户手册n 系统安装手册本架构书与本系统的“程序设计书”一起，为编写程序、单元测试、集成测试（测试）提供基本依据；本架构书为其它有关文件提供基本依据；本架构书为软件质量保证人员提供工作依据；本架构书将作为软件测试和系统验收的准则；本架构书与本系统的“程序设计书”一起，将作为编码的基准文件。1.2 范围本设计书从技术角度定义了本系统的架构，内容涵盖了本系统的设计思想、软件体系结构、软件功能模块分解及边界设计、应用框架设计、与外围系统地连接处理、开发规范等。对本系统使用的主要技术，如PowerWeb、工作流、规则技术、Jasper等）也做了简要介绍。本系统中硬件设备和网络设备的设计以及软件详细设计部分不在本规格之内。1.3 术语n PowerWeb：是东南融通开发的一个Web界面开发平台。n intelliRule：是东南融通开发的规则系统，可实现规则的编辑、编译和执行。n JasperReports：开放源码的报表生成工具，用户需要按照它制定的规则编写报表格式的XML模板文件，然后指定数据源得到导出的报表文件。n iReport：一个帮助那些使用JasperReports library生成报表的用户以可视化方式设计报表的工具。n Hibernate：Hibernate O-R mapping tools，由 www.hibernate.org 提供，用于数据层的开发。n Spring：Spring - Java/J2EE Application Framework，由 www.springframework.org 提供，用于业务逻辑层的开发。n 工作流引擎：解释业务流程的定义，与工作流的参与者（包括人或软件）相互作用，并根据需要调用其它的IT系统、应用、或者数据。n 规则引擎：对业务规则进行解释。是一种高性能的专用解释（推理）程序。把当前提交给引擎的数据对象与加载在引擎中的业务规则进行匹配，符合当前数据状态下的业务规则会被激活，根据业务规则中声明的执行逻辑，触发对应的操作。n tfm：tobacco fund monitor烟草资金管理系统1.4 参考文档n 烟草资金监管平台系统需求规格书.docn CMBP演示系统，http:/172.16.9.230/cmbpofficedemo (admin/admincmbp)1.5 文档组织方式第二章关注的是整个系统的内外部环境以及各相关要素之间的关系。第三章关注的是整个系统提供的具体功能、展现形式和功能实现的技术框架。第四章关注的是基础平台部分的功能实现思想以及实现的技术框架。第五章关注的是本系统的数据和外围系统的数据库的数据如何同步和更新。第六章和第七章关注的是两个主要的非功能性需求如何实现，即安全性和性能。第八章是对需要客户化的几个问题的方案概述。第九章是指导开发人员开发， 保证设计的一致性和代码具有良好的可读性，保证开发能规范有序地进行的一些指导和要求。第十章是指导开发人员搭建开发和调试环境，也可了解未来该系统如何部署。2 系统总体架构本章将从技术角度阐述本系统的定位、设计思想、逻辑架构、应用架构、物理架构以及需要交互的外围系统。本章是后续章节的编制依据。2.1 产品特点n 采用了先进的J2EE技术架构，确保系统的可扩展性、安全性、可靠性。n 安全、高效的电子支付平台，全面掌握行业资金流动情况。n 全新的多方位的监督理念，包括设置行业企业帐户库、流程控制点、流水帐管理、多渠道的帐目对照、实时报警。n 三级体系，两级监管，组成一个贯穿事前、事中、事后的全方位资金监管体系。n 界面友好，B/S结构的界面，C/S的应用效果，新鲜直观，操作方便。n 统一的接口规范，灵活的的对外接口和报文配置，方便对接不同的业务系统和银行系统。n 实时警示，报警方式灵活选择，报警内容容易定制。n 功能强大的工作流管理系统和规则系统，业务流程和监控规则可以自由调整，做到随需应变。n 丰富的图文并茂的监控方式，包括数据表格、柱状图、散列图、仪表图等，一目了然掌控全局。n 构件化功能组装，强大、简单的业务延伸能力，方便新业务的拓展。2.2 设计指导思想n J2EE平台，B/S结构， MVC设计模式。J2EE平台实现系统的平台无关性（包括操作系统无关性和应用服务器无关性）。B/S架构的优点是维护方便，能够降低成本。采用MVC设计模式，使系统具有更大的灵活性和扩展性。n 充分使用已有的软件资产，提高复用程度，降低开发成本。在本系统中，使用了公司的研发产品intelliFlow工作流管理系统和intelliRule规则系统，参考了公司其它项目中的流程处理框架和基于PowerWeb的应用框架，修改扩展了消息服务构件、通讯网关构件和组织模型维护。n 优先使用构件的组合，以构件的思想搭建一个松耦合的系统。在本系统中，最基础的功能在bas模块中，这是所有的基础，在此之上是消息服务构件、通讯网关构件和流程处理框架，这些框架、构件、工具库和intelliFlow工作流管理系统、intelliRule规则系统一起构成系统的基础平台；基于该平台开发3个应用子系统的功能。n 面向接口编程，实现可以替换，充分发挥面向对象编程的优势。面向接口编程的好处是实现方式容易配置，譬如本系统将来要外接的系统在5个以上，十分复杂，尤其是组织数据也可能取自其它系统，将各功能以接口形式提供，就可以在外界有变化时，只需要单独实现，而不会涉及到已有代码的修改，大大降低测试的工作量。n 配置灵活的思想，使有利于产品推广。保证流程、报警规则、消息模板、消息发送方式、报文收发实现类能方便配置。n 分层分块思想，方便开发和维护。整个系统分为基础平台和应用功能，基础平台提供应用框架和核心技术，应用功能主要是在此基础上实现业务功能，以良好的形式展现。应用框架分为流程框架和非流程处理框架，都由表现层、业务逻辑层和持久化层组成。对于构件，分为核心功能和扩展功能，扩展功能在实施中客户化；公用组件包里面包含了系统使用的各种公共功能，相对比较独立。n 通过详细的规范简化应用功能的后继开发，保证设计思想和编码风格的一致性。产品最大的问题是由于实施应用的点比较多，各自情况不一样，导致修改或客户化的可能性很高，同时产品生命周期长，参与的开发人员会相对比较多，为应对这一特点，本系统通过详细的规范降来低学习成本，提高易维护程度。2.3 系统逻辑架构本系统安装在各省公司和国家局，各省与国家局之间的系统完全独立，但省与国家局数据库之间有数据同步、上载和下传活动发生，省之间的数据库完全独立。本系统的角色有监管人员、财务人员、业务人员和系统管理员，不同的角色对应系统不同的访问权限，一个人只有一个角色。其中只有省公司有系统管理员，即系统是统一维护。本系统的基础数据一部分来于各个业务系统(如合同信息)，一部分在省级系统中维护(如人员信息)，一部分由国家局系统维护后下载到省级系统使用(如银行信息)。本系统需要实时或定时地从业务系统中获取业务数据，前者如业务合同信息，后者如分公司的销售数据。与银行系统的连接（如查询余额）通过国家局接口连接总行进行。本系统的应用层将在基于J2EE技术的东南融通基础平台之上进行开发。并重点使用该平台的应用开发框架、页面框架集及控件集、流程引擎、规则引擎和构件库。关于这一部分的详细介绍见第4章。本系统的应用模块包括帐户管理、运营监管、综合查询、烟叶收购、两烟购销等。关于各功能的详细介绍见3.5节。2.4 系统应用架构系统应用架构图描述系统的组成部分和各个部分的依赖关系。n 系统使用Java语言开发，B/S结构，支持的浏览器为微软IE 5.0以上n PowerWeb开发平台辅助前台展现层的实现n 规则引擎负责依照监管规则对业务数据进行处理n 工作流引擎负责对业务流程进行处理n Jasper负责报表处理，同时使用JFreeChar实现一些特殊图形的显示n 应用逻辑层使用Hibernate/iBatis负责对数据进行存取，使用Spring负责系统各个部件的组装以及一些辅助功能n 系统用到的数据库为Oracle或DB2, 应用服务器为IBM的Websphere Application Server，这是由解决方案决定的。各技术的选择理由如下：2.5 系统物理架构系统部署图描述系统运行时所依赖的硬件环境，该环境由节点和节点之间的依赖关系组成。系统为三级体系、两级监管，三级体系指国家局、省公司、分公司，两级监管指在国家局和省局都单独安装本系统，对业务进行监督管理，国家局和省局之间通过数据的上传和下载保证信息的同步。逻辑上，系统的服务器包括Web服务器、应用服务器和数据库服务器。Web服务器主要负责静态页面的显示，应用服务器主要是提供中间层组件、流程引擎和规则引擎的运行环境。当数据较少时，这些服务器可安装在同一台机器上；当数据量增加时，这些服务器可按需要分别安装在不同的机器上，Web服务器、应用服务器还可由多台机器组成集群（Cluster），实现负载均衡机制。原则上数据库服务器使用单独的机器。系统的运行环境如下：客户机/服务器软件配置备注客户端Windows 2000 ProfessionalIE 5.5 以上应用服务器WAS5.1.1数据库服务器Oracle9i2.6 与业务系统的关系本系统与各业务系统之间的关系如下图：本系统需要从各业务系统获取业务数据，并保存在本系统中，以查询和统计。通过通讯网关实现外部系统数据的获取，即应用模块提出请求指令，通讯网关连接外部系统，发送报文并获取报文，应用模块获取报文后进行其后的数据处理，对外的报文格式为XML。数据是实时还是定时从各系统获取，以及获取后的处理，待需求细化后在详细设计中体现。2.7 与银行系统的关系2.7.1 连接示意图本项目的银行连接属于“银企直联”范畴，为实现与银行进行直联，必须签订网上“企业银行”银企直联服务协议，基于该协议，在本系统的应用服务器上安装银企直联客户端，本系统根据银行提供的接口说明组织XML报文，直接调用银行提供的API，实现与银行的金融数据交换，安全问题由银行负责。连接示意图如下：2.7.2 接口关系图本系统需要与银行系统进行连接的业务如下：向银行系统收发报文的方式与业务系统类似，不同之处在于和业务系统打交道时需要本系统连接业务系统，而与银行系统打交道时，连接银行系统是由其客户端解决，本系统只是组织XML格式的报文并调用客户端的API。3 应用框架设计本章将阐述本系统的应用框架、系统的功能菜单、数据流转等。本章为Web层、业务逻辑层和数据访问层的设计及实现提供依据。3.1 技术框架客户浏览器发出HTTP请求，通过控制器转发调用相应的业务处理模块来业务逻辑，处理的结果通过控制器相应的视图格式化，返回客户端浏览器呈现给使用者。在页面的开发上，多采用JSP TAG，实现页面元素的重用，所有相同元素统一控制以增强应用的可维护性。业务层的设计遵循组件化设计模式。业务逻辑被封装在业务逻辑组件之中，控制器Action通过调用业务逻辑组件的接口来实现业务逻辑处理。当需要对数据进行处理时，业务逻辑组件通过调用数据访问组件的方法来完成对持久数据的操作。另外，在业务逻辑组件之间的通讯也是通过调用接口的方式来实现，以确保组件的重用性和扩展性。数据访问层遵循DAO设计模式，通过Hibernate和iBatis来访问数据库。使用Hibernate主要做单表的操作，使用iBatis主要用来实现复杂的查询操作，以优化性能。3.2 界面设计本系统的界面风格将参考“烟草资金监管演示系统”和PowerWeb的页面开发控件效果，由专业的美工人员设计。如下是设计的主要想法，本部分在设计完成后将被替换。3.2.1 登陆参考3.2.2 首页参考n 整个页面分为上，左, 右, 下四块, 上为常用菜单图标等, 下为脚注, 右边开发人员可自由分割，左为树形菜单n 上面的常用菜单和左边的功能菜单都是动态获取的n 需要做分公司、省公司和国家局的首页3套，具体待需求明确后定。n 打开一个菜单页面时，新的页面tab页效果显示3.2.3 新增页面略。3.2.4 修改页面略。3.2.5 审批页参考n 每个子系统一个审批任务列表n 每条任务选中进入后为对应的业务信息和审批信息3.2.6 查询页参考3.3 类设计业务功能实现的类关系如下图：n LTActionServlet实现转发功能，根据struts的配置文件决定流程和页面的流转，包括常用数据格式的转换。n Action中调用各业务逻辑处理，业务逻辑的处理实现依照Spring的框架在XServiceImpl中处理，每个处理类都对应一个接口类。n 数据层的操作在使用Hibernate时在XDaoImpl中实现，使用iBatis时，在XSqlDaoImpl中实现，每个处理类都对应一个接口类。3.4 模块划分分类模块代码模块名称基础平台bas基础功能、非流程框架和工具类库org使用工作流组织模型的组织维护iwf流程处理框架mns消息服务cgs通讯网关应用功能ssm系统管理和基础信息account账号处理payroll网上支付monitor资金监管bulletin公告管理 基础平台各部分的关系如下图：3.5 功能菜单根据每个人的权限动态生成功能菜单，采用树状方式显示。如下是系统的全部功能：一级菜单二级菜单三级菜单系统管理系统设置权限管理通知设置基础信息行政区划组织管理卷烟管理账户管理子系统账户设置合作银行登记合作银行选择账户种类定义账户查询账户信息查询账户余额查询账户审批查询账户种类查询账户申办账户开设申请银行开户办理账户信息变更账户销户办理账户审批账户审批任务状态管理账户启用账户停用账户冻结账户解冻网上支付子系统资金拨付拨付申请拨付审批资金拨付业务支付烟叶收购支付烟叶采购支付卷烟采购支付辅料采购支付固定资产采购支付费用支付人工费用支付办公费用支付业务费用支付物流费用支付基建支付捐赠支付专卖经费支付其他费用支付对账管理对账单查询下载批量下载银企勾兑资金监管子系统业务监管交易列表两烟购销确认烟叶收购监管烟叶购销监管卷烟购销监管辅料采购监管卷烟销售监管拨付监管拨付列表资金拨付监管费用监管支付列表费用支付监管固定资产采购监管人工费用支付监管办公费用支付监管业务费用支付监管物流费用支付监管基建支付监管捐赠支付监管专卖经费支付监管其他费用支付监管贷款担保监管警示统计公告管理公告申请公告审批公告管理综合查询账户交易明细查询4 基础功能设计4.1 组织模型本系统使用工作流管理系统的组织模型，模型如下图：n 组织单元(Unit)：机构、部门、工作组的统称。n 组织单元类型：可以是机构，部门或工作组n 角色(Role)：指标准岗位，如监管，财务n 职位(Position)：也称管理职位，指一个组织中的一个标准岗位(不是一个人)。职位可以和人关联。n 汇报关系：指一个人（或职位）向另一个人(或职位)汇报。 显示汇报关系：直接设置的汇报关系。 隐式汇报关系：由上下级职位关系决定的汇报关系。n 群组：人员的集合，这些人可来于不同的组织单元(如机构)n 代理：指一个人(或职位)代理另一个人(或职位)的职权本系统目前只使用如下概念：组织单元、角色、职位，不使用群组、代理、显示汇报关系，未来根据需要可以扩展。本系统将在工作流组织模型基础上做扩展，即增加部分表的字段信息。该模型中的机构对应本系统中的省公司或国家局，子机构对应分公司和工业企业，部门对应这些机构下的部门。组织树的表现形式如下：XX省公司/国家局-职位 -人员 -部门1 -职位 -人员 -部门2 -XX分公司-部门1-部门2-企业 -部门1 -部门24.2 权限控制本系统的权限控制包括动态菜单，操作功能和数据权限三类的控制。4.2.1 菜单权限控制系统根据登陆人所拥有的菜单权限动态生成能访问的菜单。菜单权限的维护机制如下：n 一个用户对应一个角色。角色和权限关联，角色对应的权限可增加，但不能取消。用户对应某个角色时，即默认拥有了该角色对应的全部权限。n 每个用户的权限是角色对应权限的子集，即可取消部分权限，但不能增加。n 角色增加权限A时，拥有该角色的人都增加权限A。n 用户登陆时，根据登陆人的ID号，获得该人能访问的全部菜单，保存在session中，并形成菜单树。数据关系参见“烟草资金监管基础平台数据库设计说明书”n 提交请求时，server端校验是否能操作该菜单。n 系统的全部功能菜单作为初始化数据提供。4.2.2 操作权限控制n 一个菜单对应的web页面上有多个功能，如增加、删除、修改、查询、上载，这称为功能权限，又称操作权限。n 功能权限的维护和菜单权限同时维护，即在给角色或人设置菜单权限时，同时指定在对应的功能；一个菜单项下对应一个或多个功能权限。n 用户登录时，根据登陆人的ID号，获得该人能访问的全部功能，保存在session中。数据关系参见“烟草资金监管基础平台数据库设计说明书”n 每个功能按钮在页面上的显示使用“按钮控件”，该控件能根据功能ID决定按钮是否可用，如果不可用，disable按钮。n 提交请求时，server端校验是否能操作该功能。n 系统的全部功能权限作为初始化数据提供。4.2.3 数据权限控制对数据权限控制包括以下两种要实现的功能：n 在账号处理审批查询时，国家局领导可查询全部省，省级领导可查询本省的全部审批，市级单位只能查询本地区的，普通员工只能查询个人的。n 在业务处理上，要能以组织机构+分管范围定义（如某领导分管厦门，漳州，泉州的卷烟销售）的方式控制数据。数据权限的实现方案为：n 对业务需要做数据权限的部分，需要维护人员的分管范围，分管范围的粒度为分公司/工业企业。n 审批查询的数据权限固化在代码内，即省级领导可查询全部的分公司/工业企业，分公司只能查自己地区内所有的工业企业，工业企业只能查自己的，其他人只能查自己。n 所有需要做数据权限功能的表的每条记录绑定操作员工号、公司/企业代码、部门号（非必须）。n 所有需要数据权限控制的查询功能使用iBatis实现，在业务查询信息外同时传入操作人员ID号和可看的公司/企业列表；该列表在登陆时获得，并保存在session中；如果没有公司/企业列表，但有操作人员号表示查询操作人员自己提交的。4.3 流程控制使用intelliFlow工作流和工作流应用框架实现对流程的控制。工作流应用框架的数据库设计参见“烟草资金监管基础平台数据库设计说明书”。本系统提供给最终用户的系统中只包括工作流引擎，建模工具只提供给实施推广人员使用，本系统不使用流程监控工具。工作流应用框架负责衔接应用业务和流程管理，作为一个半正式产品使用，其后台数据库是固定的，但框架由于必然涉及到应用的使用，在不同的系统中会有调整。本系统中有调整，主要是：n 将原来的流程发起后输入表单改为表单输入完毕提交时发起流程。n 将一次性查询所有任务改为按业务分类查询任务，如账号审批任务包括申请、开户、销户等流程任务的审批。n 需要增加根据各种业务属性查找流程，由于有多个审批查询功能，业务属性在不同的业务审批查询中不一样。n 由于工作流升级，个别API没有兼容带来的修改。4.3.1 流程功能概述n 所有流程的业务表现都是A - B - C 这种线型依次审批的形式，每个环节一个人审批；所有审批关系在系统上线前就决定，不存在随机指定。n 审批的操作包括同意，不同意，驳回，同意时运行到下一个结点，不同意时流程结束，驳回有两种情况，驳回到流程发起人，也有驳回到上一审批人。n 流程发起人在流程被驳回后可以取消流程，即流程有3种方式结束：同意、不同意、发起人取消。n 需要提供超时功能，超时指任务的超时，不需要流程的超时支持；超时信息要在任务提醒中显示。n 一个省的所有地区在某个业务上的处理流程是全部相同的，任务分派的方式也全部相同的，即不存在一个业务的处理，在某个地区可能多一个环节或少一个环节之类的情况。n 流程发生在账号审批、拨付审批、公告管理和警示处理业务中，业务流程总数在10个左右。n 流程的任务列表按子系统分类显示，即整个系统有多个任务列表，同时首页上有简要的任务提醒摘要信息，并能导航到不同的任务列表；任务列表上的业务信息根据业务不同显示的也不同。n 在web上提供按业务和流程信息查询流程的功能，不同子系统的查询字段不一样；查询时，有数据权限的控制，如省的领导可查看全部市的信息，市的领导只能看本地区的，普通人员只能查自己的。n 流程不会出现跨系统的审批，即各省和国家局的审批活动是独立的。n 在开发过程中，所有流程的任务按角色进行分配，以此进行调试和演示；在系统上线时，使用流程建模工具配置任务分配方式。n 所有流程的定义和任务分派方式在系统上线前都需要可自由变动。4.3.2 工作流的使用n 本系统按intelliFlow通常的开发模式使用，即首先使用工作流建模工具建立流程和进行任务分派，流程框架封装工作流的调用并将流程与业务关联起来，开发人员在流程开发时不需要接触到对工作流的直接调用。n 在系统上线前，需要使用工作流建模工具修改分派策略，使与实际的组织数据匹配，然后再上传部署流程定义。4.3.3 工作流的集成工作流需要以ear包的形式运行在应用服务器环境下，本系统和工作流集成的方式是在intelliFlow发布的ear包中添加本系统的web application(war包形式)，删除发布包中不需要的如下文件：demo.war，demo.jar，intelliFlow-mns.jar，org.war，同时修改META-INFapplication.xml，在其中增加本应用web application的部署描述。4.3.4 系统流程设计n 流程分包管理，一级包名为他tfm，二级包位account(账号审批)、payroll(资金拨付)、警示处理(notify)和公告管理(bulletin) 。n 在开发过程中，所有流程按单位号+角色进行分派，其中单位号为流程变量。n 由于本系统流程不多，为显示内容丰富和直观，流程设计不做归纳整理，即需求有几个流程，流程设计时就定义几个。n 在系统上线前，如果组织数据和分派方式不一样，需要通过流程建模工具配置分派策略；如果流程增加新的结点，需要做一定的页面开发；如果不使用本系统提供的组织模型表，组织数据的获取需要重新开发; 如果需要其它的流程功能, 可能需要一定的开发(如修改页面)。系统包括如下流程(注：没有标明省的任务执行人都指是被监管单位的人)(1). 开设申请 (包ID：tfm.accouont，模板ID：openaccount)(2). 开户办理 (包ID：tfm.accouont，模板ID：accountconfirm)(3). 销户、账户信息变更(包ID：tfm.accouont，模板ID：modifyaccount)(4). 账户状态修改(包ID：tfm.accouont，模板ID：modifystatus) (5).另外2个子系统的流程待需求细化和分析后补充。4.3.5 流程处理框架流程处理框架的业务组件对应的接口为com.longtop.iwf.WfService，采用Spring框架。本系统中的动作都是人工动作，流程中的人工动作分为数据录入和审批环节。业务数据的处理和流程数据的处理分开进行，业务数据由业务逻辑实现处理，流程数据由工作流引擎处理，所以这些操作包在一个Spring的service中，通过配置JTA事务支持，实现业务操作和工作流使用EJB实现的操作的事务一致性。流程处理框架目前提供的主要服务有(具体参见Javadoc.)： 流程方面，发起和取消流程。 流程变量，取得和设置流程变量。 任务列表，取得任务列表。 任务方面，接受任务（start,continue,resume）提交任务（commit），挂起任务(suspend)。 组织方面，提供流程框架用到的与组织相关的一些方法，这里的组织指使用工作流组织模型和表结构。 主要的类有： com.longtop.iwf.WfClient 封装intelliFlow工作流的API com.longtop.iwf.WfServiceImpl 流程处理，包括流程与业务的关联建立，调用WfClient的流程相关功能。 com.longtop.iwf.IwfExtendServiceImpl 实现辅助功能， 如根据用户号取得用户在职位、角色、部门、机构的信息。4.3.6 流程基本操作一个业务一般由经办申请、一级或多级主管审批组成。一个标准业务操作流程如下图：任务操作说明： 申报：任务提交，流程进入下一步骤。 取消：取消申请，流程结束。 同意：表示审批通过，可以进入流程的下一个步骤。 不同意：申请被取消，流程结束。 驳回：表示审批没有通过，要做适当修改，任务驳回至上一个步骤或申请人，根据业务的不同处理不同。(1). 发起流程 业务数据输完后，点“提交”，提交业务数据，同时发起流程并记录流程和业务的关联关系。流程发起为首结点执行。 基础的Action com.longtop.iwf.web.BaseProcessAction实现发起流程并记录流程和业务的关联关系，具体的流程处理，需要写一个子类action，实现业务数据的处理，一类业务对应一个子action。如: BasAction为系统最底层的action，BaseProcessAction处理和流程有关的公共内容，AccountProcessAction实现如下的API，调用账户开设申请的业务逻辑处理方法，在该方法内提交处理业务数据和调用工作流API处理流程数据。时序图如下：其中AccountAppProcessAction和IOpenApplyService和需要发起流程的具体业务对应，WfService为流程框架处理类，WfClient封装对工作流的调用，WorklistLocal为工作流对外的接口。 根据工作流应用框架要求，发起流程前需要配置好表IWF_BIZ_CATEGORY和IWF_PROCESS_CONFIG。 需要发起流程的页面要hidden两个字段的值，即bizCode和bizName，与IWF_BIZ_CATEGORY表中的配置对应。 由于工作流是使用EJB实现，为保证实现事务的控制，应用的service使用JTA事务，并且调用的其它service不要有事务控制，直接使用xxxTarget。 PROPAGATION_REQUIRED PROPAGATION_REQUIRED PROPAGATION_REQUIRED PROPAGATION_REQUIRED,readOnly (2). 取得任务列表 由于本系统有比较多的根据业务信息查询审批任务，不同的子系统业务信息数量和内容不完全一致，因此，有关任务的查询都不直接调用工作流的API实现，而是关联业务表、流程业务关联表、流程表、任务表直接查询，查询结果分页显示，分页功能使用PowerWeb的表格控件实现。 数据库的查询使用iBatis 任务列表的获取如下，在Action内将查询条件拼成Hashmap后，调用查询实现类，查询获得任务列表信息，其中包含业务信息和流程信息，再分页显示。(3). 选中任务 选中任务指选择任务列表中的某一条任务，进行审批。选中任务的主要操作是要获得对应的业务信息和流程信息，显示在审批页面上。 实现机制为：当前任务选中后要进入的JSP文件和获得页面数据的handler配置在数据库中，即表IWF_NODE_CONFIG中；选择一条任务后，通过调用工作流的API获得流程信息，根据流程信息的MPID在表IWF_NODE_CONFIG中找到对应的配置信息，执行handler获得业务数据，最后forward到配置的JSP页面。 基础的Action com.longtop.iwf.web.BaseAcceptTaskAction继承BasAction，实现任务选中后的操作，包括找到和当前结点操作对应的JSP文件和业务处理handler。本系统中，不需要使用子类action。时序图如下： 业务处理XxxHandler继承com.longtop.iwf.handler.BaseTaskHandler实现当前任务相关业务数据的获得。其实现实通过对应业务表中主键的bizId获得业务信息。Handler的处理框架如下：public Map startTask(IwfTaskVO iwfTaskVO, UserProfileVO upvo) throws GenericException String bizId = iwfTaskVO.getBizId(); /根据bizId查找业务数据 /实例化一个JSP页面上要使用的form, 该form继承于BaseTaskForm this.setKeyValues(iwfTaskVO, form实例); Map result = UtilMap.makeMap(form实例名, form实例); return result; (4). 任务审批 任务审批有同意、不同意和驳回三种结果。 任务审批通过调用com.longtop.iwf.web.BaseTaskAction实现。本系统不需要使用子action。 审批意见的处理：在提交任务commitTask 时，审批意见直接存入intelliFlow Task 表的Memo 字段中，方法为：建立一个字符串类型的临时变量，变量名为com.cit.wf.util.Constant.SYSVAR_TASKMEMO，审批意见作为该变量的值，将该变量放入提交的流程变量集中即可，流程引擎会自动取得该变量的值存入Task 表的Memo 字段中。(5). 流程查询流程查询在业务上称审批查询，在web上表现为多个菜单，一个菜单对应业务的一个分类。输入信息包括：流程信息、业务信息；输出信息包括：流程信息、业务信息、当前任务信息（如当前环节、当前处理人），不同的业务分类对应的业务信息不一样；流程查询还需要考虑数据权限控制，领导能看全省的，市的领导只能看个人的，普通人只能看自己的。实现方案如下： 同“取得任务列表”进行查询。 在查询时使用数据权限控制方案，参考“4.2.3 数据权限控制”4.4 规则处理本系统使用规则系统处理警示提醒。规则的表达方式和规则系统的调用方式待需求细化和分析结束后补充。4.4.1 开发过程规则的开发可以分为两块，首先是业务用户组织和定义业务规则，然后是技术人员映射技术实现。在本系统中，规则的所有开发都由技术人员处理。4.4.2 规则定义具体组织和表达方式需要待需求明确和分析后确定。4.4.3 规则执行具体使用方式需要待需求明确和分析后确定。4.5 消息服务4.5.1 功能描述n 消息服务构件负责提供报警方式的可配置和报警内容的可定制，并完成消息的发送和发送痕迹管理。发送痕迹管理采用文件形式保存，每天发送的痕迹保留在一个文件中，消息发送失败的痕迹保存在一个专门的文件中。n 系统提供的报警方式为邮件和短消息，消息的发送人统一为系统设置的一个邮件地址或手机用户n 发送方式是按业务配置，即不同的业务消息发送方式可不一样，如果业务的消息发送方式没有配置，使用整个系统缺省的方式。n 为实现消息的发送，用户要保证基础条件满足，即有邮件服务器或开通短消息发送渠道。4.5.2 邮件发送邮件发送使用javamail，通过Socket连接邮件服务器，发送邮件。邮件的发送为异步方式，先将邮件信息保存在数据库中，再使用任务调度扫描邮件队列，并发送邮件。邮件的消息内容使用velocity的模板机制，不同的业务发送模板不一样，使用文件形式配置；不同业务的发送人使用规则系统定制规则决定。4.5.3 短信发送短信发送有3种方式，下面介绍一下各自的实现方式及特点：1、 向已有的短信平台发送数据，由短信平台代为发送短信。这样的短信平台提供商有新浪、搜狐等。此方式一般采用HTTP的数据提交方式，接口简单，开发成本低，但要求服务器必须具备internet条件，对服务器的安全性要求较高，且功能较为单一，一般只做短信的发送。2、 通过短信网关发送短信。建立短信网关专线，使用CMPP（移动）、SGIP（联通）、CNGP（小灵通）协议进行数据的发送。此方式具备短信交互功能、吞吐性能好，但运行费用、开发成本较高。3、 采用GSM Modem发送短信。公司已有多个此方式的成功案例，具备多种变成语言接口（ActiveX、Java、C#），可实现短信的交互功能，开发成本低。本系统支持向已有短信平台发送数据和采用GSM 方式发送两种方式，前者的机制十分简单，连接短信平台并发送就可以，这里着重介绍后一种方式的实现。(一) 系统实现图 (二) 系统分析系统使用专门一台短信服务器与移动短信网关进行短信业务处理，短信服务器使用GSM Modem直接与移动接收发送短信，短信服务器可选用一台或多台GSM Modem同时与移动网关进行短信收发，设备数量由业务量大小而定，如在系统使用初期业务量较小，可用较少的GSM Modem ，如果业务量增大后，由于 GSM Modem 每发送一条需要6-10秒的时间，短信服务器如果不能及时完成信息处理，就可以增加多台GSM Modem 并行处理提以高数据流量，减少发送延迟。使用多台GSM Modem也可提高系统稳定性，当其中某些GSM Modem设备故障，系统也可保持运行。系统可实现按需