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

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

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

image

我们使用Go来开发ChainCode,那么可以采用https://github.com/looplab/fsm 这个FSM库。这个库也是Fabric官方采用的状态机库。下面是我的操作过程:

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

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

image

2.定义FSM初始化函数

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

func InitFSM(initStatus string) *fsm.FSM{
   f := fsm.NewFSM(
      initStatus,
      fsm.Events{
         {Name: "Submit", Src: []string{"Draft"}, Dst: "Submited"},
         {Name: "Approve", Src: []string{"Submited"}, Dst: "L1Approved"},
         {Name: "Reject", Src: []string{"Submited"}, Dst: "Reject"},
         {Name: "Approve", Src: []string{"L1Approved"}, Dst: "Complete"},
         {Name: "Reject", Src: []string{"L1Approved"}, Dst: "Reject"},
      },
      fsm.Callbacks{},
   )
   return f;
}

3.在ChainCode中调用FSM Event

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

  • Draft
  • Submit
  • Approve
  • Reject
于是我们可以在Invoke函数中定义4中情况:
func (t *SimpleChaincode) Invoke(stub shim.ChaincodeStubInterface) pb.Response {
   function, args := stub.GetFunctionAndParameters()
   fmt.Println("invoke is running " + function)
   if function == "Draft" { //自定义函数名称
      return t.Draft(stub, args) //定义调用的函数
   } else if function == "Submit" {
      return FsmEvent(stub,args,"Submit")
   }  else if function == "Approve" {
      return FsmEvent(stub,args,"Approve")
   }  else if function == "Reject" {
      return FsmEvent(stub,args,"Reject")
   }
   return shim.Error("Received unknown function invocation")
}
其中Draft函数就是把表单状态初始化为Draft并保存到数据库,并不涉及状态的修改:
func (t *SimpleChaincode) Draft(stub shim.ChaincodeStubInterface, args []string) pb.Response{
   formNumber:=args[0]
   status:="Draft"
   stub.PutState(formNumber,[]byte(status))//初始化Draft状态的表单保存到StateDB
   return shim.Success([]byte(status))
}
而其他操作都涉及状态的修改,由于我们引入了状态机,所以我们只需要初始化状态机,并发送对应的Event即可,而最新的状态是由状态机根据我们的定义而获得的。所以我们虽然有3个操作,去只需要一个函数就能完成,并没有冗余的if else判断,这就是状态机的优势!
func  FsmEvent(stub shim.ChaincodeStubInterface, args []string,event string) pb.Response{
   formNumber:=args[0]
   bstatus,err:=stub.GetState(formNumber)//从StateDB中读取对应表单的状态
   if err!=nil{
      return shim.Error("Query form status fail, form number:"+formNumber)
   }
   status:=string(bstatus)
   fmt.Println("Form["+formNumber+"] status:"+status)
   f:=InitFSM(status)//初始化状态机,并设置当前状态为表单的状态
   err=f.Event(event)//触发状态机的事件
   if err!=nil{
      return shim.Error("Current status is "+status+" does not support envent:"+event)
   }
   status=f.Current()
   fmt.Println("New status:"+status)
   stub.PutState(formNumber,[]byte(status))//更新表单的状态
   return shim.Success([]byte(status));//返回新状态
}

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:

docker exec -it cli bash

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

peer chaincode install -n fsmtest -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/fsmtest 
ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem 
peer chaincode instantiate -o orderer.example.com:7050 --tls true --cafile $ORDERER_CA -C mychannel -n fsmtest -v 1.0 -c '{"Args":[]}'

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

peer chaincode invoke -o orderer.example.com:7050  --tls true --cafile $ORDERER_CA -C mychannel -n fsmtest -c '{"Args":["Draft","EXP1"]}'

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

image

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

peer chaincode invoke -o orderer.example.com:7050  --tls true --cafile $ORDERER_CA -C mychannel -n fsmtest -c '{"Args":["Submit","EXP1"]}'

image

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

peer chaincode invoke -o orderer.example.com:7050  --tls true --cafile $ORDERER_CA -C mychannel -n fsmtest -c '{"Args":["Approve","EXP1"]}'

image

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

image

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

5.总结

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

posted @ 2017-09-08 00:32  深蓝  阅读(4966)  评论(0编辑  收藏

我要啦免费统计