| Oracle Business Intelligence Applicationsリリース・ノート リリース7.9.4 E06111-01 |
|
 戻る |
このリリース・ノートでは、Oracle Business Intelligence Applicationsリリース7.9.4に関する既知の問題と対処方法について説明します。次の各項で構成されています。
このリリース・ノートは、新しい情報が入手可能になった時点で定期的に更新されます。最新バージョンのリリース・ノートを参照できるように、次のOracle Business Intelligence ApplicationsドキュメントのWebサイトをチェックしてください。
この項では、Oracle Business Intelligence Applications製品に関する一般的な問題とその対処方法について説明します。この項の内容は次のとおりです。
動作要件の詳細は、『Oracle Business Intelligence Applicationsシステム要件およびサポートされるプラットフォーム』を参照してください。このマニュアルは、Oracle Business Intelligence Applicationsのドキュメント・セットにあります。次の場所にあるOracle Metalinkの「Certify」タブからも入手できます。
この項では、Oracle Business Intelligence Applicationsのインストールおよびアップグレードに関するリリース・ノートについて説明します。この項の内容は次のとおりです。
以前のリリースからアップグレードする場合は、Oracle Business Intelligence Presentation Catalogだけでなく、Oracle BI Applications環境全体の複数インスタンスの共存をアップグレード準備段階で計画しておいてください。
アップグレードを正常に実行するには、Oracle BI Applications環境全体の複数インスタンスの共存が不可欠です。
この項では、Oracle Business Intelligence Applicationsの各ドキュメントの修正事項について説明します。この項の内容は次のとおりです。
第1.2.3.1項「『Oracle Business Intelligence Applicationsインストレーションおよび構成ガイド』の修正事項」
第1.2.3.2項「『Oracle Business Intelligence Applicationsアップグレード・ガイド』の修正事項」
第1.2.3.3項「『Oracle Business Intelligence Applicationsデータ・ウェアハウス管理コンソール・ガイド』の修正事項」
『Oracle Business Intelligence Applicationsインストレーションおよび構成ガイド』には、次の修正事項があります。
「はじめに」のOTN索引ページへのURLリンクで、「www」の前にスペースがあります。正しくは次のとおりです。
http://www.oracle.com/technology/about/index.html
次のリンクは間違っています。
http:// www.oracle.com/technology/about/index.html
PDF版のドキュメントでこのURLリンクを選択すると、ブラウザにOTNページが正しく表示されますが、HTML版では選択しても表示されません。
Oracle Business Intelligence Applicationsリリース7.9.4には該当しません。
Oracle Business Intelligence Applicationsリリース7.9.4には該当しません。
この項では、Oracle Business Intelligence Applications全般に関するリリース・ノートについて説明します。この項の内容は次のとおりです。
第1.3.4項「SAシステムのプレゼンテーションカラムの不正な名前が原因でiBotのアプリケーション・ユーザーへの配信ができない」
第1.3.10項「Oracle Business Intelligence Applicationsリリース7.7.1.xでのマッピングの問題」
第1.3.14項「Oracle Business Intelligence Presentation Catalogにおけるレポートの問題」
第1.3.19項「Oracle Business Intelligence Interactive Dashboardsのあいさつで不適切なユーザー名が表示される」
データ・ウェアハウス管理コンソールを使用すると、異なるソース・システム・コンテナからのサブジェクトエリアで構成される実行プランを作成できます。ただし、今回のリリースでは、この機能がサポートされていません。たとえば、Oracle Applications 11.5.8とSiebel Applications 7.8のサブジェクトエリアを同じ実行プランに含めることはできません。
この問題を回避するには、異なるコンテナのサブジェクトエリアに対して、別個の実行プランを作成してください。たとえば、実行プランにOracle Applications 11.5.8コンテナのSales、InventoryおよびReceivablesというサブジェクトエリアがあるとします。この場合、Siebel Applications 7.8のSalesサブジェクトエリアをポピュレートするには、別の実行プランを用意する必要があります。
データ・ウェアハウス管理コンソールの完全ロード・コマンドと増分ロード・コマンドは、ソーステーブルからデータが前回抽出された日付と、データがターゲットテーブルに前回ロードされた日付に基づいて実行されます。
このように最終抽出日と最終ロード日に依存してしまうと、2つの異なるソース・システムからデータを初めてロードする際に問題が発生する場合があります。たとえば、最初のソースのETLを完全抽出と完全ロードで実行して、2つ目のソースのETLを完全抽出と増分ロードで実行するとします。この場合、2つ目のロード操作が最初のものよりも遅くなる可能性があります。完全なロード・マッピングは、増分マッピングよりも単純な処理だからです。増分マッピング（特に集計テーブル）では、デルタ集計、データ操作などの複雑な処理が行われるため、増分ロードはより負荷が高い操作になります。
日常的なETL操作において、増分ETL実行時のパフォーマンス劣化は、データ量が少ないため顕著でないことがありますが、2つのソース・システムから相次いでデータが初回抽出および初回ロードされる状況では、大量のデータが増分モードでロードされるため、2つ目のロード操作はかなり遅くなります。
たとえば、Oracle Applications 11.5.8から3年分のデータを抽出およびロードした後で、Oracle Applications 11.5.10から3年分のデータをロードしたとします。この場合、Oracle Applications 11.5.10ソースのロード操作の速度は著しく低下します。
この問題への対処方法はありません。
Oracle 9iリリース2 Databaseで実行プランを作成する場合、データ・ウェアハウス管理コンソールのリポジトリをバッチ・モードで使用できません。この状況でバッチ・モードを有効にすると、次のようなエラー・メッセージが表示されることがあります。
MESSAGE:::Error while persisting dependency. EXCEPTION CLASS::: com.siebel.analytics.etl.execution.ExecutionPlanInitializationException
このエラーは、Oracle 9i JDBCドライバで配列挿入やバルク挿入が処理されないために発生します。実行プランは、バルク挿入を使用しないと正常に作成されます。
この問題を回避するには、次の手順を実行します。
実行プランの作成時には、「Enable Batch Mode」ボックスの選択を解除します。デフォルトでは、バッチ・モードが有効になります。
Oracle Database 10gで使用可能なJDBCドライバを使用し、シン接続でDACリポジトリに接続します。
Oracle Business Intelligence DeliversのiBotでは、SAシステムのサブジェクトエリアに対して事前定義済クエリーを実行して、iBotの受信者グループに関連付けられたアプリケーション・ユーザーの一覧を取得します。iBotを実行すると、この事前定義済クエリーが次のようなエラー・メッセージを表示して失敗します。
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 27005] Unresolved column: "Time Zone".
このクエリー・エラーによって、iBotの受信者グループに関連付けられたアプリケーション・ユーザーへのコンテンツ生成やコンテンツ配信ができなくなります。このエラーは、インタラクティブダッシュボードや電子メール、Oracle Business Intelligence Disconnected Analyticsの切断モードで使用するアプリケーションのキャッシュ生成など、iBotのすべての宛先タイプに影響を与えます。この問題は、SAシステムのサブジェクトエリアの「Time Zone」プレゼンテーションカラムが、「Timezone」と誤って記述されているために発生します。
この問題を回避するには、Oracle Business Intelligence Administration Toolを使用して、SAシステムのプレゼンテーションカタログで現在「Timezone」と定義されているプレゼンテーションカラムを「Time Zone」に変更してください。
SAシステムのサブジェクトエリアについては、『Oracle Business Intelligence Server管理ガイド』を参照してください。
Oracle BI DeliversのiBotでは、SAシステムのサブジェクトエリアに対して事前定義済クエリーを実行して、iBotの受信者グループに関連付けられたアプリケーション・ユーザーの一覧を取得します。iBotを実行すると、ユーザー設定でタイムゾーンが指定されていないユーザーは無効であるとみなされ、iBotが配信されません。
この問題は、SAシステムのビジネスモデルにあるS_USER論理テーブルソースのS_TIMEZONE結合で、結合タイプが右の外部結合ではなく、内部結合として定義されているために発生します。
この問題を回避するには、次の手順を実行します。
Oracle Business Intelligence Administration Toolを表示します。
「Business Model and Mapping」レイヤーで、SAシステムのビジネスモデルとUSER論理テーブルを開きます。
「USER Logical Table」の「Sources」で、S_USER論理テーブルソースをダブルクリックします。
「Logical Table Source - S_USER」ダイアログ・ボックスにある「General」タブの「Joins」セクションで、S_TIMEZONE結合の結合タイプを「INNER」から「RIGHT OUTER」に変更します。
SAシステムのサブジェクトエリアについては、『Oracle Business Intelligence Server管理ガイド』を参照してください。
最大カラム数255を超えるいくつかの次元テーブルでは、次元の要素参照が遅くなるため、参照データベース・サーバーのメモリーが不足してしまいます。次のテーブルでは、この問題が報告されています。
W_CUSTOMER_FIN_PROFL_D
W_CUSTOMER_LOC_D
W_CUSTOMER_LOC_USE_D
W_ORG_D
W_PRODUCT_D
W_SALES_PRODUCT_D
W_SUPPLIER_PRODUCT_D
この問題を回避してパフォーマンスを向上させるには、次の手順を実行します。
実行速度の遅いセッションを編集します。
上述の大規模な次元を参照するすべての変換で、次のように変更します。
インデックス・キャッシュ・サイズ = 10MB
データ・キャッシュ・サイズ = 20MB
この変更はセッション側で行うため、マッピングを変更する必要はありません。
データ・ウェアハウス管理コンソールでは、完全または増分ロードでプライマリ・ターゲットテーブルが切り捨てられると、ETLのパフォーマンスを向上させるため、そのターゲットテーブルの特定タスクに対して定義されている登録インデックスが自動的に削除および再作成されます。また、このテーブルでインデックスを再作成した後に、ETLインデックスに関する統計が自動的に収集されます。データベース・オプティマイザはこの統計を使用して、データのクエリーの最適なアクセス・パスを選択します。
このタスクの完全および増分ロード・コマンドの基になるワークフローはSDE_ListOfValuesです。これは、SIL_ListOfValuesGeneralセッションとSIL_CopyListOfValuesToOLTPセッションで構成されています。最初のセッションはW_LST_OF_VAL_Gテーブルをポピュレートし、2つ目のセッションはW_LST_OF_VAL_GテーブルのS_ETL_LOVテーブルをポピュレートします。S_ETL_LOVテーブルはこのタスクのプライマリ・テーブルとして定義されているため、データ・ウェアハウス管理コンソールではW_LST_OF_VAL_Gテーブルが分析されません。
このタスクを変更して、W_LST_OF_VAL_Gテーブルを別のプライマリ・テーブルとして含めたとしても、このテーブルは、上述の2つのセッションを構成するワークフロー全体が実行されるまで分析されません。そのため、分析されていないW_LST_OF_VAL_Gテーブルから行を抽出してS_ETL_LOVテーブルにポピュレートするまで、タスクがハングしてしまいます。
この問題を回避する手順は次のとおりです。
必要に応じて、この回避策が適用されるデプロイ済コンテナをコピーします。デフォルトのコンテナに変更を加えることはできません。
Informatica Workflow Managerで、SIL_ListOfValuesGeneralセッション用とSIL_CopyListOfValuesToOLTPセッション用に、それぞれ1つずつ新しいワークフローを作成します。ワークフロー名は、ワークフロー内で使用されるセッション名と同じ名前にする必要があります。
データ・ウェアハウス管理コンソールで、固定値リストとOLTPへのコピー・タスク用に、それぞれ1つずつコピーを作成します。最初のコピーはFix List Of Values（固定値リスト）、2つ目のコピーはCopy List Of Values to OLTP task（OLTPタスクへの値リストのコピー）と、命名してください。これらのタスクのプロパティが、次のように設定されていることを確認します。
タスク1: Fix List Of Values
Command for Incremental Load: SIL_ListOfValuesGeneral
Command for Full Load: SIL_ListOfValuesGeneral
Folder Name: Extract
Primary Source: DBConnection_OLAP
Primary Target: DBConnection_OLTP
Task Phase: General
Execution Type: Informatica
Priority: 5
Source Tables: W_LST_OF_VAL_G（プライマリ）、W_PARAM_G（参照）
Target: W_LST_OF_VAL_G（プライマリ）
「Truncate Always」と「Truncate For Full Load」の両オプションが選択されていないことを確認してください。
タスク2: Copy List of Values to OLTP
Command for Incremental Load: SIL_CopyListOfValuesToOLTP
Command for Full Load: SIL_CopyListOfValuesToOLTP
Folder Name: Extract
Primary Source: DBConnection_OLAP
Primary Target: DBConnection_OLTP
Task Phase: General
Execution Type: Informatica
Priority: 5
Source Tables: W_LST_OF_VAL_G（プライマリ）
Target: S_LST_OF_VAL（プライマリ）
「Truncate Always」と「Truncate For Full Load」の両オプションが選択されていることを確認してください。
TASK_GROUP_Extract_lst_of_valタスク・グループを編集して、Fix List of ValuesとCopy to List task（リストのコピー・タスク）を削除します。その後、新しく作成したFix List Of ValuesとCopy List Of Values to OLTPの両タスクをこのタスク・グループに追加します。これらのタスクの実行順序を次のように設定します。
Fix List of Values: 1
Copy Lists of Values to OLTP: 2
該当するサブジェクトエリアを再アセンブルして、これらの新しいタスクをサブジェクトエリアに含めます。
これらのタスクが実行される実行プランを再作成します。
Oracle BI Applicationsおよびデータ・ウェアハウス内での複数通貨に対する現在のサポートと設計では、トランザクション・システム（またはOLTPシステム）に為替レートと、それらを格納するテーブル構造が存在することを前提とします。
OLTPシステムで、「取引通貨」から選択した「1つ以上のデータ・ウェアハウス通貨」への為替レートが提供されないと、要素テーブルの「取引」通貨から「グローバル1」通貨への為替レートがNULLになります。そのため、これらの取引ではグローバル通貨に基づく分析ができなくなります。また、複数の集計テーブルに格納されているデータの正確性にも影響します。この問題は、サポートされている他の2つの通貨（グローバル2とグローバル3）にも影響を与えます。
この問題を回避するには、選択した3つのデータ・ウェアハウス通貨として追加する前に、OLTPシステムにおける全取引通貨に対応する為替レートをすべて用意してください。この処理を行ってないため為替レートの問題が発生する場合は、OLTPシステムでその問題を解決してから、全トランザクションを再実行できます。
Teradataデータソースのマーケティング・メタデータでセグメントの保存済み結果セットを設定する場合、保存済み結果セット・ヘッダーの挿入に関するデフォルトSQLで構文エラーが検出されます。セグメントの保存済み結果セットを保存しようとすると、次のエラー・メッセージが表示されます。
Odbc driver returned an error (SQLExecDirect). State: 37000. Code: 10034. [NQODBC] [SQL_STATE: 37000] [nQSError: 10034] The SQL statement has a syntax error. [nQSError: 43093] An error occurred while processing the EXECUTE PHYSICAL statement. [nQSError: 16001] ODBC error state: 37000 code: -3706 message: [NCR][ODBC Teradata Driver][Teradata RDBMS]Syntax error: expected something between the 'COUNT' keyword and ','.. [nQSError: 16014]]
この問題の原因は、Teradataデータベースでは、デフォルトSQLのCOUNTキーワードに二重引用符が必要なことにあります。この問題を回避するには、次の手順を実行します。
Oracle BI Administration Toolで、「Manage」メニューの「Marketing」を選択します。
「Target Level」をダブルクリックし、「Saved Result Sets」タブを選択します。
COUNTキーワードを二重引用符で囲むことによって、保存済み結果セット・ヘッダーを挿入する物理SQLを変更します。
次の例では、SQLコードのCOUNTキーワードが二重引用符で囲まれています。
INSERT INTO M_SR_HEADER (GUID, SEGMENT_PATH, DATE_TIME, TARGET_LEVEL, "COUNT", CREATED_BY) VALUES ('@{guid}', '@{segmentPath}', '@{createdTime}', '@{targetLevel}', @{count}, '@{createdBy}')
バインドなしのLOVタイプを、S_LST_OF_VAL OLTPテーブルからデータ・ウェアハウス・テーブルに移動するために使用した「SIL_ListofValuesDimension_MissingActivityCodes」マッピングは、使用できません。この問題は、バインドされたLOVタイプを使用している場合は発生しません。ただし、バインドなしのLOVタイプをsra_resolution_cdで使用している場合は、リリース7.7.1.xでもこのマッピングが必要です。
この問題を回避するには、データソースがOracle Siebel CRM Applicationsリリース7.7以上の場合、新しい環境に古いマッピングを再インポートしてから1回かぎりのジョブとして実行します。Oracle Siebel CRM Applicationsリリース7.5.3以下の場合は、このジョブをETLプロセスの一部として実行します。
英語以外のマシンでInformatica Infa Serverを使用する環境でウェアハウスをOracleデータベース上で稼働している場合、Informatica Serverからウェアハウスへ、小数のデータタイプ・カラムを含むレコードを挿入しようとすると、Oracleデータベースの問題が発生することがあります。次のようなOracleエラー・メッセージが表示されます。
Error: ORA-01722: invalid number
この問題を回避するには、セッション・プロパティの「Enable high precision」オプションの選択を解除します。このオプションは、小数点ポートの精度を28桁以下にするかどうかを示します。Informaticaでは、このオプションを解除すると、小数点ポートの精度が15桁以下になります。Oracle Business Intelligence Applicationsでは、IDカラムに小数点ポートが使用されているため、15桁の精度で十分です。
Informatica PowerCenterの制限により、Oracle BI Applicationsの英語以外のデプロイメント（日本語、簡体字中国語など）では、Informatica Repositoryの復元にPMREPAGENT restoreコマンドを使用する必要があります。Oracle BI Applicationsの英語以外のデプロイメントでInformatica PowerCenterのユーザー・インタフェースを使用してInformatica Repositoryを復元しようとすると、そのプロセスに失敗します。
Informatica Repositoryを英語以外のデプロイメントで復元するには、次のサンプル・コマンドのとおり、PMREPAGENT restoreコマンドを使用します。
\OracleBI\dwrep\Informatica\PMREP\PMREPAGENT restore -r <INFA_REP_NAME> -t <INFA_REP_CONNECT_TYPE> -u <INFA_REP_DBOWNER> -p <INFA_REP_PASSWORD> -c <INFA_REP_CONNECT_STR> -h <INFA_REPSERVNAME> -o <INFA_REPSERVPORT> -i <INFA_REP_FILE> -n
PMREPAGENTコマンドの詳細は、Informatica PowerCenterのインストールと構成に関するドキュメントを参照してください。
地域次元テーブルにマッピングされている「キャンペーン担当者セグメント分析」カタログの「コンタクト地域」次元属性が、キャンペーン履歴要素テーブルに適切に結合されていません。そのため、この次元を使用すると、Oracle Business Intelligence Serverで適切なナビゲーション・パスを見つけることができません。
この問題を回避するには、「キャンペーン担当者セグメント分析」カタログから地域次元を削除します。この次元を使用する際には、「顧客プロファイルセグメント分析」など、この次元を持つ別のサブジェクトエリアに切り替えてから、そこで参照してください。
出荷時のOracle BI Presentation Catalogでは、次のレポートのクエリー・パフォーマンスが低くなります。
/共有/インタラクティブ販売/価格決定/プロモーション/推奨プロモーション
/共有/インタラクティブ販売/価格決定/プロモーション/マーケットバスケット分析 - プロモーションの推奨
/共有/マーケティング/顧客動向 (B2C)/プロダクト/次回購入製品
/共有/インタラクティブ販売/プロダクト/マーケティング/次回購入製品
現行リリースでは、これらのレポートを使用しないでください。この問題への対処方法はありません。
DACのデプロイ手順によって、ETLにおけるシーケンス・ジェネレータの変換がリセットされ、1から再度開始されます。そのため、様々なアプリケーションとアダプタのソース独立ロード（Source Independent Load: SIL）マッピングを同時に実行すると問題が発生する場合があります。これらのSILマッピングは同時に実行できません。
この制限については、同時に実行できないETL操作を示す次の2つの例で説明します。
Siebel VerticalアダプタとOracle EBSアダプタを使用する場合。SiebelアダプタではSIL_VertフォルダのSILマッピングが、Oracle EBSアダプタではSILOSフォルダのSILマッピングがそれぞれ使用されます。SIL_Vertフォルダのシーケンス・ジェネレータは新しい値に更新されますが、SILOSフォルダの対応するシーケンス・ジェネレータは更新されません。そのため、共通次元（従業員、為替レートなど）に対するSILOSマッピングはすべて失敗します。
SILOSフォルダとPLPフォルダにあるマッピングから同じ次元表がロードされる場合。前述と同じ問題が発生するため、マッピングの実行に失敗します。
この問題を回避するには、一方のフォルダのシーケンス・ジェネレータ値を1〜1,000,000,000のように、上限に十分大きな有限値を設定してから、SILOSフォルダのシーケンス・ジェネレータ値を1,000,000,001〜2,000,000,000（最大値）に設定します。
MPLT_SA_ORA_SalesInvoiceLinesFactのEXT_SALES_ORDER_NUM、EXT_SALES_ORDER_ITEMおよびEXT_ITEM_DETAIL_NUMの式が、SALES_ORDLN_IDと矛盾しています。
リリース7.9、7.9.1および7.9.2の場合、次の手順で問題を修正してください。
MPLT_SA_ORA_SalesInvoiceLinesFactのSALES_ORDER_NUM、SALES_ORDER_LINEおよびITEM_DETAIL_NUMの式を、次のように変更します。
IIF(INP_INTERFACE_LINE_CONTEXT='ORDER ENTRY', INP_SALES_ORDER, NULL)
IIF(INP_INTERFACE_LINE_CONTEXT='ORDER ENTRY', INP_SALES_ORDER_LINE, NULL)
IIF(INP_INTERFACE_LINE_CONTEXT='ORDER ENTRY', INP_ITEM_DETAIL_NUMBER, NULL)
Siebel OLTP 8.0を使用している場合は、次のようにRPD会計レイヤーにフィルターを追加する必要があります。
Oracle BI Administration Toolを表示します。
「Forecasting Siebel OLTP」接続プールの物理レイヤーで、テーブルS_FCST_ITEM_DTLを開きます。
選択タイプを変更します。
ウィンドウに、次のSQLを貼り付けます。
S_FCST_ITEM_DTL.AGGR_DIM_NAME_1 IS NULL AND
S_FCST_ITEM_DTL.AGGR_DIM_NAME_2 IS NULL AND
S_FCST_ITEM_DTL.AGGR_DIM_NAME_3 IS NULL AND
S_FCST_ITEM_DTL.AGGR_DIM_NAME_4 IS NULL AND
S_FCST_ITEM_DTL.AGGR_DIM_NAME_5 IS NULL AND
S_FCST_ITEM_DTL.AGGR_DIM_NAME_6 IS NULL
変更内容を保存します。
Siebel 8.0に事前インストールされている電子メールのパーソナライズ・フォーマットでは、生成済リストがトリートメントIDによって制約されません。そのため、キャンペーン開始時に、所定のトリートメントのリストファイルを生成するSOAPコールが発行されると、そのキャンペーンの該当者全員がリストで返されてしまいます。たとえば、2つの異なるキャンペーン・メンバー・セットに割り当てられた2件の電子メール・トリートメントがある場合、この問題が原因でキャンペーン・メンバー全員に両方のトリートメントが送信されます。
この項では、この問題の対処方法について説明します。
この項では、Oracle BI Administration Toolでリポジトリを更新する方法について説明します。
Oracle BI Administration Toolを起動します。
「Physical」レイヤーで、物理カラムDCP_IDをMarketing OLTPデータベースのCampaign Promotion物理テーブルに追加してから、「Physical Column」ダイアログで次の値を指定します。
Name: DCP_ID
Type: VARCHAR
Length: 15
Nullable: yes
「Business Model and Mapping」レイヤーで、論理カラムTreatment IdをMarketing Contact ListビジネスモデルのOLTP Campaign Promotion論理テーブルに追加してから、「Logical Column」ダイアログで次の値を指定します。
Name: Treatment Id
Logical Table Source: S_CAMP_CON
Mapped as: "Marketing OLTP".dbo."Campaign Promotion".DCP_ID
「Business Model and Mapping」レイヤーで、論理カラムTreatment IdをMarketing Account ListビジネスモデルのOLTP Campaign Promotion論理テーブルに追加してから、「Logical Column」ダイアログで次の値を指定します。
Name: Treatment Id
Logical Table Source: S_CAMP_CON
Mapped as: "Marketing OLTP".dbo."Campaign Promotion".DCP_ID
「Presentation」レイヤーで、プレゼンテーションカラムTreatment IdをMarketing Contact ListプレゼンテーションカタログのCampaign History（トランザクションデータベース）プレゼンテーションテーブルに追加してから、「Presentation Column」ダイアログで次の値を指定します。
Name: Treatment Id
Logical Column: "Marketing Contact List"."OLTP Campaign Promotion"."Treatment Id"
「Presentation」レイヤーで、プレゼンテーションカラムTreatment IdをMarketing Account ListプレゼンテーションカタログのCampaign History（トランザクションデータベース）プレゼンテーションテーブルに追加してから、「Presentation Column」ダイアログで次の値を指定します。
Name: Treatment Id
Logical Column: "Marketing Account List"."OLTP Campaign Promotion"."Treatment Id"
この項では、Siebel Marketingの「キャンペーンロードフォーマット」と「電子メールサーバーフォーマット」を更新する方法について説明します。
Siebel Marketingにログインします。
「キャンペーン担当者」統合コンポーネントに「トリートメント ID」を追加し、「カラム式の編集」ダイアログで次の値を指定します。
テーブルの見出し: キャンペーン担当者
カラムの見出し: トリートメント ID
カラム式: '@{treatmentID}{0}'
「トリートメント ID」カラムに基づいて出力を制約するフィルターを追加し、「フィルターの作成と編集」ダイアログで次の値を指定します。
演算子: 等しい/存在する
式: '@{treatmentID}{0}'
ソース・システムがOracle E-Business Suite（EBS）またはOracle PeopleSoftの場合、Oracle Business Intelligence Interactive Dashboardsのあいさつでユーザー名が正しく表示されません。ダッシュボードヘッダーのあいさつで使用される変数DISPLAY_NAMEは、LOGINプロパティという初期化ブロックを介してポピュレートされます。出荷時の設定では、この初期化ブロックで使用される接続プールとSQL文はSiebel OLTPを指しています。Oracle Business Intelligence Applicationsを実行する際にソース・システムがOracle EBSまたはPeopleSoftの場合、「Initialization Block: LOGIN Properties」の接続プールとデータソースSQLを次のように変更する必要があります。
この問題の解決策は次のとおりです。
Oracle BI Administration Toolを使用して、EnterpriseBusinessAnalytics.rpdファイルを開きます。
「Manage」→「Variables」にナビゲートし、Variables Managerを開きます。
「Session」→「Initialization Block」で、「LOGIN Properties」初期化ブロックを選択します。
ダブルクリックして、プロパティ・ダイアログ・ボックスを開きます。
「Edit Data Source」ボタンをクリックします。
「Browse」ボタンをクリックします。
ご使用のOLTPシステムに応じて、「Select Connection Pool」ウィンドウで、Oracle EBS OLTP接続プールまたはPeopleSoft OLTP接続プールのいずれかを選択します。
「Session Variable Initialization Block Data Source - LOGIN Properties」ウィンドウの「Default Initialization String」ボックスで、ソース・システム・アプリケーションと実行中のデータベース・プラットフォームに応じて適切なSQLを入力します。
表1-1 ソース・システム・アプリケーションとデータベースの各組合せで必要なSQL文字列
| ソース・システム・アプリケーション（データベース・プラットフォーム） | デフォルトの初期化文字列に必要なSQL |
|---|---|
|
Oracle EBS（Oracle RDBMS） |
Select PER.FULL_NAME, 0 from PER_ALL_PEOPLE_F PER, FND_USER USR WHERE USR.USER_NAME= ':USER' AND USR.EMPLOYEE_ID=PER.PERSON_ID AND (SYSDATE <= USR.END_DATE OR USR.END_DATE IS NULL) AND PER.EFFECTIVE_START_DATE <= USR.START_DATE AND (USR.START_DATE < PER.EFFECTIVE_END_DATE OR PER.EFFECTIVE_END_DATE IS NULL) |
|
PeopleSoft（Oracle RDBMS） |
SELECT CASE WHEN EMPLOYEE_NAME_TODAY.EMPLID IS NULL THEN USR.OPRDEFNDESC ELSE EMPLOYEE_NAME_TODAY.NAME END DISPLAY_NAME, 0 FROM PSOPRDEFN USR LEFT OUTER JOIN (SELECT B.EMPLID, B.NAME FROM PS_NAMES B, (SELECT EMPLID, MAX(EFFDT) EFFDT FROM PS_NAMES WHERE NAME_TYPE = 'PRI' AND EFFDT <= SYSDATE GROUP BY EMPLID) C WHERE B.EMPLID = C.EMPLID AND B.EFFDT = C.EFFDT AND B.NAME_TYPE = 'PRI') EMPLOYEE_NAME_TODAY ON USR.EMPLID = EMPLOYEE_NAME_TODAY.EMPLID WHERE USR.OPRID=':USER' |
|
PeopleSoft（MSSQL RDBMS） |
SELECT CASE WHEN EMPLOYEE_NAME_TODAY.EMPLID IS NULL THEN USR.OPRDEFNDESC ELSE EMPLOYEE_NAME_TODAY.NAME END DISPLAY_NAME, 0 FROM PSOPRDEFN USR LEFT OUTER JOIN (SELECT B.EMPLID, B.NAME FROM PS_NAMES B, (SELECT EMPLID, MAX(EFFDT) EFFDT FROM PS_NAMES WHERE NAME_TYPE = 'PRI' AND EFFDT <= GETDATE() GROUP BY EMPLID) C WHERE B.EMPLID = C.EMPLID AND B.EFFDT = C.EFFDT AND B.NAME_TYPE = 'PRI' ) EMPLOYEE_NAME_TODAY ON USR.EMPLID = EMPLOYEE_NAME_TODAY.EMPLID WHERE USR.OPRID=':USER' |
|
PeopleSoft（DB2 RDBMS） |
SELECT CASE WHEN EMPLOYEE_NAME_TODAY.EMPLID IS NULL THEN USR.OPRDEFNDESC ELSE EMPLOYEE_NAME_TODAY.NAME END DISPLAY_NAME, 0 FROM PSOPRDEFN USR LEFT OUTER JOIN (SELECT B.EMPLID, B.NAME FROM PS_NAMES B, (SELECT EMPLID, MAX(EFFDT) EFFDT FROM PS_NAMES WHERE NAME_TYPE = 'PRI' AND EFFDT <= CURRENT TIMESTAMP GROUP BY EMPLID) C WHERE B.EMPLID = C.EMPLID AND B.EFFDT = C.EFFDT AND B.NAME_TYPE = 'PRI' ) EMPLOYEE_NAME_TODAY ON USR.EMPLID = EMPLOYEE_NAME_TODAY.EMPLID WHERE USR.OPRID=':USER' |
この問題は、以前のリリースのSiebel Analytics（7.5.x以上）からOracle Business Intelligence Applicationsリリース7.9.4へアップグレードするときに発生します。アップグレードしたデータ・ウェアハウスへのデータ移行時に、Oracleデータベースの接続にOracleネイティブ・ドライバではなくODBC接続が使用されている場合、アップグレードのワークフローが失敗し、次のエラー・メッセージが表示されます（『Oracle Business Intelligence Applicationsアップグレード・ガイド』の「アップグレードしたデータ・ウェアハウスへのデータの移行」を参照）。
CMN_1836 Error: Data for Lookup [LKP_W_POSITION_DH_WID] fetched from the database is not sorted on the condition ports. Please check your database sort order for the lookup condition ports.
この問題を回避するには、ODBCのかわりにOracleネイティブ・ドライバを使用します。
次の販売予想のファクトに不正な値があるため、レポート作成時にエラーが発生します。
前回の予想概要 : 最良ケース
前回の予想概要 : 最悪ケース
前回の予想概要 : 売上
前回の予想概要 : 予想売上
前回の予想概要 : 費用
前回の予想概要 : マージン
この問題は、前述の各指標への適用が必要なフィルターがないため発生します。
|
注意: この問題は、出荷時のレポートやダッシュボードには影響しません。 |
この問題を解決するには、物理レイヤーにカラム"S_FCST_ITEM_DTL"."AGGR_DIM_NAME_1"を追加してから、論理レイヤーの指標式に対して必要な変更を行います。次の詳細手順を実行することで、この問題の原因となっているディテール行をフィルターで除外できます。
物理レイヤーにカラム"S_FCST_ITEM_DTL"."AGGR_DIM_NAME_1"を追加して必要な変更を行う手順は次のとおりです。
Oracle BI Administration Toolを使用して、リポジトリ（.rpdファイル）を開きます。
リポジトリの「Physical」レイヤーで、テーブルS_FCST_ITEM_DTL（path: Forecasting Siebel OLTP.Catalog.dbo）を探します。
カラムAGGR_DIM_NAME_1（Data type: varchar; Length: 50）をテーブルに追加します。
リポジトリの「Business Model and Mapping」レイヤーで、前述の指標をForecasting.FACTSフォルダ内で探します。
各指標で、次を実行します。
指標を右クリックし、「Properties」を選択します。
「Data Type」の「OLTP Prior Forecast Summary」をハイライトし、「View...」を選択します。
指標式の周りを、次のコードでラップします。
CASE WHEN "Forecasting Siebel OLTP"."Catalog"."dbo"."S_FCST_ITEM_DTL"."AGGR_DIM_NAME_1" IS NULL THEN IFNULL ( ) END
次の表に、各指標の修正された式を示します。
リポジトリを保存します。
表 1-2 更新後の指標式とその値
| 指標 | 修正された式 |
|---|---|
|
前回の予想概要 : 最良ケース |
|
|
前回の予想概要 : 最悪ケース |
|
|
前回の予想概要 : 売上 |
|
|
前回の予想概要 : 予想売上 |
|
|
前回の予想概要 : 費用 |
|
|
前回の予想概要 : マージン |
|
次の言語フォルダは、%:\oraclebidata\disconnected\pharma\messagesから欠落しています。
l_ar: アラビア語
l_el: ギリシャ語
l_hu: ハンガリー語
l_iw: ヘブライ語
l_no: ノルウェー語
l_pl: ポーランド語
l_ro: ルーマニア語
l_ru: ロシア語
l_sk: スロバキア語
l_th: タイ語
l_tr: トルコ語
この問題を回避するには、次の手順を実行します。
%:\oraclebidata\disconnected\pharma\messages\に移動し、次のフォルダを追加します。
l_ar
l_el
l_hu
l_iw
l_no
l_pl
l_ro
l_ru
l_sk
l_th
l_tr
対応する_iBotsCaptions.xmlファイルとPharmaCaptions.xmlファイルを、%:\oraclebidata\web\res\l_XX\Captions\から%:\oraclebidata\disconnected\pharma\messages\l_XX\へコピーします。
「キャンペーン担当者セグメント分析」サブジェクトエリアに、このサブジェクトエリアにないはずの「業種名」次元が含まれています。このカラムを使用して分析すると、メタデータ矛盾エラーが発生します。このカラムを「プレゼンテーション」サブジェクトエリアから削除するか、使用しないでください。
これは、General Ledger Analyticsとともに使用するOracle EBSアダプタ固有の問題です。
ETL時には、ETLプロセスによって各取引の取引通貨からウェアハウスのグローバル通貨への為替レートの解決が試みられます。総勘定元帳から「Statistics」仕訳を抽出する場合、ETLプロセスが、これらの取引の為替レートも解決しようとします。しかし、「Statistics」仕訳の取引通貨が「STAT」であるため、為替レートが解決されません。「STAT」は通貨コードでなく、為替レートは解決できないからです。その結果、為替レートはデフォルトの0に設定されます。Oracle Business Intelligence Applicationsでは、グローバル金額が、取引金額をグローバル為替レートと掛けることで計算されるため、これらの取引のグローバル金額を表示しようとすると、それらはすべて0になってしまいます。ただし、このような統計取引のグローバル金額は通常、元の取引金額として表示します（つまり、これらの取引における取引金額はグローバル金額と等しいはずです）。そのためには、後述の手順を実行して、「STAT」通貨の処理という特別なケースを指定します。取引通貨が「STAT」の場合、返される為替レートは常に1である必要があります。
「STAT」通貨処理の特別なケースを指定する手順は次のとおりです。
Informatica Designerにログインします。
SILOSフォルダを開きます。
再使用可能マップレットMPLT_CURCY_CONVERSION_RATESを探して開きます。
EXPT_CALC_EXCH_RATES式変換を開きます。
「Expression Editor」ダイアログを使用して、次の表に記載された変数の式の値を、古い式の値から新しい式の値へと変更します。
表1-3 EXPT_CALC_EXCH_RATES変数およびその古い式の値と新しい式の値
| 変数名 | 古い式の値 | 新しい式の値 |
|---|---|---|
|
DOC_TO_LOC_EXCH_RATE_VAR |
IIF(ISNULL(DOC_TO_LOC_EXCH_RATE), IIF(LOC_CURR_CODE = DOC_CURR_CODE, 1.0, IIF(ISNULL(LOC_CURR_CODE), NULL, :LKP.LKP_W_EXCH_RATE(DOC_CURR_CODE,LOC_CURR_CODE,EXCH_DT,LOC_RATE_TYPE_VAR,DATASOURCE_NUM_ID))), DOC_TO_LOC_EXCH_RATE) |
IIF(ISNULL(DOC_TO_LOC_EXCH_RATE), IIF(LOC_CURR_CODE = DOC_CURR_CODE, 1.0, IIF(DOC_CURR_CODE = 'STAT', 1.0, IIF(ISNULL(LOC_CURR_CODE), NULL, :LKP.LKP_W_EXCH_RATE(DOC_CURR_CODE,LOC_CURR_CODE,EXCH_DT,LOC_RATE_TYPE_VAR,DATASOURCE_NUM_ID)))), DOC_TO_LOC_EXCH_RATE) |
|
DOC_TO_GLOBAL1_EXCH_RATE_VAR |
IIF(ISNULL(GLOBAL1_CURR_CODE), NULL, IIF(GLOBAL1_CURR_CODE = DOC_CURR_CODE, 1.0, IIF(GLOBAL1_CURR_CODE = LOC_CURR_CODE, DOC_TO_LOC_EXCH_RATE_VAR, :LKP.LKP_W_EXCH_RATE(DOC_CURR_CODE, GLOBAL1_CURR_CODE, EXCH_DT,GLOBAL1_RATE_TYPE, DATASOURCE_NUM_ID)))) |
IIF(ISNULL(GLOBAL1_CURR_CODE), NULL, IIF(GLOBAL1_CURR_CODE = DOC_CURR_CODE, 1.0, IIF(DOC_CURR_CODE = 'STAT', 1.0, IIF(GLOBAL1_CURR_CODE = LOC_CURR_CODE, DOC_TO_LOC_EXCH_RATE_VAR, :LKP.LKP_W_EXCH_RATE(DOC_CURR_CODE, GLOBAL1_CURR_CODE, EXCH_DT,GLOBAL1_RATE_TYPE, DATASOURCE_NUM_ID))))) |
|
DOC_TO_GLOBAL2_EXCH_RATE_VAR |
IIF(ISNULL(GLOBAL2_CURR_CODE), NULL, IIF(GLOBAL2_CURR_CODE = DOC_CURR_CODE, 1.0, IIF(GLOBAL2_CURR_CODE = LOC_CURR_CODE, DOC_TO_LOC_EXCH_RATE_VAR, :LKP.LKP_W_EXCH_RATE(DOC_CURR_CODE, GLOBAL2_CURR_CODE, EXCH_DT,GLOBAL2_RATE_TYPE, DATASOURCE_NUM_ID)))) |
IIF(ISNULL(GLOBAL2_CURR_CODE), NULL, IIF(GLOBAL2_CURR_CODE = DOC_CURR_CODE, 1.0, IIF(DOC_CURR_CODE = 'STAT', 1.0, IIF(GLOBAL2_CURR_CODE = LOC_CURR_CODE, DOC_TO_LOC_EXCH_RATE_VAR, :LKP.LKP_W_EXCH_RATE(DOC_CURR_CODE, GLOBAL2_CURR_CODE, EXCH_DT,GLOBAL1_RATE_TYPE, DATASOURCE_NUM_ID))))) |
|
DOC_TO_GLOBAL3_EXCH_RATE_VAR |
IIF(ISNULL(GLOBAL3_CURR_CODE), NULL, IIF(GLOBAL3_CURR_CODE = DOC_CURR_CODE, 1.0, IIF(GLOBAL3_CURR_CODE = LOC_CURR_CODE, DOC_TO_LOC_EXCH_RATE_VAR, :LKP.LKP_W_EXCH_RATE(DOC_CURR_CODE, GLOBAL3_CURR_CODE, EXCH_DT,GLOBAL1_RATE_TYPE, DATASOURCE_NUM_ID)))) |
IIF(ISNULL(GLOBAL3_CURR_CODE), NULL, IIF(GLOBAL3_CURR_CODE = DOC_CURR_CODE, 1.0, IIF(DOC_CURR_CODE = 'STAT', 1.0, IIF(GLOBAL3_CURR_CODE = LOC_CURR_CODE, DOC_TO_LOC_EXCH_RATE_VAR, :LKP.LKP_W_EXCH_RATE(DOC_CURR_CODE, GLOBAL3_CURR_CODE, EXCH_DT,GLOBAL1_RATE_TYPE, DATASOURCE_NUM_ID))))) |
変更内容を保存します。
