CN112732432A - 一种跨应用的工作流处理方法 - Google Patents

Abstract

本发明涉及信息技术领域，提供了一种跨应用的工作流处理方法。主旨在于解决微服务系统中跨应用的工作流应用和节点之间传输、共享数据问题。主要方案包括，工作流微服务管理节点将管理该微服务系统中其他所有微服务应用节点的工作流相关的工作量调度和流程处理；当用户在各个微服务应用节点上对流程进行操作后，工作流微服务管理节点会将新的流程定义文件在微服务系统中进行广播；工作流微服务管理节点为微服务应用节点提供的流程引擎会自动将上一个微服务应用节点的工作流节点的任务数据传输至下一个微服务应用节点的对应的工作流节点，然后所述的下一微服务应用节点的流程引擎进行工作流任务的处理。

Description

一种跨应用的工作流处理方法

技术领域

本发明涉及信息技术领域，提供了一种跨应用的工作流处理方法。

背景技术

传统的工作流平台致力于解决单个应用内流程流转和流程控制问题，其提供一套基于本地的工作流开发组件，开发完成的工作流定义文件以及节点数据均保存在应用本地的数据库。流程触发和流转时，本地的工作流引擎会读取本地数据库的流程定义文件进行流程控制、节点之间的数据也是通过本地应用进行传输。

传统方法的不足，传统的工作流平台技术只能服务于单个应用本身，不支持跨应用的工作流。当前银行IT建设紧随互联网技术的脚本在发展，微服务架构在银行也得到广泛应用，以贷款业务为例，在传统的流程中，贷款的授信审批、合同审批、放款审批均在一个系统中完成，因此传统的工作流技术可以较好的解决工作流方面的问题。但是，在微服务架构中，随着应用的服务拆分，贷款的授信审批、合同审批、放款审批被放到不同的应用中来处理，针对这种场景，由于传统的工作流技术将流程文件和流程节点中间数据均封装在应用本身，无法通过微服务的注册中心等组件在不同的应用和节点之间传输、共享数据，所以其本身无法很好的适用于以上微服务的场景。

发明内容

本发明的主旨在于解决微服务系统中跨应用的工作流应用和节点之间传输、共享数据问题。

为解决上述技术问题，本发明采用以下技术方案：

一种跨应用的工作流处理方法，包括以下步骤：

步骤1：在微服务系统中部署一个单独的工作流微服务管理节点，该工作流微服务管理节点将管理该微服务系统中其他所有微服务应用节点的工作流相关的工作量调度和流程处理；

步骤2：当用户在工作流微服务管理节点上对流程进行新增、修改、删除动作后，工作流微服务管理节点会将新的流程定义文件在微服务系统中进行广播，由其他微服务应用节点进行接收和处理；

步骤3：对于微服务应用节点的工作流，工作流微服务管理节点为微服务应用节点提供的流程引擎会自动将上一个微服务应用节点的工作流节点的任务数据传输至下一个微服务应用节点的对应的工作流节点，然后所述的下一微服务应用节点的流程引擎进行工作流任务的处理；

步骤4：各个微服务应用节点处理完工作流后，流程引擎会将相关状态异步发送给工作流微服务管理节点，工作流微服务管理节点收集到工作流状态后进行整理存档，用户可以在工作流微服务管理节点对流程进行事后回溯和实时监控。

上述技术方案中，步骤1具体包括：

步骤1.1：工作流微服务管理节点作为一个单独的服务发布到微服务系统，同时将该服务注册到微服务的注册中心，用于工作流服务查找和调用;

该工作流微服务管理节点实现如下：

1.1.1.统一管理工作流流程定义和节点规则设置视图，统一存储和管理流程定义文件；

工作流微服务管理节点提供独立的web管理台，用户在管理台通过拖拽、修改配置的方式来配置工作流，配置时需要设置各个工作流节点的调用逻辑和各个工作流节点所在的服务名；配置完成后工作流微服务管理节点会生成流程定义文件；流程定义文件创建成功后首先会保存在工作流微服务管理节点的内存数据库中，然后再同步给相关的微服务应用节点；

1.1.2 使用主从模式部署：

工作流微服务应用节点采用多节点部署，各个节点之间通过选举算法确定一个工作流主节点，同一时间只有工作流主节点在提供服务，当工作流主节点出现故障时会重新选举另外一个工作流子节点作为工作流主节点；

1.1.3.使用redis作为分布式内存数据库，在工作流定义完成之后，将流程定义文件序列化后保存在redis中，以提高流程文件同步的效率；

步骤1.2：工作流微服务管理节点将流程引擎的流程同步、流程监控方法打包成jar文件，供给其他服务进行调用。

上述技术方案中，对于修改操作，工作流微服务管理节点会记录相应的版本号，然后将最新的流程定义文件同步给相关的微服务应用节点。

对于删除操作，工作流微服务管理节点不会删除该流程定义文件，而是将其打一个标志，置为“无效”，然后将对应的状态同步到相关的微服务应用节点。

上述技术方案中，步骤2具体包括以下步骤：

步骤2.1：在各个微服务应用节点中集成工作流微服务管理节点提供的jar包，jar包中的主要方法类我们称之为流程引擎，流程引擎提供流程文件同步、流程文件解析、流程启动、流程转发、流程状态同步功能，当各个微服务应用节点启动后将去注册中心查找工作流微服务管理节点的服务，流程引擎会从工作流微服务管理节点同步流程定义文件至本地内存，然后将流程文件解析成内部对象，我们称之为流程定义对象，其包含了该流程文件中定义的各种细节，方便后续的流程流转工作的处理；

步骤2.2：各个微服务应用节点在工作流的开始的节点调用流程引擎的流程启动方法，当工作流的开始节点执行完成后流程引擎会根据流程定义对象将流程转发给后续节点处理。

步骤2.3：当用户在工作流微服务管理节点上对流程进行新增、修改、删除动作后，工作流微服务管理节点会将新的流程定义文件在微服务系统中进行广播，由其他微服务应用节点进行接收和处理。

上述技术方案中，流程定义文件存在修改和删除，则该微服务应用节点在流程文件同步成功之后会在本地内存存在多个流程定义对象，启动流程时流程引擎会默认根据流程id查找版本号最新的流程定义文件来发起流程，同时该流程的版本号会和流程id一起作为节点数据同步给下一个工作流节点；

对于置为失效的流程定义文件，若用户调用相关的流程启动的方法，流程引擎会抛出异常，流程发起失败；

在下一工作流节点，流程引擎会根据流程id和版本号一起查找对应的流程，也就是说，对于在已经发起之后再修改和删除的流程，流程引擎会根据发起时的流程id和版本号找到对应的流程进行处理，直到流程终止。

上述技术方案中，在配置工作流时，用户可以设置各个工作流节点是自动处理还是需要手工处理：对于自动处理的工作流节点，各个微服务应用节点中的流程引擎会自动触发工作流节点的方法执行；

对于自动处理的工作流节点，工作流节点之间的数据直接通过工作流引擎的上下文信息进行传递，对于人工干预的节点，则需要先将节点数据保存到数据库介质待处理人调用时在初始化对应工作流节点数据。

上述技术方案中，对于需要人工处理的工作流节点，在流程定义文件中配置查找用户或角色的方法，用来确定该任务应该由谁进行处理，然后由对应的微服务应用节点在处理用户操作的程序中先调用流程引擎的获取任务数据方法来查询和展示流程中的业务数据，在用户处理完成点击提交后，在微服务应用节点中调用流程引擎的提交方法，然后由流程引擎根据流程定义文件将流程转发到下一工作流节点处理；

对于需要自动处理的工作流节点，在流程定义文件中需要配置任务处理的方法。当流程流转到此工作流节点后，流程引擎根据流程定义文件的描述识别其为自动处理任务后会自动调用该处配置的方法，并在方法执行完成之后交工作流的流程流转至下一工作流节点。

上述技术方案中，步骤3.1：在每一个工作流节点处理完成后，需要在节点处理的代码中显式调用流程引擎的静态方法void ProcessEngine.putLocalthreadVal(HashMapmp)方法，该方法的作用是将当前节点的业务数据保存在执行环境的上下文中，在下一个工作流节点通过显示调用HashMap ProcessEngine.getLocalthreadVal()可以获取到上一节点保存的业务数据。

上述技术方案中，3.1.1如果下一工作流节点是自动运行节点，流程引擎会将业务数据保存在本地内存中，当前工作流节点调用HashMapProcessEngine.getLocalthreadVal()则直接从本地内存获取数据；

3.1.2如果下一工作流节点是手工运行节点，流程引擎会将业务数据序列化后保存到数据库，并释放掉本地内存的数据，当处理人手工处理时，程序调用HashMapProcessEngine.getLocalthreadVal()时流程引擎会自动从数据库中对业务数据反序列化到内存然后再进行处理；

3.1.3如果下一任务节点在其他微服务应用节点中，则流程引擎会将本地的业务数据发送至对方微服务应用节点的流程引擎，对方微服务应用节点的流程引擎在根据流程定义文件的描述来确定下一步的工作：如果下一节点是自动任务则直接调用；如果是手工任务，则先序列化保存至数据库。

上述技术方案中，步骤4具体包括以下步骤：

步骤4.1：各个微服务应用节点的流程引擎在节点任务处理完成之后，会将状态数据异步发送给工作流微服务管理节点进行记录；

步骤4.2：工作流微服务管理节点实时接收和整理各个微服务应用节点的流程处理状态，最终生成每个工作流的流程的流转状态，其中包括任务名称、每个实际处理节点所在的微服务应用节点、IP、流程处理开始时间、流程处理结束时间、任务处理人信息，监控到每个流程的处理状态和当前所在的节点，实现用户进行流程查找、状态监控和问题排查。

因为本发明采用上述技术方案，因此具备以下有益效果：

1、本发明支持跨应用的工作流流程控制。传统的工作流平台只能支持单个应用中的流程定义和流程控制，本发明的工作流平台可以跨服务应用。

2、通过将工作流平台的流程引擎进行封装，提供给用户统一的、简单的API，方便业务系统的使用。

3、通过微服务技术实现流程定义文件的分发和流程状态收集，可以在应用系统不重启服务的情况下实时同步流程定义文件，满足在微服务框架中应用发布和监控的需求。

4、本发明并能够实时将新的流程定义文件同步到应用服务中。能够联合多个系统共同完成一个流程的控制。采用流程状态收集技术，将各个应用的流程处理信息统一同步到工作流平台，通过工作流平台可以监控到工作流每个任务在那个服务的那个节点运行以及运行的状态等。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明，即所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。

本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，术语“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本发明提供了一种跨应用的工作流处理方法，该平台支持跨应用的工作流调用，比如一个工作流需要经过SERVICE_A,SERVICE_B两个应用，该流程在SERVICE_A中走完T1，T2两个节点后需要走到SERVICE_B的T3、T4两个节点，本发明使用以下步骤实现该场景：

步骤1：在微服务系统中部署一个单独的工作流微服务管理节点，该工作流微服务管理节点将管理该微服务系统中其他所有微服务应用节点的工作流相关的工作量调度和流程处理；

步骤2：当用户在各个微服务应用节点上对流程进行新增、修改、删除动作后，工作流微服务管理节点会将新的流程定义文件在微服务系统中进行广播，由其他微服务应用节点进行接收和处理；

步骤3：对于微服务应用节点的工作流，工作流微服务管理节点为微服务应用节点A提供的流程引擎会自动将上一个微服务应用节点A的工作流节点的任务数据传输至下一个微服务应用节点B的对应的工作流节点，然后调用微服务应用节点B的流程引擎进行工作流任务的处理，其中节点A和节点B中的A，B仅仅用于区分两个不同的微服务应用节点，无其他具体含义；

步骤4：各个微服务应用节点处理完工作流后，流程引擎会将相关状态异步发送给工作流微服务管理节点，工作流微服务管理节点收集到工作流状态后进行整理存档，用户可以在工作流微服务管理节点对流程进行事后回溯和实时监控。

上述步骤1具体包括以下步骤：

步骤1.1：工作流微服务管理节点作为一个单独的服务发布到微服务系统，同时将该服务注册到微服务的注册中心，用于工作流服务查找和调用，该工作流微服务管理节点具有如下特点：

（1）统一管理工作流流程定义和节点规则设置视图，统一存储和管理流程定义文件；

工作流微服务管理节点提供独立的web管理台，用户在管理台通过拖拽、修改配置的方式来配置工作流，配置时需要设置各个工作流节点的调用逻辑和各个工作流节点所在的服务名；配置完成后工作流微服务管理节点会生成流程定义文件，该文件本质上是一个xml格式的文件。该文件创建成功后首先会保存在工作流微服务管理节点的内存数据库中，然后再同步给相关的微服务应用节点。比如某一工作流涉及的应用包括服务A和服务B，则该流程定义文件只会同步给A和B，不会同步到其他的服务节点。

对于修改操作，工作流微服务管理节点会记录相应的版本号，然后将最新的流程定义文件同步给相关的微服务应用节点。

对于删除操作，工作流微服务管理节点不会删除该流程定义文件，而是将其打一个标志，置为“无效”，然后将对应的状态同步到相关的微服务应用节点。

（2）使用主从模式部署：

工作流微服务应用节点采用多节点部署，各个节点之间通过选举算法确定一个工作流主节点，同一时间只有工作流主节点在提供服务，当工作流主节点出现故障时会重新选举另外一个工作流子节点作为工作流主节点；

（3）使用redis作为分布式内存数据库，在工作流定义完成之后，将流程定义文件序列化后保存在redis中，以提高流程文件同步的效率；

步骤1.2：工作流平台将流程引擎的流程同步、流程监控方法打包成jar文件，供给其他服务进行调用；

步骤2具体包括以下步骤：

步骤2.1：在各个微服务应用节点中集成工作流微服务管理节点提供的jar包，jar包中的主要方法类我们称之为流程引擎，流程引擎提供流程文件同步、流程文件解析、流程启动、流程转发、流程状态同步功能，当各个微服务应用节点启动后将去注册中心查找工作流微服务管理节点的服务，流程引擎会从工作流微服务管理节点同步流程定义文件至本地内存，然后将流程文件解析成内部对象，我们称之为流程定义对象，其包含了该流程文件中定义的各种细节，方便后续的流程流转工作的处理；

步骤2.2：各个微服务应用节点在工作流的开始的节点调用流程引擎的流程启动方法，当工作流的开始节点执行完成后流程引擎会根据流程定义对象将流程转发给后续节点处理。

如前所示，流程定义文件存在修改和删除的场景。对于流程文件修改的场景，则该微服务应用节点在流程文件同步成功之后会在本地内存存在多个流程定义对象，启动流程时流程引擎会默认根据流程id查找版本号最新的流程定义文件来发起流程，同时该流程的版本号会和流程id一起作为节点数据同步给下一个工作流节点；

对于置为失效的流程定义文件，若用户调用相关的流程启动的方法，流程引擎会抛出异常，流程发起失败。

在下一工作流节点，流程引擎会根据流程id和版本号一起查找对应的流程，也就是说，对于在已经发起之后再修改和删除的流程，流程引擎会根据发起时的流程id和版本号找到对应的流程进行处理，直到流程终止。不会因为流程定义文件中途发生变化而导致流程错乱。

在配置工作流时，用户可以设置各个工作流节点是自动处理还是需要手工处理：对于自动处理的工作流节点，各个微服务应用节点中的流程引擎会自动触发工作流节点的方法执行；

在工作流的节点执行的方法分两种类型：（1）指定class文件中的静态方法（2）指定spring容器中的bean的方法。对于类型1，如（ClassX.executeTask()），实现原理为流程引擎通过反射的方式，先获取相应的类“ClassX”，然后再调用对应的方法“executeTask()”，对于类型2,如(#bean1)，则流程引擎会通过名称在容器中查到到相应的bean实例，然后再调用该bean的的方法，在此处无需指定bean的方法，流程引擎会基于bean继承的接口来调用特定的方法。

如果工作流的节点需要手工，则将工作流的的开始节点的数据保存到数据库中，等待特定的用户进行处理，此处有如下细节：

（1）对于自运行的工作流节点，工作流节点之间的数据直接通过工作流引擎的上下文信息进行传递，对于人工干预的节点，则需要先将节点数据保存到数据库介质待处理人调用时在初始化对应工作流节点数据。

（2）对于分表分库的微服务应用节点，需要设置将工作流节点的数据保存到公共的微服务数据库中，这样可以避免用户登陆微服务应用节点的不同而查询不到任务数据；

（3）流程引擎提供了消息通知的钩子函数的接口，比如希望当流程到达某个用户处理时，可以实现短信通知的功能。则可以继承相应的接口，实现发送短信的逻辑，流程引擎在任务到达时会调用该方法来发送短信。

（4）对于人工处理的工作流的节点必须要在流程定义文件中指定任务的处理人，由于不同的微服务之间用户和角色设置可能不同，因此工作流微服务管理节点提供了一种更通用的方式来确定流程的接收人：在流程引擎中定义一个用户查找的接口UserFinderInterface，该接口有唯一方法“defineProccer”由各个微服务应用节点对其实现，在流程定义文件中配置该接口的实现类（如UserRoleDefine）。当任务通过工作流流转到对应工作流节点时，工作引擎会根据流程定义文件的配置调用UserRoleDefine的方法，然后根据方法的返回值来确定任务的处理人。

通过上述描述可以看出：

（1）对于需要人工处理的工作流节点，在流程定义文件中配置查找用户或角色的方法，用来确定该任务应该由谁进行处理，然后由对应的微服务应用节点在处理用户操作的程序中先调用流程引擎的获取任务数据方法来查询和展示流程中的业务数据，在用户处理完成点击提交后，在微服务应用节点中调用流程引擎的提交方法，然后由流程引擎根据流程定义文件将流程转发到下一工作流节点处理。

（2）对于需求自动处理的工作流节点，在流程定义文件中需要配置任务处理的方法。当流程流转到此工作流节点后，流程引擎根据流程定义文件的描述识别其为自动处理任务后会自动调用该处配置的方法，并在方法执行完成之后交工作流的流程流转至下一工作流节点。

步骤3具体包括以下步骤：

步骤3.1：在每一个工作流节点处理完成后，需要在节点处理的代码中显式调用流程引擎的静态方法void ProcessEngine.putLocalthreadVal(HashMap mp)方法，该方法的作用是将当前节点的业务数据保存在执行环境的上下文中，在下一个工作流节点通过显示调用HashMap ProcessEngine.getLocalthreadVal()可以获取到上一节点保存的业务数据，其具体细节如下：

（1）如果下一工作流节点是自动运行节点，流程引擎会将业务数据保存在本地内存中，当前工作流节点调用HashMap ProcessEngine.getLocalthreadVal()则直接从本地内存获取数据。

（2）如果下一工作流节点是手工运行节点，流程引擎会将业务数据序列化后保存到数据库，并释放掉本地内存的数据，当处理人手工处理时，程序调用HashMapProcessEngine.getLocalthreadVal()时流程引擎会自动从数据库中对业务数据反序列化到内存然后再进行处理。

（3）如果下一任务节点在其他微服务应用节点中，则流程引擎会将本地的业务数据发送至对方微服务应用节点的流程引擎，对方微服务应用节点的流程引擎在根据流程定义文件的描述来确定下一步的工作：如果下一节点是自动任务则直接调用；如果是手工任务，则先序列化保存至数据库。

步骤4具体包括以下步骤：

步骤4.1：各个微服务应用节点的流程引擎在节点任务处理完成之后，会将状态数据异步发送给工作流微服务管理节点进行记录；

步骤4.2：工作流微服务管理节点实时接收和整理各个微服务应用节点的流程处理状态，最终生成每个工作流的流程的流转状态，其中包括任务名称、每个实际处理节点所在的微服务应用节点、IP、流程处理开始时间、流程处理结束时间、任务处理人信息，监控到每个流程的处理状态和当前所在的节点，实现用户进行流程查找、状态监控和问题排查。

Claims (9)

1.一种跨应用的工作流处理方法，其特征在于，包括以下步骤：

步骤1：在微服务系统中部署一个单独的工作流微服务管理节点，该工作流微服务管理节点将管理该微服务系统中其他所有微服务应用节点的工作流相关的工作量调度和流程处理；

步骤2：当用户在各个微服务应用节点上对流程进行新增、修改、删除动作后，工作流微服务管理节点会将新的流程定义文件在微服务系统中进行广播，由其他微服务应用节点进行接收和处理；

步骤3：对于微服务应用节点的工作流，工作流微服务管理节点为微服务应用节点提供的流程引擎会自动将上一个微服务应用节点的工作流节点的任务数据传输至下一个微服务应用节点的对应的工作流节点，然后所述的下一微服务应用节点的流程引擎进行工作流任务的处理；

步骤4：各个微服务应用节点处理完工作流后，流程引擎会将相关状态异步发送给工作流微服务管理节点，工作流微服务管理节点收集到工作流状态后进行整理存档，用户可以在工作流微服务管理节点对流程进行事后回溯和实时监控；

步骤2具体包括以下步骤：

步骤2.1：在各个微服务应用节点中集成工作流微服务管理节点提供的jar包，jar包中的主要方法类称之为流程引擎，流程引擎提供流程文件同步、流程文件解析、流程启动、流程转发、流程状态同步功能，当各个微服务应用节点启动后将去注册中心查找工作流微服务管理节点的服务，流程引擎会从工作流微服务管理节点同步流程定义文件至本地内存，然后将流程文件解析成内部对象，我们称之为流程定义对象，其包含了该流程文件中定义的各种细节，方便后续的流程流转工作的处理；

步骤2.2：各个微服务应用节点在工作流的开始的节点调用流程引擎的流程启动方法，当工作流的开始节点执行完成后流程引擎会根据流程定义对象将流程转发给后续节点处理；

步骤2.3：当用户在工作流微服务管理节点上对流程进行新增、修改、删除动作后，工作流微服务管理节点会将新的流程定义文件在微服务系统中进行广播，由其他微服务应用节点进行接收和处理。

2.根据权利要求1所述的一种跨应用的工作流处理方法，其特征在于，

在配置工作流时，用户可以设置各个工作流节点是自动处理还是需要手工处理：对于自动处理的工作流节点，各个微服务应用节点中的流程引擎会自动触发工作流节点的方法执行；

对于自动处理的工作流节点，工作流节点之间的数据直接通过工作流引擎的上下文信息进行传递，对于人工干预的节点，则需要先将节点数据保存到数据库介质待处理人调用时在初始化对应工作流节点数据。

3.根据权利要求2所述的一种跨应用的工作流处理方法，其特征在于，对于需要人工处理的工作流节点，在流程定义文件中配置查找用户或角色的方法，用来确定该任务应该由谁进行处理，然后由对应的微服务应用节点在处理用户操作的程序中先调用流程引擎的获取任务数据方法来查询和展示流程中的业务数据，在用户处理完成点击提交后，在微服务应用节点中调用流程引擎的提交方法，然后由流程引擎根据流程定义文件将流程转发到下一工作流节点处理；

对于需要自动处理的工作流节点，在流程定义文件中需要配置任务处理的方法，当流程流转到此工作流节点后，流程引擎根据流程定义文件的描述识别其为自动处理任务后会自动调用该处配置的方法，并在方法执行完成之后交工作流的流程流转至下一工作流节点。

4.根据权利要求1所述的一种跨应用的工作流处理方法，其特征在于，步骤3.1：在每一个工作流节点处理完成后，需要在节点处理的代码中显式调用流程引擎的静态方法voidProcessEngine.putLocalthreadVal(HashMap mp)方法，该方法的作用是将当前节点的业务数据保存在执行环境的上下文中，在下一个工作流节点通过显示调用HashMapProcessEngine.getLocalthreadVal()可以获取到上一节点保存的业务数据。

5.根据权利要求4所述的一种跨应用的工作流处理方法，其特征在于：

3.1.1如果下一工作流节点是自动运行节点，流程引擎会将业务数据保存在本地内存中，当前工作流节点调用HashMap ProcessEngine.getLocalthreadVal()则直接从本地内存获取数据；

3.1.2如果下一工作流节点是手工运行节点，流程引擎会将业务数据序列化后保存到数据库，并释放掉本地内存的数据，当处理人手工处理时，程序调用HashMapProcessEngine.getLocalthreadVal()时流程引擎会自动从数据库中对业务数据反序列化到内存然后再进行处理；

3.1.3如果下一任务节点在其他微服务应用节点中，则流程引擎会将本地的业务数据发送至对方微服务应用节点的流程引擎，对方微服务应用节点的流程引擎在根据流程定义文件的描述来确定下一步的工作：如果下一节点是自动任务则直接调用；如果是手工任务，则先序列化保存至数据库。

6.根据权利要求1所述的一种跨应用的工作流处理方法，其特征在于：

步骤1.1：工作流微服务管理节点作为一个单独的服务发布到微服务系统，同时将该服务注册到微服务的注册中心，用于工作流服务查找和调用;

该工作流微服务管理节点实现如下：

1.1.1.统一管理工作流流程定义和节点规则设置视图，统一存储和管理流程定义文件；

工作流微服务管理节点提供独立的web管理台，用户在管理台通过拖拽、修改配置的方式来配置工作流，配置时需要设置各个工作流节点的调用逻辑和各个工作流节点所在的服务名；配置完成后工作流微服务管理节点会生成流程定义文件；流程定义文件创建成功后首先会保存在工作流微服务管理节点的内存数据库中，然后再同步给相关的微服务应用节点；

1.1.2 使用主从模式部署：

工作流微服务应用节点采用多节点部署，各个节点之间通过选举算法确定一个工作流主节点，同一时间只有工作流主节点在提供服务，当工作流主节点出现故障时会重新选举另外一个工作流子节点作为工作流主节点；

1.1.3.使用redis作为分布式内存数据库，在工作流定义完成之后，将流程定义文件序列化后保存在redis中，以提高流程文件同步的效率；

步骤1.2：工作流微服务管理节点将流程引擎的流程同步、流程监控方法打包成jar文件，供给其他服务进行调用。

7.根据权利要求1所述的一种跨应用的工作流处理方法，其特征在于：

对于修改操作，工作流微服务管理节点会记录相应的版本号，然后将最新的流程定义文件同步给相关的微服务应用节点；

对于删除操作，工作流微服务管理节点不会删除该流程定义文件，而是将其打一个标志，置为“无效”，然后将对应的状态同步到相关的微服务应用节点。

8.根据权利要求1所述的一种跨应用的工作流处理方法，其特征在于，

流程定义文件存在修改和删除，则该微服务应用节点在流程文件同步成功之后会在本地内存存在多个流程定义对象，启动流程时流程引擎会默认根据流程id查找版本号最新的流程定义文件来发起流程，同时该流程的版本号会和流程id一起作为节点数据同步给下一个工作流节点；

对于置为失效的流程定义文件，若用户调用相关的流程启动的方法，流程引擎会抛出异常，流程发起失败；

在下一工作流节点，流程引擎会根据流程id和版本号一起查找对应的流程，也就是说，对于在已经发起之后再修改和删除的流程，流程引擎会根据发起时的流程id和版本号找到对应的流程进行处理，直到流程终止。

9.根据权利要求4所述的一种跨应用的工作流处理方法，其特征在于：步骤4具体包括以下步骤：

步骤4.1：各个微服务应用节点的流程引擎在节点任务处理完成之后，会将状态数据异步发送给工作流微服务管理节点进行记录；

步骤4.2：工作流微服务管理节点实时接收和整理各个微服务应用节点的流程处理状态，最终生成每个工作流的流程的流转状态，其中包括任务名称、每个实际处理节点所在的微服务应用节点、IP、流程处理开始时间、流程处理结束时间、任务处理人信息，监控到每个流程的处理状态和当前所在的节点，实现用户进行流程查找、状态监控和问题排查。