做工作流產品的實施有很多年了，也加了很多諸如 activiti flowable jbpm 等社區和群聊。
發現很多人在走彎路，深陷泥潭不可自拔。
所以寫了這篇文章，旨在告訴很多走向了activiti flowable整合道路的兄弟們，切勿太過於深入整合。
推薦下個人博文地址 doc.agilebpm.cn（這里有我多年工作流實施的經驗和成果）
流程任務動態設置任務候選人
問題：我現在有個問題，想聽聽各位大佬的意見，我所有的流程節點人都是不固定的，所以流程定義文件中用的都是變量，這些人可能是流程啟動的時候一次性傳入進去，也可能是上一節點才臨時決定下一節點審批人，目前我把這些節點變量（具體的人），全部存在流程變量中（每個流程都可能都有好多人），這樣做好么？有啥其他方案
弊端：
- 流程變量人員的設置都依靠代碼，實施流程太重，性能差。
- 流程實施對開發員對於流程引擎必須有足夠的了解。整體流程實施人員學習成本太高。
- 不利於維護，而且迭代更新的后期成本太高。
正確做法：
將流程人員配置化，當任務創建時，通過解析器解析出配置人員，設置到identityLink中。任務提交，還可以動態為下節點設置候選人。
這樣不需要使用流程變量。而且配置化，策略模式的去解析各種人員配置形式。可以隨時修改。而且不需要編碼實現。
flowable，activiti 流程引擎與表單整合
大多人做法： 使用url表單
弊端
- 分支等需要業務數據的場景會很尷尬，可能又要編碼設置流程變量來解決了。
- 流程驅動url表單去加載數據，但是數據保存又要和流程引擎耦合。
如果url表單的數據處理器沒有實現配置化，那么又要編碼實施（辛苦）
正確的做法
url表單當然可以實現但必須注意一下幾點
- 在與其他系統整合過程中要注意事物問題
- url表單與流程配置化，
- url表單數據的處理器（保存數據的邏輯處理層）需要和流程進行配置化。
url表單前端提供數據，提交任務后，將業務數據交給 數據處理器，
數據處理器返回 業務id，businessKey 然后設置給流程。
除了url表單，還可以構建一個表單引擎服務（並非activiti那種，太弱了）
- 將業務數據抽象成統一的業務對象，
- 使用業務對象構建，自動生成可擴展的表單
- 為流程配置表單，將業務對象作為流程運行時的可用參數。
這樣流程提交后，做業務數據的持久化動作，並且可以在流程中使用到流程表單數據。這樣做還有一個好處，流程表單的開發標准化。可以專注的為表單構建更多的可復用的表單組件。
activiti5與flowable6選擇
參考 https://blog.csdn.net/hj7jay/article/details/68483096
肯定選擇flowable，這個會是流程高效流程引擎的未來，而且越來越注重整合方面的事情了。
activiti流程變量獲取設值
可以通過實現了VariableScope接口的實體操作流程變量。 如：ExecutionEntity，TaskEntity在任務、流程監聽事件中都可以拿到。
建議封裝BpmContext 用線程變量存儲一個類似 org.activiti.engine.impl.context.Context一樣的線程流程變量對象。可以直接靜態方法方式拿到流程的variableScope操作流程變量。
可以在流程啟動接口，任務處理接口直接將流程變量提交給流程引擎
activiti駁回，activiti自由跳轉
現實方式
- 重寫activiti緩存，讓流程定義緩存線程化
- 任務提交前，克隆流程定義，放入線程中，動態修改流程圖，讓當前節點流程直接指向目標節點
- 提交任務
但駁回前要做一些前置的判斷，比如同步中無法駁回等等
修改流程圖可以參考https://www.oschina.net/code/snippet_39770_36561
注意：緩存必須拷貝並線程化，否則存在多線程問題，比如上面那篇文章。就只能作參考駁回那部分代碼。
文章會不定期更新其他人遇到的問題