基于工作流的平台管理系统设计，解析异构应用系统业务协同工作流平台设计与实现

「本文重点介绍关于工作流平台系统。」

对于互联网金融平台来说,重要的业务尤其是涉及资金业务相关操作时都有必要有相关的审批流程.同时在流程的流转过程中需要和各个业务系统进行交互,完成真正的业务处理, 并记录这个过程中所有人的操作以及每一步操作时所涉及数据快照,以便于内外部审计和问题的追溯。

◆✦下面为两个典型的业务流程✦◆

(注: 为了说明方便, 已经简化和修改相关步骤, 和点融实际操作不一致)

一. 借款人银行卡信息修改

该流程发起原因主要是由于借款人银行卡变更原因需要修改. 流程关键步骤为:

❶ 用户联系客户服务人员,提交申请, 包括借款信息, 手持身份证照片, 银行卡信息等

❷ 申请提交系统后, 由风控进行审核

❸ 运营部门进行修改操

二. 提前还款流程

发起流程的主要原因是用户希望按照合同进行提前还款. 流程关键步骤为:

❶ 借款人联系客服人员, 提交申请

❷ 运营生成提前还款说明书, 其包括详细金额数据

❸ 借款人确认, 通过客服服务人员上传签字照片

❹ 运营代扣还款金额, 结清借款

❺ 生成还款结清证明

在平台的实际运营中, 有各种各样的业务需要处理, 包括借款人, 出借人, 资金等等, 同时还涉及到各个不同的业务部门, 而且流程的流转操作人员和部门也随着公司业务的发展而不同的调整. 设计一个基础的流程框架和实现基础代码, 形成简洁的开发模式是该系统的关键. 因此整个系统的设计涉及到以下主要几个方面:

☞ 选择合适的工作流引擎

对于一个类似涉及到审批以及执行具体业务的系统, 基于简单的状态控制的设计, 或者自行开发类工作流引擎轮子的做法都是不合适. 所以一个开源并且被广泛使用的工作流引擎是一个正确而且必须的选择. Activiti 工作流引擎由于其轻量级, 易用性等优点目前在业界被广泛使用. 其工作流的状态机和外部系统的连接只需要通过一个ID进行关联即可, 即activiti的business key。 (如下图)

☞设计通用的底层数据来支持不同的业务

由于这样一个运营管理系统涉及到各种不同的业务数据. 如借款人信息相关涉及借款ID, 银行卡信息等; 如出借人信息则涉及用户ID, 电话号码等; 而对于资金相关如提前还款则涉及到提前还款日期, 还款金额等. 所以一套支撑不同具体业务的流程数据表结构也是非常重要.

☞ 基础框架代码的设计

一个好的设计不是一步到位的设计, 而是一个循序渐进的过程以及不断重构的过程. 但是非常重要的一点就是在一开始能够根据当前的需求以及所能预见的需求进行设计, 并且在这个基础框架代码上开发要更加便利和简洁.

◆✦以下对第二、三点进行展开✦◆

数据库设计

如上所说, 这样的一个数据设计必须能够满足:

1. 能够满足不同的业务域的需求, 如出借, 借款, 资金相关的具体业务数据

2. 能够记录每一步的操作审批或业务执行结果, 同时记录相关的数据快照

所以, 基于具体的业务进行数据表的设计是不合适的, 且无法扩展. 常见的设计为基于Key-Value的设计, 而key则是各个不同业务系统涉及到的metadata. 如USER_ID(用户ID), LOAN_ID(借款ID)等等. 设计概述如下:

一个Request代表某一个人发起的请求, Snapshot代表这个流程的每一步操作. Property则分别为Request的Snapshot的具体的数据, 当其REQUEST_ID非空SNAPSHOT_ID为空时表示其为REQUEST的属性(SNAPSHOT同理), 即用户发起请求所带入的数据. 如: 用户信息修改: PROPERTY则包括NAME(KEY)为USER_ID(用户唯一ID), ATTACHMENT(用户手持身份证照片), EMAIL(修改项)等相应的值. 而对于SNAPSHOT, 则记录对应审核以及操作的信息, 其对应的PROPERTY则保存了对某个数据修改前后的值.

基础框架代码设计

初始的场景和需求包括:

1. 一些通用的activiti流程, 如一步操作即创建后只需要一步完成操作, 两步流程 – 创建后一步审核一步操作等, 不同的业务会使用相同的流程.

2. 在activiti流程相同的情况下, 不同的业务的步骤其处理人/组则不同

3. 不同业务流程的实际代码开发应该简洁, 和工作流引擎解耦, 即实际的开 发人员 在不了解工作流引擎具体工作原理的情况下可以进行迅速的开发, 并 只需要关注具体 的业务需求

为了解决#1的问题, 则需要定义出流程--步骤—业务(请求类型)—处理人/组 的配置 关系, 并在流程流转时自动设置, 而不是在流程描述文件 (bpmn)里 指定

为了解决 #2 的问题, 则需要用服务进行封装, 抽象出一些接口以及基类的实 现, 并 应用一些常见的设计模式(工厂模式)和java的特性(反射).

下图为基本的架构设计

基于这样的框架完成基础代码后, 最终对于一个实现具体业务的开发人员来说, 其实 现一个业务流程代码主要包括:

1. 实现一个创建Request的页面, 用于录入业务数据

2. 实现一个Request详细页面, 用于展示详情, 包括操作历史, 和业务操作按钮

3. 实现该业务涉及的具体步骤的操作processor类(如审批或和其他系统对接, 完成实际的业务),

4. 将流程涉及的processor和对应的业务类型, 流程名, 流程步骤进行注册绑定

演进过程

正如上面曾说到, 对于一个系统设计, 不可能一步到位, 在最初时要抓住最需要解决的问题, 比如在这个系统开始阶段, 最核心的设计包括:

➤ 数据库设计 和RequestService对底层数据操作的封装

➤ WorkflowService对工作流引擎的封装

➤可配置化的根据业务类型(Request Type) 和配置(process_cfg)在运行时动态设置流程相应的处理人/组

持续的重构包括:

➤将各种处理类(业务处理类, 流程处理人/组分配处理类, 通知处理类) 通过RegisterService的统一注册管理, 并且支持应用对于特定的流程实现特定的处理类来替代默认的处理类

➤RequestQuery支持统一的查询入口对业务流程数据进行查询

➤ 根据业务需要提供ASync的processor处理基类, 因为实际应用中发现, 一些业务的处理(如批量)需要一段时间的执行才能完成, 而异步处理基类则完成基础实现, 并由相应子类去实现虚函数即可.

公共化工作流模块:

➤ 最近, 另外一个项目其应用到的场景和这个系统有类似之处, 其独立于该业务管理平台. 在这种情况下, 将该工作流相关的模块进行公共化, 以JAR包的形式提供, 使得另外一个系统的开发能够短期内达到同样的效果

借鉴Activiti的源代码

在设计和实现该系统时会有

这样或者那样的疑惑或者斗争,

哪一种实现更好?

别人的系统是如何实现的?

这里举几个例子

Property表里是否需要需要用不同的字段(LONG_VALUE, TEXT_VALUE, DOUBLE_VALUE等)存不同类型的值;还是直接都存成字符串, 在代码中再根据需要转成Long, Double等?当然两种实现都是可行的, 并且各有优缺点, 并且个人觉得存在不同的字段上优点更大一些(主要体现在查询效率), 但是如何更加的让自己信服? 在看activiti的文档时发现外部的业务数据以Map的方式存在activiti的数据库中, 那么activiti的设计者一样会碰到同样的问题. 通过查看源代码以及其数据库设计, 发现其将数据存入不同的字段. 但是在我的设计中, 我并没有完全照搬Activiti的处理方式, 比如: 我没有为布尔类型加单独的字段, 而是以0或者1的方式存入LONG_VALUE里。

Activiti中提供便捷的查询类, 如: ProcessInstanceQuery, TaskQuery. 其同时支持按照Process和Task相应的属性数据进行查询, 和Request/Snapshot以及property有很大的相似之处, 借鉴并根据实际情况实现自己的RequestQuery类, 支持各类复杂查询, 如: 按照指定的property的name和value查询, 支持or的查询等。

Activiti的数据库版本的自动升级. 当我们升级activiti的版本时, 其实我们只需要更新JAR的版本号, 而不用关心起底层数据库是否需要升级, activiti在其表中会记录数据库scheme的版本号, 启动时会自动判断并根据需要自动更新数据库. 这也是非常值得借鉴的地方, 尤其是当这个模块被多个系统所使用时。

解析异构应用系统业务协同工作流平台设计与实现

政务信息化进程中，各地区、各部门根据自身管理需求而引入的各种应用系统，在单个业务领域的管理上无疑有自己的特点，但由于它们无法面向整个的业务过程，各个系统之间也难以紧密集成，使得政府部门"环环相扣"的业务被这些分散的系统"分隔"开来，形成"应用孤岛".政府部门不得不花费大量的人力、物力在不同的应用系统之间切换，从而造成运营效率低下和反应迟缓。随着社会经济的快速发展，"应用孤岛"与业务协同的矛盾日益突出。IT行业的技术进步带来政务效率提高的同时，也会带来业务流程的变革。这种业务流程的变革也造成了原有应用系统无法使用或使用效率低下。

　　1 解决方案

　　针对"应用孤岛"与业务协同的矛盾，本文以松散耦合、独立于具体应用为指导思想，设计了电子政务可变业务协同工作流平台，实现多业务应用系统之间的松散耦合，松散耦合，顾名思义就是比较松散点的耦合。是种分层次的耦合。一般项目都会要求，高内聚、低耦合。而松散耦合算是种低耦合。打个比方说MVC模式，分为三层，Module、View、Controller,一定意义上算是种松散耦合。在可视环境下进行业务流程配置，即可应对可变业务流程。在本工作流平台基础上，各机构的业务系统不需要修改代码，只要在原有的系统上建立一个适配器模块，便可以完成接入工作。不会影响原有的系统，实施成本降低，运营效率得到大幅提高。

　　本工作流模型设计基于应用集成技术和WCF服务技术，独立于具体应用之外，提供流程分析、建模、重组、部署、管理、监控、评估、优化的环境。政务业务协同实施开发人员在不改变各部门现有管理模式的前提下，根据不同部门业务协同的需求，可以方便快速地利用这些工具和服务接口，在可视化的建模环境中，将异构应用系统按照流程驱动的方式整合在一起，实现业务流程管理与应用系统间的松散耦合。 

    2 可变业务协同工作流服务平台原型系统

　　2.1 平台架构

　　本工作流服务平台搭建在。NET Framework 3.5之上，主要应用了Windows Communication Foundation、Window Workflow Foundation两大前沿技术。作为电子政务、企业应用整合、信息共享、业务协同的服务平台，工作流服务平台系统具有良好的架构。　　

（1）业务流程处理框架

　　业务流程处理框架提供了设计、执行和管理业务流程的功能，并且有很强的可扩展性和可用性，它不仅可以用于实现自动化的流程管理，也可以作为基础平台搭建可人工干预的工作流服务。

　　（2）业务流程数据服务框架

　　业务流程数据服务框架采用集中式业务流程数据存储，支持多种数据存储介质。存储业务流程及业务流程在执行过程中所有传递、产生的相关数据，如流程实例、收发数据、日志等。

　　（3）消息处理框架

　　消息处理管道框架负责将接收到的消息或要进行发送的消息，根据消息的处理规则（拆包、封包），实现消息的预处理操作序列。将对象与若干XML数据包进行转换，以及对消息体进行加密、解密，提定编码、解码格式等。

　　（4）应用适配器框架

　　用于将专有的企业应用系统与标准技术连接在一起，包括各种主流应用适配器和标准通讯协议适配器，如File、HTTP、SMTP、Web Services、SAP、DBMS等。也可以把企业应用暴露的接口封装成适配器，使传统应用结构转变成服务体系结构，保护已有应用投资。

　　（5）开发和管理工具

　　可视化的建模工具将确保开发人员迅速设计出适用于多种不同应用程序和技术手段的业务处理过程。

　　（6）安全、监控工具

　　提供相应的安全、监控工具以确保传入和出站消息的安全、运行时信息和配置信息的安全以及能够安全地与不同应用系统相集成；能够实时监控流程的运行状态、跟踪流程处理结果、流程的访问控制；应用集成单点登录等。

　　2.2 工作流平台组成

　　（1）工作流设计器

　　工作流设计器为可视化的流程设计工具，用户通过拖放等方式绘制流程，并通过对环节的配置来实现环节操作、环节表单、环节参与者的配置。目前支持顺序工作流和状态机工作流两种工作流类型。

　　（2）工作流引擎服务

　　工作流引擎服务是整个工作流服务平台的，以Windows服务形式常驻内存，在系统开机时自动启动，作为工作流的运行环境。主要由工作流实例运行、工作流日志服务、工作流持久化服务、工作流跟踪服务等多个功能组成。工作流引擎服务同时承载工作流实例、活动和工作流运行时环境。

　　（3）工作流引擎管理服务

　　管理工作流引擎服务包括更新、备份、启动、停止等功能操作，该服务是Windows服务，常驻内存。系统管理员可以通过"控制面板"中的"服务"子项，找到并控制该服务。工作流监控系统调用工作流引擎管理服务的接口方法，以友好的UI界面对工作流引擎服务进行管理，如更新、备份引擎等操作。

　　（4）工作流管理系统

　　管理与维护用于创建一个工作流所必要的信息组织，如工作流组织、工作流节点组织、项目组织、工作流前置组织、工作流模板等信息。实现对业务流程系统、应用集成系统、应用适配器系统的动态配置。

　　（5）工作流监控系统

　　流程监控系统通过提供图形化的方式对工作流服务平台的流程实例运行过程进行监控，包括流程实例状态、日志、异常监测并提供性能。主要功能包括以下几个方面：

　　工作流以及工作流实例的维护、跟踪、控制、工作流版本更新等功能；提供日志管理与维护。工作流（Workflow），就是"业务过程的部分或整体在计算机应用环境下的自动化",它主要解决的是"使在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者促使此目标的实现".工作流概念起源于生产组织和办公自动化领域，是针对日常工作中具有固定程序活动而提出的一个概念，目的是通过将工作分解成定义良好的任务或角色，按照一定的规则和过程来执行这些任务并对其进行监控，达到提高工作效率、更好的控制过程、增强对客户的服务、有效管理业务流程等目的。尽管工作流从产生到现在已经取得了相当的成就，但对工作流的定义还没有能够统一和明确，不同学者从不同角度对工作流做出了不同的定义。

　　模拟流程运行生成性能，获知流程运行的时间、效率及某个环节需要的时间周期等。

　　异常信息，可通过对异常信息来更正和处理流程操作。

　　（6）工作流通信接口

　　工作流通信接口用于工作流平台的对外管理接口，以WCF服务方式暴露给外界调用，输入相关的参数即可与工作流平台进行通信，如创建工作流实例、发送、接收和工作流引擎服务交互数据等。

　　（7）前置系统

　　部署在机构应用前端，实现在不同的应用集成系统之间进行路由，使不同的应用集成系统之间实现互联互通。打破孤立状态，实现集中式管理。系统利用应用接口适配器组件提供的开发框架，以适应不同应用系统的连接。通过配置的方式实现与应用系统的连接，提高部署效率，降低实施成本。

　　3 应用

　　在区域电子政务可变业务协同中，以"企业养老金发放"为例，进行了应用试验，效果良好。

　　3.1 养老保险金发放存在的问题

　　当前的养老保险金发放存在着重复享受养老保险待遇及起死回生冒领养老保险金的普遍问题。为解决此问题，必须借助电子政务技术手段，建立一个全省性的社会保障基金管理网络，与民政部门、公安部门进行联网沟通，实现企业和事业单位养老保险人员养老保险金发放的业务协同服务。通过跨部门、跨区域的联合监管、协同办理，及时了解信息，才能有效地堵塞企业和机关人员虚报、冒领养老保险金的现象。

　　3.2 解决方案

　　（1）业务协同部门

　　参与"企业养老保险人员养老金发放"业务协同任务的主要部门及其目前运行的业务软件和数据库。

　　"企业养老保险人员养老金发放"协同业务事项需要以上各个部门的业务系统及业务数据库按照一定的流程进行协同配合，以完成人员信息数据的抽取、传输、比对和核查等操作。

　　（2）业务协同应用模型

　　根据"企业养老保险人员养老金发放"的业务协同需求，在工作流服务平台定制"企业养老保险人员养老金发放"业务协同流程。通过在各部门系统前端部署的前置系统实现工作流服务平台流程控制，实现各部门业务数据交换和业务功能协同，以达到联合监管的目的。

　　（3）业务协同流程描述

　　监管堵塞企业和机关人员虚报、冒领养老保险金流程如图4所示。社保局每月发放企业基本养老保险时，通过工作流服务平台向公安厅全省人口信息系统提交核对人口死亡情况申请，公安厅全省人口信息系统自动响应劳动和社会保障部门请求，返回人口死亡核对情况。

　　社保局向财政工资发放系统核对请求提供政府直接退休金人员名单，财政工资统发系统自动响应该请求。社保局根据工作流服务平台返回的信息，审核本月应发放的企业养老保险，并发放养老保险。

　　省财政部门编制预算时通过工作流服务平台要求省社保局提供各单位缴交企事业基本养老保险的人员名单及相关金额、企事业基本养老保险发放金额以便合理安排下一年度预算。

　　（4）业务协同流程设计

　　根据"企业养老保险人员养老金发放"的业务协同需求，在本工作流服务平台可视化环境中定制"企业养老保险人员养老金发放"业务协同流程。通过在各部门系统前端部署的前置系统实现工作流服务平台流程控制，实现各部门业务数据交换和业务功能协同，以达到联合监管的目的。利用工作流服务平台提供的工作流流程设计器工具，在可视化的编辑环境中，设计跨部门业务协同整合工作流。

　　（5）业务协同流程服务的实施

　　通过工作流服务平台提供的业务协同流程服务在异构的应用系统之间形成松耦合，实现信息交换、路由、分发、转换等功能。业务协同主要以消息和异步通讯技术为手段、面向服务体系为框架、XML为信息描述语言，XML（Extensible Markup Language）即可扩展标记语言，它与HTML一样，都是SGML（Standard Generalized Markup Language,标准通用标记语言）。Xml是Internet环境中跨平台的，依赖于内容的技术，是当前处理结构化文档信息的有力工具。扩展标记语言XML是一种简单的数据存储语言，使用一系列简单的标记描述数据，而这些标记可以用方便的方式建立，虽然XML占用的空间比二进制数据要占用更多的空间，但XML极其简单易于掌握和使用。实现各应用系统间的集成。

　　社保局的工作人员在每月养老金发放时间，登录社保局内部的"企业基本养老保险系统",开启"养老金发放"功能，就会通过部署在省社保局前端的前置系统，将请求发往工作流服务平台，启动"企业养老保险人员养老金发放业务工作流",实现社保局、公安厅、财政厅联合审查的"企业养老保险人员养老金发放"业务协同工作。

　　本文依据WFMC提出的工作流模型，基于WCF与WWF两大前沿技术，Windows Communication Foundation （WCF） 是由微软发展的一组数据通信的应用程序开发接口，它是。NET框架的一部分，由 .NET Framework 3.0 开始引入，与 Windows Presentation Foundation 及 Windows Workflow Foundation 并行为新一代 Windows 操作系统以及 WinFX 的三个重大应用程序开发类库。在 .NET Framework 2.0 以及前版本中，微软发展了 Web Service （SOAP with HTTP communication），.NET Remoting （TCP/HTTP/Pipeline communication） 以及基础的 Winsock 等通信支持，由于各个通信方法的设计方法不同，而且彼此之间也有相互的重叠性（例如 .NET Remoting 可以开发 SOAP, HTTP 通信），对于开发人员来说，不同的选择会有不同的程序设计模型，而且必须要重新学习，让开发人员在使用中有许多不便。设计与实现了可变业务协同工作流服务平台，并在区域电子政务资源共享应用示范中应用，有效突破了"应用孤岛".实践证明，本工作流服务平台具有安全、高效、低成本、易部署等特点，为可变业务协同工作流服务平台提供了可行的解决方案。

「上述就是小编为大家整理的工作流平台系统相关内容」

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。