CN1316408C - 工作流程管理系统及判断其中信令事件收件人的方法 - Google Patents

Abstract

本发明提供了一种计算机化的方法，用于确定具有可比较功能的工作流程管理系统或计算机系统(WFMS)内的信令请求的收件人。在接收到信令请求(该请求提供一组信号数据元素)时，本发明不要求信号数据元素包括所说的信令请求的收件人的任何显式说明。为确定作为业务进程的进程模型的实例的进程实例的特定事件活动是否为信令请求的可能的收件人，建议确定进程模型是否包括事件标识说明。根据本发明的此事件标识说明涉及信号数据元素的子集。对事件标识说明的评估允许间接地判断事件活动是否为信令请求的收件人。

Description

工作流程管理系统及判断其中信令事件收件人的方法

技术领域

本发明涉及用于改进具有涉及事件的信令的可比较功能的工作流程管理系统或计算机系统(WFMS)的健壮性和易用性的装置和方法。

背景技术

一个重要性越来越大的新技术领域是工作流程管理系统(WFMS)领域。WFMS支持业务进程的建模和执行。在WFMS环境内执行的业务进程可以控制谁将执行网络的哪件工作以及为此工作利用哪些资源。单件工作可以跨被某种网络连接的大量不同计算机系统地进行分布。

“IBM MQSeries Workflow”(以前叫做“IBM FlowMark”)这一产品代表了这样的典型、现代化的、先进的、功能强大的工作流程管理系统。它支持将业务进程建模为活动网络。此活动网络(进程模型)是作为有向非循环加权彩色图来构建的。图形的节点代表执行的活动。图形的边(控制连接器)描述了执行活动的可能的顺序。进程图的定义是通过IBM MQseries Workflow的流程定义语言(FDL)或通过内嵌的图形编辑器进行的。

工作流程管理系统的运行时组件使用所说的进程模型作为创建进程实例的模板。每一个进程实例都与一组值(通常叫做“上下文”)关联。所说的值是进程实例的请求者或者通过相应的请求提供，或者由实现各种活动的程序检索，或者是某一进程实例的执行历史的结果。上下文是某一进程实例所特有的。所说的上下文内的一个特定的重要信息片段是唯一地标识进程实例的进程实例标识符。值得注意的是，通常，进程实例标识符只是在从特定的进程模型派生的进程实例集内唯一的。

特别重要的活动类型是事件活动。事件活动提供了让进程实例等到发出事件的能力。信号，或换句话说，事件，可以在WFMS内创建，但通常其来源位于工作流程管理系统之外。在接收到所说的信号时，工作流程管理系统将所提供的信息作为上下文信息存储(在此情况下，存储到事件活动的输出容器中)，并继续导航。

事件的信令是通过发送到工作流程管理系统的相应的信号请求进行的。所说的信号请求可以由利用工作流程管理系统所提供的应用程序编程接口的程序来创建，或者通过向通常可以执行这样的信号请求的工作流程管理系统发送一个相应的工作流程管理系统定义的消息来创建。与执行信令事件的方式无关，信令请求必须包含其中事件正在等待的进程实例的相应的进程实例标识符以及事件的标识符。此信息是必需的，以便工作流程管理系统可以定位进程模型内的正确的进程实例和正确的事件。如果信令请求的发出者不知道事件标识符，或者甚至不知道进程实例标识符，则发出者必须获得此信息。为便于执行此项操作，工作流程管理系统提供了查询功能，以便允许发出者查询事件活动的输入容器。进程建模者的必须确保，事件活动的输入容器包含从中可以派生进程实例标识符的相应的值。

这种最先进的方法具有多处不足，特别是，当事件通过向工作流程管理系统发送一个消息来发出时。

事件的信令发送者必须向工作流程管理系统指出，请求是为了请求发送事件；意思是说，请求者必须遵循工作流程管理系统定义的消息结构。此结构通常要求具有某些指示符，如在消息的某些位置消息代表文本字符串信号作为消息的第一字段的命令。这就要求，当信号应该由工作流程管理系统进行处理时，现有的面向消息的发送者程序必须修改；这是一个不一定总可以实现的方法。另一个克服此情况的方法是使用一种转换程序，该转换程序将发送者的原始消息转换为工作流程管理特定的消息；该方法不仅增大了整个系统的复杂性(使维护和系统管理变得更加复杂)，而且还降低了产生信号的性能。

发送者必须维护目标进程实例的进程实例标识符。如果这不可能实现，发送者必须从工作流程管理系统获取相应的信息(事件的输入容器中的数据)。这要求，发送者已经知道事件的名称，以便它可以设置到工作流程管理系统的相应的查询。这也有缺点，对进程模型作出的每个更改(如更改事件的名称)都需要对发送者进行重新编程(如修改事件的新名称)。

发送者必须知道事件的名称(根据WFMS的命名法)，即使它知道进程实例标识符。知道名称包括在某种程度上知道进程模型的结构；例如，进程模型可以在同一个进程模型内多次使用同一个名称，当从比较简单的进程模型合成一个比较复杂的进程模型时可能会容易产生这种情况。

从上文列出的不足可以看出，该技术的当前状态强制事件的发送者和工作流程管理系统之间的紧密耦合，该耦合由发送者必须维护关于工作流程管理系统维护的信息的信息所声明。由于上文概述的原因，此情况是相当不受欢迎的。在工作流程管理系统中应该可以指定处理任意消息以便发送事件所需的所有信息。还应该可以任意发送事件，以便向WFMS发送信令事件，而不必为适应WFMS要求而修改所说的信号。任意的发送者应该被允许不知道信令请求的消费者(即，收件人)的具体特征。然后，可以独立于信令请求的消费者开发信号发送者。

如果一个人想起通常以诸如C2B(消费者对企业)或B2C(企业对消费者)业务进程之类的术语所概述的典型的因特网情况，最先进的方法在这一问题的领域的弱点变得更加显著。在这些情况下，显然，信号发送者与工作流程管理系统的紧密耦合是根本不理想的。

本发明基于这样的目标：使事件发送者在等待所说的事件的通知的相应的进程实例中定位相应的事件时，无需维护所需要的信息。

发明内容

本发明的目标由独立的权利要求解决。在相应的子权利要求中阐述了本发明的有利的配置和实施例。

本发明提供了一种计算机化的方法，用于确定具有可比较功能的工作流程管理系统或计算机系统(WFMS)内的信令请求的收件人。

在接收到信令请求(该请求提供一组信号数据元素)时，本发明不要求信号数据元素包括所说的信令请求的收件人的任何显式说明。

为确定作为业务进程的进程模型的实例的进程实例的特定事件活动是否为信令请求的可能的收件人，建议确定进程模型是否包括事件标识说明。根据本发明的此事件标识说明涉及信号数据元素的子集。对事件标识说明的评估允许间接地判断事件活动是否为信令请求的收件人。

所提出的本发明避免了上述所有不足。基于所提出的方法免除了信令请求的发送者指定某一收件人提供了又一个优点，即，对于单一的信令消息，可以存在多收件人。

附图说明

图1显示了由进程图代表的进程模型的示例。

图2说明了作为输入和输出容器的活动的签名和通过数据连接器将数据从一个活动移动到另一个活动的实施例。

图3说明了当激活时等待处理消息的事件活动的结构。

图4说明了使用用于描述消息的内容的XML架构定义发送事件的消息的定义。

图5直观地显示了使用MQseries Workflow的流程定义语言的必需的规范的细节。

图6说明了确定发送事件的消息的结构的另一种方法。

图7说明了标识作为信令消息的目标的事件的另一种方法。

具体实施方式

在附图和说明书中，阐述了本发明的优选实施例，虽然这里使用了特定的术语，但是如此给出的描述只是在作为通用和描述性的意义上使用术语的，而不是起限制作用。然而，很显然，在不偏离所附权利要求所阐述的本发明的更广泛的精神和范围的情况下，可以进行各种其他更改和修改。

本发明可以以硬件、软件或硬件和软件的组合实现。任何类型的计算机系统-或适于执行这里描述的方法的其他装置都适合。典型的硬件和软件的组合可以是具有这样的计算机程序的通用计算机系统，当加载并执行该计算机程序时，控制计算机系统以便它执行这里描述的方法。本发明还可以嵌入在包括实现这里描述的方法的所有特点的计算机程序产品中，这种计算机程序产品在加载到计算机系统中时，能够执行这些方法。

本上下文中的计算机程序装置或者计算机程序是指以任何语言、代码或注释表达的一组指令的任何表达式，用于使具有信息处理能力的系统直接或者在下列操作中的任何一种或两种操作都执行之后执行特定的功能：a)转换到另一种语言、代码或注释；b)以不同的材料形式再现。

是基于IBM的“MQSeries Workflow”工作流程管理系统来对本发明进行说明的。当然，也可以使用任何其他WFMS。此外，本发明还可以应用于不作为单独的WFMS而在某些其他类型的系统内提供WFMS功能的任何其他类型的系统。

根据本发明，如果WFMS引擎是基于由发送者提供的数据元素确定任何信令请求的收件人的处理实体，是有利的。但是，当然，本发明也可以在对发送事件的请求的处理实体不是WFMS引擎本身而是某些其他实体的其他情况下应用。

1.概述

下面是有关基于IBM的“MQseries Workflow”的工作流程管理系统WFMS的基本概念的简要概述。

从企业的观点来看，对业务进程的管理变得越来越重要：业务进程(或简称为“进程”)控制哪件工作将由谁来执行以及为此工作利用哪些资源，即，业务进程描述了企业将如何实现其业务目标。WFMS可以支持对业务进程的建模和它们的执行。

以软件系统直接支持的方式将业务进程作为一个语法单位建模是非常理想的。此外，软件系统也可以作为基本上作为输入获取这样的模型的解释器来工作：该模型叫做“进程模型或工作流程模型”，然后可以对该模型实例化，从而可以确定取决于模型的实例化的上下文的工作步骤的单独的顺序。这样的业务进程的模型可以被视为在企业内执行的类似的进程的一个类别；它是描述特定类型的业务进程的所有可能的执行变量的架构。这样的模型的实例以及其解释代表单独的进程，即，模型规定的变量的具体的、与上下文相关的执行。WFMS有助于业务进程的管理。它提供了描述业务进程(生成时)的模型的手段，它基于相关的模型(运行时)驱动业务进程。下面将描述IBM的WFMS MQseries Workflow的元模型，即，为描述业务进程模型而提供的语法元素，以及这些语法元素的含义和解释。

进程模型是进程的完整的表示，包括进程图和定义图表的组件后面的逻辑的设置。MQseries Workflow进程模型的重要组件有：

●进程

●活动

●区块

●控制流程

●连接器

●数据容器

●数据结构

●条件

●程序

●人员

下面将描述这些元素中的其中几个。

活动是元模型的基本元素。活动代表从某种角度来看是其自己的语义实体的业务操作。

MQSeries Workflow进程模型由下面几种类型的活动构成：

程序活动：指派一个程序执行活动。当启动活动时，调用该程序。在完全自动化的工作流程中，程序执行活动，无需人的干预。否则，用户必须通过从运行时工作列表选择活动来启动该活动。来自程序的输出可被用于程序活动的退出条件以及用于到其他活动的过渡条件。

进程活动：指派一个(子)进程执行活动。当启动活动时，调用该进程。进程活动代表了重复使用一组对不同的进程通用的活动。来自进程的输出可被用于进程活动的退出条件以及用于到其他活动的过渡条件。

控制流，即，通过运行中的进程的控制流程确定了执行活动的顺序。MQSeries Workflow工作流程管理器将进程沿着通过启动条件、退出条件和过渡条件被评估为TRUE而确定的路径导航。

连接器链接进程模型中的活动。使用连接器，可以定义活动的顺序和活动之间的数据传输。由于活动可能不任意地执行，因此它们通过控制连接器绑定在一起。控制连接器可以被视为两个活动之间的有向边；连接器的终点的活动不能在连接器的起点处的活动(成功地)完成之前开始。从而控制连接器对一个业务进程模型内的控制的潜流进行建模。默认连接器指定当没有其他控制连接器离开活动的过渡条件被评估为TRUE时控制应该流向哪里。默认连接器能使工作流程模型处理例外的事件。数据连接器指定一个工作流程模型中的数据的流动。数据连接器发自一个活动或区块，并将活动或区块作为其目标。可以指定输出数据发往一个目标或发往多个目标。一个目标可以有一个以上输入数据连接器。

进程定义包括活动的建模、活动之间的控制连接器，输入/输出容器，以及数据连接器。进程被表示为以活动作为节点，控制/数据连接器作为图形的边的有向非循环图。图形是通过内嵌的图形编辑器操作的。数据容器有指定为命名的数据结构。这些数据结构本身是通过DatastructureDefinition功能指定的。程序活动是通过程序实现的。程序是通过Program Definition功能注册的。区块与进程包含相同的结构，如活动、控制连接器等等。然而，它们是未命名的，并且有它们自己的退出条件。如果不符合退出条件，则再次启动区块。区块如此实现Do Until结构。进程活动是作为进程来实现的。这些子进程是作为带有其通常的属性的常规，命名的进程定义的。进程活动为进程定义提供了较大的灵活性。它不仅允许通过对活动的永久优化为程序和进程活动来构建进程(自顶向下)，而且从一组现有的进程生成进程(自底向上)。

实现程序活动的所有程序是通过Program Registration功能定义的。为每一个程序注册了程序的名称、其位置，调用字符串。调用字符串由程序名称和传递到程序的命令字符串构成。

作为这样的一个进程模型的示例，图1概要显示了这样的进程图的结构。活动(A1到A5)被表示命名的圆形；名称通常描述了活动的用途。活动以各种形式解决可能需要执行的不同的任务。它们可能具有不同的活动实施方式，以满足这些不同的需要。程序活动由指派的程序执行，进程活动(如100)由另一个进程101执行，区块(如102)以内嵌的do-until循环实现宏103。控制连接器p12、p13、p24、p35、p45被表示为箭头；箭头的头部描述了控制流沿着进程移动的方向。控制连接器从那里开始的活动叫做“源活动”；它在那里结束的活动叫做“目标活动”。  当一个以上的控制连接器离开活动时，这表示潜在地平行的工作。

2.容器和数据连接器

图2显示了两个活动A200和B210，可以是比较复杂的进程模型的一部分。活动A200和B210具有一个与它们关联的输入容器220、240；活动A200还具有与其关联的输出容器230。在根据本发明的基本的变更中，一个活动的输入和输出容器在概念上可以视为活动的签名。活动从输入容器获取其执行所需的数据，并将它产生的数据以及其他活动所需要的数据写入到输出容器中。如同签名一样，活动的容器只对该活动可用；意思是说，它们只在本地可用。例如，输入容器220和输出容器230只对所关联的活动A200可用。因此，如果活动B210需要来自活动A200的输出容器230的数据，则此数据必须从活动A200的输出容器230复制到活动B210的输入容器240。

为了将数据从其中一个活动复制到另一个活动，提供了数据连接器260，该数据连接器在图2中被描述为虚线箭头。图2的数据连接器260表示，活动A200的容器230的所有或部分必须复制到活动B210的输入容器240。

然而，一个活动的输出容器和另一个活动的输入容器通常具有不同的数据结构，例如，包含不同的数据字段。因此，在图2中提供了容器图250，该图定义了活动A200的输出容器230的数据字段复制到活动B210的输入容器240的数据字段中。容器图250还指定在将数据复制到活动B210的输入容器240之前，是否必须由工作流程管理系统执行数据的转换。

3.事件活动

事件活动是工作流程管理系统支持的另一种类型的活动。它们提供了让进程实例等到从工作流程管理系统外面发出事件的能力。在接收到信号时，工作流程管理系统处理请求并继续导航。事件活动具有大多数属性程序和进程活动。输入和输出容器是关联的。它可以是控制连接器的源和目标以及数据连接器的源和目标。它具有开始条件，可以为它指定最后期限。

图3说明了比较复杂的进程模型的此概要显示的部分301。控制连接器360一进入事件活动，事件活动300就进入了等待状态。如果在实现进程模型时事件活动没有进入的控制连接器，一旦创建进程实例，事件活动就进入等待状态。事件活动一直处于此状态，直到发出事件。某客户端310向发出事件活动300正在等待的事件的工作流程管理系统发出相应的请求350。此请求必须(1)将相应的进程实例中的相应的事件(2)标识为收件人。此外，事件信号可以提供存储在输出容器320中的数据，以便事件发送者所提供的信息可以对进程实例可用。当正确地发出事件时，导航继续。有关事件活动的更多细节可以在Leymann/Roller，Production Workflow：Conceptsand Techniques，Prentice Hall，New Jersey ISBN和US Patent US6,065,009 Events as Activities an Process Models of WorkflowManagement Systems中找到。

4.通过XML定义消息

图4显示了通过XML架构定义对消息的定义(有关XML和XML架构的细节，请参阅http://www.w3.org)。消息的用途是向图5中定义的事件活动发送事件。关键字complexType 400开始用户定义的XML结构的定义。结构的名称是SignalMessage 410。该结构由一组元素420构成，并带有所说的元素的元素名称430和数据类型440。

5.处理事件的信令

图5说明了使用MQSeries Workflow(申请者出售的最先进的工作流程管理系统)的流程定义语言(FDL)实现/指定的本发明。FDL只被用作示例；可以使用指定发送事件的任何其他方式。基础元模型只作说明；可以使用其他元模型。

本发明的重要原理是提供允许事件的任意发送者完全不知道信令请求的收件人的技术；意思是说，具体的进程实例等待所说的事件。这就免除了发送者维护等候具体的进程实例的进程实例标识符和维护对应的进程模型内的事件活动的标识符。

本发明的基本目标是，WFMS本身可以利用信令请求内的发送者提供的数据元素或数据元素的子集，以唯一地标识作为事件的收件人的具体进程实例(或多个进程实例)和/或具体的事件活动(或多个事件活动)。

为使WFMS能执行此标识任务，建议提高包括具有说明的事件活动的进程模型，这些说明定义要使用的信令请求所提供的(一个或多个)数据元素集，以将所说的进程模型的某些进程实例和所说的事件活动标识为收件人。一旦WFMS接收到信令请求，知道进程模型的WFMS将利用这些预先定义的事件标识说明和拥有信令请求的具体数据元素，以确定事件的具体收件人。

该示例说明了利用本发明的事件活动的定义。

DATASTRUCTURE定义500标识具有名称SignalMessage501的数据结构。数据结构引用(通过XML关键字)502 XML架构SignalMessage 503(这是图4中定义的XML架构)。此数据结构定义了被接受为张贴事件活动520的信令的消息的结构。

DATASTRUCTURE定义510标识具有名称EventOutput的数据结构。数据结构包含INTEGER 512类型的字段AmountOffered。此数据结构用于事件活动520的输出容器；字段AmountOffered被计划作为在信令消息中提供的相应的字段的目标。

事件活动是通过EVENT_ACTIVITY关键字520进行定义的；事件活动的名称是ReceiveOffer 522。事件活动的输出容器是通过OUTPUT关键字进行定义的，该关键字将数据结构EventOutput 524标识为输出容器的结构。

关键字SIGNAL 540标识与发送事件关联的所有属性；在本发明提出的特定的事件标识说明中，包括在本节内。在本示例内，它标识了，数据结构SignalMessage 526代表了发送事件的消息的结构。

关键字MESSAGE_IDENTIFICATION 536用于向工作流程管理系统指出应该如何确定消息的结构；该结构定义消息的布局。参数XML_SCHEMA 528指出，应该使用消息提供的XML架构名称(这对于XML消息是典型的，因为能够使用XML分析器来分析消息是理想的)。下面将讨论MESSAGE_IDENTIFICATION参数的其他可能的参数值。如果信令消息具有指定的XML架构，则工作流程管理系统将此消息当作此ReceiveOffer活动的潜在的信令消息。意思是说，如果信令消息具有XML架构SignalMessage，则信令消息是事件活动ReceiveOffer 522的信令消息的备选。

关键字PROCESS_INSTANCE 542标识信令消息中的应该用于标识进程实例的字段。在该示例中，使用了XML消息的字段ContractId 530。一般而言，进程实例可以由涉及信令消息内的数据元素的值和来自进程实例的上下文的数据元素的值的任何任意的复杂布尔表达式来标识。

关键字TARGET_IDENTIFICATION 544用于定义表达式532，当该表达式被评估为True时，信令消息被指向事件活动。因此，此关键字允许标识WFMS将信令事件到其中的进程模型内的具体活动。表达式通过使用信令消息中的一个或多个字段来构建。在该示例中，如果信令消息中的字段ActionId包含文本字符串ReceiveOffer，则信令消息指向此活动。

MAP关键字546提供了将字段从信令消息映射到活动输出容器的能力。在该示例中，它将字段AmountOffered从信令消息复制到输出容器。其他可能性是将信令消息的字段复制到全局/键容器(有关细节，请参阅Leymann/Roller：Production Workflow：Concepts and Techniques，Prentice Hall，2000)。

图6说明了标识信令消息的结构的另一种可能性。它定义了一个表达式，当该表达式被评估为True时，信令消息具有被指定为信令消息结构的结构。意思是说，当字段messageId 610包含值512时，信令消息具有为信令消息定义的结构，因此是事件活动ReceiveOffer的信令消息的备选。

图6提出了对进一步问题的解决方案。在某些环境中，潜在的收件人只在所说的某些领域内是唯一的。这种情况的示例是进程实例标识符，这些进程实例标识符只在该进程实例集(它们是由常见的进程模型派生而来)内是唯一的。

为应付这种情况，有人建议，事件标识说明包括说明，当对这些说明进行评估时，允许将潜在的收件人的范围限制到常见的进程模型的进程实例。图6中的特定的实施例允许从信令消息的一个或多个数据元素(在此示例中，参数businessProcessID-请参见图4)解释进程模型的标识符。结果，只有以此解释的标识符从进程模型实例化的进程实例被视为潜在的收件人；当然，事件标识说明内的其他说明将进一步变窄，并标识具体的收件人。

一个进程实例内的事件唯一地通过活动实例标识符进行标识。因此，存在其他用于指定信令消息的目标的方法。所说的说明是PROCESS INSTANCE和TARGET_IDENTIFICATION说明的组合的备选说明。图7说明了这种说明的形式。关键字ACTIVITY_IDENTIFICATION 710标识信令消息内的一个或多个字段，以将事件活动的标识符解释(甚至通过一个更复杂的表达式)为信令事件的收件人。在当前示例中，作为信令消息的一部分的字段EventId 720直接用于解释代表所说的收件人的事件活动标识符。

在运行时，上述说明被WFMS以下列方式使用：

首先，WFMS判断信令消息的结构。这就要求检查所有进程模型中的所有事件活动的所有MESSAGE_DEFINITION。如果不能确定信令消息的结构，WFMS认为，消息不是事件信令消息，并采取其他必需的操作。

其次，WFMS确定作为信令消息的目标的进程实例。

第三，WFMS确定作为信令消息的目标的所说的进程实例内的活动实例。

第四，WFMS将字段信令消息复制到进程实例的上下文。

Claims (14)

1.一种计算机化的方法，用于判断具有可比较功能的工作流程管理系统内的信令请求的收件人，

所说的工作流程管理系统管理作为业务进程的进程模型的实例的进程实例，以及

所说的方法的进一步的特征在于

所说的进程模型包括至少一个事件活动，以及

在第一个步骤中，所说的工作流程管理系统接收信令请求，

所说的信令请求提供了一组信号数据元素；以及

所说的信号数据元素不包括标识所说的进程实例或所说的事件活动作为所说的信令请求的收件人的任何显式说明；以及

在第二个步骤中，所说的工作流程管理系统

判断所说的进程模型是否包括涉及所说的信号数据元素的子集的事件标识说明；以及在肯定的情况下，

对事件标识说明进行评估以间接地判断所说的事件活动是否为所说的信令请求的收件人；以及在肯定的情况下执行第三个步骤，

在第三个步骤中，所说的工作流程管理系统向所说的事件活动作为收件人提供所说的信令请求。

2.根据权利要求1所述的用于判断信令请求的收件人的计算机化方法，

其特征在于，所说的事件标识说明包括第一说明，该第一说明通过评估确定所说的进程实例是否为所说的信令请求的所说的收件人。

3.根据权利要求2所述的用于判断信令请求的收件人的计算机化方法，

其特征在于，所说的事件标识说明包括第二说明，该第二说明通过评估确定所说的进程实例的所说的事件活动是否为所说的信令请求的所说的收件人。

4.根据权利要求3所述的用于判断信令请求的收件人的计算机化方法，

其特征在于，所说的第一和/或所说的第二说明包括进一步涉及所说的进程实例的上下文的数据元素的布尔谓词。

5.根据权利要求3所述的用于判断信令请求的收件人的计算机化方法，

其特征在于，所说的第二说明从所说的信号数据元素的所说的子集解释要与标识所说的事件活动的第二标识符进行比较的第一标识符，以便确定所说的进程实例的所说的事件活动是否为所说的信令请求的所说的收件人。

6.根据权利要求2所述的用于判断信令请求的收件人的计算机化方法，

其特征在于，所说的事件标识说明包括第四说明，该第四说明通过评估将可能的收件人的范围限制到所说的进程模型的进程实例。

7.根据权利要求1所述的用于判断信令请求的收件人的计算机化方法，

其特征在于，所说的事件标识说明包括第三说明，该第三说明基于所说的信令请求的类型确定所说的进程实例是否为所说的信令请求的所说的收件人。

8.一种具有可比较功能的工作流程管理系统，用于判断工作流程管理系统内的信令请求的收件人，所说的工作流程管理系统管理作为业务进程的进程模型的实例的进程实例，所说的进程模型包括至少一个事件活动，该工作流程管理系统包括：

用于接收信令请求的装置，

所说的信令请求提供了一组信号数据元素；以及

所说的信号数据元素不包括标识所说的进程实例或所说的事件活动作为所说的信令请求的收件人的任何显式说明；以及

用于判断所说的进程模型是否包括涉及所说的信号数据元素的子集的事件标识说明的装置；

用于对事件标识说明进行评估以间接地判断所说的事件活动是否为所说的信令请求的收件人的装置；以及

用于向所说的事件活动作为收件人提供所说的信令请求的装置。

9.根据权利要求8所述的系统，其特征在于，所说的事件标识说明包括第一说明，该第一说明通过评估确定所说的进程实例是否为所说的信令请求的所说的收件人。

10.根据权利要求9所述的系统，

其特征在于，所说的事件标识说明包括第二说明，该第二说明通过评估确定所说的进程实例的所说的事件活动是否为所说的信令请求的所说的收件人。

11.根据权利要求10所述的系统，

其特征在于，所说的第一和/或所说的第二说明包括进一步涉及所说的进程实例的上下文的数据元素的布尔谓词。

12.根据权利要求10所述的系统，

其特征在于，所说的第二说明从所说的信号数据元素的所说的子集解释要与标识所说的事件活动的第二标识符进行比较的第一标识符，以便确定所说的进程实例的所说的事件活动是否为所说的信令请求的所说的收件人。

13.根据权利要求9所述的系统，

其特征在于，所说的事件标识说明包括第四说明，该第四说明通过评估将可能的收件人的范围限制到所说的进程模型的进程实例。

14.根据权利要求8所述的系统，

其特征在于，所说的事件标识说明包括第三说明，该第三说明基于所说的信令请求的类型确定所说的进程实例是否为所说的信令请求的所说的收件人。

Images