在Fabric ChainCode中导入第三方包（以状态机为例）

在企业级应用开发中，经常会涉及到流程和状态，而有限状态机（FSM）则是对应的一种简单实现，如果复杂化，就上升到Workflow和BPM了。我们在Fabric ChainCode的开发过程中，也很可能涉及到状态机，这里我们就举一个例子，用FSM实现一个二级审批的状态转移。

我们有一个表单，员工填写表单是可以保存为Draft状态，提交后变成Submitted状态，然后在一级审批的时候，可以Approve或者Reject，同意了改为L1Approved，进入下一级审批，拒绝了那么就以Reject状态打回给起草人，二级审批人员也是有Approve和Reject两个操作，同意了状态就改为Complete，拒绝了就改为Reject。这是一个很常见的审批例子。

我们使用Go来开发ChainCode，那么可以采用 这个FSM库。这个库也是Fabric官方采用的状态机库。下面是我的操作过程：

1.新建ChainCode项目并引入fsm库

我们新建一个项目fsmtest，并在其中建立住ChainCode文件：main.go，然后新建vendor文件夹，将从GitHub clone下来，并放在vendor/github.com/looplab/fsm文件夹中，最终项目个文件结构如下：

2.定义FSM初始化函数

接下来打开main.go文件，除了编写ChainCode所必须使用的函数外，最主要的就是编写定义状态机转移的初始化函数了，我们根据前面流程图中的流程状态定义，我们可以写出如下的FSM初始化函数：

3.在ChainCode中调用FSM Event

接下来我们在ChainCode重定义了4个函数，

• Draft
• Submit
• Approve
• Reject

于是我们可以在Invoke函数中定义4中情况：

其中Draft函数就是把表单状态初始化为Draft并保存到数据库，并不涉及状态的修改：

而其他操作都涉及状态的修改，由于我们引入了状态机，所以我们只需要初始化状态机，并发送对应的Event即可，而最新的状态是由状态机根据我们的定义而获得的。所以我们虽然有3个操作，去只需要一个函数就能完成，并没有冗余的if else判断，这就是状态机的优势！

4.部署并测试ChainCode

现在状态写完了，我们需要进行测试，我们可以git push到GitHub，然后到Ubuntu中git clone下来，也可以通过rz命令，把Windows中开发好的ChainCode上传到Ubuntu中，不管什么方法，最终我们整个ChainCode项目放在了~/go/src/github.com/hyperledger/fabric/examples/chaincode/go/fsmtest这个文件夹下。

然后使用e2e_cli下面的network_setup.sh up命令启动整个Fabric网络。启动Fabric网络后，我们需要进入CLI进行部署和合适fsmtest：

然后安装并初始化我们的ChainCode：

现在安装完毕后，我们可以起草一个报销单EXP1：

我们可以看到系统返回的结果：

现在状态是Draft，然后我们试一试提交报销单EXP1：

我们看到状态已经改为Submitted了。接下来我们进一步一级审批通过，二级审批通过，都是执行相同的命令：

这个时候，状态已经是Complete了，如果我们再次调用Approve函数会怎么样？因为我们在状态机中并没有定义这么一个流转事件，所以肯定是报错，无法正常执行的：

大家如果也在做这个实验，也可以去测试Reject函数，会得到想要的结果的。

5.总结

总的来说，在Fabric的ChainCode开发中，引入第三方的库可以方便我们编写更强大的链上代码。而这个FSM虽然简单，但是也可以很好的将状态流转的逻辑进行集中，避免了在状态流转时编写大量的Ugly的代码，让我们在每个函数中更专注于业务逻辑，而不是麻烦的状态转移。最后直接粘贴出我的完整ChainCode ，方便大家直接使用。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!