掌桥专利:专业的专利平台
掌桥专利
首页

一种工作流的构建方法、装置和设备

文献发布时间:2023-06-19 11:29:13


一种工作流的构建方法、装置和设备

技术领域

本说明书实施例涉及计算机应用技术领域,特别涉及一种工作流的构建方法、装置和设备。需要说明的是,本申请公开的工作流的构建方法、装置和设备可用于金融领域,也可用于除金融领域之外的任意领域,本申请公开的产品数据处理方法、装置及设备的应用领域不做限定。

背景技术

目前在企业日常管理中工作流程是每一个企业管理系统中必不可少的组件,从项目全流程管理、合同订单管理到人员请假、人员报销均需要使用流程组件。现有技术中通常是即基于BPM(业务流程管理)提供一系列场景化解决方案,需按照BPMN(业务流程建模与标注)标准建立业务流程,对于一些有特殊需求的场景,系统开发人员需要基于这些组件的复杂源码进行重构或是通过调整大量工作流原生表数据进行处理。因此,采用现有技术中的技术方案无法针对特殊的业务需求便捷地构建工作流。

针对上述问题,目前尚未提出有效的解决方案。

发明内容

本说明书实施例提供了一种工作流的构建方法、装置和设备,以解决现有技术中无法在工作流迭代、变更较频繁的场景下便捷地构建工作流的问题。

本说明书实施例提供了一种工作流的构建方法,包括:根据目标业务需求定义活动信息集;其中,所述活动信息集中包含:活动节点、活动流向;基于所述目标业务需求定义所述活动信息集中各个活动节点的控制器;其中,所述控制器用于控制活动节点的流向;根据所述活动信息集和各个活动节点的控制器,利用程序语言构建所述目标业务需求对应的目标工作流;其中,所述目标工作流执行产生的实例数据利用预设的数据对象存储。

本说明书实施例还提供了一种工作流的构建装置,包括:第一定义模块,用于根据目标业务需求定义活动信息集;其中,所述活动信息集中包含:活动节点、活动流向;第二定义模块,用于基于所述目标业务需求定义所述活动信息集中各个活动节点的控制器;其中,所述控制器用于控制活动节点的流向;构建模块,用于根据所述活动信息集和各个活动节点的控制器,利用程序语言构建所述目标业务需求对应的目标工作流;其中,所述目标工作流执行产生的实例数据利用预设的数据对象存储。

本说明书实施例还提供了一种工作流的构建设备,包括处理器以及用于存储处理器可执行指令的存储器,所述处理器执行所述指令时实现所述工作流的构建方法的步骤。

本说明书实施例提供了一种工作流的构建方法,可以根据目标业务需求定义活动信息集,其中,所述活动信息集中可以包含:活动节点、活动流向等。可以基于上述目标业务需求定义所述活动信息集中各个活动节点的控制器,上述控制器用于控制活动节点的流向。通过设计控制器可以提供更多业务自定义处理模式,有效降低了工作流处理逻辑与系统业务处理的偶合性。进一步的,可以根据所述活动信息集和各个活动节点的控制器,利用程序语言构建所述目标业务需求对应的目标工作流;其中,所述目标工作流执行产生的实例数据利用预设的数据对象存储。在工作流迭代、变更较频繁的场景下使得开发人员可以结合活动定义和控制器定义可以便捷地迭代响应系统业务需求,并且对于频繁调整审批流程或是有特殊处理审批需求场景下有更好的适用性与重构性,从而有利于开发人员进行业务扩展和个性化改造。

附图说明

此处所说明的附图用来提供对本说明书实施例的进一步理解,构成本说明书实施例的一部分,并不构成对本说明书实施例的限定。在附图中:

图1是根据本说明书实施例提供的工作流的构建方法的步骤示意图;

图2是根据本说明书实施例提供的利用闭环控制器进行闭环判断的流程的示意图;

图3是根据本说明书实施例提供的存在分支子流程和差异分值闭环的场景的闭环判断流程的示意图;

图4是根据本说明书实施例提供的存在分支子流程的闭环判断流程的示意图;

图5是根据本说明书实施例提供的工作流的构建装置的结构示意图;

图6是根据本说明书实施例提供的工作流的构建设备的结构示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本说明书实施例的原理和精神。应当理解,给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本说明书实施例,而并非以任何方式限制本说明书实施例的范围。相反,提供这些实施方式是为了使本说明书实施例公开更加透彻和完整,并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域的技术人员知道,本说明书实施例的实施方式可以实现为一种系统、装置设备、方法或计算机程序产品。因此,本说明书实施例公开可以具体实现为以下形式,即:完全的硬件、完全的软件(包括固件、驻留软件、微代码等),或者硬件和软件结合的形式。

虽然下文描述流程包括以特定顺序出现的多个操作,但是应该清楚了解,这些过程可以包括更多或更少的操作,这些操作可以顺序执行或并行执行(例如使用并行处理器或多线程环境)。

请参阅图1,本实施方式可以提供一种工作流的构建方法。该工作流的构建方法可以用于在工作流迭代、变更较频繁的场景下下便捷地根据业务需求构建工作流。上述工作流的构建方法可以包括以下步骤。

S101:根据目标业务需求定义活动信息集;其中,活动信息集中包含:活动节点、活动流向。

在本实施方式中,可以根据目标业务需求定义活动信息集;其中,上述目标业务需求可以用于表征需要建立的工作流的处理逻辑和涉及的处理对象。上述活动信息集中可以包含:活动节点、活动流向等,当然可以理解的是,上述活动信息集中还可以包含其它信息,例如:活动操作、活动节点的处理对象等,具体的可以根据实际情况确定,本说明书实施例对此不作限定。

在本实施方式中,活动节点(work_flow_node)的定义可以如表1中所示。

表1

在本实施方式中,活动定义可以为一套工作流的配置信息,定义了某一个工作流有多少个活动节点,每个活动节点分别有哪些操作,这些操作可以流转至其他哪些活动节点,其中POS_MARK表示流转至该节点需要为上一个节点增加多少权重值,NEG_MARK表示分支活动节点返回对应的主干活动节点需扣减多少权重值。上述工作流数据对象用于存放工作流执行过程中实际产生的流程数据的相关信息,可以包括:工作流信息、活动任务信息、任务用户信息、任务跟踪信息等。

在本实施方式中,上述“工作流数据对象”具体记录了每一次工作流从启动到完成的真实情况,“工作流数据对象”中的信息均是通过执行用户具体操作所对应的控制器,并通过控制器处理活动定义配置信息自动生产流程数据,其中,上述活动任务信息可以记录流转过程中每一个活动节点的状态,包括活动节点权重值(MARK)以及活动任务状态(STATUS)。例如:有一个立项流程,工作流程的活动定义中定义立项有申请节点、内部审批节点、征求节点、批复节点。当发起了多个立项流程,每一个立项流程实际流转根据不同的操作或者业务场景会出现各种流转情况有些是退回的有些是审批通过的,数据对象用于记录这些实例。

在本实施方式中,上述工作流类型(APP_TYPE)用于区分不同的工作流的类型,包括区分独立的工作流类型、父子工作流类型,也可以包括用户自行定义类型标识。例如:采购计划审批工作流标识为01、采购立项(父流程)审批工作流标识为02、外部技术资源(子流程)审批工作流标识为02-03、测评(子流程)审批工作流标识02-04。

在本实施方式中,权重加分值和权重减分值用于分支流程、会签等此类场景,从主干活动节点到达分支节点,通过权重加分值乘以分支数量计算出该主干活动节点的分支权重值(MARK=POS_MARK×num)。从分支回到主干活动节点时,通过将主干活动节点的分支权重值-(权重减分值×返回的分支数量)计算出该主干活动节点的任务执行结果(MARK=MARK-NEG_MARK×num),如果MARK小于等于0,则完成了分支、会签,可以进入下一个环节。结果MARK大于0,则需要继续等待其他分支、会签反馈,以完成分支闭环。

在本实施方式中,上述主干分支标识(MULTIPATH)用于标识活动节点是主干活动节点还是分支活动节点。如果操作指向的下一节点为主干标识,则不允许当前环节是仍有在途的分支活动节点,需要完成当前所有分支流程后(MARK<=0)才能进入下一主干环节。如果操作指向的下一节点为分支标识,即使当前环节仍有未完成的分支活动节点,仍能够继续增加新的分支流向。如果当前为分支活动节点,也能够基于当前分支活动节点再进行分支到分支的操作,同时分支活动节点下一个活动节点为新的主干活动节点,则下一个主干活动节点可以作为该分支上的一个主干活动节点。最后分支均需要返回之前原始的主干或者分支活动节点进行闭环,以继续后续流程。同时,对于竞争类活动节点可通过修改权重值来实现,从而使得通过活动节点定义可以实现较为复杂的活动节点流图。

在本实施方式中,活动操作(work_node_operate)的定义可以如表2中所示。

表2

在本实施方式中,一个活动节点(STATE_NUM)包含多个操作(OPER_ID),每一个操作对应一个操作控制器,操作控制器由OPER_CTL与CTL_PARAM组成,OEPR_CTL可以存放用户自定义的业务方法,例如:java方法名。CTL_PARAM存可以放用户调用该方法的入参,例如具体的实体类等。从而操作控制器可以根据用户的定义程序去系统中查找对应的业务方法通过反射或者依赖注入的方式进行处理,并将业务处理结果与结果匹配器进行匹配,决定该操作流向哪一个节点。

在本实施方式中,活动流向(work_node_direct)的定义可以如表3中所示。

表3

在本实施方式中,活动节点的每一个操作会产生多个流向流转至不同的下一活动节点,如果该操作存在用户自定义业务流向判断,可以对操作控制器进行配置,根据业务表单处理结果判定流程流向。如果该操作不涉及业务逻辑,则操作控制器默认为空,可以按照操作-流向一对一的关系进入下一个活动节点。

在本实施方式中,活动用户的定义可以如表4中所示。

表4

在本实施方式中,活动用户用于表示一个活动节点应由哪些用户处理,通过定义活动用户和用户信息实体类,可以便于后续按照自定义用户、角色、组、机构等模式进行工作流数据对象的查找及统计。

在本实施方式中,上述用户信息实体类主要以Bean类提供给用户自定使用,用户可以根据目标业务需求将相关信息写入用户信息实体类中。例如用户自定义一个“采购立项”审批流程(APP_TYPE=02),该流始默认初始节点为“立项申请”的活动节点(STATE_DESC=采购立项申请),该节点关联了一个“提交申请”的操作(OPER_DESC=提交申请)。在一些实施例中,可以根据流程类型(APP_TYPE)以及当前发起用户(work_node_assignee)执行ProcessInstance processInstance=workflowEngine.getRuntimeFlow().startProcessInstanceByType(“02”,work_node_assig nee),以启动“采购立项”的审批流程。进一步的,可以执行processInstance.getTaskByUserId(state_num,work_node_assignee.user_id).completeTask(oper_id,projectInfo)方法进行当前活动任务的流转,并返回该流程的下一活动任务的实体信息,并通过nextTask.setAssignee(List)的方法设置下一活动的用户信息。

S102:基于目标业务需求定义活动信息集中各个活动节点的控制器;其中,控制器用于控制活动节点的流向。

在本实施方式中,可以基于上述业务需求定义活动信息集中各个活动节点的控制器。其中,上述控制器用于在工作流中根据活动定义以及数据对象信息进行活动节点的流向控制,上述数据对象用于存放工作流执行过程中实际产生的流程数据的相关信息。

在本实施方式中,上述控制器可以包括操作控制器、闭环控制器。操作控制器可以包括:控制器入参(CTL_PARAM)、控制器(OPER_CTL)、结果匹配器(CTL_RESULT)三个要素,其中控制器入参为用户自定义的实体类名称,控制器为用户自定义的业务流转控制方法,结果匹配器是根据用户自定义业务处理结果匹配寻找下一个活动节点的流向。例如:用户自定义一个“采购立项”审批流程(APP_TYPE=02),该流程包含一个“立项申请”的活动节点(STATE_DESC=采购立项申请),该节点关联了一个“提交申请”的操作(OPER_DESC=提交申请),基于该流程用户定义了一系列表单实例信息,包含立项名称、金额等。该操作包含两个流向,如果立项金额小于1万可直接提交部门领导审批(DIRECT_DESC=部门领导审批),否则先要提交部门采购岗初审后再提交部门领导审批(DIRECT_DESC=采购岗初审)。用户自定义表单实例信息com.flow.purchase.bean.projectInfo实体类通过用户自定义业务处理类com.flow.purchase.projectCheck中的projectAmountCheck方法获取业务结果,最后经过结果匹配器处理工作流流向结果。

在本实施例中,可以将用户自定义立项表单实体类com.flow.purchase.projectInfo设置在“提交申请”操作的控制器入参(CTL_PARAM)中,其次将用户自定义业务处理方法名com.flow.purchase.projectCheck.projectAmountCheck设置在“提交申请”操作流向控制器(OPER_CTL)中。当用户在“立项申请”的活动节点中进行“提交申请”操作时,获取到当前活动任务信息后,可以将上述自定义立项表单的相关信息(com.flow.purchase.projectInfo)、OPER_ID等作为入参进行工作流的调用,工作流会根据入参信息装载该操作下的控制器中的用户自定义的业务流转控制方法,完成相应的业务处理。并根据业务处理结果,从“部门领导审批”以及“采购岗初审”这两个流向中匹配一个符合条件的下一活动节点,进行流转。

在本实施方式中,上述闭环控制器可以用于对当前活动任务处理状态的判定,以及下一活动任务处理状态的判定。可以根据当前活动节点及下一活动节点定义中的POS_MARK、NEG_MARK与活动任务信息中的MARK进行权重分值判定以达到控制活动任务闭环状态的目的。一个活动节点可以对应一个活动任务,同时一个活动节点可以对应多个操作,例如:审批节点可以对应相应人员进行审批的活动任务,同时审批节点可以对应选择审批通过、选择审批不通过等操作。具体的可以根据实际情况确定,本说明书实施例对此不作限定。

S103:根据活动信息集和各个活动节点的控制器,利用程序语言构建目标业务需求对应的目标工作流;其中,目标工作流执行产生的实例数据利用预设的数据对象存储。

在本实施方式中,可以根据上述活动信息集和上述各个活动节点的控制器,利用程序语言构建目标业务需求对应的目标工作流。其中,上述目标工作流执行产生的实例数据利用预设的数据对象存储,以便可以及时调用。

在本实施例方式中,可以结合目标业务需求对应的场景利用程序语言构建目标工作流。例如:如果是会签处理,工作流支持多次建立分支活动任务,可以多次调用processInstance.getTaskByUserId(state_num,work_node_assignee.user_id).completeTask(oper_id,projectInfo)产生多个分支活动任务,对于每一个活动任务可以通过nextTask.setAssignee(List)更新活动用户信息(其中List为一条活动用户信息)以实现会签功能。如果是竞争性审批场景,对应的可以仅调用一次上述processInstance.getTaskByUserId(state_num,work_node_assignee.user_id).completeTask(oper_id,projectInfo)产生一个活动任务,对于该活动任务指定多个work_node_assignee(活动用户)即可。

在本实施方式中,上述预设的数据对象可以用于存放工作流执行过程中实际产生的流程数据的相关信息,可以包括:工作流信息、活动任务信息、任务用户信息、任务跟踪信息等。其中,工作流信息用于记录工作流类型与工作流实例的关联关系,工作流信息(work_flow_record)的定义可以如表5中所示。

表5

在本实施方式中,基于一个工作流活动定义(配置模板),能够基于该定义(模板)发起无数具体的流程,每一个具体的流程即为一个工作流实例。

在本实施方式中,上述活动任务信息用于根据活动节点定义、活动操作定义、活动流向定义通过工作流控制器实现流程实例的任务记录,上述活动任务信息(work_task_record)的定义可以如表6中所示。

表6

在本实施方式中,上述活动任务实例可以为某一个工作流实例中一个活动节点对应的活动任务实例。上述任务用户信息可以用于关联每一个任务实例对应的用户处理信息,其中,USER_ID、ROLE_ID、GROUP_ID、BRANCH_ID可以根据目标业务需求自定义设置,上述任务用户信息(work_assignee_record)的定义可以如表7中所示。

表7

在本实施方式中,上述任务跟踪信息用于对工作流实例的具体操作信息进行完整的记录,上述任务跟踪信息(work_step_record)的定义可以如表8中所示。

表8

在本实施方式中,上述任务用户信息以及任务跟踪信息可以通过数据冗余的方式提供工作流统计及查询功能的可扩展性及灵活性。进一步的,可以按照上述工作流信息、活动任务信息、任务用户信息、任务跟踪信息等实体的定义建立数据对象相应的表结构以存储相关信息。在一些实施例中,也可通过重写的方式进行实体字段的扩展或者调整,具体的可以根据实际情况确定,本说明书对此不作限定。

从以上的描述中,可以看出,本说明书实施例实现了如下技术效果:可以根据目标业务需求定义活动信息集,其中,活动信息集中可以包含:活动节点、活动流向等。可以基于上述目标业务需求定义活动信息集中各个活动节点的控制器,上述控制器用于控制活动节点的流向。通过设计控制器可以提供更多业务自定义处理模式,有效降低了工作流处理逻辑与系统业务处理的偶合性。进一步的,可以根据活动信息集和各个活动节点的控制器,利用程序语言构建目标业务需求对应的目标工作流;其中,目标工作流执行产生的实例数据利用预设的数据对象存储。在工作流迭代、变更较频繁的场景下使得开发人员可以结合活动定义和控制器定义可以便捷地迭代响应系统业务需求,并且对于频繁调整审批流程或是有特殊处理审批需求场景下有更好的适用性与重构性,从而有利于开发人员进行业务扩展和个性化改造。

在一个实施方式中,活动信息集中还可以包含:活动操作,基于目标业务需求定义活动信息集中各个活动节点的控制器,可以包括:在确定目标活动节点需要自定义操作控制器的情况下,将目标活动节点对应的活动任务实例编号、活动操作编号、自定义表单实例作为目标操作控制器的入参。进一步的,可以根据目标活动节点对应的活动节点和活动流向,在目标操作控制器中写入自定义控制类和自定义业务流转控制方法;其中,目标活动节点包含多个操作,目标操作控制器用于确定目标操作的节点流向。

在本实施方式中,可以针对活动信息集中每个活动节点定义一个操作控制器,操作控制器可以包括:控制器入参(CTL_PARAM)、控制器(OPER_CTL)、结果匹配器(CTL_RESULT)三个要素。其中,控制器入参可以自定义的实体类名称,可以包括:活动任务实例编号、活动操作编号、自定义表单实例;控制器为用户自定义的业务流转控制方法,结果匹配器可以用于根据用户自定义业务处理结果匹配寻找下一个活动节点的流向。

在本实施方式中,上述自定义表单实例可以为活动操作定义下的CTL_PARAM参数,上述自定义表单实例可以用于表征用户在目标活动节点的操作,可以用于确定业务处理结果。上述自定表单实例中可以包含自定义的多个相关业务参数,例如:立项名称、金额等。

在本实施方式中,上述自定义业务流转控制方法可以用于表征目标活动节点的业务处理逻辑,可以结合自定义表单实例对应的目标操作和自定义业务流转控制方法确定出业务处理结果,进而可以确定出目标操作的节点流向。

在一个实施方式中,在利用程序语言构建目标业务需求对应的目标工作流之后,还可以包括:在目标工作流流转至目标活动节点的情况下,可以将目标活动节点对应的活动任务实例编号、活动操作编号、自定义表单实例作为入参传入目标操作控制器。可以根据目标活动节点对应的活动任务实例编号和活动节点编号,获取目标活动节点下的操作实体信息。进一步的,可以根据目标活动节点对应的活动操作编号匹配得到操作实体信息中的目标操作实体信息。在确定目标操作实体信息存在对应的目标操作控制器的情况下,可以根据目标操作控制器中的自定义业务流转控制方法确定目标活动节点的下一活动节点编号。

在本实施方式中,当目标工作流流转至目标活动节点的情况下,可以将目标活动节点对应的活动任务实例编号、活动操作编号、自定义表单实例作为入参传入目标操作控制器。在一些实施例中,也可以通过活动任务实例编号获取目标活动节点对应的活动任务实体后将活动操作编号、自定义表单实例传入目标操作控制器中。其中,上述活动任务实体可以为数据对象中记录的活动任务信息(work_task_record)。

在本实施方式中,由于活动任务实体中可以记录有已流转到的活动节点下所有对应的操作实体信息。因此,可以根据活动操作编号(OPER_ID)匹配到目标活动节点下某个具体操作实体信息。例如:找到“采购立项申请”活动节点下的“提交审批”操作。

在本实施方式中,可以判断目标活动节点下的操作实体是否有自定义的操作控制器,如果操作控制器(OPER_CTL)为空,则可以认为操作与流向为一对一。其中,如果没有用户自定义控制器,则需要定义唯一一条流向信息,通过活动操作编号(OPER_ID)找唯一一条流向信息。如果操作控制器(OPER_CTL)写入了自定义控制类和业务流转控制方法,对于传统java项目可以通过反射的方式实例化自定义控制类,对于Spring项目可以从Spring容器中加载自定义控制类,Spring是一个免费开源框架。

在本实施方式中,如果上述自定义控制类实例化成功后,控制器会将传入的活动任务实例编号、活动操作编号、自定义表单实例作为入参,调用该实体类中的对应的自定义业务流转控制方法,同时为了确保配置的代码名称在用户系统中存在,可以根据自定义业务流转控制方法的入参类名称,对表单实体类进行校验和类型转换,并通过反射或者注入依赖转化为可执行的程序,以完成自定义逻辑处理。

在本实施方式中,在完成自定义业务流转控制方法逻辑处理后,获取自定义业务流转控制方法的返回值,并通过活动操作编号(OPER_ID)遍历该操作下的所有流向信息,并通过返回值与结果匹配参数进行匹配,匹配方式可支持简单的关系运算符匹配,例如:{result}>1000、{result}<=1000。进一步的,可以读取最终匹配成功的下一个活动节点编号(NEXT_STATE_NUM)。

在本实施方式中,可以根据下一活动节点编号(NEXT_STATE_NUM)装载下一活动节点的实体信息,并将目标活动节点的任务实体、下一活动节点的任务实体作为入参传入闭环控制器,从而可以确定目标活动节点是否可以流转至下一活动节点。

在一个实施方式中,根据目标业务需求定义活动信息集,可以包括:在确定活动信息集中包含分支活动节点的情况下,设置各个分支活动节点的权重加分值和权重减分值;其中,权重加分值用于表征在到达下一个分支活动节点时增加的当前活动节点权重值,权重减分值用于表征在分支返回时减去的分支活动节点的权重值。

在本实施方式中,权重加分值和权重减分值用于分支流程、会签等此类场景。从主干活动节点到达分支节点,可以通过权重加分值乘以分支数量计算出该主干活动节点的分支权重值(MARK=POS_MARK×num)。从分支回到主干活动节点时,通过将主干活动节点的分支权重值-(权重减分值×返回的分支数量)计算出该主干活动节点的任务执行结果(MARK=MARK-NEG_MARK×num),如果MARK小于等于0,则完成了分支、会签,可以进入下一个环节。结果MARK大于0,则需要继续等待其他分支、会签反馈,以完成分支闭环。

在本实施方式中,权重加分值和权重减分值的具体数值可以根据实际情况确定,例如,一个活动环节流转出相同的10条分支给不同的机构用户进行会签,开发人员定义会签的每条分支POS_MARK=1,但只需要50%用户处理即可闭环该会签,那么在会签指向的闭环活动节点的NEG_MARK=2,从而实现5条分支返回闭环活动节点即可结束该会签。当然,权重加分值和权重减分值设置的方式不限于上述举例,所属领域技术人员在本说明书实施例技术精髓的启示下,还可能做出其它变更,但只要其实现的功能和效果与本说明书实施例相同或相似,均应涵盖于本说明书实施例保护范围内。

在一个实施方式中,在根据目标业务需求定义活动信息集之后,还可以包括:在确定活动信息集中包含分支活动节点的情况下,在各个分支流程的末端设置闭环控制器;其中,闭环控制器用于判断当前分支流程是否闭环以流转至下一主干流程。

在本实施方式中,在本实施方式中,上述闭环控制器可以用于对当前活动任务处理状态的判定,以及下一活动任务处理状态的判定。可以根据当前活动节点及下一活动节点定义中的POS_MARK、NEG_MARK与活动任务信息中的MARK进行权重分值判定以达到控制活动任务闭环状态的目的。

在本实施方式中,如果一个分支活动节点的下一活动节点为主干活动节点,则可以认为该分支活动节点为当前分支流程的末端,可以在该分支活动节点与下一活动节点之间设置闭环控制器。

在一个实施方式中,在利用程序语言构建目标业务需求对应的目标工作流之后,还可以包括:在目标工作流流从目标主干活动节点流转至分支活动节点时,获取目标主干活动节点对应的分支数量和分支活动节点的权重加分值。可以将目标主干活动节点对应的分支数量与分支活动节点的权重加分值的乘积作为目标主干活动节点的分支权重值,并在从分支活动节点回到目标主干活动节点时,确定当前分支活动节点的下一活动节点是否为主干活动节点。进一步的,在确定下一活动节点为主干活动节点的情况下,可以获取返回的分支数量和目标主干活动节点对应的分支活动节点的权重减分值,并将分支权重值与返回的分支数量和权重减分值的乘积的差值作为目标主干活动节点的任务执行结果,从而可以根据目标主干活动节点的任务执行结果判断是否调用下一活动节点。

在本实施方式中,在目标工作流流从目标主干活动节点流转至分支活动节点时,可以通过分支活动节点的权重加分值乘以标主干活动节点对应的分支数量计算出目标主干活动节点的分支权重值(MARK=POS_MARK×num)。在从分支活动节点回到目标主干活动节点时,可以先确定当前分支活动节点的下一活动节点是否为主干活动节点,如果当前分支活动节点的下一活动节点是主干活动节点,则不能存在仍在处理中的分支,需要确定目标主干活动节点是否形成闭环。如果当前分支活动节点的下一活动节点是分支活动节点,则可以基于分支节点继续进行流向新的分支。

在本实施方式中,在确定下一活动节点为主干活动节点的情况下,可以通过将目标主干活动节点的分支权重值-(目标主干活动节点对应的分支活动节点的权重减分值×返回的分支数量)计算出目标主干活动节点的任务执行结果(MARK=MARK-NEG_MARK×num)。

在一个实施方式中,在确定当前分支活动节点的下一活动节点是否为主干活动节点之后,还可以包括:在确定下一活动节点为分支活动节点的情况下,获取下一分支活动节点的权重加分值,并将数据对象中目标主干活动节点的任务状态更新为处理中。

在本实施方式中,如果当前分支活动节点的下一活动节点是分支活动节点,则可以基于分支节点继续进行流向新的分支。在一些实施例中,可以读取下一活动节点的分支活动节点权重加分值(POS_MARK),并将数据对象中存储的当前分支活动节点的活动任务状态设置为处理中(STATUS=1)。进一步的,可以更新目标主干活动节点权重值为MARK=MARK+POS_MARK。

在一个实施方式中,根据目标主干活动节点的任务执行结果判断是否调用下一活动节点,可以包括:在确定目标主干活动节点的任务执行结果小于等于0的情况下,根据数据对象确定在目标主干活动节点之前是否存在任务状态为处理中的历史任务。确定在目标主干活动节点之前存在任务状态为处理中的历史任务的情况下,可以确定历史任务对应的活动节点的下一节点是否为目标主干活动节点。进一步的,可以在确定历史任务对应的活动节点的下一节点为目标主干活动节点的情况下,确定历史任务对应的活动节点的任务执行结果。并在历史任务对应的活动节点的任务执行结果小于等于0的情况下,新增下一活动节点对应的任务实例;其中,新增的任务实例的任务状态为待处理,默认权重值为0。

在本实施方式中,如果目标主干活动节点的任务执行结果大于0,并且下一活动节点为主干节点,则不允许创建下一活动节点任务,需要等流转出去的分支达到闭环条件(MARK<=0)后才可流向主干节点。如果目标主干活动节点的任务执行结果大于0,并且下一活动节点为分支节点,则可基于分支节点继续进行流向新的分支。

在本实施方式中,如果目标主干活动节点的任务执行结果小于等多个与0,说明该任务没有仍在处理中的分支,没有限制条件。当前活动任务已流转出去分支任务后,当前活动任务仍允许继续发起其他分支任务,只有当前活动任务已经完成了流转出去的分支任务后,当前活动任务才能流向后续的主干节点。

在本实施方式中,在确定目标主干活动节点的任务执行结果小于等于0的情况下,可以根据数据对象中记录得到当前活动任务实体中上一活动任务实例编号(LAST_TASK_ID)向前追溯是否存在任务状态为任务处理中(STATUS=1),并且该处理中的任务的活动节点编号与操作控制器提供的下一活动节点编号一致的历史任务。如果有处理中的历史任务,说明当前完成的任务隶属于某个分支线中的一个任务,并且当前活动任务的操作是流向回原未闭环的目标主干活动节点,用于闭环之前的历史任务。在完成当前活动任务状态处理后,需要进行历史任务的闭环状态处理。如果向前追溯未找到,则说明当前活动任务的操作流向的下一活动节点并不涉及分支线,在完成当前活动任务状态处理后,可以实现创建下一活动任务实例。

在本实施方式中,在确定历史任务对应的活动节点的下一节点为目标主干活动节点的情况下,可以确定存在未闭环的历史活动任务的节点。可以根据未闭环的历史活动节点分支权重减分值(NEG_MARK),与历史任务的当前活动节点权重值(MARK)相减。经过计算后,如果历史任务的当前活动节点权重值(MARK)小于等于0,则说明该任务已满足闭环要求,可以更新该历史任务的活动节点状态为任务待处理(STATUS=0)。此时该历史任务为当前任务,后续如流转主干活动节点,可以将该任务的活动节点装更新为完成。如果历史任务的活动节点权重值大于0,说明历史任务还未满足闭环要求,仍有在途的分支流程,只能继续发起分支活动节点,或等其他分支流程返回后才可流转主干活动节点。

在本实施方式中,在确定满足闭环条件,可以流转至下一活动节点的情况下,可以新增任务实例,需要新增一个TASK_ID的任务实例,并且可以将当前任务的TASK_ID作为新增任务实例的LAST_TASK_ID,可以将新增任务示例的活动节点权重值默认设置为0,活动任务状态为任务待处理(STATUS=0)。

在一个实施方式中,确定在目标主干活动节点之前是否存在任务状态为处理中的历史任务之后,还可以包括:确定在目标主干活动节点之前不存在任务状态为处理中的历史任务的情况下,调用下一活动节点。进一步的,可以更新数据对象中目标主干活动节点和目标主干活动节点对应的分支活动节点的任务状态为任务完成。

在本实施方式中,在确定不存在未闭环的历史任务的情况下,可以新增一个TASK_ID的任务实例,以调用下一活动节点。由于可以流转至下一活动节点,为了确保节点流转的准确性和可追溯性,可以将数据对象中存储的目标主干活动节点和目标主干活动节点对应的分支活动节点的任务状态更新为任务完成(STATUS=2)。

在一个场景示例中,利用闭环控制器进行闭环判断的流程可以如图2所示,节点1可以通过操作1流转到节点2的两条分支,节点2的每条分支的POS_MARK为1,则会将节点1的活动任务信息中记录的MARK更新为2分。节点1通过操作2流转到节点3的一条分支的POS_MARK为1,此时会为节点1的活动任务信息中记录的MARK累加为3分(节点2的2分+节点3的1分),从而使得节点1的MARK=POS_MARK×3。

在本场景示例中,节点2可以通过操作3流转至节点4,节点2可以通过操作7返回至主干节点1,节点3可以通过操作4流转至节点5。在经过后续其他节点处理完成后,可以进行分支的闭环处理。节点4通过操作6闭环至节点1,此时节点1的NEG_MARK为1,所以在闭环时会去扣减节点1在数据对象中活动任务信息中记录的MARK(原来MARK已累积了3分,操作6闭环后扣减1分后为2分),当节点2通过操作7继续闭环至节点1时,节点1在活动任务信息中记录的MARK被扣减至1分,最后节点5通过操作5闭环至节点1后,节点1在活动任务信息中记录的MARK值归0,完成了所有分支闭环,节点1在活动任务信息中记录的STATUS由任务处理中(STATUS=1)恢复为任务待处理(STATUS=0)。

在本场景示例中,如果要从节点1通过操作8流向下一个主干节点6必须要完成分支闭环,也就是节点1在活动任务信息中记录的STATUS为任务待处理(STATUS=0)(即节点1的MARK值归0或小于0),此时节点1可以通过操作8流向活动节点6。其中,主干节点MULTIPATH=0、分支节点MULTIPATH=1。

在一个场景示例中,存在分支子流程和差异分值闭环的场景的闭环判断流程可以如图3所示,节点1可以通过操作1流转到节点2的两条分支,节点2的每条分支的POS_MARK为1,则会将节点1在活动任务信息中记录的MARK更新为2分。节点1可以通过操作2到达分支节点3,节点3的POS_MARK为1,此时会为节点1在活动任务信息中记录的MARK累加为3分(节点2的2分+节点3的1分)。

在本场景示例中,节点3可以通过操作4流转到节点5的两条分支,节点5的每条分支POS_MARK为2,则会为节点3在活动任务信息中记录的MARK更新为4分。节点5可以通过操作5闭环至节点3,此时节点3的NEG_MARK为2,所以在闭环时会去扣减节点3在活动任务信息中记录的MARK(原来节点3的MARK已累积了4分,之后2条分支分别通过操作5闭环至节点3,将节点3的MARK值扣减2+2,共4分),此时节点3的MARK归0,节点3的任务状态可以更新为任务待处理(STATUS=0)。

在本场景示例中,存在差异分值闭环,此时会为节点1在活动任务信息中记录的MARK累加至3分,节点4通过操作6闭环至节点1,此时节点1的NEG_MARK为2,所以在闭环时会去扣减节点1在活动任务信息中记录的MARK(原来MARK已累积了3分,操作6闭环后扣减2分)。当节点2通过操作7继续闭环至节点1,那么节点1在活动任务信息中记录的MARK被扣减至-1分,节点1的MARK值小于0,即使另一个节点3未发起闭环操作,系统也认为完成了闭环,节点1在活动任务信息中记录的STATUS由任务处理中(STATUS=1)恢复为任务待处理(STATUS=0),可执行后续任务。在一些实施例中,也可以由节点3通过操作8闭环至节点1,具体的可以根据实际情况确定,本说明书实施例对此不作限定。

在一个场景示例中,存在分支子流程的闭环判断流程可以如图4所示,节点1可以通过操作1流转到节点2的两条分支,节点2的每条分支的POS_MARK为1,则会将节点1在活动任务信息中记录的MARK更新为2分。节点1可以通过操作2到达分支节点3,节点3的POS_MARK为1,此时会为节点1在活动任务信息中记录的MARK累加为3分(节点2的2分+节点3的1分)。

在本场景示例中,如果节点2可以通过操作3流转至节点4,节点4通过操作6闭环至节点1,此时节点1的NEG_MARK为2,所以在闭环时会去扣减节点1在数据对象中活动任务信息中记录的MARK(原来MARK已累积了3分,操作6闭环后扣减2分后为1分)。同时节点3可以通过操作7闭环至节点1,此时节点1的NEG_MARK为2,所以在闭环时会去扣减节点1在数据对象中活动任务信息中记录的MARK(原来MARK已扣减为1分,操作7闭环后扣减2分后为-1分)。由于此时节点1的MARK小于等于0,可以关闭其他未处理的节点2,从而完成节点1的闭环,节点1在活动任务信息中记录的STATUS由任务处理中(STATUS=1)恢复为任务待处理(STATUS=0)。

在本场景示例中,节点3可以通过操作4流转到节点5的两条分支,节点5的每条分支POS_MARK为2,则会为节点3在活动任务信息中记录的MARK更新为4分。节点5可以通过操作5闭环至节点3,此时节点3的NEG_MARK为4,所以在闭环时会去扣减节点3在活动任务信息中记录的MARK(原来节点3的MARK已累积了4分,通过操作5闭环至节点3可以将节点3的MARK值扣减为0分),此时节点3的MARK归0,可以关闭其它未处理的节点5,同时节点3的任务状态可以更新为任务待处理(STATUS=0)。

基于同一发明构思,本说明书实施例中还提供了一种工作流的构建装置,如下面的实施例。由于工作流的构建装置解决问题的原理与工作流的构建方法相似,因此工作流的构建装置的实施可以参见工作流的构建方法的实施,重复之处不再赘述。以下所使用的,术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现,但是硬件,或者软件和硬件的组合的实现也是可能并被构想的。图5是本说明书实施例的工作流的构建装置的一种结构框图,如图5所示,可以包括:第一定义模块501、第二定义模块502、构建模块503,下面对该结构进行说明。

第一定义模块501,可以用于根据目标业务需求定义活动信息集;其中,活动信息集中包含:活动节点、活动流向;

第二定义模块502,可以用于基于目标业务需求定义活动信息集中各个活动节点的控制器;其中,控制器用于控制活动节点的流向;

构建模块503,可以用于根据活动信息集和各个活动节点的控制器,利用程序语言构建目标业务需求对应的目标工作流;其中,目标工作流执行产生的实例数据利用预设的数据对象存储。

本说明书实施例实施方式还提供了一种电子设备,具体可以参阅图6所示的基于本说明书实施例提供的工作流的构建方法的电子设备组成结构示意图,电子设备具体可以包括输入设备61、处理器62、存储器63。其中,输入设备61具体可以用于输入目标业务需求。处理器62具体可以用于根据目标业务需求定义活动信息集;其中,活动信息集中包含:活动节点、活动流向;基于目标业务需求定义活动信息集中各个活动节点的控制器;其中,控制器用于控制活动节点的流向;根据活动信息集和各个活动节点的控制器,利用程序语言构建目标业务需求对应的目标工作流;其中,目标工作流执行产生的实例数据利用预设的数据对象存储。存储器63具体可以用于存储目标工作流执行产生的实例数据等数据。

在本实施方式中,输入设备具体可以是用户和计算机系统之间进行信息交换的主要装置之一。输入设备可以包括键盘、鼠标、摄像头、扫描仪、光笔、手写输入板、语音输入装置等;输入设备用于把原始数据和处理这些数的程序输入到计算机中。输入设备还可以获取接收其他模块、单元、设备传输过来的数据。处理器可以按任何适当的方式实现。例如,处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(ApplicationSpecific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式等等。存储器具体可以是现代信息技术中用于保存信息的记忆设备。存储器可以包括多个层次,在数字系统中,只要能保存二进制数据的都可以是存储器;在集成电路中,一个没有实物形式的具有存储功能的电路也叫存储器,如RAM、FIFO等;在系统中,具有实物形式的存储设备也叫存储器,如内存条、TF卡等。

在本实施方式中,该电子设备具体实现的功能和效果,可以与其它实施方式对照解释,在此不再赘述。

本说明书实施例实施方式中还提供了一种工作流的构建方法的计算机存储介质,计算机存储介质存储有计算机程序指令,在计算机程序指令被执行时可以实现:根据目标业务需求定义活动信息集;其中,活动信息集中包含:活动节点、活动流向;基于目标业务需求定义活动信息集中各个活动节点的控制器;其中,控制器用于控制活动节点的流向;根据活动信息集和各个活动节点的控制器,利用程序语言构建目标业务需求对应的目标工作流;其中,目标工作流执行产生的实例数据利用预设的数据对象存储。

在本实施方式中,上述存储介质包括但不限于随机存取存储器(Random AccessMemory,RAM)、只读存储器(Read-Only Memory,ROM)、缓存(Cache)、硬盘(Hard DiskDrive,HDD)或者存储卡(Memory Card)。存储器可以用于存储计算机程序指令。网络通信单元可以是依照通信协议规定的标准设置的,用于进行网络连接通信的接口。

在本实施方式中,该计算机存储介质存储的程序指令具体实现的功能和效果,可以与其它实施方式对照解释,在此不再赘述。

显然,本领域的技术人员应该明白,上述的本说明书实施例的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本说明书实施例不限制于任何特定的硬件和软件结合。

虽然本说明书实施例提供了如上述实施例或流程图的方法操作步骤,但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑性上不存在必要因果关系的步骤中,这些步骤的执行顺序不限于本说明书实施例提供的执行顺序。所述的方法的在实际中的装置或终端产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

应该理解,以上描述是为了进行图示说明而不是为了进行限制。通过阅读上述描述,在所提供的示例之外的许多实施方式和许多应用对本领域技术人员来说都将是显而易见的。因此,本说明书实施例的范围不应该参照上述描述来确定,而是应该参照前述权利要求以及这些权利要求所拥有的等价物的全部范围来确定。

以上所述仅为本说明书实施例的优选实施例而已,并不用于限制本说明书实施例,对于本领域的技术人员来说,本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本说明书实施例的保护范围之内。

相关技术
  • 一种工作流的构建方法、装置和设备
  • 工作流的构建方法、装置、电子设备及可读存储介质
技术分类

06120112939769