转自 http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-1001filenetp8proddev/index.html
对于消费品公司而言，向市场介绍新产品的能力是企业发展的关键。从产品理念评估有效移动到实际产品的制造和分销的能力是成功的关键。这个流程的实现需要集成大量的多样信息和一个复杂、动态和协作的自动化流程。
通过结合内容管理和流程管理功能，IBM FileNet P8 能够充当新产品开发（NPDI）流程的一个有效实现的基础。FileNet P8 还能支持其他重要功能，比如遵从性和对业务流程运作的分析洞察。
本文介绍如何实现 NPDI 流程的其中一个部分：美术品更改管理。本文的目的是对如何利用 IBM FileNet P8 的不同部分来生成类似解决方案提供一些启发。本文具体关注创建一个流程流，使用一个 eForm. 来启动流程流，以及使用 ECM Widgets 来构建一个 Web 界面。本文还介绍了这个解决方案需要的其他两个任务：提供一个未处理请求概览；实现一个特殊审查流程。本文末尾的 参考资料 部分提供了一些资源链接，您可以通过它们详细了解 NPDI 总体流程和 ECM 提供的价值。
在 NPDI 流程内，美术品更改管理就是指更改或创建美术作品以支持新产品发布。图 1 提供了组成这个流程的步骤、参与者和内容的概览。
这个流程通常由市场营销主管发起，市场营销主管与其他几个小组合作，包括工程小组、研究小组、美工小组、法律小组和制造小组。其间将生成大量的内容，包括设计文档、营养标签、美术作品、法律文档和审查反馈。
本文下面的小节介绍如何使用 IBM FileNet P8 的 “开箱即用” 功能来开发样例实现。本文假定您熟悉 FileNet P8 产品的组件。
整个样例开发只使用 IBM FileNet P8 套件的现有软件组件：
- 内容资源库是 P8 Content Engine 4.5.1。
- 业务流程使用 P8 Business Process Manager 4.5.1。
- 电子表单使用 FileNet P8 eForms 4.0.2.4 构建。
- 自定义用户界面使用 ECM Widgets 4.5.1 构建。
- 搜索功能使用 Workplace XT 1.1.4 实现。
图 2 展示了美术品更改管理的流程流，特殊步骤的所有者以及生成的关键文档。
一个典型的美术品更改管理场景是：市场营销主管发起一个更改请求，以便支持一个新品种冰激凌的开发。然后必须创建美术作品来满足新设计的包装需求和市场营销、法律和公司等方面的要求。
这个更改请求最初同时提交到工程和研究小组。每个小组负责生成或批准一个文档，然后将这些文档提交到美工小组的主管，这样美工小组的主管才能制作满足需求的美术作品。美术作品完成后，将通过一个涉及多个小组的审查和审批流程。最后，美术作品及其支持内容被返回到运营产品生命周期管理系统中。
对于这个样例实现，我们使用 Content Engine Enterprise Manager 来定义 4 个文档类别。其中，前三个类别对美术品更改管理很关键：
- Nutritional Label (NLI) 由研究小组的主管制作。
- Die Line 描述产品包装设计，由工程部门生成。
- Artwork 由美工部门创建。
上述每个类别都利用了系统属性，比如 owner 和 date created。其他属性，比如 case ID、material ID 和 product ID，也被添加进来。这些属性支持灵活地搜索文档，这是这个解决方案的一项重要要求。case ID 也很重要，因为它将与一个特定更改请求相关的所有文档集合在一起。当流程经过不同参与者并进出不同系统时，这个属性提供了统一和完整的上下文。
上述类别的每个文档都有一个属性，用于表明文档状态（草稿、审查或批准）和负责人（当前处理文档的人）。最后，这些文档类别利用 annotations 属性来支持流程参与者进行评论。通过评论实现协作是美术品更改管理的另一个重要要求。
第 4 个文档类别是一个更基础的文档类别，用于支持项目计划和审查反馈等文档。这个类别有 3 个属性：owner、document title 和 case ID。
图 3 展示了样例实现的美术品更改管理业务流程流，该流程流使用 Process Designer 工具创建。
这是一个直观的流程。以下是一些设计说明：
- Case Setup 步骤的传出路径（outgoing route）被标记为 “all true conditions”，以便满足以下要求：工程主管和研究主管必须同时工作。
- 美工部门的主管需要工程主管和研究主管在他之前完成工作。为实现这一点，Develop Artwork 步骤在 routing 选项卡中标识为一个 collector step。Corporate 和 Legal 步骤也被标识为一个 collector，以确保所有文档在最后审批之前完成。
- 可以在整个流程中更改营养标签和设计文档。这样，特定的步骤将被添加到流程流，以确保完善最终的版本。
- 对于样例实现，用户界面 Web 页面使用 ECM Widgets 构建，以便支持参与者完成流程流中的步骤。本文稍后将详细介绍这些页面的创建过程。这些页面被创建后，它们将被链接到适当的步骤，具体方法是为对应的步骤定义一个步骤处理器并将这个 UI 页面的 URL 分配给它。
可以通过多种方法将特定流程步骤分配给一个角色或个人。角色和个人可以分配给工作流小组。也可以创建个人收件箱。对于这个样例实现，为每个步骤创建了 worker 队列，然后将它们分配给特定角色。那些 worker 队列然后为它们所属的角色提供（feed）收件箱。
我们为这个流程定义了几个数据字段。我们定义了一些附件数组来保存美术作品文档，并定义了一些附件字段来保存营养标签和分模线（die line）。尽管我们对这些美术文档使用了多个单独的附件，这些附件也可以包含在单个附件数组中。将这些附件放到它们自己的附件字段中，就可以在用户界面中轻松突出显示它们。
作为这个流程的一部分，设计师可以构建电子邮件通知、里程碑和升级点来确保流程可以按时推进。也可以在流程中设置各种点来从一个运营系统（比如 SAP 或 IBM InfoSphere Master Data Management）检索数据。例如，可以从运营系统检索信息，以便供研究和开发小组初始化营养标签。另外，在流程的末尾，数据应该在流程结束前反馈到运营系统。由于这个样例被构建为一个独立实现，因此没有实现与运营系统的集成。但是，通过使用一个组件步骤和一些自定义代码模块，这种集成很容易实现。
市场营销主管通过完成一个电子表单来发起更改请求。这个表单如图 4 所示。
市场营销主管提供产品的 UPC 符号。这个 UPC 符号用于填充表单中的大部分字段，包括 material number、packaging type、brand code 和 project number。另外，系统提供流程参与者的默认值。市场营销主管可以通过选择参与者列表来更改这些值。
字段中的默认值很可能是通过使用 UPC 符号作为键值从一个数据库或运营系统中检索到的。在这个 eForm. 中，单击确认允许连接器（比如 JDBC 连接或 Web 服务调用）检索那些值。
一个表单策略用于关联这个 eForm. 和美术品更改流程。表单策略使用 Workplace XT 创建。创建表单策略时，从资源库选择表单模板和流程流。然后，将 eForm. 中的字段映射到流程流中的数据字段。最简单的方法是对 eForm. 字段分配对应的数据字段的名称（字段名称区分大小写）。这种方法允许表单策略向导自动映射所有字段。
在向导内，您还可以设置安全性来控制可以启动这个 eForm. 的人员。对于这个样例实现，市场营销部门的员工获得了这个授权。
在任何时候，市场营销主管都可能需要查看系统中的所有未处理的更改请求。如果能够查看这些更改请求、它们的目标日期和当前状态，市场营销主管就能确保每个更改请求都按预期的方式移动，并在必要时采取措施。
为实现这个功能，每个更改请求表示为资源库中的一个特殊文档。这些文档属于一个文档类别，带有属性 owner、casestate 和 caseID。尽管有多种方法可以表示一个更改请求，但使用文档有以下几个优势：
- 文档持久存储于资源库中，即使在执行更改请求的流程实例完成后。
- 文档属性能够存储关于更改请求的信息，比如请求的状态。
- 文档可以充当保存有关更改请求本身的日志的容器 — 存储关于更改请求的说明和注释的位置。更改请求的日志很重要，因为它可以用于分析流程的有效性。对于审计和遵从性目的，更改请求日志中的注释也许比较重要。不同的更改请求日志可以集中到一起，提供关于更改请求流程的有趣分析。
更改请求文档使用流程流中的步骤添加和维护。图 5 中的图表展示了修改后的流。
上图添加了两种类型的步骤。首先，在完成启动后立即添加了一个组件步骤处理器，用于创建更改请求文档（在图表中的标签为 “Create request document”）。屏幕截图的下半部分展示了这个新的步骤处理器的配置。位于右侧的是 createDocument Content Engine (CE) 函数的参数，该函数用于创建更改请求文档。这个新的更改请求文档的名称在请求启动时设置为流程流数据字段 CaseID 的值。另外，对这个新的更改请求文档的一个引用存储到附件数据字段 CaseTracker 中，这样就可以在整个流程流过程中访问该请求文档。所有更改请求文档都存储在一个资源库文件夹中，这个文件夹在附件数据字段 CaseFolder 中引用。文档类型可以是纯文本或 XML。
propArray 参数用于设置新更改请求文档上的属性。这个数组的格式使用以下形式的三元组：
因此，如果要设置更改请求的初始状态，将 propArray 参数设置为：
"{'CaseState', 'STRING', CaseState}"
上述示例中的第三个参数是流程流数据字段 CaseState。
更改请求文档创建后，可以在流程流中插入其他步骤来更新请求文档。图 5 中展示了两个这样的步骤：一个在 Generate NLI 后面，另一个在 Load Die Line 后面。在这些步骤（标签为 Update Case State）中，setProperty 函数可以用于更新一个更改请求文档的属性，比如 state 或 assignee。
这个基础架构就位后，市场营销主管就能使用一个自定义 Web 页面（如图 6 所示）来查看更改请求。
（查看图 6 的 大图。）
上面显示的用户界面使用 IBM FileNet ECM Widgets 实现。IBM FileNet ECM Widgets 是一个 Web 用户界面元素集合，这些元素可以链接在一起提供一个自定义 Web 用户界面。这个页面上有 4 个小部件：
- 页面顶端是一个 Toolbar 小部件。Toolbar 小部件可用于创建一个自定义动作下拉菜单。从这个页面的 Toolbar，市场营销主管可以发起一个新的更改请求，这将显示一个电子表单，这个电子表单在此前介绍过并在图 4 展示。
- 页面上的下一个小部件是一个 Content List 小部件。Content List 小部件显示资源库搜索的结果。它们通过提供一个已存储的搜索的 URL 进行配置，这个搜索使用 Workplace XT 中的 Search Designer 创建。这个页面上的 Content List 小部件展示了分配给这个主管的未处理更改请求，以及关于每个请求的重要信息，比如当前状态和负责人。
- 页面左下角是另一个小部件 Content List。当市场营销主管从页面顶端的列表中选择一个特定更改请求时，将执行一个搜索，并在左下角的小部件中显示与那个更改请求关联的所有文档。使用这个小部件，市场营销主管可以检查并编辑每个文档。
- 页面右下角是一个 Viewer 小部件。Viewer 小部件提取一个特定的文档并显示其内容。对于这个应用程序，这个小部件从页面顶端的选择列表中提取更改请求文档并显示其内容，即更改请求的日志。目前，这是一个只读视图。但是，可以创建一个自定义小部件，以便允许市场营销主管向日志添加其他注释。
这个样例实现中的小部件被链接到一起，以便当页面顶端的 Content List 中的一个更改请求被选中时，该请求的 caseID 作为搜索的关键字传递到左下角的小部件，且更改请求文档被传递到右下角的小部件。这种链接通过将这些小部件连接到一起来完成。这些小部件有默认的连接行为，通常可以将它们轻松链接到一起。
文档 Viewer 小部件和顶端的 Content List 小部件之间的连接是使用默认连接行为的一个例子。在文档 Viewer 小部件的小部件配置选项列表中，可以选择 widget wiring 选项，并在对应的对话框中将 Content List 小部件连接到 Viewer 小部件。连接好后，默认行为是 Content List 小部件从选中行中将被引用文档传递到 Viewer 小部件中进行显示，这正是我们需要的。
对于自定义连接要求，您可以使用 JavaScript. Adapter 小部件，这是一个非视觉小部件，允许您编写 JavaScript. 代码来实现自定义功能。在这个样例实现中，这个小部件用于链接顶端的 Content List 和右下角的 Content List。JavaScript. 用于将选中行的 CaseID 从顶端小部件传递到底端小部件，在底端小部件中，CaseID 用作搜索的关键字。为完成上述任务，您将添加一个 JavaScript. Adapter 小部件到页面上，并使用以下 JavaScript. 代码填充它：
return [{'name':'CaseID', 'value':payload.name}]
在本例中，payload 是一个表示从 Content List 中传递出去的内容的对象。name 属性的值被分配给 CaseID 参数，以用于搜索文档。
然后，您需要如图 7 所示连接 Content List、JavaScript. Adapter 和文档 Viewer 小部件并隐藏 JavaScript. Adapter 小部件，以免它出现在用户界面中。
在这个样例实现中，每个参与者都拥有不同的责任。尽管有一些重叠，但每个参与者进行的活动是不同的。因此，每个参与者需要一个自定义环境来尽可能高效地完成他们的工作。本文的这个小节将向您展示如何使用 IBM FileNet ECM Widgets 来创建基于 Web 的自定义工作环境。
图 8 展示了工程主管的工作环境页面的屏幕快照。
（查看图 8 的 大图。）
这个页面上有 5 个 ECM 小部件：
- 页面顶端是一个 In-basket 小部件，用于显示分配给这个负责人的所有任务。
- 下面是一个 Toolbar 小部件。对于工程师，Toolbar 小部件包含 3 个选项：创建一个团队工作室，执行一个文档搜索，以及启动一个审查流程。可以向 Toolbar 添加新项目，方法是配置这个 Toolbar 小部件并添加新的菜单项。菜单项可以是不同的类型；在本例中，所有动作都是 URL 驱动的，因此每个菜单项都配置了一个 URL，该 URL 在选项被选中时调用。
- Toolbar 小部件下方是一个 Work Data 小部件，显示一个选中任务的所有属性。
- 右边是一个 Attachment 小部件，标签为 Change Request Documents，用于显示与这个特定任务关联的所有附件。在这个屏幕快照中，有一个针对分模线的附件（工程师将在这个附件就绪时填充它）和一个针对这个更改请求的项目计划的附件。
- 页面右下方是一个 Step Completion 小部件，标签为 Task Actions。这个小部件用于保存在一个特定任务中的所有工作，并将一个任务标记为已完成。一旦某个任务被标记为已完成，该任务就从工程师的任务列表中删除。
要关联这个页面和工程主管并配置任务列表以显示他的 In-basket，应该执行以下步骤：
- 在 Process Configuration Console 中，创建一个 Application Space，为这个解决方案包含的所有 ECM 小部件提供一个上下文。
- 使用 Process Configuration Console，在这个 Application Space 中定义 Engineering Role 并指定这个页面为 Engineering Role 的登录页面。
- 在配置这个页面来表示任务处理器和登录页面时，将 In-basket 小部件配置为不在单独的窗口中打开任务。您应该已经在使用 Process Designer 构建流程流时为任务处理器指定了这个 URI。
- 使用 Process Configuration Console，定义 In-basket 小部件，将 Engineering 角色映射到 Engineering Work Queue，后者已在构建流程流时定义。对于这个样例解决方案，您在实现流程流时创建并使用的每个 Work Queue 只需一个 ECM In-basket。
这些步骤将对与流程流中的特定步骤相关联的所有页面执行。
美术品更改管理的一个重要要求就是支持动态审查。工程、研究、美工和市场营销主管在其完成工作之后可能都需要发起一个审查流程。例如，当工程主管完成了创建分模线的流程后，他很可能会发起一个特殊的内部审查流程。那时，工程师将确定要参加审查的人员清单、要审查的文档和目标完成日期。如果不预先了解这些信息，对整个流程建模流程流可能很困难。
对于这个样例实现，Process Designer 用于创建一个简单的审查流程，然后添加一个动作项到工程主管的工具栏。这个动作项允许工程主管调用审查流程，生成如图 9 所示的屏幕。
图 9 中的屏幕是一个流程流的 WorkplaceXT 默认启动屏幕，它显示流程流的数据字段，允许用户在启动前初始化值。
在这个屏幕中，工程主管可以选择参加审查的团队成员，附加需要的文档，并提供一些说明和注释，以便在审查人员审查这些文档时提供指导。当流程流启动时，团队成员被添加到流程审查工作组，文档被传递给他们以便进行审查。一旦审查结束，工程主管将收到通知，然后他就可以将他的设计文档提交到更改请求。
使用一个流程流来建模审查流程允许 ECM 实现审查流程自动化，这有助于有效推动一个通常手动执行的流程，而手动执行的流程往往是效率低下的根源。另外，由于审查流程由 ECM 推动，因此在流程结束时，表明文档审查人员的信息可以添加到更改请求日志。出于历史记录和遵从性考虑，这些信息可能很重要。
本文详细介绍了一个样例实现的各种元素，这个样例实现展示了 IBM FileNet P8 如何充当一个用于管理对美术作品的更改的业务流程的构建基础。在消费品行业和其他生产和运输产品的行业中，这个流程是新产品研发的一个重要组成部分。本文提供了一些技术细节，涉及如何创建流程流，如何使用一个电子表单来启动流程，以及如何使用小部件创建自定义 Web 页面。另外，本文解决了这个解决方案的两个特定要求：提供一个未处理的更改请求概览；实现了内部审查这样的动态流程。除了作为美术品更改管理流程的关键元素之外，这些实现细节还可以在您构建其他类型的具体解决方案时提供帮助。