IBM Cognos 最佳实践: 面向使用 IBM Cognos BI 的 OEM 的持久模型最佳实践

最新推荐文章于 2021-02-19 15:20:52 发布

zhangqinghao9203

最新推荐文章于 2021-02-19 15:20:52 发布

阅读量1.7k

点赞数

分类专栏： Cognos 文章标签： cognos 商业智能

Cognos 专栏收录该内容

18 篇文章 0 订阅

订阅专栏

IBM Cognos 最佳实践: 面向使用 IBM Cognos BI 的 OEM 的持久模型最佳实践

文档性质：最佳实践；产品；Framework Manager；关注领域：建模

本文将更详尽地阐述现有的持久模型文档，并说明在 8.4.1 中创建持久模型的流程。

查看本系列更多内容 | 0 评论：

Paul Maric, 战略项目顾问, IBM

Steve Newman, 技术经理，ISV/ASL 解决方案专家, IBM

2012 年 4 月 16 日 (最初于 2010 年 5 月 21 日)

内容

免费下载：IBM® Cognos® Express V9.5 或者 Cognos® 8 Business Intelligence Developer Edition V8.4 试用版
下载更多的 IBM 软件试用版，并加入 IBM 软件下载与技术交流群组，参与在线交流。

简介

目的

本文将描述如何确保对 Framework Manager 模型的已发布包和 Content Store 中相应内容作出的修改能够继续发挥作用，即使对模型做出变更。

适用范围

本实践适用于 IBM Cognos 8 BI v8.4.1 和 IBM Cognos 10 BI，特别是针对非 OLAP 源的 Framework Manager 模型以及 Content Store 中创建的相应内容。包括但不限于 Report Studio、Query Studio、Analysis Studio 和 Event Studio 的内容。

例外与除外责任

在出版之际，该技术尚不适用于 Dimensionally Modelled Relational (DMR) 模型。

回页首

概述

背景

在创建并发布一个 Framework Manager 模型时，使用已发布包的 studio 会引用包中的组件，以通过 [命名空间].[对象名] 形式的 XML 表达式元素来生成查询，其中，对象名可以是一个查询项（以 [查询主题].[查询项] 形式）、过滤器、计算等。由于引用的是对象名，而不是隐含的或不变的标识符，因此务必确保 studio 中使用的对象名在发布后没有发生变化。

实施这一做法的挑战包括：

不了解有关创建模型或内容的实践，从而造成根据模型创建的内容具有不可持久性
可以在创建模型时实施这一做法，但是在创建内容时无法控制用户的 Content Language 设置。在 IBM Cognos BI 版本 8.4.1 之前，如果要充分实施这一做法，在创建内容时用户的内容语言必须与模型的设计语言相匹配。这要求用户在每次创建内容时记得修改它们的首选设置，或者始终将其设置为设计语言。这对于较小的开发组可能可行，但是对于更大的团队，不仅不可行，并且无法实施。

IBM Cognos BI v8.4.1 引入了一个新的 FM 模型设置，可强制新创建的内容引用模型的设计语言，而不是与用户的内容区域设置相对应的模型语言。在 IBM Cognos 8.4.1 中，这一设置无法通过 FM 界面看到，并且必须在模型的底层 xml 文件中进行手动设置。而在 IBM Cognos 10 中，可以在项目的属性窗格启用该项设置。结果是，持久模型中新内容自动变为具有持久性。

但是，现有的内容也必须设置为具有持久性，这将是本文其余部分所讨论的重点。我们将通过示意图讨论实现模型和内容持久性的整个过程。

先决条件

本文作出了以下假设条件：

本文内容基于一篇现有的 IBM Cognos 最佳实践文档，名为 “IBM Cognos 8 Framework Manager - Durable Models”，其位置见下面链接。本文假设读者熟悉这篇文档的内容。
http://www.ibm.com/developerworks/data/library/cognos/page60.html
本文中有对产品和实用工具以及第三方应用程序的引用，假设读者完全了解如何选择它们以及它们的实际用法。每个产品/实用工具/应用程序都有其自己的用户指南和/或参考手册，读者需要阅读并理解这些内容。诊断实用工具 “按原样” 提供，不作为产品予以支持，而是用来演示使用 IBM Cognos BI SDK 可以实现哪些功能。
本文介绍的流程将更新 IBM Cognos BI Content Store 中的信息，因此强烈建议在非生产测试或开发环境中对生产内容存储库的副本测试该流程。同时还强烈建议针对生产进行验证和更新之前，选取生产内容存储库的一个备份，并将所有用户锁定到系统之外，从而确保不会干扰该流程。
本文提到了规范和内容，通常是指通过 IBM Cognos Connection 创建的任意内容，其中包括 Report Studio 报表、Query Studio 查询、Analysis Studio 分析、Event Studio 事件等。本文假设读者熟悉所有可通过 FM 模型创建的内容类型。
Framework Manager 模型遵循分层最佳实践，这意味着最少有 2 层最高水平的命名空间，这确保对底层数据结构做出的修改与已发布包层是分离开来的。本文仅适用于表示层。FM 帮助文档 ‘Guidelines for Modeling Metadata’ 的 ‘Organizing the Model’ 一节中描述了最佳实践。

回页首

模型持久性

下列显示了使用 IBM Congnos BI 实现完整的模型和内容持久性的过程，同时详细描述了步骤内容。

要实现持久型模型，必须满足以下条件：

为模型创建的设计语言不能与用户选择的区域设置相同，比如英语，设计语言通常为津巴布韦英语。
在包中已发布的所有命名空间、查询主题和查询项的设计语言在包第一次发布后不能发生改变。不过，其他语言名称可以根据需要修改。
已发布包的命名空间、查询主题、查询项、大小、快捷方式等结构不能随时间变化。该结构存储在规范的定义中，同时存储的还有设计语言的名称，因此不能更改这些内容。
在 IBM Cognos 8.4.1 中，<fixIdsToDefaultLocale> 元素必须存在于 model.xml 中。在 IBM Cognos 10 中，项目级别属性 Use Design Locale for Reference ID 必须设置为真。

如果该模型不具有持久性，必须做出如下更改以使模型具有持久性：

如果模型还没有设计语言，那么：
- 为模型添加必要的设计语言，然后将其添加至基于此模型的每个包的语言中。保存并关闭模型。
- 使用 XML 或文本编辑器，打开 model.xml 文件并在靠近文件顶部的位置，更改 <defaultLocale>en</defaultLocale> to <defaultLocale>en-zw</defaultLocale> 的值。
在 IBM Cognos 8.4.1 中，要在 model.xml 文件中刚刚修改过的 <defaultLocale> 元素下面插入一个空白行，并将 <fixIdsToDefaultLocale>true</fixIdsToDefaultLocale> 添加至该新插入的空白行。
在 IBM Cognos 10 中，要将项目级别属性 Use Design Locale for Reference ID 设置为真，如以下屏幕截图所示。
图 1：Framework Manager 中显示 ‘Use Design Locale for Reference ID’ 属性的项目属性窗格屏幕截图

模型具有持久性后，需要重新发布模型上的包并检查现有内容是否具有持久性。本文第 4 节将讨论如何处理内容持久性。

回页首

内容持久性

新内容持久性

只要模型是持久性的，所有使用 IBM Cognos BI 开发的新内容就都具有持久性。通过适当地将那些规范中的非持久性组件替换为持久性组件可使现有的非持久性内容具有持久性。因为出于持久性以外的其他原因需要对内容进行更新，所以现有的内容通常会随着时间变为持久性内容。

现有内容的持久性

现有规范是否具有持久性？

如果规范中的所有查询项表达式都引用模型内一个有效的查询项位置/名称，且对应于模型的设计语言，那么规范被定义为具有持久性。如果无法对此做出判断，那么将认为至少有一部分规范是不具有持久性的。

对持久模型执行验证

开发并运行进程（手动或自动，或同时使用两者），检查系统中所有规范的有效性，包括特定于用户的内容。这可以通过多种方式实现，其中包括：

使用 IBM Cognos Upgrade Manager 执行批量验证和即时处理。
使用诸如 Validate Report Specifications Diagnostic 的诊断工具。
通过 studio 验证选项分别进行验证。
使用第三方工具，如 Motio PI。

由于具有稳健特性，特别是即时处理特性，使用 IBM Cognos Upgrade Manager 可能是进行验证的最佳选择。但是需要根据各种因素做出这一决定，包括与更新进程（稍后介绍）的集成，以及该进程是否可以与整个系统升级结合在一起。下文将详细讨论每种方法的优缺点。

如果在验证时返回以下消息，则说明该规范为无效规范：

QE-DEF-0030 Expression parsing error.
QE-DEF-0359 The query contains a reference to at least one object '[namespace].[query_subject].[query_item]' that does not exist.

有效规范是指在验证期间不会返回此消息的规范。

不过需要注意的一点是，这些定义只适用于这种特定的消息，规范可能会由于其他原因而验证失败，但是任何其他验证错误消息都不会与该应用有关。

如果验证失败，则执行手动更新丢失项一节中所描述的步骤。如果验证成功，则执行对仅使用设计语言的持久模型进行验证一节中所描述的步骤。

手动更新丢失项

包含不存在组件的规范不能够通过自动方式更新，因为模型中不存在可以引用以便进行更新的内容。因此，必须手动更新或重新创建验证失败的规范。验证消息将表明哪些引用丢失，因此可以用它们判断需要向规范重新添加什么内容。

如果一些引起无效规范的更改或更改模式为已知，并且有许多规范都受到影响，那么手动方法就有些不切实际。这种情况下，可以创建一个自动更新进程来完成这个任务。例如，如果查询项 ‘Product Name’（在包中公开）从 [Presentation Layer].[Items].[Product Name] 移动到 [Presentation Layer].[Products].[Product Name]，那么无法通过模型 XML 映射识别，但是可以通过手动方式或进一步自动化来增强更新进程的映射。需要对手动工作和自动化进行权衡，从而确保更新进程能够更有效运行，以满足您的需求。

更改之后，下一步是返回并如文中对持久模型进行验证小节中所描写的持久模型执行验证。可以重复循环这一操作直至所有的规范都为有效。

对仅使用设计语言的持久模型运行验证

要创建仅使用设计语言的持久模型，创建持久模型的副本，从该副本中删除所有非设计语言。将其保存为一个临时的仅供测试的模型。不要覆盖现有的模型，因为这个临时模型的用途只是用于验证测试。

发布适用的包，确保能移除旧的模型版本，并运行一个进程，对早期验证步骤中所有被认为是 “有效” 的规范进行验证。这是通过检查相同的错误实现的。

如果先前有效的规范仍然有效，则执行重新发布持久模型一节中所描述的步骤。

如果先前有效的规范为无效，则执行自动更新（可选）一节中所描述的步骤。

自动更新（可选）

非持久规范可以通过自动化进程更新，该进程通过引用整个持久模型将规范的非持久部分映射到持久的设计语言值。可以遍历整个持久模型的 XML 来识别该映射，这个过程需要由您开发并测试。注意，只有在模型中存在大量需要进行映射的对象或难以手动识别映射的情况下，创建这种类型的自动化映射进程才是有意义的。否则，应当使用手动创建的映射文件，该文件可以被提供给进程，更新尽可能多的规范。

实际的规范更新可以通过一个名为 Dynamic Report Specification Updater (DRU) 的诊断工具实现，可从下列网址获取该工具：

http://www.ibm.com/support/docview.wss?uid=swg24021248

识别非持久规范的流程还应当提供一个规范列表，其中包含相关的 ‘丢失’ 元素的引用，从而可以将该列表提供给这个流程。

此步骤完成后，执行对仅使用设计语言的持久模型重新运行验证一节中所描述的步骤。

对仅使用设计语言的持久模型重新运行验证

出于以下原因，将对更新的规范进行重新验证：

要确保所有更新规范现在都具有可持久性。
已知在 Report Studio (Query Studio, Analysis Studio and Event Studio) 以外的其他的 studio 中创建的规范都使用了不完全符合 [namespace].[query subject].[query item] 格式的表达式引用。更新进程不适用于这种微型规范，因此，需要通过手动的方式识别并管理这些规范。如果手动修复非常繁琐（通常是因为数量巨大或需要访问用户内容），可以对这些规范中的表达式引用的模式进行分析，然后调整更新流程来满足这个需求。

如果无法重新验证更新规范，则执行手动更新丢失项一节描述的步骤。如果成功地重新验证了所有的更新规范，则执行重新发布持久模型一节描述的步骤。

手动更新丢失项

在自动化过程中无法具备可持久性的报告规范需要手动予以更新，具体方法是在相应的 studio 中打开规范，作出必要的修改并进行保存。完成所有必要的修改并进行保存后，循环回对仅使用设计语言的持久模型重新运行验证。

重新发布持久模型

打开整个持久模型并重新发布到内容库，并关闭包版本化功能。完成此步骤后，执行对持久模型重新运行验证一节中描述的步骤。

对持久模型重新运行验证

对所有更新的规范（手动和自动方式）再次进行重新验证，确保它们可以对实际的持久模型发挥作用。如果正确完成了这个过程，应当不会出现任何问题，但是如果出现问题的话，需要对这些规范再进行一遍手动更新流程以修复问题。

图 2：描述内容持久性一节的流程图

回页首

附录 A

验证方法

下列为可能的验证报告规范的方法列表，其中包含每个方法的优缺点。

方法	优点	缺点
Upgrade Manager	批处理即时处理具有全面 Cognos 版本升级的工作流程可以执行数据/文件验证	不能实现自动化不支持 My Folders
Dynamic Report Specification Updater diagnostic	批处理可进行数据验证轻松地修改和扩展	需要较为复杂的集成缺少即时处理功能功能单一
通过 studio 单独操作	选项简单适合用于规范数量较少的情况	不能实现自动化
第三方工具，如 Motio PI	识别大量的无效规范	免费选项可能无法扩展，或不具有验证输出结果

有关自动化的考虑

要实现更高程度的自动化，需要进行一些额外考虑：

将用户内容临时移动到公共文件夹区域，将其包含到流程中。可以使用 IBM Cognos Support Technotes 中的样例通过 IBM Cognos BI SDK 访问用户内容。该 SDK 示例为：如何查看内容库中所有帐户的所有 “My Folder” 文件夹的内容。这是通过使用关键字 ‘SDK 用户内容‘ 对 IBM Cognos Support Technotes 进行搜索实现的示例。
由于在这个过程中修改了一个包，因此需要对每个规范进行更新和验证，这可以通过自动化进程完成。使用关键字 ‘SDK 更新’ 对 IBM Cognos Support Technotes 进行搜索将会返回多个示例，其中包括 ‘在重新发布包后更新查询或报告的 SDK 样例’ 和 ‘在 FM 发布后更新所有包中的所有报告和查询对象的 SDK 样例’。
更加通用的或批处理驱动的更新进程可能会比使用 Dynamic Report Specification Updater (DRU) 更好。针对此需求的样例 SDK 为 ‘更新内容库中的查询对象的 SDK 样例’，这将通过使用关键字 ‘SDK 更新’ 执行搜索来返回。

参考资料

学习

通过 developerWorks Information Management 专区：在这里可以学到更多关于 Information Management 的知识。还可以找到技术文档、how-to 文章、培训、下载、产品信息等。
通过 Information Management 专区 Cognos BI 专题，了解更多有关 Cognos BI 专题的产品和技术资源。
通过多媒体课堂：体验魅力 Cognos BI 10 系列，了解最新 Cognos BI 10 的最新特性和相关技术，并介绍了 Cognos 商业智能报表开发的技术细节。
随时关注 developerWorks 技术活动和网络广播。