Cisco Prime Service Catalog 11.0 レポート ガイド
Cisco Prime Service Catalog レポートのモニタリングおよび運用
Cisco Prime Service Catalog レポートのモニタリングおよび運用

Cisco Prime Service Catalog レポートのモニタリングおよび運用

この章は次のトピックで構成されています。

Cognos メモリ使用率の設定

Cognos メモリ使用率は、Cognos のヒープ サイズを変更して設定します。 Cognos Server のヒープ サイズを変更するには、次の手順を実行します。


    ステップ 1   IBM Cognos サービスを停止します。
    ステップ 2   C:\Program Files\cognos\c10_64\bin64 ディレクトリに置かれている startup.bat を開きます。
    ステップ 3   startup.bat ファイルで、使用する Cognos マシンの RAM サイズに応じて、Cognos により推奨されている別のヒープ サイズ設定を参照できます。

    rem 1GB RAM のマシンの場合

    set CATALINA_OPTS=-Xmx768m -XX:MaxNewSize=384m -XX:NewSize=192m -XX:MaxPermSize=128m %DEBUG_OPTS%

    rem 2GB RAM のマシンの場合

    rem set CATALINA_OPTS=-Xmx1152m -XX:MaxNewSize=576m -XX:NewSize=288m -XX:MaxPermSize=128m %DEBUG_OPTS%

    rem 3GB RAM のマシンの場合

    rem set CATALINA_OPTS=-Xmx1536m -XX:MaxNewSize=768m -XX:NewSize=384m -XX:MaxPermSize=128m %DEBUG_OPTS%

    システム RAM サイズに基づいて、上記のヒープ サイズ設定のいずれかを使用するか、ヒープ サイズ設定を変更して、rem を行の先頭に使用して、残りのヒープ サイズ設定をコメント化します。

    ステップ 4   IBM Cognos サービスを再起動します。

    IBM Cognos Server のタイムアウト間隔の設定

    IBM Cognos セッションのタイムアウト設定は、シングル サインオンがシームレスに稼働するように、Service Catalog のタイムアウト設定と一致していなければなりません。

    タイムアウト間隔を設定するには、次の手順を実行します。


      ステップ 1   [スタート(Start)] > [すべてのプログラム(All Programs)] > [IBM Cognos 10-64] > [IBM Cognos Configuration] を選択します。
      ステップ 2   [環境(Environment)] > [IBM Cognosサービス(IBM Cognos service)] を選択します。
      ステップ 3   [IBM Cognos] をクリックします。
      ステップ 4   [リソースのプロパティ(Resource Properties)] で、[Pingタイムアウト(秒数)(Ping timeout in seconds)] を選択します。 タイムアウト間隔(秒数)として 960 と入力します。 960 は、設定可能な最大値です。
      ステップ 5   設定を保存します([保存(Save)] アイコンをクリックします)。
      ステップ 6   IBM Cognos サービスを再起動します。

      標準レポート パッケージの更新

      標準レポート パッケージをサポートするレポート データベース内の全テーブルは、毎回の 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 つの方法でカスタム レポート パッケージにロードされます(次の図を参照)。

      図 1. カスタム レポート パッケージのプロセス フロー:パート 1

      フォーム データ カスタム ETL

      カスタム Java プログラムは、フォーム データをレポート可能ディクショナリおよびサービスからデータ マート内の対応するディメンションへロードするほかに、ロードされたディクショナリとサービスの追跡も行います。 このプログラムの最初の実行では、トランザクション データベース内のデータすべてを、データ マートをサポートする分析的データベースにロードします。 後続のサイクルでは、データの増分をロードします。つまり、トランザクション データベース内の新しいデータや変更されたデータだけが、データ マート内で挿入または更新されます。

      このプログラムは、実際のデータのロードに加え、新しいレポート可能ディクショナリおよびサービスをチェックし、オブジェクトのリストを更新します。 前掲の図で「...マッピングするためのメタデータ」と書かれているこの情報は、その後別のカスタム プログラムで使用されます。 このプログラムは、Framework Manager API を使用して Report Designer と Ad-Hoc Reports でユーザが使用可能なデータのビジネス ビューを作成します。これにより、レポート可能ディクショナリに割り当てられた名前とその属性がレポーティング ツール内で正確に表示されるようになります。

      Data Manager ETL

      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』を参照してください。

      Cognos Framework Manager データ モデルのカスタマイズ

      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 サイクルによって生成される新規ビジネス ビューに組み込まれます。 このようなカスタマイズは、アプリケーションをアップグレードした後に、再適用する必要があります。