前言
如何基於開源流程引擎開發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的團隊提供參考，盡量少踩坑，也可以與我深度溝通。后續的文章中我們繼續分享經驗，分享踩坑經歷。