集成序言：
其它商業版的工作流引擎，我這里就不一一訴說了，用過才知道好壞，要不技術過硬各種資料查查查，要不金錢開道請商務入駐。但是Activiti系列網上的資料確實是最多的，畢竟市場占有率擺在那。
Activiti7相對前面幾個版本，優缺點我就不概述了，這些可以自行百度，首先7的表結構和代碼整理，就是一個大版本，這些都是隱性的。對照到最大的顯性變化，可能就是推出了微流程的實現。但是這些和我們只是單純工具使用者來說，壓根不受影響，最起碼80%的api調用方式還是依照之前版本的方式，總之大的變動不明顯，小的優化一堆堆。這也是作者想用新技術的原因，就貪了那點性能。
產品思路方向：
按照傳統的集成方式無非就是: 通用的后端微服務引擎+通用的業務表單設計器+通用的前端回顯表單內容的組件+專屬的bpmn流程模型設計器+外部用戶權限系統；這幾者的關系很容易理解，就是字面意思。
- 首先你得實現適合自己公司ui界面的模型設計器，在設計器里需要集成bpmn的規范，如果有條件，還能集成外部用戶權限系統到里面，這樣就方便畫流程的時候更方便的編寫各種網關條件和設置默認的節點負責人。
- 接着要實現一套通用的業務表單設計器api，能讓用戶通過前端頁面操作，可以快速的構造出一張業務表單，該表單記錄着該業務的基礎信息，並且需同時記錄該業務表的全部屬性信息，方便后期回顯給前端。
- 然后要實現一套通用的前端回顯表單內容的組件，前端通過后端返回的業務表數據（業務表基礎數據+業務表屬性信息），回顯表單給用戶查看。這一塊市面是有很多類似組件，比如FormMaking。
- 最后就是核心的流程運轉了，這一部分就是外部用戶權限系統+通用的后端微服務引擎合作部分了。配置人員畫好A流程，配置好A業務表單，然后就將A流程與A業務表單進行綁定，用戶通過回顯的A表單填寫A業務數據，最后調取外部用戶權限系統分配下一節點負責人，再點擊同意或者拒絕使流程運轉到下一步。
寫道這里，想必對於集成這玩意已經有想法了把。大的方向就這4點，其中2，3可以不實現前端部分，自己后端寫死就行了，唯一的麻煩就是缺少了動態配置的優點，集成者自己可以權衡選擇。
activiti7的坑：
1，想集成必須看源碼，開發者喪心病狂的在各大Service中強行植入了Security，常規方式是不可能繞過的，除非改源碼。但是對於玩jwt+redis那一套的人，其實Security的存在並不重要。再加上微服務的架構盛行，集成之前肯定是已存在用戶系統了，所以只需要考慮如何對接外部用戶系統就夠了，而這也是集成的核心。
2，既然被強行植入了Security，但是我確實不需要他，那么該怎么排除它並集成外部獨立用戶系統，再加上ACTIVITI內部的用戶組系的干擾?你沒看錯，是完全排除，不是偽排除，網上很多都是偽排除的方式。
3，既然被強行植入了Security，但是我的外部用戶權限系統本來就用的Security，那么該怎么集成？自己去寫中間層轉換把，把自己的Security用戶角色體系寫一個配置類，啟動的時候塞到Activiti7的Security體系中。
4，Activiti7的代碼被優化整理過，部分api和service產生了變動，導致以前的調用方式產生了錯誤。至於正確的調用的方式？比如流程會簽，動態分配，自由跳轉，進度坐標添加說明展示等核心功能。
5，如果你是初學者，哪怕你看視頻學會了基本操作，但是涉及到具體業務后，你會發現通過你學的基本操作再去構造各個API是多么費力的一件事，因為對它的理解並不深刻，所以在構造API的時候往往缺少了通用性，這是初學者不可避免的問題。
集成（請認真看圖片標紅文字，你能想到的功能其實全都有）：
先看一下源碼目錄結構，其中狀態引擎放到最后講，因為他是一套獨立的流程引擎，和activiti沒有任何關系。但是對於簡單流程卻很實用！如果不想集成activiti7的話。
看紅色箭頭的注解就能理解了，本人按照上訴的產品思路已經完成了那些模塊。至於通用的表單回顯和設計器，我也只是實現非常簡陋的，目前只有回顯。這一塊就需要強大的前端功底了，如果沒有這個條件，就前端寫死把，反正后端數據是規整的。
后端架構為: SpringBoot2.3.2.RELEASE+SpringCloudAlibaba(nacos,dubbo)+redis,Jwtt+tkmybatis+mysql8,很常規的一套微服務架構
項目初衷是為了實現一套新架構的用戶權限系統+流程引擎+表單引擎+服務器運維+開發工具的系統，是對自己多年工作經驗的總結，也是對開源社區新技術的求知實踐。
架構選型SpringCloud Alibaba系列組件，目前該腳手架的第一版與第二版都已穩定運行在生產環境中，而第三版仍在繼續深耕優化。架構設計整體清晰，強調低耦合，低引用，用最少的體量去實現業務場景，充分利用已有資源。
基於整體架構:
重寫全部出入參的數據類型序列化與反序列化規范，通過封裝的工具統一格式化形成類似偽報文的restful概念。重寫繼承的方式擴展了validator系列參數校驗與轉換的規則，通過封裝的定制化標簽實現參數的期望值轉換。重寫擴展spring-schedules系列，使其能實現定時任務增刪改查的功能，減少外部定時任務插件的依賴。
基於業務場景:
豐富redis+jwt的安全認證體系，通過封裝請求頭，校驗域名，校驗簽名串，頒發token的方式進行常規的請求校驗，通過token攜帶的角色，數據范圍進行接口鑒權的請求校驗。
豐富了攔截器錯誤與頁面錯誤響應規范，區分不同的開發環境，定制統一格式話的報警提示。
豐富orm數據訪問層體系，通過封裝sqlsession后提供5大泛型API，並與擴展單表Mapper組件，強行約束了數據庫訪問規范，保證sql調用的來源統一，並為后期sql攔截，分析，耗時業務場景留下余地。
豐富了常用接口aop插件，其中包括接口數據加解密，RateLimiter限流，鑒權，檢查ip，檢查重復提交，token放行，簽名串放行，自動數據分頁等。
豐富了與微信的交互功能，其中包括公眾號/小程序掃碼登陸，解析用戶數據，支付，消息推送等功能。
豐富了不同開發場景下的單體與微服務之間的切換功能，並擴展附件上傳功能為本地/遠程/壓縮多種優化方式。
豐富了服務器運維與開發工具相關api，其中包括獲取服務器內存，cpu，jvm等軟件件信息，代碼生成，自動建表等開發工具。平台日志，接口日志，接口頻率監控，系統最近一周用戶情況，與服務健康檢查等功能。
基於開源activiti7，實現了微服務版的流程引擎設計與表單設計。
全部模塊都是通過API網關聚合集成到了前端ui里，ui集成過程中考慮到僅僅用作演示，所以后台api都是經過處理的，縮小了范圍。正式集成的時候，可以改動下查詢條件，擴大查詢范圍。下面看一看前端效果
以上就是activiti7的集成到實現的一系列效果了。是不是很解耦，集成者不需要太懂activiti,只要看得懂我寫的api就行了，也就20多個吧，就能實現這一套東西了，並且還安全可靠不踩坑。
下面再來講一講狀態引擎，狀態引擎適合簡單流程的實現，邏輯也很清晰，這套實現是我基於上一家公司產品，自己取其精華動手實現的。效果還是很不錯的，流程走向也清晰。
介紹完畢！看到最后，有興趣的朋友可以加我QQ群121837392，咨詢源碼事宜。
暫時演示環境：https://yj.whpyinfo.com:8065
或
暫時演示環境：https://projectview.top
微信小程序掃碼后，不要刷新瀏覽器,等待3秒左右web端自動登陸，默認只能查看流程相關菜單。
源碼提供的功能包括二方面：
1，黑盒操作，運行起來后，通過給與指定參數調取對應api，即可讓畫好的流程順利運行下去。比如新開發一個報銷流程，只需要通過源碼提供的畫圖工具畫好流程圖，並導入流程引擎中，之后就是常規的啟動，運行等一些列api的調用，直至流程運行結束，這中間都是不需要改動任何源碼的，因為源碼中的api都是朝着通用性設計的，真正實現零開發對接業務系統。
2，白盒操作，自己根據情況，適當的在api種增刪改查自己的業務邏輯。因為api寫的很具有層次感，所以只要閱讀后，看名字也知道什么意思，改動起來難度不大。
最后提醒一下，我是個人開發者，擁有多年的工作流開發經驗，源碼本身也是作者斷斷續續歷時一年的時間打磨而成，不可能讓你白嫖的拿去的，這不現實。