『壹』 SpringBoot啟動activiti的流程,測試的時候如何發送這個url的post請求
『貳』 方正飛鴻BPM CS有哪些產品組件
方正飛鴻快速開發平台BPM CS是國內做開發平台最好的廠商，它有以下組件：
(1)FormDesigner
自主研發的UI設計器，完全兼容EXTJS、JQuery，支持數據域綁定與界面展現的圖形化設計，支持HTML與JS組件圖形化設計。
(2)WorkflowDesigner
自主研發的圖形化流程設計器，支持所見即所得流程設計，全面支持BPMN2.0標准模型定義，支持泳道圖流程設計。
(3)ModelDesigner
自主研發的數據建模工具，支持庫操作，支持反庫映射，支持庫對象實現類代碼生成。
(1)BizDesigner
自主研發的業務建模工具，對數據模型抽象化，描述業務關系，實現邏輯層，支持業務流程圖形化設計，結合MVC框架，符合SOA構件標准。
(4)MVC
自主研發的業務實現框架，支持SOA標准，支持XML路由，內部與建模工具完全無縫對接，前端、中間層、後端多個MVC小框架整合成一個大的MVC架構體系。
(5)DAO
自主研發的數據持久層，支持XML配置實現，支持多數據源操作，具備高事務並發性能。
(6)Workflow
自主研發的工作流引擎，全面支持BPMN2.0標准模型定義，具備靈活的流轉策略，高效性能。
(7)Authority
統一的許可權認證體系，內部以行、列、URL為實現原則進行許可權分配，對外提供豐富介面以便異構系統進行許可權認證調用。
(8)3Platform
集業務流程平台、靈動業務平台、技術開發平台為一體的高端平台產品。
具體情況你可以訪問方正飛鴻官網了解詳情，提供免費試用的機會，也可撥打電話400電話進行咨詢。
『叄』 請問低 代 碼是什麼 請指教
低代碼開發平台最近好像挺熱啊，聽說微軟、Google都入局了，國內資本如今也在熱捧。網路指數了解了一下，關聯度最高的那幾個國內產品，不少是存在了好多年，更有甚者xx表差不多是上一個世紀的老產品了，也來蹭一下熱度。
那麼，低代碼到底是什麼玩意？是新鮮事物么？為啥上個世紀的老產品也湊一份熱鬧？我們一起去看看。
低代碼平台，洋文稱Low Code Development Platform，注意了，這個Low可不是你想的那個Low，不是低級的意思，而是少量、簡易的DSL代碼甚至是無代碼的意思。
為什麼能夠是更少量甚至是無代碼呢？開發者們想想自己是怎麼減少重復代碼的就會明白了。 我拿自定義表單的場景作為例子，從演化的路徑上來看，是這樣的：
一開始，在一個應用里實現了一個自定義表單的功能，做新應用的時候，也需要這個功能，我們會把原來的代碼復制一份，然後簡單改一些樣式或變數，搞定。
然後，越來越多的應用需要自定義表單的功能了，我們把那砣代碼抽象成一個函數庫，每次需要的時候只需要引用函數庫，給不同的參數就好了，省了代碼復制不說，一下子就提升了代碼的可維護性，這時，代碼就開始變少了。
再後來，我們嫌引用函數庫還麻煩了，我們把這個功能做成了一個獨立應用或微服務，提供一系列常見的表單模板，使用的時候，在這個應用裡面選一個模板，稍配置一下，然後復制一個鏈接到目標應用上粘貼一下就能用了。這個時候，自定義表單變成了一個Saas服務，目標應用中要實現自定義表單的功能已經不需要編寫代碼了。至此，這個自定義表單服務就是一個低代碼應用了。
上面舉的自定義表單例子，你可能有意無意間接觸過了，例如金數據，就是對表單收集這個場景進行了極致的抽象，形成一套固定的表單設計套路，並且讓表單的開發可以通過可視化配置來完成。順帶說一句，金數據的創始人現在就在二次創業，做的正是低代碼開發平台。所以，你懂的了。
早年的DreamWave、FrontPage，現在的RapidWeaver等可視化網頁製作軟體、大量的在線可視化網站拖拉拽建站應用，就是網頁製作場景的低代碼平發平台。
BAAS，Backend As A Service，後端服務平台，直接讓開發者省掉了後端的開發工作，也是一種典型的低代碼開發平台，例如微信小程序的雲開發平台、知曉雲、Lean Cloud等。
眾多的移動應用、小程序可視化製作平台，提供大量的場景模板，簡單調整一下參數就可以得到一個自己的應用。
應用的場景覆蓋得更廣了，之前的低代碼應用，只能夠滿足相對窄的應用場景，如建站、表單、BAAS，但到了後面，抽象層次往下降一層，允許定義數據結構、定義界面和流程，能夠解決更多通用的場景了，就自然而然有了平台的感覺。
涉及開發的環節更完整了，以前的建站，純粹是前端頁面的拼湊，而BAAS，也只是解決後端的問題，而到了後來的小程序可視化製作時，就把前後端的開發都囊括進去了，幾乎就不需要代碼開發了，又自然而然有開發平台的即視感了。
所以，低代碼的本質就是應用場景的極致抽象並且模板化的過程。實際上，我們以前看到的低代碼產品多了去了，只是那個時候還沒有低代碼這個概念罷了。下面我給你說說：
以上這些應用場景的本質都是低代碼或零代碼，但為什麼低代碼平台的概念在這幾年才興起？我猜想，是應用的場景覆蓋得更廣、涉及開發的環節更完整導致了平台化的出現。
再看看微軟和Google的低代碼平台，都是解決相對通用場景、涵蓋前後端開發環節的形態，就更加印證了我的猜想。
不對呀，上面說到了通用場景，但同時也說了低代碼的本質是場景的抽象並且模板化，通用和模板化不矛盾嗎？這里就要說低代碼平台的限制了，所謂的通用場景也只能是相對通用，可模板化的，於是就有了模板化的通用場景，即這個通用場景是受限的，不是完全的通用。所以，現在大多數的低代碼平台都是面向企業，做企業應用的。因為企業應用，是一個可以模板化的垂直通用場景，例如釘釘宜搭、簡道雲、織信Informat等等，都是服務企業用戶。
最後，低代碼並非零代碼，盡管市面上有不少零代碼的應用平台打著低代碼的旗號吸引關注。代低碼平台的底層邏輯還是一個開發平台，需要對個性化的需求開放實現途徑，如何開放？開放介面？二次開發？還是開放DSL？不一而足。如果一個平台沒有支持個性化需求的開發能力，那它不算是一個及格的低代碼開發平台，充其量只是低代碼應用罷了。
好了，現在你已經知道什麼是低代碼了，往後，我會帶大家一起實現一些低代碼開發的場景，並對低代碼的商業化進行深度的思考，例如誰會為低代碼平台買單、低代碼平台到底是專業平台還是小白應用等等。 合理並且有效地運用低代碼，不僅可以讓我們工作高效地運行，還能最大程度保證團隊目標的達成。我推薦織信，它內置了100+的應用模板，覆蓋OA、ERP、CRM、績效、人事、企業服務、個人及組織等多個應用場景。
『肆』 activiti可以在前端頁面修改流程圖嗎
Activiti默認用的事H2資料庫，要想讓activiti使用獨立運行的H2或者其他資料庫，可以修改activiti explorer web應用的WEB-INF/CLASSES目錄下的db.properties
『伍』 activiti怎麼調用介面啟動子流程
1. Activiti REST模塊介紹
關於Rest的介紹就免除了，主要介紹一下Activiti Rest模塊的功能以及如何使用。
1.1 使用REST的好處
簡單化 ：利用現有模塊（activiti-rest.war）代替直接API調用
標准化 ：各個系統根據rest模塊的介面規范訪問REST資源，統一處理；對於工作流平台來說此特性尤為突出
擴展性 ：如果官方提供的REST介面還不能滿足可以繼續在其基礎上進行擴展以滿足業務系統（平台）的需求
1.2 不適合使用REST的場景
業務數據與流程數據分離: 就像kft-activiti-demo中 普通表單 的演示一樣，業務數據保存在一張單獨設計的表中，而不是把表單數據保存在引擎的變數表中，所以對於這樣的場景中需要聯合事務管理的就不能使用REST了，例如：啟動流程、任務完成、業務與流程數據聯合查詢。
1.3 部署Rest模塊
從 5.11 版本開始不再使用ant腳本的方式啟動demo，並且把activiti-explorer和activiti-rest分離並分別提供一個war包，在 wars 目錄可以找到它。
把activiti-rest.war解壓到Web伺服器的應用部署目錄（例如tomcat的webapps），根據實際需求修改activiti-rest/WEB-INF/classes/db.properties裡面的資料庫配置後啟動應用。
可以通過REST工具測試是否部署成功可以正常的提供服務，例如Chrome的插件REST Console ，或者通過Spring MVC提供的RestTemplate。
2. 訪問REST資源
對於REST模塊提供的介面可以參考用戶手冊的 REST API 章節，有著詳細的介紹（包括URL和參數含義）。
2.1 身份認證
REST介面的大部分功能都需要驗證，默認使用 Basic Access Authentication(基本連接認證) ，所以在訪問資源時要在header中添加驗證信息，當然為了安全期間把用戶名和密碼進行base 64位加密。
可以在用戶登陸之後把用戶名和密碼進行加密並設置到session中，這樣在前端就可以直接通過Ajax方式獲取資源了：
import jodd.util.Base64;
String base64Code = "Basic " + Base64.encodeToString(user.getId() + ":" + user.getPassword());
session.setAttribute("BASE_64_CODE", base64Code);
2.2 通過Ajax方式讀取資源
下面通過kft-activiti-demo中的代碼片段介紹：
$.ajax({
type: "get",
url: REST_URL + 'process-definition/' + processDefinitionId + '/form',
beforeSend: function(xhr) {
xhr.setRequestHeader('Authorization', BASE_64_CODE);
},
dataType: 'html',
success: function(form) {
// 獲取的form是字元行，html格式直接顯示在對話框內就可以了，然後用form包裹起來
$(dialog).html(form).wrap("
"); var $form = $('.formkey-form'); // 設置表單action $form.attr('action', ctx + '/form/formkey/start-process/' + processDefinitionId); } });
在第5行處設置了ajax請求的header信息，這樣REST模塊就可以通過header的信息進行身份認證，通過之後就可以執行資源請求並返回處理結果。
2.3 通過Java方式讀取資源
3. Ajax跨域問題解決辦法
把REST模塊和應用部署在同一個Web伺服器中（廢話……）
等待官方提供JSONP的支持，JIRA Issue： ACT-1534
利用後台代理方式，把請求的URL發送給後台代理伺服器，獲取數據之後再把結果返回給前台
4. kft-activiti-demo的REST演示
我在github上創建了一個REST分支： https://github.com/henryyan/kft-activiti-demo/tree/rest
在 外置表單 模塊中把 讀取表單 和 簽收任務 通過調用activiti-rest模塊實現，思想和設計方式和本文介紹的一致。
目前還未支持跨域的問題，所以運行demo的時候要把kft-activiti-demo和activiti-rest模塊部署在一個tomcat裡面，如果tomcat的埠不是8080則需要修改application.properties 文件的：
activiti.rest.service.url=http://localhost:8080/activiti-rest/service/
『陸』 如何使用Activiti Rest模塊
1. Activiti REST模塊介紹
關於Rest的介紹就免除了，主要介紹一下Activiti Rest模塊的功能以及如何使用。
1.1 使用REST的好處
簡單化：利用現有模塊（activiti-rest.war）代替直接API調用
標准化：各個系統根據rest模塊的介面規范訪問REST資源，統一處理；對於工作流平台來說此特性尤為突出
擴展性：如果官方提供的REST介面還不能滿足可以繼續在其基礎上進行擴展以滿足業務系統（平台）的需求
1.2 不適合使用REST的場景
業務數據與流程數據分離:就像kft-activiti-demo中普通表單的演示一樣，業務數據保存在一張單獨設計的表中，而不是把表單數據保存在引擎的變數表中，所以對於這樣的場景中需要聯合事務管理的就不能使用REST了，例如：啟動流程、任務完成、業務與流程數據聯合查詢。
1.3 部署Rest模塊
從5.11版本開始不再使用ant腳本的方式啟動demo，並且把activiti-explorer和activiti-rest分離並分別提供一個war包，在wars目錄可以找到它。
把activiti-rest.war解壓到Web伺服器的應用部署目錄（例如tomcat的webapps），根據實際需求修改activiti-rest/WEB-INF/classes/db.properties裡面的資料庫配置後啟動應用。
可以通過REST工具測試是否部署成功可以正常的提供服務，例如Chrome的插件REST
Console，或者通過Spring MVC提供的RestTemplate。