基于赋时编排图的区块链业务流程管理引擎

孙笑笑，沈沪军，杨思青，俞东进+

(1.杭州电子科技大学 计算机学院，浙江 杭州 310018；2.复杂系统建模与仿真教育部重点实验室，浙江 杭州 310018)

0 引言

随着业务流程的日益复杂化，一些需要跨组织协作的业务流程场景不断涌现，如金融教育管理、医疗健康管理、资产管理、供应链等[1]，对于这些跨组织的业务流程，组织间缺乏信任是其进行业务协同的最大障碍。传统的业务流程管理方法一般采用第三方权威机构，如银行、支付宝等作为中央控制者进行信任委托，但这可能会带来交易安全风险增加、效率低下、不可追溯等问题[2]。近年来，区块链技术受到广泛关注，它是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的一种新型应用模式，具有去中心化、不可篡改、开放自治、可追溯的特性。区块链以太坊平台使用智能合约来实现流程自动化，不需要依赖任何集中的第三方权威机构进行组织间协作[3]。以保险为例，无论飞机延误险、意外险还是疾病险，只要将保单及航班号、意外事故列表单、用户的病历单等上链，在达到智能合约自动触发的条件时(如飞机延误)，保险公司将自动化理赔投保人的申请，既可减少纠纷，也能提高双方的效率。现有研究表明，在业务流程中引入区块链技术，对解决跨组织业务流程的信任问题具有重要意义[1-2,4]。

近年来出现的一批通过智能合约控制复杂业务流程的方法或引擎如Caterpillar[5]，Lorikeet[6]等，普遍存在实例化成本高、灵活性差(如版本迭代困难)等问题，特别是这些方法或引擎都存在一个共同的缺点，即没有在智能合约中适当考虑时间或缺乏时间约束，而时间在跨组织业务流程中至关重要[7]。例如订单业务中，客户厂家间通过遵守订单的截止日期和延迟交付日期来维持合作伙伴间共同的业务目标。实际上，区块链平台目前并没有有效表示时间、管理时间约束的方式。另外，由于智能合约由交易驱动，其在封闭环境中执行，无法访问全局时间信息[7]，若能在智能合约中适当引入时间约束，则可减轻跨组织业务流程中一些活动因违反时间约束而导致过度消耗区块链Gas的问题(例如提前终止或通知订单业务中不满足约定发货时间约束的流程)，从而避免在组织间出现纠纷。

针对上述问题，本文提出一种基于赋时编排图的区块链业务流程引擎，将跨组织业务流程中的时间约束分为编排活动的单次持续时间约束、编排活动的最大持续时间约束和编排活动的间隔时间约束3类，基于3类时间约束扩展现有编排图提出赋时编排图的概念，旨在通过赋时编排图解决跨组织业务流程中因违反时间约束导致的信任缺失问题，达到流程优化的目的。另外，有别于Caterpillar等通用引擎部署时采用实例和智能合约一对一的编译型部署方式，本文引擎采用基于元模型的解释型部署方式，部署后的智能合约可被不同流程实例编排复用，大幅降低了对区块链Gas的消耗。同时，引擎集成了基于投票机制的版本控制策略，可解决现有版本迭代难题，流程管理者通过版本信息可追溯同一版本的实例活动信息。

1 相关工作

目前较早开源的区块链业务流程管理引擎Caterpiller从输入一个BPMN2.0(business process modeling notation)流程模型开始[5]，采用智能合约和实例一对一的编译型方式进行合约部署，可确保所有流程实例均符合流程参考模型，但其未对区块链Gas成本消耗问题进行优化[8]。另外，Caterpillar在实例执行过程中忽略了组织间的消息交互，即将跨组织业务流程视为组织内部业务流程存在一定局限性。TRAN等[6]针对资产管理提出一种流程模型驱动的区块链业务流程执行引擎Lorikeet，支持在资产注册表数据模式中自动生成智能合约，解决了在区块链上进行资产管理的难题，然而Lorikeet不支持限制级别的访问控制，支持的功能也只限于资产管理。

现有的大部分研究，如Caterpillar[5]和Lorikeet[6]等，未涉及业务流程管理中至关重要的时间约束。KLINGER等[9]对时间约束进行了概念级别的讨论；ABID等[10]虽然对Caterpillar的时间约束进行了扩展，包括相对时间约束和绝对时间约束两种，但是仍未解决Caterpillar本身存在的缺乏组织间消息交互、实例化成本高等问题；LADLEIF等[7]提出一套对现有区块链平台进行时间度量的方法，并系统比较了它们的特性；HILDEBRANDT等[11]早期提出一种可用于描述跨组织定时业务流程的全局合同和每个组织本地合同的动态定时图结构，可解决组织间的信任缺失问题，但其仅从概念级别进行讨论而缺乏实践应用；HAARMANN[12]讨论采用模拟技术分析基于区块链的跨组织业务流程的持续时间，但只停留于概念级别。

随着区块链业务流程管理研究的不断发展，框架灵活性逐渐引起学者们的关注。LPEZ-PINTADO等[13]对Caterpillar进行结构调整，提出一种基于动态数据结构的流程模型解释器，允许流程参与者动态修改流程模型，虽然提高了框架的灵活性，但是缺乏版本迭代策略，即对流程模型的版本控制。另外，针对跨组织业务流程的多方组织协作的特殊性，LADLEIF等[14]提出针对编排图的操作语义，并通过以太坊智能合约在3个案例原型上进行了概念验证；CORRADINI等[15]提出一种编排图驱动的区块链业务流程引擎，将输入的BPMN2.0编排图转化为特定的智能合约，并通过智能合约达到控制跨组织业务流程的目的，但其同样采用智能合约和实例一对一的编译型方式，存在缺乏灵活性和Gas消耗大等问题；2020年，LICHTENSTEIN等[16]提出一种区块链上的编排方法，使生成的数据可被不同流程实例编排复用，从而降低区块链Gas成本并保证数据的完整性，但其并未对访问控制、时间约束等进行讨论；MERCENNE等[17]提出在Caterpillar上引入角色访问控制策略，以提高框架灵活性和安全性，但仅停留于概念级别；LPEZ-PINTADO等[18]提出一种用于跨组织协作的角色动态绑定模型和相应的绑定规范，并将其工作集成到Caterpillar引擎中，然而动态绑定模型的引入增加了角色授权的复杂性，也增加了在智能合约中进行访问控制的成本开销。

综上所述，现有的区块链业务流程管理方法或引擎普遍存在缺乏时间约束、实例化成本高、灵活性差(如版本迭代困难)等问题，而且这些方法或引擎多停留在理论或概念阶段，难以支持实际的生产流程。基于上述背景和相关工作，本文致力于解决已有工作限制，在高效管理考虑时间约束的区块链业务流程方面展开相关工作，提出一种基于赋时编排图的业务流程管理引擎，并在真实跨组织业务流程中开展应用。

2 预备知识和相关定义

2.1 编排图

现有的区块链业务流程管理方法或引擎普遍从BPMN模型图着手研究，这些BPMN模型图主要分为BPMN流程图、BPMN协作图和BPMN编排图3类，其中协作图和编排图常被用于描述跨组织业务流程的执行过程[19-20]。具体地，协作图详细描述了如何实现和管理不同组织间及组织内的组件；编排图主要从流程的全局视角出发，其更关注组织间如何交互而忽略组织内不必要的细节。相比协作图而言，编排图对流程的描述更简洁也更能突出组织间的协作，因此本文采用编排图进行基于区块链的跨组织业务流程建模。

定义1编排图。编排图用一个四元组G={Event,Gateway,Activity,Flow}表示。其中：事件Event仅包括编排活动的开始事件、结束事件；网关Gateway用于控制编排流程中序列流的走向，包括排他网关、并行网关、事件网关；编排活动Activity表示消息协作双方进行的活动，包括编排活动名称、发送者、接收者、消息；序列流Flow用于连接编排元素，表示指定执行的顺序。

图1所示为编排图的常用元素，包括事件、网关、编排活动和序列流，其中编排活动根据其携带的消息数量分为单向活动(One-Way)和双向活动(Two-Way)。

2.2 赋时编排图

本文在编排图的基础上定义了若干时间约束的相关概念，并提出赋时编排图的概念。

定义2编排活动的活动时间。T(ID)={TstartTime,TendTime}表示某个编排活动中参与者双方进行消息交互的时间信息，其中TstartTime，TendTime分别为编排活动的消息发送时间和消息确认时间。

例如在提交订单业务中，客户作为消息发送者收到货物以后发起一个收货确认消息，生产商作为消息接收者收到确认消息，本次编排活动即正常结束。

定义3编排活动的单次持续时间约束。Tdura(ID)={Tmin,Tmax}表示编排活动执行一次的持续时间(即TendTime-TstartTime)需满足的时间约束，其中Tmin为该编排活动的单次最小持续时间约束，Tmax为该编排活动的单次最大持续时间约束。编排活动的单次持续时间约束满足

Tmin≤TendTime-TstartTime≤Tmax。

(1)

例如在提交订单业务中，订单仓库出库需要在1 h内完成，仓库出库花费的时间需在管理者规定的时间内，此即为编排活动的单次最大持续时间约束。

定义4编排活动的最大持续时间约束。Tcard(ID)={maxLoop(ID)·Tmax}表示编排活动在多次执行后最终执行成功需满足的时间约束，其中：Tmax为该编排活动的单次最大时间约束，是编排活动的单次持续时间约束Tdura(ID)的一部分；maxloop(ID)为某个编排活动能够执行的最大次数，默认值为1。

例如在提交订单业务中，某编排活动的消息接收者确认消息后由于一些外部原因导致消息丢失，此时对该编排活动设置一个大于1的maxloop(ID)阈值，即可激活对该编排活动的重启，从而避免流程终止。

定义5编排活动的间隔时间约束。Tinter(ID)={AA,AAV}表示某个编排活动和其他编排活动的间隔时间约束集合。其中AA={ActivityID1,…,ActivityIDm}是与当前活动存在间隔时间约束的所有活动的ID集合，AAV={Value1,…,Valuem}是与当前活动存在间隔时间约束的所有活动的时间约束值。

例如在提交订单业务中，客户从订单提交到取货有一定期限要求，该期限即从订单提交到收货这两个编排活动之间的间隔时间约束。通过设置间隔时间约束可解决此类时间需求期限如“客户需在一周内取货”的超时问题。

定义6时间约束的编排活动。TOT={ActivityID,Participants,Tdura,Tcard,Tinter}表示考虑上述3种时间约束的编排活动，其中ActivityID,Participants,Tdura,Tcard,Tinter分别表示编排活动序号、编排活动的参与者、编排活动的单次持续时间约束、编排活动的最大持续时间约束、编排活动的间隔时间约束。

定义7编排图消息。M=(Name,MesType,sender,receiver,TOT,Content)是编排活动中消息的具体内容，Name,MesType,sender,receiver,TOT,Content分别表示消息的名称、类别、发送者地址、接收者地址、所对应的时间约束的编排活动、所带的内容。其中MesType包括发送者发送的消息Request和接收者确认的消息Reply两类。

定义8赋时编排图。TM={E,M,D,T}表示考虑时间约束的编排图，E,M,D,T分别为该赋时编排图的元素(包括事件、网关和编排活动)、消息、决策条件、时间约束条件。其中元素E={EstartEvent,EendEvent,Gparallel,Gexclusive,TOT},EstartEvent为开始事件，EendEvent为结束事件，Gparallel为并行网关，Gexclusive为互斥网关，TOT为时间约束的编排活动。

2.3 基于赋时编排图的流程控制

赋时编排图TM部署后，添加访问控制组织CO和模型版本V得到元模型，元模型即流程实例执行的参考模型。

定义9访问控制组织。CO={U,R,UR}为包含所有业务流程参与者的组织结构，其中U为访问控制组织的参与者，R为访问控制组织的角色，UR为访问控制组织的参与者与角色的映射关系。

定义10模型版本。V=(VID,ListElement,ListMessage,StartEvent,Status)表示元模型的版本信息，是基于版本控制的一个通用元素部件。其中VID，ListElement，ListElement，ListMessage，StartEvent，Status分别为该版本部件中的版本号、元素版本数组、消息版本数组、版本的开始事件、版本的状态(Init表示提出，Pass表示通过)。

定义11元模型。ML={E,M,D,T,CO,VID}是实例进行创建和执行的参考模型，其中E，M，D，T分别为赋时编排图TM中的元素、消息、决策条件、时间约束条件，CO为访问控制组织，VID为模型版本V的版本号。

以太坊上的流程实例通过调用智能合约的接口方法达到基于元模型创建和执行的目的。具体地，本文包括3类智能合约，按部署顺序分别为访问控制合约、投票合约和脚手架合约，其中脚手架合约的代码引用了访问控制合约和投票合约，即将3个智能合约链接在一起。

定义12访问控制合约。ACC={COaddressMap,RList,UList,ACClink}为一个用于对智能合约操作者进行访问授权的智能合约。其中COaddressMap存储访问控制组织CO的引用地址；RList={role1,…,rolem}存储模型ML到合约翻译过程中的所有角色；UList={user1,…,userm}为所有执行实例的区块链用户账号集合；ACClink为访问控制合约部署后的合约引用地址。访问控制组织CO={U,R,UR}是包含所有业务流程参与者的组织结构，U为参与者，R为访问控制组织的角色，UR为访问控制组织的参与者与角色的映射关系。

定义13投票合约。VC={VP,ACClink,VClink}为发布提案并由参与者进行投票的智能合约，其通过ACClink链接了访问控制合约ACC。其中：提案VP={ID,SCaddress,VID,Voterequire,Votenow,State}，包括提案序号、脚手架地址、当前版本号、提案通过需要的人数、提案当前已经通过的人数、提案状态(包括发起状态Init和通过状态Pass);VClink为投票合约部署后的合约引用地址。

定义14脚手架合约。SC={TM,V,I,ACClink,VClink}是一个存储业务流程赋时编排图TM、模型版本V和实例I的智能合约，其通过ACClink和VClink分别链接访问控制合约ACC和投票合约VC。其中业务流程赋时编排图TM={E,M,D,T}，模型版本V={(E1,V1,M1,V1,D1,V1,T1,V1),…,(En,Vn,Mn,Vn,Dn,Vn,Tn,Vn)}，实例I={IE,IM,IG}，IE,IM,IG分别表示实例元素、实例消息内容、实例全局数据。

3 方法描述

3.1 引擎框架

3.1.1 主体引擎

如图2所示为本文提出的基于赋时编排图驱动的业务流程管理引擎，分为链下部分和链上部分。链下的组件主要包括建模器、翻译器和部署器，链上的组件主要包括智能合约、事件监听器和以太坊平台。为保证本文的赋时编排图能够在以太坊上的智能合约中正确执行，本文引擎的执行步骤分别为流程梳理、流程建模、模型翻译、模型部署、模型版本初始化、模型版本投票决议、创建新实例并执行。图中RPC表示远程过程调用(remote process call)。

3.1.2 链下部分

智能合约可以控制业务流程在链上的执行过程，但在控制流程之前需对业务流程进行建模并编写和部署合约代码，这些过程由流程管理者主导在链下完成。链下部分的步骤主要包括流程梳理、流程建模、模型翻译、模型部署。

步骤1流程梳理。流程管理者从跨组织企业的日志文件中梳理跨组织业务流程和时间约束信息，即活动单次持续时间约束Tdura(ID)、活动最大持续时间约束Tcard(ID)、活动间隔时间约束Tinter(ID)，为下一步的流程建模提供参考。

步骤2流程建模。流程管理者分析跨组织业务流程和时间约束信息，在chor-js建模器[21]中编排业务流程赋时编排图TM。chor-js建模器支持BPMN2.0[8]规范的编排图，能够涵盖并支持上文编排图的所有常用元素，但chor-js建模器并不支持时间约束相关的扩展功能，因此流程管理者在建模期间需要根据跨组织业务流程需求录入时间约束信息，并在编排活动的备注栏中录入活动单次持续时间约束Tdura(ID)、活动最大持续时间约束Tcard(ID)或活动间隔时间约束Tinter(ID)，最后导出BPMN格式表示的赋时编排图TM。

步骤3模型翻译。流程管理者将BPMN格式表示的赋时编排图TM，通过本文基于Java语言实现的翻译器解析出JSON格式表示的模型组件，用于下一步模型部署。该步骤的具体实现将在3.2.2节的算法1中阐述。

步骤4模型部署。流程管理者通过Remix平台[22]按顺序编译投票合约VC、访问控制合约ACC和脚手架合约SC，得到3个合约对应的ABI(Application Binary Interface)文件。另外，流程管理者需按序在以太坊[23]平台上部署投票合约VC、访问控制合约ACC和脚手架合约SC，得到3合约地址，然后通过调用Web3.js[23]接口并传入3个合约的ABI文件和合约地址，得到合约实例。 最后，通过合约实例获取元模型的控制流信息和访问控制组织CO，其中元模型的控制流信息包括赋时编排图的元素E、消息M、决策信息D、时间约束信息T。赋时编排图的具体部署过程将在3.2.3节的算法2中阐述。

3.1.3 链上部分

基于区块链的业务流程管理引擎中，多方参与者一般是通过调用智能合约开放的接口来推动流程的执行。上文的链下部分主要进行模型相关的准备，本节主要阐述链上如何用模型驱动。链上部分的步骤包括模型版本初始化、模型版本投票决议、创建新实例并执行。

步骤5模型版本初始化。在验证通过角色访问控制权限后，通过调用脚手架合约SC的接口对模型的版本进行初始化，默认初始化版本号为1；然后基于访问控制组织CO将本地以太坊私链Ganache默认的10个账号绑定元模型的角色权限。

步骤6模型版本投票决议。在模型版本投票决议阶段，版本发起人发布的新版本号相当于投票合约中的一个投票提案VP，新版本号经过所有参与者投票表决通过后得到元模型ML，基于元模型ML可进行实例创建和执行。图3所示为链上版本控制示意图，包括发布新版本、模型和版本绑定、实例版本控制3部分。其中，发布新版本主要包括版本提交、投票决策、版本发布3个过程，模型每部署一次都要求发布一个新版本，得到新版版本号后需将新版本集成到版本部件V；另外，根据已有的赋时编排图TM、访问控制组织CO、发布的新版本号或旧版本号可得元模型ML，元模型ML是实例进行创建和执行的参考模型，其中绑定了版本信息；最后，基于元模型创建新实例并执行实例，实例的执行过程需基于版本号，从而达到版本控制实例的效果。

步骤7创建新实例并执行。模型版本投票表决通过后，新版本号将集成到本文引擎的脚手架合约SC的版本部件V中，创建新实例需携带版本号。在创建实例元素过程中，本文采用延迟元素实例的方法，仅当元素被启用时才在链上创建对应元素，即未被启用的实例元素不在链上添加数据，从而减少冗余数据，降低区块链Gas消耗。另外，由于编排图的业务流程是基于消息驱动的，违背消息交互顺序的请求会被脚手架合约SC拒绝，并通过事件监听器将监听到的事件信息通知给具体的用户，从而保证正确执行流程实例。进一步地，正确执行的消息被接受后会自动触发消息所属元素的状态转化函数，激活下一个元素的执行状态。访问控制合约ACC贯穿于整个流程执行过程，所有涉及权限的操作都会基于ACC中的方法进行权限验证，无对应角色权限的参与者将无法在链上执行编排活动。本文将在3.2.4节具体阐述实例在时间约束下执行编排活动的过程，实例执行过程中的区块链Gas消耗等分析将在第4章实验分析部分详细阐述。

3.2 赋时编排图驱动的业务流程执行过程

本节进一步详细介绍赋时编排图在整个引擎框架中的具体实现过程，主要包括赋时编排图的建模、赋时编排图的解析、赋时编排图的部署、基于赋时编排图的流程控制。

3.2.1 赋时编排图的建模

赋时编排图建模期间，流程管理者重点根据跨组织业务流程需求录入3类时间约束信息，完成编排后导出BPMN格式表示的赋时编排图TM文件F。具体地，本文基于赋时编排图建立一个示例的跨组织业务流程模型，图4所示为该赋时编排图中的一个编排活动，称为“收货确认”，其中添加3类时间约束的过程如下：

(1)添加活动单次持续时间约束Tdura(ID) 如图4所示，流程管理者对“收货确认”编排活动添加Tmin和Tmax两个单次持续时间约束，分别表示该活动的单次最小持续时间约束和单次最大持续时间约束。

(2)添加活动最大持续时间约束Tcard(ID) 因为网络故障、区块链服务故障、流程参与者误操作等会导致“收货确认”不成功，使流程非正常终止，而流程非正常终止往往需要基于元模型重新创建新实例并执行，所以如图4所示，流程管理者对编排活动“收货确认”设定maxLoop(ID(“收货确认”))=3，表示该活动最大可以重发3次，以确保流程按顺序执行下去，避免流程非正常终止。

(3)添加活动间隔时间约束Tinter(ID) 由于部分特定客户有类似“需在一周内取货”的需求，流程管理者需添加从“订单提交”到“收货确认”两个编排活动之间的时间间隔约束。具体如图4所示，流程管理者在当前编排活动中录入所有与其存在间隔时间约束的活动集合和约束值集合。

3.2.2 赋时编排图的解析

引擎执行步骤3的模型翻译阶段，部署器通过支持方法Bpmn.readFile翻译在模型建模期间输出的BPMN文件F，并输出JSON格式表示的元模型ML部件。算法1描述了赋时编排图解析的详细过程。具体地，第4～8行解析了该编排图的序列流，即将当前编排活动及其前驱活动数组和后继活动数组绑定。在解析时间约束时，本文将输入的序列分为活动内时间约束MapObjectIntra和活动间时间约束MapObjectInter两类，其中活动内时间约束MapObjectIntra包括从活动的单次持续时间约束Tdura(ID)和活动的最大持续时间约束Tcard(ID)得到的信息体，而活动间时间约束MapObjectInter指与活动的间隔时间约束Tinter(ID)相关的所有信息体。第17～25行描述如何从MapObjectIntra中解析出活动内时间约束的相关信息并写入元模型ML部件，第26～30行描述如何从MapObjectInter中解析出活动间时间约束的相关信息并写入元模型ML部件。

算法1赋时编排图的解析。

输入：业务过程编排者采用建模器建模期间输出的BPMN格式的赋时编排图文件F。

输出：JSON格式表示的元模型ML的部件(E,M,D,T)。

01:FUNCTION parseChoregraphy(BPMN2.0-ChorType-File F)

03: FOREACH sequenceFlow IN CollectionSequenceFlowDO:

04: //遍历当前元素，绑定前驱和后继元素数组

05: FlowNow←parseNowFlow(squenceFlow)

06: PreElements←equenceFlow.sourceElement

07: NextElements←equenceFlow.targetElement

08: M←addBandingChildElement(FlowNow,PreElements,NextElements)

09: END FOR

10: RETURN M

11: END FUNCTION

12: FUNCTION addBandingChildElement(FlowNow,PreElements,NextElements)

13: //如果当前元素的类型是编排活动

14: IF typeOf(FlowNow).equals("Task") DO:

15: MapObjectIntra←JSONObject.parseObject(FlowNow)

16: MapObjectInter←JSONObject.parseObject(FlowNow)

17: FOREAC Hentry IN MapObjectIntra DO://活动内时间约束

18: IF entry.getKey.equals("maxTime") DO:

19: M.setMaxTime(entry.getValue.parseToInt());

20: ELSE IF entry.getKey.equals("minTime") DO:

21: M.setMinTime(entry.getValue.parseToInt());

22: ELSE IF entry.getKey.equals("maxLoop") DO:

23: M.setMaxLoop(entry.getValue.parseToInt());

24: ELSE:

25: …

26: FOREACH entry in MapObjectInter DO:

27: IF entry.getKey.equals("pre_TaskId_array") DO:

28: M.setPreTaskIdArray(entry.getValue.ToList);

29: ELSE IF entry.getKey.equals("pre_Task_durationArray") DO:

30: M.setPreTaskDurataionArray(entry.getValue.ToList);

31: RETURN ML

32: END FUNCTION

3.2.3 赋时编排图的部署

模型部署阶段主要是将3.2.2节赋时编排图解析得到的元模型ML部件部署到以太坊上，输出包含元模型控制流信息的脚手架合约SC。具体地，第5～7行通过将Remix部署后的合约的ABI文件导入并调用Web3.js提供的接口获取部署在以太坊上的合约实例；第8～13行从JSON表示的元模型ML的部件中取出Solidity语言数据结构表示的角色列表RList、元素列表ElementList、消息列表MessageList、决策列表DecisionList、时间约束列表TOTList；第15～16行调用ACC合约方法给操作者用户user绑定模型的角色；最后第17～18行进行版本V初始化和模型实例版本的绑定。

算法2将解析后的元模型部件和初始化数据部署到以太坊。

输入：JSON格式表示的元模型ML的部件、部署者的账号user、脚手架合约SC、访问控制合约ACC、投票合约VC编译后的文件集合ABI以及对应Remix部署后的地址集合ADD。

输出：合约SC。

01: M=(E,M,D,T);E={EstartEvent,EendEvent,Gparallel,Gexclusive,TOT}

02: ABI=(ABISC,ABIACC,ABIVC);ADD=(SCaddress,ACCaddress,VCaddress)

03: FUNCTION deployAndImportData(M,user,ABI,ADD)

04: //根据合约的ABI文件和合约地址获取区块链上的合约实例

05: accInstance←web3.eth.Contract(ABIACC,ACCaddress)

06: voteInstance=web3.eth.Contract(ABIVC,VCaddress)

07: chorInstance=web3.eth.Contract(ABISC,SCaddress)

08: //将元模型ML的部件数据导入合约SC

09: RList←getRList(M,E)

10: ElementList←getElementList(M)

11: MessageList←getMessageList(M)

12: DecisionList←getDecisionList(M)

13: TOTList←getTOTList(M,E)

14: //调用ACC合约方法给操作者用户user绑定元模型的角色

15: FOREACH role in RList DO:

16: allocateRoleToUser(role,user)

17: //初始化版本V结构和绑定版本

18: SC.V←addVersion(SC)

19: FOREACH tot in TOTList DO:

20: IF tot NOT IN SC.M DO:

21: SC.M←addTime(SC,tot)

23: END IF

24: END FOR

25: …//元素、消息、决策部署同第18～23行

26: RETURN SC

27: END FUNCTION

3.2.4 基于赋时编排图的流程控制

本文引擎中实例可复用元模型的数据。具体地，实例通过模型部署后的智能合约调用合约的接口方法来访问元模型信息，如模型控制流信息、访问控制组织、版本号。在本文流程实例执行过程中，主要执行基于元模型的流程和填充元模型数据流信息。另外，本节重点介绍基于赋时编排图的流程控制，引擎通过消息传递推动业务流程的执行，即一个消息的正确执行需要发送者调用sendMessage方法且确认调用ackMessage方法后才算结束。canSendMessage方法是sendMessage方法体最开始的一部分，用于判断当前是否满足发送消息的条件，如消息发送者和消息接收者是否拥有执行消息的角色权限、序列流顺序是否正确、消息绑定的编排活动是否处于激活状态、网关的决策类别和决策值是否正确等。本文将编排活动的单次持续时间约束判断逻辑放在ackMessage方法中，将编排活动的最大持续时间约束和活动间的间隔时间约束放在下一个活动的sendMessage方法中，以保证时间约束逻辑控制流程实例执行的正确性。

算法3描述编排活动单次持续时间约束的Solidity代码逻辑。具体地，第8～11行判断当前活动执行一次的持续时间是否符合本文活动的单次持续时间约束Tdura，其中now为Solidity获取当前区块的时间，ts.startTime为当前活动的开始时间，因此now-ts.startTime表示实例当前活动的持续时间。ts.minTime和ts.maxTime为参考元模型的最小持续时间约束和最大持续时间约束，emit为Solidity语言支持的事件回调机制，本文用其通知流程参与者违反了时间约束，并传递当前活动的名称、违反的时间约束类型等信息。

算法3编排活动的单次持续时间约束。

01: //确认消息时判断持续时间约束

02: FUNCTION ackMessage(uinti_id, uintm_id, InstanceMessageStatus status){

03: ……//如果满足当前的消息回复状态、角色权限、编排活动的状态

04: Instance storage i=instanceMap[i_id];

05: MessageStruct storage ms=messageMap[m_id];

06: TimeStruct storage ts=timeMap[ms.task].versionMap[i.versionId];

07: //编排活动的单个持续时间约束

08: IF ((now-ts.startTime>ts.maxTime)||(now-ts.startTimets.minTime)){

09: emit notifyToUser(“当前活动名称X”，“不满足活动单次持续时间约束”);

10: RETURN false;

11: }

12: }

算法4描述编排活动最大持续时间约束的Solidity代码逻辑。如定义3所述，编排活动的最大持续时间约束Tcard(ActivityID)={maxLoop(ActivityID)·Tmax}，其中Tmax为算法3中设置的编排活动对应的ts.maxTime，即最大单次持续时间；maxLoop为最大重发次数，该值已在赋时编排图建模期间录入。MainChoreography是本文脚手架SC合约的主体，其代码引用访问控制合约ACC和投票合约VC，即将3个合约链接在一起。canSendMessage会在发送消息之前判断当前活动在规定的最大重发次数下的持续时间是否符合本文活动最大持续时间约束Tcard(ID)。具体地，第13～14行通过当前的编排活动序号获取序列流的上一个编排活动序号；第18～21行是该时间约束的主要逻辑部分，不符合时间约束的消息将以Solidity的事件回调机制emit通知流程参与者。

算法4编排活动的最大持续时间约束。

输入：实例instanceID、消息的messageID。

01: CONTRACT MainChoreography {

02: //访问控制合约

03: AccessControlaccessControl;

04: //投票合约

05: VoteContractvoteContract;

06: …//脚手架合约中包括赋时编排图TM中除时间约束T以外的元素和版本V等

07: //最大持续时间约束

08: FUNCTION canSendMessage(uinti_id, uintm_id, string reveiver, string[] valType) {

09: Instance storage i=instanceMap[i_id];//获取当前的实例

10: MessageStruct storage ms=messageMap[m_id];

11: //获取当前编排活动ID

12: uint storage now_es_id=ms.task;

13: //获取序列流的上一个编排活动ID

14: uint storage pre_es_id=elementMap[ms.task].versionMap[i.versionId].preElement;

15: …//角色权限、序列流顺序、决策类别和值是否满足参考模型的参数等

16: TimeStruct storage pre_ts=timeMap[pre_es_id].versionMap[i.versionId];

17: TimeStruct storage now_ts=timeMap[now_es_id].versionMap[i.versionId];

18: IF (now-pre_ts.endTime>pre_ts.maxLoop * pre_ts.maxTime){

19: emit notifyToUser(“当前活动名称X”，“不满足最大持续时间约束”);

20: RETURN false;

21: }

22: RETURN true;

23: }

24:}

算法5描述编排活动间隔时间约束的Solidity代码逻辑。编排活动的间隔时间约束Tinter(ID)根据当前活动和其他活动之间的间隔时间是否满足参考元模型设定的值来调整活动的执行状况。具体地，第9～13行为编排活动间隔时间约束的主要逻辑部分，其中ts.pre_taskId_array，ts.pre_taskId_durationArray分别为与当前活动有间隔时间约束的活动序号的集合列表、与当前活动有间隔时间约束值的集合列表。算法5遍历ts.pre_taskId_array列表，逐一判断当前活动和列表中活动的间隔时间是否满足ts.pre_taskId_durationArray列表中对应的值，若不满足，则以Solidity的事件回调机制emit通知给流程参与者。

算法5编排活动的间隔时间约束。

01: //下一个活动发送消息之前判断间隔时间约束

02: FUNCTION sendMessage(uinti_id, uintm_id, address _receiver, string[]_valName, string[]_valValue){

03: …//如果满足消息回复状态、角色权限和编排活动状态

04: Instance storage i=instanceMap[i_id];

05: MessageStruct storage ms=messageMap[m_id];

06: TimeStruct storage ts=timeMap[ms.task].versionMap[i.versionId];

07: …//最大持续时间约束部分

08: //间隔时间约束

09: FOR (var i=0;i

10: IF (now-timeMap[ts.pre_taskId_array[i]].versionMap[i.versionId]>ts.pre_taskId_durationArray[i]) {

11: {

12: EMIT notifyToUser(“当前活动名称X”，”不满足间隔时间约束”);

13: RETURN false;

14: }

15: …//其他非时间约束

4 实验分析

为验证本文所提基于赋时编排图的区块链业务流程管理引擎的效果，本章以一家助听器企业的商品订购流程为例，建立相应的业务流程模型，并采用本文方法将其部署在区块链上执行，然后对实验结果进行分析和评估。

4.1 实验准备

4.1.1 实验环境

本文实验环境如下：操作系统为Windows 10专业版，64位；处理器为英特尔第七代酷睿i5-7500(3.40 GHZ，四核四线程)；内存为16 GB；JDK版本为1.8.0_181；Solidity版本为0.4.22；Node.js版本为10.13.0；Ganache版本为v2.5.4；部署器为Remix；以太坊JavaScript API为Web3.js[23]；编排图建模器为chor-js[21]；对比引擎为ChorChain[15]。

4.1.2 实验案例

采用本文所提业务流程赋时编排图对该助听器企业的商品订购流程进行编排，如图5所示，流程主要涉及4个流程参与者(即门店客户、生产商、物流商、发货承运商)、9个编排活动、12条消息、4个决策网关和5个事件，是一个典型的跨组织业务流程。采用本文所提基于赋时编排图驱动的业务流程管理引擎，可解决该跨组织业务中由于消息差错或延迟产生的信任问题。具体地，当图中的发货承运商和生产商产生利益纠纷时，发货承运商和生产商可通过区块链追溯过程实例的具体信息来解决该矛盾，不需要第三方权威机构介入；而在引入时间约束后，可以有效解决由于生产商产品生产过慢、物流商产品交付时间延迟等带来的经济处罚问题。

基于所提出的引擎，在以太坊私链上对该商品订购跨组织业务流程案例对10个实例执行过程进行模拟实验，相关实例覆盖图中包含的所有元素、消息和决策信息。其中商品订购流程的赋时编排图通过Remix部署于以太坊私链上，以太坊私链由以太坊节点仿真器Ganache搭建，并选取其中10个以太坊账户作为流程参与者。

4.2 区块链Gas消耗分析

本文引擎在以太坊节点仿真器Ganache搭建的本地私有链上执行。值得注意的是，以太坊上的交易不是免费的，需向挖矿的矿工支付加密货币作为手续费，而需要支付的手续费即Gas总成本由衡量操作复杂性的Gas数量和Gas单价的乘积决定，即

Cgas=GasUsed·GasPrice。

(2)

式中：Cgas为在区块链上执行某项操作或某个智能合约部署、调用合约方法等所需计算资源的Gas总成本；GasUsed为Gas的数量；GasPrice为Gas的单价。

在本文所提基于赋时编排图的区块链业务流程管理引擎中，Gas总成本主要由合约部署成本Cdeploy、数据导入与版本初始化成本Cinit、实例创建和执行成本CinstancecreaAndExe3部分组成，即

CALL=Cdeploy+Cinit+CinstancecreaAndExe。

(3)

4.2.1 合约部署

表1所示为本文引擎的部署成本Cdeploy，主要分为访问控制合约ACC的部署成本ACCdeploy、投票合约VC的部署成本VCdeploy和脚手架合约SC的部署成本SCdeploy3部分，即

Cdeploy=ACCdeploy+VCdeploy+SCdeploy。

(4)

表1 合约部署Gas消耗

4.2.2 数据导入与版本初始化

合约部署完成后，需要在创建实例之前导入数据并进行版本初始化，表2所示为数据导入和版本初始化的Gas消耗。本文采用Ganache中的10个以太坊账户作为实验评估测试的过程参与者，addParticipant表示初始化导入10个账户；addRole表示将元模型ML解析后的所有角色列表导入脚手架合约SC对应的数据结构中；addMessage，addElement，addDMN，addVersion分别表示往脚手架合约SC中导入对应的消息M、元素E、决策D和时间T，相关描述如算法2所示；vote表示版本初始化过程中的投票决策。

表2 数据导入与版本初始化的Gas消耗

4.2.3 实例创建和执行

在完成合约部署和数据导入与版本初始化后，流程管理者即可基于脚手架合约SC创建基于版本V的流程实例，实例通过引用脚手架合约SC中通用的数据结构进行编排活动的消息交互，来执行流程实例。实例创建和执行总成本

(5)

式中：Cinstancecrea，Cinstanceexe分别为单个实例创建和执行的Gas成本。

本文基于图5模拟了10个实例的创建和执行过程，表3所示为创建和执行流程实例的Gas消耗结果，包括newInstance(创建新实例)，sendMessage(发送编排活动中的消息)，ackMessage(确认编排活动中的消息)，completeTask(激活并启用事件或网关)4个实例方法的调用次数、平均Gas消耗和Gas消耗合计。

表3 实例创建和执行Gas消耗

4.3 与现有工作的比较

4.3.1 定性比较

本节将本文所提基于赋时编排图的区块链业务流程管理引擎与现有方法或引擎进行比较，包括LPEZ-PINTAD等[5]提出的Caterpillar引擎、LADLEIF等[14]提出的针对编排图的操作语义、LICHTENSTEIN等[16]提出的区块链上降低Gas消耗的编排方法、AMAL ABID等[10]针对Caterpillar提出的时间约束扩展方法、CORRADINI等[15]提出的ChorChain原型引擎。本文主要从访问控制、版本控制、时间控制、实例化成本和执行成本5个角度对这些方法进行定性评估和比较，如表4所示，表中★越多表示在相关方面越具优势。

表4 相关原型或方法的定性比较

(2)版本控制 本文引擎集成并实现了基于投票机制的版本控制策略，是一种比较新颖的方式，也是目前区块链结合业务流程领域少数提供版本控制的原型引擎，其中实例基于版本进行归档或追溯，可以解决现有版本迭代困难的问题。

(3)时间控制 AMAL ABID等针对Caterpillar扩展了时间约束的功能，用于支持多个活动间时间约束和活动内时间约束，如流程活动的开始和完成时间[10]，并分别给出相应的定义和Solidity代码来实现，但是仍未解决Caterpillar本身存在缺乏组织间消息交互、实例化成本高等问题，也未给出实例验证。不同于Caterpillar引擎用BPMN流程图驱动流程，本文基于编排图扩展了时间约束，提出集成了编排活动单次时间约束、活动最大时间约束和活动间隔时间约束的赋时编排图，实现了对链上业务流程有效时间的管理。另外，本文通过一家助听器行业的实际业务流程进行了实验验证。

4.3.2 定量比较

本节将对成本进行定量比较。本文采用CORRADINI等[15]提出的ChorChain原型引擎作为对比，因为ChorChain引擎与本文引擎类似，均通过编排图驱动链上的业务流程，不同的是ChorChain引擎采用实例和合约一对一的编译型方式进行部署，其部署的合约是单一实例独占的，所以合约部署与实例创建同时完成，而本文引擎先进行合约部署、数据导入与版本初始化这两个过程得到元模型，再基于参考的元模型创建和执行实例。

如上文所述，本文引擎的执行总成本主要分为合约部署成本、数据导入与版本初始化成本、实例创建和执行成本3部分，其中合约部署、数据导入与版本初始化两个部分只需消耗Gas一次，即这两部分成本不会随流程实例数量的增加而增加，而实例创建和执行消耗的Gas成本则随实例数量的增加而增加。ChorChain的执行成本主要分为实例创建成本和实例执行成本两部分，这两部分的Gas成本会同时随流程实例数量的增加而增加。

图6所示为本文引擎和ChorChai引擎[15]的Gas执行总成本对比。ChorChain引擎由于没有合约部署、数据导入与版本初始化这两个过程带来的额外成本，在没有实例或实例数量少于7的情况下，其执行总成本(图中第3条柱状图的总高度)相对较低，优于本文引擎(图中第2条柱状图的总高度)。然而随着实例数量的增加，由于ChorChain引擎需要为每个实例创建一个合约后再执行，平均每次将带来约7 903 213的Gas总开销(其中实例创建占总成本60%左右，实例执行占40%左右)，其执行总成本明显增加。本文引擎虽然比ChorChain引擎多了合约部署、数据导入与版本初始化两个部分的执行成本，但是因为这两个部分只需执行一次，所以随着实例数量的增加，其执行总成本增加得比较缓慢。在实例数量大于7时，本文引擎的执行总成本开始少于ChorChain引擎，可见本文引擎在大量实例下更具优势。 另外，相比无时间约束，在本文引擎中添加时间约束平均增加17%的总执行成本，这是在编排活动中集成时间约束判断带来的不可避免的Gas消耗。

综上所述，通过定量分析实验可知，虽然本文引擎需在实例创建和执行之前付出额外的代价用于合约部署、数据导入与版本初始化，而且实例的执行平均成本高于ChorChain引擎，但是本文引擎在执行大量流程实例时总体上表现更优。

5 结束语

针对现有区块链业务流程管理引擎实例化成本过高、版本迭代困难、缺乏时间约束等问题，本文提出一种基于赋时编排图的业务流程管理引擎。引擎引入活动单次持续时间约束、活动最大持续时间约束和活动间隔时间约束3类时间约束，在链上对时间敏感的业务流程进行高效管理。另外，引擎采用基于元模型的解释型部署方式，部署后的智能合约可被不同流程实例编排复用，从而大幅降低区块链Gas消耗。引擎还提供了基于投票机制的元模型版本控制策略，解决了版本迭代困难的问题。

未来将尝试在引擎中集成支持编排子过程和标记等更多功能的建模器，同时尝试结合版本控制进行实例动态迁移，并对实例相关资源进行更细致地评估和扩展。在跨组织业务流程中，业务流程时间相关的预测，如供应链中商品到货时间预测等研究较少，未来将结合时间信息和机器学习方法进行链上时间预测。