この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章は次のトピックで構成されています。
次の表に示されるロールは、Organization Designer モジュールで定義されます。これらは、Reporting および Advanced Reporting モジュールにアクセスするユーザに割り当てる必要があります。
ユーザを定義済みロール「Service Operations Report User」に割り当てると、そのユーザには事前に作成されたレポートの実行が可能になります。 管理者は、個々のロールに基づいて、Reporting フィーチャにアクセスするためのレポート機能を有効にする必要があります。
RBAC を有効にするには、次の手順を実行します。
ここでは、レポートを実稼働環境まで移行する方法について説明します。
通常、Service Catalog 実装は複数のサイトで構成され、それぞれのサイトが異なる役割を果たします。
サイト |
使用方法 |
---|---|
開発 |
サービス定義が開発され、単体テストが行われます。カスタマイゼーションが最初に適用されます。 |
テスト |
開発アクティビティから干渉されることのない、制御された環境。ここでは、品質保証または他の担当者が Service Catalog をテストします。 |
Production |
ユーザ コミュニティが Service Catalog からサービスを要求でき、IT チームがサービス要求を満たすことができる実稼働環境。 |
上記のガイドラインに従うと、Service Catalog ソフトウェアに適用済みのカスタマイゼーションを失うことなく、このソフトウェアをアップグレードできます。 ただし、これらのガイドラインには、クライアントから提供されたコンテンツ(サービス定義や個人プロファイルなど)をサイト間で移行する必要性についての説明がありません。 この機能は Catalog Deployer で提供されています。
Catalog Deployer モジュールは、メタデータ(サービス定義)およびリポジトリに保存されている組織データ(個人、組織、および関連するエンティティ)の設定管理を行います。 Catalog Deployer のマニュアルについては、『Cisco Prime Service Catalog Designer Guide』を参照してください。
ここで説明する導入オプションを使用してレポートを移動するには、Reporting モジュールの管理権限が必要です。 事前定義されているサイト管理者ロールには、この権限が含まれます。
ソースとターゲットの両方の環境の Cognos Server のファイル システムにアクセスできる必要があります。
展開中の特定のタイミングで、Service Catalog OLTP データベースをサイト間でコピーすることが望ましい場合があります。 次に例を示します。
Service Catalog OLTP データベースをサイト間でコピーするには、次の手順を実行します。
ソース データベースをエクスポートには、次の手順を実行します。
ステップ 1 | 予測されるダウンタイムをユーザに通知します。 |
ステップ 2 | ソース環境の Prime Service Catalog および Service Link サービスを停止します。 |
ステップ 3 | ソース データベースをエクスポートします。 データのソースおよびエクスポートの日付を追跡するために使用する命名規則を決定します。 |
ステップ 4 | システムのシャットダウンを実行できない場合は、Oracle エクスポートの -consistent フラグを使用します。 |
ステップ 5 | Prime Service Catalog および Service Link サービスを再起動します。 |
データをターゲット データベースにインポートするには、次の手順に従います。
ステップ 1 | ターゲット環境で、Prime Service Catalog および Service Link のサービスを停止します。 |
ステップ 2 | ターゲット データベースの最新のバックアップ コピーがあることを確認します。 |
ステップ 3 | 必要に応じて、宛先からのエクスポート ファイルを、ターゲット データベース サーバにアクセスできるファイル システムにコピーします。 |
ステップ 4 | ターゲット データベースにデータをインポートします。 |
ステップ 5 | SQLServer の場合は、新たにインポートされるデータベースに存在するログインおよびユーザが、Service Catalog のこのインスタンスに必要な資格情報と一致することを確認します。 必要に応じて新しいログインを作成したり、既存のログインをデータベース オーナーに関連付けたりして、このユーザが適切な権限を持つようにします。 Oracle の場合は、新しくインポートされるデータベースに適切なユーザが存在し、Service Catalog インストーラで指定されたように特権が付与されていることを確認します。 |
ステップ 6 | 両サイトが 2 つの異なる Cognos レポート サーバにアクセスしている場合は、各サイトの「CognosServer」の名前を指定する CnfParams テーブルのエントリを更新して、更新内容をコミットします。 |
ステップ 7 | ターゲット環境で、Prime Service Catalog および Service Link のサービスを再起動します。 |
ステップ 8 | [管理(Administration)] > [エンティティホーム(Entity Homes)] > [SiteProtection] の [このサイト(This Site Is)] プロパティを現在のサイトに設定します。 [エンティティホーム(Entity Homes)] の指定が異なる場合、またはサイトの保護レベルが異なる場合は、手動で変更を行い、変更を保存します。 |
ステップ 9 | 両サイトが 2 つの異なる LDAP ディレクトリに接続している場合は、ディレクトリ統合のデータ ソース定義を適宜変更します。 |
ステップ 10 | Service Link エージェントの接続プロパティをすべてチェックし、ターゲット環境に合わせて変更します。 |
ステップ 11 | 手作業での追加処理がある場合はそれを実行し、データを調整します。 たとえば、一部のユーザ、グループ、または組織に権限を追加したり、権限を取り消したりする場合があります。 |
ステップ 12 | メンテナンスが完了したことをユーザに通知します。 |
エクスポート ファイルを作成するには、次の手順を実行します。
ステップ 1 | 開発マシンで、CustomReports という名前のフォルダを Cognos の Public Folders ディレクトリに作成します。 フォルダの名前を変更しても構いませんが、パブリック フォルダにする必要があります。 |
ステップ 2 | 新しいレポートを上記で作成した CustomReports フォルダにコピーします。 |
ステップ 3 | レポート管理者の機能を持つユーザとして Service Catalog にログインします。 |
ステップ 4 | 右上隅の [起動(Launch)] に移動し、[IBM Cognos管理(IBM Cognos Administration)] をクリックします。 |
ステップ 5 | [設定(Configuration)] タブをクリックします。 |
ステップ 6 |
[コンテンツ管理(Content Administration)] に移動し、画面の右上隅にある [新規エクスポート(New Export] アイコンをクリックします。
|
ステップ 7 | エクスポートの名前(たとえば、CustomReports)およびその他の詳細を指定し、[次へ(Next)] をクリックします。 |
ステップ 8 | [導入方法(Deployment Method)] ページで、[パブリックフォルダおよびディレクトリ コンテンツの選択(Select public folders and directory content)] を選択して、[次へ(Next)] をクリックします。 |
ステップ 9 |
[追加(Add)] をクリックして、手順 1 で作成した CustomReports フォルダを選択します。 次に、カスタム レポート フォルダを選択し、下部にある [追加(Add)] を選択してから [OK] をクリックします。
|
ステップ 10 |
[インポート後に無効化(Disable after import)] の選択を解除して、[次へ(Next)] をクリックします。 |
ステップ 11 | [次へ(Next)] をクリックします。 |
ステップ 12 | [ディレクトリコンテンツの選択(Select the directory content)] セクションで、[Cognosグループおよびロールを含める(Include Cognos groups and roles)] を選択し、[既存のエントリを置換(Replace existing entries)] を選択して、[次へ(Next)] をクリックします。 |
ステップ 13 | [一般オプションの選択(Specify the general options)] セクションで、 [アクセス権限を含める(Include access permissions)] を選択して、[新規および既存のエントリに適用(Apply to new and existing existing entries)] を選択します。 |
ステップ 14 | [外部ネームスペース(External namespaces)] で、[外部ネームスペースへの参照を含める(Include references to external namespaces)] を選択します。 |
ステップ 15 | [エントリ所有者(Entry ownership)] セクションで、[インポートを実行するユーザ(The user performing the import)] を選択して、[一般オプションの選択(Specify the general options)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 16 | [導入アーカイブの指定(Specify a deployment archive)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 17 | [要約の確認(Review the summary)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 18 | [アクションの選択(Select an action)] セクションで、[完了(Finish)] をクリックします。 |
ステップ 19 | [今すぐ(Now)] を選択し、[オプションを使用して実行(Run with options)] セクションで [実行(Run)] をクリックします。 このプロセスにより、CustomReports.zip が Cognos Source マシンの <CognosHome>\c10_64\deployment フォルダに作成されます。 |
ファイルをインポートするには、次の手順を実行します。
ステップ 1 | エクスポートされたファイル CustomReports.zip を実稼働マシンの <CognosHome>\c10_64\deployment フォルダにコピーします。 |
ステップ 2 | 画面右上隅の [起動(Launch)] に移動し、[IBM Cognos管理(IBM Cognos Administration)] をクリックします。 |
ステップ 3 | [設定(Configuration)] タブをクリックします。 |
ステップ 4 |
[コンテンツ管理(Content Administration)] に移動し、画面右上隅の [新規インポート(New Import)] アイコンを選択します。
|
ステップ 5 | [CustomReports] を選択し、[次へ(Next)] をクリックします。 |
ステップ 6 | [CustomReports] を選択し、[パブリックフォルダのコンテンツの選択(Select the public folders content)] セクションで [次へ(Next)] をクリックします。 |
ステップ 7 | [ディレクトリのコンテンツの選択(Select the directory content)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 8 | [一般オプションの指定(Specify the general options)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 9 | [要約の確認(Review the summary)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 10 | [アクションの選択(Select an action)] セクションで、[完了(Finish)] をクリックします。 |
ステップ 11 | 新しいレポート フォルダ CustomReports が、実稼働マシンのパブリック フォルダ エリアに表示されます。 |
Service Catalog データ マートは、通常、サービス設計者がカスタマイズせずにインストールできます。 ただし、この「最小の共通特性」によるアプローチでは、ほとんどのサイトのレポート作成要件を満たすことができません。 このため、推奨される手順は、上記のベスト プラクティスを、サイトのディクショナリおよびサービス設定と組み合わせて確認することです。 次のセクションをワークシートとして使用することで、アナリストはサイトに対して必要なデータ マート設定を決定できます。 これらの設定パラメータは、Advanced Reporting を設定するために使用できます。
これらのパラメータは、データ マートをインストールする際に指定する必要がある多くのプロパティに対応しています。 データ マートの設定とそのインストールのカスタマイズに使用されるインストールおよび設定パラメータの詳細については、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。
データ マートを作成するときに、データ マートが保持するディクショナリおよびサービス ディメンションの最大数を指定します。 これらの各ディメンションはデータ マートの個別のテーブルに対応します。 ディクショナリまたはサービスの数は、データ マートをインストールした後に増やすことができます。 ただし、この手順を避けるために、直近の導入に対して計画されている現在の要件および機能向上に対応できる十分なテーブルでデータ マートを作成してください。
作成する必要がある各タイプのテーブル数を決定するための「特効薬」はありません。 一部のガイドラインは前のセクションで説明されています。 サービス設計者はすべてのディクショナリを確認し、データ マートに含めるディクショナリを決定して、それらを [Service Designer] > [ディクショナリ(Dictionaries)] コンポーネントの [レポート可能(Reportable)] ドロップダウン メニューで [はい(Yes)] を選択することで、レポート可能なディクショナリとして指定する必要があります。
Service Catalog は、レポート可能として指定され、データ マートに作成されたサービスおよびディクショナリ テーブルの数が指定された数を超過しないように追跡します。 後からディクショナリ(またはサービス)をレポート可能にしないと決定した場合は、対応する [レポート可能(Reportable)] フィールドを [いいえ(No)] に変更します。 これにより、データ マートをロードする ETL ジョブからソース ディクショナリまたはサービスが削除されます。 レポート作成フレームワークでは、クエリー サブジェクトを引き続き利用できます。ただし、ディクショナリまたはサービス データを保持するテーブルを別のディクショナリまたはサービスとともに使用することはできず、使用中のテーブル数の 1 つとしてカウントされます。
パラメータ |
デフォルト値 |
サイトでの値 |
---|---|---|
NUMBER_OF_SERVICE_TABLES |
100 |
|
NUMBER_OF_DICTIONARY_TABLES |
100 |
|
データ マート内のすべてのデータは文字列(テキスト)、数値、または日付(時間コンポーネントを含む)として格納されます。 内部ディクショナリからのデータは、次の表で示すように、適切な型に変換されます。
データ マート列のデータ タイプ |
内部ディクショナリのデータ タイプ |
データベース固有の実装 |
---|---|---|
数値(Number (Numeric)) |
番号(Number) 資金(Money) |
Oracle:NUMBER SQL Server:FLOAT |
日付(Date) |
日付(Date) 日付および時刻(Date and Time) |
Oracle:DATE SQL Server:DATETIME |
文字列(Varchar:可変長文字列) |
テキスト(Text) Person URL アカウント(Account) 電話 SSN(社会保障番号) ブール値 |
Oracle:VARCHAR2 SQL Server:VARCHAR |
Person データ タイプは、サービス フォーム上の [個人の選択(Select a Person)] ウィンドウで示されるように、個人の名と姓の組み合わせとしてデータ マート内に表されます。 Boolean データ タイプは、データ タイプのオプション ボタン表現で示されるように、「yes」および「no」に対応する文字列で表されます。
外部ディクショナリからのデータは適切なタイプに変換されます。 たとえば、すべての数値フィールドはその大きさや精度に関係なく、上記の表に示すターゲット データベースの数値型に変換されます。 外部ディクショナリ テーブルのグラフィックおよびラージ オブジェクト(LOB)データ タイプはサポートされていないため、データ マートの作成時や ETL プロセスによるデータのロード時には無視されます。
データ マート設定の一環として、設計者はディクショナリおよびサービス テーブルに作成されるデータ型(文字、数値、日付)ごとの列数を指定します。 すべてのディクショナリ テーブルは、データ型ごとの許容列数に関して、同一の構成である必要があります。 これは、サービス テーブルについても同様です。
(注) |
SQLServer では、テーブルの行の長さを 8k(8192)バイトよりも大きくしないよう警告しています。 これにより、サービス ディメンション テーブルのサイズには大幅な制限が課されることになります。 このような制限は Oracle には存在しないため、データ タイプごとの列数とテキスト列のサイズを合計行サイズ制限の 32k まで増やすことができます。 |
ディクショナリおよびサービス テーブルの列数を増やすオプションの 1 つは、文字列型(VARCHAR)の列のサイズを(次に説明する DATA_STRING_MAX_SIZE プロパティで指定されている)デフォルト値の 200 文字から減らす方法です。文字列型の列の最大サイズはすべてのディクショナリ(およびサービス)に適用されるため、この値を減らす場合は注意してください。 指定されたサイズよりも長いテキスト データは切り捨てられます。
テーブルがインストール プロセスによって作成された後に、各データ タイプの列数を変更することはできません。
パラメータ |
デフォルト値 |
サイトでの値 |
---|---|---|
NUMBER_OF_DICTIONARY_VARCHAR_FIELDS |
40 |
|
NUMBER_OF_DICTIONARY_NUMERIC_FIELDS |
10 |
|
NUMBER_OF_DICTIONARY_DATE_FIELDS |
10 |
|
NUMBER_OF_SERVICE_VARCHAR_FIELDS |
80 |
|
NUMBER_OF_SERVICE_NUMERIC_FIELDS |
20 |
|
NUMBER_OF_SERVICE_DATE_FIELDS |
20 |
|
データ マート ディクショナリおよびサービス テーブル内の文字フィールドの最大サイズは、デフォルトで 200 文字に設定されています。 これは、ディクショナリおよびサービスにおける、すべてのテーブル内のすべての文字(テキスト)フィールドのサイズです。 このプロパティは、最初のデータ マートのインストール後に、Cisco Technical Assistance Center(TAC)から入手できるスクリプトを実行することでのみ変更できます。
文字フィールドには、1 行(テキスト)および複数行(テキスト域)のフィールドとしてサービス フォームに表されるデータと、オプション ボタンとして表されるデータが格納されます。 チェックボックスおよび複数選択のドロップダウン リストで 1 つ以上のオプションをオンにした場合は、オンにしたすべてのオプションがカンマで区切られた状態で同じデータ マート文字フィールドに含まれます。 文字フィールドの最大サイズを設定する際は、注意が必要です。 サイズが小さすぎると、データは大幅に切り捨てられる場合があるため、一般的に説明フィールドおよびコメント フィールドが影響を受けます。 サイズが大きすぎると、ETL プロセスおよびレポートの生成の両方のパフォーマンスに悪影響が生じる場合があります。
パラメータ |
デフォルト値 |
サイトでの値 |
---|---|---|
DATA_STRING_MAX_SIZE |
200 |
|
次の手順に従って、サイトのレポート可能なディクショナリおよびサービスをサポートするデータ マートの設定方法を決定します。
Reporting モジュールには、Service Catalog データ マートを保守するためのスクリプトや、ユーザが使用できる標準レポートおよび KPI を生成するためのスクリプトが必要です。
Cognos DataManager ETL から生成された Service Catalog Extract-Transform-Load(ETL)スクリプトは、Service Catalog から提供される作成済みレポートの実行と、データ マートにあるフォームに依存しないすべてのデータをサポートするデータベースに対する入力を制御します。
追加コマンド ファイルにより、Cognos QueryStudio と Report Studio(Ad-Hoc Reports および Report Designer)で使用されるフレームワークの生成が完了し、Service Catalog のデータ マートでアドホック レポーティングが可能になります。
これらのスクリプトは、同じ呼び出しとロギングのフレームワークを共有します。 これらは、Cognos サーバに配置して実行される Windows .cmd ファイルとして使用できます。 任意のエンタープライズ スケジューラを使用して実行をスケジュールできます。 Cognos サーバの <ReportingInstalledDirectory>\logs ディレクトリには、これらのスクリプトのアクティビティのログが記録されます。
標準レポートおよび主要業績評価指標(KPI)をサポートするには、次のスクリプトが必須です。
プログラム |
説明/使用方法 |
---|---|
update_datamart_std.cmd |
Data Manager で指定した ETL ルールに従って、事前に作成されたレポートをサポートするデータベース テーブルにデータを入力します。 これは、データベース コンテンツの差分リフレッシュではなく完全な再ビルドです。 <8cognos.root >\c10_64 \datamanager \log にログ ファイルが生成されます。 |
データ マートをサポートするには、次のプログラムが必須です。
プログラム |
説明/使用方法 |
---|---|
update_datamart.cmd |
カスタム レポート作成パッケージで使用されるデータ マート テーブルにデータを入力します。 また、Form Data Reporting テーブルのデータも取得します。 これは、カスタム レポート パッケージのすべてのテーブルの差分更新です。 ログ ファイルを cognos.root/c10-64 および cognos_installed_dir/logs/ cognos_datamart_update.log に生成します。 このスクリプトは、次のオプションを使用して実行できます。 |
create_model.cmd |
動的に定義されたレポート可能オブジェクト(ディクショナリとサービス)および標準のファクトとディメンションを含む Cognos FrameworkManager モデルを作成します。 静的に定義されたモデル(データ マートで使用される標準のファクトとディメンション)を、レポート可能なサービスとディクショナリを記述する、動的に生成されたメタデータとマージしてモデルが再ビルドされます。 |
publish_fdr_pkg.cmd |
FrameworkManager モデルを Cognos BI サーバに Cognos ScriptPlayer ユーティリティ経由でパブリッシュします。 モデルを作成するプログラム(create_model.cmd)の後に、Service Catalog データ マート更新の一部として実行する必要があります。 |
環境の拡大に伴って、Form Data Reporting(アドホック レポート)ディクショナリおよびサービス テーブルの数を増加する必要があります。たとえば、追加サービスをオンラインにする場合や、追加ディクショナリのコンテンツのレポートが必要な場合などです。 Cisco Prime Service Catalog レポート ソリューションをインストールした後、FDR Configurator ユーティリティを使用して、Form Data Reporting 設定を変更できます(DataMart についてを参照)。
ここでは、FDR Configurator を起動して設定する方法について説明します。
(注) |
この項で説明されているタスクを実行するには、管理者権限を持つユーザとしてログインする必要があります。 |
このプログラムを実行するには、次の手順を実行します。
ステップ 1 | Cognos マシン上で、環境変数 JAVA_HOME を<COGNOS_HOME >\bin64\jre\7.0 に設定します。 次に、PATH 環境変数の先頭に %JAVA_HOME%\bin を追加します。 |
ステップ 2 | データ マート データベースにアクセスするすべてのプログラムを停止します。 |
ステップ 3 | 「<Reporting_Install_Dir>\cognos\bin」ディレクトリに移動します。 |
ステップ 4 |
fdrConfigurator.exe をダブルクリックして FDR Configurator を起動します。 経過表示バーが表示されます。 完了すると、FDR Configurator ウィザードの最初のページ([概要(Introduction)] ページ)が表示されます(以下を参照)。
|
この設定ウィザードでは、各ページに表示されるさまざまなフィールドを順次設定していきます。 各ページに入力したら、[次へ(Next)] をクリックして次のページに進みます。また、[戻る(Previous)] をクリックすると前のページに戻ることができます。 ウィザードの最後に [インストール(Install)] をクリックして設定を開始します。 随時、[キャンセル(Cancel)] をクリックすることで、設定を行わずにウィザードを終了できます。
設定オプションでは、大文字と小文字が区別されるので、大文字と小文字を区別せずにデータベース名などの値を入力すると、設定が失敗する可能性があります。
FDR Configurator ウィザードを実行するには、次の手順を実行します。
ステップ 1 | FDR Configurator を起動します(FDR Configurator の起動を参照)。 | ||||||||||
ステップ 2 | ウィザードの最初のページ([概要(Introduction)] ページ。FDR Configurator の起動を参照)で、[次へ(Next)] をクリックしてウィザードを開始します。 | ||||||||||
ステップ 3 |
ウィザードの次の 2 つのページでは、変更する Reporting インストールについて、データベース タイプを選択し、データ マート データベースのパスワードを入力します。各ページを完了するごとに、[次へ(Next)] をクリックしてください。 データ マート データベースのページで [次へ(Next)] をクリックすると、ウィザードの [Form Data Reportingテーブル(Form Data Reporting Tables)] ページが表示されます(以下を参照)。 |
||||||||||
ステップ 4 |
Form Data Reporting テーブルの設定は、既存のデータ マート データベースから取得されます。 次の表に説明されているように、これらの設定は変更できます。
[デフォルトに戻す(Restore Defaults)] をクリックすると、編集した値は、既存のデータ マート データベースの現行の設定値で上書きされます。 |
||||||||||
ステップ 5 |
[次へ(Next)] をクリックして、ウィザードの次のページに進みます。 ウィザードの [Form Data Reportingディクショナリ設定(Form Data Reporting Dictionary Settings)] ページが表示されます(以下を参照)。 |
||||||||||
ステップ 6 |
Form Data Reporting ディクショナリの設定は、既存のデータ マート データベースから取得されます。 次の表に説明されているように、Form Data Reporting ディクショナリの設定は変更できます。
[デフォルトに戻す(Restore Defaults)] をクリックすると、編集した値は、既存のデータ マート データベースの現行の設定値で上書きされます。 |
||||||||||
ステップ 7 |
[次へ(Next)] をクリックして、ウィザードの次のページに進みます。 ウィザードの [Form Data Reportingサービス設定(Form Data Reporting Service Settings)] ページが表示されます(以下を参照)。 |
||||||||||
ステップ 8 |
Form Data Reporting サービスの設定は、既存のデータ マート データベースから取得されます。 次の表に説明されているように、Form Data Reporting サービスの設定は変更できます。
[デフォルトに戻す(Restore Defaults)] をクリックすると、編集した値は、既存のデータ マート データベースの現行の設定値で上書きされます。 |
||||||||||
ステップ 9 | [次へ(Next)] をクリックして、ウィザードの要約ページに進みます。 | ||||||||||
ステップ 10 | 設定ウィザードで、設定プロセスを開始するのに十分な情報が入力されました。 このページで設定内容を確認してください。 変更が必要な場合は、[戻る(Previous)] をクリックして目的のページに戻り、必要な変更を行ってください。 内容が正しい場合、[インストール(Install)] をクリックして設定を開始します。 このプロセスの実行中にウィザードを中止することは避けてください。 | ||||||||||
ステップ 11 |
設定プロセスが正常に完了したら、[完了(Done)] をクリックして設定ウィザードを閉じます。 設定プロセスが失敗した場合は、[完了(Done)] をクリックして設定ウィザードを閉じてから、ステップ 1 に戻って FDR Configurator を再試行します。 設定プロセスのログは、「<Reporting_Install_Dir>\_CSP_FDRConfigurator\Logs」ディレクトリにあります。 |
ここでは、Cognos に HTTPS を設定する方法について説明します。
SSL サポートを Cognos Server で有効にするには、Cognos Gateway のプロトコルを HTTPS に変更する必要があります(IIS などの Web サーバも HTTPS に設定されていることが前提です)。
(注) |
Windows Server 2008 R2 の場合、TCP ポート(80)を削除できません。そのため、ファイアウォールを使用して TCP ポート(80)を無効にする必要があります。 |
IIS 証明書を Cognos Server にインポートするには、次の手順を実行します。
ステップ 1 |
IIS で使用されるサーバ証明書は、Cognos 10.2.1 BI Server の安全な場所にコピーする必要があります。
|
||
ステップ 2 | コマンド プロンプトを開いて、フォルダ「C:\Program Files\cognos\c10_64\bin」に移動します。 | ||
ステップ 3 | JAVA_HOME=C:\Program Files\cognos\c10_64\bin64\jre\7.0 を設定します。 | ||
ステップ 4 |
次のコマンドを入力して、IIS サーバ証明書を Cognos 10.2.1 の JCA Keystore にインポートします。 例: ThirdPartyCertificateTool.bat -T -i -r CA_certificate_file -k crn_location/configuration/signkeypair/jCAKeystore -p password (for example: ThirdPartyCertificateTool.bat -T -i -r “c:\certnew.cer” -k “C:\Program Files\Cognos\c10-64\configuration\signkeypair\jCAKeystore” -p NoPassWordSet) |
SSL に対応するために Cognos 10.2.1 を設定するには、次の手順を実行します。
ステップ 1 |
[Program Files] > [IBM Cognos 10-64] > [IBM Cognos設定(IBM Cognos Configuration)] を選択します。 |
ステップ 2 |
[環境(Environment)] > [ゲートウェイURI(Gateway URI)] を選択します。 http を https に変更し、デフォルトのポート 80 を 443 に変更します。 |
ステップ 3 |
[暗号化(Cryptography)] > [相互認証を使用しますか(Use mutual authentication?)] を選択し、 [はい(True)] に変更します。 |
ステップ 4 | [暗号化(Cryptography)] > [Cognos] > [サードパーティCAを使用しますか(Use third party CA?)] を選択し、 [はい(True)] に変更します。 |
ステップ 5 | 設定を保存します。 |
ステップ 6 | IBM Cognos サービスを停止します。 |
ステップ 7 | 再起動します。 |
newscale.properties を変更するには、次の手順を実行します。
ステップ 1 | newscale.properties ファイルで、cognoswebprotocol パラメータの http を https に変更します。 |
ステップ 2 | Prime Service Catalog アプリケーション サーバを再起動します。 |
変更を検証するするには、次の手順を実行します。
ステップ 1 |
https://CognosServername.domain.com/cognos10 にログインし、Cognos Connection にログインできるかチェックします。 |
ステップ 2 |
https://RequestCenterServername.domain.com/RequestCenter にログインし、Reporting モジュールまたは Advanced Reporting モジュールに移動できるかチェックします。 |
主要業績評価指標(KPI)では、Service Catalog サービスの管理で重要と見なされるトレンドまたは統計情報をトレースする早くて便利な方法を提供します。
[ダッシュボード(Dashboard)] オプションは、Reporting モジュールに含まれています。 このオプションを使用して、最大 4 つの KPI を表示するようにポータルを設定できます。
[Reporting] > [ダッシュボード(Dashboard)] > [ダッシュボードの設定(Configure Dashboard)] ボタンを選択すると、使用可能な KPI のリストが表示されます。
[主要業績評価指標の選択(Select Key Performance Indicators)] ページで、レポート名の左側にあるチェックボックスをオンにして、ダッシュボードに表示する KPI を指定します。 [順序(Order)] ドロップダウン メニューを使用して、選択した KPI をダッシュボードの四分円に表示する順序(1 ~ 4)を選択します。 選択内容をクリアするには [リセット(Reset)] をクリックし、変更を行わずにポップアップ ウィンドウを閉じるには [キャンセル(Cancel)] をクリックします。 [KPIの選択内容の保存(Save KPI Selection)] をクリックします。 変更はダッシュボードに反映されます。
Service Catalog のパフォーマンスを測定する KPI を指定できます。 インストールしていないモジュールの KPI を選択した場合、グラフの代わりに「使用可能なデータはありません(No data available)」という凡例が表示されます。
素早く簡単に新しい KPI を登録できます。
ステップ 1 | [モジュール(Module)] ドロップダウン メニューから [Advanced Reporting] を選択します。 |
ステップ 2 | [KPI 管理(KPI Administration)] をクリックします。 |
ステップ 3 | [新規KPIの登録(Register New KPI)] をクリックします。 |
ステップ 4 | KPI パラメータを入力します。 |
ステップ 5 |
[登録(Register)] をクリックします。 新しい KPI が [KPI管理(KPI Administration)] ページの KPI リストに表示されます。 |
[KPI管理(KPI Administration)] オプションは、「分析管理者」のロールを持つユーザが Advanced Reporting モジュールで使用できます。 [KPI管理(KPI Administration)] オプションを使用すると管理者は、KPI の表示または動作を調整できます。 次の手順を実行します。
ステップ 1 | [Advanced Reporting] > [KPI管理(KPI Administration)] を選択します。 | ||||||||||||||||||||||||||||||||||||
ステップ 2 | [主要業績評価指標の選択(Select Key Performance Indicators)] ページで KPI を選択します。 | ||||||||||||||||||||||||||||||||||||
ステップ 3 | KPI を選択すると、そのプロパティが [KPIの更新(Update KPI)] のページに表示されます。 | ||||||||||||||||||||||||||||||||||||
ステップ 4 |
変更が必要な KPI プロパティは、KPI の表示を定義するプロパティのみです。 これには次が含まれます。
レポート可能グリッド ディクショナリなしで設定されたサービスの場合、サービスに対する各要求(申請エントリ)は ETL プロセスによってキャプチャされ、対応する DM_FDR_SERVICETABLE に 1 行のデータとして挿入されます。 ただし、1 つ以上のレポート可能グリッド ディクショナリが設定されたサービスの場合、ETL プロセスは DM_FDR_SERVICETABLE テーブルに複数行のデータを挿入します。 挿入される行の数は、レポート可能グリッド ディクショナリのうち最大の行数に対応します。 たとえば、レポート可能非グリッド ディクショナリ 1 つ(Employee)と、レポート可能グリッド ディクショナリ 2 つ(Contact、Address)を持つサービスがあるとします。 このサービスに対する要求が、Contact 内のデータ 3 行、Address 内のデータ 2 行、Employee ディクショナリ内のいくらかのデータを持つと仮定します。 このサービスに対してサービス テーブル内にキャプチャされたフォーム データは、次のようになります。
|
目次
この章は次のトピックで構成されています。
次の表に示されるロールは、Organization Designer モジュールで定義されます。これらは、Reporting および Advanced Reporting モジュールにアクセスするユーザに割り当てる必要があります。
ユーザを定義済みロール「Service Operations Report User」に割り当てると、そのユーザには事前に作成されたレポートの実行が可能になります。 管理者は、個々のロールに基づいて、Reporting フィーチャにアクセスするためのレポート機能を有効にする必要があります。
RBAC を有効にするには、次の手順を実行します。
ステップ 1 | [Organization Designer] > [ロール(Roles)] > [機能(Capabilities)] を選択します。 | ||||||||||||||||||
ステップ 2 | [システム機能の追加(Add System Capability)] テーブルで、[モジュールの選択(Choose Module)] ドロップダウン リストから [Reporting] モジュールを選択します。 | ||||||||||||||||||
ステップ 3 | 選択する機能の [機能の選択(Choose Capability)] チェックボックスをオンにします。 以下の表を参照してください。 | ||||||||||||||||||
ステップ 4 |
[追加(Add)] をクリックします。
|
ここでは、レポートを実稼働環境まで移行する方法について説明します。
通常、Service Catalog 実装は複数のサイトで構成され、それぞれのサイトが異なる役割を果たします。
サイト |
使用方法 |
---|---|
開発 |
サービス定義が開発され、単体テストが行われます。カスタマイゼーションが最初に適用されます。 |
テスト |
開発アクティビティから干渉されることのない、制御された環境。ここでは、品質保証または他の担当者が Service Catalog をテストします。 |
Production |
ユーザ コミュニティが Service Catalog からサービスを要求でき、IT チームがサービス要求を満たすことができる実稼働環境。 |
上記のガイドラインに従うと、Service Catalog ソフトウェアに適用済みのカスタマイゼーションを失うことなく、このソフトウェアをアップグレードできます。 ただし、これらのガイドラインには、クライアントから提供されたコンテンツ(サービス定義や個人プロファイルなど)をサイト間で移行する必要性についての説明がありません。 この機能は Catalog Deployer で提供されています。
Catalog Deployer モジュールは、メタデータ(サービス定義)およびリポジトリに保存されている組織データ(個人、組織、および関連するエンティティ)の設定管理を行います。 Catalog Deployer のマニュアルについては、『Cisco Prime Service Catalog Designer Guide』を参照してください。
ここで説明する導入オプションを使用してレポートを移動するには、Reporting モジュールの管理権限が必要です。 事前定義されているサイト管理者ロールには、この権限が含まれます。
ソースとターゲットの両方の環境の Cognos Server のファイル システムにアクセスできる必要があります。
展開中の特定のタイミングで、Service Catalog OLTP データベースをサイト間でコピーすることが望ましい場合があります。 次に例を示します。
Service Catalog OLTP データベースをサイト間でコピーするには、次の手順を実行します。
ステップ 1 | ターゲット環境で、Prime Service Catalog および Service Link のサービスを停止します。 |
ステップ 2 | ターゲット データベースの最新のバックアップ コピーがあることを確認します。 |
ステップ 3 | 必要に応じて、宛先からのエクスポート ファイルを、ターゲット データベース サーバにアクセスできるファイル システムにコピーします。 |
ステップ 4 | ターゲット データベースにデータをインポートします。 |
ステップ 5 | SQLServer の場合は、新たにインポートされるデータベースに存在するログインおよびユーザが、Service Catalog のこのインスタンスに必要な資格情報と一致することを確認します。 必要に応じて新しいログインを作成したり、既存のログインをデータベース オーナーに関連付けたりして、このユーザが適切な権限を持つようにします。 Oracle の場合は、新しくインポートされるデータベースに適切なユーザが存在し、Service Catalog インストーラで指定されたように特権が付与されていることを確認します。 |
ステップ 6 | 両サイトが 2 つの異なる Cognos レポート サーバにアクセスしている場合は、各サイトの「CognosServer」の名前を指定する CnfParams テーブルのエントリを更新して、更新内容をコミットします。 |
ステップ 7 | ターゲット環境で、Prime Service Catalog および Service Link のサービスを再起動します。 |
ステップ 8 | [管理(Administration)] > [エンティティホーム(Entity Homes)] > [SiteProtection] の [このサイト(This Site Is)] プロパティを現在のサイトに設定します。 [エンティティホーム(Entity Homes)] の指定が異なる場合、またはサイトの保護レベルが異なる場合は、手動で変更を行い、変更を保存します。 |
ステップ 9 | 両サイトが 2 つの異なる LDAP ディレクトリに接続している場合は、ディレクトリ統合のデータ ソース定義を適宜変更します。 |
ステップ 10 | Service Link エージェントの接続プロパティをすべてチェックし、ターゲット環境に合わせて変更します。 |
ステップ 11 | 手作業での追加処理がある場合はそれを実行し、データを調整します。 たとえば、一部のユーザ、グループ、または組織に権限を追加したり、権限を取り消したりする場合があります。 |
ステップ 12 | メンテナンスが完了したことをユーザに通知します。 |
ステップ 1 | 開発マシンで、CustomReports という名前のフォルダを Cognos の Public Folders ディレクトリに作成します。 フォルダの名前を変更しても構いませんが、パブリック フォルダにする必要があります。 |
ステップ 2 | 新しいレポートを上記で作成した CustomReports フォルダにコピーします。 |
ステップ 3 | レポート管理者の機能を持つユーザとして Service Catalog にログインします。 |
ステップ 4 | 右上隅の [起動(Launch)] に移動し、[IBM Cognos管理(IBM Cognos Administration)] をクリックします。 |
ステップ 5 | [設定(Configuration)] タブをクリックします。 |
ステップ 6 | [コンテンツ管理(Content Administration)] に移動し、画面の右上隅にある [新規エクスポート(New Export] アイコンをクリックします。 |
ステップ 7 | エクスポートの名前(たとえば、CustomReports)およびその他の詳細を指定し、[次へ(Next)] をクリックします。 |
ステップ 8 | [導入方法(Deployment Method)] ページで、[パブリックフォルダおよびディレクトリ コンテンツの選択(Select public folders and directory content)] を選択して、[次へ(Next)] をクリックします。 |
ステップ 9 | [追加(Add)] をクリックして、手順 1 で作成した CustomReports フォルダを選択します。 次に、カスタム レポート フォルダを選択し、下部にある [追加(Add)] を選択してから [OK] をクリックします。 |
ステップ 10 |
[インポート後に無効化(Disable after import)] の選択を解除して、[次へ(Next)] をクリックします。 |
ステップ 11 | [次へ(Next)] をクリックします。 |
ステップ 12 | [ディレクトリコンテンツの選択(Select the directory content)] セクションで、[Cognosグループおよびロールを含める(Include Cognos groups and roles)] を選択し、[既存のエントリを置換(Replace existing entries)] を選択して、[次へ(Next)] をクリックします。 |
ステップ 13 | [一般オプションの選択(Specify the general options)] セクションで、 [アクセス権限を含める(Include access permissions)] を選択して、[新規および既存のエントリに適用(Apply to new and existing existing entries)] を選択します。 |
ステップ 14 | [外部ネームスペース(External namespaces)] で、[外部ネームスペースへの参照を含める(Include references to external namespaces)] を選択します。 |
ステップ 15 | [エントリ所有者(Entry ownership)] セクションで、[インポートを実行するユーザ(The user performing the import)] を選択して、[一般オプションの選択(Specify the general options)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 16 | [導入アーカイブの指定(Specify a deployment archive)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 17 | [要約の確認(Review the summary)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 18 | [アクションの選択(Select an action)] セクションで、[完了(Finish)] をクリックします。 |
ステップ 19 | [今すぐ(Now)] を選択し、[オプションを使用して実行(Run with options)] セクションで [実行(Run)] をクリックします。 このプロセスにより、CustomReports.zip が Cognos Source マシンの <CognosHome>\c10_64\deployment フォルダに作成されます。 |
ステップ 1 | エクスポートされたファイル CustomReports.zip を実稼働マシンの <CognosHome>\c10_64\deployment フォルダにコピーします。 |
ステップ 2 | 画面右上隅の [起動(Launch)] に移動し、[IBM Cognos管理(IBM Cognos Administration)] をクリックします。 |
ステップ 3 | [設定(Configuration)] タブをクリックします。 |
ステップ 4 | [コンテンツ管理(Content Administration)] に移動し、画面右上隅の [新規インポート(New Import)] アイコンを選択します。 |
ステップ 5 | [CustomReports] を選択し、[次へ(Next)] をクリックします。 |
ステップ 6 | [CustomReports] を選択し、[パブリックフォルダのコンテンツの選択(Select the public folders content)] セクションで [次へ(Next)] をクリックします。 |
ステップ 7 | [ディレクトリのコンテンツの選択(Select the directory content)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 8 | [一般オプションの指定(Specify the general options)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 9 | [要約の確認(Review the summary)] セクションで、[次へ(Next)] をクリックします。 |
ステップ 10 | [アクションの選択(Select an action)] セクションで、[完了(Finish)] をクリックします。 |
ステップ 11 | 新しいレポート フォルダ CustomReports が、実稼働マシンのパブリック フォルダ エリアに表示されます。 |
Service Catalog データ マートは、通常、サービス設計者がカスタマイズせずにインストールできます。 ただし、この「最小の共通特性」によるアプローチでは、ほとんどのサイトのレポート作成要件を満たすことができません。 このため、推奨される手順は、上記のベスト プラクティスを、サイトのディクショナリおよびサービス設定と組み合わせて確認することです。 次のセクションをワークシートとして使用することで、アナリストはサイトに対して必要なデータ マート設定を決定できます。 これらの設定パラメータは、Advanced Reporting を設定するために使用できます。
これらのパラメータは、データ マートをインストールする際に指定する必要がある多くのプロパティに対応しています。 データ マートの設定とそのインストールのカスタマイズに使用されるインストールおよび設定パラメータの詳細については、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。
データ マートを作成するときに、データ マートが保持するディクショナリおよびサービス ディメンションの最大数を指定します。 これらの各ディメンションはデータ マートの個別のテーブルに対応します。 ディクショナリまたはサービスの数は、データ マートをインストールした後に増やすことができます。 ただし、この手順を避けるために、直近の導入に対して計画されている現在の要件および機能向上に対応できる十分なテーブルでデータ マートを作成してください。
作成する必要がある各タイプのテーブル数を決定するための「特効薬」はありません。 一部のガイドラインは前のセクションで説明されています。 サービス設計者はすべてのディクショナリを確認し、データ マートに含めるディクショナリを決定して、それらを [Service Designer] > [ディクショナリ(Dictionaries)] コンポーネントの [レポート可能(Reportable)] ドロップダウン メニューで [はい(Yes)] を選択することで、レポート可能なディクショナリとして指定する必要があります。
Service Catalog は、レポート可能として指定され、データ マートに作成されたサービスおよびディクショナリ テーブルの数が指定された数を超過しないように追跡します。 後からディクショナリ(またはサービス)をレポート可能にしないと決定した場合は、対応する [レポート可能(Reportable)] フィールドを [いいえ(No)] に変更します。 これにより、データ マートをロードする ETL ジョブからソース ディクショナリまたはサービスが削除されます。 レポート作成フレームワークでは、クエリー サブジェクトを引き続き利用できます。ただし、ディクショナリまたはサービス データを保持するテーブルを別のディクショナリまたはサービスとともに使用することはできず、使用中のテーブル数の 1 つとしてカウントされます。
データ マート内のすべてのデータは文字列(テキスト)、数値、または日付(時間コンポーネントを含む)として格納されます。 内部ディクショナリからのデータは、次の表で示すように、適切な型に変換されます。
データ マート列のデータ タイプ |
内部ディクショナリのデータ タイプ |
データベース固有の実装 |
---|---|---|
数値(Number (Numeric)) |
番号(Number) 資金(Money) |
Oracle:NUMBER SQL Server:FLOAT |
日付(Date) |
日付(Date) 日付および時刻(Date and Time) |
Oracle:DATE SQL Server:DATETIME |
文字列(Varchar:可変長文字列) |
テキスト(Text) Person URL アカウント(Account) 電話 SSN(社会保障番号) ブール値 |
Oracle:VARCHAR2 SQL Server:VARCHAR |
Person データ タイプは、サービス フォーム上の [個人の選択(Select a Person)] ウィンドウで示されるように、個人の名と姓の組み合わせとしてデータ マート内に表されます。 Boolean データ タイプは、データ タイプのオプション ボタン表現で示されるように、「yes」および「no」に対応する文字列で表されます。
外部ディクショナリからのデータは適切なタイプに変換されます。 たとえば、すべての数値フィールドはその大きさや精度に関係なく、上記の表に示すターゲット データベースの数値型に変換されます。 外部ディクショナリ テーブルのグラフィックおよびラージ オブジェクト(LOB)データ タイプはサポートされていないため、データ マートの作成時や ETL プロセスによるデータのロード時には無視されます。
データ マート設定の一環として、設計者はディクショナリおよびサービス テーブルに作成されるデータ型(文字、数値、日付)ごとの列数を指定します。 すべてのディクショナリ テーブルは、データ型ごとの許容列数に関して、同一の構成である必要があります。 これは、サービス テーブルについても同様です。
(注) |
SQLServer では、テーブルの行の長さを 8k(8192)バイトよりも大きくしないよう警告しています。 これにより、サービス ディメンション テーブルのサイズには大幅な制限が課されることになります。 このような制限は Oracle には存在しないため、データ タイプごとの列数とテキスト列のサイズを合計行サイズ制限の 32k まで増やすことができます。 |
ディクショナリおよびサービス テーブルの列数を増やすオプションの 1 つは、文字列型(VARCHAR)の列のサイズを(次に説明する DATA_STRING_MAX_SIZE プロパティで指定されている)デフォルト値の 200 文字から減らす方法です。文字列型の列の最大サイズはすべてのディクショナリ(およびサービス)に適用されるため、この値を減らす場合は注意してください。 指定されたサイズよりも長いテキスト データは切り捨てられます。
テーブルがインストール プロセスによって作成された後に、各データ タイプの列数を変更することはできません。
データ マート ディクショナリおよびサービス テーブル内の文字フィールドの最大サイズは、デフォルトで 200 文字に設定されています。 これは、ディクショナリおよびサービスにおける、すべてのテーブル内のすべての文字(テキスト)フィールドのサイズです。 このプロパティは、最初のデータ マートのインストール後に、Cisco Technical Assistance Center(TAC)から入手できるスクリプトを実行することでのみ変更できます。
文字フィールドには、1 行(テキスト)および複数行(テキスト域)のフィールドとしてサービス フォームに表されるデータと、オプション ボタンとして表されるデータが格納されます。 チェックボックスおよび複数選択のドロップダウン リストで 1 つ以上のオプションをオンにした場合は、オンにしたすべてのオプションがカンマで区切られた状態で同じデータ マート文字フィールドに含まれます。 文字フィールドの最大サイズを設定する際は、注意が必要です。 サイズが小さすぎると、データは大幅に切り捨てられる場合があるため、一般的に説明フィールドおよびコメント フィールドが影響を受けます。 サイズが大きすぎると、ETL プロセスおよびレポートの生成の両方のパフォーマンスに悪影響が生じる場合があります。
パラメータ |
デフォルト値 |
サイトでの値 |
---|---|---|
DATA_STRING_MAX_SIZE |
200 |
|
Reporting モジュールには、Service Catalog データ マートを保守するためのスクリプトや、ユーザが使用できる標準レポートおよび KPI を生成するためのスクリプトが必要です。
Cognos DataManager ETL から生成された Service Catalog Extract-Transform-Load(ETL)スクリプトは、Service Catalog から提供される作成済みレポートの実行と、データ マートにあるフォームに依存しないすべてのデータをサポートするデータベースに対する入力を制御します。
追加コマンド ファイルにより、Cognos QueryStudio と Report Studio(Ad-Hoc Reports および Report Designer)で使用されるフレームワークの生成が完了し、Service Catalog のデータ マートでアドホック レポーティングが可能になります。
これらのスクリプトは、同じ呼び出しとロギングのフレームワークを共有します。 これらは、Cognos サーバに配置して実行される Windows .cmd ファイルとして使用できます。 任意のエンタープライズ スケジューラを使用して実行をスケジュールできます。 Cognos サーバの <ReportingInstalledDirectory>\logs ディレクトリには、これらのスクリプトのアクティビティのログが記録されます。
標準レポートおよび主要業績評価指標(KPI)をサポートするには、次のスクリプトが必須です。
プログラム |
説明/使用方法 |
---|---|
update_datamart_std.cmd |
Data Manager で指定した ETL ルールに従って、事前に作成されたレポートをサポートするデータベース テーブルにデータを入力します。 これは、データベース コンテンツの差分リフレッシュではなく完全な再ビルドです。 <8cognos.root >\c10_64 \datamanager \log にログ ファイルが生成されます。 |
データ マートをサポートするには、次のプログラムが必須です。
プログラム |
説明/使用方法 |
---|---|
update_datamart.cmd |
カスタム レポート作成パッケージで使用されるデータ マート テーブルにデータを入力します。 また、Form Data Reporting テーブルのデータも取得します。 これは、カスタム レポート パッケージのすべてのテーブルの差分更新です。 ログ ファイルを cognos.root/c10-64 および cognos_installed_dir/logs/ cognos_datamart_update.log に生成します。 このスクリプトは、次のオプションを使用して実行できます。 |
create_model.cmd |
動的に定義されたレポート可能オブジェクト(ディクショナリとサービス)および標準のファクトとディメンションを含む Cognos FrameworkManager モデルを作成します。 静的に定義されたモデル(データ マートで使用される標準のファクトとディメンション)を、レポート可能なサービスとディクショナリを記述する、動的に生成されたメタデータとマージしてモデルが再ビルドされます。 |
publish_fdr_pkg.cmd |
FrameworkManager モデルを Cognos BI サーバに Cognos ScriptPlayer ユーティリティ経由でパブリッシュします。 モデルを作成するプログラム(create_model.cmd)の後に、Service Catalog データ マート更新の一部として実行する必要があります。 |
環境の拡大に伴って、Form Data Reporting(アドホック レポート)ディクショナリおよびサービス テーブルの数を増加する必要があります。たとえば、追加サービスをオンラインにする場合や、追加ディクショナリのコンテンツのレポートが必要な場合などです。 Cisco Prime Service Catalog レポート ソリューションをインストールした後、FDR Configurator ユーティリティを使用して、Form Data Reporting 設定を変更できます(DataMart についてを参照)。
ここでは、FDR Configurator を起動して設定する方法について説明します。
(注) |
この項で説明されているタスクを実行するには、管理者権限を持つユーザとしてログインする必要があります。 |
ステップ 1 | Cognos マシン上で、環境変数 JAVA_HOME を<COGNOS_HOME >\bin64\jre\7.0 に設定します。 次に、PATH 環境変数の先頭に %JAVA_HOME%\bin を追加します。 |
ステップ 2 | データ マート データベースにアクセスするすべてのプログラムを停止します。 |
ステップ 3 | 「<Reporting_Install_Dir>\cognos\bin」ディレクトリに移動します。 |
ステップ 4 |
fdrConfigurator.exe をダブルクリックして FDR Configurator を起動します。 経過表示バーが表示されます。 完了すると、FDR Configurator ウィザードの最初のページ([概要(Introduction)] ページ)が表示されます(以下を参照)。
|
この設定ウィザードでは、各ページに表示されるさまざまなフィールドを順次設定していきます。 各ページに入力したら、[次へ(Next)] をクリックして次のページに進みます。また、[戻る(Previous)] をクリックすると前のページに戻ることができます。 ウィザードの最後に [インストール(Install)] をクリックして設定を開始します。 随時、[キャンセル(Cancel)] をクリックすることで、設定を行わずにウィザードを終了できます。
設定オプションでは、大文字と小文字が区別されるので、大文字と小文字を区別せずにデータベース名などの値を入力すると、設定が失敗する可能性があります。
FDR Configurator ウィザードを実行するには、次の手順を実行します。
ステップ 1 | FDR Configurator を起動します(FDR Configurator の起動を参照)。 | ||||||||||
ステップ 2 | ウィザードの最初のページ([概要(Introduction)] ページ。FDR Configurator の起動を参照)で、[次へ(Next)] をクリックしてウィザードを開始します。 | ||||||||||
ステップ 3 |
ウィザードの次の 2 つのページでは、変更する Reporting インストールについて、データベース タイプを選択し、データ マート データベースのパスワードを入力します。各ページを完了するごとに、[次へ(Next)] をクリックしてください。 データ マート データベースのページで [次へ(Next)] をクリックすると、ウィザードの [Form Data Reportingテーブル(Form Data Reporting Tables)] ページが表示されます(以下を参照)。 |
||||||||||
ステップ 4 |
Form Data Reporting テーブルの設定は、既存のデータ マート データベースから取得されます。 次の表に説明されているように、これらの設定は変更できます。
[デフォルトに戻す(Restore Defaults)] をクリックすると、編集した値は、既存のデータ マート データベースの現行の設定値で上書きされます。 |
||||||||||
ステップ 5 |
[次へ(Next)] をクリックして、ウィザードの次のページに進みます。 ウィザードの [Form Data Reportingディクショナリ設定(Form Data Reporting Dictionary Settings)] ページが表示されます(以下を参照)。 |
||||||||||
ステップ 6 |
Form Data Reporting ディクショナリの設定は、既存のデータ マート データベースから取得されます。 次の表に説明されているように、Form Data Reporting ディクショナリの設定は変更できます。
[デフォルトに戻す(Restore Defaults)] をクリックすると、編集した値は、既存のデータ マート データベースの現行の設定値で上書きされます。 |
||||||||||
ステップ 7 |
[次へ(Next)] をクリックして、ウィザードの次のページに進みます。 ウィザードの [Form Data Reportingサービス設定(Form Data Reporting Service Settings)] ページが表示されます(以下を参照)。 |
||||||||||
ステップ 8 |
Form Data Reporting サービスの設定は、既存のデータ マート データベースから取得されます。 次の表に説明されているように、Form Data Reporting サービスの設定は変更できます。
[デフォルトに戻す(Restore Defaults)] をクリックすると、編集した値は、既存のデータ マート データベースの現行の設定値で上書きされます。 |
||||||||||
ステップ 9 | [次へ(Next)] をクリックして、ウィザードの要約ページに進みます。 | ||||||||||
ステップ 10 | 設定ウィザードで、設定プロセスを開始するのに十分な情報が入力されました。 このページで設定内容を確認してください。 変更が必要な場合は、[戻る(Previous)] をクリックして目的のページに戻り、必要な変更を行ってください。 内容が正しい場合、[インストール(Install)] をクリックして設定を開始します。 このプロセスの実行中にウィザードを中止することは避けてください。 | ||||||||||
ステップ 11 |
設定プロセスが正常に完了したら、[完了(Done)] をクリックして設定ウィザードを閉じます。 設定プロセスが失敗した場合は、[完了(Done)] をクリックして設定ウィザードを閉じてから、ステップ 1 に戻って FDR Configurator を再試行します。 設定プロセスのログは、「<Reporting_Install_Dir>\_CSP_FDRConfigurator\Logs」ディレクトリにあります。 |
ここでは、Cognos に HTTPS を設定する方法について説明します。
SSL サポートを Cognos Server で有効にするには、Cognos Gateway のプロトコルを HTTPS に変更する必要があります(IIS などの Web サーバも HTTPS に設定されていることが前提です)。
(注) |
Windows Server 2008 R2 の場合、TCP ポート(80)を削除できません。そのため、ファイアウォールを使用して TCP ポート(80)を無効にする必要があります。 |
ステップ 1 |
IIS で使用されるサーバ証明書は、Cognos 10.2.1 BI Server の安全な場所にコピーする必要があります。
|
||
ステップ 2 | コマンド プロンプトを開いて、フォルダ「C:\Program Files\cognos\c10_64\bin」に移動します。 | ||
ステップ 3 | JAVA_HOME=C:\Program Files\cognos\c10_64\bin64\jre\7.0 を設定します。 | ||
ステップ 4 |
次のコマンドを入力して、IIS サーバ証明書を Cognos 10.2.1 の JCA Keystore にインポートします。 例: ThirdPartyCertificateTool.bat -T -i -r CA_certificate_file -k crn_location/configuration/signkeypair/jCAKeystore -p password (for example: ThirdPartyCertificateTool.bat -T -i -r “c:\certnew.cer” -k “C:\Program Files\Cognos\c10-64\configuration\signkeypair\jCAKeystore” -p NoPassWordSet) |
ステップ 1 |
[Program Files] > [IBM Cognos 10-64] > [IBM Cognos設定(IBM Cognos Configuration)] を選択します。 |
ステップ 2 |
[環境(Environment)] > [ゲートウェイURI(Gateway URI)] を選択します。 http を https に変更し、デフォルトのポート 80 を 443 に変更します。 |
ステップ 3 |
[暗号化(Cryptography)] > [相互認証を使用しますか(Use mutual authentication?)] を選択し、 [はい(True)] に変更します。 |
ステップ 4 | [暗号化(Cryptography)] > [Cognos] > [サードパーティCAを使用しますか(Use third party CA?)] を選択し、 [はい(True)] に変更します。 |
ステップ 5 | 設定を保存します。 |
ステップ 6 | IBM Cognos サービスを停止します。 |
ステップ 7 | 再起動します。 |
ステップ 1 |
https://CognosServername.domain.com/cognos10 にログインし、Cognos Connection にログインできるかチェックします。 |
ステップ 2 |
https://RequestCenterServername.domain.com/RequestCenter にログインし、Reporting モジュールまたは Advanced Reporting モジュールに移動できるかチェックします。 |
主要業績評価指標(KPI)では、Service Catalog サービスの管理で重要と見なされるトレンドまたは統計情報をトレースする早くて便利な方法を提供します。
[ダッシュボード(Dashboard)] オプションは、Reporting モジュールに含まれています。 このオプションを使用して、最大 4 つの KPI を表示するようにポータルを設定できます。
[Reporting] > [ダッシュボード(Dashboard)] > [ダッシュボードの設定(Configure Dashboard)] ボタンを選択すると、使用可能な KPI のリストが表示されます。
[主要業績評価指標の選択(Select Key Performance Indicators)] ページで、レポート名の左側にあるチェックボックスをオンにして、ダッシュボードに表示する KPI を指定します。 [順序(Order)] ドロップダウン メニューを使用して、選択した KPI をダッシュボードの四分円に表示する順序(1 ~ 4)を選択します。 選択内容をクリアするには [リセット(Reset)] をクリックし、変更を行わずにポップアップ ウィンドウを閉じるには [キャンセル(Cancel)] をクリックします。 [KPIの選択内容の保存(Save KPI Selection)] をクリックします。 変更はダッシュボードに反映されます。
Service Catalog のパフォーマンスを測定する KPI を指定できます。 インストールしていないモジュールの KPI を選択した場合、グラフの代わりに「使用可能なデータはありません(No data available)」という凡例が表示されます。
[KPI管理(KPI Administration)] オプションは、「分析管理者」のロールを持つユーザが Advanced Reporting モジュールで使用できます。 [KPI管理(KPI Administration)] オプションを使用すると管理者は、KPI の表示または動作を調整できます。 次の手順を実行します。
ステップ 1 | [Advanced Reporting] > [KPI管理(KPI Administration)] を選択します。 | ||||||||||||||||||||||||||||||||||||
ステップ 2 | [主要業績評価指標の選択(Select Key Performance Indicators)] ページで KPI を選択します。 | ||||||||||||||||||||||||||||||||||||
ステップ 3 | KPI を選択すると、そのプロパティが [KPIの更新(Update KPI)] のページに表示されます。 | ||||||||||||||||||||||||||||||||||||
ステップ 4 |
変更が必要な KPI プロパティは、KPI の表示を定義するプロパティのみです。 これには次が含まれます。
レポート可能グリッド ディクショナリなしで設定されたサービスの場合、サービスに対する各要求(申請エントリ)は ETL プロセスによってキャプチャされ、対応する DM_FDR_SERVICETABLE に 1 行のデータとして挿入されます。 ただし、1 つ以上のレポート可能グリッド ディクショナリが設定されたサービスの場合、ETL プロセスは DM_FDR_SERVICETABLE テーブルに複数行のデータを挿入します。 挿入される行の数は、レポート可能グリッド ディクショナリのうち最大の行数に対応します。 たとえば、レポート可能非グリッド ディクショナリ 1 つ(Employee)と、レポート可能グリッド ディクショナリ 2 つ(Contact、Address)を持つサービスがあるとします。 このサービスに対する要求が、Contact 内のデータ 3 行、Address 内のデータ 2 行、Employee ディクショナリ内のいくらかのデータを持つと仮定します。 このサービスに対してサービス テーブル内にキャプチャされたフォーム データは、次のようになります。
|