级别： 初级 娄丽军, 软件部售前工程师, IBM公司
2004 年 3 月 01 日 本文将就实践中获得的一些MQ Workflow建模和使用中的相关技巧，与读者做一些交流和探讨。
MQ Workflow作为面向企业业务流程整合的一个强大运行平台和工作流引擎，已经赢得了越来越多客户的青睐，同时随之而来的是，用户在使用该产品的过程中，越来越多地希望更加全面，更加深入的了解该产品的一些使用技巧，尤其是在流程建模方面的一些经验，从而能够更加充分地利用该产品的特有功能和更大限度地发挥该产品的相关优势，为此，本文将就实践中获得的一些MQ Workflow建模和使用中的相关技巧，与读者做一些交流和探讨。
为了便于对本文的理解，我们将首先将本文中用到的一些WF中的术语做一个统一的介绍。
Process Model/Template (流程模型)：用户业务流程在WF系统中的表示，利用WF提供的配置(Bulidtime)工具来进行定义，其中包括对人员，数据结构，控制逻辑的定义等，流程模型需要被翻译和转换为流程模板，然后输入到WF的运行时(Runtime)环境中进行运行。
Process Instance (流程实例)：WF的Runtime环境中的对应于某个流程模板的流程运行实例。
Activity(活动)：流程模型中某一个步骤，它可以是一个程序活动(Program Activity), 流程活动(Process Activity)或块活动(Block Activity)。
Program程序(程序): Activity的具体实现，它拥有一个逻辑名称，物理上对应于系统中某个可执行程序（包括DLL）或某个JSP。
Person(人)：完成流程中的每个活动的人，对应于企业中的员工(Staff)。
Role(角色)：企业中的员工所担当的责任。角色可以作为向员工分派任务时的一个衡量标准。
Worklist(任务列表)：分派给员工的任务项的总和。
Workitem(任务项)：在一个流程运行过程中，员工要完成的工作。
System(系统)：WF网络规划中的最小单位，由若干WF的server组成。
System Group(系统组)：共享同一个数据库的一组系统。
Domain(域)：System Group的总和，共享同样的人员和拓扑信息。
1 关于流程建模
1.1 Data Container（数据容器）的使用
在WF中，某个Activity或者Process的输入和输出数据需要存放在Data Container中，每个Activity通过其Input Container和Output Container接收数据和输出数据。在使用Data Container时，要结合Container本身的特点以及它对性能的影响等方面来科学地使用它。一方面，从Container的自身特点来看，它本身物理上存在以下限制：
首先是其字节大小的限制：在WF的早期版本中，Data Container的大小为32K，从版本V3.3开始，Data Container的大小增加为4MB。其次是其包含字段数的限制：Data Container最多可以包含512个用户定义的数据字段，这其中还包括其嵌套的Container中的字段，因此，通过Data Container嵌套的方法，并不能突破512个字段的限制。
另外一方面，Container的大小和字段的个数都直接影响系统的性能。
鉴于以上两方面的考虑，大家不能把Container当成用户数据的载体，进而将所有的用户数据都放在Container当中；相反，我们应该用Container来存储与Process（流程）控制相关的数据，而把真正的用户数据存放在外部数据库中。比如，在电信行业的工单处理系统中，我们仅将工单的唯一标识作为Data Container的一个数据字段，而把工单中包含的实际业务数据存储在数据库中。
1.2 Dummy Node(No Operation Activity, 哑节点)的使用
图表 1
在某些情况下，你可能需要在一个流程的一开始，根据Input Container的内容来决定流程中下一个Activity的走向，比如，在我们给出的图示中，Activity C,E,F,G被封装在一个Sub-process或Block中，当G接收工单之后，认为工单数据有误，决定将工单回退给C, C对工单进行处理之后，可能根据不同的情况，将工单派发给E,F,G中的任何一个部门，如何对这种业务处理进行流程建模呢？
我们给出Dummy Activity或称No Operation Activity(不做任何操作的活动)的解决办法，在流程的一开始，我们设置一个No Operation Activity，它不做任何业务逻辑处理，而只是根据条件判断流程的走向。如图1所示，我们给出Dummy Decision Node D，根据不同的控制条件(control condition，图中用红色虚线表示)来决定流程的下一个Activity是C,E,F,G中的哪一个。
定义No Operation Node的方法和步骤如下：
1) 创建一个新的program，
- 在General Tab中，设置其名称为：FMCINTERNALNOOP
- 在Data Tab中，选择"Program can handle any data structures", 并选择"Program can run unattended"
2) 定义与该program对应的activity
- 选择以上定义的FMCINTERNALNOOP，作为program
- 在execution tab中，deselect "user program execution agent"（表明你定义了一个UPES）
- 选择"Asynchronous" 异步方式
- 重新选择"user program execution agent"，或者将Server Name设置为NONE
- 在start tab中，选择Automatic
- 在data tab中，设置同样的input 和output数据结构，以避免数据映射
1.3 Block和Subprocess的使用
在WF中，Block(区块)和Subprocess(子流程)是两种十分有效的建模手段，二者各有特点，大家可以根据实际情况，因地制宜地使用它们。
Block在WF中的主要作用和目的是实现某一系列Activity的循环执行，这非常类似我们编程时使用的循环语句。它通常是一个Process的一部分，我们可以设定Block的退出条件（Exit Condition），只有当整个Block的退出条件满足时，Block才会退出循环，结束执行。对Block的使用要注意以下方面：Block并不意味着高性能和高处理能力的循环。例如，使用一个Block去实现一个守候进程将是一个非常不合适的做法。正确的做法应该是，将该守候进程作为一个Process中调用的一个Activity来处理。
相应地，子流程的设计和使用是MQ Workflow提供的一个用于提高系统的可重用性的手段，任何流程都可以被重用为子流程。
当然，在使用子流程的时候，也要考虑子流程的一些特点。比如：子流程在运行时是被动态绑定的，在这个意义上，我们称之为后绑定（late binding）。在MQ Workflow中，当一个流程启动时，它才被实例化，这时该流程模板才会被克隆到流程实例的数据库表中。从性能角度考虑，这同时意味着性能的下降，因为只有当子流程被调用时，它才被实例化，所以子流程的效率比Block还会略差。所以，当你从性能角度考虑时，可能Block是一个好的选择。
子流程也可以作为一个简化流程设计的手段：当你的多个流程都需要重用一个较为复杂的处理逻辑时，你可以将该处理逻辑封装为一个子流程。它的优势在于你可以对子流程修改一次，而如果使用Block，你需要在调用它的所有地方做修改。
同时，子流程有很强的灵活性，因为，MQ Workflow提供了动态流程调用（dynamic process invocation）的功能，即我们可以将要调用的子流程的名字作为Data Container的一个字段，在流程执行过程中，动态获得该流程的名称，从而动态地调用相应的流程。
对于Block和Subprocess二者而言都需要注意的另外一个非常重要的因素是, 只用当一个Block/Subprocess中的所有Activity都结束时，该Block/Subprocess才能结束。而一个Activity结束的条件必须是以下三种情况之一：该Activity本身运行结束或者该Activity被强行终止（force finish）或者是进入一个死路径(dead path)导致该Activity不会被执行。
1.4 对Activity超时的处理
在WF中，你可以设定某个Activity的"生命周期"（这类似于MQ中消息的生命周期的概念），从而对Activity进行超时处理，比如，可以向指定的用户发出通知（Notification）等。在使用这一功能时，要注意：
1） 有关超时时间的计数单位：如果你使用Data Container的某个字段作为超时时间，该时间的计数单位是秒，而在MQ中，消息生命周期是用十分之一秒来计算的；
2） 有关Scheduling Server的监测时间间隔：在设置Scheduling Server的监测时间间隔时，要保证此间隔要小于Activity的超时时间，以便获得及时的响应。设置Scheduling Server的监测时间间隔的方法是：
在Buildtime中，编辑Network Tab中Domain的属性，在Domain属性的Server Tab中，选择"Complete scheduling server settings", 在弹出的Scheduling Server属性对话框中，设置其时间间隔，如图2所示。
图表 2
3） 有关数据映射：当Activity超时时，系统不做数据映射（Data Mapping），为此，当你需要数据传递输出到下一个Activity时，你最好使用一个缺省数据映射（default data connector）来实现超时活动的数据输出。
如何在WF模型中判断和利用Activity的超时情况，并进行正确的处理呢？
图表 3
如图3所示，我们给出一个流程举例，我们设置WaitForCustomerReponse和 ProcessQuestionnaireResult两个Activity之间的控制条件（Transition Condition）为_STATE()<>_Expired，同理，设置WaitForCustomerReponse和NoResponseFollowup之间的控制条件为_STATE()=_Expired。
1.5 Automatic 或 Staffless Activities(无人工参与的活动)
当你创建和配置那些自动化运行的应用时，从提高系统性能的角度考虑，你需要设定该Activity的由一个固定用户来执行，较为常见的用法是创建一个"AUTOMATIC"用户，并指定为该用户。这样做的原因在于当系统产生XML消息时必须在Starter字段设置UserID的值，而且通过使用Staff1来指定特定用户比使用Staff2动态指定用户，可以很好地提高性能。
1.6 Cleanup时间的设定
我们曾经遇到这样的客户需求，他们想保留一定时期内的流程运行情况的记录，例如对系统中每个流程的启动时间，停止时间等信息做出记录，便于对流程的管理和统计分析。要实现这一需求，他们设想使用WF本身的运行时数据库表(Runtime Table)中的记录，从而避免自己额外编程的负担。那末，如何使得WF为我们保存特定时间段内的相关信息呢？我们可以通过设置WF Cleanup Server中的Cleanup Time来实现。如图4所示，
图表 4
我们在流程(process)的属性对话框的Control Tab中，可以设置对已经处理完的流程和任务项的保留时间，当该时间到达时，Cleanup Server会自动将其从数据库删除。在此之前，我们可以查询数据库，达到我们前面讲述的需求。
2 关于Staff的设计和管理
2.1 用户权限
在WF中，对人员的解析（Staff Resolution）和任务项分派（Workitem Assignment）是不需要用户必须与WF建立会话的，无论用户是否登录系统，人员的解析都会进行。为了能够启动(Start), 检出(Checkout), 检入(Checkin)用户的任务项，该用户必须是任务项的拥有者。如果我们在用户属性对话框中的Authrization Tab中，定义某用户拥有对其他用户的任务项权限(Person: Workitem)，则该用户将可以看到其他用户拥有的任务项或分派给其他用户的任务项，并且可以将自己的任务项授权\转移(Transfer)给指定的其他用户。
图表 5
如图5所示，这里需要注意的是我们如果指定了用户WEBBANK_CLERK能够看到并且可以将任务项转移给用户A1，那末用户WEBBANK_CLERK将只能看到并且可以将任务项转移给用户A1，因此，如果我们需要用户WEBBANK_CLERK可以将其任务项转移给其他任何用户，我们必须设置Person:Workitem为所有用户。
这样随之而来，会产生另外一个问题，如何使得用户在登录时只能看到属于自己的任务项，而又可以将其转移给其他多个用户呢？解决办法是，我们可以为该用户创建其私有的任务列表，利用生成任务列表时的过滤条件，为该用户生成一个属主等于它本人的任务列表，这样，它可以它虽然看不到其他用户的任务项，却可以将任务项转移给其他用户，如图6所示。
图表 6
关于对流程的权限控制，可注意以下几点：
如果某用户是流程的启动者，则他可以察看流程实例并对流程进行监控;
Category (类别)的使用可以更加细化对流程的权限控制。我们知道，在WF中，我们可以将某些相关流程划分到一个Category当中，如果某用户只对特定的Category有权限，他将只能够看到该Category中的流程模板并启动它。如果某用户对某个Category没有权限，他将不能察看流程实例，即使存在分派给该用户的工作项。
例如，在银行贷款流程中，我们将流程WebCreditRequest的Category设定为BankingPrcess，然后设定用户WEBBANK_CLERK只能看到属于他自己的任务项，并且只对BankingPrcess category有权限。假如，管理员将其他Category中的任务项转移给他，他将只能看到该任务项，而无法对其他Category中的流程进行察看和监控。
2.2 Role（角色）和 Team Worklist（组工作列表）的使用
在WF中，用户可以拥有一个或多个角色。如果我们在流程模型中指定了执行某个Activity的用户是动态分配的（这可以通过在Activity Properties的Staff2 Tab中设定），那末在流程的执行过程中，流程引擎会根据Staff2 Tab中设定的role/organization/level标准来为满足条件的用户产生工作项。如图7所示：
图表 7
工作项和属主之间是一对一的关系，如果有N个用户满足条件，WF将会产生N个工作项。在这种情况下，"Team Worklist"（组工组列表）是一种非常有效的提高系统性能的手段。定义组工组列表的方法很简单，我们只需要创建一个"特殊的"用户ID，如：TEAM_A，逻辑上它相当于一个角色"Role_A"。然后设置某用户属性的Authrization Tab中的Person: Workitem属性为TEAM_A。这样，在流程运行过程中，将会只有一个工作项产生，而所有对TEAM_A（组工组列表）的工作项有权限的用户都可以看到此工作项，并转移给自己执行，如图8所示。
图表 8
3 与其他应用的整合
在使用MQWF的时候，大家很关心并且经常遇到的一个问题就是MQWF如何与其他应用系统进行整合，如何与外部系统进行接口？MQWF解决这个问题的有效途径就是通过UPES与XML Interface。
MQWF通过XML Interface与外界系统进行双向交互，一方面，外界可以向WF发送XML消息来向Workflow引擎发送请求，比如：启动某一个流程；另一方面，MQWF可以向外界发送XML消息，通过UPES来处理该消息。UPES是User Program Execution Server的简称，它对应着MQ系统中一个队列，如果我们定义了UPES队列(UPES queue)，MQWF便会向该队列发送XML消息，我们需要通过应用程序来读取该队列，并对其进行处理。
3.1 XML Interface
WF向UPES队列发出的消息主要有ActivityImplInvoke, ActivityExpired和TerminateProgram三种类型。用户需要对这三种消息都加以适当的处理，比如，当WF向UPES发出了ActivityImplInvoke消息之后，当该Activity超时的时候，流程引擎会进入下一个Activity。紧接着，WF会向UPES发出ActivityExpired消息，我们在UPES的实现当中必须处理此消息，以便于通知超时的那支应用不必再进行继续处理，更进一步而言，我们甚至要回滚该应用，因为从WF的角度而言，它认为这个Activity没有被执行。
如前所述，WF的XML接口是双向的，我们可以直接向WF引擎的系统队列EXEXMLINPUTQ发送不同类型的消息，从而向WF获得不同的服务。这些消息大致有以下几种：ProcessTemplateCreateInstance，ProcessTemplateCreateAndStartInstance，ProcessTemplateExecute，ProcessInstanceDelete，ProcessInstanceRestart，ProcessInstanceResume，ProcessInstanceStart，ProcessInstanceSuspend，ProcessInstanceTerminate等，其中最常用的是ProcessTemplateCreateAndStartInstance，可以利用它来从外部创建并启动流程实例。XML接口提供了用于操作流程实例和流程模板的功能，它不包含全部的MQWF API，例如，它不具备查询任务列表或流程监控的功能。
利用XML向UPES发送消息时需要注意的一个问题就是权限的问题，根据来判断用户对流程模板以及流程实例的权限呢？这里，WF是利用消息的消息描述符，即MQMD结构中的UserIdentifier字段来作为MQ Workflow中的Person用户来进行权限校验的。因此，当你想MQ 队列发送消息时，一定要设置MQMD的该字段，并且在打开队列的选项MQOO中设置MQOO_SET_INDENTITY_CONTEXT选项。
3.2 UPES的使用
定义UPES的方法如下，
1） 首先，在Buildtime的Network Tab中，为你自己的本地系统创建一个名称为WEBCRED的User-Defined Program Execution Server（用户自定义的程序执行服务器），在其Message Queueing Tab中，输入你的队列管理器的名称FMCQM，以及消息队列的名称WebCreditInput，需要注意，WF自己并不会自动为你建立该队列，需要你在MQ系统中，建立该队列，同时遵循大小写敏感的命名规则。
图表 9
2） 其次，在流程模型的Activity属性定义中，编辑其执行属性，去掉User program execution agent的缺省选项，选择你指定的Program Execution Server，即前面定义的UPES，例如：WEBCRED.FMCSYS.FMCGRP。
图表 10
至此，UPES就配置完成，可供使用了。关于XML消息的具体内容，我们在此就不再举例了。
4 WebClient
WF为我们提供了两种客户端方式来登录服务器，通过客户端我们可以对流程模板、流程实例、任务列表、任务项等进行各种操作，这两种客户端分别是Custom Client（WF的传统客户端）和WebClient（基于浏览器的Web客户端）。随着Java和Web应用的普及，大家越来越多地采用WebClient的瘦客户端方式。
为了使用WebClient，来自动地创建并启动某个流程实例，我们需要创建一个"Starter"用户，WebClient是使用该用户来创建并启动流程实例的。
当使用WebClient时，与各个Activity对应的应用程序的物理实现是与Activity同名的一些JSP，所以通常情况下，你不需要定义对应于Activity的Program的物理实现，然而，作为一个最佳实践，我们建议大家将program的物理应用设定为：fmcnshow.exe，大家知道，fmcnshow是WF自身提供的一个例子程序，它可以读取Input container的各个字段的数值，可以为Output Container的各个字段赋值，可以设置应用程序的返回值。在使用WebClient时，将Activity的Program设定为fmcnshow.exe的好处在于：即使你的WebClient由于配置或其他原因暂时不可用时，你同样可以使用Custom Client来测试你的流程。
使用WebClient的另外一种常见的需求是，在某些情况下，你可能希望既采用WebClient，又希望Server上的某些传统应用能够被调起，这时，需要我们手工地启动PEA。大家知道，PEA(Program Excution Agent)在WF中有着非常重要的作用，当我们启动Custom Client，登录到WF的管理服务器(Administration Server)的时候，WF的PEA便会自动启动，它负责调起客户端的应用。手工启动PEA的步骤和配置方法如下：
在Buildtime中，编辑Activity的属性，在Control Tab中，去掉"Program activities can be checked out"的选项，这是与使用WebClient的不同之处：在WebClient中，你要允许检出（check out）任务项。
在服务器上手工启动PEA，方法是使用fmcxspea -u=admin -p=password命令，停止PEA的方法是使用fmcxpsd命令。
5 Global Data Container和AuditTrail的使用
从版本V3.3.2开始，WF增加了一个新的功能，叫做Global Data Container（全局数据容器），要注意的是，大家不要从它的名称上产生误解，Global Data Container（简称GDC）中的字段是不能被设置的，它仅仅是用来将与流程相关的数据记录日志之用，这里所说的日志即指Audit Trail(审计追踪)。在你的模型设计中，你不能读取GDC的数值，但是你可以通过API来读取它。
从性能角度需要考虑的是，如果你在流程中定义了GDC，GDC中的数据将被记录日志到系统的FMC.AUDIT_TRAIL表中，因此，用户一定要合理设计GDC的字节大小，因为对数据库的操作将直接影响系统的性能。
除了审计功能之外，GDC的另外一个重要作用在于，你可以利用GDC中的有关字段作为Worklist（任务列表）的sort(排序)和filter（过滤）条件，例如，设定某些条件来限制某用户可以看到的任务项。
在WF的流程实例的运行过程中，WF可将某些事件信息记录到Audit Trail(审计追踪)当中，这些追踪信息可以记录到数据库中，也可以XML的格式记录到MQ的消息队列中。追踪信息包括Object（产生事件的实体，如：Process, Activity, WorkItem, Block, Container等），Event（具体的事件类型），ProgTempName（当前的流程实例对应的流程模板名称）等。Audit Trail共有三个选项，即Off, Condensed, Full。如果选择Condensed level，GDC的数据将不被计入Audit Trail中，为此，我们可以使用Full选项。同时为了避免大量的信息被计入审计，我们可以设定Audit Trail的过滤条件，如在FDL中，指定：FULL AUDIT_TO_DB FILTER AUDIT_TO_DB list of events，这样可以减少审计追踪的信息量。
关于作者  | | | 娄丽军，IBM公司软件部售前工程师，1998年加入IBM公司软件部，四年来一直从事IBM通讯及业务整合中间件(WebSphere Business Integration家族)产品的技术支持工作，是软件部从事该领域技术支持时间最长的工程师之一，拥有WebSphere Business Integration相关的产品经验，这些产品包括WebSphere MQ家族的所有产品：MQSeries, MQ Integrator, MQ Workflow以及CrossWorlds等，并具有很多大型项目的支持经验，曾参与国家税务总局，人民银行清算系统、华夏银行电子联行系统、中国联通计费系统、海关与国家税务总局互连系统，以及公安部、铁道部、中信实业银行、电信等重要客户的有关项目的技术支持。 |
对本文的评价
| 
