级别： 中级 Kurt Lind (klind@de.ibm.com), 顾问软件工程师, IBM
2008 年 3 月 17 日 
本文描述用于业务流程和人工任务的基于实例的授权和人员解析的 Business Process Choreographer 编程模型。本文解释如何使用人员解析创建工作项（工作项是基于实例的授权的核心构件），如何使用人员谓词建模授权规则，在部署时如何转换这些谓词，以及如何在运行时将其用于人员解析。
来自 IBM WebSphere Developer Technical Journal.
引言
Human Task Manager 是一个 IBM® WebSphere® Process Server 组件，它支持人与 Web 服务和业务流程之间的交互。通过与用于编排业务流程的 Business Flow Manager 结合，Human Task Manager 为执行涉及人工的业务流程提供了强有力的支持。这两个组件共同构成了 Business Process Choreographer。Business Process Choreographer 的主要功能之一是能够通过考虑业务上下文为业务流程和人工任务提供基于实例的授权。这使您可以在审核或审批流程中建模复杂的授权规则，如四眼原则，这是标准 J2EE™ 授权方法的主要增强，该方法仅支持基于方法定义静态身份验证，而不考虑业务上下文。基于实例的授权依赖于要执行的人员解析，执行该解析可以将人员分配到各种角色中，以便用于以后的授权检查。
尽管授权规则是为任务模板建模的，但这些规则对于基于该模板的每个人工任务或业务流程实例可以有不同的行为，这是因为它们在将人员分配到授权角色时可以考虑业务上下文数据。
本文描述 Human Task Manager 人员解析的编程模型，前者为基于实例的授权提供访问控制列表。本文首先介绍编程模型，然后讨论如何为人工任务建模授权规则，应用哪些缺省值，以及如何继承授权。最后，本文将解释如何配置人员解析插件和人员查询结果刷新守护进程。
本文假定您已熟悉以下白皮书所述的 Business Process Choreographer 概念、体系结构和编程模型：WebSphere Process Server V6 Business Process Choreographer：概念和体系结构与 WebSphere Process Server V6.0 Business Process Choreographer 编程模型。此外，在继续阅读本文之前，强烈建议您阅读本系列文章的第 1 部分。
编程模型
人员解析（也称为员工解析）确定将哪些用户分配到人工任务或业务流程的特定授权角色，以及发送哪些电子邮件地址升级通知。人员解析由人员支持服务（也称为员工分配服务）和人员解析插件（也称为员工目录插件）执行，二者一起提供人员信息解析的抽象层。人员存储库是一个外部人员目录，如 LDAP（轻量级目录适配器协议），或者是一个为 IBM WebSphere Application Server 安全配置的存储库。
在设计人工任务和具有人工交互的业务流程时，对组织信息引用的封装是一个重要考虑事项。尽管人工任务和流程通常相对稳定，但关联的组织信息却在不断变化。例如，员工被分配到新项目中或者升迁，新聘员工加入现有团队中，或者员工临时外出并要求接替人员。
可以通过两种方法将业务流程逻辑与关联的组织模型区分开：
-
基于组或搜索查询定义人员查询。被查询的组织结构存储在外部人员存储库中，如 LDAP。
-
基于人工任务或业务流程上下文的变量定义人员查询。一个典型示例是将业务流程的启动者分配到流程中的人工任务。
由于这两种方法互不相关，因此，Human Task Manager 人员解析同时支持这两种方法。例如，您可以根据哪个员工在业务流程中执行了以前的“申请差旅审批”任务，将该员工的经理分配到“差旅审批”任务。
人工任务（间接地说就是业务流程）的授权规则使用所谓的人员谓词（也称为员工分配标准）来定义，它们就是授权规则模板。人员查询谓词是一些针对人工任务授权角色的抽象授权规则，可以在业务流程和人工任务建模期间对其参数化并将其绑定到特定的人员存储库。
建模
图 1 显示的图形说明了如何建模使用人员解析的人工任务和业务流程。
图 1. 建模人工任务和具有人员查询的业务流程
作为任务或流程的建模者，您可以使用 IBM WebSphere Integration Developer 中的任务编辑器创建人工任务。在定义人工任务时，可以选择一个授权角色，如“潜在所有者”，并将其与任务编辑器中提供的谓词集中的一个人员谓词关联。为了支持建模查询详情，人员谓词附带了一组必须填充数据的参数。参数数据可以参考上下文变量，如 %wf:process.starter%。当完成参数值的填充时，即可部署授权规则。得到的参数化人员谓词存储为人工任务模型的一部分。
对于每个任务，还要指定人员解析插件配置 JNDI（Java 命名和目录接口）名，它是指一个人员插件配置（也称为人员目录配置），该配置将用于人员谓词部署，并在以后的运行时中执行部署的人员查询。缺省情况下，将使用 UserRegistry 人员解析插件配置。结果任务或流程模型导出为 J2EE 企业存档 (EAR) 文件，可以将其部署在WebSphere Process Server 安装上。
Process Choreographer 提供了一组缺省的人员谓词，可以将其用于标准的人员查询。您可以扩展谓词集和定义更符合需要的谓词。管理员负责定义和自定义人员查询谓词及其关联的映射 XSLT 文件，因此他们需要对目标人员存储库有深入的了解。
在完成建模人工任务和业务流程之后，便可以将其组装，并准备好将其作为 EAR 文件部署到运行时服务器。
部署
图 2 中的示意图描述了部署步骤和涉及的角色。
图 2. 部署人工任务和具有人员谓词的业务流程
当 WebSphere Application Server 管理员部署人工任务或业务流程模型 EAR 文件时，人员支持服务会将参数化人员查询谓词转换为特定于插件的人员查询。此步骤涉及 XSLT（可扩展样式表语言转换）谓词映射文件。XSLT 文件与一个人员插件配置关联，该配置通过使用任务模型中指定的相应 JNDI 名称绑定到人工任务。
在 XSL 转换将参数化人员谓词映射到人员存储库模式和特定于插件的查询语言后，部署过程接着将验证这些查询并将其部署到人员解析插件中。Human Task Manager 通过其人员插件配置访问人员解析插件，它与访问 XSLT 文件所使用的配置构件相同：
- 在管理控制台中，特定于人员存储库的人员解析插件由人员插件提供程序（也称为员工目录提供程序）表示。
- 每个人员插件提供程序必须至少有一个人员插件配置。
- 每个配置都具有
- 一个用于定位自己的 JNDI 名称，该名称在建模人工任务时指定。
- 一个到 XSLT 谓词映射文件的引用，该引用将参数化谓词转换为特定于插件的人员查询语言。
- 一组用于 LDAP 插件配置的配置属性，例如，该属性包含一个指向人员存储库 LDAP 服务器的提供程序 URL。
在部署之前，WebSphere Application Server 管理员应确保用于人工任务或业务流程模型的人员插件配置的可用性。WebSphere Process Server 附带了三个特定于人员存储库的人员解析插件。WebSphere Portal 提供了用于 WebSphere Member Manager 的第四个插件。缺省人员插件配置可用于每个插件。如果缺省配置与系统参数不匹配，则可能需要为 LDAP 或 WebSphere Member Manager 插件提供程序创建自己的插件配置。如果希望使用自定义的 XSLT 谓词映射文件，请创建一个引用您的 XSLT 文件的新人员插件配置。
 | | 缺省 XSLT 映射文件可能随产品一起更新，如果您使用的不是自己的映射文件副本，则可能会替换您的更改。 |
|
当人员支持服务完成将参数化人员谓词转换为特定于插件的查询时，人员解析插件就部署了结果人员查询，部署构件会存储在 Business Process Choreographer 数据库中，并可以在运行时供人员解析使用。
人员解析
图 3 中的示意图描述了在运行时的人员解析。
图 3. 解析人员查询
例如，在运行时，实际的人员解析是在任务开始时检索人工任务的潜在所有者。授权管理从数据库中检索存储的人员查询规范，解析由此查询引用的上下文变量集，并调用人员支持服务来解析它。人员支持服务选择合适的人员解析插件并向其委派人员解析。
人员解析插件将查询的上下文变量引用替换为具体的值，然后调用人员存储库的 API 方法来检索用户 ID 或组 ID 列表，并将人员查询结果返回到授权管理。
如果注册了人员查询结果后处理器插件（也称为员工分配后处理器插件），它将由此人员查询结果和一组上下文数据调用，该插件提供了改变结果的可能性。例如，此插件可以执行对所涉及人员的工作负载管理（通过删除具有高工作负载员工的用户 ID），或添加其他员工的用户 ID，来提高整体业务流程的性能。此插件甚至可以更改人员查询结果的类型，例如，从用户 ID 列表更改为一个组 ID，反之亦然。修改的人员查询结果然后返回到授权管理。
授权管理将人员查询结果转换为 Business Process Choreographer 数据库中存储的所谓的工作项。工作项为人员解析结果构建一个可用于 Business Process Choreographer 授权的缓存。这样，不用对每个授权请求都查询包含组织模型的人员存储库，而只是在第一次解析授权规则时或者在工作项中缓存的人员查询结果过期或刷新时才查询。
工作项缓存的内容在以下两种情况下用于基于实例的授权：
- 当调用应用基于实例授权的 API 方法时。例如，
claim() 方法。
- 用于隐式或显式过滤
query() 方法的结果集。调用方仅接收其具有适当工作项的潜在结果集的行。
当调用诸如 claim() 的 API 方法时，将执行授权检查，以验证是否允许此用户执行该操作。授权检查将登录用户的用户 ID 或组成员列表与工作项缓存的内容相比较。（注意，此检查是区分大小写的。）
对于用户工作项，调用用户的用户 ID（调用方主体名）将与所有用户工作项的用户 ID 相比较，这些用户工作项与调用了 API 方法的主业务对象（例如，人工任务）关联。如果发现某个工作项与此用户、所选业务对象和允许调用此 API 方法的预定义授权角色相关联，则会授予权限。
对于组工作项，调用用户的组成员列表将与所有组工作项的组 ID 相比较，这些组工作项与调用 API 方法的主业务对象（例如，人工任务）关联。如果发现某个工作项属于此用户所在的组，并且该组与所选业务对象和允许调用此 API 方法的预定义授权角色相关联，则会授予权限。
J2EE 角色 BPESystemAdministrator 和 TaskSystemAdministrator 的成员始终有管理员权限，并被视为对每个业务对象有管理员工作项。J2EE 角色 BPESystemMonitor 和 TaskSystemMonitor 的成员始终有阅读者权限，并被视为对每个业务对象有阅读者工作项。
如果您使用 query() API 方法，则可以隐式将适当工作项检查添加到数据库查询来执行授权。此授权检查可以过滤结果集，并确保调用方只能看到其具有适当工作项的这些结果集。由于每个授权角色都可以授予阅读者权限，因此调用方由于任何分配原因（授权角色）而拥有匹配的工作项就足够了。匹配的工作项可以是与调用方主体名对应的用户工作项，也可以是与调用方所在组之一对应的组工作项。（此检查也是区分大小写的。）J2EE 角色 BPESystemAdministrator、BPESystemMonitor、TaskSystemAdministrator 或 TaskSystemMonitor 的成员可以始终查看每个结果集行。（请参阅参考资料，了解有关 query() API 方法的详细信息。）
传输工作项
有时，您可能会出于多种原因需要修改在人员解析过程中创建的员工分配，如动态管理员工的工作负载、业务关键团队成员的缺席等。
对于这些情况，Business Process Choreographer 为您提供了一组运行时 API 方法，您可以使用这些方法修改在人员解析过程中在实例对象（如人工任务、升级、流程实例及其活动）上创建的工作项。这些 API 方法支持：
- 将工作项从一个人传递到另一个人。
- 将组工作项从一个组传递到另一个组。
- 在一个实例对象上为另一个人创建一个工作项。
- 删除某个人的工作项。
注意，上述操作需要遵循下列限制：
- 不允许删除最后一个管理员工作项，这是因为相应的实例对象必须保持能够管理。
- 不支持创建、传输或删除“Everybody”工作项。
- 工作项的创建、传输和删除必须在原始对象上进行。由于角色继承而分配的工作项不能在继承该工作项的对象上传输，而只能在发生人员解析的原始对象上传输。例如，流程管理员工作项只能根据流程实例 ID 或流程管理任务 ID 进行传输，而不能根据内联人工任务 ID 或流程活动 ID 传输，因为在这些对象上，存在工作项仅是为了反映角色继承。
- 出于安全原因，不允许每个人都能够传输每个工作项。这适用以下规则：
- 管理员可以向任何人创建、传输或删除每个授权角色的工作项。
- 发起人可以向以下任何人创建、传输或删除这些授权角色的工作项：潜在所有者、潜在启动者、发起者、阅读者、编辑和升级接收者。
- 任务所有者可以将其自己的工作项传输给其他潜在所有者或传输给管理员。
- 任务启动者可以将其启动者工作项传输给其他潜在启动者或传输给管理员。
- 传输工作项还可能由于拥有流程对象的不兼容状态被禁止。例如，在任务完成之后，将不允许您传输任务所有者工作项。
- 在缺省情况下，将验证工作项传输或创建的目标用户 ID。不验证组工作项传输的目标组 ID。
- 在向新升级接收者添加或传输工作项时，将不会向此人发送任何电子邮件，即使在升级操作是电子邮件时也如此。
当人员解析结果被刷新时，将重新应用其传输历史。因此，人员解析刷新不会重设一个工作项的创建、传输或删除。
使用任务编辑器建模授权规则
WebSphere Integration Developer 为您提供了一个功能强大的编辑器，即人工任务编辑器（图 4），您可以使用该编辑器为业务流程和人工任务建模授权规则。可以使用人员谓词为预定义的授权角色集定义授权规则。
图 4. 人工任务编辑器
通过在编辑器画布的 Staff settings 下选择您所选的授权角色，可以定义授权规则。然后，Verb（或员工组）将显示在人工任务的属性窗格。
通过单击任务窗格上 Receiver settings 旁边的关联图标，可以将一个角色添加到人工任务。以下角色可用于人工任务：
-
Potential instance creator 指定谁可以从此模型中创建任务实例。在创建任务实例（作为在任务创建过程中的第一个角色）前，将对其解析以检查授权。
-
Potential owner 指定谁可以对此任务进行操作（通过声明和完成任务）。它在任务开始过程中被解析为第二个角色。
-
Potential starter 指定谁可以启动与此任务关联的服务。它在任务创建过程中被解析为第二个角色。
-
Administrator 指定谁可以管理任务和对任务执行每个允许的操作。它在任务开始过程中被解析为第一个角色。
-
Editor 指定谁可以对主张的任务操作，但不能影响任务的生命周期。它在任务开始过程中被解析为第三个角色。
-
Reader 指定谁可以看到所有任务属性和关联对象，但不能更改它们。它在任务开始过程中被解析为第四个角色。
并不是每种角色对每种类型的任务都适用。表 1 显示了哪种任务支持哪种授权角色。
表 1. 授权角色及人工任务对它的支持情况
| 授权角色 | 参与任务 | 原始任务 | 纯人工任务 | 管理任务 |
|---|
|
潜在实例创建者
| X | X | X | -- | |
潜在所有者
| X | -- | X | -- | |
潜在启动者
| -- | X | -- | -- | |
管理员
| X | X | X | X | |
编辑
| X | -- | X | -- | |
阅读者
| X | X- | X | X |
对于内联原始任务，潜在实例创建者角色与潜在启动者角色相同。内联任务与其所属的业务流程紧密耦合。它们的生命周期通常由流程实例确定，并且它们可以访问流程上下文数据。只有使用 Human Task Manager API 启动的内联原始任务管理自己的生命周期。独立任务作为服务组件提供，独立于最终围绕的业务流程，因此管理自己的生命周期并且无权访问流程上下文。
当为人工任务建模升级时，您可以定义人员，指定谁将使用升级接收者角色查看升级和接收关联的通知。
业务流程角色是使用与流程或它的某些活动关联的人工任务定义的：
-
要定义 business process readers 和 administrators，请在没有选择特定的流程活动时，在 BPEL 编辑器的 Human Task 属性选项卡上选择流程管理任务，然后在这里为这两个角色定义授权角色。
-
要定义 potential starters for a Receive or Receive Choice activity 或 "on event" Event Handler，请在流程模型上选择该活动，并在 Human Task 属性选项卡中单击 Human task 链接，然后在这里为潜在启动者定义授权规则。
-
要定义 administrators for invoke activities，请在流程模型中选择该活动，并在 Human Task 属性选项卡中单击 Human task 链接，然后在这里为管理员定义授权角色。
-
要定义 default administrators for process activities，请在没有选择特定的流程活动时，在 BPEL 编辑器的 Human Task 属性选项卡上为该活动选择缺省管理任务，并在这里为此角色定义授权角色。
业务流程将始终使用流程启动者的授权方导航。这意味着，由调用活动表示的服务将始终由使用此用户的安全上下文调用。因此，当您在业务流程中作为调用活动建模独立参与人工任务时，需要确保能够实例化业务流程的所有人员都作为潜在实例创建者分配到此任务。否则，流程引擎在运行时可能无法调用此任务。
当您在人工任务编辑器中选择了该角色时，Verb 选项卡将显示在人工任务的 Properties 窗格中。图 5 显示了此选项卡的详细信息，您可以在该选项卡中建模一个授权规则。
图 5. 人员谓词定义
您可以从下拉框中选择您所选的人员谓词。下方的描述字段简要概述了所选谓词的功能和人员插件提供者支持。
底部的表列出了由所选谓词支持的参数。必需参数在该表的第一列中标上了星号。在 Value 字段中输入您选择的参数值。有些谓词参数有一组与之关联的提示，可以帮助您输入适当的值。在单击支持提示的参数的 Value 字段时，将在该字段的右侧显示一个按钮。单击此按钮可以看到一组提示（图 6）。
图 6. 谓词参数提示
对于每个人工任务，您可以选择或输入您所选的人员插件配置 JNDI 名，它将在运行时解析您定义的授权规则。在人工任务编辑器中单击人工任务窗格，可以看到人工任务属性选项卡。单击 Details 选项卡可以看到插件配置 JNDI 名的可编辑下拉框。您可以从下拉列表中选择缺省项，也可以输入自定义的人员插件配置的 JNDI 名。
表示您的组织规则的参数化人员谓词是作为人工任务模型的一部分存储的，并将与人工任务或业务流程模型 EAR 文件一起部署。当完成建模一个流程或任务时，您就可以组装它，并将其部署到 WebSphere Process Server 运行时，后者提供了一组预配置的人员解析插件，可以使用这些插件为这些授权规则执行人员查询。
人员查询谓词
WebSphere Integration Developer 中的人工任务编辑器附带了一个预定义的人员查询谓词集，可以提供对基本授权规则的支持。您可以扩展和改写该谓词集以更好地适应您的项目需求。
有些人员谓词不受所有人员插件提供程序的支持。例如，Manager of Employee 谓词仅对 LDAP 人员插件提供程序可用。有关人员谓词及其参数的详细信息，请参阅参考资料中的 WebSphere Process Server 信息中心。
下面是人工任务编辑器提供的预定义人员谓词的摘要：
-
Department Members 可让您查询部门的成员。
-
Everybody 可分配每个通过身份验证的用户。
-
Group 可以分配整个组，而不解析其成员（后期绑定）。此谓词为整个组创建一个单一的组工作项，而不是为每个组成员创建用户工作项，因此可以有效地支持大型组。（必须在管理控制台中为此谓词启用组工作项，因为在缺省情况下组工作项是被禁用的。）对于小型组，或者您的用户是许多组中的成员时，则使用 Group Members 谓词更合适，这是因为在启用组工作项时，授权检查会更复杂，并且成本会随着人员所属的组数增加而增加。
-
Group Members 用于查询一个组的成员。组成员使用人员查询解析（早期绑定）。对于大型组，最好使用 Group 选项卡。
-
Group Members without Filtered Users 用于查询一个组的成员，但从结果集中删除一组用户。要删除的那组用户由搜索过滤器定义。
-
Group Members without Named Users 用于查询一个组的成员，但从结果集中删除一组用户。要删除的该组用户作为谓词参数输入，但最好使用上下文变量。此谓词支持四眼原则。
-
Group Search 可让您基于属性匹配搜索一个组。此谓词解析它发现的组成员。
-
Manager of Employee 检索给定姓名的人员的经理。
-
Manager of Employee by user ID 检索给定用户 ID 的人员的经理。此谓词在与上下文变量一起使用时非常有用。
-
Native Query 可让您基于人员插件提供程序特定参数定义本机查询。可以使用此谓词定义简单的自定义查询。对于更复杂的自定义人员查询，则应定义一个新谓词。
-
Nobody 不分配一般用户。只有继承用户适用于此授权角色。对于具有强制人员分配的角色，将另外应用空结果集的缺省值。
-
Person Search 基于属性匹配搜索人员。
-
Role Members 在人员存储库中查询某个角色的成员。
-
Users 分配按姓名标识的用户。（在人工任务和业务流程透视图中，不建议在任务模型中硬编码用户名，而建议使用更动态的用户分配方法，以便在分配的人员更改组织时不会失败。）
-
Users by user ID 分配按其用户 ID 标识的用户。此谓词在与上下文查询一起使用时非常有用，例如，在从上下文变量分配用户 ID 时：
Users by user ID [UserID='%wf:process.starter%']
-
Users by user ID without Named Users 用于分配按用户 ID 标识的一个或多个用户，但从结果集中删除一组用户。要删除的该组用户作为谓词参数输入，但最好使用上下文变量。此谓词支持四眼原则；例如，它分配前一流程活动中的一组潜在所有者，但删除前一活动的所有者（两者都使用上下文变量）。
这些谓词中有些可能返回要分配到授权角色的潜在较大用户 ID。由于此类大型人员分配在业务流程中通常意义不大，但会影响整个性能，因此 Human Task Manager 提供了一个阈值参数来限制返回的用户 ID 的数量。在缺省情况下，该阈值参数设置为 20 个用户。如果您希望使用更大的结果集，则可以在与您的人员插件配置关联的 XSLT 文件中自定义此参数。
电子邮件地址的人员查询谓词
在建模具有升级操作电子邮件的升级时，一些其他人员查询谓词用于解析升级接收者的电子邮件地址。在 WebSphere Integration Developer 中使用任务编辑器时看不到这些谓词，但当创建新谓词时或者创建临时任务时，了解适用哪些规则非常重要。
为了选择解析升级接收者电子邮件地址的正确谓词，任务编辑器将搜索与升级接收者谓词具有相同名称的谓词，前缀为“Email Address for”并具有相同的参数集。
- 如果存在此谓词，将使用该谓词并将接收与升级接收者谓词相同的参数。
- 如果不存在此谓词，任务编辑器将使用 Email Address for Users by user ID 谓词，并将其作为输入参数传递到变量
%htm:escalation.receivers%。此谓词接收每个升级接收者的用户 ID，搜索相应的用户记录，并从此用户记录中检索电子邮件地址。此谓词会始终工作，但由于搜索数量非常大，它可能比本机电子邮件谓词实现慢。
此算法在任务编辑器的后台实施，通常不会看到它，但当创建临时任务或新任务查询谓词时，您会注意到它。在创建临时任务时，应根据上述算法为 eMailReceiver 选择人员谓词。在创建新任务查询谓词时，请考虑创建相应的电子邮件谓词。如果实施此方法比按用户 ID 搜索每个用户快，就值得这样做。
LDAP 人员解析插件本身支持以下用于解析电子邮件地址的人员查询谓词：
- Email Address for Department Members
- Email Address for Group Members
- Email Address for Group Members without Filtered Users
- Email Address for Group Search
- Email Address for Role Members
- Email Address for Users
- Email Address for Users by user ID（缺省电子邮件人员查询谓词）。
建模基于上下文的授权规则
在定义多个复杂的授权规则（如四眼规则）时，您需要访问流程上下文，以便排除前一任务的所有者并强制实施此原则。Human Task Manager 为您提供了使用上下文变量访问周围上下文的权限，该变量可以包括在人员谓词参数中，如上图 6 所示。
此处的上下文是指前一人员解析中的数据，任务输入或输出消息中的值、自定义属性等。对于内联任务，可以使用周围业务流程的其他上下文。上下文变量是指使用百分号 ( % ) 并具有以下标记形式：
%context variable%
例如：%htm:task.originator%。不允许在变量名内部使用百分号。如果需要在可以使用上下文变量的字符串内部使用百分号，则应使用两个百分号 ( %% )。上下文变量还可以包含 XPath 表达式。如果 XPath 表达式本身包含一个百分号，则必须按 XML 的指定方式将其转义（使用 %）。
并不是所有上下文变量的值在任务或升级生命周期中始终都可用。例如，任务所有者仅在声明任务之后才可用。如果在定义变量之前使用了该变量，则不会替换此变量。例如，在为变量替换处理以下字符串时：
The task owner is %htm:task.owner% and needs to review the document until %htm:property.reviewCompletionTime%.
任务所有者已经可用，但自定义属性 reviewCompletionTime 尚未设置，替换之后的结果将如下所示：
The task owner is John and needs to review the document until %htm:property.reviewCompletionTime%.
上下文变量可能解析为单个值或多个值。单值上下文变量计算为参数上下文中替换的字符串，例如，cn=%htm:task.originator% 计算为“sarah”。多值上下文变量，如 %htm:task.administrators% 计算为字符串阵列。（多值上下文变量的使用限于每个人员查询元素一个。）
上下文变量的示例：
%htm:task.owner% 解析到声明了任务实例的人员的用户 ID，因此成为该任务的所有者。
%htm:task.potentialOwners% 解析到此任务实例的潜在所有者集（由前一人员查询分配）。
%htm:task.property.customPropertyName% 提供对人工任务的自定义属性的访问。前导 htm:task.property. 是一个常量分隔符，后跟自定义属性的名称。
%htm:input.[messagePartName][\XPathExpression]% 解析到任务输入消息，或任务输入消息的各部分。前导 htm:input. 是一个常量分隔符，后跟要访问的消息部分的可选名称。此外，还可以后跟一个 XPath 表达式，仅访问消息（部分）的特定元素。注意，XPath 表达式必须解析到一个字符串、字符串阵列、具有有用 toString() 方法的 Java 对象或具有有用 toString() 方法的 Java 对象阵列。例如，%htm:input.\admins% 解析到输入消息中名为 admins 的字符串阵列元素。由于这是单个部分构成的消息，因此未指定部分名称。
内联人工任务可以访问流程上下文，因此它们也可以访问流程上下文变量。
它们可以访问简单的流程上下文变量，如 %wf:process.administrators% 或 %wf:activity(activityName).owner%，其中“activityName”表示所有者将解析到的活动的名称。
它们可以使用表达式 %wf:property.customPropertyName% 访问流程自定义属性，其中 wf:property. 是一个常量部分。
它们还可以使用以下表达式访问流程变量或流程输入消息：%wf:variable.[variableName]\messagePartName[\XPathExpression]%，其中 wf:variable. 是一个常量部分。消息部分的名称对接口类型的变量是强制性的，doclit/wrapped 样式的接口的缺省值是“<operationName>Parameters”。请检查您的消息 WSDL 以了解确切的部分名称。对于数据类型的接口（业务对象），部分名称是可选的。记住，在为流程管理任务计算上下文变量时，一定不要指定变量名，因为该变量名将直接从流程输入消息中获取。还要知道，从流程输入消息指定人员解析结果可能会导致安全漏洞。
以下示例介绍了如何访问流程变量：表达式 %wf:variable.ReadersVar\\readers% 访问名为“ReadersVar”的流程变量的字符串阵列属性“readers”。
以下示例介绍了如何访问流程输入消息：表达式 %wf:variable.\operation1Parameters\reader% 访问输入消息部分的字符串类型的元素“reader”。"operation1Parameters"
要在 WebSphere Integration Developer 中找到您的 XPath 表达式的正确部分名称，请按下列步骤操作：
- 选择描述您的变量或输入消息类型的 WSDL 文件。该文件通常有您的流程模型名和 .wsdl 后缀。否则，请检查正确的 WSDL 文件的变量定义，可以通过以下方法找到：单击该变量，然后在
Properties 面板的 Details 选项卡上，按 Browse 按钮查看哪个 WSDL 文件定义了该变量。
- 使用 WSDL 编辑器在源视图中打开 WSDL 文件，并检查与您的流程输入消息或变量关联的操作。通过在初始接收活动上单击可以找到输入消息操作，并且在 Properties 面板的 Details 选项卡上可以看到所选的操作。另外，通过单击变量可以找到与该变量关联的操作，并且在 Properties 面板的 Details 选项卡上可以看到所选的操作。在这里还可以看到该变量使用的是输入消息类型还是输出消息类型。
- 该操作定义消息名。检查声明该部分的消息定义。
- 部分名称是在定义 XPath 表达式时必须输入的字符串。
在本示例中，您会找到定义输入消息 (operation1Request) 的操作 (operation1)。(operation1Request) 消息使用“operation1Parameters”名称定义一个单一部分。
...
<message name="operation1Request">
<part element="tns:operation1" name="operation1Parameters"/>
</message>
<message name="operation1Response">
<part element="tns:operation1Response" name="operation1Result"/>
</message>
<portType name="ApprovalProc">
<operation name="operation1">
<input message="tns:operation1Request" name="operation1Request"/>
<output message="tns:operation1Response" name="operation1Response"/>
</operation>
</portType>
... |
为临时任务和任务模板建模授权规则
当使用运行时 API 建模临时人工任务时，将使用 Eclipse Modeling Framework (EMF) API 来创建任务模型作为 EMF 对象和属性的树。人工任务的授权规则是使用 TStaffSettings 类建模的，它聚合了一个任务的所有授权角色，您可以在其中为每个支持的授权角色附加授权规则。人员设置由主要 TTask 对象聚合。升级的授权规则直接由 TEscalation 类聚合。
分配到授权角色的授权规则使用 TStaffRole 类的相应子类建模。以下授权角色类可用于为人工任务建模授权角色：
- TAdministrator
- TEditor
- TPotentialInstanceCreator
- TPotentialOwne
- TPotentialStarter
- TReader。
以下授权角色类可用于为升级建模授权角色：
- TEMailReceiver
- TEscalationReceiver。
当在任务编辑器中建模人工任务时，编辑器将基于对升级接收者授权角色的选择自动在后台为您创建电子邮件收件人谓词。当创建临时任务模型并使用具有升级操作“>e-mail”的升级时，则必须手动建模电子邮件收件人的人员谓词。有关详细信息，请参阅电子邮件地址的人员查询谓词。
每个 TStaffRole（子）类都聚合一个表示授权规则的谓词对象。您将基于在 WebSphere Integration Developer 任务编辑器中使用的同一组人员谓词创建授权规则。您要建模的谓词的内容与使用任务编辑器创建（基于您的输入）的参数化人员谓词相对应。该谓词是 TVerb 类的一个对象，并有一个名称属性和一个参数对象列表。所选的人员插件配置（XSLT 文件）必须支持谓词名。
参数是 ParameterType 类的对象。它们有两个属性：ID 和值。参数 ID 是显示在任务编辑器中的参数名，并且与所选谓词相对应的 XSLT 模板支持该参数名。参数值正是您要在任务编辑器中输入的值，其中包括上下文变量。
通过输入 JNDI 名称作为主要 TTask 对象的 JndiNameStaffPluginProvider 属性可以为临时任务选择人员插件配置。
人员解析缺省值和授权继承
缺省人员分配
一些授权角色是必不可少的，这些角色上分配了人员。例如，如果没有为人工任务分配管理员，则该人工任务可能会变得不可用。而且，如果参与的或纯人工任务没有分配潜在所有者，则无人执行分配的工作。
因此，Human Task Manager 为特定于每个授权角色的缺失或失败的授权规则定义缺省值。空人员解析结果与失败的人员解析结果同等对待。表 2、3 和 4 显示了哪个缺省值适用于哪个人工任务或业务流程授权角色。
表 2. 业务流程角色的人员解析缺省值
| 业务流程角色 | 角色不在流程模型中定义 | 人员解析失败或返回空结果 |
|---|
|
流程管理者
| 流程启动者成为流程管理员 | 抛出 EngineAdministratorCannotBeResolvedException，并且不启动流程。 | |
流程阅读者
| 无阅读者 | 无阅读者 |
表 3. 内联人工任务和升级角色的人员解析缺省值
| 内联人工任务或升级角色 | 角色不在流程模型中定义 | 人员解析失败或返回空结果 |
|---|
|
任务管理员
| 仅适用于继承 | 抛出 AdministratorCannotBeResolvedException，并且不启动任务 | |
任务编辑
| 无编辑 | 无编辑 | |
任务潜在实例创建者
| 每个人成为潜在实例创建者 | 每个人成为潜在实例创建者 | |
任务潜在所有者
| 每个人成为潜在所有者 | 管理员成为潜在所有者 | |
任务潜在启动者
| 每个人成为潜在启动者 | 每个人成为潜在启动者 | |
任务阅读者
| 仅适用于继承 | 仅适用于继承 | |
升级接收者
| 管理员成为升级接收者 | 管理员成为升级接收者 |
表 4. 独立人工任务和升级角色的人员解析缺省值
| 独立人工任务或升级角色 | 角色不在流程模型中定义 | 人员解析失败或返回空结果 |
|---|
|
任务管理员
| 发起者成为管理员 | 抛出 AdministratorCannotBeResolvedException，并且不启动任务 | |
任务编辑者
| 无编辑者 | 无编辑者 | |
任务潜在实例创建者
| 每个人成为潜在实例创建者 | 每个人成为潜在实例创建者 | |
任务潜在所有者
| 每个人成为潜在所有者 | 管理员成为潜在所有者 | |
任务潜在启动者
| 发起者成为潜在启动者 | 抛出 CannotCreateWorkItemException，并且任务未启动 | |
任务阅读者
| 仅适用于继承 | 仅适用于继承 | |
升级接收者
| 管理员成为升级接收者 | 管理员成为升级接收者 |
授权角色继承
业务流程的管理员希望得到执行此流程中的每个操作的授权，以便能够解决在流程操作中发生的问题。您还希望一些角色从高级业务实体（如流程）向较低实体（流程活动）继承授权。Human Task Manager 使用以下规则提供了直观的授权继承：
- 流程管理员是流程的每个活动、内联任务（包括其子任务和后续任务）或任务升级的管理员。
- 流程阅读者是流程的每个活动、内联任务（包括其子任务和后续任务）或任务升级的阅读者。
- 内联参与任务授权角色的成员在相应的人工任务活动上具有相同的角色。
- 内联原始任务的潜在启动者是相关 Receive 或 Receive Choice 活动的潜在启动者，也是“事件上”的事件处理程序。
- 任务管理员是此任务的每个子任务和后续任务（包括这些任务之一的升级）的管理员。
- 每个任务角色的成员是此任务的每个子任务和后续任务（包括这些任务之一的升级）的阅读者。
- 升级接收者是此任务的升级任务、每个子任务和后续任务（包括这些任务之一的升级）的阅读者。
您不能在低级业务实体上传输继承的工作项；而须将业务实体上分配到人员的工作项直接传输到角色。例如，您可以使用业务流程上的管理员工作项传输流程管理员，但不能传输一个活动上同一用户的管理员工作项或此流程实例的内联人工任务，这是因为它是继承而来的。此规则的基本原理是您不能立刻从直接工作项中区分继承的工作项。您可能认为您可以传输任务管理员，但实际传输的是流程管理员，而这不是您的目的。如果一个人在一个任务上有两个管理员工作项，一个从流程继承而来，另一个是直接分配的；则直接分配的当然可以传输。
另外请注意，人工任务容器和流程容器 J2EE 角色的成员“继承”对其他用户可视的每个业务实体（流程、活动、任务、升级）的权限：当通过 Business Flow Manager API 调用某个方法时，J2EE 角色 BPESystemAdministrator 的成员具有管理员授权，J2EE 角色 BPESystemMonitor 的成员具有阅读者授权。当通过 Human Task Manager API 调用某个方法时，J2EE 角色 TaskSystemAdministrator 的成员具有管理员授权，J2EE 角色 TaskSystemMonitor 的成员具有阅读者授权。因此，尤其是对于同时访问两个 API 的用例，建议您（但不是必需的）向两组角色分配同一组人员和组。
人员插件配置
以上各节通过定义应用什么人员谓词，它在运行时接收哪些输入参数来执行该规则，描述了如何建模授权规则。还需要指定要查询的人员存储库才能执行授权规则。您可以通过输入人员插件配置的 JNDI 名称（作为运行时服务器资源提供）在任务模型中间接地指定人员存储库及其访问参数。Human Task Manager 同时支持多个人员插件配置；您可以为每个人工任务模型指定一个。
人员插件配置确定人员解析在运行时的执行方式。每个配置都有一个唯一的 JNDI 名称，用于将其注册为应用程序服务器资源，并指定：
- 将使用哪些存储库类型（例如 LDAP 或 User Registry）。
- 使用哪个 XSLT 文件将人员谓词及其参数映射到可在运行时执行的具体人员查询。XSL 转换：
- 将人员谓词及其参数映射到与人员存储库类型相对应的 XML 语言（人员插件提供程序）。
- 根据需要调整人员存储库模式的结果查询。例如，这对于每个客户选用一个不同的 LDAP 模式的 LDAP 服务器而言非常必要。
- 所选人员插件提供程序需要的其他自定义属性。例如：
- 要访问的目录服务器的主机名和端口。
- 目录服务器连接的安全设置。
人员插件配置在 WebSphere administrative 控制台的 Resources => Staff plug-in provider 下提供。在此面板上，可以单击您选择的人员插件提供程序，并在打开的屏幕中选择 Staff plug-in configuration，以获取对您选择的插件提供程序可用的人员插件配置列表。从这里，您可以添加、删除或修改人员插件配置。图 7 显示了在选择添加或修改时打开的人员插件配置屏幕。
图 7. 人员插件配置
您可以为插件配置输入一个名称、描述和 JNDI 名称。在创建配置时可以设置 XSLT 文件的位置。JNDI 名称是引用该配置的任务模型的链接并且必须是唯一的。插件配置在部署使用它的任务模型之前必须可用。
如果插件提供程序支持自定义属性，则可以使用 Custom properties 链接访问它们。这将打开另一个面板，可以在其中设置人员插件提供程序支持的属性值。例如，LDAP 人员插件支持一组自定义属性，如 LDAP 提供程序 URL（主机名和端口）。（确保使用人员插件提供程序屏幕公开的 Custom 属性链接；而不是使用人员插件配置屏幕上的链接。）
人员查询结果刷新守护进程
由于每个组织都在不断地变化，所以人员解析结果可能会过期，因此需要在工作项缓存中进行刷新。人员查询结果刷新守护进程（也称为员工分配刷新守护进程）负责刷新那些已过期的人员查询结果。
刷新守护进程定期运行并刷新当时过期的所有人员查询结果。刷新根据与相应工作项关联的人员谓词发生。人员解析将被再次调用，并且新结果存储在现有工作项中。因此，一旦组织发生更改，刷新守护进程可让工作项缓存保持最新。如果以前传输了工作项，将再次应用传输历史记录，因此该刷新不会覆盖以前的传输。
刷新守护进程的行为由两个参数控制：
-
timeout for staff query result 确定最后一次更新后人员查询结果保持有效的时间。当此时段过后，该查询结果可进行更新。
-
staff query refresh schedule 控制何时运行刷新守护进程，以刷新过期的查询结果。
您可以在 WebSphere 管理控制台的面板 Application Servers => <server name> => Human task container 中访问这两个参数。在此面板的编辑字段组 Staff Resolution 中，您可以找到字段 Staff query refresh schedule 和 Timeout for staff query result。使用 WebSphere CRON 日历语法作为字符串值输入刷新间隔（请参阅参考资料）。作为整数输入超时值（以秒为单位），指定新人员查询结果过期后的持续时间。
以下规则适用于人员查询刷新：
- 当刷新工作项缓存时，将不考虑上下文变量的更改；当第一次对此人员查询执行人员解析时，刷新将基于所提供的上下文数据发生。
- 如果原始人员解析没有返回任何结果或者失败，并因此应用了人员解析缺省值，则刷新将应用于人员解析缺省值，而不应用于原始人员查询。
- 还可以使用 WebSphere Application Server 管理控制台或 JACL 脚本 refreshStaffQuery.jacl 手动强制执行人员查询结果刷新，（有关详细信息，请参阅参考资料）。以此方法刷新时，将刷新所有指定的人员查询结果，而不只是过期的结果。
- 通过刷新守护进程、管理控制台或 JACL 脚本执行的刷新不适用于组工作项的用户到组成员关系。用户的组成员关系列表在用户重新登录时刷新。
刷新守护进程仅适用于 WebSphere Process Server V6.0.2 及更高版本。
结束语
Human Task Manager 为业务流程和面向服务的体系结构所涉及的人员提供了功能强大的、基于实例和业务上下文的授权。它可以基于灵活的授权规则执行人员解析查询，并可以缓存查询结果，以获得更好的授权性能。
本文描述了 WebSphere Process Server Business Process Choreographer 规则和基于实例的授权以及人员解析编程模型。其中描述了授权角色及其继承规则和缺省值，如何定义授权规则以及如何解析授权规则以执行基于实例的授权。
致谢
作者衷心感谢同事 Eric Van Norman、Gerhard Pfau 和 Hans Schoen，他们在准备本文的过程中给予了不少帮助。
参考资料 学习
讨论
关于作者 | 
| |
Kurt Lind 曾在德国曼海姆的应用科技大学就读通信工程专业。作为 WebSphere Process Server 团队的一名成员，他负责 Human Task Manager 和业务流程编排安全体系结构的工作。 |
对本文的评价
| 
