我們接著上一節來講；
在熟悉動態增加組織或修改配置的步驟後，我們就可以使用java的api來完成動態增加組織或修改配置了；
廢話不多說，直接上乾貨；
1，預製條件
org3的證照以及組織3的MSP詳情資訊，需要提前準備（如果不清楚的，可以回頭看一下上一章）
fabric-java-sdk 1.2 我這裡使用的是1.2版本，更高版本基本相同，沒有什麼大變化
2，啟動configtxlator工具的rest服務
準備configtxlator工具，你可以通過原始碼編譯或在網上自己下載
執行 ./configtxlator start命令，預設埠是7059
3，建立通道連結
4， 獲取通道配置位元組碼
byte[] mychannelConfig = channel.getChannelConfigurationBytes();
這一步對應的是peer channel fetch config命令生成後的pb檔案
5，將位元組碼轉化為json
通過configtxlator 工具提供的decode方法，解碼的訊息型別為 common.Config
6，讀取org3.json內容
7，將組織3的內容和channel當前的配置資訊合併
當前配置資訊的結構體如下圖，我們可以使用JSONObject來代替cli客戶端的jq工具來操作json內容
8，將合併後的json檔案，編碼成位元組碼
將json檔案提交給configtxlator 工具提供的encode方法，解碼的訊息型別為 common.Config
這一段邏輯就相當於是將修改後的json，轉化為pb檔案的邏輯
9，在第4步中，我們獲取過通道的位元組碼，而這裡我們有修改後的位元組碼，只要對這兩個做一次對比；就可以獲取到需要修改的部分內容；
依舊使用configtxlator工具，而這時候需要呼叫的是計算介面：compute,訊息型別為：update-from-configs
10，構建修改配置，向orderer傳送變更交易了；
這裡大家可能有個疑惑，不是要需要其他組織簽名的嗎？是不是少了一步？
當前需要簽名，而這也是使用api的一個好處，他幫我們做了好多事情；先看一下下面的這段程式碼，有幾點注意點：
注意點：
a),通道的updateChannelConfiguration方法，第二個引數是無邊界的陣列；
b)這個引數，就是各個組織的修改提供的簽名人。上面是動態增加組織的，如果是修改配置的話；比如修改區塊大小資訊，那麼這裡主要傳一個orderer的使用者就可以；
c)是不是什麼使用者都可以進行提交修改？當然不是，必須是admin；
d)此方法，是沒由返回值的，所以只能通過異常捕獲，或使用斷言的方法，來判斷你的修改是否成功了；
備註：channel，在提交修改的sendUpdateChannel方法中，動態幫我們組裝了echo '{"payload":{"header":{"channel_header":... 這個段邏輯。這也解釋了上述的那個問題。
11，判斷是否修改成功
主要再獲取一下最新的通道配置，檢查一下你新增的組織是否在這個json物件中即可；
12,其他步驟，就不在追溯了，後面要做的就是，組織jion、安裝/升級合約.這樣組織3才會更新資料。否則會被orderer拒絕訪問同步。在orderer端，你會看到需要Org1MSP/Org2MSP,但獲取到是Org3MSP的異常；
我使用是是couchdb，資料已經同步。ok完成動態新增組織；動態修改配置，其實是一個步驟。就不在追溯了；
備註：
當前這一章中提到了configtxlator工具，但並沒有過多的對其進行詳細說明，後面我們花一章時間對他做一個說明；