基于开源流程引擎开发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）这几张表，功能十分简单，基本上满足不了国内企业级应用需求，需要单独涉及组织机构表，然后跟流程引擎进行集成。常见需求有：
- 1、流程支持多组织架构，集团总部、子公司多级组织架构，国内组织架构涉及到有组织、部门、用户、岗位、职务多个要素，这些要素间有复杂逻辑关系。
- 2、流程选人支持一人多部门多岗位，比如张三是公司副总经理，同时也是产品研发部的部门经理；
- 3、流程选人规则动态灵活，支持人员、部门、岗位交叉形式的动态选人，比如流程的某一节点的审批需要流程发起人所在部门的副经理以上职位人审批，这就是一个人员、部门、岗位三个维度的交叉动态选人规则。
- 4、流程审批体现审批人部门和职位，比如：张三是公司副总经理，同时也是产品研发部的部门经理，那么当他参与会签审批一个流程的时候，是以副总经理的身份审批的，还是以部门经理的身份审批的，在业务上是有很多区分的。
五、开源流程引擎的界面基本不能满足国内企业应用需求
目前市场上主流开源流程引擎，如JBPM、Activiti、Flowable、Camunda等的用户界面很难满足中国人应用习惯，其实国内企业对UI功能和体验要求很高的，还有每个企业领导的操作习惯和个人喜好，界面基本上要全部定制开发，而且要研究流程引擎后台接口，这部分工作量十分巨大。笔者曾经参与过一个集团级的BPM项目，采用的是IBM BPM平台，界面基本满足不了客户需求，最后界面全部重新开发，投入了很大的人力物力。
六、如何整合流程引擎，达到配置化开发，而不是硬编码
如何把开源流程引擎整合到自己的产品里，应用起来很简单，最好是图形化配置即可，这个是有一定难度的，开源流程引擎官方给的DEMO里，都是调研API接口，需要硬编码才能把流程引擎用起来，对于我们产品设计，需要把这块抽象封装起来，通过图形化界面配置完成，比如流程会签、流程跳转这些功能，是常用的功能，好多项目都需要，不可能让每个项目都按照API自己开发实现，推广应用和维护成本很高。要把流程引擎玩好，把它整合到自己的产品里，实现配置化开发，对软件架构师有较高的要求，既要懂开源流程引擎技术，还要有架构设计思维。
七、遇到复杂流程应用需求难以应对
互联网业务流程应用相对简单，基本是一个直线流程或者分支流程，但在大型集团型企业里，流程应用十分复杂，甚至是一些变态的需求，但从业务角度讲是合理的，IT很难拒绝业务，遇到这种需求，如何灵活应对？如果对流程引擎底层原理了解不深入，是很难应对的，最好勉强实现，问题也会很多，甚至写死代码，后期很难维护。
总结
基于开源流程引擎研发BPM或者OA系统，问题远远不止这些，笔者仅仅是把常见的、重要的问题列了出来，给开发自主可控的BPM的团队提供参考，尽量少踩坑，也可以与我深度沟通。后续的文章中我们继续分享经验，分享踩坑经历。
