① 如何實現bpmn文件更改後自動重新部署
首頁 > Activiti > activiti--部署bpmn/bar文件詳解
activiti--部署bpmn/bar文件詳解
Everything that is related to 'static' data (such as process definitions) are accessed through the RepositoryService. Conceptually, every such static piece of data is content of the 'repository' of the Activiti engine.
當配置好工作流，啟動工作流。我們的第一步就是配置bpmn、bar、bpmn20.xml等文件。
部署bpmn的簡單代碼：
ProcessEngine processEngine = ProcessEngines.getDefaultProcessEngine();
RepositoryService repositoryService = processEngine.getRepositoryService();
repositoryService.createDeployment()
.addClasspathResource("org/activiti/test/AssigneeUserAndGroup.bpmn")
.deploy();
簡單解釋：創建一個部署引擎DeploymentBuilder，然後通過addClasspathResource把文件路徑設置進去（最起碼activiti需要知道部署哪一個文件啊），然後啟動部署方法deploy（）。
addClasspathResource（）方法其實就是把文件讀入到一個輸入流中，然後調用addInputStream（）方法。addInputStream（）主要是創建一個資源類，然後設置名稱，位元組，並且把這個資源給deployment實體
public DeploymentBuilder addInputStream(String resourceName, InputStream inputStream) {
if (inputStream==null) {
throw new ("inputStream for resource '"+resourceName+"' is null");
}
byte[] bytes = IoUtil.readInputStream(inputStream, resourceName);
ResourceEntity resource = new ResourceEntity();
resource.setName(resourceName);
resource.setBytes(bytes);
deployment.addResource(resource);
return this;
}
public DeploymentBuilder addClasspathResource(String resource) {
InputStream inputStream = ReflectUtil.getResourceAsStream(resource);
if (inputStream==null) {
throw new ("resource '"+resource+"' not found");
}
return addInputStream(resource, inputStream);
}
所以也可以直接調用addInputStream(String resourceName, InputStream inputStream)進行文件的部署。
注意：單獨部署一個bpmn文件，png會在底層BpmnDeployer中分解出來，並且保存到資料庫中。
如果一個部署中涉及到多個文件，我們可以打包一起部署，例如方法addZipInputStream(ZipInputStream zipInputStream)，其實addZipInputStream會把這個包下面的所有文件逐一找出來，然後創建資源類，設置到deployment實體中。
public DeploymentBuilder addZipInputStream(ZipInputStream zipInputStream) {
try {
ZipEntry entry = zipInputStream.getNextEntry();
while (entry != null) {
if (!entry.isDirectory()) {
String entryName = entry.getName();
byte[] bytes = IoUtil.readInputStream(zipInputStream, entryName);
ResourceEntity resource = new ResourceEntity();
resource.setName(entryName);
resource.setBytes(bytes);
deployment.addResource(resource);
}
entry = zipInputStream.getNextEntry();
}
} catch (Exception e) {
throw new ActivitiException("problem reading zip input stream", e);
}
return this;
}
下面說說.bar文件怎麼打包：
（1）把文件都拷到同一目錄下面
（2）對diagrams文件夾進行打包
diagrams.zip
(3)修改文件的擴展名diagrams.bar
其實一切很簡單...
② JAVA工作流框架哪個比較好
為了更好地幫助大家找到適合自己的流程引擎， 快速地完成流程引擎技術架構選型， 快速地完成項目交付。下面一起來看看java快速開發框架工作流引擎快速開發平台。 希望您能從中找到適合您自己的流程引擎。
Activiti是由jBPM 的創建Tom Baeyen離JBoss之後建立的項目，構建在開發 jBPM 版本1到4時積累的多年經驗的基礎之上，旨在創建下一代的 BPM 解決方案。文檔豐富，csdn有相應專欄，並且國人貢獻了一本《activiti實戰》詳細地講解了基於activiti的開發內容，網上教程資源豐富。Activiti上手比較快，界面也比較簡潔、直觀，學習周期相對較短。
官方提供webapp war包，部署在Tomcat下可快速操作和了解activiti，esclipse提供支持activiti項目的ide插件，總的來說環境支持良好。
代碼量大，核心代碼改動難度較大，但提供了完整的技術文檔，架構良好，網上開發文檔較多，一定上降低了二次開發的難度。
支持，用戶體驗好，但是流程設計器是英文版，還需要漢化。
支持多種表單：動態表單，外置表單，普通表單，但表單設計未集成，需要自己集成表單設計。
支持絕大部分工作流功能，符合中國國情的審批流程需要在此基礎上進行開發。
JBPM（Java Business Process Management）：JAVA業務流程管理，是一個可擴展、靈活、開源的流程引擎， 它可以運行在獨立的伺服器上或者嵌入任何Java應用中。
1、jBPM3是一個完整的工作流系統實現，面向開發人員，目的在於簡化對組織核心流程進行支撐的軟體創建，不支持標准。
2、jBPM4引入PVM，使其擁有更強大的擴展性，同時增加BPMS特性，這些特性包括了對BPMN的支持、面向業務人員的Web建模器和簡單統計分析功能的加入。
3、jBPM5基於原先的Drools Flow，支持BPMN，通過與Drools的合並支持BAM，通過內容倉庫增加對流程可視化的支持。由於放棄了jBPM4的PVM，引擎的可擴展性受到損害，並且不再支持jPDL。
XJR快速開發平台可視化開發，高效快速，開發成本低。兼容強，支持多種資料庫，基於B/S架構，純瀏覽器應用，只需要拖拽組件，拼接流程，就能實現各層的審批。面向服務介面設計，容易整合企業現有的資源。前後端分離設計，採用shiro許可權驗證，通過簡單配置就可以實現功能許可權和數據許可權。開源級代碼，二次擴展強。
XJR快速開發平台技術選型
使用目前流行的多種web技術，包括springboot， JPA，Druid， Activiti，Lombok，swagger，poi，WebSocket，Jquery，BootStrap， maven，Jenkins 等等，支持多種資料庫Mysql, Oracle, sqlserver等。 分層設計：使用分層設計，分為，service，Controller，view層，層次清楚，低耦合，高內聚。 安全考慮：嚴格遵循了web安全的規范，前後台雙重驗證，參數編碼傳輸，密碼md5加密存儲，shiro許可權驗證，從根本上避免了SQL注入，XSS攻擊，CSRF攻擊等常見的web攻擊手段。
模塊功能
功能模塊：開發向導、代碼 生成器，商業智能、工作流、報表管理、移動端開發、作業計劃、多語言、數據源管理、企業微信、釘釘、消息管理，菜單 管理，用戶管理，機構管理，角色管理，區域管理，字典管理，日誌查詢等基礎模塊。
③ 如何在eclipse中配置bpmn2插件
bpmn modeler 早就不更新不能下載了。。。
你可以去看看下面的帖子。
http://www.myexception.cn/eclipse/1863140.html
④ 業務流程建模標記法的BPMN基本話題
BPMN僅限於支持對業務流程有用的建模概念。這意味著組織所做的非業務目的其他類型建模將排除在BPMN之外。例如，以下方面的建模不屬於BPMN的一部分：
組織結構 職能分解數據模型 此外，雖然BPMN會顯示數據的流（消息）以及活動與數據器物的關聯，但它並非數據流圖（data flow diagram）。 BPMN用很小一套圖形要素做簡單的圖來建模，這將令業務用戶與開發者一樣容易理解其中的過程和流。它的四種基本要素如下：
流對象（Flow Object） 事件（Events），活動（Activities），關口（Getways） 連接對象（Connecting Objects） 順序流（Sequence Flow），消息流（Message Flow），關聯（Association） 泳道（Swimlanes） 池（Pool），道（Lane） 器物（Artifacts/Artefacts） 數據對象（Data Object），組（Group），注釋（Annotation） 這四大類對象令我們有機會做出簡單的業務流程圖（BPD, business process diagram）。同時，BPMN也允許在BPD中創建你自己的流對象、器物類型，使圖更好理解。
事件 Event
活動 Activity
關口 Gateway
連接 Connections 流對象（Flow Objects）是BPMN的主要描述對象，由三種核心要素（事件、活動、關口）組成。
事件（Event） 「事件」（Event）以圓環表示，指發生的事情（區分於「活動」代表所做的事情）。圓環中的圖標代表事件的類型（例如：信封為消息，時鍾為時間）。事件也被分為「捕獲」（Catching，例如捕獲輸入的消息而開始一個流程）或「拋出」（Throwing，例如在流程結束拋出消息）。 開始事件（Start event） 作為流程的觸發器；以細單線標明，並且只能「捕獲」（Catch），所以它顯示為空心（輪廓）的圖標。 結束事件（End event） 表現流程的結果；以粗單線標明，且只能「拋出」（Throw），所以顯示為實心圖標。 中間事件（Intermediate event） 表現發生在開始和結束事件之間的事；以雙線標明，可以是「拋出」或「捕獲」（相應採用實心或空心圖標）。例如，一任務流到一事件，拋出一個消息到另一個池，然後由下一個事件守候，捕獲其回應。 活動（Activity） 「活動」（Activity）用圓角矩形表示，並描述必需做的工作的種類。 任務（Task） 任務代表單一工作單元，它不會或不能被分解為更深層次上的業務流程細節，而不包含操作程序步驟的圖示（此非BPMN的目的）。 子流程（Sub-process） 用於隱藏或顯露深層業務流程細節——收起時，在矩形底部用加號標明子流程；展開時，在矩形內顯示全部的流對象、連接對象及器物。 子流程自含開始及結束事件，來自「父」流程的順序流不可跨過其邊框。 事務（Transaction） 子流程的一種形式，其所包含的全部活動必須作為一個整體對待，即它們必須完全結束以滿足目標，其中任何一個失敗就必須全部償還（撤回）。事務作為擴展的子流程，用雙線環繞。 關口（Gateway） 「關口」（Gateway）用菱形表示，基於所示條件決定路徑的分流與合並。 「流對象」通過「連接對象」（Connecting objects）互相連接。連接對象包括三個類型（順序、消息、關聯）：
順序流（Sequence Flow） 「順序流」用實心線和箭頭表示，顯示活動進行的順序。「順序流」還可以在開始端帶有符號，以小菱形標明其中一些發自活動的「條件流」（conditional flow），同時以對角斜線標明發自活動或決定，帶條件流的「默認流」（default flow）。 消息流（Message Flow） 「消息流」用虛線表示，起始端有一個空心圓圈，終端是一個空心箭頭。它告訴我們哪些消息流跨過組織的邊界（即介於池之間）。消息流不可用於在同一個池中連接活動或事件。 關聯（Association） 「關聯」（Association）用點線表示。它用於建立器物或文本到流對象的聯系，並且可以用空心箭頭標明某種方向性（指向器物表示結果，源自器物表示輸入，同時出現則表示讀和更新）。當器物或文本聯繫到順序或消息流時，關聯無需標明方向（那些流已經顯示了方向）。
泳道 Swimlanes
數據對象 Data objects
組 Groups
注釋 Annotation 泳道（Swimlanes）是從視覺上對活動加以組織或分類的機制。它基於交叉功能流程圖基礎，在BPMN中有兩種類型：
池（Pool） 表示流程中的主要參與者，典型地，用來分開不同的組織。一個池可容納一個或多個道（像真實的泳池一樣）。當池為展開的（顯示出內部細節），繪做大的矩形；若為收起的（隱藏起內部細節），繪做沿著圖的長或寬伸展的空的矩形。 道（Lane） 在池中，用於活動按職能或角色歸類。繪做按池的長或寬展開的矩形。道包含流對象、連接對象和人造物。
器物（Artifacts）使開發者可以帶給模型/圖更多的信息，通過這一方式，使模型/圖更可讀。預定的三種器物如下：
數據對象（Data Objects） 「數據對象」向讀者顯示在活動中需要或產生哪些數據。 組（Group） 組表現為虛線的圓角矩形。組用來將不同的活動分組，但不影響圖中的流。 注釋（Annotation） 注釋為模型/圖的讀者增加可理解性。 點擊小圖查看全尺寸圖
帶正常流的流程
討論循環
電子郵件投票流程
採集投票 在BPMN的三種子模型之內和之間，可以創建各種類型的圖。以下列出的是能夠用BPMN建模的業務流程類型（其中帶星號的可能無法映射到執行語言）：
高層次私有流程的活動（非職能分解）* 細節私有流程（Detailed private business process） 當前或過往的業務流程* 未來或新業務流程 與一個或多個外部實體互動的細節私有業務流程（或「黑盒子」流程） 兩個或更多細節私有業務流程的交互作用 細節私有業務流程到抽象流程的聯系 細節私有業務流程到協作流程的聯系 兩個或更多抽象流程* 抽象流程與協作流程的關系* 單獨的協作流程（例如：ebXML BPSS或RosettaNet）* 兩個或更多細節私有業務流程通過抽象流程的交互作用 兩個或更多細節私有業務流程通過一個協作流程的交互作用 兩個或更多細節私有業務流程通過抽象與寫作流程的交互作用 BPMN的設計目標是允許上述全部類型的圖。然而，需要小心的是，包含了太多的子模型類型，例如三種或更多的私有流程之間都有消息流連接，這樣的圖可能會變得難以理解。因而，我們建議建模者為諸如私有流程、協作流程的BPD建立明確的目標。 BPMN 2.0的工作提案名為「業務流程模型及標記法」。BPMN 2.0為新的業務流程模型和標記法建立單一規范，對標記法、元模型和交換格式做出界定。2.0版的名稱有所修改，但仍會維持「BPMN」這個標志。已提議的特徵有：
結合BPMN和「業務流程定義元模型」（Business Process Definition Meta model, BPDM），形成單純一致的語言 使能在建模工具間交換業務流程模型及其布局，以保持語義完整性 擴充BPMN以允許將模型配置與編排成獨立或集成的模型 支持模型上不同透視法的顯示和交替，令用戶可以聚焦於特定的關注點 串列化BPMN，為模型轉換提供XML方案（schemes），向執行決策支持方向擴展業務模型。 新BPMN的建議方案計劃在2008年內完成。 有兩個不同的小組分別在競爭的規范草案上工作。第一個小組包括例如EDS和MEGA，目標是直接吸收BPDM到BPMN規范。第二個小組包括例如SAP AG，IBM，Oracle，不準備直接包括BPDM，而試圖提供兩個標准間的映射。從2008年7月開始，二者開始討論合並其草案提出單一的規范。
⑤ 如何實現Activiti的分支條件的自定義配置
一、Activiti的流程分支條件的局限
Activiti的流程分支條件目前是採用腳本判斷方式，並且需要在流程定義中進行分支條件的設定，如下圖所示：
<sequenceFlow id="flow2" sourceRef="exclusiveGw" targetRef="theTask1">
<conditionExpression xsi:type="tFormalExpression">${input == 1}</conditionExpression>
</sequenceFlow>
<sequenceFlow id="flow3" sourceRef="exclusiveGw" targetRef="theTask2">
<conditionExpression xsi:type="tFormalExpression">${input == 2}</conditionExpression>
</sequenceFlow>
<sequenceFlow id="flow4" sourceRef="exclusiveGw" targetRef="theTask3">
<conditionExpression xsi:type="tFormalExpression">${input == 3}</conditionExpression>
</sequenceFlow>
從上面的定義可以看到，流程的分支條件存在以下兩個致命的局限性：
1．分支條件需要在流程定義（XML）中設定，這要求流程定義必須由開發人員來設計及編寫
2．分支條件比較簡單，一般為boolean表達式，表達式里的為單變數的判斷處理。
以上兩個局限性限制了流程的分支判斷處理必須由開發人員來設定，而國內的大部分的流程應用都要求是普通的業務人員即可處理，或者是由有一定計算機
基礎的人員來設置處理。這要求我們對流程的條件設置提出了更高的要求，上一節我們通過修改Activiti的流程定義的XML中的分支條件表達式，同時刷
新流程定義的引擎緩存，如下的代碼就是基於這種方式：
JsonNode jsonObject=objectMapper.readTree(configJson);
JsonNode configsNode=jsonObject.get("configs");
BpmSolution bpmSolution=bpmSolutionManager.get(solId);
BpmDef bpmDef=bpmDefManager.getLatestBpmByKey(bpmSolution.getDefKey(), ContextUtil.getCurrentTenantId());
ActProcessDef processDef=actRepService.getProcessDef(bpmDef.getActDefId());
String processDefXml=actRepService.getBpmnXmlByDeployId(bpmDef.getActDepId());
System.out.println("xml:"+processDefXml);
ActNodeDef sourceNode=processDef.getNodesMap().get(nodeId);
ByteArrayInputStream is=new ByteArrayInputStream(processDefXml.getBytes());
Map<String,String> map = new HashMap<String,String>();
map.put("bpm","http://www.omg.org/spec/BPMN/20100524/MODEL");
map.put("xsi","http://www.omg.org/spec/BPMN/20100524/MODEL");
SAXReader saxReader = new SAXReader();
saxReader.getDocumentFactory().setXPathNamespaceURIs(map);
Document doc = saxReader.read(is);
//Document doc=Dom4jUtil.load(is, "UTF-8");
Element rootEl=doc.getRootElement();
if(configsNode!=null){
//取得分支條件列表
JsonNode configs=configsNode.get("conditions");
if(configs!=null){
Iterator<JsonNode> it=configs.elements();
while(it.hasNext()){
ObjectNode config=(ObjectNode)it.next();
String tmpNodeId=config.get("nodeId").textValue();
String tmpCondition=config.get("condition").textValue();
Element seqFlow=(Element)rootEl.selectSingleNode("/bpm:definitions/bpm:process/bpm:sequenceFlow[@sourceRef='"
+sourceNode.getNodeId()+"' and @targetRef='"+tmpNodeId+"']");
if(seqFlow==null) continue;
Element conditionExpress=(Element)seqFlow.selectSingleNode("bpm:conditionExpression");
if(conditionExpress==null){
conditionExpress=seqFlow.addElement("conditionExpression");
conditionExpress.addAttribute("xsi:type", "tFormalExpression");
}else{
conditionExpress.clearContent();
}
conditionExpress.addCDATA(tmpCondition);
}
}
}
//修改流程定義的XML，並且清空該流程定義的緩存
actRepService.doModifyXmlAndClearCache(bpmDef.getActDefId(),bpmDef.getActDepId(), doc.asXML());
【說明】
1．基於這種方式容易出錯，因為流程的分支條件寫迴流程定義的XML是比較容易出問題的，同時不清楚人員填寫什麼條件回XML文件中。
2．對於Jsaas中的一個流程定義可用於多個流程解決方案中使用配置不同的條件不太適合，因為一個流程定義是一樣，但可能會分支的條件設置不一樣。
基於以上的要求，為此我們對Activiti進行擴展，以使得我們可以允許流程引擎在分支判斷處理中，執行我們的條件設置，其原理如下：
當流程引擎跳至分支條件判斷處理時，可以讓它執行我們的腳本設置條件，條件滿足時，則跳至我們的設置的目標節點，從而實現干預流程引擎本身的執行方式，為了不影響Activiti的原的運行機制，我們還是保留其舊的執行判斷方式。
二、Activiti的擴展點
Activiti的流程擴展是比較靈活的，我們通過改寫這個ExclusiveGateway的節點的行為方法即可，其實現方法如下：
package com.redxun.bpm.activiti.ext;
import java.util.Iterator;
import javax.annotation.Resource;
import org.activiti.engine.impl.bpmn.behavior.;
import org.activiti.engine.impl.pvm.PvmTransition;
import org.activiti.engine.impl.pvm.delegate.ActivityExecution;
import org.apache.commons.lang.StringUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.redxun.bpm.core.entity.config.ExclusiveGatewayConfig;
import com.redxun.bpm.core.entity.config.NodeExecuteScript;
import com.redxun.bpm.core.manager.BpmNodeSetManager;
import com.redxun.core.script.GroovyEngine;
import com.sun.star.uno.RuntimeException;
/**
* 對網關的條件判斷，優先使用擴展的配置
* @author keitch
*
*/
@SuppressWarnings("serial")
public class Ext extends {
protected static Logger log = LoggerFactory.getLogger(Ext.class);
//節點的設置管理器
@Resource
BpmNodeSetManager bpmNodeSetManager;
//腳本引擎
@Resource GroovyEngine groovyEngine;
@Override
protected void leave(ActivityExecution execution) {
log.debug("enter Ext=======================");
if (log.isDebugEnabled()) {
log.debug("Leaving activity '{}'", execution.getActivity().getId());
}
String solId=(String)execution.getVariable("solId");
String nodeId=execution.getActivity().getId();
log.debug("solid is {} and nodeId is {}",solId,nodeId);
if(StringUtils.isNotEmpty(solId)&& StringUtils.isNotBlank(nodeId)){
ExclusiveGatewayConfig configs=bpmNodeSetManager.getExclusiveGatewayConfig(solId, nodeId);
for(NodeExecuteScript script:configs.getConditions()){
String destNodeId=script.getNodeId();
String condition=script.getCondition();
log.debug("dest node:{}, condition is {}",destNodeId,condition);
//執行腳本引擎
Object boolVal=groovyEngine.executeScripts(condition, execution.getVariables());
if(boolVal instanceof Boolean){
Boolean returnVal=(Boolean)boolVal;//符合條件
if(returnVal==true){
//找到符合條件的目標節點並且進行跳轉
Iterator<PvmTransition> transitionIterator = execution.getActivity().getOutgoingTransitions().iterator();
while (transitionIterator.hasNext()) {
PvmTransition seqFlow = transitionIterator.next();
if(destNodeId.equals(seqFlow.getDestination().getId())){
execution.take(seqFlow);
return;
}
}
}
}else{
throw new RuntimeException("表達式:\n "+condition+"\n返回值不為布爾值(true or false)");
}
}
}
//執行父類的寫法，以使其還是可以支持舊式的在跳出線上寫條件的做法
super.leave(execution);
}
}
我們通過繼續改寫了這個分支節點的跳出機制，並且通過腳本引擎來執行其條件分支的判斷處理，但流程引擎並不了解我們擴展的類，這時我們需要配置Activiti流程引擎的行為動作工廠類，如下所示：
package com.redxun.bpm.activiti.ext;
import org.activiti.bpmn.model.ExclusiveGateway;
import org.activiti.engine.impl.bpmn.behavior.;
import org.activiti.engine.impl.bpmn.parser.factory.;
/**
* 擴展預設的流程節點默認工廠類，實現對Activiti節點的執行的默認行為的更改
* @author keitch
*
*/
public class ActivityBehaviorFactoryExt extends {
private Ext ;
/**
* 通過Spring容器注入新的分支條件行為執行類
* @param
*/
public void setExt(Ext ) {
this. = ;
}
//重寫父類中的分支條件行為執行類
@Override
public create(ExclusiveGateway exclusiveGateway) {
return ;
}
}
三、Activiti的Spring配置的更改
在Activiti的流程引擎配置中加入新的流程行為動作執行工廠類。配置如下所示，注意activityBehaviorFactory的屬性配置：
<bean id="processEngineConfiguration" class="org.activiti.spring.">
<property name="dataSource" ref="dataSource" />
<property name="transactionManager" ref="transactionManager" />
<property name="databaseSchemaUpdate" value="true" />
<property name="jobExecutorActivate" value="false" />
<property name="enableDatabaseEventLogging" value="false" />
<property name="databaseType" value="${db.type}" />
<property name="idGenerator" ref="actIdGenerator"/>
<property name="eventListeners">
<list>
<ref bean="globalEventListener"/>
</list>
</property>
<property name="activityFontName" value="宋體"/>
<property name="labelFontName" value="宋體"/>
<!-- 用於更改流程節點的執行行為 -->
<property name="activityBehaviorFactory" ref="activityBehaviorFactoryExt"/>
</bean>
<bean id="activityBehaviorFactoryExt" class="com.redxun.bpm.activiti.ext.ActivityBehaviorFactoryExt">
<property name="" ref=""/>
</bean>
<bean id="" class="com.redxun.bpm.activiti.ext.Ext"/>
⑥ activiti串列會簽的時候怎麼設置相應的屬性
BPMN2的標准中並沒有對以上這種情景提供完善的支持，因此要在Activiti中實現會簽審批，我們需要結合Activiti提供的流程任務的多實例特性，進行一些必要的擴展，以支持我們的中國特色的會簽需求。 會簽任務也是一種人工任務，其在activiti的定義中，也是使用UserTask來定義，但在屬性上我們需要對這個定義的類型進行特殊的配置，即為多任務實例類型（並行或串列）任何一種。另外需要定義會簽的參與人員，再定義會簽的完成條件（若不定義，表示其是所有參與人均完成後，流程才往下跳轉）。
⑦ 請問低 代 碼是什麼 請指教
低代碼開發平台最近好像挺熱啊，聽說微軟、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、績效、人事、企業服務、個人及組織等多個應用場景。
⑧ eclipse設計activiti流程圖conditionexpression怎麼設置的
Activiti 有個Eclipse 插件，Activiti Eclipse Designer ，可用於圖形化建模、測試、部署 BPMN 2.0的流程。安裝步驟如下：
1、eclipse打開help-> install new software，單擊add：
2、Name: Activiti BPMN 2.0 designer
3、Location:
進行安裝。
注意：要求eclipse必須是3.6以上版本，建議使用最新的eclipse進行安裝。