CN102419833A - 工作流引擎***和工作流处理方法 - Google Patents

Abstract

一种工作流引擎***，包括***接口、请求受理模块和工作流处理模块，请求受理模块用于从所述***接口处接收工作流请求，并根据所述工作流请求生成对应的工作流处理消息以及请求处理完成消息；将请求处理完成消息返回请求用户；工作流处理模块，用于根据所述请求受理模块生成的工作流处理消息，运行相应的工作流处理流程。本发明还提供一种工作流处理方法。通过本发明将请求处理完成消息及时返回请求用户，能够有效缓解引擎***的调度拥塞；而且最终用户能够及时得到***的反馈，从而能够提高***使用上的性能体验。

Description

工作流引擎***和工作流处理方法

技术领域

本发明涉及通信和计算机领域，尤其涉及一种工作流处理技术。

背景技术

随着计算机技术、通信技术以及互联网技术的飞速发展，越来越要求企业对应用数据进行信息化管理。目前，在企业信息化管理应用数据时，离不开工作流引擎***。

随着信息化的不断深入，电信业务的不断扩大，信息***用户数激增，对基于工作流的应用***的性能提出更高的要求，同时也就对工作流引擎提出更高的要求。要求工作流引擎能够在上层应用***被大量并发用户访问时，能够并发的、准确的、高效的响应应用***的对象调用。也就是说，应用***的压力最终转化为对工作流引擎对象调用的压力。因此，工作流引擎的稳定性和时效性就成了决定工作流产品性能的关键因素。

传统工作流引擎***的逻辑结构示意图如图1所示，其主要包括：核心控制器10(有些也称为路由器)、流程模块20、表单模块30、接口业务服务实现模块40和公共模块50。

下面以工作流引擎***从服务接口(图中同步接口)接收到一个流转请求为例，对工作流引擎***的工作原理进行描述：

核心控制器10接收到流转请求后，先通过流程模块20中的流程定义管理构件查询该流程的完整定义，以确定其流转环节、关联表单和相关配置规则；

根据确定的关联表单，核心控制器10调用表单模块30中的各类构件完成表单的计算和数据保存；当涉及到对后端业务***服务调用时，核心控制器10根据业务数据规则，调用接口业务服务实现模块40的外部接口业务服务构件，来完成业务数据的计算；核心控制器10调用流程模块20中的逻辑计算构件和路由判断构件，针对最终业务数据进行路由判定并得到下一环节活动项；核心控制器10调用流程模块20中的参与者管理构件和活动项管理构件，组合计算生成待办事项；核心控制器10调用流程模块20中的待办事项管理构件，写入待办事项；

上述事项完成后，核心控制器10将处理完成的消息反馈给同步接口的调用者，整个服务过程完成。

由上可以看出，传统工作流引擎***主要是基于构件的工作流引擎，其根据职能划分将整个工作流引擎***最终划分为各种不同的构件，并通过核心控制器10根据接口的业务服务实现来实现各流程流转等的执行过程，并以同步接口的方式将流转功能暴露供应用***进行调用，从而完成整个流程流转的执行。

这种工作流引擎，比较有利于工作流引擎的快速开发和目前各种工作流产品的整合集成，并在一定程度上能够提高工作流中间构件的复用程度，然而随着信息化用户的迅猛发展，在SaaS(Software-as-a-service，软件即服务。SaaS是基于互联网提供软件服务的软件应用模式。)环境下，当海量用户群大量并发访问时，其访问压力将集中在内核构件的流程调度与执行模块上，这种情况下，往往容易引起引擎***的调度拥塞。

另外，传统的工作流引擎在被应用***调用后，即需要协同引擎各模块的构件进行一系列计算，应用***在工作流引擎完成计算之前一直处于等待状态，最终用户同样也得不到***的反馈，因此严重影响了***使用上的性能体验。

发明内容

本发明的目的是提供一种工作流引擎***，通过本发明，能够有效缓解引擎***的调度拥塞；而且最终用户能够及时得到***的反馈，从而能够提高***使用上的性能体验。

本发明的目的是通过以下技术方案实现的：

本发明提供一种工作流引擎***，包括***接口，其还包括：

请求受理模块，用于从所述***接口处接收工作流请求，并根据所述工作流请求生成对应的工作流处理消息以及请求处理完成消息；将请求处理完成消息返回请求用户；

工作流处理模块，用于根据所述请求受理模块生成的工作流处理消息，运行相应的工作流处理流程。

其中，所述工作流引擎***还包括：

消息队列处理模块，用于将所述请求受理模块所生成的工作流处理消息，入消息队列等候处理，当处理时间到达时，弹出此工作流处理消息队列，并根据所述工作流处理消息中的参数触发相应的工作流处理模块运行。

本发明还提供一种工作流处理方法，所述工作流处理方法包括：

接收工作流请求，并根据所述工作流请求生成对应的工作流处理消息以及请求处理完成消息；

将请求处理完成消息返回请求用户；并根据所述工作流处理消息，运行相应的工作流处理流程。

其中，所述工作流处理方法还包括：

将所述工作流处理消息，入消息队列等候处理，当处理时间到达时，弹出此工作流处理消息队列，并根据所述工作流处理消息中的参数触发相应的工作流处理流程。

由上述本发明提供的技术方案可以看出，本发明请求受理模块，接收工作流请求，并根据该工作流请求生成对应的工作流处理消息以及请求处理完成消息；将请求处理完成消息返回请求用户；工作流处理模块根据所述请求受理模块生成的工作流处理消息，运行相应的工作流处理流程。通过本发明将请求处理完成消息及时返回请求用户，能够有效缓解引擎***的调度拥塞；而且最终用户能够及时得到***的反馈，从而能够提高***使用上的性能体验。

附图说明

图1是现有技术的逻辑结构原理图；

图2是本发明第一实施例的逻辑结构原理图；

图3是本发明第一实施例的流转处理工作原理图；

图4是本发明第二实施例的流程图。

具体实施方式

结合大量工作流成功应用案例，从用户对于流程处理过程中的使用意图入手进行认真分析，可以发现用户在完成当前流程的审核后，其实并不愿意等待工作流引擎***去完成这一系列的计算、判断、路由等工作后才给出成功的提示，因为这一系列工作中大部分内容不依赖于用户的直接操作或主观判断。用户本质上只要确定完成了本环节工作后(表单中必须填写的内容)，就应该可以直接提交本环节，后续的处理工作可以由工作流引擎独立完成，处理过程即便发生意外失败实际上也与上一环节的提交用户没有任何关系。

考虑到以上因素，工作人员从对工作流各处理模块之间的直接调用进行解耦入手，研发了本发明的技术方案。

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。

本发明第一实施例提供一种工作流引擎***，该第一实施例在传统基于构件的工作流引擎基础上，引入了消息队列，通过消息队列将工作流各处理模块之间的直接调用进行解耦，并引入生产者消费者模型，使各个模块高内聚低耦合，消除模块间潜在的竞争资源引用，实现***可服务化部署模式，为***横向扩展消除技术障碍。该工作流引擎***的结构原理图如图1所示，包括：

请求受理模块100、消息队列处理模块200、工作流处理模块300、同步接口400。其中，工作流处理模块300可以是流转处理模块，也可以是其它工作流处理模块。

请求受理模块100，用于从同步接口400处接收工作流请求，所述工作流请求中携带有：请求用户的身份信息、请求的工作流参数，以及期望返回的结果信息等；请求受理模块100读取请求中携带的工作流参数，并调用一些与该工作流参数对应的规则和/或定义，对这些参数进行解析，将解析后的数据进行保存后，生成与这些数据对应的工作流处理消息以及请求处理完成消息，并将此工作流处理消息提交到消息队列处理模块200，将请求处理完成消息返回请求用户。

消息队列处理模块200将此工作流处理消息以生产者的身份入消息队列等候处理，当处理时间到达时，弹出此工作流处理消息队列，并根据该工作流处理消息中携带的参数，触发相应的以消费者身份注册的工作流处理模块300，如消息中的数据参数若是流转处理参数，则触发流转处理模块。

工作流处理模块300依据工作流处理消息中的数据参数执行相应的工作流处理，后续的具体处理过程与现有技术中的相应描述相同，这里就不再详细描述了。

上述第一实施例中，需要工作流处理模块300事先在消息队列中注册为消费者。当消息被弹出后，会触发以消费者身份注册的工作流模块300启动，从而执行后续的工作流程，后续的工作流处理流程与现有技术中的相关描述类似，这里不再详细描述。

下面以工作流引擎***接收到流转请求为例，对本发明第一实施例进行详细说明，该实例的工作原理如图3所示，包括：请求受理模块100、消息队列处理模块200、流转处理模块500。

下面以工作流引擎***从服务接口(图中同步接口400)接收到一个流转请求为例来描述该第一实施例的工作原理：

工作流引擎***通过请求受理模块100从同步接口400，接收到一个流转请求；该流转请求包括：请求者的身份标识，流转请求数据参数等；

请求受理模块100根据流转请求中携带的工作流信息，通过其内设置的一组表单构件，完成表单的处理，并最终生成一个处理完成消息和一个流转处理消息，请求受理模块100根据请求者的身份标识将处理完成消息给反馈给请求者，将流转处理消息提交给消息队列处理模块200中的生产者，该流转处理消息中携带有流转请求数据参数；

消息队列处理模块200中的生产者将流转处理消息入消息队列等待处理，待该消息队列的流转处理消息到达处理时间时，触发流转处理模块300以消息消费者身份从消息队列中获取一个流转处理消息，并根据该消息中携带的流转请求数据参数进行后续的处理，如调用逻辑计算构件和路由判断构件，针对最终业务数据进行路由判定并得到下一环节活动项；调用参与者管理构件和活动项管理构件，组合计算生成待办事项；调用待办事项管理构件，写入待办事项等，该后续处理与传统工作流引擎的处理模式相同，这里就不再详细描述。

上述实例是以流转处理环节解耦为例对本发明说明的，但本发明适用并不局限于流转处理环节解耦，还可以是其它的工作流处理环节。任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，都可轻易联想到的更多模块之间的解耦均可延用本发明，比如：流转处理和待办事项解耦、流转环节计算和参与者计算解耦等。

上述第一实施例中，以消息生产者的身份投放一个工作流处理的消息，将处理完成消息反馈给同步接口的请求者，服务快速完成，请求者能够很快获得反馈消息，无需长时间等待，从而增强了用户使用该引擎***的性能体验。

另外，本发明在传统基于构件的工作流引擎基础上，利用消息队列将工作流各处理模块之间的直接调用进行解耦，并引入生产者消费者模型，使各个模块高内聚低耦合，消除模块间潜在的竞争资源引用，实现***可服务化部署模式，为***横向扩展消除技术障碍。应用***在调用工作流引擎后，工作流引擎只需要对表单内的数据进行解析、校验和保存，即可结束此次工作流请求的处理；大量后续关于工作流请求的实际处理过程则可由工作流处理模块以异步的方式进行处理，无需阻塞发出请求的应用***，从而极大提升了处理效率。

此外，工作流处理模块可以根据***压力情况，通过启动更多的节点来实现***的横向扩展，保障工作流引擎可以轻松应对海量客户规模下的大并发访问压力。

上述实施例中，还可以不包括生产者和消费者。此时需要根据工作流处理参数，将后续的工作流处理模块与消息队列中的消息建立对应关系。例如，若监测消息队列中的参数含有工作流处理参数，则消息队列中的消息被弹出后，就激发相应的工作流处理模块启动后续的流程。

本发明第二实施例提供一种工作流处理方法，该工作流处理方法的处理流程如图4所示，包括：

步骤11，接收工作流请求，并根据所述工作流请求生成对应的工作流处理消息以及请求处理完成消息；

步骤12，将请求处理完成消息返回请求用户，并结束；

步骤13，将工作流处理消息，入消息队列等候处理，当处理时间到达时，弹出此工作流处理消息队列，并触发工作流处理模块运行；

步骤13的具体处理过程与第一实施例中的相关描述相同，这里不再详细描述。

步骤14，工作流处理模块根据所述工作流处理消息，触发相应的工作流处理流程。

由上述实施例可以看出，本发明在传统基于构件的工作流引擎基础上，利用消息队列将工作流各处理模块之间的直接调用进行解耦，打破传统基于构件的工作流引擎同步紧耦合的协作模式，将其转为异步松耦合协作模式，从而可以消除竞争资源的持续占用，为***横向扩展消除技术障碍，实现***可服务化部署模式；并引入生产者消费者模型，从而实现生产者和消费者近乎无限线性的横向扩展能力。从而为工作流引擎作为重要基础模块在SaaS环境的应用中解决了最为关键的线性横向扩展能力问题。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (4)

1.一种工作流引擎***，包括***接口，其特征在于，所述工作流引擎***还包括：

请求受理模块，用于从所述***接口处接收工作流请求，并根据所述工作流请求生成对应的工作流处理消息以及请求处理完成消息；将请求处理完成消息返回请求用户；

工作流处理模块，用于根据所述请求受理模块生成的工作流处理消息，运行相应的工作流处理流程。

2.根据权利要求1所述的工作流引擎***，其特征在于，所述工作流引擎***还包括：

消息队列处理模块，用于将所述请求受理模块所生成的工作流处理消息，入消息队列等候处理，当处理时间到达时，弹出此工作流处理消息队列，并根据所述工作流处理消息中的参数触发相应的工作流处理模块运行。

3.一种工作流处理方法，其特征在于，所述工作流处理方法包括：

接收工作流请求，并根据所述工作流请求生成对应的工作流处理消息以及请求处理完成消息；

将请求处理完成消息返回请求用户；并根据所述工作流处理消息，运行相应的工作流处理流程。

4.根据权利要求1所述的工作流处理方法，其特征在于，所述工作流处理方法还包括：

将所述工作流处理消息，入消息队列等候处理，当处理时间到达时，弹出此工作流处理消息队列，并根据所述工作流处理消息中的参数触发相应的工作流处理流程。

Images