この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章は次のトピックで構成されています。
Cognos メモリ使用率は、Cognos のヒープ サイズを変更して設定します。 Cognos Server のヒープ サイズを変更するには、次の手順を実行します。
IBM Cognos セッションのタイムアウト設定は、シングル サインオンがシームレスに稼働するように、Service Catalog のタイムアウト設定と一致していなければなりません。
タイムアウト間隔を設定するには、次の手順を実行します。
標準レポート パッケージをサポートするレポート データベース内の全テーブルは、毎回の ETL サイクルで切り捨てられ、すべて更新されます。 レポートの内容は、ETL サイクルの完了後すぐに更新され、表示可能になります。 ETL の処理中、事前作成されたレポートを実行することはできません。
データ マートのビジネス ビューを提供するカスタム レポート パッケージのデータベース コンテンツを更新するには、複数の Cognos および Service Catalog コンポーネントが必要です。データ マートは、Extract-Transform-Load(ETL)プロセスによってトランザクション システムから定期的にロードする必要があります。 つまり、データはトランザクション システムから抽出され、(オンライン トランザクション用ではなく)レポート用に最適な形式に変換されてから、データ マートにロードされます。
ETL プロセスは増分のプロセスです。 最後にデータ マートが更新された後で変更または作成されたデータだけが、次の ETL サイクルで処理されます。 更新プロセスの実行中でも、ユーザは引き続きデータ マートにアクセスしたり、レポートを実行したりできます。 ただし、レポートによっては応答時間に悪影響が及ぶ場合があります。 ETL プロセスの実行によって、トランザクション データベースの応答時間に及ぶ影響はまったくないか、非常に限られています。
通常、更新プロセスは定期的な間隔で自動的に実行されるようにスケジュールされます。 データ マートが 24 時間ごとに、理想的にはユーザ アクティビティが少ない期間に更新されるようにすることを推奨します。
全パッケージに対する Service Catalog ETL プロセスでは、Cognos データ マネージャ ランタイム コンポーネントを使用して、アプリケーションのインストール手順の一環としてレポーティング サーバに展開される実行ファイルを生成します。 これらのスクリプトは、Cognos SQL を使用して OLTP ソースからデータを読み取るため、異なるデータベース環境間でのさらに優れたカタログのポータビリティが実現します。 Oracle や SQL Server 専用のコードは、OLTP ソースで作成されるビューに抽象化されます。 Data Manager スクリプトには、Service Catalog データベース(ソフトウェアの国際化に対応)内に格納された特殊形式文字列の変換に対処する User Defined Function(UDF)も含まれています。 UDF はまた、HTML タグがディクショナリのキャプションやフィールド ラベルに含まれている場合、それらのタグをデータから除去します。
Service Catalog の申請レコード(OLTP パフォーマンス最適化のために圧縮された独自形式で格納されています)からサービス フォームのフィールド レベルのデータを標準のリレーショナル形式で抽出するには、カスタム プログラムが必要になります。 このカスタム プログラムは Service Catalog アプリケーション サーバで動作します。
カスタム レポート データ プロジェクトの作成と保守には、別のカスタム プログラムが必要です。 このスクリプトは、Cognos Framework Manager SDK を使用して、各カスタマー サイトでレポート可能として選択されたサービスとディクショナリに基づき、動的にカスタム レポート プロジェクトを作成します。 この動的構造とコンテンツが標準データ マート ファクトとディメンションに追加されて、カスタム レポート プロジェクトで使用可能なデータ マートが生成されます。
生成された実行可能ファイルは、バッチで実行できるようにジョブ ストリームに順に並べられます。 ジョブ ストリームの正確な構造は、インストールされて設定済みの Reporting コンポーネント(事前作成済みレポートと KPI、およひカスタム レポート データ マート)によって異なります。
Reporting のインストールは、1 日 1 回のデータ マート更新時に開始することを推奨します。通常、データ マートの更新は、トランザクション処理が盛んではない時間にスケジュールされているためです。 ただし、データ マートの更新は、Service Catalog のオンライン使用時と同時にスケジュールされる場合や、1 日に複数回スケジュールされる場合もあります。 データベース サーバの負荷に影響する場合、オンライン トランザクション ユーザのパフォーマンスも影響を受けます。 インデックスの再作成に伴って一部の Reporting ユーザがパフォーマンスの一時的な低下を報告する可能性がありますが、通常影響は一時的なものです。
Advanced Reporting で使用可能なデータ マートをサポートするすべてのテーブルは、各 ETL サイクルで増分式に更新されます。 そのため、基本的に、ETL サイクルの間もデータ マートはオンラインのままです。 ただし、データベースのアクティビティが増加し、テーブルのインデックスが一時的に使用できなくなることから、パフォーマンスに悪影響が生じる場合があります。
カスタム レポート パッケージの作成に使用されるプロセス フローでは、前述のコンポーネントを使用します。 根本的な違いとして、追加の Cognos コンポーネントおよびシスコ製のカスタム コードを使用して、データ マートで動的に定義されたフォーム データ(レポート可能サービスおよびディクショナリ形式)の包含を扱うことです。
データは、Cognos(Data Manager)ETL スクリプトとカスタム Java プログラムの 2 つの方法でカスタム レポート パッケージにロードされます(次の図を参照)。
カスタム Java プログラムは、フォーム データをレポート可能ディクショナリおよびサービスからデータ マート内の対応するディメンションへロードするほかに、ロードされたディクショナリとサービスの追跡も行います。 このプログラムの最初の実行では、トランザクション データベース内のデータすべてを、データ マートをサポートする分析的データベースにロードします。 後続のサイクルでは、データの増分をロードします。つまり、トランザクション データベース内の新しいデータや変更されたデータだけが、データ マート内で挿入または更新されます。
このプログラムは、実際のデータのロードに加え、新しいレポート可能ディクショナリおよびサービスをチェックし、オブジェクトのリストを更新します。 前掲の図で「...マッピングするためのメタデータ」と書かれているこの情報は、その後別のカスタム プログラムで使用されます。 このプログラムは、Framework Manager API を使用して Report Designer と Ad-Hoc Reports でユーザが使用可能なデータのビジネス ビューを作成します。これにより、レポート可能ディクショナリに割り当てられた名前とその属性がレポーティング ツール内で正確に表示されるようになります。
DataManager ETL は、静的に定義された(ディメンションまたはファクト)データを OLTP データベースから、データ マート内の対応するディメンションとファクトへロードします。 このロード プロセスは増分式で行われます。 最初にこのプロセスが実行される際には、トランザクション データベースから使用可能なデータすべてがロードされます。 以降の実行では、前回の ETL 実行以降に挿入または変更されたデータだけがロードされます。
OLTP データベースのソース テーブルにはすべて、タイム スタンプ列があります([CreatedOn]/[ModifiedOn])。 これらの列は、新しいレコードの挿入時または既存のレコードの変更時に更新されます。 ETL プロセスでは、ソース テーブルのタイム スタンプ列を、ETL プロセスの最終実行日時と比較することにより、新規データと更新データをキャプチャします。
ETL プロセスは、データマート内で新しい行の挿入および既存の行の更新の両方を処理するよう最適化されています。 たとえば、サービス要求が送信されると、要求とその要求のタスクのすべてがデータ マート内に作成されます。 その後、タスクが更新されると、既存のタスク ファクトが更新されて、新しい情報が反映されます。
ETL プロセスは次のように動作します。
抽出ビューに基づいて、OLTP データベースから新規データまたは更新データを選択します。抽出ビューには、データマートに必要な列が含まれ、ソース データのタイム スタンプと ETL プロセスの最終実行日時を比較することによってフィルタリングされます。
OLAP データベースのステージング テーブル(プレフィックス STG で判別)が、OLTP データベースからの新規データや更新データを一時的に保持します。 ステージング テーブルは、OLTP テーブルと 1 対 1 で対応します。 これらのテーブルは、ETL の実行ごとに切り捨てられるため、新規データと更新データだけを含むことになります。
OLAP データベース内の作業領域テーブル(プレフィックス WRK で判別)は、抽出されたデータを保持し、それ以前の ETL の実行によって抽出されたデータを統合します。 作業領域テーブルは、トランザクション データベース内の複数のテーブルから取得されたデータを持つディメンションのためにデータを変換する場合にだけ使用されます。 ソース テーブルからターゲット テーブルへのマッピングについては、「Form Data Reporting 設定の変更」に記載されています。
ETL では、ステージング テーブルと作業テーブルの両方を使用して、新規データや更新データをデータマート内の適切なディメンション テーブルやファクト テーブルに挿入します。 ビジネス ビューはこれらのテーブルに基づいて作成され、パッケージ内のクエリー サブジェクトとして公開されます。
Cognos 8.4.0/ 8.4.1 から Cognos バージョン 10.2.1 に Prime Service Catalog レポート ソリューションをアップグレードすると、システムにより、[マイフォルダ(My Folders)] と [パブリックフォルダ(Public Folder)] 内にある既存のレポート仕様とカスタマイズされたレポートのすべてが自動的に移行されます。
さらに、管理権限を使用して手動でアップグレードする場合、レポート ソリューション ウィザードですべてのレポートを移行することもできます。
いずれの場合も、アップグレードする際には既存のすべてのレポートのバックアップを作成しておくことを推奨します。
アップグレードの実行について詳しくは、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。
Service Catalog には、データ マートへのデータの入力に使用する Framework Manager および Data Manager ツールのランタイム ライセンスだけが付属しています。 Cognos のエンタープライズ開発ライセンスを持つ Service Catalog ユーザが、追加のクライアント専用データなどの、データ マートの内容のカスタマイズを希望する場合があります。
カスタマイズを成功させる鍵は、Framework Manager を介して設定されたデータのビジネス ビューに、静的および動的コンポーネントの両方が含まれるという点を考慮することにあります。 普遍的なファクトとディメンションを指定する静的コンポーネントは、次のファイルに保存されます。
<App_Home>\cognos\Reports\CustomReportsDataModel\ CustomReportsDataModel.cpf
(レポート サーバー上にあります)。 ETL はこのファイルをビジネス ビューの基礎として使用してから、追加の DictionaryData および ServiceData ディメンションを生成します(どちらのオブジェクトがレポート可能としてマークされているかによります)。 静的コンポーネントに対するクライアントのカスタマイズは、IBM Cognos Framework Manager を使用して適用されます。 このようなカスタマイズは、次の ETL サイクルによって生成される新規ビジネス ビューに組み込まれます。 このようなカスタマイズは、アプリケーションをアップグレードした後に、再適用する必要があります。
目次
この章は次のトピックで構成されています。
IBM Cognos セッションのタイムアウト設定は、シングル サインオンがシームレスに稼働するように、Service Catalog のタイムアウト設定と一致していなければなりません。
タイムアウト間隔を設定するには、次の手順を実行します。
標準レポート パッケージをサポートするレポート データベース内の全テーブルは、毎回の ETL サイクルで切り捨てられ、すべて更新されます。 レポートの内容は、ETL サイクルの完了後すぐに更新され、表示可能になります。 ETL の処理中、事前作成されたレポートを実行することはできません。
データ マートのビジネス ビューを提供するカスタム レポート パッケージのデータベース コンテンツを更新するには、複数の Cognos および Service Catalog コンポーネントが必要です。データ マートは、Extract-Transform-Load(ETL)プロセスによってトランザクション システムから定期的にロードする必要があります。 つまり、データはトランザクション システムから抽出され、(オンライン トランザクション用ではなく)レポート用に最適な形式に変換されてから、データ マートにロードされます。
ETL プロセスは増分のプロセスです。 最後にデータ マートが更新された後で変更または作成されたデータだけが、次の ETL サイクルで処理されます。 更新プロセスの実行中でも、ユーザは引き続きデータ マートにアクセスしたり、レポートを実行したりできます。 ただし、レポートによっては応答時間に悪影響が及ぶ場合があります。 ETL プロセスの実行によって、トランザクション データベースの応答時間に及ぶ影響はまったくないか、非常に限られています。
通常、更新プロセスは定期的な間隔で自動的に実行されるようにスケジュールされます。 データ マートが 24 時間ごとに、理想的にはユーザ アクティビティが少ない期間に更新されるようにすることを推奨します。
全パッケージに対する Service Catalog ETL プロセスでは、Cognos データ マネージャ ランタイム コンポーネントを使用して、アプリケーションのインストール手順の一環としてレポーティング サーバに展開される実行ファイルを生成します。 これらのスクリプトは、Cognos SQL を使用して OLTP ソースからデータを読み取るため、異なるデータベース環境間でのさらに優れたカタログのポータビリティが実現します。 Oracle や SQL Server 専用のコードは、OLTP ソースで作成されるビューに抽象化されます。 Data Manager スクリプトには、Service Catalog データベース(ソフトウェアの国際化に対応)内に格納された特殊形式文字列の変換に対処する User Defined Function(UDF)も含まれています。 UDF はまた、HTML タグがディクショナリのキャプションやフィールド ラベルに含まれている場合、それらのタグをデータから除去します。
Service Catalog の申請レコード(OLTP パフォーマンス最適化のために圧縮された独自形式で格納されています)からサービス フォームのフィールド レベルのデータを標準のリレーショナル形式で抽出するには、カスタム プログラムが必要になります。 このカスタム プログラムは Service Catalog アプリケーション サーバで動作します。
カスタム レポート データ プロジェクトの作成と保守には、別のカスタム プログラムが必要です。 このスクリプトは、Cognos Framework Manager SDK を使用して、各カスタマー サイトでレポート可能として選択されたサービスとディクショナリに基づき、動的にカスタム レポート プロジェクトを作成します。 この動的構造とコンテンツが標準データ マート ファクトとディメンションに追加されて、カスタム レポート プロジェクトで使用可能なデータ マートが生成されます。
生成された実行可能ファイルは、バッチで実行できるようにジョブ ストリームに順に並べられます。 ジョブ ストリームの正確な構造は、インストールされて設定済みの Reporting コンポーネント(事前作成済みレポートと KPI、およひカスタム レポート データ マート)によって異なります。
Reporting のインストールは、1 日 1 回のデータ マート更新時に開始することを推奨します。通常、データ マートの更新は、トランザクション処理が盛んではない時間にスケジュールされているためです。 ただし、データ マートの更新は、Service Catalog のオンライン使用時と同時にスケジュールされる場合や、1 日に複数回スケジュールされる場合もあります。 データベース サーバの負荷に影響する場合、オンライン トランザクション ユーザのパフォーマンスも影響を受けます。 インデックスの再作成に伴って一部の Reporting ユーザがパフォーマンスの一時的な低下を報告する可能性がありますが、通常影響は一時的なものです。
カスタム レポート パッケージの作成に使用されるプロセス フローでは、前述のコンポーネントを使用します。 根本的な違いとして、追加の Cognos コンポーネントおよびシスコ製のカスタム コードを使用して、データ マートで動的に定義されたフォーム データ(レポート可能サービスおよびディクショナリ形式)の包含を扱うことです。
データは、Cognos(Data Manager)ETL スクリプトとカスタム Java プログラムの 2 つの方法でカスタム レポート パッケージにロードされます(次の図を参照)。
カスタム Java プログラムは、フォーム データをレポート可能ディクショナリおよびサービスからデータ マート内の対応するディメンションへロードするほかに、ロードされたディクショナリとサービスの追跡も行います。 このプログラムの最初の実行では、トランザクション データベース内のデータすべてを、データ マートをサポートする分析的データベースにロードします。 後続のサイクルでは、データの増分をロードします。つまり、トランザクション データベース内の新しいデータや変更されたデータだけが、データ マート内で挿入または更新されます。
このプログラムは、実際のデータのロードに加え、新しいレポート可能ディクショナリおよびサービスをチェックし、オブジェクトのリストを更新します。 前掲の図で「...マッピングするためのメタデータ」と書かれているこの情報は、その後別のカスタム プログラムで使用されます。 このプログラムは、Framework Manager API を使用して Report Designer と Ad-Hoc Reports でユーザが使用可能なデータのビジネス ビューを作成します。これにより、レポート可能ディクショナリに割り当てられた名前とその属性がレポーティング ツール内で正確に表示されるようになります。
DataManager ETL は、静的に定義された(ディメンションまたはファクト)データを OLTP データベースから、データ マート内の対応するディメンションとファクトへロードします。 このロード プロセスは増分式で行われます。 最初にこのプロセスが実行される際には、トランザクション データベースから使用可能なデータすべてがロードされます。 以降の実行では、前回の ETL 実行以降に挿入または変更されたデータだけがロードされます。
OLTP データベースのソース テーブルにはすべて、タイム スタンプ列があります([CreatedOn]/[ModifiedOn])。 これらの列は、新しいレコードの挿入時または既存のレコードの変更時に更新されます。 ETL プロセスでは、ソース テーブルのタイム スタンプ列を、ETL プロセスの最終実行日時と比較することにより、新規データと更新データをキャプチャします。
ETL プロセスは、データマート内で新しい行の挿入および既存の行の更新の両方を処理するよう最適化されています。 たとえば、サービス要求が送信されると、要求とその要求のタスクのすべてがデータ マート内に作成されます。 その後、タスクが更新されると、既存のタスク ファクトが更新されて、新しい情報が反映されます。
ETL プロセスは次のように動作します。
抽出ビューに基づいて、OLTP データベースから新規データまたは更新データを選択します。抽出ビューには、データマートに必要な列が含まれ、ソース データのタイム スタンプと ETL プロセスの最終実行日時を比較することによってフィルタリングされます。
OLAP データベースのステージング テーブル(プレフィックス STG で判別)が、OLTP データベースからの新規データや更新データを一時的に保持します。 ステージング テーブルは、OLTP テーブルと 1 対 1 で対応します。 これらのテーブルは、ETL の実行ごとに切り捨てられるため、新規データと更新データだけを含むことになります。
OLAP データベース内の作業領域テーブル(プレフィックス WRK で判別)は、抽出されたデータを保持し、それ以前の ETL の実行によって抽出されたデータを統合します。 作業領域テーブルは、トランザクション データベース内の複数のテーブルから取得されたデータを持つディメンションのためにデータを変換する場合にだけ使用されます。 ソース テーブルからターゲット テーブルへのマッピングについては、「Form Data Reporting 設定の変更」に記載されています。
Cognos 8.4.0/ 8.4.1 から Cognos バージョン 10.2.1 に Prime Service Catalog レポート ソリューションをアップグレードすると、システムにより、[マイフォルダ(My Folders)] と [パブリックフォルダ(Public Folder)] 内にある既存のレポート仕様とカスタマイズされたレポートのすべてが自動的に移行されます。
さらに、管理権限を使用して手動でアップグレードする場合、レポート ソリューション ウィザードですべてのレポートを移行することもできます。
いずれの場合も、アップグレードする際には既存のすべてのレポートのバックアップを作成しておくことを推奨します。
アップグレードの実行について詳しくは、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。
Service Catalog には、データ マートへのデータの入力に使用する Framework Manager および Data Manager ツールのランタイム ライセンスだけが付属しています。 Cognos のエンタープライズ開発ライセンスを持つ Service Catalog ユーザが、追加のクライアント専用データなどの、データ マートの内容のカスタマイズを希望する場合があります。
カスタマイズを成功させる鍵は、Framework Manager を介して設定されたデータのビジネス ビューに、静的および動的コンポーネントの両方が含まれるという点を考慮することにあります。 普遍的なファクトとディメンションを指定する静的コンポーネントは、次のファイルに保存されます。
<App_Home>\cognos\Reports\CustomReportsDataModel\ CustomReportsDataModel.cpf
(レポート サーバー上にあります)。 ETL はこのファイルをビジネス ビューの基礎として使用してから、追加の DictionaryData および ServiceData ディメンションを生成します(どちらのオブジェクトがレポート可能としてマークされているかによります)。 静的コンポーネントに対するクライアントのカスタマイズは、IBM Cognos Framework Manager を使用して適用されます。 このようなカスタマイズは、次の ETL サイクルによって生成される新規ビジネス ビューに組み込まれます。 このようなカスタマイズは、アプリケーションをアップグレードした後に、再適用する必要があります。