如何基于開源流程引擎開發OA系統？開源流程引擎哪個好？把它整合到自己的産品裡難不難，有沒有啥風險？這是大家經常遇到的問題。筆者從2006年開始參與流程引擎開發，經曆了三代流程引擎研發，支撐過上千個項目應用，把遇到的一些問題總結出來，給大家參考。
如何基于開源流程引擎開發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的團隊提供參考，盡量少踩坑，也可以與我深度溝通。後續的文章中我們繼續分享經驗，分享踩坑經曆。
專注雲原生、低代碼、流程引擎研發和應用。免費體驗環境：http://www.yunchengxc.com