编者按：BPM流程引擎现在越来多受到企业客户的青睐，每个企业的流程需求都各有差异，流程引擎有基于开源开发的，也有企业自研的，那么这两者的区别是什么呢？企业该如何选择呢？
关键词：BPM流程引擎、流程整合、源码交付
一、基于开源的流程引擎的难点
市场上比较有名的开源流程引擎有osworkflow、jbpm、activiti、flowable、camunda。其中：Jbpm4、Activiti、Flowable、camunda四个框架同宗同源，祖先都是Jbpm4，开发者只要用过其中一个框架，基本上就会用其它三个。
Activiti的设计初衷是嵌入式引擎应用，减少大量的硬编码工作，而应对BPM引擎中心需求仍有很多不足。因此基于开源的流程引擎存在着以下几方面的难点：
1、扩展或定制开发难以满足中国特色需求
基于开源流程引擎API接口进行扩展开发，但目前市场上主流开源流程引擎，如JBPM、Activiti、Flowable、Camunda，均是老外开发的，底层架构设计较好，但功能上不能满足中国特色的流程应用需求，比如：抄送、会签、加签、传阅、跳转、任意流、退回、取回、撤销、一人多部门等需求，这些需求均需要扩展开发才可以，对于没有BPM研发经验的团队来说，开发周期长，风险较大。
2、流程引擎自带的组织用户模型不能满足中国特色需求
开源流程引擎自带了简单的组织用户表，比如camunda流程引擎自带了用户表（act_id_user）、用户群组表（act_id_group）、用户群组关联表（act_id_membership）这几张表，功能十分简单，基本上满足不了国内企业级应用需求，需要单独涉及组织机构表，然后跟流程引擎进行集成。
3、如何整合流程引擎，达到配置化开发，而不是硬编码
开源流程引擎官方给的DEMO里，都是调研API接口，需要硬编码才能把流程引擎用起来，对于我们产品设计，需要把这块抽象封装起来，通过图形化界面配置完成，比如流程会签、流程跳转这些功能，是常用的功能，好多项目都需要，不可能让每个项目都按照API自己开发实现，推广应用和维护成本很高。要把流程引擎玩好，把它整合到自己的产品里，实现配置化开发，对软件架构师有较高的要求，既要懂开源流程引擎技术，还要有架构设计思维。
上面说了三点基于开源的BPM流程引擎一些局限性，其实并不止上述的三个点，在经历过这些种种的不适合的情况下，也有一些厂商自主研发的流程引擎，表现很不错，特别是在满足中国特色的流程需求方面，比如国产老厂商天翎，下面我们来盘点一下天翎的自研BPM流程引擎的有什么优势？
二、MayApps平台自研BPM流程引擎的优势所在
1、应用功能需求符合国内企业的流程应用需求
MayApps在自研的BPM流程引擎中，也是看到了基于开源的流程引擎在这方面与国内企业的需求不匹配，于是在研发过程中，特意按照国内企业的流程需求，提供审批节点、审批路径、审批人员、审批权限、审批时限、审批动作和审批通知等7大控制内核，特适应中国式流程管理模式和操作习惯。
2、支持多种方式整合形式，灵活性强
关于开源流程引擎整合难的问题，MayApps平台BPM流程引擎利用开放的接口将流程引擎集成到企业已有系统中，以最小的调整成本实现对原有系统流程功能的激活。并且提供了大量软件开发所需的功能控件和业务模板，用户通过可视化托拉拽配置为主的方式即可快速完成管理软件的开发，像生产汽车一样生产软件、像搭积木一样构建系统，提升软件开发交付效率80%以上！
3、基于图标库构建报表引擎，满足动态表单应用开发的需求
MayApps平台的表单设计支持印刷和拖拽模式，提供选项卡、主子表、富文本、部门选择、日期选择、视图选择、二维码扫描、OCR识别和视频等30多种功能控件，同时平台支持控件自定义拓展，用户可结合自身业务需求自由添加及复用。
4、最重要的一点：支持源码交付机制！
软件开发来说，源码的重要程度不用多说，源码交付机制这个点可以说是个大杀器，企业开发自己拥有源码，意味着企业是可以“为所欲为”的，企业对软件的自主权完全掌握在了自己的手上，不用依赖厂商，也不再被厂商绑架。