其他分享
首页 > 其他分享> > 基于开源流程引擎开发BPM或OA有哪些难点

基于开源流程引擎开发BPM或OA有哪些难点

作者:互联网

前言

    如何基于开源流程引擎开发OA系统?开源流程引擎哪个好?把它整合到自己的产品里难不难,有没有啥风险?这是大家经常遇到的问题。笔者从2006年开始参与流程引擎开发,经历了三代流程引擎研发,支撑过上千个项目应用,把遇到的一些问题总结出来,给大家参考。

一、代码量大,研究困难,尤其涉及底层代码修改,无法下手

 
   目前的开源流程引擎越做越复杂,就以flowable6.4.1为例,源代码工程就103个,如果想深度掌握,必须要研究源代码,但这么多的代码如何研究,对于没有BPM研发经验的人来讲难度是比较大的,也许有人说我不用研究源代码,就调用它的API就可以了,你看完文章下面的内容就知道了可不可以。
 
在这里插入图片描述

二、如何扩展或定制开发满足中国特色需求

 
   有些团队在开发BPM的时候,基于开源流程引擎API接口进行扩展开发,但目前市场上主流开源流程引擎,如JBPM、Activiti、Flowable、Camunda,均是老外开发的,底层架构设计较好,但功能上不能满足中国特色的流程应用需求,比如:抄送、会签、加签、传阅、跳转、任意流、退回、取回、撤销、一人多部门等需求,这些需求均需要扩展开发才可以,对于没有BPM研发经验的团队来说,开发周期长,风险较大。

三、流程引擎自带的电子表单均不能满足复杂应用需求

 
   虽然开源流程引擎也带了电子表单模块,基本上比较简单,都是字段平铺的往下罗列,对于满足国内企业级的应用开发差距很大,必须重新开发才可以,这就涉及到电子表单的开发工作量,以及表单跟流程引擎集成的问题,一个功能强大的电子表单开发,其难度和工作量不低于流程引擎的开发,需要有顶层的架构设计思想,功能性、性能和扩展性要综合考虑,涉及到的细节问题很多。国内泛微BPM的电子表单功能较为强大。

四、流程引擎自带的组织用户模型不能满足中国特色需求

 
   开源流程引擎自带了简单的组织用户表,比如camunda流程引擎自带了用户表(act_id_user)、用户群组表(act_id_group)、用户群组关联表(act_id_membership)这几张表,功能十分简单,基本上满足不了国内企业级应用需求,需要单独涉及组织机构表,然后跟流程引擎进行集成。常见需求有:

五、开源流程引擎的界面基本不能满足国内企业应用需求

 
   目前市场上主流开源流程引擎,如JBPM、Activiti、Flowable、Camunda等的用户界面很难满足中国人应用习惯,其实国内企业对UI功能和体验要求很高的,还有每个企业领导的操作习惯和个人喜好,界面基本上要全部定制开发,而且要研究流程引擎后台接口,这部分工作量十分巨大。笔者曾经参与过一个集团级的BPM项目,采用的是IBM BPM平台,界面基本满足不了客户需求,最后界面全部重新开发,投入了很大的人力物力。

六、如何整合流程引擎,达到配置化开发,而不是硬编码

 
   如何把开源流程引擎整合到自己的产品里,应用起来很简单,最好是图形化配置即可,这个是有一定难度的,开源流程引擎官方给的DEMO里,都是调研API接口,需要硬编码才能把流程引擎用起来,对于我们产品设计,需要把这块抽象封装起来,通过图形化界面配置完成,比如流程会签、流程跳转这些功能,是常用的功能,好多项目都需要,不可能让每个项目都按照API自己开发实现,推广应用和维护成本很高。要把流程引擎玩好,把它整合到自己的产品里,实现配置化开发,对软件架构师有较高的要求,既要懂开源流程引擎技术,还要有架构设计思维。

七、遇到复杂流程应用需求难以应对

 
   互联网业务流程应用相对简单,基本是一个直线流程或者分支流程,但在大型集团型企业里,流程应用十分复杂,甚至是一些变态的需求,但从业务角度讲是合理的,IT很难拒绝业务,遇到这种需求,如何灵活应对?如果对流程引擎底层原理了解不深入,是很难应对的,最好勉强实现,问题也会很多,甚至写死代码,后期很难维护。

总结

 
   基于开源流程引擎研发BPM或者OA系统,问题远远不止这些,笔者仅仅是把常见的、重要的问题列了出来,给开发自主可控的BPM的团队提供参考,尽量少踩坑,也可以与我深度沟通。后续的文章中我们继续分享经验,分享踩坑经历。

标签:需求,流程,BPM,OA,开源,引擎,开发
来源: https://www.cnblogs.com/hibpm/p/14912659.html