21.1 关于基于工作流程的配置信息提供
Identity Manager 的一个主要功能是基于工作流程的配置信息提供，这是管理用户访问组织中安全资源的进程。 这些资源可以包含诸如用户帐户、计算机和数据库之类的数字实体。 在此版本中，受供资源被映射到 Identity Manager 权利。
Identity Manager 可以为大量的供应请求提供服务。 供应请求是用户或系统用于授予或取消访问组织资源的操作。 这些请求可以由终端用户通过 Identity Manager 用户应用程序直接初始化，也可以通过在 Identity Vault (eDirectory) 中响应发生的事件间接初始化。
供应请求需要从组织中的一个或多个人中获得许可权限时，此请求将启动工作流程。 工作流程协调完成请求所需的批准。 某些供应请求需要获得个人批准；而另外一些请求则需要获得多人批准。 在某些实例中，可以不经任何批准完成请求。
某些工作流程需要以顺序方式处理，其中每个批准步骤都按顺序执行。 而其它一些工作流程则支持并行处理。 定义供应请求时，请指定工作流程是支持顺序处理还是并行处理。
Identity Manager 提供一套基于万维网的工具，管理员可以使用此套工具将供应功能构建到用户应用程序中。 使用这些工具可以配置供应请求，也可以管理正在进行的工作流程。 若要配置供应请求，管理员需要创建将资源联结到工作流程的供应请求定义。
21.1.1 高级体系结构
下图显示 Identity Manager 中包含的基于工作流程供应系统的高级体系结构：
以下部分描述此体系结构的所有部件。
供应万维网接口
Identity Manager 用户应用程序提供万维网接口，终端用户通过此接口提交供应请求并在提交后管理这些请求。 用户应用程序还允许应用程序管理员或组织经理指派受托人或代理来供应工作流程。
提示：供应和工作流程操作在 Identity Manager 用户应用程序的《请求和批准》选项卡中可用。
有关受托人和代理的更多信息，请参见部分 21.3, 供应安全性。 有关使用用户应用程序的完整详细信息，请参见《Identity Manager 用户应用程序：用户指南》。
iManager 管理工具
iManager 提供可以用来配置和管理供应请求以及与这些请求相关联的工作流程的插件。
若要配置供应请求，则将其联结到受供资源，指定关联的工作流程运行时特征并使此请求可用。 初始化供应请求后，则可以使用 iManager 查看工作流程进程状态，重指派工作流程内的活动或在工作流程停止时将其终止。
Identity Manager 用户应用程序驱动程序
除了支持终端用户供应资源的请求，Identity Manager 还允许在响应 eDirectory 中发生的事件时初始化供应请求。 Identity Manager 用户应用程序驱动程序监听事件并通过初始化相应的供应请求来进行响应。 这些请求可以又依次初始化工作流程以处理批准进程。 例如，如果进行了这样的配置，Identity Manager 将执行的方案是：向 eDirectory 中添加新用户时，将自动启动预先指定的供应请求和工作流程。
供应系统
供应系统执行所需的所有处理以初始化并完成供应请求。 如果请求需要一项或多项批准，则供应系统依次调用工作流程系统以启动工作流程进程。 给予必需的批准后，供应系统按照请求供应资源。
供应系统维护 Identity Vault (eDirectory) 中可用的和未解决的有关供应请求信息。
若要初始化某个请求或执行所需的处理以完成请求，系统将通过目录提取层访问 Identity Vault。
有关目录提取层的详情，请参见部分 4.0, 配置目录提取层。
工作流程系统
供应请求需要一项或多项批准时，工作流程系统将协调此批准过程。 处理过程中，此流程和这些部件进行交互：
- 工作流程数据库
- 底稿编写引擎
- Audit
- SMTP
- 安全系统
工作流程数据库
要跟踪正在执行的工作流程状态，工作流程系统需将信息储存在数据库中。 此数据库维护有关工作流程进程实例、工作列表（队列）和工作流程地址的信息。 此外，它还储存在执行工作流程进程中添加的任何注释。
底稿编写引擎
只要工作流程包含必须被求值的动态表达式，工作流程系统都将调用底稿编写引擎。 动态表达式可以包含目录提取层中实体的变量、函数、运算符以及参照。
Novell Audit
工作流程系统与 Novell Audit 进行交互以记录有关工作流程进程状态的信息。 在处理过程中，工作流程可能会记录已发生的各种事件的信息。 然后，用户可以使用 Novell Audit 报告工具查看日志记录数据。
有关设置日志记录的详情，请参见部分 5.0, 设置日志记录。 有关控制希望 Identity Manager 用户应用程序生成的日志记录讯息级别的详情，请参见部分 12.0, 日志记录配置。
SMTP
工作流程进程通常会在执行过程中的多个时刻发送电子邮件通知。 例如，将一个工作流程活动指派给一个新收件人时，可能会发送电子邮件。
管理员可以在 iManager 中编辑电子邮件模板，并在工作流程进程中使用此模板。 在运行时，工作流程系统从 eDirectory 中检索此模板并用适合通知的动态文本替换标记。
通过简单邮件传送协议 (SMTP) 处理电子邮件通知。
有关电子邮件通知所需的基本设置步骤，请参见部分 23.3, 配置电子邮件服务器和部分 23.4, 使用安装的电子邮件模板。 有关配置用于工作流程的电子邮件通知的详情，请参见配置工作流程活动。
21.1.2 供应和工作流程示例
假定用户需要一个 IT 系统中的帐户。 若要设置此帐户，用户需要通过 Identity Manager 用户应用程序初始化请求。 此请求将启动协调批准过程的工作流程。 给予必需的批准后，请求也已完成。 此过程有三个基本步骤，概括如下。
第 1 步： 初始化请求
在 Identity Manager 用户应用程序中，用户通过类别浏览资源列表并选择要供应的一个资源。 在 Identity Vault 中，将选择的受供资源与供应请求定义 相关联。 供应请求定义是供应系统中最重要的对象。 它将受供资源联结到工作流程，工作流程进程通过它开放给终端用户。 供应请求定义向用户提供显示初始请求表所需的所有信息，并在初始请求完成后启动工作流程。
在本示例中，用户选择新帐户资源。 用户初始化请求时，万维网应用程序从供应系统中检索初始请求表和相关联的初始请求数据说明，该供应系统从供应请求定义获得这些对象。
初始化供应请求时，供应系统将跟踪发起人和收件人。 发起人是提出请求的人员。 而收件人是接受请求的人员。 在某些情况下，发起人和收件人可能是同一个人。
每个供应请求都有与之相关联的操作。 此操作指定用户是否要授予或取消资源。
第 2 步： 批准请求
用户初始化请求后，供应系统将启动工作流程进程。 工作流程进程协调批准。 在本示例中，需要经过两级批准，一级来自用户管理器，另一级来自管理器主管。 如果在工作流程中任何用户拒绝批准，则该工作流程终止并拒绝请求。
注：Identity Manager 附带了一组供应请求模板，这些模板支持高达五级的工作流程批准。 在 Identity Manager 的后续版本中，基于 Eclipse 的设计环境将提供允许创建个人自定义工作流程进程的工具。 有关本版本附带模板的更多信息，请参见部分 22.2, 使用已安装的模板。
工作流程可以用顺序或并行的方式处理批准。 在顺序工作流程中，每个批准任务都必须在下个批准任务开始之前得到处理。 在并行工作流程中，用户可以同时处理多个批准任务。
顺序工作流程 以下是包含两个批准级别的顺序工作流程基本设计模式：
并行流程 以下是包含两个批准级别的并行流程基本设计模式：
注：可以轻松更改显示标签（第一步批准、第二步批准等）以适合应用程序的需求。 对于并行流程，可能希望指定不按顺序处理的标签。 例如，可能想要指派三个并行批准中的一个批准，三个并行批准中的两个批准等标签。
工作流程定义由下列部件构成
开始活动 工作流程进程首先执行开始活动。 此活动使用初始请求数据初始化工作文档。 它也联结诸如发起人和收件人等多个系统值，以便在底稿表达式中可以使用这些值。
用户活动 执行完开始活动后，工作流程系统将处理转发到该流程中的第一个用户活动中。 用户活动为支持用户交互的活动。 若要处理这些交互，活动将显示一个表格，该表格给予用户作用于请求的能力。 在上述工作流程示例中，第一步批准和第二步批准是用户活动的示例。 可以将用户活动标签本地化以满足国际要求。
用户活动可以支持下列一个或多个操作：
- 声明
- 批准
- 拒绝
- 拒收
- 重指派（仅适用于组织经理和用户应用程序管理员）
注：表格中的字段和按钮将随请求的资源和配置的工作流程而变化。 例如，产品附带的很多模板不支持拒收操作。
用户活动有五个可能的结果：
- 已批准
- 拒绝
- 拒收
- 错误
- 超时
注：即使用户不进行任何操作，也可能会出现错误结果和超时结果。
如果用户批准请求，工作流程会将控制转发到流程中的下一个活动。 如果不再需要批准，就会供应资源。 如果用户拒绝了请求，工作项目将被转发到工作流程中的下一个活动并且该请求被拒绝。 此外，用户也可以重指派任务（如果他/她是组织经理或用户应用程序管理员），这样可将工作项目置于其它用户的队列中。
注：产品附带的供应请求模板配置为在请求被拒绝时终止工作流程进程。 请求被拒绝时，工作项目会被转发到完成活动中，这会终止流程。
用户活动指派到的用户称为收件人。 可通过电子邮件向活动的收件人通知指派的任务。 要进行与该活动关联的工作，该收件人可单击电子邮件中的 URL，在工作列表（队列）中找到任务，然后声明该任务。
收件人必须在指定的时间内响应用户活动，否则活动将超时。 通常情况下，超时间隔以小时或天为单位，以使用户有足够的时间进行响应。
活动超时后，工作流程进程可能会试图再次完成该活动，这取决于为该活动指定的重试计数。 在某些情况下，工作流程进程可能配置为将已超时的活动上报给另一用户。 在这种情况下，会将活动重指派给新的收件人（例如，该用户的经理），使该用户还有机会完成该活动的工作。 如果最后一次重试超时，则可能会将该活动标记为已批准或已拒绝，这取决于工作流程的配置。
条件活动 在执行过程中，工作流程进程可能会执行测试并检查结果，以确定下一步该做什么。 条件活动提供此功能。 条件活动使用底稿表达式定义要求值的条件。 在上面所示的工作流程示例中，批准条件就是条件活动的一个例子。
条件活动支持三种可能的结果：
- True
- False
- 错误
分支和合并活动 在支持并行处理的工作流程中，分支活动允许两个用户在工作项目的不同区域并行操作。 用户完成工作后，合并活动会同步流程中进来的分支。
供应活动 供应活动完成供应请求。 仅在给出所有必要的批准后，才执行此活动。
有关供应步骤的详情，请参见第 3 步： 完成请求。
完成活动 完成活动是工作流程中的最后一项活动。 当完成了工作流程中的所有活动并且流程的最终结果可用时，可以执行完成活动。 工作流程系统可通过检查指向完成活动的链接，确定进程的最终状态。 当批准链接指向完成活动时，则总流程状态为已批准。 如果有任何其它结果（拒绝、超时或错误）指向完成活动，则总流程状态为被拒绝。
当工作流程过程到达完成活动并且状态为已批准时，批准过程即为完成，也可以完成供应请求。
第 3 步： 完成请求
供应请求被批准后，工作流程系统就可以开始执行供应步骤。 此时，控制被传递回供应系统。
为完成供应请求，供应系统可能会执行 Identity Manager 权利，或直接处理 eDirectory 对象及其特性。 在执行供应步骤过程中，它将按照供应数据定义中的说明创建任何相关的对象，并记录对收件人执行供应操作的结果。 这可能会涉及设置或去除收件人的特性值，也可能涉及在收件人的多值特性中添加项目或去除项目，具体取决于用户请求的操作是授予还是撤消。 涉及的特性为 eDirectory 特性（可能通过向收件人添加辅助类才可用）。 特性值本身可能属于简单类型，也可能属于允许供应系统指定内部子特性值的复杂类型。