CN115330171A - 业务流程控制方法、装置、计算机设备及可读存储介质 - Google Patents

Abstract

本申请公开了一种业务流程控制方法、装置、计算机设备及可读存储介质，涉及互联网技术领域。可以使流程修改更加灵活，提高业务流程流转速度及审批效率。其中方法包括：对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则；在第一业务流程中，按照待修改规则，修改至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，第一业务流程用于指示修改前的原始业务流程；将至少一个第二审批规则与待修改规则进行比对，基于比对结果，生成第二业务流程，第二业务流程指示结束修改的第一业务流程；将业务数据发送至第二业务流程中第一个未完成的流程节点进行审批，直至第二业务流程中的最后一个流程节点审批结束。

Description

业务流程控制方法、装置、计算机设备及可读存储介质

技术领域

本申请涉及互联网技术领域，尤其是涉及一种业务流程控制方法、装置、计算机设备及可读存储介质。

背景技术

随着互联网业务的发展与互联网企业的壮大，企业的内部沟通成本成几何倍提升，因此，企业内部需要一套规范化的、清晰的业务流程流转控制系统，即流程引擎。流程引擎是用来处理大量的重复的业务逻辑的，通过流程引擎可以缩减大量的业务开发按成本，并提供一系列机制确保我们的业务的流畅度与准确性。

相关技术中，流程引擎需要先通过拖拽连线、点选节点等方式绘制流程模板，再基于固定好的流程模板来进行流程实例化，以使相关业务能够严格按照审批流程进行业务流转，直至审批完成。

在实现本申请的过程中，申请人发现相关技术至少存在以下问题：

在业务审批过程中，较长的审批流程容易发生如审批人离职、业务归属改变等意外情况，进而需要开发人员修改相应节点审批规则后重新启动审批流程，这就使得业务流转过程不够灵活，从而导致业务流程流转速度慢，审批效率低。

发明内容

有鉴于此，本申请提供了一种业务流程控制方法、装置、计算机设备及可读存储介质，主要目的在于解决业务流转过程不灵活，导致业务流程流转速度慢，审批效率低的技术问题。

根据本申请的第一个方面，提供了一种业务流程控制方法，该方法包括：

对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则；

在第一业务流程中，按照所述待修改规则，修改所述至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，所述第一业务流程用于指示原始业务流程，所述第一审批规则用于指示在所述第一业务流程中存储的原始审批规则；

将所述至少一个第二审批规则与所述待修改规则进行比对，基于比对结果，生成第二业务流程，所述第二业务流程用于指示结束修改的第一业务流程；

将业务数据发送至所述第二业务流程中第一个未完成的流程节点进行审批，直至所述第二业务流程中的最后一个流程节点审批结束。

根据本申请的第二个方面，提供了一种业务流程控制装置，该装置包括：

识别模块，用于对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则；

修改模块，用于在第一业务流程中，按照所述待修改规则，修改所述至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，所述第一业务流程用于指示原始业务流程，所述第一审批规则用于指示在所述第一业务流程中存储的原始审批规则；

比对模块，用于将所述至少一个第二审批规则与所述待修改规则进行比对，基于比对结果，生成第二业务流程，所述第二业务流程用于指示结束修改的第一业务流程；

审批模块，用于将业务数据发送至所述第二业务流程中第一个未完成的流程节点进行审批，直至所述第二业务流程中的最后一个流程节点审批结束。依据本申请第三方面，提供了一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述第一方面中任一项所述方法的步骤。

依据本申请第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面中任一项所述的方法的步骤。

本申请提供的一种业务流程控制方法、装置、计算机设备及可读存储介质，本申请对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则。随后，在第一业务流程中，按照待修改规则，修改至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，将至少一个第二审批规则与待修改规则进行比对。接下来，基于比对结果，结束对第一业务流程的修改，将结束修改的第一业务流程作为第二业务流程。最后，将业务数据发送至第二业务流程中第一个未完成的流程节点进行审批，直至第二业务流程中的最后一个流程节点审批结束。管理人员在业务审批过程中如果发现业务审批流程产生意外情况，可以通过使用方终端上传相关的流程修改指令，以使流程引擎根据修改指令自动进行流程的修改，并且将业务数据直接流转至第一个未审批的流程节点中，无需重新进行审批，使得流程修改更加灵活，进而提高业务流程流转速度及审批效率。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了本申请实施例提供的一种业务流程控制方法的流程示意图；

图2示出了本申请实施例提供的另一种业务流程控制方法的流程示意图；

图3A示出了本申请实施例提供的一种业务流程控制装置的结构示意图；

图3B示出了本申请实施例提供的一种业务流程控制装置的结构示意图；

图3C示出了本申请实施例提供的一种业务流程控制装置的结构示意图；

图4示出了本申请实施例提供的一种计算机设备的装置结构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

在一个实施例中，如图1所示，提供了一种业务流程控制方法，包括以下步骤：

101、对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则。

在本申请实施例中，开发人员可以基于使用方终端发起流程修改指令对已经设定好的第一业务流程进行修改。流程引擎响应于使用方终端发起的流程修改指令，对流程修改指令进行识别，在修改流程指令中读取至少一个需要进行修改的目标流程节点以及待修改规则。需要说明的是，使用方终端可以是电脑、平板、手机等带有显示屏的智能设备，本申请对使用方终端设备不进行具体限定。进一步地，待修改规则中存储有本次修改的内容，对目标流程节点一一对应。

102、在第一业务流程中，按照待修改规则，修改至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则。

在本申请实施例中，考虑到修改操作可能发生在审批流程执行过程中，故存在有正在执行的第一业务流程，也就是修改前的原始业务流程。流程引起在第一业务流程中查找至少一个目标流程节点对应的第一审批规则，即在第一业务流程中存储的原始审批规则。再按照待修改规则对至少一个第一审批规则进行修改，得到至少一个第二审批规则。

103、将至少一个第二审批规则与待修改规则进行比对，基于比对结果，生成第二业务流程，第二业务流程用于指示结束修改的第一业务流程。

在本申请实施例中，将至少一个第二审批规则与待修改规则进行比对，基于比对结果，确定审批规则是否修改成功。在确定修改成功后，将现在的业务流程作为第二业务流程。

104、将业务数据发送至第二业务流程中第一个未完成的流程节点进行审批，直至第二业务流程中的最后一个流程节点审批结束。

在本申请实施例中，考虑到修改前的第一业务流程中部分流程节点的审批状态为审批完成。因此，为了提高审批效率，流程引擎会将审批完成的流程节点的审批状态同步至第二业务流程，并将业务数据发送至第二业务流程中第一个未完成的流程节点进行审批。在审批完成后，将业务数据流转至下一个流程节点，直至第二业务流程中存储的最后一个流程节点完成审批。

本实施例提供的业务流程控制方法，对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则。随后，在第一业务流程中，按照待修改规则，修改至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，将至少一个第二审批规则与待修改规则进行比对。接下来，基于比对结果，结束对第一业务流程的修改，将结束修改的第一业务流程作为第二业务流程。最后，将业务数据发送至第二业务流程中第一个未完成的流程节点进行审批，直至第二业务流程中的最后一个流程节点审批结束。管理人员在业务审批过程中如果发现业务审批流程产生意外情况，可以通过使用方终端上传相关的流程修改指令，以使流程引擎根据修改指令自动进行流程的修改，并且将业务数据直接流转至第一个未审批的流程节点中，无需重新进行审批，使得流程修改更加灵活，进而提高业务流程流转速度及审批效率。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的实施过程，提供了业务流程控制方法，如图2所示，该方法包括以下步骤：

201、接收使用方终端发送的链表结构实体，对链表结构实体进行反解析，确定流程数据，对流程数据进行实例化，得到第一业务流程，采用第一业务流程进行业务数据的审批。

随着互联网业务的发展与互联网企业的壮大，企业的内部沟通成本几何倍提升，因此，企业内部需要一套规范化的、清晰的业务流程流转控制系统，即流程引擎。流程引擎是用来处理大量的重复的业务逻辑的，通过流程引擎可以缩减大量的业务开发按成本，并提供一系列机制确保我们的业务的流畅度与准确性。目前，流程引擎需要先通过拖拽连线、点选节点等方式绘制流程模板，再基于固定好的流程模板来进行流程实例化，以使相关业务能够严格按照审批流程进行业务流转，直至审批完成。但是申请人认识到，在业务审批过程中，较长的审批流程容易发生如审批人离职、业务归属改变等意外情况，进而需要开发人员修改相应节点审批规则后重新启动审批流程，这就使得业务流转过程不够灵活，从而导致业务流程流转速度慢，审批效率低。

因此，本申请提供的一种业务流程控制方法、装置、计算机设备及可读存储介质，本申请对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则。随后，在第一业务流程中，按照待修改规则，修改至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，将至少一个第二审批规则与待修改规则进行比对。接下来，基于比对结果，结束对第一业务流程的修改，将结束修改的第一业务流程作为第二业务流程。最后，将业务数据发送至第二业务流程中第一个未完成的流程节点进行审批，直至第二业务流程中的最后一个流程节点审批结束。管理人员在业务审批过程中如果发现业务审批流程产生意外情况，可以通过使用方终端上传相关的流程修改指令，以使流程引擎根据修改指令自动进行流程的修改，并且将业务数据直接流转至第一个未审批的流程节点中，无需重新进行审批，使得流程修改更加灵活，进而提高业务流程流转速度及审批效率。

在本申请实施例中，基于链表实现的业务流程存储控制能让使用方绕过通过传统的提前绘制好流程流转图模型的方式来将流程实例化并运行流程。

具体地，使用方可以通过使用方终端上传符合本流程引擎规定的json化链表结构实体，来促使本流程引擎反解析json化链表结构实体，确定流程数据，其中，流程数据至少包括流程节点、审批人、审批类型。进一步地，对流程数据进行流程实例化，得到第一业务流程。实例化后的流程，会从初始节点开始，通过各个节点的状态变更，来层层推进流程节点的运行，最后让第一业务流程运行到终态。

202、对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则。

在本申请实施例中，开发人员可以基于使用方终端发起流程修改指令对已经设定好的第一业务流程进行修改。流程引擎响应于使用方终端发起的流程修改指令，对流程修改指令进行识别，在修改流程指令中读取至少一个需要进行修改的目标流程节点以及待修改规则，其中，待修改规则中存储有本次修改的内容，对目标流程节点一一对应。需要说明的是，使用方终端可以是电脑、平板、手机等带有显示屏的智能设备，本申请对使用方终端设备不进行具体限定。

在实际应用过程中，流程引擎首先基于自然语言处理技术对流程修改指令进行识别，获取流程修改指令中指示的至少一个节点标识和待修改规则。随后，在第一业务流程中，查询至少一个节点标识对应的目标流程节点，得到至少一个目标流程节点。

例如，基于自然语言处理技术，对流程修改指令进行识别，确定流程修改指令中指示待修改的目标节点为c节点、e节点、f节点。待修改规则中指示，c节点的审批人为甲乙，审批类型为并行，e节点的审批类型为并行，f节点的审批人为群组01，审批类型为协同。进一步地，流程引擎在第一业务流程中确定c节点、e节点、f节点作为至少一个目标节点。

203、对于至少一个目标流程节点中的每个目标流程节点，在待修改规则中，查询目标流程节点对应的修改内容，按照修改内容，在第一业务流程中进行修改，得到至少一个第二审批规则。

在本申请实施例中，考虑到修改操作可能发生在审批流程执行过程中，故存在有正在执行的第一业务流程。流程引起在第一业务流程中查找至少一个目标流程节点对应的第一审批规则。再按照待修改规则对至少一个第一审批规则进行修改，得到至少一个第二审批规则。

在实际应用过程中，对于至少一个目标流程节点中的每个目标流程节点，在待修改规则中，查询目标流程节点对应的修改内容，修改内容至少包括审批人修改、审批类型修改其中之一。例如，待修改规则中指示，c节点的审批人为甲、乙，审批类型为协同，e节点的审批类型为并行，f节点的审批人为群组01，审批类型为并行。进一步地，流程引擎在第一业务流程中确定c节点、e节点、f节点作为至少一个目标节点。在实际用于过程中，当审批人离职或调岗等意外情况发生时，可以进行审批人的修改。具体地，当修改内容为审批人修改时，在第一审批规则中找到原审批人，将原审批人替换成修改内容中指示的目标审批人，得到第二审批规则。依旧以目标流程节点为c、e、f为例，流程引擎在第一业务流程中搜索c节点的第一审批规则，从中读取到原审批人为丙，即由丙进行单人审批，接下来根据待修改规则中指示的修改内容，将第一审批规则中的审批人替换为待修改规则中指示的甲、乙二人。

进一步地，为了保证审核的可靠性或提高审核的效率可以对流程节点的审核类型进行修改。具体地，当修改内容为审批类型修改时，在第一审批规则中删除原数据下发链条，按照修改内容指示的审批类型，绘制目标数据下发链条进行存储，得到第二审批规则，数据下发链条包括串行链条、并行链条、协同链条。依旧以目标流程节点c为例，流程节点c的第一审批规则是由丙进行串行链条审批，即业务数据发送给丙，丙审核通过后将业务数据流转至下一流程节点。规则修改后，审核人变为甲、乙二人，审核类型变为并行链条，此时业务数据会同时发送给甲、乙二人，当两人同时审批同意才会将业务数据流转至下一流程节点。

需要说明的是，审批类型可分为，串行、并行、协同三种。串行情况下，流程节点内部的人员按照串行顺序去依次分发审核任务，直至流程节点中所有审核人都审核通过后才会流转到下一流程节点。并行情况下会将审核任务同时分发到该流程节点下的所有审核人名下，之后当所有审核人都审核通过后才会流转到下个流程节点。协同情况下，会将审核任务同步分发到该流程节点下的所有审核人名下，当任意一个审核人审核后，都会推进流程到下一个流程节点。节点的审批人可分为单人或群组(群组内含有多人)，使用方提前配置好群组信息，在节点审核人员选择中就可以选择其所录入的群组，群组审批类型目前分为并行和协同两种。单个流程节点下既可以有单人，也可以有群组，并且群组与单人可相互转办。

204、将至少一个第二审批规则与待修改规则进行比对，基于比对结果，生成第二业务流程。

在本申请实施例中，流程引擎将至少一个第二审批规则与待修改规则进行比对，基于比对结果，确定审批规则是否修改成功。在确定修改成功后，将现在的业务流程作为第二业务流程。

具体地，分别将至少一个目标流程节点中的每个目标流程节点的第二审批规则与待修改内容中对应的修改内容进行比对，生成比对结果。若比对结果指示第二审批规则与对应的修改内容一致，则设置目标流程节点的节点状态为修改成功。若比对结果指示第二审批规则与对应的修改内容不一致，则生成修改失败提示信息，修改失败提示信息用于指示修改失败的指定流程节点，并触发重新发起对指定流程节点的修改指令，对修改失败的指定流程节点再次进行修改，直至修改成功。最后，对至少一个流程节点的节点状态进行识别，在全部流程节点的节点状态全部设置为修改成功时，结束对第一业务流程的修改，将修改完成的第一业务流程作为第二业务流程。

205、将业务数据发送至第二业务流程中第一个未完成的流程节点进行审批，直至第二业务流程中的最后一个流程节点审批结束。

在本申请实施例中，考虑到修改前的第一业务流程中部分流程节点的审批状态为审批完成。因此，为了提高审批效率，流程引擎会将审批完成的流程节点的审批状态同步至第二业务流程，并将业务数据发送至第二业务流程中第一个未完成的流程节点进行审批。在审批完成后，将业务数据流转至下一个流程节点，直至第二业务流程中存储的最后一个流程节点完成审批。依旧以目标流程节点为c、e、f为例，第一业务流程中存在a、b、c、d、e、f六个流程节点，对c、e、f节点修改后，第二业务流程依旧是六个流程节点。第一业务流程中a、b、c流程节点的节点状态为审批完成，此时将业务数据流转至d节点，采用第二业务流程中的审批规则对业务数据进行审批。

另外，对于第一业务流程中的每个流程节点，当流程节点开启接收到业务数据后，识别流程节点对应的邮件通知名单，将流程提醒发送至邮件通知名单指示的邮箱地址。具体地，邮件提醒包括待办提醒，事件跟踪提醒等，当某人名下有新的审核任务时会基于设置的待办开关来决定是否发送待办提醒邮件。当事件流转(通过、转办、作废等)步骤发生时根据流程节点对应的邮件通知名单发送事件跟踪提醒邮件。还可以设置邮件额外通知人，当一个事件需要通知流程流转流程外的人员时，通过配置邮件额外通知人，来让相关人员收到邮件提醒。

在实际应用过程中，使用方还可以发起流程升降级指令对第一业务流程进行流程升降级。具体地，响应于使用方终端发送流程升降级指令，获取第三业务流程和流程映射表，在流程映射表中查询第一指定节点对应的第二指定节点，在第三业务流程中，将第二指定节点设置为审批完成，并将业务数据发送至第三业务流程中第一个未完成的流程节点进行审批，直至第三业务流程中的最后一个流程节点审批结束，第一指定节点用于指示第一业务流程中已完成审批的流程节点。例如，A流程有a-b-c三个流程节点，B流程有a-b-c-d-e五个流程节点，使用方提前定义好A、B流程的节点映射关系，即流程映射表。在A流程运行过程中可以进行流程升级，升级后A流程实例会变成B流程所定义的五个流程节点。同时基于先前定义的映射关系，将A流程中已流转的审批状态同步到新流程中，即若A流程中a-b-c流程节点已审批，升级后只需要d-e流程节点再进行审批即可。

本实施例提供的业务流程控制方法，对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则。随后，在第一业务流程中，按照待修改规则，修改至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，将至少一个第二审批规则与待修改规则进行比对。接下来，基于比对结果，结束对第一业务流程的修改，将结束修改的第一业务流程作为第二业务流程。最后，将业务数据发送至第二业务流程中第一个未完成的流程节点进行审批，直至第二业务流程中的最后一个流程节点审批结束。管理人员在业务审批过程中如果发现业务审批流程产生意外情况，可以通过使用方终端上传相关的流程修改指令，以使流程引擎根据修改指令自动进行流程的修改，并且将业务数据直接流转至第一个未审批的流程节点中，无需重新进行审批，使得流程修改更加灵活，进而提高业务流程流转速度及审批效率。

进一步的，作为图1、图2所示方法的具体实现，本实施例提供了一种业务流程控制装置，如图3A所示，该装置包括：识别模块301、修改模块302、比对模块303、审批模块304。

该识别模块301，用于对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则；

该修改模块302，用于在第一业务流程中，按照所述待修改规则，修改所述至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，所述第一业务流程用于指示原始业务流程，所述第一审批规则用于指示在所述第一业务流程中存储的原始审批规则；

该比对模块303，用于将所述至少一个第二审批规则与所述待修改规则进行比对，基于比对结果，生成第二业务流程，所述第二业务流程用于指示结束修改的第一业务流程；

该审批模块304，用于将业务数据发送至所述第二业务流程中第一个未完成的流程节点进行审批，直至所述第二业务流程中的最后一个流程节点审批结束。

在具体的应用场景中，该修改模块302，用于对于所述至少一个目标流程节点中的每个目标流程节点，在所述待修改规则中，查询所述目标流程节点对应的修改内容，所述修改内容至少包括审批人修改或审批类型；当所述修改内容为审批人修改时，在所述第一审批规则中找到原审批人，将所述原审批人替换成所述修改内容中指示的目标审批人，得到所述第二审批规则；当所述修改内容为审批类型修改时，在所述第一审批规则中删除原数据下发链条，按照所述修改内容指示的审批类型，绘制目标数据下发链条进行存储，得到所述第二审批规则，所述数据下发链条包括串行链条、并行链条、协同链条。

在具体的应用场景中，该比对模块303，用于分别将所述至少一个目标流程节点中的每个目标流程节点的第二审批规则与所述待修改内容中对应的修改内容进行比对，生成比对结果；若所述比对结果指示所述第二审批规则与对应的修改内容一致，则设置所述目标流程节点的节点状态为修改成功，在所述至少一个流程节点的节点状态全部设置为修改成功时，结束对所述第一业务流程的修改，将结束修改的第一业务流程作为所述第二业务流程；若所述比对结果指示所述第二审批规则与对应的修改内容不一致，则生成修改失败提示信息，所述修改失败提示信息用于指示修改失败的指定流程节点，并触发重新发起对所述指定流程节点的修改指令，对所述指令流程节点进行修改，直至所述指定流程节点的节点状态设置为修改成功，结束对所述第一业务流程的修改，将结束修改的第一业务流程作为所述第二业务流程。

在具体的应用场景中，如图3B所示，所述装置还包括：接收模块305、获取模块306。

该接收模块305，用于接收所述使用方终端发送的链表结构实体，对所述链表结构实体进行反解析，确定流程数据，所述流程数据至少包括流程节点、审批人、审批类型；

该获取模块306，用于对所述流程数据进行实例化，得到所述第一业务流程；

该审批模块304，还用于采用所述第一业务流程进行所述业务数据的审批。

在具体的应用场景中，该识别模块301，用于基于自然语言处理技术对所述流程修改指令进行识别，获取所述流程修改指令中指示的所述至少一个节点标识和所述待修改规则；在所述第一业务流程中，查询所述至少一个节点标识对应的目标流程节点，得到所述至少一个目标流程节点。

在具体的应用场景中，该审批模块304，用于将所述业务数据发送至所述第二业务流程中第一个未完成的流程节点，按照所述流程节点对应的审批规则对所述业务数据进行审批；在审批完成后，将所述业务数据流转至下一流程节点进行审批，直至所述第二业务流程中的最后一个流程节点审批结束。

在具体的应用场景中，如图3C所示，所述装置还包括：发送模块307、升降级模块308。

该发送模块307，用于对于所述第一业务流程中的每个流程节点，当所述流程节点开启接收到所述业务数据后，识别所述流程节点对应的邮件通知名单，将流程提醒发送至所述邮件通知名单指示的邮箱地址；和/或，

该升降级模块308，用于响应于使用方终端发送流程升降级指令，获取第三业务流程和流程映射表，在所述流程映射表中查询第一指定节点对应的第二指定节点，在所述第三业务流程中，将所述第二指定节点设置为审批完成，并将所述业务数据发送至所述第三业务流程中第一个未完成的流程节点进行审批，直至所述第三业务流程中的最后一个流程节点审批结束，所述第一指定节点用于指示所述第一业务流程中已完成审批的流程节点。

本申请实施例提供的装置，可以对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则。随后，在第一业务流程中，按照待修改规则，修改至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，将至少一个第二审批规则与待修改规则进行比对。接下来，基于比对结果，结束对第一业务流程的修改，将结束修改的第一业务流程作为第二业务流程。最后，将业务数据发送至第二业务流程中第一个未完成的流程节点进行审批，直至第二业务流程中的最后一个流程节点审批结束。管理人员在业务审批过程中如果发现业务审批流程产生意外情况，可以通过使用方终端上传相关的流程修改指令，以使流程引擎根据修改指令自动进行流程的修改，并且将业务数据直接流转至第一个未审批的流程节点中，无需重新进行审批，使得流程修改更加灵活，进而提高业务流程流转速度及审批效率。

需要说明的是，本实施例提供的一种业务流程控制装置所涉及各功能单元的其它相应描述，可以参考图1、图2中的对应描述，在此不再赘述。

在示例性实施例中，参见图4，还提供了一种设备，该设备包括通信总线、处理器、存储器和通信接口，还可以包括输入输出接口和显示设备，其中，各个功能单元之间可以通过总线完成相互间的通信。该存储器存储有计算机程序，处理器，用于执行存储器上所存放的程序，执行上述实施例中的业务流程控制方法。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现所述的业务流程控制方法的步骤。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种业务流程控制方法，其特征在于，包括：

对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则；

在第一业务流程中，按照所述待修改规则，修改所述至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，所述第一业务流程用于指示原始业务流程，所述第一审批规则用于指示在所述第一业务流程中存储的原始审批规则；

将所述至少一个第二审批规则与所述待修改规则进行比对，基于比对结果，生成第二业务流程，所述第二业务流程用于指示结束修改的第一业务流程；

将业务数据发送至所述第二业务流程中第一个未完成的流程节点进行审批，直至所述第二业务流程中的最后一个流程节点审批结束。

2.根据权利要求1所述的方法，其特征在于，所述按照所述待修改规则，修改所述至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，包括：

对于所述至少一个目标流程节点中的每个目标流程节点，在所述待修改规则中，查询所述目标流程节点对应的修改内容，所述修改内容至少包括审批人修改或审批类型；

当所述修改内容为审批人修改时，在所述第一审批规则中找到原审批人，将所述原审批人替换成所述修改内容中指示的目标审批人，得到所述第二审批规则；

当所述修改内容为审批类型修改时，在所述第一审批规则中删除原数据下发链条，按照所述修改内容指示的审批类型，绘制目标数据下发链条进行存储，得到所述第二审批规则，所述数据下发链条包括串行链条、并行链条、协同链条。

3.根据权利要求1所述的方法，其特征在于，所述将所述至少一个第二审批规则与所述待修改规则进行比对，基于比对结果，生成第二业务流程，包括：

分别将所述至少一个目标流程节点中的每个目标流程节点的第二审批规则与所述待修改内容中对应的修改内容进行比对，生成比对结果；

若所述比对结果指示所述第二审批规则与对应的修改内容一致，则设置所述目标流程节点的节点状态为修改成功，在所述至少一个流程节点的节点状态全部设置为修改成功时，结束对所述第一业务流程的修改，将结束修改的第一业务流程作为所述第二业务流程；

若所述比对结果指示所述第二审批规则与对应的修改内容不一致，则生成修改失败提示信息，所述修改失败提示信息用于指示修改失败的指定流程节点，并触发重新发起对所述指定流程节点的修改指令，对所述指令流程节点进行修改，直至所述指定流程节点的节点状态设置为修改成功，结束对所述第一业务流程的修改，将结束修改的第一业务流程作为所述第二业务流程。

4.根据权利要求1所述的方法，其特征在于，所述对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则之前，所述方法还包括：

接收所述使用方终端发送的链表结构实体，对所述链表结构实体进行反解析，确定流程数据，所述流程数据至少包括流程节点、审批人、审批类型；

对所述流程数据进行实例化，得到所述第一业务流程；

采用所述第一业务流程进行所述业务数据的审批。

5.根据权利要求1所述的方法，其特征在于，所述对所述流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则，包括：

基于自然语言处理技术对所述流程修改指令进行识别，获取所述流程修改指令中指示的所述至少一个节点标识和所述待修改规则；

在所述第一业务流程中，查询所述至少一个节点标识对应的目标流程节点，得到所述至少一个目标流程节点。

6.根据权利要求1所述的方法，其特征在于，所述将业务数据发送至所述第二业务流程中第一个未完成的流程节点进行审批，直至所述第二业务流程中的最后一个流程节点审批结束，包括：

将所述业务数据发送至所述第二业务流程中第一个未完成的流程节点，按照所述流程节点对应的审批规则对所述业务数据进行审批；

在审批完成后，将所述业务数据流转至下一流程节点进行审批，直至所述第二业务流程中的最后一个流程节点审批结束。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

对于所述第一业务流程中的每个流程节点，当所述流程节点开启接收到所述业务数据后，识别所述流程节点对应的邮件通知名单，将流程提醒发送至所述邮件通知名单指示的邮箱地址；和/或，

响应于使用方终端发送流程升降级指令，获取第三业务流程和流程映射表，在所述流程映射表中查询第一指定节点对应的第二指定节点，在所述第三业务流程中，将所述第二指定节点设置为审批完成，并将所述业务数据发送至所述第三业务流程中第一个未完成的流程节点进行审批，直至所述第三业务流程中的最后一个流程节点审批结束，所述第一指定节点用于指示所述第一业务流程中已完成审批的流程节点。

8.一种业务流程控制装置，其特征在于，包括：

识别模块，用于对接收到的流程修改指令进行识别，确定至少一个目标流程节点以及待修改规则；

修改模块，用于在第一业务流程中，按照所述待修改规则，修改所述至少一个目标流程节点对应的第一审批规则，得到至少一个第二审批规则，所述第一业务流程用于指示原始业务流程，所述第一审批规则用于指示在所述第一业务流程中存储的原始审批规则；

比对模块，用于将所述至少一个第二审批规则与所述待修改规则进行比对，基于比对结果，生成第二业务流程，所述第二业务流程用于指示结束修改的第一业务流程；

审批模块，用于将业务数据发送至所述第二业务流程中第一个未完成的流程节点进行审批，直至所述第二业务流程中的最后一个流程节点审批结束。

9.一种计算机存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。

10.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。

Images