工作流管理系统,基于工作流的平台管理系统设

作者:互联网

图片 1

任务推动的与目标拉动的

前者指的是从过程的开始逐步地一个环节一个环节的执行,当某个活动实例被处理完之后,后续的有关活动将被创建并被激活,由此直至整个工作流程的完成。这是目前大多数面向过程的WfMS所使用的执行方式。而在目标拉动的WfMS中,一个业务流程被看成是一个目标。过程实例执行时,该目标将被分解得到多个相互之间按一定约束条件的关联起来的可执行的多个环节,其中各环节还可以当成是子目标而进一步进行分解。在各环节均执行完毕之后,整个过程也就完成了。目标拉动是一种全新的执行方式,下一代的WfMS将具有此种特征。应该说明的是:上述分类只是从不同的角度入手的。一般来说,后面那些特点将给WfMS带来更好的灵活性,同时也将成为那些能够支持跨机构的大规模复杂工作流管理、面向关键任务的WfMS不可缺少的特征。

 

2. 工作流管理系统的标准和产品返回顶部

 

近年来,工作流技术得到长足的发展。1993年成立了工作流管理联盟(Workflow Management Coalition,WFMC)。此后,该组织颁布了一系列工作流产品标准,包括工作流参考模型、工作流术语表、工作流管理系统各部分间接口规格、工作流产品的互操作性标准等。这些举措加速了工作流技术的商品化。

现在,许多公司都基于这些标准推出了自己的工作流产品。工作流产品主要分为两大类:

1.基础的工作流系统

提供引擎、设计器、相关接口等。应用系统的开发商可以基于此类系统开发具有工作流管理功能的应用软件。典型产品如ActionTechnologiesInc.的ActionWorkflow、IBM的FlowMark等。

2.应用了工作流技术

包括内置较完整的工作流功能,但面向应用的应用级软件系统,这种系统是直接面向最终用户的流程化应用。同时,系统中还往往针对应用需要,集成了其他功能。典型产品如神州数码工作流软件EasyFlow,就是以工作流技术为核心的全面的企业办公自动化(OA)产品。

 

3. 工作流管理系统优势返回顶部

 

1、快速、高效、稳定的流程引擎,引擎支持大并发访问。

2、兼具人工和自动流程,具有明显的“中国流程”特色的柔性工作流。

3、灵活的部署方式,支持集中部署、分布式部署。

4、高效的流程集成、整合框架;同时支持嵌入式流程开发。

5、国内数十个行业,拥有近千个成功的客户案例。

 

4. 工作流管理系统的意义返回顶部

 

由于信息技术的发展和日趋激烈的商业竞争,人们不再满足于独立、零散的办公自动化和计算机应用,而是需要综合的、集成化的解决方案。作为一种对常规性事务进行管理、集成的技术,WFMS的出现是必然的。它可以带来以下收益:

1.改进和优化业务流程,提高业务工作效率;

2.实现更好的业务过程控制,提高顾客服务质量;

3.提高业务流程的柔性等。

4.规范行为,落实制度;

5.协同内外,快速响应;

6.监控全面,提升执行。

 

5. 相关连接返回顶部

5.1 百度百科

http://baike.baidu.com/item/工作流管理系统

5.2 

6.返回顶部

 

作者:ylbtech
出处:http://ylbtech.cnblogs.com/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

1) jBPM的运行需要数据库的支持,因此系统设计时要选定所用数据库。只要是Hibernate支持的数据库,jBPM就支持。数据库的初始化可以由jBPM自动完成,也可以通过ant generate.ddl任务生成SQL语句,在jBPM外部自己创建所需的表。

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

面向文档的与面向过程的

前者的侧着点在于将电子形式的文档、图像等在有关的人员之间进行分发,以便能够得到不同人的处理与审阅。现有的文档管理与映像管理系统均属此类。在面向过程的WfMS中,工作流被描述成一序列执行环节。与各环节相应都有待处理的数据对象。各环节的数据对象可以按不同的方式分发到其他环节中去,如可以将数据对象的值作为控制条件、或者依此数据对象组装成其他的数据对象等。高端的WfMS一般都属此类系统。

jBpm是一个灵活可扩展的工作流管理系统。作为 jBpm运行时server输入的业务流程使用简单强大的语言表达并打包在流程档案中。jBpm将工作流应用开发的便利性和杰出的企业应用集成(EAI)能力结合了起来。jBpm包括一个Web应用程序和一个日程安排程序。jBpm是一组J2SE组件,可以作为J2EE应用集群部署。

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

ylbtech-Miscellaneos:工作流管理系统

2) 使用jPdl定义工作流,生成processdinination.xml文件。可以采用GUI工具jPdl,但目前只支持jBPM1.0,而且bug很多。XML的DTD定义文件在jBPM下载包中。

哪一种实现更好?

结构化的与即席的

结构化工作流指的是在实际工作过程中会反复重复、严格按照某个固定的步骤进行的业务过程。定义此种工作流所需要的各种类型的信息可以通过对业务过程进行详细的分析而得到,从而得到完整的过程定义并在以后的应用过程中反复使用。大量的办公程序,如公文处理、审批等都属此类。即席工作流则是针对那些重复性不是很强或没有重复性的工作流程的,关于这类流程执行所需的有关参数(如参加者等)事先无法确定,而必须推迟到过程实例运行时才能确定,同时在执行过程中间还可能会发生一些意外的情况。这种动态多变的特点在提供更高灵活性的同时,也为过程的建模与执行带来更多的复杂性。

JBPM流程实例(PI)Process Instance http://www.linuxidc.com/Linux/2014-06/102858.htm

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

 

3) Ant create.pde生成pde包的工作目录。将processdinination.xml文件和其它需要的文件放在指定的目录下,使用ant build.precess.archives生成pde包。pde包的格式采用jar。

☞ 基础框架代码的设计

基于邮件和基于数据库

前者使用电子邮件来完成过程实例执行过程中消息的传递、数据的分发与事件的通知。低端的系统所使用的经常就是此种方法,它可以充分发挥电子邮件系统在广域环境下的数据分发功能,但整个系统将运行于一种松散耦合的模式下。在基于数据库的WfMS中,所有的数据都保存在某种类型的DBMS中,过程的执行实际上就是对这些数据的查询与处理。高端的大规模系统所使用的一般都是此种方法。

跟JBPM学习设计模式 http://www.linuxidc.com/Linux/2014-06/102861.htm

图片 2返回搜狐,查看更多

目前已有上百种声称具有工作流管理功能的商品化软件或原型系统。为了对这些系统的功能、特点等有一具清晰的认识,可以根据工作流过程本身的特点、系统建模的方式、所使用的底层支撑技术、以及工作流过程的执行方式等的不同而对它们进行相应的分类如下:

4) 更改pde工作目录/src/config/jbpm.properties的相关属性,主要是设定相关的数据库连接信息。注意要将数据库的JDBC驱动放在pde工作目录的lib目录下。

借鉴Activiti的源代码

 工作流管理系统(Workflow Management System, WfMS)是一个软件系统,它完成工作量的定义和管理,并按照在系统中预先定义好的工作流逻辑进行工作流实例的执行。 工作流管理系统不是企业的业务系统,而是为企业的业务系统的运行提供了一个软件的支撑环境。 工作流管理联盟(WfMC,Workflow Management Coalition)给出的关于工作流管理系统的定义是:工作流管理系统是一个软件系统,它完成工作流的定义和管理,并按照在计算机中预先定义好的工作流逻辑推进工作流实例的执行。

工作流程编辑

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

1. 工作流管理系统的分类返回顶部

5) Ant deploy.process.archives将刚才生成的pde部署到数据库。实际上就是向数据库插入一些相关数据。

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

JBPM流程部署校验 http://www.linuxidc.com/Linux/2014-06/102860.htm

二. 提前还款流程

JBPM4.4部署在Tomcat6以上的版本jar包冲突 http://www.linuxidc.com/Linux/2014-04/99476.htm

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

JBPM流程实例(PV)Process Variables http://www.linuxidc.com/Linux/2014-06/102859.htm

☞ 选择合适的工作流引擎

6) 利用jBPM API函数开发相应的工作流程。

公共化工作流模块:

图片 3

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

图片 4

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

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

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

原标题:基于工作流的平台管理系统设计

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

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

下图为基本的架构设计

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

❺ 生成还款结清证明

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

图片 5

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

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

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

这里举几个例子

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

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

持续的重构包括:

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

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

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

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

图片 6

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

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

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

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

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

图片 7

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

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

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

➤ WorkflowService对工作流引擎的封装

数据库设计

❸ 运营部门进行修改操

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

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

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

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

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

图片 8

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

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

演进过程

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

初始的场景和需求包括:

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

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

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

责任编辑:

基础框架代码设计

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

图片 9

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

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

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

本文由金沙国际发布,转载请注明来源

关键词: