098]配置的变迀动作、流程走向等规则，可以保存在本地数据库或者生成配置文件，以供系统从本地数据库或配置文件中调用对应的变迀动作并执行。
[0099]本实施例中，业务流程的变迀动作的走向可以为并行或串行。
[0100]如果执行相应变迀跳转到相应状态之后，由于业务的需要进行状态的回退，可以激活退回动作进行状态的回退。
[0101]采用本发明实施例所述方法，用户可以使用描述性语言或者采用图形化工具定制流程图，提供较为便捷的工作流配置方式，并生成相应数据作为持久化，允许以数据库或者文件的存储方式，通过依赖不同场景需求设置相应的激活方式，并依据实际场景做回退操作，满足不同场景需求。
[0102]本发明实施例基于Petri网模型的工作流引擎实现方式可适用于电商的订单生成流程及订单的后续操作走向。但是，需要说明的是，该应用场景可适用于但不局限于电商的订单流程。
[0103]基于以上内容，为了更清楚地描述上述基于Petri网模型的工作流引擎实现方法，下面将以在电商平台上前台用户下订单直至订单完成的流程为例，对本发明实施例进行详细阐述。
[0104]随着电商平台越来越普及，网上购物已成为一种普遍的购物行为和方式，为提升用户的体验，用户需了解在购买商品之后的订单走向，包括订单备货、发货以及物流走向，故在电商平台后端订单状态的及时更新或变迀变得尤为重要，这方面包括人工审核确认、自动抓取物流信息等。
[0105]结合5所示，通常通过以下几个步骤完成订单的业务过程，具体如下:
[0106]步骤1，用户前台下单生成一张订单，按照支付方式启动不同的订单工作流，此时，订单为未处理状态；
[0107]步骤2，用户前台付款，则从订单初始状态变更为订单已付款状态，如果在24小时之内没有付款则变更为订单已取消状态；
[0108]步骤3，后台客服审核订单无误后，通过点击处理推送订单报文信息到物流公司进行发货，此时订单变成已备货状态，如果物流公司推送发货信息给该订单，则及时更新订单状态为已发货；
[0109]步骤4，当用户收货并签收，此时推送签收信息更新订单状态为已签收，如果用户拒收，则推送拒收信息，更新订单状态为未妥投；
[0110]步骤5，如果用户实际为投妥，但由于快递人员误操作为未妥投，此时需要撤销订单未妥投状态为上一个状态，也即是已发货状态，再重新更新订单状态为已签收。
[0111]结合上述订单业务过程，利用本发明实施例的基于Petri网模型的工作流引擎的具体实现流程如下:
[0112]步骤10，使用基于Petri网模型的工作流引擎实现方法，通过描述性语言或者图形化工作生成起始状态，并定制后续的变迀动作，应用于订单的流程也即是订单生成状态，具体见上述步骤I ;
[0113]步骤20，通过不同的应用场景激活相应的动作，允许是外部消息激活，也允许是人工激活，或者是定时激活，执行相应变迀动作，并接收执行结果作为依据，跳转到相应状态，应用于订单的流程可以是订单未付款通过外部支付结果变成已付款状态(外部消息激活)，或者是订单由于时间过期未付款变成订单已取消状态(定时激活)，具体见上述步骤2 ；
[0114]步骤30，中间状态可读取定制或者配置好的变迀动作，重复执行相应变迀动作，直至业务流程的结束，也即是跳转到结束状态，应用于订单流程实施例则是由于商品的发货，订单已付款状态变成订单已发货状态，或者是商品的签收从订单已发货状态变成订单已签收状态，具体见上述步骤3、步骤4。
[0115]基于Petri网模型的工作流引擎实现方法的回退流程如下:
[0116]步骤40，中间状态允许回退到上一个状态，应用于订单流程实施例可以是商品签收变成商品拒收，需要商品签收状态退回到订单已发货状态，再执行拒收操作，具体见上述步骤5 ；
[0117]步骤50，回退动作会读取描述状态的变迀过程表，这里用令牌表表示，令牌表记录的是按照时间操作进行升序排列的操作状态，依据当前状态和上一次的变迀动作，读取到上一个状态值，撤销当前状态的变迀动作，激活上一个状态的变迀动作以及上一个状态；
[0118]步骤60，通过回退动作的返回结果，如果成功则回退到上一个状态，失败则提示错误?目息O
[0119]本发明实施例通过上述方案，在业务流程的当前中间状态的变迀动作结束后，接收外部触发的回退指令；根据回退指令，读取预先配置的变迀令牌表，变迀令牌表记录有按照时间操作顺序排列的操作状态；根据当前中间状态从所述变迀令牌表中读取上一次变迀动作及上一状态；撤销当前中间状态的变迀动作，并激活上一次变迀动作及上一状态，由此根据业务实际场景实现了业务流程的回退操作，提高业务流程处理灵活性，满足不同场景需求；此外，业务流程的走向、动作可灵活配置或者定制，并生成相应数据允许以数据库或者文件形式进行存储，通过依赖不同场景需求，可提供不同的流程激活方式，进一步满足不同场景需求。
[0120]对应地，提出本发明实施例业务流程处理装置。
[0121]如图6所示，本发明第一实施例提出一种业务流程处理装置，所述业务流程包括起始状态、中间状态和结束状态，所述装置包括:接收模块201、读取模块202及处理模块203，其中:
[0122]接收模块201，用于在业务流程的当前中间状态的变迀动作结束后，接收外部触发的回退指令；
[0123]读取模块202，用于根据所述回退指令，读取预先配置的变迀令牌表，所述变迀令牌表记录有按照时间操作顺序排列的操作状态；根据当前中间状态从所述变迀令牌表中读取上一次变迀动作及上一状态；
[0124]处理模块203，用于撤销当前中间状态的变迀动作，并激活上一次变迀动作及上一状态。
[0125]本实施例中，基于Petri网模型生成业务流程的工作流引擎，基于该工作流引擎实现业务流程处理，根据业务实际场景实现业务流程的回退操作，以提高业务流程处理灵活性，满足不同场景需求。
[0126]Petri网模型是一种描述离散的、分布式系统的数学建模工具。它用形式化手段描述状态及变迀，类似于有穷状态机模型。其文法规则有利于计算机程序维护。
[0127]如前所述，工作流泛指在业务当中的部分或者整体在互联网通信服务领域下的自动化，是对工作流程及各种操作步骤之间业务规则的抽象。
[0128]工作流引擎主要解决的问题是为了实现某个业务目标，利用计算机的协议规则传递任务、?目息或者服务。
[0129]本实施例采用基于Petri网模型来实现工作流引擎，流程的顺序流转、分支、汇聚、跳转等算法都有定义/定理为依据。
[0130]其中，Petri网模型包含四个基本元素:
[0131]库所:用于描述有穷状态机的状态；
[0132]变迀:用于状态迀移所需要执行的动作；
[0133]有向弧:用于描述状态变迀的方向；
[0134]令牌:描述状态的变迀过程。
[0135]本实施例考虑到:现有的工作流引擎主要依据是判断当前的工作状态生成相应的动作，不可定制且不易修改。且实际的工作流走向都是按指定的顺序流转，在实际业务过程中，需要进行业务的回退，常用的方式只能依据当前的状态生成相应的动作做跳转，但本实施例基于Petri网模型的工作流引擎实现方法可依据描述状态的变迀过程也即是令牌的走向来直接进行回退。
[0136]通常，业务流程包括起始状态、中间状态和结束状态，一个业务流程的结束以结束状态为止。
[0137]在进行业务流程处理时，依据工作流引擎，以起始状态作为起点，通过起始状态执行相应的变迀(动作)跳转到相应的状态，直至结束状态。
[0138]在业务流程处理过程中，可能会存在需要进行业务回退的情况，比如，用户通过电商平台购买商品时，订单业务处理过程中，用户实际为投妥，但由于快递人员误操作为未妥投，此时需要撤销订单未妥投状态为上一个状态，也即是已发货状态，再重新更新订单状态为已签收。
[0139]因此，在本实施例中，为了实现业务流程的回退操作，在业务流程的当前某一中间状态下，在变迀动作结束后，获取回退操作指令，该回退操作的指令可以由用户触发，也可以由系统根据用户反馈而触发。
[0140]之后，根据用户触发的回退指令，执行相应的回退操作。
[0141]具体地，首先，根据回退指令，读取预先配置的变迀令牌表，该变迀令牌表记录有按照时间操作顺序排列的操作状态。
[0142]之后，根据当前中间状态从所述变迀令牌表中读取上一次变迀动作及上一状态。
[0143]最后，撤销当前中间状态的变迀动作，并激活上一次变迀动作及上一状态。
[0144]比如，订单业务处理过程中，用户实际为投妥，但由于快递人员误操作为未妥投，此时需要撤销订单未妥投状态为上一个状态，也即是已发货状态，再重新更新订单状态为已签收。
[0145]本实施例通过上述方案，在业务流程的当前中间状态的变迀动作结束后，接收外部触发的回退指令；根据回退指令，读取预先配置的变迀令牌表，变迀令牌表记录有按照时间操作顺序排列的操作状态；根据当前中间状态从所述变迀令牌表中读取上一次变迀动作及上一状态；撤销当前中间状态的变迀动作，并激活上一次变