集成 HFM 11.1.2.4 与 ODI 元数据知识模块


Ricardo Giampaoli Oracle ACE 和 Rodrigo Radtke Oracle ACE

2017 年 6 月

简介

Oracle Hyperion Financial Management (HFM) 是一款企业绩效管理 (EPM) 工具，可提供财务整合和报告，让用户能够快速整合和报告财务成果、满足全球监管要求、降低合规成本以及增强对数据的信心。

与其他 EPM 工具一样，HFM 使用加载到工具中的维度（元数据）和事实量度（数据）来创建报告。在新版本 (11.1.2.4) 推出之前，HFM 可以使用 Oracle Data Integrator (ODI) 将此类元数据和数据加载到工具中，这样大型企业就可以围绕 HFM 和 ODI 集成来构建大型环境。

然而，在新版本的 HFM 中，Oracle 决定取消对 ODI 的支持，也就是说所有 HFM 集成将必须从 ODI 转向使用 HFM 进行手动迭代，这需要使用另一个集成工具，或者需要使用新的 Java HFM API 创建自定义代码。Oracle 的这项决策对新 HFM 实施的影响是可控的，但是会对现有的集成流程产生很大的影响，因为大型现有环境中并没有可顺利实施的方案。

本文重点介绍如何使用通过新的 Java HFM API 构建的 ODI 知识模块 (KM) 将元数据加载到 HFM。通过这种 ODI KM，企业可以继续使用传统的 ODI/HFM 集成，无需大幅改变集成流程或者在其环境中添加新的工具。新的 HFM 实施也将受益于这些 ODI KM，因为它们允许在元数据和数据上建立任何类型的复杂 ETL 逻辑，然后再轻松地将这些数据加载到 HFM。

当前的 HFM 元数据集成流程状态

在 11.1.2.4 版推出之前，用户可以轻松地将 ODI 用于 HFM 集成流程。ODI 通过 Oracle 提供的特定 HFM 驱动程序 (HFMDriver.dll) 使用 KM 来访问和操作 HFM 应用。下面列出了适用于 11.1.2.4 HFM 应用的所有可能的元数据加载过程：

数据关系管理 (DRM)：DRM 是 Oracle 提供的用于存储和管理大型/复杂元数据集的主要工具，可供各种下游应用使用。HFM 支持通过两种方式来使用 DRM。对于 HFM Classic 来说，DRM 可以创建和导出包含元数据信息的 .APP 文件；这些 .APP 文件可以随后在 HFM 工作区中导入。对于非传统 HFM 应用来说，DRM 可以创建和导出 .ADS 文件，这些文件可用于加载 EPMA 接口表，随后导入到 HFM 应用中。

Enterprise Performance Management Architect (EPMA)：EPMA 仅适用于非传统 HFM 应用。它依赖于其接口表，可以先在接口表中填充元数据，然后再将其发送给 HFM 应用。除了“不支持”传统 HFM 应用之外，Oracle 还表示 EPMA 不在其未来规划中，新实施不应考虑 EPMA。换句话说，EPMA 仍然受 Oracle 支持，但是该工具不会再进行新的开发/增强。

Financial Data Management 企业版 (FDMEE)：Oracle 正在努力将 FDMEE 打造成 EPM 领域数据和元数据的终极集成工具。然而，FDMEE 存在一些严重的局限性，尤其是在元数据集成流程方面。目前，FDMEE 只能通过 Fusion GL、EBS 和 PeopleSoft Enterprise 财务管理应用将维度元数据加载到 HFM。

手动迭代：用户可以随时访问工作区中的 HFM 应用，并在“管理”部分中执行手动元数据提取/加载过程。对于 HFM 传统应用来说，用户可以使用位于 HFM 服务器上的 HFM 桌面客户端；它适用于非常简单的元数据流程，但并不适用于企业环境。

使用 HFM Java API 创建自定义代码：Oracle 针对 HFM 11.1.2.4 发布了一个全新的 Java API，可以在 HFM 应用上执行多种任务。如果您处于复杂的大型环境中或者对元数据元素应用了特定的 ETL 逻辑，这或许是理想的途径。Java API 让您可以自动化整个元数据流程，从而创建可扩展、强健、安全的环境。

使用这些选项，大型/复杂环境最终可以使用 Java API 创建自己的自定义代码，因为所有其他选项都存在某种限制。采用现有 ODI 集成流程的企业可能不想从头开始重新构建所有内容，也不愿意在其架构中添加新工具。由于我们的架构同时存在这两个痛点，因此我们决定使用 HFM Java API 创建全新的 ODI KM。这种方法具有以下优势：

  • 虽然它可能被认为是自定义代码，但代码本身集中存储在 ODI KM 中，可以在不同的集成项目中共享和重复使用多次。此外，由于代码集中放置，因此我们可以集中修复可能存在的问题，或者实施可让整个 HFM 架构受益的未来增强。
  • HFM/ODI 原有代码全部可以重用，只需将旧 KM 切换为新 KM 即可（只需稍作调整，详见下文）。
  • 无需在公司的现有架构中实施新工具。和过去一样，ODI 将为 HFM 应用处理所有元数据、数据和整合流程。
  • 可以创建复杂的 ETL 逻辑，HFM 可以使用 ODI 从几乎任何来源获取数据。
  • 可以创建自动化流程，无需任何人工干预，打造真正的企业解决方案。

本文以下章节将重点介绍如何让 ODI 元数据 KM 在您的环境中发挥效用：一个 RKM 用于反向工程 ODI 中的 HFM 数据存储信息，另一个 RKM 用于将元数据加载到 HFM。它们在构建时尽可能考虑了通用性，因此在一些情况下可以“开箱即用”。

本文还将介绍创建这些新 ODI KM 时做出一些决定的原因，因为您可能希望调整这些可定制 ODI KM 的代码，以便解决架构中存在的重大问题。

HFM Classic 应用对 HFM Java API 架构的要求

在开始使用 ODI KM 之前，我们需要了解一下新 HFM Java API 的工作原理。从本质上来说，它取代了旧的 HFM Visual Basic (VB) API。Oracle 做出这个架构转变决定是为了以后将 HFM 转换为与平台无关的应用，因为基于 Java 的架构支持 HFM 在 Windows 以外的平台中运行。这一决定将大大有利于整个 HFM 架构；缺点是过去使用 HFM VB API 的每个组件现在都需要转换为 HFM Java API。

新的 HFM Java API 可以轻松应用于多个管理任务。本文不打算介绍所有 API 方法或如何使用它们，而是重点介绍如何准备好您的架构以使其正常工作，并对一些相关概念进行简要概述。本文中所描述的步骤使用以下应用/版本执行：HFM Classic 11.1.2.4（位于 Windows Server 2012 R2 服务器上）、ODI 11.1.1.9（位于 Windows Server 2012 R2 服务器上并运行 ODI 独立代理）、JDK 1.7.0_67 和 Eclipse Mars 发行版 (4.5.0)。

Java API 必须满足以下要求才能正常运行：

  • JDK 安装在将运行代码的服务器上。
  • 将以下三个 HFM JAR 文件导入到 Java 代码中：epm_hfm_web.jar、epm_j2se.jar 和 epm_thrift.jar。这三个文件位于 HFM 服务器的 %EPM_ORACLE_HOME%\common\jlib\11.1.2.0 文件夹中。

先看看这两个要求，似乎很简单：在安装了 JDK 的机器上创建一些 Java 代码，并将三个 HFM JAR 文件导入其中。问题是这三个 JAR 文件仅包含清单文件，而不包含需要在 HFM 中使用的实际 Java 代码。换句话说，清单文件仅包含到其他 JAR 文件（其中包含实际 Java 代码）的类路径或者指向其他清单文件（其中包含到其他 JAR 文件的类路径）的指针。例如，图 1 显示了 epm_thrift.jar 清单文件的内容：

giampaoli-hfm-km-fig001
图 1 — 清单文件示例

您可以看到，此清单文件指向其他一些 JAR 文件，包括 libthrift.jar、Log4j.jar 和 jakarta-commons.jar 等。此外，它还指向一些特定的文件夹（例如 ../../loggers/Log4j/1.2.14/lib）。这意味着，我们不能仅将这三个 JAR 文件复制粘贴到服务器中，并将它们导入到我们的 HFM Java 程序中，因为这些文件指向的是位于其他位置的特定文件夹中的其他一些 JAR 文件。

这种清单架构非常适合在我们的环境中组织和避免 JAR 重复文件，但同时也会引入一个新的问题：如何在 Java 代码（位于 ODI 内部）中导入此类 JAR 文件和所有依赖关系？这个问题主要可以通过两种架构方法来解决：

  • 将 ODI 安装在与 HFM 相同的服务器中。这是一种简单快捷的方法，因为我们只需要将 ODI 指向位于 HFM 目录中的三个 JAR 文件。这种方法的唯一问题是，从架构的角度来说，将 ODI 代理安装在 HFM 服务器有时是不可行或不可取的。
  • 将必要的 HFM JAR 文件复制到 ODI 代理服务器。为了避免复制整个 HFM 中间件文件夹，我们可以弄清楚这些清单文件真正使用了哪些 JAR 文件，只将这些必需的文件复制到 ODI 代理服务器。

这两种方法各有利弊。第一种方法快速简便，不过需要将 ODI 和 HFM 安装在同一台服务器上，稍有不便。这种方法有利于 HFM 未来升级，因为您在升级 HFM 时不需要更改 ODI 中的任何内容（或者可能只需要指向一个新的目录）。

第二种方法比较复杂，但是让我们能够灵活地将 HFM 和 ODI 置于不同的服务器上。这种方法给我们带来两个主要挑战：确定 HFM 代码需要哪些 JAR 文件；未来升级 HFM 时可能需要再次搜索所有这些 JAR 的依赖关系，从而确保它们在新版本的 HFM 中没有发生变化。

这两种方法都需要在 ODI 中进行某种设置，下一节将对此进行详细探讨。

在同一台服务器上使用 ODI 和 HFM

如果您的架构允许您在同一台服务器上安装 HFM 和 ODI 代理，则可以使用这种非常简单的方法。您只需更改 odiparams 文件（独立代理中的 oracledi\agent\bin\odiparams.bat 文件）并添加这三个 HFM JAR 文件的位置。打开 odiparams.bat 文件，搜索“ODI_ADDITIONAL_CLASSPATH”。在该设置中，设置 HFM JAR 文件的位置，如下例所示（根据您的环境调整路径）：

set
ODI_ADDITIONAL_CLASSPATH=%ODI_ADDITIONAL_CLASSPATH%;"D:\Oracle\Middleware\EPMSystem11R1\common\jlib\11.1.2.0\epm_j2se.jar";"D:\Oracle\Middleware\EPMSystem11R1\common\jlib\11.1.2.0\epm_thrift.jar";"D:\Oracle\Middleware\EPMSystem11R1\common\jlib\11.1.2.0\epm_hfm_server.jar"

保存文件，重新启动 ODI 代理：ODI 将读取这三个清单文件并且能够找到所有必需的 HFM JAR 文件，以便在其代理中运行 HFM Java 代码。

值得一提的是，我们为什么在 ODI_ADDITIONAL_CLASSPATH 中设置了这些 JAR 文件，而不是像我们在 ODI 中处理其他传统 jar 文件那样，将它们复制到 oracledi\agent\drivers 文件夹中。这是因为清单文件不包含任何实际的 JAR 代码，只是指向另一个 JAR 文件，该 JAR 文件的相对路径也仅针对自己的 JAR 文件。

换句话说，如果我们尝试将三个 HFM JAR 文件复制到 ODI 代理驱动程序文件中，ODI 将读取清单文件，但是无法找到其他 JAR 文件，因为其路径所相对的是原始 JAR 文件，它们也不在 ODI 代理文件夹中。但是，如果我们直接使用 ODI_ADDITIONAL_CLASSPATH 将完整路径添加到 HFM 安装中的原始路径，系统将正常运行。

在不同的服务器上使用 ODI 和 HFM

在这种情况下，搜索 JAR 依赖关系不是一项可以手动轻松完成的工作，只是因为清单文件可能会指向一组 JAR 文件，而这些 JAR 文件可能又会指向另一组 JAR 文件，依此类推。幸运的是，可以通过一些工具来简化这项工作。

本文的附录中提供了 HFM 11.1.2.4 和 ODI 集成流程中使用的所有必需的 JAR 文件的清单，还描述了如何使用 Eclipse Java IDE（您可以根据自己的喜好使用不同的方法/工具）查找所有必需的 JAR 文件。如前所述，当您需要将 HFM 升级至较新版本并确保 ODI 服务器上拥有新的 JAR 文件时，此资源将派上用场。

首先，您需要在 HFM 服务器上安装 Eclipse IDE。主要理念是使用 Eclipse 创建一个非常简单的 Java 类，其中包含与之相关联的三个必要的 HFM JAR 文件。接下来，我们将使用 Eclipse 的导出方法生成一个“可执行的 Jar”文件，其中保存虚拟 Java 类以及清单文件引用的所有 JAR 文件。随后，只需将这些 JAR 文件复制到 ODI 代理文件夹。

安装 Eclipse 之后，进入 File\New\Java Project 菜单，创建一个新的 Java 项目。

giampaoli-hfm-km-fig002
图 2 — 创建一个 Java 项目

之后，右键单击该 Java 项目并创建一个新的类。

giampaoli-hfm-km-fig003
图 3 — 创建一个 Java 类

要将三个必要的 HFM JAR 文件关联至 Java 项目，请再次右键单击该项目并选择"Build Path"\"Configure Build Path..."。

giampaoli-hfm-km-fig004
图 4 — 配置构建路径

转到"Libraries"，单击"Add External JARs..."。导航至 HFM 安装文件夹，添加 %EPM_ORACLE_HOME%\common\jlib\11.1.2.0 文件夹中的 epm_hfm_web.jar、epm_j2se.jar 和 epm_thrift.jar。

giampaoli-hfm-km-fig005
图 5 — 添加外部 JAR

在 Java 文件中，创建任何虚拟代码（例如“Hello World！”）并执行，如下面的图 6 所示。完成此步骤后，Eclipse 会创建一个有效的 .class 文件并在随后导出。

giampaoli-hfm-km-fig006
图 6 — 创建并执行虚拟 Java 代码

接下来，进入"File\Export"菜单，选择"Java\Runnable JAR file"。

giampaoli-hfm-km-fig007
图 7 — 作为可运行的 JAR 文件导出

在"Launch configuration"框中，选择您创建的 Java 类以及一个将包含导出的 JAR 文件的文件夹（您可以为此虚拟 JAR 文件选择任何名称）。接下来是一个非常重要的步骤：在"Library handling"中，选择"Copy required libraries into a sub-folder next to the generated JAR"。

giampaoli-hfm-km-fig008
图 8 — 导出所需的库

这个选项可以让 Eclipse 完全根据我们的想法来执行任务：它将分析代码依赖关系、检查三个 HFM 清单文件并将运行该代码所需的所有 JAR 文件复制到一个子文件夹中 — 换句话说，就是为了让代码能够正常运行，我们需要复制到 ODI 代理服务器上的所有 JAR 文件。

转至导出文件夹并检查其内容。其中包含来自 Java 类的虚拟 JAR 文件以及一个 HFM_lib 文件夹。双击该文件夹后，我们可以看到其中包含 132 个 JAR 文件，都需要复制到 ODI 代理服务器。复制所有 JAR 文件并粘贴到 oracledi\agent\drivers 文件夹中。

giampaoli-hfm-km-fig009
图 9 — 导出的 JAR 文件

重新启动 ODI 代理。现在已经可以在 ODI 中执行任何 HFM Java 代码了。值得一提的是，采用这种方法，我们不需要更改 odiparams 文件中的任何内容，因为系统会在 ODI 代理启动时默认读取 oracledi\agent\drivers。另外还请记住，在将 HFM 升级至较新版本时，您可能需要重复这些步骤，确保 ODI 代理文件夹中包含完整的 JAR 文件。

适用于 HFM 11.1.2.4 的 ODI 反向知识模块

本节将介绍创建适用于 HFM11.1.2.4 的 ODI RKM 所使用的概念。尽管大多数 ODI/HFM 开发人员只希望导入 ODI RKM（下载链接参见附录部分）并在项目中使用，但本文将描述创建这个 RKM 所需的主要步骤和决策。理解其内部工作方式之后，您可以根据需要更改其代码。

这个 RKM 只包含三个步骤，如下面的图 10 所示。第一个步骤和最后一个步骤用于重置和设置 ODI 数据存储元数据信息。它们使用负责管理 SNP_REV ODI 表的标准 ODI API调用（SnpsReverseResetTable 和 SnpsReverseSetMetaData）。

SNP_REV ODI 表位于 ODI 工作存储库模式中，充当“临时”表，在应用于 ODI 之前会填充适当的数据存储信息。换句话说，每次将任何数据存储转移到 ODI 时，都要先重置 SNP_REV 表，在其中填充正确的信息，然后再根据 SNP_REV 表中的内容设置 ODI 数据存储信息。

giampaoli-hfm-km-fig010
图 10 — RKM 命令步骤

第二步是存储所有真正逻辑的地方。此步骤负责连接到 HFM 应用，向 HFM 发送提取元数据命令，以便创建包含最新元数据信息的 .APP 文件，读取其格式并将其解析为 SNP_REV 表，如图 11 所示。在为 ODI 运行反向过程时，我们并不关心 HFM 应用中的元数据类型，我们关心的是 .APP HFM 文件中寸在的列和头部。

giampaoli-hfm-km-fig011
图 11 — ODI - HFM 反向流程

我们可以在下面的图 12 中看到一个 .APP 文件 Entity 维度下的样子。每个 .APP 文件将包含一个带有感叹号的头部，表示 HFM 中存在的一个维度。这一行的下方是所有需要发送到 HFM 的列，用于将成员加载到该维度上。

由于每个维度都有一组自己的列，我们在不同的 HFM 应用也有不同数量的 HFM 自定义维度，因此 ODI 反向过程只需向 HFM 发送一条命令即可一次性提取单个 .APP 文件中的所有维度，并解析整个文件以查找这些维度头部。当 ODI 发现其中一个维度时，它会在 SNP_REV_TABLE 和 SNP_REV_COL 表中插入相关信息。

giampaoli-hfm-km-fig012
图 12 — Entity.APP 文件示例

ODI 数据存储中还添加了 .APP 文件中所没有的其他一些信息。添加到数据存储中的这些信息有助于运行其他过程（例如，元数据和数据加载）。下面的表 1 列出了反向过程自动创建的其他信息以及创建这些信息的原因。

特性

原因

在自定义维度上创建“只读”的 AggregationWeight 列

AggregationWeight 并非以“列”的形式存在于 .APP 文件中，但 HFM 会在构建自定义层次结构时使用它。如果元数据加载过程中没有与 AggregationWeight 映射的对象，则默认值为 1。

为所有维度创建“只读”的 ParentMember 列

ParentMember 并非以“列”的形式存在于 .APP 文件中，但 HFM 会使用它构建成员之间的父/子关系。

表别名会相应地设置为该维度的 HFM API 函数名称

表别名用于在其他 HFM KM 中为其所属的各个维度调用正确的“SET”Java 命令。

“Default Parent”列使用“DefaultParent=”作为默认值

该默认值会在 HFM 元数据加载过程中自动添加到 .APP 文件中。

“Description(s)”列使用“<%=odiRef.getOption( "DESCRIPTION_LANGUAGE" )%>=”作为默认值

该默认值用于在 HFM 元数据加载过程中选择存储元数据的语言。在元数据加载 IKM 中，此选项的默认值为“English"。

根据 .APP 文件中的维度自动创建 HFMData 数据存储

HFMData 数据存储使用数据加载 IKM 将数据加载到 HFM（详见下一篇文章）。

表 1 — RKM 其他特性

ODI RKM 使用

本节重点介绍如何在完成架构设置后使用新的 RKM。本文假设读者已经熟悉 HFM 和 ODI 使用、拓扑、模型和接口配置的基本概念，将仅演示将数据存储信息反向工程到 ODI 的高级步骤。

首先是将新的 RKM 导入 ODI。这是一个非常简单的 KM，只需通过一个选项来设置反向工程数据存储信息时将生成的日志文件。双击该 KM 可以看到一段关于其基本情况和使用方法的简短描述。它与以前/较早的 ODI/HFM RKM 之间只有两点不同。第一个区别是新的 RKM 尚不支持“多期”HFM 数据表。这当然可以在将来根据需要决定是否实施，但现在我们决定暂不实施。

第二个区别是在数据服务器（物理架构）上设置“集群（数据服务器）”信息的方式。在新的 HFM API 中，我们需要介绍两个新设置：Oracle Home 和 Oracle Instance Paths。这些路径与安装了 HFM 应用的服务器相关。这些设置将在 HFM API 内部使用，以确定与该特定 HFM 实例相关的所有 HFM 信息。

为了支持这两个新设置，再加上为了继续在一个位置（ODI 拓扑）中容纳所有连接信息，“集群（数据服务器）”已经重载，接收了三个设置，而不是只有一个，这些设置用冒号分隔。因此，“集群（数据服务器）”现在接收“dataServerName:oracleHomePath:oracleInstancePath”，而不仅仅是 dataServerName。

giampaoli-hfm-km-fig013
图 13 — 数据服务器配置

要满足这些要求，只需创建一个新的数据服务器，并设置重载的“集群（数据服务器）”信息以及 ODI 用于访问 HFM 应用的用户名/密码。随后，我们只需使用 HFM 应用的名称创建一个物理模式，创建一个新的逻辑模式并将其与上下文相关联。

一切就绪，我们现在可以使用新的 RKM 对数据存储信息进行反向工程了。创建一个新的 ODI 模型并选择指向 HFM 应用的逻辑模式。在“Reverse Engineer”选项卡上，选择“Customized”和新的 RKM。为这个反向执行日志添加一个有效的文件夹位置，单击“Reverse Engineer”。

giampaoli-hfm-km-fig014
图 14 — 为反向工程建立配置模型

检查 Operator 中的执行是否顺利完成。如果已经顺利完成，您应该会看到所有 HFM 维度的列表以及 ODI Model 组件中的 HFMData 数据存储信息。

giampaoli-hfm-km-fig015
图 15 — 在 ODI 中成功地对 HFM 进行了反向工程
 

适用于 HFM 11.1.2.4 的 ODI 元数据集成知识模块

适用于 HFM 的 IKM 元数据加载分为两个步骤，如图 16 所示：第一步，在文件夹位置创建一个有效的 .APP 文件；第二步，将该 .APP 文件加载到 HFM 应用。这个 IKM 基本上模拟了可以使用工作区在 HFM 中完成的手动过程；用户可以创建一个有效的 .APP 文件并通过工作区将其加载到 HFM 应用。ODI 在此处用于抽象创建有效 .APP 文件这一过程的所有细节，同时支持用户在创建并将文件加载到 HFM 之前灵活执行各种 ETL 逻辑。

giampaoli-hfm-km-fig016
图 16 — IKM 命令步骤

IKM 的第一步是创建三个必要的 .APP 部分：头部、成员和层次结构。头部部分依据 ODI 接口创建过程中告知的 IKM 选项创建而成。

giampaoli-hfm-km-fig017
图 17 — .APP 头部部分

成员部分使用从源数据存储返回的元数据信息构建而成。

giampaoli-hfm-km-fig018
图 18 — .APP 成员部分

层次结构部分在创建时使用父/标签列构建成员之间的关系。

giampaoli-hfm-km-fig019
图 19 — .APP 层次结构部分

这个 IKM 使用由新 RKM 创建的 HFM 数据存储中预先配置的一些信息；例如，在成员部分中，代码将返回所有未设置为“Read Only”列的目标数据存储信息。回想一下，RKM 流程中创建的所有“人造”列（例如“Aggregation Weight”和“Parent Member”）均设置为"Read Only"，也就是说这些列并不是 .APP 文件的一部分，它们也不会作为成员列在文件中创建。

然而，它们随后将在层次结构部分中使用，其中“Parent Member”用于创建成员之间的层次结构关系，“Aggregation Weight”用作自定义维度的额外列，只有这两个维度使用“Aggregation Weight”信息。IKM 将使用表别名在 Java API 中调用正确的“set”方法。例如，“Account”维度会根据其别名“Accounts”调用“setAccounts”API 命令。“Entity”维度也是如此，它会根据其别名“Entities”调用“etEntities”。

可以看到，元数据 IKM 将转发一些在 RKM 反向流程中作为 ODI 数据存储的一部分创建的信息，因此如果您计划对数据存储对象本身进行任何更改，请谨慎操作，因为某些更改可能会导致新 IKM 停止正常运行。

ODI IKM 元数据使用

在 ODI 中正确地对 HFM 数据存储信息进行反向工程并导入新的“IKM SQL to Hyperion Financial Management Dimension 11.1.2.4 Java API”之后，现在该构建元数据加载接口了。您会注意到，它提供了比传统的适用于 HFM 的 IKM 元数据更丰富的选项。这是因为新的 IKM 主要分为两个步骤：首先在文件夹位置创建一个 .APP 文件，然后获取该 .APP 文件并将其加载到 HFM。

创建此 .APP 文件时需要在应用 IKM 选项的 ODI 接口对象中定义一些设置。表 2 列出了所有可用选项以及相关使用说明。

选项

描述

示例值

APP_FILE_DELIMITER

定义在 .APP 文件创建中将使用哪个分隔符。

; , | *

APP_FILE_LOCATION

定义在加载到 HFM 之前创建和存储 .APP 文件的文件夹位置。

C:/Temp/Account.app

CUSTOM_ORDER

HFM 应用中的自定义维度顺序。

Custom1;Custom2;

Custom3;Custom4

DESCRIPTION_LANGUAGE

元数据成员中使用的描述语言。

英语

FILE_FORMAT

HFM 应用的 .APP 文件格式。

11.12

LOG_LOCATION

日志文件位置。

C:/Temp/Account.log

ORDER_BY_COLUMNS

从源结果集中选择一个有效的列名称，将使用该列对 .APP 文件中的成员进行排序。

源结果集中的任何列名称

REMOVE_DUPLICATED_

FROM_HIERARCHIES

此选项可删除元数据源中可能存在的“父-成员”关系中的任何重复引用。创建此选项是因为 HFM 不允许 .APP 文件的层次结构会话中出现相同的重复关系。如果您的元数据中存在这种情况（重复），请将此选项设置为 True。注意：如果设置为 True，ORDER_BY_COLUMNS 将被忽略，并且会按照 Label 和 Parent Member 的顺序创建文件。

True

False

SET_CHECK_INTEGRITY

根据数据检查元数据以确保完整性。

True

False

SET_CLEAR_ALL

删除应用数据库中的所有维度成员以及相应的数据、日记帐和公司间交易。

True

False

SET_PRESCAN

设置为 True 可验证文件格式是否正确。注意：这不会将 .APP 文件加载到 HFM，而只会扫描文件格式。

True

False

SET_USE_REPLACE_MODE

如果设置为 True，将删除应用数据库中的所有维度成员，并将加载文件中的成员放入数据库。如果设置为 False，HFM 会采用合并形式加载：如果维度成员位于加载文件和应用数据库中，数据库中的成员会被加载文件中的成员所替换。如果数据库中包含加载文件未引用的其他维度成员，数据库中的成员不会发生更改。

True

False

START_WITH_MEMBER

设置用于构建父子关系的起始列名称。这必须是目标数据存储中的列，它与 START_WITH_VALUE 选项一起使用。

目标数据存储中的任何列名称。一般是 Label 或 ParentMember

START_WITH_VALUE

设置用于构建父子关系的起始值。它与 START_WITH_MEMBER 选项一起使用。

层次结构中的任何值。示例：

= "Channel"

= "Products"

Is null

Is Not null

= "BS"

VERSION

HFM 应用的 .APP 文件版本。

11.1.5026

表 2 — IKM 选项

我们都知道 IKM 选项用于正确地创建 .APP 文件，接下来详细介绍一下 CUSTOM_ORDER、FILE_FORMAT 和 VERSION 选项，这三个选项用于为 .APP 文件创建有效的头部。要确定 HFM 应用希望在 .APP 文件头中接收哪些信息的最便捷的方法就是在 HFM 应用中手动生成一个 .APP 文件。在您的 HFM 应用中，选择“Application Tasks/Extract/Application Elements”并从中导出任何元数据。

giampaoli-hfm-km-fig020
图 20 — 从 HFM 导出 .APP 文件

打开生成的 .APP 文件，您将看到一个有效的头部，因此您可以在 ODI IKM 选项上使用相同的信息。

.APP 文件的第二部分主要是元数据信息，这些信息基于接口 ETL 组件（例如，源转换逻辑、目标数据存储等）构建而成。任何选项都无法影响此部分。

对于第三部分，可以使用以下四个选项来正确构建它们：START_WITH_MEMBER、START_WITH_VALUE、REMOVE_DUPLICATED_FROM_HIERARCHIES 和 ORDER_BY_COLUMNS。这些选项将定义 IKM 如何在 .APP 文件上构建父子关系及其顺序。

它使用 Oracle 的 CONNECT BY 命令创建此关系，使用 START_WITH_MEMBER 和 START_WITH_VALUE 确定层次结构的第一个成员，然后据此构建层次结构。

ORDER_BY_COLUMNS 选项用于在创建 .APP 文件层次结构时定义成员的顺序。这个选项非常重要，因为 HFM 会根据此顺序将成员加载到应用。

REMOVE_DUPLICATED_FROM_HIERARCHIES 是一个特殊选项，用于包含“共享成员”（在层次结构中出现不止一次的成员）的复杂层次结构模型中。在这些情况下，由于 Oracle CONNECT BY 命令的性质，某个成员可能会在层次结构结果集中出现两次且信息相同。HFM 不允许这种情况发生，一旦发生，将抛出错误。可以使用 REMOVE_DUPLICATED_FROM_HIERARCHIES 选项绕过此限制，但这样做会导致 ORDER_BY_COLUMNS 选项被忽略，并且结果集将仅按标签和父成员的字母顺序排序。

由于所有其他选项都无需加以说明，而且不会影响 .APP 文件的创建，接下来我们可以开始创建 ODI 接口了。在这个例子中，我们将从一个 Oracle 表中加载 Custom1 维度。其创建方式与任何其他接口一样：您可以对映射的列执行联接、筛选和 ETL 修改等操作。

giampaoli-hfm-km-fig021
图 21 — 用于加载 HFM 元数据的 ODI 接口

请注意，由于我们的目标是 HFM 应用，因此我们需要将临时区域 (Staging Area) 设置为一个有效的 Oracle 逻辑模式（可能与源数据存储中使用的相同），以便对元数据执行任何 ETL。

giampaoli-hfm-km-fig022
图 22 — 设置不同的临时区域

在“Flow”选项卡中，选择集成所需要的选项并执行接口。如果一切顺利，那么您会在 ODI Operator 中看到两个绿色步骤，表示元数据已成功加载至 HFM 应用。您可以检查在 IKM 选项中添加的文件夹中创建的 .APP 文件以及所生成的日志。

giampaoli-hfm-km-fig023
图 23 — HFM 元数据加载日志信息

我们可以看到，用这种方法将元数据加载到 HFM 非常简单和透明，与旧版 ODI/HFM KM 所用方法相同。

 

总结：真实环境中的 HFM/ODI 集成

本文展示了 ODI 作为开发平台的真正实力。ODI 不仅仅是一款 ETL 工具，它超越了这个范围，让我们能够在几乎任何现有技术之间实现任何类型的连接。只需少量设置和一些重新设计的 KM，我们就可以重新实现传统的 HFM/ODI 连接，让我们能够对所需的元数据执行任何类型的 ETL，然后再轻松、系统性地将其加载到 HFM。

这些新的 KM 已经证明它们在实际项目中的价值。当公司要将 HFM 升级至较新版本时，使用旧的 HFM KM 创建的一些 ODI 作业需要被新系统创建的作业所替代。这是一项伟大的成就，因为不需要在环境中安装任何新应用（如 FDMEE）；而且，所有原来的 ODI 代码都可以重复使用，因为要让 ODI 在新版本的 HFM 中继续正常运行，只需用新的 KM 替换旧的 KM，并对其拓扑、数据存储和接口选项进行一些细微的调整。

在新的 HFM 实施中，用户可以使用 ODI 创建功能强大、可扩展且开发复杂性极低的企业集成解决方案，因为新的 ODI KM 可以抽象出其内部的所有硬逻辑并根据需要重复使用多次。此外，借助 ODI，用户还可以将任何类型的元数据和数据源集成到 HFM 中，确保所有业务需求得到充分满足，包括各种高度复杂的要求。

ODI 是一个动态、强大的工具，可为创建和维护 EPM 环境提供一个优秀的平台。本文为我们突破想象力的限制提供了一些指引。只需对 KM 进行少量改动，我们就可以突破默认开发的边界、实现更高水平的卓越运营并提供更高的灵活性、可靠性和可扩展性来应对全球竞争性环境中的挑战。

关于作者

Oracle ACE Rodrigo Radtke 是 Dell 的软件开发顾问，致力于研发 ODI 和 EPM 工具。他是一位拥有丰富软件开发经验的计算机工程师，尤为擅长财务 BI 领域，同时也是一位 Oracle Data Integrator、Oracle SQL Expert 和 Java（SCJP 和 SCWCD）认证专家。

Oracle ACE Ricardo Giampaoli 是管理硕士和系统分析师，拥有 20 年的 IT 行业经验，过去九年中一直担任 EPM 顾问。他是一位 Hyperion Planning、Essbase、OBIEE 和 ODI 认证专家，擅长使用各种 Oracle 工具。

Rodrigo 和 Ricardo 经常会在 Kscope 等活动中以及他们的博客（https://devepm.com/）上分享自己的专业知识。

附录

HFM 11.1.2.4 和 ODI 11.1.1.9 集成所需的 Jar 文件：

Jar 文件

  

adm.jar

admaps.jar

admodbo.jar

ap.jar

ArtifactListing.jar

audit-client.jar

axiom-api-1.2.10.jar

axiom-impl-1.2.10.jar

axis-ant.jar

axis-jaxrpc-1.2.1.jar

axis.jar

axis2-adb-1.5.4.jar

axis2-kernel-1.5.4.jar

axis2-transport-http-1.5.4.jar

axis2-transport-local-1.5.4.jar

backport-util-concurrent.jar

broker-provider.jar

bsf.jar

castor-1.3.1-core.jar

castor-1.3.1.jar

com.bea.core.apache.commons.collections_3.2.0.jar

com.bea.core.apache.commons.net_1.0.0.0_1-4-1.jar

com.bea.core.apache.commons.pool_1.3.0.jar

com.bea.core.apache.log4j_1.2.13.jar

com.bea.core.apache.regexp_1.0.0.0_1-4.jar

com.bea.core.apache.xalan_2.7.0.jar

com.bea.core.apache.xml.serializer_2.7.0.jar

com.oracle.ws.orawsdl_1.4.0.0.jar

commons-cli-1.1.jar

commons-codec-1.4.jar

commons-compress-1.5.jar

commons-configuration-1.5.jar

commons-dbcp-1.4.0.jar

commons-discovery-0.4.jar

commons-el.jar

commons-fileupload-1.2.jar

commons-httpclient-3.1.jar

commons-io-1.4.jar

commons-lang-2.3.jar

commons-validator-1.3.1.jar

cpld.jar

css.jar

cssimportexport.jar

ctg.jar

ctg_custom.jar

dms.jar

epml.jar

epm_axis.jar

epm_hfm_web.jar

epm_j2se.jar

epm_jrf.jar

epm_lcm.jar

epm_misc.jar

epm_stellant.jar

epm_thrift.jar

essbaseplugin.jar

essbasestudioplugin.jar

ess_es_server.jar

ess_japi.jar

fm-actions.jar

fm-adm-driver.jar

fm-web-objectmodel.jar

fmcommon.jar

fmw_audit.jar

glassfish.jstl_1.2.0.1.jar

hssutil.jar

httpcore-4.0.jar

identitystore.jar

identityutils.jar

interop-sdk.jar

jacc-spi.jar

jakarta-commons.jar

javax.activation_1.1.jar

javax.mail_1.4.jar

javax.security.jacc_1.0.0.0_1-1.jar

jdom.jar

jmxspi.jar

jps-api.jar

jps-common.jar

jps-ee.jar

jps-internal.jar

jps-mbeans.jar

jps-unsupported-api.jar

jps-wls.jar

js.jar

json.jar

jsr173_1.0_api.jar

lcm-clu.jar

lcmclient.jar

LCMXMLBeans.jar

ldapbp.jar

ldapjclnt11.jar

libthrift-0.9.0.jar

log4j-1.2.14.jar

lucene-analyzers-1.9.1.jar

lucene-core-1.9.1.jar

lucene-spellchecker-1.9.1.jar

neethi-2.0.4.jar

ojdbc6dms.jar

ojdl.jar

opencsv-1.8.jar

oraclepki.jar

org.apache.commons.beanutils_1.8.3.jar

org.apache.commons.digester_1.8.jar

org.apache.commons.logging_1.1.1.jar

osdt_cert.jar

osdt_core.jar

osdt_xmlsec.jar

quartz.jar

registration_xmlBeans.jar

registry-api.jar

resolver.jar

saaj.jar

scheduler_ces.jar

servlet-api.jar

slf4j-api-1.5.8.jar

slf4j-log4j12-1.5.8.jar

sourceInfo.jar

stax-api-1.0.1.jar

wf_ces_utils.jar

wf_eng_agent.jar

wf_eng_api.jar

wf_eng_server.jar

wldb2.jar

wlpool.jar

wlsqlserver.jar

wsplugin.jar

xbean.jar

xmlparserv2.jar

xmlpublic.jar

xmlrpc-2.0.1.jar

XmlSchema-1.3.1.jar

表 3 — 所需的 Jar 文件

本文谨代表作者的专业见解、结论和意见。Oracle 发布本文旨在鼓励社区内就这些信息进行广泛交流，并促进同行的评估和评论。Oracle 相关产品团队尚未审查本文是否符合 Oracle 的标准和实践，其发布不应被解释为 Oracle 对其中所表述内容的认可。