微服务办事大厅综合解决方案基于“以人为本，以服务为中心”，的理念，将移动互联、大数据、云计算等信息技术应用到高校公共服务之中，为师生和社会公众提供全方位、主动式、精准化、个性化、一站式的高效便捷的融合服务成为智慧校园服务发展的新方向。
基于微服务架构模式的网上办事大厅，采用一组服务的方式来构建一个应用,服务独立部署在不同的进程中,不同服务通过一些轻量级交互机制来通信，服务可独立扩展伸缩,每个服务定义了明确 的边界,不同的服务甚至可以采用不同的编程语言来实现。
在“互联网+”时代，随着信息化技术在各所高校中的推行与发展，我校的校园局域网都己经初具规模，呈现出更好的发展势头。在数字化的校园建设过程中，我校的基础平台以及各部门的业务数字系统也都己经建成并有所发展。就目前形势来看，校园的信息化水平日益提高，信息网络化技术飞速发展，这些都促使各各所高校的师生对业务办理部门的要求更高，同时也推动了信息化的服务不断自我改进和完善。目前，我校虽然己经具备信息门户，但是许多业务的办理、职称申报、表格的填写以及流程的审批等仍然没能实现网上办理。以往的业务办理流程较为复杂，难以进行结果的跟踪，也缺乏及时的反馈与评价，难以满足广大师生的需求。
因此，急需探索新型融合服务建设模式，全面提升信息化服务架构，梳理业务流程，促进信息资源的充分共享利用，实现面向师生提供高效、多渠道的网上办事信息化服务。
建设目标
以人为本，建设“线上申请，一站式服务，多渠道通办”为核心的融合服务体系。该体系以事项、流程、服务为核心，整合资源，从全局进行服务规划与服务渠道建设，规范事务办理和协同流程，解决跨部门协同服务的难题，统筹学校各部门服务资源向用户提供统一服务，促进服务模式建设创新，实现服务流程优化、服务模式多元、服务渠道畅通，为向“服务型”高校转型打下坚实的信息化基础。
设计原则
根据项目总体建设目标，方案的架构设计需要遵循以下原则：
l 健壮性原则
健壮性是系统的基础，本项目整体采用Linux操作系统服务器，分布式架构，各个组件模块之间采用松耦合设计，各个系统组建单独进行严格的测试及市场考验。
l 标准性、开放性原则
本项目系统所涉及到的软硬组件都遵循国际或者行业标准开发施，软件开发部分严格按照开发规范进行设计。
l 先进性原则
系统须采用业界公认先进的和标准的软件技术，符合信息技术发展的趋势，保证系统在可预见的阶段内有强大的生命力。
l 可扩展原则
本项目系统采用松耦合组件设计，各个组件之间独立开发运行并交互。数据访问开设标准api接口，开发者可以根据系统开发标准进行功能扩展开发。同时，系统运算、存储等资源可以根据实际使用情况与需求做针对性动态扩展，保证可拓展的同时完全不影响系统正常运行。
l 安全性原则
安全保密是高校信息化建设的关键，平台涉及到学校人员数据、业务数据等，因此安全性需要放在首位进行考虑。系统层面要有设权限系统，控制访问者的系统访问权限及数据访问安全。系统并设有容错及安全恢复机制。
l 稳定性原则
系统采用故障检查、告警和处理机制，保证数据不因意外情况丢失或损坏；采用灵活的任务调度机制实现负载均衡，防止“瓶颈”产生，在任何情况下，都保持可预见的输出。
l 高效性原则
系统从计算到存储均采用分布式架构，并且能不断优化性能。分布式系统架构能够合理运用每一份系统资源，实现计算、存储、分析资源得到更充分、更高效的利用，最终实现同等计算资源情况下更高效的计算、存储、分析性能。
项目建设内容
PC服务门户
2.1.1 访问方式
系统支持游客访问模式，未登录时，为游客访问，可以浏览和检索校内的事务及相关办理指南。登录后进行个人中心，可以获取与自身有关的事务，并可以进行业务的办理。
服务门户平台提供两种登陆方式：1、与学校信息门户单点集成，校内师生通过信息门户即可直接进入一站式服务平台；2、系统独立登陆认证方式，提供系统级管理员后台登陆以及特殊情况下用户使用一站式服务平台的第二入口。
个性化界面
本项目提供的界面风格，将根据学校提供的素材及学校特色进行设计，使界面具有良好的视觉设计，并能体现现代风格与学校特色，让用户易懂易用。
且按角色设计个性化界面，包括领导、教师、学生及不同类别的学生等角色，展示与角色相关的信息。
学生首页示意图
2.1.3 服务检索
为全校师生用户提供事项查询与服务指南查看服务，支持包括模糊搜索、标签搜索、基于历史记录、最近访问等在内的搜索方式。可以通过相关关键字检索对应的事项以及相关指南，用户输入相关关键字以后，点击查询功能即可搜索出与输入关键字相关的事项列表，点击列表以后中的某一项事项以后，进入事项办理向导页面，该页面详细描述了办理该事项的相关指南，其中包括但不仅限于受理机构、事项类型、办理对象、办理指南以及附件表格等数据项。
事项服务指南
2.1.4 热门事务
提供热门事务在一站式服务平台的展示，根据事务的办理和访问次数自动产生最新的热门事务。
2.1.5 推荐事务
根据角色推荐给用户个人相关的事务，比如，毕业离校时为学生推荐离校办理服务；教师职称评定时期为教师推荐评职的相关服务。
2.1.6 我的收藏
面向提供用户事务收藏功能，用户可以将自己已经办理的、未办理但是感兴趣或关心的事务添加到我的事务收藏中，方便下次快速办理，而不用去事务中心检索查找。
2.1.7 服务咨询
提供用户对办事事务进行咨询功能，可以在线对管理人员发起咨询，提供常见问题查看功能。
提供离线留言功能，以便管理员上线后可以对咨询进行回复。
2.1.8 服务办理
通过事务展示界面点击具体事务可以直接进入办理界面进行办理，相应权限的人员对事务申请进行审批处理；支持一对多审批，:如学生奖助学金申请、学生公选课等学生单个申请，教师可以批量审核。
系统提供个性化展示，每个用户只能看到与个人相关的办事服务。
2.1.9 流程跟踪
用户可以跟踪事务办理的进度，如正在办理流程的当前的状态（哪个节点、有没有开始处理、以及处理了多久、下一个处理节点等）；还可以查看已经办结事务的办理状态、当前处理人和上一步处理时间等信息。
2.1.10 事务评价
可设置对事务进行评价，可以查看事务的评价信息，管理员可以对评价进行审核。
2.1.11 事务分类
提供对事务的分类管理功能，可按业务类型、功能类型和服务对象等进行分类，分类可以自定义，按业务可分为生活、学习、数据和科研等类型，按功能可以分为查询和办理，按服务对象可分为教师、学生和访客。
2.1.12 事务统计
提供对大厅的访问统计服务，如可以进行最受欢迎的事务统计、评价最高的事务统计、办理最快的事务统计、效率不高的部门统计、等等；统计周期可以是近一个月、半年或一年等。
2.1.13 快捷通道
提供快捷通道功能，熟悉业务流程的用户可以通过快捷通道直接进入业务办理界面。
2.2 微门户
2.2.1 与PC办事大厅集成
提供学校服务大厅的微门户入口，微门户支持基于学校的微信企业号完成建设。功能与WEB 版服务大厅功能保持同步的，提供一致性的服务体验，并兼容iOS、android、WP等各大操作系统。
微门户示意图
2.2.2 现有企业号集成
本项目将完成与学校现有企业集成，在学校现有企业号中构建微信端的办事大厅，通过微信企业号可进行事务办理、流程跟踪等功能。
2.2.3 消息推送
系统提供将服务平台消息推送至微信端，事务办理过程中面向申请人员及办理人员的各种提醒通知，通过微信主动推送给用户。
消息推送示意图
2.2.4 个性化功能
支持根据用户的身份提供个性化功能，每个用户登录微信门户一站式办事大厅界面后，获取个性化的功能服务，根据身份显示不同的应用模块。
2.2.5 身份漫游
系统能够与学校已有或将有的身份认证平台集成，实现基于身份认证平台的统一身份管理和统一身份认证。微门户为登录的唯一入口，用户进行过身份认证后，实现用户一次登录，进入应用无需用户输入用户密码再次登录。
2.3 微服务基础平台
相对于传统的单体应用架构,微服务架构通过将 功能分解到各个离散的服务实现对应用系统的解耦, 具有明显的优势:复杂度可控,每一个微服务专注于单一功能,代码 量小、复杂度低,服务之间通过接口通信,服务边界清晰;技术选型灵活,可以针对不同的业务服务特征选 择不同的技术平台或产品,有针对性的解决具体的业务问题;独立部署,微服务运行在独立的进程中,当某个 微服务发生变更时,可独立进行部署,无需编译、部署整个应用,使得服务发布更高效,同时降低对生产环境 所造成的风险,缩短应用交付周期;方便扩展,每个服务可以根据实际需求独立进行扩展；容错，在微服务架构下,故障被隔离在微服务内部，可通过超时重试、多副本策略等机制实现应用层面的容错,避免全局不可用。
2.3.1 服务网关
服务网关是微服务架构设计中一个不可或缺的部分，需要通过API网关封装系统内部架构，为每个客户端提供一个定制的API；本项目在通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还需具备权限控制等功能；客户端只需要同网关交互，而不必调用特定的服务。API网关为每一类客户端提供特定的API，减少客户端与应用程序间的交互次数，同时需要简化客户端代码。
服务网关具体功能需求如下：
1、对客户端实现身份认证；
2、通信会话的密钥协商，报文的加密与解密；
3、日常流控与应急屏蔽；
4、内部响应报文的场景化裁剪；
5、支持「前正后反模型」的集成框架；
6、报文格式的转换；
7、业务路由的支撑；
8、客户端优先的超时机制；
2.3.2 负载均衡
负载均衡在微服务架构中需要包括两大功能：首先是用于业务网关对客户端的负载；其次用于微服务之间和内部调用的负载。
主要需求如下：
1、低并发度优先；
2、随机，按权重设置随机概率；
3、轮循，按公约后的权重设置轮循比率；
4、本地服务优先获取策略；
5、一致性 ，相同参数的请求总是发到同一提供者；
6、权重可配置的负载均衡策略。
2.3.3 服务注册与发现
微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，客户端消费服务时需要实现服务注册发现机制，从而获取给其发送请求的服务实例的位置，同时服务提供方一般以集群方式提供服务，需要解决服务提供者的负载均衡和健康检查问题。项目实时需要建立一套服务注册表，即一个包括服务、服务的实例和其位置信息的数据库。各服务实例需要在启动时注册至该服务注册表，并在关闭时进行注销。该服务的客户端以及/或者路由器通过查询此服务注册表以找到可用的服务实例。
服务实例必须向注册表中实现注册和注销，必须同时满足自注册模式和第三方注册模式。服务注册表是微服务架构中重要的组件，必须采用高可用方式部署，发现机制需要包括客户端服务发现、服务器端服务发现两种机制。
2.3.4 服务治理
微服务架构需要由多个服务组成，服务之间依赖关系错综复杂，一个前端请求一般会依赖于多个后端服务。由于服务可靠性概率问题，服务可能会出错或者产生延迟，因此项目要求应用必须对其依赖的故障进行容错和隔离，否则该应用本身就处在被拖垮的风险中。在流量高峰时，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源(线程，队列等)被耗尽，造成雪崩效应，严重时可致整个系统瘫痪。微服务架构服务治理模块需要实现容错组件、实现故障隔离、容错、降级、限流、快速失败方法等解决稳定性问题。
要实现服务的容错管理，首先要实现实时的采集和统计服务运行数据，包括服务运行时间，次数等，这些是服务容错，限流或容错策略计算的基础。
2.3.5 配置管理
微服务系统有很多依赖配置，例如访问数据库有连接字符串配置，连接池大小和连接超时配置，这些配置在不同环境(开发/测试/生产)一般不同，比如生产环境需要配连接池，而开发测试环境可能不配，另外有些参数配置在运行期需要动态调整，例如，运行时根据流量状况动态调整限流和熔断阀值。微服务的配置管理模块需要实现如下功能：
1、非开发环境下应用配置保密，避免将关键配置写入源代码；
2、不同部署环境下应用配置隔离；
3、同一部署环境下的服务器应用配置一致性，即所有服务器使用同一份配置；
4、分布式环境下应用配置可管理性，即提供远程管理配置的能力。
2.3.6 服务通信
微服务架构模式将单一应用程序划分成一组小的服务，服务之间需要互相协调、互相配合；在构建微服务架构中，服务和服务之间通信采用轻量级的通信机制，实现彼此间的互通互联，互相协作。轻量级通信协议必须使用与语言无关、平台无关的通信协议。同时要求实现同步通信和异步通信两种通信架构模式。
2.3.7 日志中心
微服务架构体系下，业务调用链越来越复杂，一个请求可能会涉及到多个个服务的协同处理，因此本项目微服务的日志架构必须满足快速定位各个服务的状况的功能。具体需求如下：
1、故障快速定位
通过调用链跟踪，一次请求的逻辑轨迹可以用完整清晰的展示出来。开发中可以在业务日志中添加调用链ID，可以通过调用链结合业务日志快速定位错误信息。
2、各个调用环节的性能分析
在调用链的各个环节分别添加调用时延，可以分析系统的性能瓶颈，进行针对性的优化。
3、各个调用环节的可用性，持久层依赖等
通过分析各个环节的平均时延，QPS等信息，可以找到系统的薄弱环节，对一些模块做调整，如数据冗余等。
4、数据分析
调用链是一条完整的业务日志，可以得到用户的行为路径，汇总分析应用在很多业务场景。
5、日志分析
对于重要的日志，满足索引，检索、排序、分类，并且提供一定程度的可视化、分析日志的功能。
6、可根据数据规模横向扩展
随着业务的快速发展，当用户数量加倍时，简单的加几台机器或者服务器就可以承担日志管理功能。
7、高效传输接口
可以方便的通过API或者通过扩展接入到已经有的监控、报警，或者其他系统里面。门账号发送权限。
2.4 流程引擎平台
本项目将建设校级统一的流程引擎平台，为各部门、各业务系统提供一个通用的、统一管理的具有扩展性的业务流程管理平台，对业务流程整个生命周期进行管理，包括业务流程的定义、测试验证、部署、运行、监控、管理、业务化定制调整。
提供可视化的流程建模和设计工具、图形化的流程编辑界面，可通过拖拽等操作自主配置流程及设计表单，实现快速、低成本、可持续维护的流程服务开发机制，有效应对学校管理过程中大量且持续变化的个性化管理流程要求。
并基于流程引擎平台建设一站式网上办事大厅，实现各类业务在网络上统一申报、办理的综合性服务平台。实现流程服务的集成与统一管理，并支持后续办事服务的建设集成。
2.4.1 快速业务构建能力
工作流引擎需提供多种方式的快速业务构建能力，支持从简单表单定义到复杂业务子系统的快速开发，快速响应业务需求。
n 在线表单开发
支持B/S模式的在线可视化表单建模，提供拖拽式、所见即所得的可视化化表单设计能力，实现零代码开发。
支持文本、日期、选择、文件上传等多种web交互控件
提供多种表单数据验证方案，灵活控制数据的有效性。
支持为不同流程环节定义表单内字段的只读、隐藏、编辑。
在线表单可支持脚本、事件扩展，加强表单的处理能力。
n 支持响应式表单
通过平台构建的表单要提供响应式功能，能自动识别出移动终端而自动调整布局，并能响应移动设备的触摸事件，提供良好的移动界面体验。 使得一次定义表单，多终端适配。
n 图形化业务逻辑开发
支持图形化业务逻辑开发，可以把用户的业务需求直接以分支、循环、同步等图形化编程来操作数据对象及业务组件。使得开发者无需编写代码，就能对“需求”的理解到“逻辑”的运算达到一致性，便于系统维护与未来快速响应需求变更。
n 支持业务逻辑复用
通过图形编程形成的业务处理逻辑，能够打包成构件包，并允许被不同的业务逻辑调用。实现共性业务逻辑复用，大大增加开发效率。
n 提供丰富的业务构件
系统需提供丰富的业务构件，包括数据操纵、事务操作、发短信通知、发邮件等常见业务功能构件。
系统需提供流程操纵相关的业务构件，包括流程启停、任务领取、结束、活动回退等。
2.4.2 多种运行模式
支持直接嵌入基于J2EE构架业务系统的运行模式。
支持独立运行模式，通过开放的标准接口体系进行远程调用。
支持负载均衡的集群部署。
2.4.3 流程接口规范
至少要支持WfMC/XPDL、BPMN、BPEL标准规范中的一种。
提供Java API，方便引擎嵌入运行模式下业务系统流程的操纵、检索、监控。
提供Webservice、RESTful api等远程调用接口，在独立运行模式下支持异构平台业务系统的流程接入，为学校各类业务系统的流程无缝整合提供基础能力。
2.4.4 可视化流程建模
提供可视化流程建模，能直观的通过拖拽各种图元与连线实现流程定义。
支持流程调试，在正式发布流程版本前允许设计人员模拟流程调试运行。
提供版本管理能力。
2.4.5 流程处理能力
支持20种以上的流程模式，包括：顺序流、并行分支、同步、独占选择、多重选择、多重聚合、任意循环、任意顺序等复杂流程模式。
支持子流程及动态多子流程实例分配。
支持多种任务完成策略，包括：多人顺序、多人并行、多人抢占、多人任意、指定执行、会签、传阅等业务功能。
支持灵活的任务分配策略。
支持业务流程预发布模式，即流程调整后进行临时存储、非即时生效，通过在线试运行、验证并调整完毕后统一发布才生效，降低变更的风险。
支持流程的灰度发布，即发布流程的新版本时，未结束的流程能以原有版本正确运行结束。
2.4.6 流程监控
支持图形化展示流程运行过程。
支持任务改派，可以由管理员改派任务的责任人。
支持人工实时修改运行数据，并提供人性化操作界面。
支持回滚，操作允许流程回滚到任意历史位置重新执行。
开放流程监控API，允许业务系统客户化流程监控功能，使之能与业务功能无缝集成。
2.4.7 版本管理
内置支持业务流程的版本管理，即发布流程的新版本时，未结束的流程能以原有版本正确运行结束。
2.5 应用管理中心
本项目建设的网上办事大厅具备应用统一管理与分发能力，能实现学校应用的统一管理与跨平台发布，可选择性发布至PC门户、微信门户，及后续建设的APP门户等，轻应用的建设将严格遵循HTML5设计规范，适配各类移动终端浏览器。并开放应用注册接口，允许第三方应用对校园提供统一服务。
2.5.1 应用注册
系统支持事务类应用与普通应用在服务大厅内注册，管理员可以往平台中注册应用，登记应用的基本信息，注册信息包括应用图标、流程描述、待办接口地址、关键词、启动入口、责任部门、业务分类等。事务类应用是指能在服务大厅检索到的办理流程、自助服务等应用。普通应用是一般的业务系统，注册到服务大厅后能为用户提供业务系统的快速链接。
2.5.2 应用管理与发布
能集中管理全校各类应用，可以控制应用上架到PC端、移动APP或微信。
可以对应用直接创建、上传、新建版本、发布、下架等操作。
可以设置多个全局的置顶应用，置顶的应用将在应用门户上优先展示。
可以为每个分类设置多个推荐应用，被推荐的应用将在应用门户的推荐列表中展示。
应用发布
2.5.3 访问统计
平台提供访问统计功能，如访问计数、排行、访问、访问来源，有助于分析应用热点，如访问来自于WEB大厅还是移动大厅，便于管理人员迅速捕捉用户需求，对应用进行分析与改进。
应用访问统计示意图
2.5.4 应用集成
全面的应用集成能力满足与第三方系统集成的需要：
1. 可以无缝集成学校统一身份认证系统；
2. 提供标准的接口规范，支持多种类型APP集成，包括支持Native-app应用、Hybrid App（混合模式移动应用）、基于Html5的web-app应用以及打包的html5（Packed Html app）应用集成；
3. 创新的界面集成，可为用户提供快捷应用消息提醒；
4. 提供开放消息API，业务系统可通过IM、UCP等渠道推送消息；业务系统也可以为自己的消息扩展处理行为。
5. 提供本地能力，移动开放平台为Web应用、Packed Html5应用提供JS API，Web和Packed Html5应用利用JS API，可以调用移动终端的本地能力，如多媒体、文件、数据库、地理位置、相册、扫码、拍照、录音、发短信、拨号呼叫等功能，为开发者提供支持，丰富用户体验。
2.5.5 应用审核
应用创建后，处于未上架状态，需要管理员审核后才能进行上架或下架，上架后的应用才能对用户展示。
2.5.6 个性化策略配置
可以按角色授权应用，如学生能看到哪些应用、老师能看到哪些应用；也可以授权应用可见的终端，如哪些应用在PC端上架展现、哪些应用在移动端上架展现。
2.5.7 用户管理与授权
实现对平台用户的统一管理，包括按角色、机构和组等进行用户的新建和维护。
根据策略规则并基于角色的访问控制技术，实现对用户集中、灵活授权和访问控制管理，从而提高系统管理效率，如可根据不同角色分配相应应用使用权限和有效期，并进行差异化的应用推荐和功能设置。
可以授权具备统一身份认证帐号的人员为开发人员，被授权者可以在平台中创建应用、更新版本、申请发布等功能。
2.5.8 应用监控
提供对应用运营数据的统计功能，包括各类应用的下载量统计、点击量统计等。
第3章 应用服务建设
建议实现如下流程服务建设：
|
序号 |
应用名称 |
功能描述 |
|
1 |
一卡通申请 |
为学生或教职工提供一卡通开卡申请 |
|
2 |
临时校园卡申请 |
学校接待外来访客时有为访客开临时卡需求，本应用为教职工提供临时卡申请服务。 |
|
3 |
临时校园卡延期 |
申请将已开通的临时校园卡延期至某个时间，流程与申请相同。 |
|
4 |
课表查询 |
查看个人课表信息。方便全校师生了解每天的课程名称和上课时间。 |
|
5 |
工资查询 |
查询个人工资相关信息，方便教职工知晓每月工资的详细组成 |
|
6 |
班车路线 |
查看学校班车时刻表（静态图片） |
|
7 |
考试安排 |
考试日程安排情况查询 |
|
8 |
调查投票 |
提供调查投票项目发布、投票、调查数据统计发布等。 |
|
9 |
补发学生证 |
学生申请补办学生证，学生处审核补办申请。 |
|
10 |
休学申请 |
学生提交休学申请。学生提交申请，辅导员确认家长是否知晓后，经过学院办公室、院长、教务处审批生效。（学院办公室需要上传休学决定。） |
|
11 |
复学申请 |
休学的学生提交复学申请。学生提交申请，医务室老师确认后，学院办公室审核同意后，分配学生至班级，学院领导确认，教务处核对备案。 |
|
12 |
学生户籍证明办理 |
学生申请办理户籍证明，相关部门审核申请。 |
|
13 |
场地借用 |
支持全校师生进行教室借用申请，填写申请表（借用单位、借用人、联系电话、教室名称、教室类型、使用设备、借用时间、具体用途等）后提交申请，审批通过后可以使用教室或其他场地 |
|
14 |
网站建设申请 |
方便学校各部门即时提出网站建设申请，可以在线提交建站需求，便捷建站。 |
|
15 |
电子邮件 |
与学校邮件系统对接，实现PC端单点登录和基于手机客户端的邮件收发和提醒服务。 |
|
16 |
接待用餐申请 |
提供来宾接待用餐申请 |
|
17 |
订水 |
方便教职工订水。提供教职工订水功能，跟现有订水系统对接，新建订水申请界面，提交申请人、电话、数量及地址等信息给审核部门进行审核。 |
|
18 |
网络故障报修 |
提供网络故障报修申请功能 |
|
19 |
域名申请、变更、注销 |
学校相关的二级部门可进行二级域名的申请、变更及注销 |
|
20 |
服务器申请 |
服务器的申请、审核。 |
|
21 |
服务器托管申请 |
服务器托管的申请、审核。 |
|
22 |
网费查询 |
查看教师或学生的个人上网账号信息、账户余额、我的账单及使用流量的明细 |
|
23 |
***权限开通申请 |
***权限开通申请的申请、审核。 |
|
24 |
用章/印申请 |
业务部门需要使用学校公章时，由申请人（拟稿人）向办公室提出用印申请，经部门领导及院领导审核通过后，方可使用印章。 |
|
25 |
教职工户籍申请 |
教师到派出所办理户籍相关业务或身份证相关业务时，需要提供后保处的集体户口个人信息页复印件给派出所。本应用为教师提供集体户口复印件的申请服务。 |
|
26 |
停车证申请 |
停车证包括临时停车证和长期停车证。临时停车证有效期为1天-1周，长期停车证有效期为1-3年，过期需要重新申请。 |
|
27 |
请假申请 |
教职工提出请假申请。 |
|
28 |
用车申请 |
教职工申请公务用车 |
第4章 系统集成
系统支持多种集成方式，并支持与第三方业务系统接口对接、数据对接等，如统一身份认证、财务系统、教务系统、资产系统、科研系统等，实现流程跨部门办理及业务数据的交换。
4.1 集成方案设计
4.1.1 接口设计原则
² 单一职责原则，能影响接口变化的只有一个原因。
² 开放-封闭原则，接口是可以扩展的，但是不能修改原有功能。
² 保证系统的安全性。
² 保证数据的一致性、完整性、正确性；
² 保证运行的高效性和数据传输的及时性；
² 具备完善的日志和监控手段；
² 接口标准化,具有通用性，符合常用接口规范；
4.1.2 常用集成方法
界面集成
将学校各系统功能界面进行集成展示，提供给用户统一的展示，方便用户查询信息和办理事务。
数据集成
通过规范数据标准，制定数据交换方法来实现业务系统间基于数据层面的共享和交互。
业务集成
各系统提供自己的业务程序接口供其它系统使用，实现各系统间业务的集成。
4.2 数据中心集成
提供与学校数据中心对接，包括从数据中心获取基础数据和向数据中心提供业务流程数据。
根据学校的数据编码标准制定业务流程基础数据结构，通过学校的数据交换工具获取数据中心的标准数据，根据学校的要求将业务流程数据通过数据交换工具同步到数据中心，实现业务流程的查询统计和分析。
4.3 身份认证集成
提供与学校统一身份系统对接包括人员机构数据同步和单点登录，针对学校目前的统一身份，我们根据身份认证配置文件和身份认证客户端对接jar包进行对接。
提供集中统一的用户与权限管理：包括组织架构、用户信息、数据与操作权限的管理与维护，系统有分级权限和逐级授权管理功能，能够很方便地对系统进行全面的权限管理；适应人员的变化，可以方便的对系统用户权限进行调整；可以无限设置所需要的权限、人员的组合；随时可以调整角色中人员组成，用于控制员工的权限。
对于组织机构、人员和角色的数据同步，提供两种实现方式，第一种是通过即时同步接口，各业务系统按接口规范实现同步的接口，统一认证平台即时调用接口将数据同步到个业务系统。第二种是通过数据表定时将组织、人员和机构数据同步到各业务系统响应数据表中。
常见单点登陆认证方式
对于单点登录认证，常见的有CAS（Central Authentication Servic是耶鲁大学开发的单点登录系统，应用广泛，具有独立于平台的，易于理解，支持代理功能），cas最基本的协议过程如下：
如上图： CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护 Web 应用的受保护资源，过滤从客户端过来的每一个 Web 请求，同时， CAS Client 会分析 HTTP 请求中是否包含请求 Service Ticket( ST 上图中的 Ticket) ，如果没有，则说明该用户是没有经过认证的；于是 CAS Client 会重定向用户请求到 CAS Server （ Step 2 ），并传递 Service （要访问的目的资源地址）。 Step 3 是用户认证过程，如果用户提供了正确的 Credentials ， CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket ，并缓存以待将来验证，并且重定向用户到 Service 所在地址（附带刚才产生的 Service Ticket ） ,并为客户端浏览器设置一个 Ticket Granted Cookie （ TGC ） ； CAS Client 在拿到 Service 和新产生的 Ticket 过后，在 Step 5 和 Step6 中与 CAS Server 进行身份核实，以确保 Service Ticket的合法性。
在该协议中，所有与 CAS Server 的交互均采用 SSL 协议，以确保 ST 和 TGC 的安全性。协议工作过程中会有2次重定向 的过程。但是 CAS Client 与 CAS Server 之间进行Ticket验证的过程对于用户是透明的（使用 HttpsURLConnection ）。
Cas请求认证时序图如下：
当用户访问另一个应用的服务再次被重定向到CAS Server的时候，CASServer会主动获到这个TGC cookie，然后做下面的事情：
1如果User持有TGC 且其还没失效，那么就走基础协议图的 Step4，达到了 SSO的效果；
2如果 TGC 失效，那么用户还是要重新认证(走基础协议图的 Step3)。
4.4 学校信息门户集成
基于门户技术对分布式系统表示层进行集成，支持大厅与学校信息门户无缝集成，实现从信息门户可直接进入管理平台办理业务。
4.5 页面集成
本项目中将各业务流程功能界面进行集成，业务可在一站式服务平台里直接进行办理，集成方式包括:
1、 IFrame集成，支持嵌入其他系统的页面，用于实现和其他网站界面的无缝集成；
2、 URL集成，基于身份认证的基础上的,以URL调用方式提供的功能服务；
3、 RSS集成，支持自动从其他符合RSS规范的网站或门户采集到需要的数据，并定义相应的服务方式；
4、 AJAX集成，基于AJAX技术的界面集成，可以将异构系统的界面在缺少第三方支持的情况下完美集成到门户；
5、 WEB剪辑，支持从应用服务器可以访问到的页面进行区域裁剪，裁剪后的内容作为提供的服务进行统一管理；
6、 API集成，提供程序API集成方式，在门户中开发页面调用业务流程的API实现业务功能的集成。
4.6 业务流程集成
使用BPM业务流程管理方法进行业务的梳理、规划，使用BPS业务流程平台（Primeton BPS）来实现流程的集成和管理，各业务系统采用统一的流程引擎实现，通过BPS的治理和监控工具来统一管理。
业务流程过程支持第三方webservice、http、socket等接口的集成，在流程和表单的每一个事件中都可以调用。支持在流程和表单中集成第三方数据，在流程和表单的每一个事件中都可以操作第三方数据。
4.7 邮件集成
通过标准邮件SMTP协议提供与邮件系统集成，向用户邮箱发送相关通知和待办提醒消息。支持在流程和表单中集成多个短信网关和邮件服务器，可以配置当前的默认网关和邮件服务器。
4.8 支持消息集成
支持与学校的统一通讯平台集成，实现消息提醒服务，如一站式服务平台待办事项提醒等，并支持短信、微信、邮件等多种手段的消息提醒。
4.9 支持微信集成
微信公众平台是运营者通过公众号为微信用户提供资讯和服务的平台，而公众平台开发接口则是提供服务的基础，开发者在公众平台网站中创建公众号、获取接口权限后，可以通过阅读本接口文档来帮助开发。
为了识别用户，每个用户针对每个公众号会产生一个安全的OpenID，如果需要在多公众号、移动应用之间做用户共通，则需前往微信开放平台，将这些公众号和应用绑定到一个开放平台账号下，绑定后，一个用户虽然对多个公众号和应用有多个不同的OpenID，但他对所有这些同一开放平台账号下的公众号和应用，只有一个UnionID，可以在用户管理-获取用户基本信息（UnionID机制）文档了解详情。
通过微信接口获取微信访问用户与统一身份系统进行身份绑定，实现微信用户的统一身份。
通过微信接口实现微信3x5菜单的管理。
通过微信接口实现关键字回复功能。
通过微信接口实现信息发布功能。
通过微信接口实现微信消息推送功能。
管理平台和业务流程与微信对接，使用微信提供的接口实现PC功能在微信端的实现，使用HTML5和CSS3技术开发适合微信展示的界面功能。
4.10 支持第三方电子签章集成
大厅支持与第三方电子签章集成，面向用户提供身份验证服务，来保障网上办事流程、数据的真实性、安全性、保密性。
第5章 系统安全
近年来，网络环境正在发生快速的变化，特别是云计算、虚拟化、大数据、移动互联网等新IT应用技术的快速发展，在为用户提供更为灵活、实用的IT应用及服务模式的同时，不可避免的对安全防护能力提出新的要求。
5.1 SSL支持
在信息安全防御方面，本系统支持业界标准的SSL2.0/3.0/TLS1.0技术，为WWW服务器与浏览器建立高强度的防窃听、防篡改、防欺诈的安全通讯通道。
5.2 IP地址访问控制
本系统还提供灵活的IP地址访问控制功能，能够灵活相互配置IP限制访问规则，进一步抵制了非法用户对敏感信息的访问。
5.3 防SQL注入攻击与XSS攻击
系统在开发时，严格遵守开发规范，从根本上防止了SQL注入式攻击与跨站脚本攻击（XSS）。系统开发完成后，经过了漏洞检测工具的测试，不存在此类漏洞。
5.4 脚本过滤
平台内的信息来自于各级信息维护人员，为了防止用户有意或无意的在页面中植入恶意脚本代码，平台对所有信息进行脚本过滤，杜绝了恶意脚本对最终浏览者的入侵。
5.5 文件上传限制
平台会过滤zip包中危险文件，包括可执行文件、动态链接库等；同时也对附件上传功能进行限制，禁止上传危险文件。
5.6 口令安全
平台具备口令猜测锁定机制，具备多钟锁定策略。当发现口令正在被暴力破解时，可以用户可以选用IP锁定策略、用户锁定策略以及混合锁定策略，防止口令被暴力破解。
同时对口令管理也需要符合下列安全规范：
l 口令的设置必须由大写字母、小写安母和数字组成的六个以上的字符。
l 系统具有自动检测弱密码功能，禁止弱密码的使用。
l 口令需要定期进行更换。
5.7 安全审计
平台对管理员、信息员的所有操作提供审计日志，便于发现非法操作。