智慧校园一站式服务平台 任务中心设计与实现

摘要：一站式服务平台建设的主要目的，是以统一身份认证为纽带，以学校主数据库为基础，将面向教师和学生的各业务系统，剥离或者重构系统的服务，进行师生信息服务的集中，从而建设学校的一站式服务平台。但以此为建设方案的许多实例，只实现了服务发起的汇聚，缺没有实现服务审批的汇聚。文章以融合校园服务平台为实施主体，以解决学校各业务系统审核任务分散的问题为目的，提出了任务中心的功能设想。任务中心要求兼容不同的流程引擎任务的整合，需支持不同的工作流任务驱动方式，同时支持移动端的同步访问；描述了任务中心的功能和接口设计，以数据库存储任务数据，API标准接口提供数据交互，前端展示任务为主要功能完成了任务中心的设计和实现。

关键词：信息化系统、服务平台、任务中心、智慧校园

1. 引言

当前，各高校的服务大厅、一站式服务门户、师生综合服务门户正在如火如荼地建设中、很多高校都基于碎片化理论在建设学校新一代的校园服务门户，以统一身份认证技术为纽带，依托各个业务系统的数据，引进流程引擎，集成业务系统的各种功能，从而将面向师生的应用功能进行抽离，通过松耦合的方式，实现服务的汇聚。我们基于微服务架构的思想，对学校的各项业务进行重新梳理，按服务性质和内容类别整合服务，按学生服务，教师服务，科研服务，管理服务等分解成各个最小的功能服务单元，再重新组织，汇聚，组合成各种服务，呈现给用户，使学校师生正在“能找到服务、会使用服务”。

然而，从高校服务平台最终的建设成果来说，虽然我们实现了服务的整合、数据的整合、身份的整合，但大部分的服务只是实现了申请、发起整合，而一个服务的过程除了发起，还包括任务的审批以及审批记录的汇总查询。

在建设学校信息业务系统时，往往是各个厂家采用市场中成熟的产品并以此为基础来建设。不同的管理业务系统使用的成熟产品也不同，他们之间登录机制不同，开发语言不同，数据库结构不同，系统设计分离，系统界面样式各异，依据目前的技术，将不同的系统中的服务抽离，碎片化，再汇聚到校园服务平台，目前实现了登录认证的统一，服务入口的一站式，异构数据的交换，但各个业务系统事务审批的汇聚、展现和查询却没有实现，或者只是实现了简单的消息提醒。

智慧校园一站式服务平台汇聚了许多业务系统的服务，其中流程类的服务都需要流程处理人审批，不同的业务系统有各自的待办任务中心,如果审批人需要分别进入不同的业务系统去处理，这对审批用户的体验及其不好。但不同业务系统的流程引擎平台不同，流程任务的处理逻辑不同，审批任务数据存储的信息不同。因此，如何解决任务处理的集中化、任务数据的集成化是需解决的重要问题之一。

综合以上提出任务审批的相关问题，利用现有的计算机信息技术，在校园服务平台上建设统一汇聚，可接入不同流程引擎平台，对接不同业务逻辑的，并能同时应用与PC端和移动端的任务中心，应是待解决的问题。本文以一站式服务平台为基础，提出了任务中心的设计和功能构想，描述了任务中心的功能和接口设计，旨在解决学校各业务系统审批任务分散、审批记录查询不便的问题，使服务平台更集中，便捷地为全校师生提供信息化服务。

2. 系统设计

任务中心系统设计的核心思路是以一站式服务平台为框架，以目前使用的技术为开发基础，实现学校各个业务系统任务审批的集中化。系统以任务处理人为中心，统一展现其跨业务系统的个人任务、流程数据信息，实现审批任务统一入口，为用户提供待办任务、已办任务、办结任务、流程跟踪等类别的审批记录分类汇总。同时，任务中心以独立服务的形式注册集成到校园服务平台上，以单独应用的形式独立部署运行。另外，任务中心提供标准的任务接入API，为第三方业务系统提供任务的接入方式。任务中心系统设计的目标是纳入不同业务系统的流程任务，兼容不同业务系统的流程驱动方式，接受不同形式的任务审批数据存储形式。

建立统一的任务中心，可以使第三方业务系统的流程任务通过固定的格式、以数据的形式推送到任务中心。任务中心按第三方业务系统流程任务的状态分别展现待办任务、已办任务或办结任务。用户可以通过任务链接直接进入第三方业务系统任务表单进行任务处理。统一的任务中心系统的设计方案如下。

• 作为单一的应用，任务中心应为独立的功能系统，必须可以单独运行和被访问，符合校园服务平台微服务的设计理念，尊守学校校园服务平台的服务注册和接入标准，可作为校园服务平台的栏目存在，并且任务中心以服务的形式体现在服务平台中。
• 任务中心应包括多个标签也，包括待办任务、已办任务、办结任务以及任务跟踪、根据任务办理的状态展现与用户相关的其他第三方业务系统的流程任务消息。
• 为第三方业务系统提供标准的API，供第三方系统对接进行数据传输，将任务推送到任务中心。
• 任务中心的展现应支持移动端，实现移动端的任务中心数据展现。
• 任务中心可接入不同的流程类技术，包容不同的流程任务驱动模式，包括流程引擎类的，如以单一事务流转的流程任务；包含以审批状态驱动审批流转的流程审批类任务。
• 任务中心需支持和接受业务系统中任务处理的不同功能逻辑，包括任务的保存、提交、转发、加签以及删除等功能。

任务中心系统在定位上属于一站式服务平台的组件，各接入业务系统的不同流程类的审批任务作为数据源向任务中心推送和交互任务状态。

3. 系统实现

任务中心系统功能整体上分为展现层、数据层、接口层、接入层，分别对应任务在校园服务平台中的展现、任务数据的存储、任务数据交互API以及业务系统调用接口接入，具体功能框架如图1所示。业务系统的审核数据调用任务中心的交互API，将审批任务推送到任务数据库存储。任务中心数据库存储业务系统推送过来的流程任务数据。任务显示页面读取任务数据库所有的任务数据，并集成到校园服务平台调用展现。对任务状态或记录的更新，同样调用任务交互API更新。

1. 任务交互API设计

任务中心的API采用Web Service接口技术，以JSON（JavaScript Object Notation,JS对象简写）的数据格式，按固定的数据设计字段将任务数据推送到任务中心的数据库表中。JSON是一种轻量级的数据交换格式。它基于ECMAScript(欧洲计算机协会制定的JS规范)的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。采用JSON数据格式可以更好地提高数据传输的效率。

任务中心的API由业务系统调用，业务系统的每个流程，根据流程节点的多少，对应一串流程数据，为保证数据的唯一性，应该定义业务系统的唯一ID，每个流程ID，每个流程节点的ID，并作为数据的联合主键，定位流程的唯一性。

任务交互API包括添加和更新功能。推送任务数据时，先进行JSON数据格式效验和约束检查，再进行业务逻辑检查，逻辑检查时，接口通过联合主键检查数据是否已存在，如不存在侧添加记录，如果已存在，则进行状态更新。在任务数据推送时，根据添加和更新的需求，JSON数据字段除关键字段外，其他字段可根据实际需要推送更新。为保证数据的完整性和有效性，数据接口不提供删除功能，但提供对数据记录的删除标记。另外，任务数据的交互API还包括日志记录和结果反馈，便于业务系统对推送结果的跟踪和问题排查。

2. 任务数据显示和查询

数据显示接口由任务中心的前端页面功能实现，根据流程任务的状态，按待办，已办，办结和跟踪分栏显示，每个栏目提供任务主题，任务相关时间任务创建人等关键字段查询。任务中心的前端页面功能必须完成学校的统一身份认证对接，需要安装校园服务平台的规范标准开发。任务中心利用Widget技术将待办任务、已办任务、办结任务、跟踪任务逐个分栏显示在校园服务平台中，也可以在校园服务平台中实现任务中心的独立访问。

3. 数据字段设计

从实际业务上来说，较少可能出现瞬时大并发量的情况，所以从应用设计上满足一定的并发量需求即可。为了满足设计需求，任务中心的数据字段应满足共建共享，标准规范的要求，能满足通常的任务流转需要，应具有包容其他流程引擎的任务数据属性。因此，在功能设计时，需要充分调研业务系统的任务流程及其数据字段。任务中心的数据字段设计包括但不限于以下重要数据字段 如下：

 

 

4. 数据同步容错

业务系统向任务中心推送任务数据时，考虑到网络不通，任务中心本身等故障原因，会影响任务数据的推送，可能会带来数据同步的问题，这里要求业务系统的推送任务数据时，需要有完整的错误处理机制。先要对推送进行日志记录，在同步推送失败时，进行重试，错误达到3次以后，则记录下来，以便管理员排查处理。

5. 功能设计

任务中心的功能是以个人为主体，按个人对任务处理的状态分为待办任务、已办任务，办结任务以及任务跟踪。

待办任务是针对个人需要处理的流程节点任务，以当前登录用户为关键字，从任务存储数据库中查询处理人为个人，且状态是末执行中的任务，供个人用户查询。已办任务与待办任务的区别就是任务状态为完成，其他功能相同。待办任务和已办任务都是指流程中的末一些节点处理任务，办结任务是任务的所有节点都已处理完的任务。待办任务、已办任务、办结任务是以任务的处理人为主体查询的，而任务跟踪是以任务的创建人为主体，显示当前用户创建的任务，无论是办结或者末办结都会显示在任务跟踪栏目中。另外，无论是待办任务还是已办任务，办结任务都可以通过任务主题，任务创建时间等字段进行定位搜索到指定任务。