我們在使用flowable 工作流引擎的時候，最常用的肯定是任務節點，因為在oa系統、審批系統、辦公自動化系統中核心的處理就是流程的運轉，在流程運轉的時候，可能我們有這樣的乙個需求，在乙個任務節點的時候，我們需要多個人對這個節點進行審批，比如實際中這樣乙個例子，假如是乙個部門的投票，這個部門有5個人，那麼當5個人都投票的時候大概分為如下幾種：
1.部門所有人都去投票，當所有人都投票完成的時候，這個節點結束，流程運轉到下乙個節點。(所有的人都需要投票)
2.部門所有人都去投票,只要有任意2/3的人同意，這個節點結束，流程運轉到下乙個節點。(部分人投票只要滿足條件就算完成)。
3.部門中有乙個部門經理，只要部門經理投票過了，這個節點結束，流程運轉到下乙個節點（一票否決權）。
4.部門中根據職位不同，不同的人都不同的權重，當滿足條件的時候，這個節點結束，流程運轉到下乙個節點。比如說所有的人員權重加起來是1，a有0.2的權重，其他的四個人分別是0.1的權重，我們可以配置權重達到0.3就可以走向下乙個節點，換言之a的權重是其他人的2倍，那就是a的投票相當於2個人投票。這種需求還是很常見的。
5.部門所有人都去投票，a投票結束到b,b開始投票結束到c,一直如此，序列執行。最終到最後乙個人再統計結果，決定流程的運轉。
上面的五種情況，我們可以提取出來一些資訊，我們的activiti 工作流引擎，必須支援如下功能，才能滿足上面的需求：
1.任務節點可以配置自定義滿足條件。
2.任務節點必須支援序列、並行。
3.任務節點必須支援可以指定候選人或者候選組。
4.任務節點必須支援可以迴圈的次數。
5.任務節點必須支援可以自定義權重。
6.任務節點必須支援加簽、減籤。(就是動態的修改任務節點的處理人)
因為實際上的需求可能比上面的幾種情況更加的複雜，上面的6個滿足條件，工作流支援前4個，後面的2個條件是不支援的，所以我們必須要擴充套件activiti 工作流引擎才能使用5、6等的功能。下面我們將詳細的介紹前四種條件的使用，在掌握基本使用之後，我們在後面的章節中將詳細的介紹，5、6這兩種功能以及可能更加複雜的操作。
為了演示如何使用，我們採用由淺入深的使用，結合流程圖、流程定義xml、以及**和資料庫的變化來闡釋每乙個配置的使用以及含義。
流程的詳細定義如下圖所示：
流程的詳細定義xml如下:
<?xml version="1.0" encoding="utf-8"?>
multiinstance
2
1.flowable:candidateusers="shareniu1,shareniu2,shareniu3,shareniu4" 這個節點可以4個人審核。
2.2 迴圈2次結束。
3.序列並行的配置。
1.1.2.1. 序列的配置
修改中的issequential為true是序列，issequential為false是並行。我們測試序列。下面的**展示啟動流程因為是以乙個節點所以部署啟動後，直接進入多例項任務。
1.1.2.1.1. 流程的部署
@test
public void addbytes()
id="sid-6d482a8a-f796-4e2b-ab2c-abbfd2da428d" sourceref="startevent1"
targetref="a">
xmlns:shareniu="" shareniu:shareniuext=""
shareniu:shareniuextboolen="false">
id="sid-ba8fc337-40dc-493b-805c-f213b7c4a17d" sourceref="a"
targetref="shareniu-b">
id="sid-df962bb4-ea4c-4d86-9a91-214eb2ec1a47" sourceref="shareniu-b"
targetref="sid-4ac81f5b-49f8-4135-b68e-1c182d004080">
1.1.4.1. 配置描述$
nrofcompletedinstances、nrofinstances 變數描述上面已經描述了，我們這裡設定的條件是大於1/4的人完成任務，任務就結束了。下面我們**部署流程，啟動流程後進行測試：
act_ru_task表如下：
我們隨便結束乙個任務，看一下act_ru_task表變化。
@test
public void complete()
id="sid-6d482a8a-f796-4e2b-ab2c-abbfd2da428d" sourceref="startevent1"
targetref="a">
xmlns:shareniu="" shareniu:shareniuext=""
shareniu:shareniuextboolen="false">
id="sid-ba8fc337-40dc-493b-805c-f213b7c4a17d" sourceref="a"
targetref="shareniu-b">
id="sid-df962bb4-ea4c-4d86-9a91-214eb2ec1a47" sourceref="shareniu-b"
targetref="sid-4ac81f5b-49f8-4135-b68e-1c182d004080">
動態配置如下所示：$
引數說明：
activiti:assignee="$"
activiti:elementvariable="assignee" 多例項任務依賴上面的配置$
activiti:collection="assigneelist"
三個引數結合決定了，當前節點的處理人來自assigneelist集合，注意這裡是集合資訊而不是字串，所以程式的執行時候變數的賦值，如下所示：
@test
public void startprocessinstancebykey() ;
vars.put("assigneelist", arrays.aslist(v));
string processdefinitionkey = "multiinstance";
processinstance startprocessinstancebykey = runtimeservice.startprocessinstancebykey(processdefinitionkey,
vars);
sysok了，測試一下，確實程式如預期的所示，大功告成。
引數的使用總結
4.flowable:candidateusers="shareniu1,shareniu2,shareniu3,shareniu4" 這個節點可以4個人審核。
5.2 迴圈2次結束。
6.序列並行的配置。
$ 完成條件的配置。
這裡我們還可以得出乙個結論：
如果使用序列方式操作nrofactiveinstances 變數始終是1，因為並行的時候才會去+1操作。
上面的程式已經解決了常用的問題，關於會簽、加簽、減籤、退籤、權重配置、自定義通過條件配置(條件自定義通過)
flowable 動態多例項
多例項動態測試 啟動流程 param users 使用者組 param processname 流程key return 流程id responsebody public string start process group requestparam value users required fal...
Kafka 單節點多Kafka Broker集群
接前一篇文章，今天搭建一下單節點多kafka broker集群環境。由於是在乙個節點上啟動多個 kafka broker例項，所以我們需要使用不同的埠來實現。cp config server.properties config server 1.properties cp config server...
Kafka單節點多broker配置
1 啟動zookeeper zkserver.sh start 2 配置多個broker 1.在kafka安裝目錄的config目錄下拷貝 server.properties 分別為server 1.properties，server 2.properties，server 3 properties...