この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章は次のトピックで構成されています。
この章では、アプリケーション コンポーネントのスタートアップ手順とシャットダウン手順、推奨バックアップ プラクティス、アプリケーション コンポーネントの構成管理とカスタマイズ、継続的な保守タスク、および重要なエラー状態、エラー メッセージ、および解決方法について説明します。
(注) |
<APP_HOME> と指定されている場合は、Service Catalog がインストールされているルート ディレクトリを意味します。 |
Linux Puppet Master、Linux、および Windows のターゲット VM は、直接もしくはプロキシを介してインターネットにアクセスできる必要があります。 または、内部リポジトリに接続するよう VM を設定することもできます。
ゲートウェイ VM は(各ガイドで)説明されているとおりにトラフィックをルーティングするよう設定し、設定後は制限しないようにする必要があります。
(注) |
アプリケーションをインストールするためにターゲット VM のポートをクローズすることはお勧めしません。 ゲートウェイ VM のポートは『Cisco Prime Collaboration Quick Start Guide』の説明に従ってオープンできます。 |
SELinux にインストールされた Puppet Master をホスティングしている Linux VM では、デフォルトのインストールと設定によって、IPTables ルールとともに必要なポート(8140、8139、および 5150)がオープンされます。
Puppet Agent によって VM での ポート アクセスやセキュリティ プロトコルが変更されることはありません。 これらのデバイスを強化すると、関連アプリケーションのインストールまたは実行が失敗する可能性があります。 VM は UCSD のフェンスド コンテナに配置され、アプリケーション障害を回避するために、アクセスはゲートウェイ VM で制御されます。
完全に展開されたシステムのコンポーネントには、Service Catalog、Integration Server(Service Link)、およびAdvanced Reporting(Cognos)が含まれています。 Service Catalog および Integration Server はそれぞれ、Catalog.war および ISEE.war の各展開パッケージ内のアプリケーション サーバに展開されます。
(注) |
各コンポーネントは展開されているとおりにバックアップし、すべてのカスタマイゼーションは展開時または変更時に保存することを推奨します。 |
次のデータベースをバックアップする必要があります。
チューニングに関する次の推奨事項は、多くの Servce Catalog サイトに適用されます。 チューニングに関するこのほかの推奨事項については、各アプリケーション サーバのマニュアルを参照してください。
組織に遠隔地のユーザが多数いる場合は、HTTP 応答の GZIP 圧縮(RFC 1952)をオンにすると役立ちます。RFC 2616 の次のセクションを参照してください。
GZIP 圧縮は、低速または遅延の大きいネットワークを使用するユーザにとって有用です。 ただし、GZIP 圧縮により、サーバとユーザのブラウザにわずかながらオーバーヘッドが発生します。
GZIP 圧縮を有効にするには、以下を実行します。
Java メモリ設定は、アプリケーション サーバが使用する Java 仮想マシン(JVM)専用の設定です。 "java -h" コマンドと "java -X" コマンドを使用すると、システムで使用可能なすべてのオプションのリストが返されます。 これらのコマンドを発行する場合は、ご利用中のアプリケーション サーバが使用する JVM と同じ JVM を呼び出していることを確認してください。
Service Catalog で「メモリ不足」エラーが発生する場合は、JVM で使用可能な最小および最大のヒープ サイズを管理する Java メモリ スイッチを調整しなければならない場合があります。 たとえば、次の設定は WebLogic に正しく適用されます。
MEM_ARGS="-verbose:gc -Xms1024m -Xmx1024m -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:MaxPermSize=256m"
キュー接続ファクトリの接続数は、JMS サーバの作業負荷に基づいて設定する必要があります。 1 つの Service Catalog インスタンスに推奨される設定は 25 です。 必要な接続数に関して、クラスタのサーバ数に基づいた厳格なルールはありません。 アプリケーション環境に最適な接続設定を実現するには、チューニング作業が必要となります。
JDK を新しいバージョンにアップグレードするには、次の手順を実行します。
Service Catalog データベースを設定およびチューニングする方法に関する主な FAQ のいくつかと、それらの質問への回答を示します。 これらの問題の詳細については、該当するデータベースに固有のマニュアルを参照してください。 これらの FAQ の多くは、SQLServer よりもチューニングの機会が多い Oracle に関するものです。
Oracle データベースのパフォーマンスは次の方法で最適化できます。
次のような設定を適用します。
パラメータ |
値 |
---|---|
perf.__large_pool_size |
16777216 |
*.processes |
300 |
*.pga_aggregate_target |
1059145600 |
*.sga_max_size |
716582400 # 内部で調整されます |
*.sga_target |
716582400 |
*.sort_area_size |
500000000 |
RequestCenter データベースのすべてのテーブルおよびインデックスに関する統計情報を収集するには、DBMS_STATS.GATHER_SCHEMA_STATS コマンドを使用します。 次の例では、"RC User" がスキーマの所有者です。
execute DBMS_STATS.GATHER_SCHEMA_STATS(ownname=>'RCUser',cascade=>TRUE);
「オプティマイザ統計情報の管理」に関する Oracle データベース管理の章では、次の点が推奨されています。
ヒストグラムレベルの統計情報の収集が不可欠なテーブルは、次のとおりです。
各テーブルの統計情報を収集する DBMS_STATS コマンドの例は、次のようになります。
BEGIN DBMS_STATS.GATHER_TABLE_STATS (OWNNAME => 'RCUser', TABNAME => 'TXACTIVITY', METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO'); END;
次のコマンドでスナップショットを有効にします。
ALTER DATABASE <database name> SET READ_COMMITTED_SNAPSHOT ON
揮発性の Service Catalog テーブルには特に、SQLServer DBCC Reindex コマンドを推奨します。 このプロセスは、勤務時間外で定期的にスケジュールする必要があります(一般的には週に 1 度)。
次に示すテーブルは最も揮発性が高く、DBCC Reindex の対象となります。
TxActivity TxActivityAssignment TxAttribute TxCheckList TxChecklistEntry TxComments TxCondition TxDictionaryHTMLBindings TxDocument TxEmailSent TxEventTrigger |
TxEventTriggerParam TxIncident TxInternalOptionList TxInvocation TxInvocationAttribute TxJMSMessage TxJoin TxMultivalue TxObjectDataHTML TxObjectDictionaries TxObjectRelation |
TxPerformerSummary TxProcess TxRequisition TxRequisitionEntry TxRequisitionStep TxRole TxRule TxSatisfaction TxService TxSubscription TxTimer |
Cognos は、すべてのレポートとキューの定義を ContentStore という名前のデータベースに格納します。 Cognos KnowledgeBase には、ContentStore のサイズ変更と維持に関するエントリが格納されます。 特に重要なのは、ContentStore に必要なサイズを算出するために、予測される使用状況の統計に基づいて発行される計算式です。
これらの計算式を組み込んだスプレッドシートは、Cisco Technical Assistance Center(TAC)から入手可能です。 次に例を示します。
コンポーネント |
推定値 |
ユニットあたりの領域(KB) |
合計(KB) |
---|---|---|---|
アクティブ ユーザ数 |
250 |
|
|
レポートを実行する同時ユーザ数(一時ディスク領域要件) |
50 |
100,000 |
5,000,000 |
保存されたレポート 1 ~ 10 ページ(1 ユーザにつき 2、Public 1、MyFolder 1) |
500 |
340 |
170,000 |
保存されたレポート 10 ~ 100 ページ(1 ユーザにつき 9、Public 4、MyFolder 5) |
2250 |
440 |
990,000 |
保存されたビュー 1 ~ 100 行(1 ユーザにつき 3、すべて MyFolder) |
750 |
250 |
187,500 |
保存されたビュー 100 ~ 1000 行(1 ユーザにつき 8、すべて MyFolder) |
2000 |
350 |
700,000 |
フォルダ Public MyFolder(1 ユーザにつき 5) |
1,250 |
|
0 |
FrameMaker モデル(シスコが提供) |
|
|
20,000 |
空のコンテンツ ストア |
1 |
3,000 |
3,000 |
アクティブ スケジュール(50 日 + 125 週) |
175 |
30 |
5,250 |
合計(Total) |
|
|
7,075,750 |
トランザクション データベースは、プレフィックス命名規則を採用した一連のリレーショナル テーブルで構成されます。 次の表は、DBA または本番データベースの保守やチューニングを行う必要がある人への支援として示されています。 これらのテーブルの構造およびコンテンツの所有権はシスコに帰属します。シスコでは、リリースごとにテーブルの名前または構造を自由に変更する権利を留保します。
プレフィックス |
意味 |
使用方法 |
---|---|---|
Cnf |
設定 |
Service Catalog が使用する内部設定情報が含まれるテーブル。一般的に、これらのテーブルは小さく、そのコンテンツは本番環境内でスタティックです。 |
Co |
ポータル コンテンツ |
Portal Manager のコンテンツとページの定義が含まれるテーブル。 |
Def |
定義 |
サービス フォーム、ディクショナリ、チェックリストなど、ユーザが設定可能なオブジェクトのユーザ定義を保持するテーブル。テーブル サイズは実装のサイズによって異なりますが、本番環境では比較的安定しています。通常は、Catalog Deployer の使用を介してのみ変更されます。 |
Dir |
ディレクトリ |
個人および組織の情報を格納するテーブル。ほとんどの場合、テーブル サイズはきわめて小さく(スキル、プロジェクト、役職)、安定しています。個人に関係するテーブルは、組織の規模によって大きく異なります。 |
JMS |
Java Message Service |
内部で使用。 |
Mdr |
メタデータ リポジトリ |
(ユーザー定義の)動的スキーマ(サービス項目、標準、ポータルなど)を使用したテーブルのメタデータを含むテーブル。 |
Si |
サービス項目(Service Item) |
サービス項目のデータを格納するテーブル。 |
St |
標準(Standards) |
標準のデータを格納するテーブル。 |
TX |
トランザクション |
すべてのトランザクションを格納するテーブル。 テーブルが非常に大きくなる可能性があります。テーブルのデータは揮発性です。 |
Uc |
ユーザ コンテンツ |
Portal Manager のカスタム コンテンツを格納するテーブル。 |
UI |
ユーザ インターフェイス |
Service Manager のビュー、ログイン時に表示されるデフォルト モジュール、Service Link フィルタなど、ユーザ インターフェイスに関するユーザ固有のカスタマイゼーションを定義するテーブル。 |
Xtr |
外部 |
Service Link が外部タスクの管理に使用するテーブル。定義テーブル(XtrDef)は非常に小さい場合がありますが、外部タスクのメッセージを格納するテーブルは規模が大きく、急速に肥大化します。 |
XtrEUI |
外部エンド ユーザ統合 |
ディレクトリ統合の定義に使用されるテーブル。 |
分割と消去を通してパフォーマンスを最適化できます。
履歴要求分割機能は、完了した要求(ステータスが「クローズ」、「キャンセル」、「配信キャンセル」、または「拒否」の要求)を履歴トランザクション テーブルに移動します。 履歴要求分割を使用すると、現在のトランザクション テーブルのデータ量が削減されることにより、アプリケーション全体のパフォーマンスが向上します。 この向上は、Service Manager、My Services、および Service Link の各モジュールにおけるタスク、要求、および外部メッセージのフィルタ処理や検索で確認できます。 ETL と要求ワークフロー処理は、現在のトランザクション テーブル内のデータが減少することからも恩恵を受けます。
履歴要求分割は、Administration モジュール内のシステム設定 [履歴要求スケジューラの有効化(Enable Historical Requisitions Scheduler)] によって制御されます。 これが有効になっている場合は、365 日を超えて完了した要求がバックグラウンド プロセスによって履歴トランザクション テーブルに移行されます。 365 日の保存期間は変更可能であり、組織の特定のニーズに合わせて変更できます。
スケジューラが無効になっている場合は、[管理(Administration)] > [ユーティリティ(Utilities)] ページで履歴要求の移行プロセスを一時的に実行することができます。
そのため、My Services と Service Manager の両方の要求ビューが [最近(Recent)] ビューと [履歴(Historical)] ビューに分割されています。 履歴トランザクション テーブルに移行された要求は、[履歴要求ビューの有効化(Enable Historical Requisitions View)] システム設定を選択することによってアクセス可能にできます。 これらの要求は、[マイサービス(My Services)] > [要求(Requisitions)] ページの [履歴(Historical)] タブだけでなく、Service Manager の [履歴要求(Historical Requisitions)] ビューにも表示されます。 UI 経由で履歴要求に関連付けられたタスクや外部メッセージを確認することはできませんが、データは Service Catalog データベースに保存されます。
初めて履歴要求の移行を行う際には、多くの場合、大量のデータを扱います。 アプリケーション ユーザへの影響を軽減するため、オフピーク期間に Administration モジュールから手動でこのプロセスを実行します。
Administration モジュールに移動し、[履歴要求のスケジューラを有効にする(Enable Historical Requisitions Scheduler)] の設定がオフになっていることを確認します。 [ユーティリティ(Utilities)] で、[プロセスの実行(Run Processes)] を開いて目的の締切日を入力します。 任意で、処理する要求のバッチ サイズと最大数を指定します。
バッチ サイズを大きくすると処理時間が短縮されますが、データベース サーバにはより大きな一時領域またはロールバック セグメントが必要になります。 要求の最大数を設定するか、[停止(Stop)] をクリックすると、履歴要求の移行プロセスの時間を制限することができます。 処理の速度と時間は、要求の平均サイズによって異なります。
(注) |
移行プロセスを実行する前に、データベース管理者と協力してリハーサルを行い、初回の実行にかかる時間を推定しておくことを推奨します。 |
履歴トランザクション データは、Reporting 用の ETL プロセスでは抽出されません。 履歴要求分割機能を設定する場合は、次の点を考慮してください。
次の設定は履歴要求分割に適用されます。
reqArchival.poller.enable:アプリケーション インスタンスを使用して履歴要求移行プロセスを実行できるかどうかを制御します。 クラスタ化された Service Catalog 環境では、常に、1 つのノードだけを使用して移行プロセスが実行されます。 サーバが性能の低いマシンの場合やサーバが災害復旧用の場合は、1 つ以上のノードでこのプロパティが "false" に設定されることがあります。
上記ファイル内のその他の設定は、通常の環境では変更しないでください。
Service Catalog には、選択した日付よりも古いトランザクションまたはユーザが指定したその他の条件を満たすトランザクションを削除するトランザクション消去機能があります。 これを使用すると、アプリケーション管理者はテスト ユーザやサンプル サービスを削除する前にテスト要求を削除することができます。 ただし、消去機能では大量データの消去は実行できません。 また、メンテナンス フェーズが長引かないようにする必要があります。
要求の消去は、次の手順で構成されます。
ステップ 1 | 消去のフィルタ条件をクリアします。 |
ステップ 2 | 消去のフィルタ条件を設定します。 |
ステップ 3 | 要求消去のリハーサルを実行します。 |
ステップ 4 | 本番の要求消去を実行します。 |
常に同じフィルタ条件を使用して要求を消去する場合(たとえば、キャンセルされた要求をすべて消去するなど)、この手順は不要です。 ただし、混乱を避けるために前回の実行からの条件を最初にクリアすることをお勧めします。
1 つまたはすべてのフィルタ条件をクリアするには、ClearAllPurgeFilter スクリプトを使用します。 [Purge Filter Name ] が指定されていない場合は、RequestCenter データベースの CnfPurgeFilter テーブルのフィルタ エントリがすべて削除されます。 そうでない場合は、[Purge Filter Name ] が CnfPurgeFilter テーブルに存在すれば指定されたフィルタのみが削除されます。
Oracle:
ClearAllPurgeFilter ORACLE [SID ] [User ] [Password ] [Purge Filter Name(オプション)]
SQL Server:
ClearAllPurgeFilter SQLSERVER [Server ] [Database ] [User ] [Password ] [Purge Filter Name(オプション)]
オプションの [Purge Filter Name ] に指定可能な値は次のとおりです。
1 つまたは複数のフィルタ条件を追加するには、AddPurgeFilter スクリプトを使用します。 要求が削除されるのは、すべての消去条件を満たす場合のみです。 フィルタ条件は RequestCenter データベースの CnfPurgeFilter テーブルに保存されます。
データベースのタイプに合わせて次の構文を使用します。
Oracle:
AddPurgeFilter ORACLE [SID ] [User ] [Password ] [Purge Filter Name ] [Purge Filter Value ]
SQL Server:
AddPurgeFilter SQLSERVER [Server ] [Database ] [User ] [Password ] [Purge Filter Name ] [Purge Filter Value ]
消去フィルタ名 |
説明 |
消去フィルタ値 |
||||
---|---|---|---|---|---|---|
CREATIONSTARTDATE |
この日付以降に作成された消去要求。 |
DD-MON-YYYY 形式の日付。 |
||||
CREATIONENDDATE |
この日付以前に作成された消去要求。 |
DD-MON-YYYY 形式の日付。 |
||||
CLOSEDSTARTDATE |
この日付以降にクローズされた消去要求。 |
DD-MON-YYYY 形式の日付。 |
||||
CLOSEDENDDATE |
この日付以前にクローズされた消去要求。 |
DD-MON-YYYY 形式の日付。 |
||||
REQUISITIONSTATUS |
指定されたステータスの消去要求。 |
可能な値は、PREPARATION、OPEN、ONGOING、CLOSED、CANCELLED、REJECTED、DELIVERY CANCELLED、ORDERED、または ALL です。 |
||||
REQUISITIONID |
要求 ID に基づいて特定の要求を消去します。 |
要求に割り当てられた固有の番号。 |
||||
REQUISITIONRANGE |
要求 ID 範囲に基づいて特定の要求を消去します。 |
開始要求 ID と終了要求 ID、およびその間にダッシュ記号(例:30001-39999)。 |
||||
SERVICEID |
サービス ID に基づいて、特定のサービスを含む要求を消去します。 |
サービスの固有識別子。サービス定義のため、Service Designer の [一般(General)] ページに表示されます。 |
||||
SERVICENAME |
サービス名に基づいて、特定のサービスを含む要求を消去します。 SERVICEID および SERVICENAME フィルタの場合は、すべてのサービス要求を含め、要求全体が削除されます。 個々のエントリ(サービス)レベルではなく、要求レベルで消去が行われます。 |
"Email Service" など、二重引用符で囲まれたサービス名。
|
要求を消去する前に、任意で「リハーサル」を実行して、実際に削除することなく、消去される要求をチェックできます。 これは、フィルタ条件を検証する役割を果たします。
フィルタ条件を満たす要求のリストを表示するには、PurgeRequisitions スクリプトを使用します。
Oracle:
PurgeRequisitions ORACLE [SID ] [User ] [Password ] DRY_RUN [UserName]
SQL Server:
PurgeRequisitions SQLSERVER [Server ] [Database ] [User ] [Password ] DRY_RUN [UserName]
UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。
リハーサルで検出された要求のリストは、RequestCenter データベースの LogPurge テーブルに保存されます。 ログ エントリは実行ごとに RunID が 1 ずつ増分されてテーブルに追加されます。 最も大きい RunID を指定して LogPurge テーブルのエントリをクエリーすると、消去される要求を確認できます。
リハーサルや要求の消去を何度も実行すると、時間とともに LogPurge テーブルが急速に大きくなる可能性があります。 したがって、定期的に LogPurge テーブルを手動で切り捨て、以前の実行のエントリを削除することを推奨します。
ステップ 1 から 3 を繰り返すと、消去条件を修正できます。 消去フィルタ条件が確定したら、実際の要求消去に進むことができます。
要求消去を行うと、タスクと Service Link メッセージを含め、消去フィルタ条件を満たす要求とそれらの要求に関連付けられたすべてのトランザクション データが削除されます。
RequestCenter データベースの LogPurge テーブルには実際の要求消去の結果も追加されます。 実際の要求消去を実行するには、次に示すように、PurgeRequisitions コマンドに PURGE パラメータを指定して使用します。
Oracle:
PurgeRequisitions ORACLE [SID ] [User ] [Password ] PURGE [UserName]
SQL Server:
PurgeRequisitions SQLSERVER [Server ] [Database ] [User ] [Password ] PURGE [UserName]
UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。
ワークフロー消去ユーティリティを使用すると、ワークフロー処理に関連するデータベースから一時データが削除されます。 これらのデータが本番環境で使用されなくなった場合は、これらを削除すればデータベースのサイズを小さくすることができます。 また、消去ユーティリティを定期的に実行すると、全体的なパフォーマンスが改善される可能性があります。
ワークフロー消去ユーティリティは、RequestCenter データベースのストアド プロシージャの形式で提供されます。 データベースの規模が大きい場合、消去ユーティリティの実行には 1 時間以上かかる場合があります。 このため、システムのダウン時またはアクティビティが少ない時間帯に消去を行う必要があります。 データベースでスクリプトの実行にかかる時間を確認するために、サンドボックス環境でのテスト実行が推奨されます。
消去の開始/終了時間を追跡するには、ストアド プロシージャを実行する前に SQL ツールで print ステートメントを表示する設定を有効にします。
Oracle データベースでユーティリティを実行するには、次の手順を実行します。
ステップ 1 | RequestCenter データベースをバックアップします。 |
ステップ 2 | データベースに対応するクエリー ツール(SQL*Plus など)を使用して、RCUser として RequestCenter データベースに接続します。 |
ステップ 3 |
次のコマンドを実行します。
日付は、DD-MON-YYYY 形式である必要があります。 UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。 実行の終了時に、総経過時間が表示されます。 次に出力の例を示します。 例: Creation/Data population of TxReq_temp- Successful Time taken for TxReq_Temp : .17 s Creation/Data population of TxReqEntry_temp- Successful Time taken for TxReqEntry_Temp : .08 s Creation/Data population of TxSubscription_Temp - Successful Time Taken for TxSubscritpion : 5.39 s Creation/Data population of TxProcess_Temp - Successful Creation/Data population of TxJoin_Temp - Successful Time Taken for TxJoin : .91 s Creation/Data population of TxCondition_Temp - Successful Time Taken for TxCondition : 1.18 s Creation/Data population of TxActivity_Temp - Successful Creation/Data population of TxEventTrigger_Temp - Successful Creation/Data population of TxEventTriggerParam_Temp - Successful Time Taken for TxEventTriggerParam : .33 s ***Creation/Data population of TxEventTrigger - Successful*** ***Creation/Data population of TxProcess - Successful*** Creation/Data population of XtrChannelInfo_Temp - Successful Creation/Data population of XtrChannelParameterSpec_Temp - Successful ***Creation/Data population of XtrChannelParameterSpec - Successful*** Elapsed time: 10.62 s PL/SQL procedure successfully completed. |
SQL Server データベースでユーティリティを実行するには、次の手順を実行します。
ステップ 1 | RequestCenter データベースをバックアップします。 |
ステップ 2 | データベースに対応するクエリー ツール(SQL Server Management Studio など)を使用して、RCUser として RequestCenter データベースに接続します。 |
ステップ 3 |
makecall ディレクトリで、次のコマンドを実行します。★クライアント指示により、原文と異なる訳文に変更★
日付は、DD-MON-YYYY 形式である必要があります。 UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。
実行の終了時に、総経過時間が表示されます。 次に出力の例を示します。 例: (2258 row(s) affected) Creation/Data population of TxReq_Temp- Successful Time taken for TxReq_Temp : 0 s (2639 row(s) affected) Creation/Data population of TxReq_Temp- Successful Time taken for TxReqEntry_Temp : 0 s (56580 row(s) affected) (0 row(s) affected) (56580 row(s) affected) Creation/Data population of TxSubscription_Temp - Successful Time taken for TxSubscription_Temp : 6 s (4551 row(s) affected) (2 row(s) affected) Creation/Data population of TxProcess_Temp - Successful Time taken for TxProcess_Temp : 0 s (4154 row(s) affected) (0 row(s) affected) (4154 row(s) affected) Creation/Data population of TxJoin_Temp - Successful Time taken for TxJoin_Temp : 1 s (9382 row(s) affected) (9382 row(s) affected) Creation/Data population of TxCondition_Temp - Successful Time taken for TxCondition_Temp : 2 s (7017 row(s) affected) Creation/Data population of TxActivity_Temp - Successful Time taken for TxActivity_Temp : 0 s (5528 row(s) affected) Creation/Data population of TxEventTrigger_Temp - Successful Time taken for TxEventTrigger_Temp : 0 s (1202 row(s) affected) Creation/Data population of TxEventTriggerParam_Temp - Successful Time taken for TxEventTriggerParam_Temp : 0 s (5528 row(s) affected) ***Creation/Data population of TxEventTrigger - Successful*** (1202 row(s) affected) ***Creation/Data population of TxEventTriggerParam - Successful*** (4553 row(s) affected) ***Creation/Data population of TxProcess - Successful*** (645 row(s) affected) Creation/Data population of XtrChannelInfo_Temp - Successful Time taken for XtrChannelInfo_Temp : 0 s (8409 row(s) affected) (8409 row(s) affected) ***Creation/Data population of XtrChannelParameterSpec - Successful*** Elapsed time: 11 s |
Service Link メッセージ消去ユーティリティは、データベースから Service Link メッセージを削除します。
これらのメッセージは(サービス フォームの複雑さおよびエージェントの設定に使用されるコンテンツ タイプ オプションに応じて)きわめて大きくなる可能性があるため、メッセージを削除することにより、Service Link 関連のデータを保持するために必要なデータベース サイズが大幅に削減されます。 外部メッセージは変更されないままです。
Oracle データベースでユーティリティを実行するには、次の手順を実行します。
ステップ 1 | RequestCenter データベースをバックアップします。 |
ステップ 2 | データベースに対応するクエリー ツール(SQL*Plus など)を使用して、RCUser として RequestCenter データベースに接続します。 次のコマンドを実行します。 SET SERVEROUTPUT ON EXECUTE sp_CleanupSlMessageContent( [FromDate], [ToDate], [UserName]); 日付は、DD-MON-YYYY 形式である必要があります。 UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。 実行の終了時に、消去されたメッセージの総数および総経過時間が表示されます。 次に出力の例を示します。 例: Updating messages with MessageStateID 2 (completed) or 3(failed) that are older than 100 daysDone updating 3200 messagesScript Start Time 07/06/2011 02:07:11 and script End Time07/06/2011 02:09:11 |
SQL Server データベースでユーティリティを実行するには、次の手順を実行します。
ステップ 1 | RequestCenter データベースをバックアップします。 |
ステップ 2 |
データベースに対応するクエリー ツール(SQL Server Management Studio など)を使用して、RCUser として RequestCenter データベースに接続します。 次のコマンドを実行します。 EXECUTE sp_PurgeWorkflowTables [FromDate], [ToDate], [UserName] 日付は、DD-MON-YYYY 形式である必要があります。 UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。 実行の終了時に、総経過時間が表示されます。 次に出力の例を示します。 例: Purge messages with MessageStateID 2 (completed) or 3 (failed) Done updating 1500 messages Script Start Time Jul 6 2011 2.57 PM and script End Time Jul 6 2011 3.57 PM |
配信できなかった電子メール通知は確認または再試行のためにアプリケーション内で保持されます。 削除または再送信するには、Administration モジュールに移動して、[ユーティリティ(Utilities)] で [不達電子メール(Undelivered Emails)] タブを探します。 情報が無効になっているメッセージは削除し、SMTP の一時的な障害が原因で配信されなかったメッセージは再送信します。
管理者はこのアプリケーション ページを定期的に訪問して再送信が必要なメッセージを確認することをお勧めします。 バックログ内に大量のメッセージが残っていると、電子メール通知プロセスが大幅に減速する可能性があります。
ここでは、アプリケーションの保守、WebLogic の管理、および JBoss について説明します。 また、データ ソースの使用と外部データ ディクショナリの「補助テーブル」の作成、キャッシュされたデータ、アプリケーションのセキュリティ、パッチの適用、およびマルチキャスト設定に関する情報も示します。
JBoss アプリケーション サーバを使用した一般的なインストールでは、コマンド ラインまたは設定されていれば Windows サービスから、アプリケーション サーバとともに Cisco Prime Service Catalog を起動および停止できます。
WebLogic の起動方法については、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。
通常の Service Catalog 動作中は、管理サーバを再起動する必要はありません。 ただし、インストール時にカスタム データベース ドライバをインストールする場合には再起動が必要です。
Cognos コンポーネントに依存する Advanced Reporting のすべてのインストールは Windows システム上にあるため、Cognos Configuration Manager から、または Windows サービスを使用して Cognos アプリケーションを再起動する手順は、どちらも Windows 固有のタスクです。
システムを再起動するには、次の手順を実行します。
ステップ 1 |
を選択します。 |
ステップ 2 | を選択します。 |
次のサービスを停止して再起動します。
Service Catalog 用の .war ファイルはファイル システムに展開されます。 このファイルの正確な場所は、アプリケーション サーバによって異なります。 Service Link アプリケーションは、.war ファイルの ISEE.war(Integration Server Enterprise Edition)として提供されます。
ここでは、アプリケーション サーバの起動とシャットダウンの手順について説明します。対象となるサーバは次のとおりです。
サーバを再起動するには、アプリケーション サーバのサーバ コンソール、またはコマンドライン スクリプトを適宜使用します。 管理者が開発環境でスクリプトを使用できるようにしてください。
展開に関する詳細を参照する必要がある重要なファイルを次に示します。 このマニュアルに明記されているか、Cisco Technical Assistance Center(TAC)からの指示がないかぎり、プロパティ ファイルと、類似の設定ファイルはすべて読み取り専用だと見なしてください。 これらのプロパティ ファイルのいずれかを変更した場合は、サービスを再起動する必要があります。
ファイル |
説明 |
---|---|
newscale.properties |
このファイルは、インストールまたはアップグレード プロセス中、およびインストーラが実行されるたびに、インストーラによって作成されます。 インストーラによってファイルが作成されると、「RequestCenter.war\WEB-INF\classes\config」フォルダに保存されます。 そのため、.ear ファイルが再展開されると、このファイルも再展開されます。 Service Catalog 管理者はファイルに含まれるデータを保持する必要があります。ただし、新しいバージョンではインストーラによって新たな情報が追加される場合があるため、ファイルのコピーを復元しないでください。 newscale.properties のエントリは次のとおりです。
|
rcjms.properties |
このファイルもまた「RequestCenter.war\WEB-INF\classes\config」フォルダにあります。 これには、アプリケーション内部通信用の JMS 設定が含まれます。 キュー名がアプリケーション サーバ上のキュー名と一致することを確認してください。 |
integrationserver.properties |
このファイルは「ISEE.war\WEB-INF\classes\config」フォルダにあります。 このファイルには、統合サーバ(Service Link)の重要なプロパティが含まれています。 |
Service Catalog はアプリケーション サーバのログ ファイルを保持し、アプリケーションの予期されたアクティビティと予期しないアクティビティをどちらも追跡します。 ログは、オープン ソース(Apache)のロギング メカニズムである log4j をベースとするフレームワークを使用して管理されます。 デフォルトで、ログは「ローリング アペンダー」に設定され、新しいログ ファイルが毎日開かれます。 アプリケーション サーバのタイプによってログ ファイルの内容と設定を調整する機能が異なるため、ログ ファイルの場所もアプリケーション サーバのタイプによって異なります。
次のことを推奨します。
Service Catalog はログ ファイルを保持する必要がありません。 ログ ファイルは、主にエラーが発生した場合のトラブルシューティング ツールとして有用です。 ログ エントリには E(エラー)、W(警告)、I(情報)、D(デバッグ)の 4 種類があり、この順で重大度が低下します。
デフォルト ログ ファイルの形式は Cisco Technical Assistance Center(TAC)で想定する形式であるため、この形式を変更することは推奨しません。 その代わり、顧客は自分たちのニーズを満たす独自のアペンダーを作成できます。
Service Link はシステム全体のログ ファイルに加えて、アダプタ タイプごとに個別のログ ファイルを使用するように設定されています。 これらのログも log4j で管理されます。 Service Link のロギングはデフォルトで有効にされます。 アダプタ固有のログ ファイルは ServiceLink\logs ディレクトリに書き込まれます。
すべてのログを記録する DEBUG レベルを有効にすると、ログのサイズが急激に大きくなります。このため、フル デバッグおよびトレース レベルのロギングを有効にするのは短期間にとどめる必要があります。 システムのパフォーマンスが大幅に低下する可能性があるため、本番システムでのロギングは最小限とし、問題を再現するために必要な期間のみとする必要があります。 詳細については、ログとプロパティを参照してください。
WebLogic では、Cisco Prime Service Catalog は WebLogic のロギング設定に基づいてメッセージをルーティングします。デフォルトでは、すべてが WebLogic サーバ ログにロギングされます。通常は次のようなパスにあります。
/apps/bea/user_projects/domains/cisco/servers/nsServer/logs/nsServer.log
デフォルトのログ レベルは INFO に設定されています。このレベルは WLS コンソール経由で調整可能です。
JBoss ログは、"<JBOSS_DIR>/standalone/log" フォルダに配置されています。 ロギング動作を決定する logging.properties ファイルは、"<JBOSS_DIR>\standalone\configuration" フォルダに配置されています。 Log4j.xml は、現在はアプリケーションのロギングの制御には使用されていません。
すべてのモジュールは、JNDI(Java Naming and Directory Interface)経由で定義された J2EE データ ソースを利用します。 これらのデータ ソースは正しいデータベースを指し、適切なログイン情報が設定されている必要があります。
次の場合には、追加の JNDI データ ソースが必要です。
Service Catalog とは異なるデータベース タイプの外部データ ソースにアクセスすることは、サービス フォームではサポートされていません(たとえば、Oracle 上で動作する Service Catalog のインスタンスから SQLServer データ ソースへのアクセスや、Service Catalog の任意のインスタンスから Sybase データ ソースへのアクセスなど)。 データ ソースを設定する手順については、『Cisco Prime Service Catalog Installation Guide』を参照してください。この手順はアプリケーション サーバに固有の手順です。
データ ソースを追加する場合は、可能なかぎりシスコのドライバを使用してください。
JBOSS 7.1.1 を使用してカスタム データ ソースを設定できます。
ステップ 1 | JBOSS アプリケーション サーバの JMX 管理コンソールにログインします。 | ||
ステップ 2 | [データソース(Datasources)] を選択します。 | ||
ステップ 3 | [検証(Validation)] タブを選択します。 | ||
ステップ 4 |
[有効な接続チェッカー(Valid Connection Checker)] フィールドに次のデータを入力します。
|
||
ステップ 5 | [一致した場合に検証する(Validate on Match)] チェックボックスをオフにして false に設定します。 | ||
ステップ 6 | [バックグラウンド検証(Background Validation)] チェックボックスをオンにして true に設定します。 | ||
ステップ 7 | [検証ミリ秒(Validation Millis)] に 600000 を入力します。 | ||
ステップ 8 | [保存(Save)] をクリックします。 | ||
ステップ 9 | [プール(Pool)] タブを選択します。 | ||
ステップ 10 | [最小プールサイズ(Min Pool Size)] に 1 と入力し、[最大プールサイズ(Max Pool Size)] に 10 を入力します。 | ||
ステップ 11 | [保存(Save)] をクリックします。 | ||
ステップ 12 | [プロパティ(Properties)] タブを選択します。 | ||
ステップ 13 | [厳密な最小(Strict Minimum)] および [事前入力が有効(Prefill Enabled)] の値として true を入力します。 | ||
ステップ 14 | [保存(Save)] をクリックします。 |
Service Catalog 内の外部ディクショナリは、データベース内の物理テーブルで補助する必要があります。 外部ディクショナリを読み取り専用にすることはできません。 すべての外部ディクショナリは読み取りと書き込みが可能です。 外部ディクショナリに書き込むのはアプリケーションのみにする必要があります。
アプリケーションで要求に外部ディクショナリを関連付けるには、外部キーとして使用可能な数値列を用意する必要があります。 通常、この名前は RequisitionEntryID とします。
次のコードにより、各行に一意の ID を生成するシーケンスが作成されます。 RequisitionEntryID カラムにインデックスを作成すると、Service Manager のパフォーマンスが大幅に最適化されます。
外部ディクショナリの補助テーブルは、Catalog Deployer によって環境間では転送されません。 service.create sequence X_SEQ のコンポーネントとして展開できるのは、ディクショナリ定義のみです。
create table ( X_ID INT CONSTRAINT PK_X primary key, REQUISITION_ENTRY_ID INT, REQUESTORLANID VARCHAR2 (10), REQUESTORNAME VARCHAR2 (50), FUNDINGSOURCECODE VARCHAR2 (15), DATENEEDED DATE, REASONFORCHANGE VARCHAR2 (50), PROJECTNAME VARCHAR2 (50), TOPINITIATIVE VARCHAR2 (5)); create or replace trigger X_it before insert on X for each row declare seq_val number; begin select X_seq.nextval into seq_val from dual; :new.X_ID := seq_val; end;
Service Designer のサービス エクスポート機能は、Service Catalog への接続確立、エクスポートされた XML の取得、XML のファイルへの保存を行い、ユーザにリンクを返します。
アプリケーションが SSL 対応の場合は、ユーザがサービスを XML ドキュメントとしてエクスポートしようとするときに問題が発生します。 アプリケーションに接続するにはサーバへの認証が必要であり、Service Catalog には SSL 証明書が必要です。
Service Catalog が SSL 対応のときにエクスポート サービス 機能を有効にするには、次の手順を実行します。
ステップ 1 | Service Catalog Web サーバで使用する、信頼できるルート CA 証明書を、Base 64 符号化形式でファイルにエクスポートします。 ファイルの拡張子は「.arm」または「.cert」になります。 これは、任意のテキスト エディタで開くことのできる単純なテキスト ファイルです。 |
ステップ 2 | 使用しているアプリケーション サーバの Java インストール環境に付属する CA 証明書キーストアを検索します。 Java インストール環境の CA 証明書キーストアは、cacerts という名前のファイルです。 |
ステップ 3 |
Service Catalog Web サーバの信頼できるルート CA 証明書を Java の cacerts キーストアにインポートします。 Java の keytool ユーティリティも使用できます。
次に、Java の keytool ユーティリティのコマンドライン構文の例を示します。これにより、ルート CA 証明書が cacerts にインポートされます。 例: keytool.exe -import -trustcacerts -alias RC –file <root_cert_file> -keystore C:\jdk1.6.0_12\jre\lib\security\cacerts
ここで、<root_cert_file> は、ステップ 1 でエクスポートした Service Catalog Web サーバのルート CA 証明書を含むファイルのフル パス名です。 keytool プログラムにより、キーストア パスワードの入力が求められます。 Java の新規インストールの場合、cacerts ファイルのデフォルト キーストア パスワードは changeit です。 「changeit」と入力するか、このマシンに Java をインストールしてからパスワードを変更した場合は、その値を入力します。 [この証明書を信頼しますか?(Trust this certificate?)] という質問が 表示された場合は、「y」と入力します。 . |
ステップ 4 | アプリケーション サーバ インスタンスを再起動し、変更を有効にします。 個々のサーバやアプリケーションではなく、このマシンの JBoss と WebLogic を含むインスタンス全体を再起動します。 |
ほとんどのサイト構成の設定は、アクセス高速化のために J2EE システムにキャッシュされます。 J2EE アプリケーションで使用される設定をリロードするには、Administration モジュールの [設定(Settings)] ページで任意のオプションを変更し、[更新(Update)] をクリックします。 これでキャッシュが無効になり、そのページの設定がリロードされます。
Cisco Prime Service Catalog には、Business Engine と呼ばれる独自のワークフロー管理システムが組み込まれています。 Business Engine のアクション(提供計画の管理)は、アプリケーション サーバで発生するため、アプリケーション ユーザはほとんど意識する必要がありません。 ただし、システム管理者には、Business Engine の処理を確認および場合によっては調整するためのユーザ インターフェイスが提供されます。
Site Administrator システム ロールを持っているユーザは、URL の http://<serverName:portNumber>/RequestCenter/businessengine/index.jsp を経由して Business Engine コンソールにアクセスできます。このコンソールの機能は次のとおりです。
このアプリケーションには、他のキャッシング メカニズムもあります。 キャッシュされた値は、アプリケーション データが変更されると自動的にリフレッシュされます。
SSO 経由の外部認証が使用される場合、一般的にユーザ パスワードはデータベースに保存されません。 保存される場合は、一方向の AES 128 ビット ハッシュとなります。 設定ファイルまたはデータベースに保存されたパスワードは、公開/秘密キー暗号化によって暗号化されます。 追加の暗号化はデータには適用されません。
コンフィギュレーション ファイル内のローカル アプリケーションのパスワードは暗号化されます。 Service Link が設定されていると、J2EE コンテナのパスワードは暗号化されずに、いくつかの設定ファイルにプレーン テキストとして保存されます。
URL は符号化されません。データレベルのセキュリティにより、各画面の承認が確認されます。
ここでは、アプリケーション セキュリティについて説明します。
Service Catalog は、多数の証明書を保存できるキーストアをパスワードで保護して保持します。
Web サーバ、または Web サーバの前にあるコンテンツ スイッチでは SSL を実行することが推奨されます(特にエクストラネットをサポートする環境の場合)。
通常、Web サーバからアプリケーション サーバへの通信を暗号化する必要はありません。
いくつかのツールでは、アプリケーションをスキャンして、CGI ベースの送信(GET 形式の送信)がアプリケーションに存在しないことを確認します。
シスコはデータのセキュリティと安全に注目しており、XSS(クロスサイト スクリプティング)攻撃によって発生する脅威をよく認識しています。
Service Catalog では標準の J2EE input-filter-config.xml ファイルを使用して、URL に < > " ' ( ) & ; の文字が含まれないことをチェックします。
このファイルは RequestCenter.war\WEB-INF\config\ にあります。
リリース 9.3.2 以降のインストールでは、悪意のあるファイルからサービス要求を保護するために使用可能なサービス設計機能が多数用意されています。 フォーム ルールとデフォルト値の設定が適用されたフォーム データを傍受しようとする悪意のある試みを阻止するために、サーバ側ルールと特定の編集制御を使用して、ブラウザ クライアントから送信されたデータをオーバーライドまたは検証することができます。 詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。
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 ディレクトリには、これらのスクリプトのアクティビティのログが記録されます。
標準レポートおよび Key Performance Indicator(KPI)をサポートするには、次のスクリプトが必須です。
プログラム |
説明/使用方法 |
---|---|
update_datamart_std.cmd |
Data Manager で指定した ETL ルールに従って、作成済みレポートをサポートするデータベース テーブルにデータを入力します。 これは、データベース コンテンツの差分リフレッシュではなく完全な再ビルドです。 <cognos.root >\c8 \datamanager \log にログ ファイルが作成されます。 |
データ マートをサポートするには、次のプログラムが必須です。
プログラム |
説明/使用方法 |
---|---|
update_datamart.cmd |
Data Manager で指定されたルールを使用して、データ マートのファクト テーブルとディメンション テーブルおよび Demand Center データ マートにデータを入力します。 これは、すべてのスタティックなディメンション データとファクト データの差分リフレッシュです。 <cognos.root >\c8 \datamanager \log にログ ファイルが作成されます。 |
create_model.cmd |
動的に定義されたレポート可能オブジェクト(ディクショナリとサービス)および標準のファクトとディメンションを含む Cognos FrameworkManager モデルを作成します。 静的に定義されたモデル(データ マートで使用される標準のファクトとディメンション)を、レポート可能なサービスとディクショナリを記述する、動的に生成されたメタデータとマージしてモデルが再ビルドされます。 |
publish_fdr_pkg.cmd |
FrameworkManager モデルを Cognos BI サーバに Cognos ScriptPlayer ユーティリティ経由でパブリッシュします。 モデルを作成するプログラム(create_model.cmd)の後に、Service Catalog データ マート リフレッシュの一部として実行する必要があります。 |
レポート可能として指定されたディクショナリおよびサービスは、Java プログラムによってデータ マートに入力されます。 プログラム アクティビティは、アプリケーション サーバの現在のログ ファイルに記録されます。
このプログラムは内部スケジューラ経由で実行されます。 スケジュールの設定は、インストール環境の一部として指定するか、newscale.properties ファイルを編集して変更します。 次のプロパティによってスケジューラが設定されます。 ETL(およびその他のプロセス)は毎日実行することを推奨します。 このジョブの実行中はデータ マートを使用できません。 ETL プロセスはトランザクション ロギングを行いながら実行されます。 トランザクション サイズ(FDR_ETL_RECORDS_PER_BATCH)を増やすことを推奨します。
#Enable ETL Process: 0 or 1 (1=Yes, 0=No) ENABLE_FDR_ETL_PROCESS=0 # FDR_ETL_TRIGGER : 1 for hourly, 2 for daily, 3 for minutes FDR_ETL_TRIGGER=1 #Frequency Hourly FDR_ETL_TRIGGER_FREQUENCY_HOURLY=5 #Daily Time HH:MM (22:30 for 10:30 PM) FDR_ETL_TRIGGER_FREQUENCY_DAILY=22:30 #Frequency in minutes FDR_ETL_TRIGGER_FREQUENCY_MINUTES=1 #Number of records per batch insertion FDR_ETL_RECORDS_PER_BATCH=500
Escalation Manager は、タスクがその運用レベル契約(OLA)を超過したかどうかをモニタリングします。 OLA を超過した場合、エスカレーションが設定されていれば、Escalation Manager はタスクが超過となってから、指定された時間が経過した後に適切な通知を送信します。
Escalation Manager は内部スケジューラ経由で実行されます。 スケジュールの設定は、newscale.properties ファイルを編集して調整できます。 デフォルトでは、Escalation Manager は月曜から金曜までの営業時間中に実行されるよう設定されています。
スケジュール設定は基本的に cron 式であり、必要なスケジュールを「秒 分 時 日 月 曜日」の形式で記述します。 たとえば、"0 0 12 ? * WED" という式は、「毎週水曜日の午後 12 時 00 分」を意味します。
Service Manager はタスク実行者がサービス要求を履行するために使用するモジュールです。
Service Manager を使用すると、ユーザは [フィルタ処理と検索(Filter and Search)] ポップアップ ウィンドウで一致する一連の条件を指定して、目的のタスクまたは要求を検索できます。 デフォルトで、これらの条件では Contains 演算子(たとえば、指定した文字列が名前に含まれるすべてのタスクを検索する機能)がサポートされません。
データベースに対してインデックス化されたクエリーが実行される確率を高めることで、このデフォルト動作でもパフォーマンスが最適化されます。 Contains クエリーを実行する機能をサポートすることは可能ですが、特に大規模なトランザクション データベースなどでは応答時間が最適でなくなる可能性があるため、管理者がこの設定を変更する場合には注意が必要です。 変更の取り消しは、Service Manager のカスタム ビューに影響を与えるため、お勧めしません。
Service Manager のユーザが Contains クエリーを指定できるようにするには、newscale.properties ファイルを編集して次のプロパティ設定を追加します。
# Service Manager will use this flag to control Contains Query in Datatable Filter and Search ContainsQueryInFnS=true
プロパティ ファイルに対するすべての変更と同様に、変更を反映させるためにはサービスを停止して再起動する必要があります。
インストール ログは、インストーラが呼び出されるたびに mmddyyyyhhmm というタイムスタンプ(010720111126 など)を使用して <APP_HOME>/logs フォルダに保存されます。
主なインストール ログを次に示します。
ファイル名 |
目次 |
---|---|
RC_Install |
全般的なインストール ログ。 |
RC_File |
ファイル システムに追加された、あるいはファイル システムから移動または削除されたファイルに関する情報。 |
RC_DbInstall |
データベースのインストールまたはアップグレード プロセス中に実行された SQL スクリプトおよび各スクリプトの実行にかかった時間に関する情報。 |
RC_Sql |
インストール中にデータベースで実行された SQL ステートメントのログ。 インストール中に SQL スクリプトでエラーが発生した場合は、このログが非常に有用な場合があります。ログには、エラーが発生したスクリプトのテキストが含まれ、そのエラーの具体的な内容が示されています。 |
インストール設定は RequestCenter/etc フォルダに記録されます。 今後の Service Catalog インストーラの呼び出しに備えてインストール設定が保存されるように、このフォルダを維持してください。
この設定は setup_options.txt ファイル内で参照できます。
Cisco Prime Service Catalog のシングル クラスタ構成のインストールでは、クラスタ内部のマルチキャスト通信が必要です。 各ノードが同じサブネット上にあるか、スイッチでサブネット間のマルチキャスト ルーティングが有効になっている必要があります。 また、ホスト サーバのネットワーク インターフェイス設定でマルチキャストを有効にする必要があります。
Service Catalog では、複数のマルチキャスト アドレスが使用されますが、これらのアドレスは一意にする必要があります。
ここでは、マルチキャスト接続をテストする方法を説明します。 次のようにして、Node1 が Node2 と通信できるかどうかチェックするテストを実行できます。
Node2 が Node1 と通信できるかどうかもチェックできます。
送信側を Node2、受信側をNode1 として、上記の手順(テスト)を繰り返します。
統合を管理するために、Service Catalog アプリケーションの設定をする際にシステム管理者がとるべき主な統合戦略については、『Cisco Prime Service Catalog Integration Guide』を参照してください。
システムでは複数の LDAP ディレクトリの統合が可能です。 2 つ以上の LDAP ソースのグループが、照会を通じて 1 つの LDAP システムとなります。 照会は、検索でのみサポートされており、バインディングではサポートされていません。 ディレクトリ統合の設定方法については、『Cisco Prime Service Catalog Integration Guide』を参照してください。
ディレクトリ統合を利用すると、統合アーキテクトは LDAP データ ソースに Service Catalog を接続し、個人プロファイル内の対応するフィールドにそのデータ ソースの属性をマッピングできます。 統合により、設計者は LDAP ルックアップをトリガーするイベントと、そのルックアップによって Service Catalog の個人プロファイルもリフレッシュするかを指定できます。 LDAP ルックアップをトリガー可能なイベントには次のようなものがあります。
ディレクトリ統合では、事前に設定されたこれらのイベントと動作に加えて、プログラマがカスタム ディレクトリ インターフェイスを実装して新しい検索機能の追加や検索ロジックの改良ができる API を提供します。
ディレクトリ データは次のような人員のプロファイルの要素にマッピングできます。
4 種類のマッピングを使用できます。
ロケールおよびタイム ゾーンがマッピングされていない場合は、Service Catalog がサーバ デフォルトを使用します。 また、オプション フィールドがマッピングされていない場合は、個人プロファイルで過去に生成された値がそのまま残ります。
カスタム マッピングは、『Cisco Prime Service Catalog Integration Guide』に記載されているパターン マッチング言語(正規表現)経由と Directory Integration API で提供されるインターフェイスに基づくカスタム プラグイン クラス経由で作成できます。
このようなマッピングはすべて、実装ごとに LDAP 統合ドキュメント内で文書化する必要があります。 Service Catalog インスタンスが移行またはアップグレードされた場合、マッピングに必要な Java クラスはすべてカスタマイゼーションとして扱われます。
Directory Integration API で提供されるインターフェイスを使用すると、ディレクトリ統合イベントによって提供される事前設定の動作をカスタム Java クラスが置き換えまたは補完できます。 インスタンスが移行またはアップグレードされた場合、このようなクラスはカスタマイゼーションとして扱われます。
さらに、カスタム クラスが JAR ファイルのサポートを必要とする場合は、これらをアプリケーション サーバにインストールし、カスタマイズとして扱う必要があります。 インストールの手順はアプリケーション サーバごとに異なります。
シングル サインオン機能は、ディレクトリ統合の一部として提供されます。 シングル サインオンに問題が発生した場合は、次の項目をチェックしてトラブルシューティングを開始します。
多くの環境で Windows 認証を使用しています。 IIS は統合 Windows 認証(IWA)をサポートし、ログインしたユーザの DOMAIN\UserName をパラメータとして渡します。
ISF は Cisco Prime Service Catalog サービス フォームに統合された JavaScript API です。 ISF を使用すれば、ユーザ クレデンシャル、過去にフォームに入力されたデータ、表示された要求のライフ サイクルなどの現在のコンテキストに基づいて、フォームのコンテンツや振る舞いを動的に変更できます。 ISF の詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。
ISF は、Service Catalog リポジトリに保存された JavaScript コードを補完する、アプリケーションまたは Web サーバに保存された JavaScript ライブラリの使用をサポートします。 このようなライブラリを使用する場合は、Service Catalog サイトをアップグレードまたは移行するときに、ライブラリをカスタマイゼーションとして扱う必要があります。
アクティブ フォーム コンポーネント内で使用できるデータ取得ルールにより、アプリケーションで外部リレーショナル データベースまたはアプリケーション データベースからデータを取得し、サービス フォームで使用することができます。 このようなデータは、フォームのフィールドへのデフォルト値の事前入力、ドロップダウン リストの生成、および詳細情報にドリルダウンする場合の値の動的入力に使用できます。 また、ユーザのデータ入力を外部データと照合することもできます。
外部データベースにアクセスするルールの場合は、対応する JEE データ ソースを作成する必要があります。 データ ソースの作成の手順については、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。 Service Catalog サイトをアップグレードまたは移行する場合、このようなデータ ソースはカスタマイゼーションとして扱われます。
Service Link は Integration Server または ISEE(Integration Server Enterprise Edition)とも呼ばれますが、これを使用すると Service Catalog で XML メッセージを使用して他のシステムに同期または非同期の要求を送信できます。 Service Designer で「外部」として設定されたタスクが、Service Link によって処理されます。
Service Link は基礎となるテクノロジーとして JMS キューを使用するので、JMS 設定に問題があると Service Link の動作に悪影響が出る可能性があります。 ほとんどの Service Link トラブルシューティングは、Service Link モジュールを使用して行うことができます。このモジュールには、送受信された個々のメッセージとそれらのメッセージを送受信するタスクをドリルダウンする機能が備わっています。
ここでは、Service Catalog のカスタマイズされたインストール用のシステムの設定と、以降のインストールまたはアップグレードでカスタム コンテンツが削除または上書きされないようにすることに関する情報を示します。
Service Catalog インストール ウィザードの詳細については、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。
Service Catalog インストール ウィザードは WAR を構築すると同時に、次の処理を行います。
展開手順では、WAR ファイル全体がサーバに展開されることが規定されています。 WAR ファイル全体が展開されると、WAR が前回展開されたディレクトリは削除され、そのディレクトリに存在したすべての Service Catalog カスタマイゼーションは失われます。
カスタマイズが失われないようにするために、Service Catalog インストール ウィザードではカスタム コンテンツがインストールに含まれるように指定できます。
手順
ステップ 1 | カスタム コンテンツを含むアーカイブを Zip 形式で作成します。 アーカイブのディレクトリ構造は展開ディレクトリの構造と一致させる必要があります。 |
ステップ 2 |
拡張インストール タイプを使用して 『Cisco Prime Service Catalog Installation and Upgrade Guide』の説明に従って、Service Catalog インストール ウィザードを実行します。 |
ステップ 3 | [アプリケーションサーバの設定(Application Server Configuration)] ページの [拡張オプション(Advanced Options)] をクリックします。 |
ステップ 4 | [拡張オプション(Advanced Options)] ダイアログボックスで、[カスタム コンテンツ(Custom Content)] を選択します。 |
ステップ 5 | [カスタムコンテンツのアーカイブ(Custom content archive)] に、アーカイブ名も含めたフル パスを入力するか、[参照(Browse)] をクリックしてカスタム コンテンツのアーカイブを探し、選択します。 |
ステップ 6 |
[Close(閉じる)] をクリックします。 『Cisco Prime Service Catalog Installation and Upgrade Guide』の説明に従って、インストールを続行します。
Service Catalog インストール ウィザードがインストールを完了する間、アプリケーションの展開ディレクトリ構造にカスタム コンテンツのアーカイブが抽出されます。 |
カスタマイズされたファイルはすべてカスタマイゼーション アーカイブに含まれている必要があります。 実装内のすべてのサイトで、次のようなカスタマイズされたファイルが必要な場合があります。
カスタマイズ可能なコンポーネント |
ディレクトリ/ファイル |
---|---|
カスタム スタイル シート、ヘッダー、フッター |
RequestCenter.war\custom\*\custom.css RequestCenter.war\custom\*\portal-custom-header.css RequestCenter.war\custom\*\images\ RequestCenter.war\custom\*\header.html、footer.html(カスタム スタイル シートがインストールされているすべてのディレクトリ) |
ISF ライブラリ |
RequestCenter.war\isfcode\* |
カスタム クラス |
RequestCenter.war\WEB-INF\classes\(ディレクトリ統合カスタマイゼーションに関連するクラスなどのカスタム クラス) |
手作業で編集されたプロパティ ファイル(このような変更もサイト固有のものである可能性があります) |
newscale.properties rcjms.properties integrationserver.properties newscalelog.properties |
シスコから提供される API 以外でデータベースを変更することはお勧めできません。 ただし、データベースに対して直接実行する必要のあるスクリプトもあります。
外部ディクショナリはデータベース テーブルとして保存されます。 このディクショナリを変更した場合は、DDL スクリプトを実行して対応するテーブルを修正する必要があります。
手動による実行が必要なパッチまたはホットフィックスの一部として、SQL スクリプトがカスタマー サポートから提供される場合があります。 ホットフィックスは、次の製品リリースに追加されるまではカスタマイゼーションとして扱い、ソフトウェア アップグレードまたは再インストールに含める必要があります。
通常、Service Catalog 実装は複数のサイトで構成され、それぞれのサイトが異なる役割を果たします。
サイト |
使用方法 |
---|---|
開発 |
サービス定義が開発され、単体テストが行われます。カスタマイゼーションが最初に適用されます。 |
テスト |
開発アクティビティから干渉されることのない、制御された環境。ここでは、品質保証または他の担当者が Service Catalog をテストします。 |
Production |
ユーザ コミュニティが Service Catalog からサービスを要求でき、IT チームがサービス要求を満たすことができる本番環境。 |
Catalog Deployer モジュールは、メタデータ(サービス定義)およびリポジトリに保存されている組織データ(人員、組織、および関連するエンティティ)の設定管理を行います。 詳細については、『Cisco Prime Service Catalog Designer Guide』で Catalog Deployer のマニュアルを参照してください。
次のように、展開中に 1 つのサイトから別のサイトに Service Catalog OLTP データベースをコピーできます。
1 つのサイトから別のサイトに Service Catalog OLTP データベースをコピーするには、次の手順を実行します。
ステップ 1 | 予測されるダウンタイムをユーザに通知します。 |
ステップ 2 | ソース環境の Service Catalog と Service Link のサービスを停止します。 |
ステップ 3 | ソース データベースをエクスポートします。 データのソースおよびエクスポートの日付を追跡できる命名規則を決定します。 |
ステップ 4 | システムのシャットダウンを実行できない場合は、Oracle エクスポートの -consistent フラグを使用します。 |
ステップ 5 | Service Catalog と Service Link のサービスを再起動します。 |
ステップ 1 | ターゲット環境の Service Catalog と Service Link のサービスを停止します。 | ||
ステップ 2 | ターゲット データベースの最新のバックアップ コピーがあることを確認します。 | ||
ステップ 3 | 必要に応じて、宛先からのエクスポート ファイルを、ターゲット データベース サーバにアクセスできるファイル システムにコピーします。 | ||
ステップ 4 | ターゲット データベースにデータをインポートします。
|
||
ステップ 5 | 両サイトが 2 つの異なる Cognos レポート サーバにアクセスしている場合は、各サイトの「CognosServer」の名前を指定する CnfParams テーブルのエントリを更新して、更新内容をコミットします。 | ||
ステップ 6 | ターゲット環境の Service Catalog と Service Link のサービスを再起動します。 | ||
ステップ 7 | プロパティを現在のサイトに設定します。 [Entity Homes] の指定が異なる場合、またはサイトの保護レベルが異なる場合は手動で変更を行い、変更を保存します。 |
||
ステップ 8 | 両サイトが 2 つの異なる LDAP ディレクトリに接続している場合は、ディレクトリ統合のデータ ソース定義を適宜変更します。 | ||
ステップ 9 | Service Link エージェントの接続プロパティをすべてチェックし、ターゲット環境に合わせて変更します。 | ||
ステップ 10 | 手作業での追加処理がある場合はそれを実行し、データを調整します。 たとえば、一部のユーザ、グループ、または組織に権限を追加したり、権限を取り消したりする場合があります。 | ||
ステップ 11 | メンテナンスが完了したことをユーザに通知します。 |
ここでは、サービス リンクの SSL の設定について説明します。
Service Link サービスの SSL の有効化には、次の作業が必要です。
VeriSign や Thawte のような既知の認証局によって署名された証明書を取得する場合は、これらの認証局のいずれかの署名者証明書を、ほとんどのクライアント プログラムがすでに認識しているという利点があります。
Service Link サービスに自己署名証明書を使用する場合は、Web インターフェイス経由で Service Link と通信するすべての外部システムと、署名者証明書を交換する必要があります。
たとえば、受信アダプタに http/ws アダプタを使用する Service Link エージェントに外部システムが応答メッセージを送信する場合、その外部システムは https URL 経由で Service Link に接続するクライアントとして機能するため、正しい SSL 接続を行うために信頼できるハンドシェイクを完了する方法を把握している必要があります。
そのためには、Service Link サービスで使用される証明書の署名者を外部システムが認識している必要があります。 このことを実現するため、外部システムの信頼できる認証局キーストアに Service Link の署名者証明書をインポートしておきます。 詳細については、この章の後半を参照してください。
(注) |
Service Link は、サーバとしては SSL ハンドシェイク時のクライアント証明書認証をサポートしていません。 |
Service Link の SSL を有効にすると、Service Link のセキュア ポートはオンになりますが、非セキュア ポートはオフになりません。 非セキュア ポートをオフにしない場合、外部システムは引き続き http URL 経由で Service Link と通信できます。 非セキュア ポートをオフにする場合は、Service Link サービスとのすべての通信で https URL を使用する必要があります。
Service Link サービスのセキュア ポートと非セキュア ポートの両方を使用して、ファイアウォール システムなどの別のメカニズムを介して非セキュア ポートへのアクセスを制御することができます。
たとえば、Two-JBoss-Server トポロジでは、Service Catalog アプリケーションが(別の JBoss サーバ上で動作している)Service Link サービスの「クライアント」でもあります。 実行時に、Service Catalog が URL の http://<SL_servername >:6080 を介して Service Link サービスに接続する必要があります。 非セキュア ポート 6080 が Service Link サービスに対してオフになっている場合は、https アドレス、つまり、https://<SL_servername >:6443 を介して Service Link に接続するように Service Catalog を設定する必要があります。
そこで、Service Link サービスの非セキュア ポート 6080 とセキュア ポート 6443 の両方をオンにするというシナリオが考えられます。 Service Catalog は、http://<SL_servername >:6080 を介して Service Link に接続できますが、他の外部システムは https://<SL_servername >:6443 を介して Service Link と通信する必要があります。 ファイアウォール システムを設定すると、すべての外部システムからのポート 6080 へのアクセスを拒否できます。
ここでは、アプリケーション サーバの非セキュア ポートをオフにする方法や、非セキュア ポート番号へのアクセスを拒否するようにファイアウォール システムを設定する方法については説明しません。 必要な情報を入手するには、システム管理者またはご使用のアプリケーション サーバのベンダーに問い合わせてください。
Service Link が Service Catalog とは別のアプリケーション サーバに展開されている場合(クラスタ化された WebLogic 環境や Two-JBoss-Server トポロジの場合)に、Service Link の SSL を有効にするには、Service Link が動作しているアプリケーション サーバの証明書とセキュア ポート番号のみを設定します。
Service Link サービスの保護に使用可能なデジタル証明書は入手済みであるとします。 この証明書は自己署名するか、または VeriSign のようなサードパーティ認証局から取得できます。 いずれの場合も、デジタル証明書はアプリケーション サーバからアクセス可能な Java キーストア(jks ファイル)にインポートする必要があります。 また、署名者証明書(証明書の公開キーとも呼ばれます)は、SSL モードで Service Link サービスと通信する外部システムに提供できるように、「Base64 エンコード ASCII」形式のファイルにエクスポートする必要があります。
(注) |
このマニュアルでは、キーストア ファイルの作成方法や Web サーバまたはアプリケーション サーバ用の証明書の要求方法は説明しません。 この項の手順では、Service Link が稼動しているアプリケーション サーバに対して SSL を有効にするために使用されるデジタル証明書を含むキーストア ファイルがすでに作成済みであるとします。 説明を容易にするため、使用するキーストア ファイルの名前は「slkeystore.jks」とします。 証明書は「servicelink」というエイリアスの下に格納されています。 このキーストア ファイルを開くためのパスワードは「slpassword」です。 |
さらに、「slsigner.cer」という名前のファイルに「Base64 エンコード ASCII」形式で署名者証明書がエクスポートされているものとします。 「Base64 エンコード ASCII」形式の例を以下に示します。
-----BEGIN CERTIFICATE----- MIICPDCCAaUCBE17w1cwDQYJKoZIhvcNAQEEBQAwZTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB MRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1NjYWxlMQswCQYDVQQLEwJRQTEVMBMG A1UEAxMMS2hhbmcgTmd1eWVuMB4XDTExMDMxMjE5MDI0N1oXDTIxMDMwOTE5MDI0N1owZTELMAkG A1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1Nj YWxlMQswCQYDVQQLEwJRQTEVMBMGA1UEAxMMS2hhbmcgTmd1eWVuMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDhTxg2RwarD6Wn4iqYeOOk3ykfXzZiDArf/X63omXquTmN0Up+mg6oJmPAfqJA l7k4+Dn7dfVtAc4h8qra7PBeBU48zrzRqZd6VAK07rz++CilQto64mHXYVomb5vWPGeKA41j9vlv ENj/tE/6++IqbwnxAqeZtY3EvEM7dcCWDwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAAaqCnfEAovy Uf2S+oAXYDo5N387a035APsz5iiUM5oiKR/KW3oRz/v0P0I/o3n312kDIJ01111pl6qpZRtPEsr1 b00Tu1cXfPmizEtz0ole606qDS+DzkS1+YYz2mLL2Zq40d1EPsMolyqyUmyq3GHaEnuhWemcv2aA wGFgbQYd -----END CERTIFICATE-----
ここでは、証明書ファイルをインストールする手順および各種アプリケーション サーバの SSL を設定する手順について説明します。
ステップ 1 | Service Link アプリケーションが稼働している JBoss サーバを停止します。 | ||
ステップ 2 | 「<JBOSS_DIR>\ServiceLinkServer\configuration」ディレクトリに「slkeystore.jks」ファイルをコピーします。ここで、<JBOSS_DIR> は、Service Link アプリケーションが展開される JBoss サーバのインストール ディレクトリです。 | ||
ステップ 3 | ファイル「<JBOSS_DIR>\ServiceLinkServer\configuration\standalone-full.xml」のバックアップを作成します。 テキスト エディタを使用してファイル「standalone-full.xml」を開きます。 特殊なキャリッジ リターン文字またはその他の書式設定文字をファイルに挿入しないテキスト エディタを使用してください。 | ||
ステップ 4 |
ファイル「standalone-full.xml」で次の行を検索します: 例: <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> その行のすぐ下に次の 3 行を挿入します: 例: <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true"> <ssl name="ssl" key-alias="servicelink" password="slpassword" certificate-key-file="../ServiceLinkServer/configuration/slkeystore.jks"/> </connector>
ファイル「standalone-full.xml」で次の文字列を検索します: 例: <socket-binding name="https" port= |
||
ステップ 5 | ポート番号の値を書き留めます。 これは、SSL モードで JBoss サーバによって使用されるセキュア ポート番号です。 | ||
ステップ 6 | Service Catalog アプリケーションが実行されている JBoss サーバを停止し、「<JBOSS_DIR>\ServiceCatalogServer\deployments\RequestCenter.war\WEB-INF\classes\config」ディレクトリに移動します。 | ||
ステップ 7 |
テキスト エディタを使用してファイル「newscale.properties」を開き、次のパラメータを検索します: 例: isee.base.url=
|
||
ステップ 8 | このパラメータの値を http://<hostname>:<nonsecure_port_number> から https://<hostname>:<secure_port_number> に変更します。 | ||
ステップ 9 |
ファイル「slsigner.cer」を「<JAVA_HOME>\jre\lib\security」ディレクトリにコピーします。ここで、<JAVA_HOME> は JDK 6 のインストール ディレクトリです。 ファイル「slsigner.cer」に CA 証明書が含まれていると仮定しています。 |
||
ステップ 10 | コマンド プロンプト ウィンドウまたはコンソール ウィンドウを開き、「<JAVA_HOME>\jre\lib\security」ディレクトリに移動します。 | ||
ステップ 11 |
次のコマンドを実行して、JDK 6 によって使用される信頼できる証明書キーストアに CA ルート証明書をインポートします。 例: <JAVA_HOME>\bin\keytool -import -trustcacerts -file slsigner.cer -alias servicelink -keystore cacerts -storepass changeit
|
||
ステップ 12 | ServiceCatalogServer と ServiceLinkServers の両方を起動し、管理者ユーザとして、または Service Link モジュールにアクセスできるユーザーとして Service Catalog URL に接続します。 | ||
ステップ 13 | Service Link のホームページを開き、「Service Link Status」のセクションで、接続が緑色のステータスであり、SSL アイコンとセキュア ポート番号の両方が表示されていることを確認します。 | ||
ステップ 14 | HTTP/WS アダプタを使用する Service Link エージェントに受信ドキュメントを送信する外部システムは、すべて次のように更新する必要があります: |
WebLogic 管理コンソールにアクセスできるユーザで次の手順を実行します。
ステップ 1 |
Service Link が動作している WebLogic マシンの「<JAVA_HOME>\jre\lib\security」ディレクトリに、証明書キーストア ファイル「slkeystore.jks」をコピーします。
<JAVA_HOME> が、WebLogic アプリケーション サーバが使用する正しい Java ディレクトリであることを確認してください。 「<WL_HOME>\common\bin」ディレクトリの下にある「commEnv.cmd」ファイル内の JAVA_HOME 設定を検索します(UNIX または Linux では「commEnv.sh」を検索します)。 例:set JAVA_HOME= C:\Program Files\Java\jdk1.7.0\ |
||||||||||||||||||||||
ステップ 2 | WebLogic 管理コンソールにログインし、[<ドメイン>] > [環境(Environment)] > [サーバ(Servers)] に移動します。 | ||||||||||||||||||||||
ステップ 3 | Service Link の WebLogic サーバの名前をクリックし、設定を開きます。それから [設定(Configuration)] >[キーストア(Keystores)] サブタブをクリックします。 | ||||||||||||||||||||||
ステップ 4 |
[キーストア(Keystores)] ページで次の値を入力します。
[Java標準トラストキーストアパスフレーズ(Java Standard Trust Keystore Passphrase)] については、「cacerts」キーストア ファイルのパスワードがまだデフォルト値の「changeit」であると仮定しています。 使用する環境で「cacerts」のパスワードが変更されている場合は、それを適切な値に置き換えてください。 |
||||||||||||||||||||||
ステップ 5 | [保存(Save)] をクリックしてから、[設定(Configuration)] > [SSL] サブタブをクリックします。 | ||||||||||||||||||||||
ステップ 6 |
[SSL] ページで次の値を入力します。
|
||||||||||||||||||||||
ステップ 7 | [保存(Save)] をクリックしてから、[設定(Configuration)] > [一般(General)] サブタブをクリックします。 | ||||||||||||||||||||||
ステップ 8 | [一般(General)] ページで次の値を入力します。 | ||||||||||||||||||||||
ステップ 9 | [保存(Save)] をクリックし、Service Link が展開されている WebLogic サーバを再起動します。 | ||||||||||||||||||||||
ステップ 10 |
ログ ファイル「<WL_servername>.out」に次のようなメッセージがあることを確認し、WebLogic サーバがセキュア ポート(9443)で起動したことを確認します。 例: <Notice> <Security> <BEA-090171> <Loading the identity certificate and private key stored under the alias hydra2 from the jks keystore file C:\jdk160_23\jre\lib\security\slkeystore.> <Notice> <Server> <BEA-002613> <Channel "DefaultSecure" is now listening on 192.168.21.72:9443 for protocols iiops, t3s, ldaps, https.> これで、Service Link サービスが SSL に対応しました。 |
||||||||||||||||||||||
ステップ 11 |
servicelink 証明書用の署名者証明書を含む「slsigner.cer」ファイルをすでに作成済みの場合は、このステップを省略します。 そうでない場合は、次の手順を実行して署名者証明書をエクスポートできます。 署名者証明書をエクスポートするには、いくつかの方法があります。次の手順は、Sun JDK 6 インストールに付属する「keytool.exe」ユーティリティを使用して証明書をエクスポートする方法の 1 つに過ぎません。 |
||||||||||||||||||||||
ステップ 12 |
Service Link サービスの非セキュア ポートを無効にする場合は、Service Link サービスと通信する外部システムを管理するシステム管理者に「slsigner.cer」ファイルを送信します。 その外部システムでは、2 つの設定を行う必要があります。
|
ステップ 1 |
Service Link サービスの非セキュア ポートを無効にするには、Service Catalog サービスの信頼できる Java 認証局キーストアに署名者証明書をインポートする必要があります。 これは、クラスタに属していない、独立した WebLogic サーバで Service Link が動作するためです (Service Catalog および Business Engine のみ、クラスタにインストールできます)。Service Catalog は、実行時に Service Link サービスに接続する「クライアント」として機能します。 |
ステップ 2 |
Service Catalog の信頼できる Java CA キーストアに署名者証明書をインポートするには、次の手順を実行します。
|
Service Link エージェントが HTTP/WS アダプタを使用して外部システムに送信メッセージを送信する場合、エージェントは外部 Web サーバに http 要求または Web サービス要求を送信するクライアントとして機能します。 外部 Web サーバが SSL 対応の場合、この Web サーバとセキュアな接続を確立するためには、Service Link にある設定が必要な場合があります。
(注) |
Service Link が複数の SSL 対応 Web サーバに接続している場合は、外部 Web サーバごとに 1 つずつの複数の署名者証明書をインポートする必要があります。クライアントとしての Service Link は、SSL ハンドシェイク時にクライアント証明書認証をサポートしません。 |
以降の項で、設定手順について詳しく説明します。
ステップ 1 | Service Link にアクセスできるユーザとして Cisco Prime Service Catalog にログインし、Service Link モジュールに移動して [統合の管理(Manage Integrations)] タブをクリックします。 |
ステップ 2 | 設定するエージェントを選択し、そのエージェントの [発信プロパティ(Outbound Properties)] ページを開きます。 |
ステップ 3 | [HttpOutboundAdapter.RoutingURL] フィールドで、https アドレスおよびセキュア ポート番号を入力します(たとえば、https://192.168.21.202:8444/HTTPSimulator/ など)。 |
ステップ 4 | [HttpOutboundAdapter.AcceptUntrustedURL] フィールドの値を [false] に設定して、セキュアな接続が行われるようにします。 |
ステップ 5 | [保存(Save)] をクリックし、[エージェントの制御(Control Agents)] タブを開いてエージェントを再起動します。 |
アプリケーション サーバ固有の手順を実行する前に、次の手順を実行する必要があります。
(注) |
外部 Web サーバ証明書の署名者が VeriSign や Thawte などの既知の認証局の場合は、Sun JDK で認識されている可能性が高いため、この手順を省略することができます。 |
-----BEGIN CERTIFICATE----- MIICPDCCAaUCBE17w1cwDQYJKoZIhvcNAQEEBQAwZTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB MRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1NjYWxlMQswCQYDVQQLEwJRQTEVMBMG A1UEAxMMS2hhbmcgTmd1eWVuMB4XDTExMDMxMjE5MDI0N1oXDTIxMDMwOTE5MDI0N1owZTELMAkG A1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1Nj YWxlMQswCQYDVQQLEwJRQTEVMBMGA1UEAxMMS2hhbmcgTmd1eWVuMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDhTxg2RwarD6Wn4iqYeOOk3ykfXzZiDArf/X63omXquTmN0Up+mg6oJmPAfqJA l7k4+Dn7dfVtAc4h8qra7PBeBU48zrzRqZd6VAK07rz++CilQto64mHXYVomb5vWPGeKA41j9vlv ENj/tE/6++IqbwnxAqeZtY3EvEM7dcCWDwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAAaqCnfEAovy Uf2S+oAXYDo5N387a035APsz5iiUM5oiKR/KW3oRz/v0P0I/o3n312kDIJ01111pl6qpZRtPEsr1 b00Tu1cXfPmizEtz0ole606qDS+DzkS1+YYz2mLL2Zq40d1EPsMolyqyUmyq3GHaEnuhWemcv2aA wGFgbQYd -----END CERTIFICATE-----
署名者証明書をインポートする手順は、Service Link が動作しているアプリケーション サーバ(JBoss 7.1.1 の設定、WebLogic 10.3.6(11g)の設定、または トラブルシューティング(Troubleshooting))によって異なります。
Service Link マシンの「管理者」ユーザとして、次の手順を実行します。
ステップ 1 | Service Link マシンの一時ディレクトリに(外部システムの)署名者証明書ファイルをコピーします。 たとえば、署名者証明書ファイルが「extws.cer」の場合は、このファイルを Service Link マシンの「C:\temp\extws.cer」にコピーします。 | ||
ステップ 2 | Service Link マシンのディレクトリ「<JAVA_HOME >\jre\lib\security」で、ファイル「cacerts」を見つけます。ここで、<JAVA_HOME > は Sun JDK 6 インストールのルート ディレクトリです。 このファイルは、Sun JDK 6 インストールに同梱されている、信頼できる CA キーストアです。 | ||
ステップ 3 | コマンド プロンプト ウィンドウまたはコンソール ウィンドウで次のコマンドを実行して、署名者証明書を「cacerts」キーストアにインポートします。 例: cd <JAVA_HOME>\jre\lib\security <JAVA_HOME>\bin\keytool -import -trustcacerts -alias extws –noprompt -file C:\temp\extws.cer -keystore cacerts -storepass changeit
|
||
ステップ 4 | Service Link サービスを再起動します。 |
WebLogic マシンの「ルート」ユーザ(UNIX と Linux の場合)または「管理者」ユーザ(Windows の場合)として、次の手順を実行します。
ステップ 1 |
Service Link サービスが稼働している WebLogic マシンの一時ディレクトリに(外部システムの)署名者証明書ファイルをコピーします。 たとえば、署名者証明書ファイルが「extws.cer」の場合は、このファイルを Service Link マシンの「/tmp/extws.cer」にコピーします。 クラスタ化された WebLogic 環境では、クラスタに属していない WebLogic サーバに Service Link を展開する必要があります。 したがって、必ず Service Link に適した WebLogic サーバを特定してください。 |
||
ステップ 2 |
Service Link マシンのディレクトリ「<JAVA_HOME>/jre/lib/security」で、ファイル「cacerts」を見つけます。ここで、<JAVA_HOME > は Sun JDK 6 インストールのルート ディレクトリです。 このファイルは、Sun JDK 6 インストールに同梱されている、信頼できる CA キーストアです。 <JAVA_HOME> が、WebLogic アプリケーション サーバが使用する正しい Java ディレクトリであることを確認してください。 これを行うには、「<WL_HOME>/common/bin」ディレクトリにある「commEnv.sh」(Windows の場合は「commEnv.cmd」)で、JAVA_HOME 設定を探します。 たとえば、JAVA_HOME="/opt/jdk1.6.0_23" などが該当します。 |
||
ステップ 3 |
コマンド プロンプト ウィンドウで次のコマンドを実行して、署名者証明書を「cacerts」キーストアにインポートします。 例: cd <JAVA_HOME>/jre/lib/security <JAVA_HOME>/bin/keytool -import -trustcacerts -alias extws –noprompt -file /tmp/extws.cer -keystore cacerts -storepass changeit
|
||
ステップ 4 | Service Link が展開されている WebLogic サーバを再起動します。 |
ここでは、送信電子メールを制限する方法、および電子メールの生成を制御する方法について説明します。 また、サポートに関するご質問や、システム環境およびエラー情報の追跡方法についてシスコに連絡する場合の情報も記載しています。
アプリケーション テンプレートをオーダーすると、オーケストレーション コンポーネントにより、[マイスタッフ(My Stuff)] の [コメントと履歴(Comments and History)] にテンプレート プロビジョニングの進行状況をトラッキングするためのオプションが表示されます。
(組み込みの)クラウド オーケストレーション サービスは、Prime Service Catalog の実行中に再起動されると、Prime Service Catalog に再接続し、AMQP のエクスチェンジを検出し、AMQP メッセージのモニタリングを再開します。
一方、Prime Service Catalog がクラウド オーケストレーション サービスの実行中に再起動されると、クラウド オーケストレーション サービスは Prime Service Catalog が実行を再開したときに再接続します。
(アプリケーション テンプレートの)オーダーが送信されると、クラウド オーケストレーション エンジン(Heat エンジン)がアプリケーション テンプレートのプロビジョニングを開始する前に、このエンジンのステータスがチェックされます。
(注) |
クラウド オーケストレーション エンジンはフォールト トレラントではありません。インフラストラクチャ テンプレートのプロビジョニング中にエンジンが停止すると、プロビジョニングは中断され、後でエンジンが再起動されても復旧できません。 |
クラウド オーケストレーション エンジンとオーケストレーション サービスの再起動
sudo service openstack-keystone restart sudo service openstack-heat-api restart sudo service openstack-heat-api-cfn restart sudo service openstack-heat-engine restart sudo service amqp-service restart sudo service psc-orchestration restart
ログ ファイル
次のトレースが一般的にモニタリングされます。
データベースの相互作用 |
com.newscale.bfw.udkernel.udsql.UdSqlBean com.newscale.bfw.udkernel.util.UdKernelUtil
|
LDAP の相互作用 |
com.newscale.bfw.ldap.jldap.JLDAPApi
|
クラスタリングの問題 |
com.opensymphony.oscache.plugins.clustersupport.AbstractBroadcastingListener com.opensymphony.oscache.plugins.clustersupport.JavaGroupsBroadcastingListener
|
サービス設計のテスト時や非本番環境では、送信電子メールを制限することがあります。
送信電子メール機能を制限することにより、実際の実行者やサービスをオーダーした顧客に対して電子メールの送信を制限したり、禁止したりすることができます。
開発環境ですべての電子メール テンプレートを「仮のアドレス」に変更することは、実際には行うべきではありません。 まず、これには非常に時間がかかります。 さらに重要なのは、テンプレート アドレスを元に戻したときに、多くのテストが無効になってしまう点です。このため、正しい受信者が適切な電子メールを受け取ることを確認する必要があります。
テンプレートで名前空間変数のみを使用し、非本番環境のユーザがディレクトリ統合によってリフレッシュされる場合は、LDAP マッピングを変更して、同じ電子メール アドレスまたは類似した仮のアドレスをユーザ全員に与えることができます。次に例を示します。
User@<company>.com または
reqcentertest@<company>.com
これには、次のようなマッピングを使用します。
expr:#cn#=(cannotmatch)?(neverthis):requestcenter@<company>.com
ただし、この方法でも、電子メールが正確に配信されることを十分にテストすることはできません。
より確実な対応策は、開発インスタンスや他のインスタンス専用に、電子メールがボックスの外部には配信されない SMTP(電子メール)サーバを使用することです。 開発サーバおよびテスト サーバに対して、(仮であるかどうかにかかわらず)すべての電子メールを標準メールボックス(rctestmailbox@company.com など)に配信する SMTP サーバを設定できます。 この方法では、Service Catalog 設定を変更する必要がないため、電子メールのテストが非常に簡単になります。 プロジェクト チームは、そのテスト メールボックスを開くことができるだけで十分です。
この方法では、受信者をオーバーライドしてテスト用の電子メール ボックスに転送する別個のテスト SMTP サーバをユーザが設定する必要があります。 本番環境では、本番 SMTP サーバを指定する必要があります。
この方法を使用する場合は、これらのフィールドの名前空間式や他のロジックをテスターが検証できるようにするために、宛先および CC のアドレスを <!-- Comment --> タグで囲んで電子メール テンプレートの HTML 本文に追加します。
Service Catalog では、送信電子メールのエンベロープが制御され、デフォルトで 1 つのメッセージが複数の受信者に送信されます。 複数受信者のメッセージが同じ SMTP サーバに送信されます。
代わりに、単一受信者の電子メールを送信すると、CPU とネットワーク帯域幅の使用率への悪影響を最小限に抑えることができます。 これは、newscale.properties ファイルの次の設定によって有効になります。
Email.One.Per.Recipient=true
この設定は、1 人の受信者が無効であるためにメッセージ全体が拒否される SMTP サーバの問題を避けるためにだけ使用します。
SMTP 接続は、10 回(デフォルト)試行され、Email.ServerDownCount プロパティで設定されます。 SMTP ホストへの接続再試行は Email.RescheduleOffset プロパティで指定された時間(ミリ秒)だけ一時停止されます。
加えて、設定限度を超えるように設定されたメールボックス、電子メール バウンスなどの配信に関する問題が発生した場合は、Email.RetryCount プロパティのデフォルト設定(現在のデフォルトは 4)に基づいて再試行されます。
環境マトリクスの例に示すようなマトリクスを使用して、使用している環境のシステムを文書に記録しておくことを推奨します。
シスコでは、各バージョンの Service Catalog が認定されているソフトウェアの詳細を示すサポート マトリクスを発行しています。 Cisco Technical Assistance Center(TAC)に、このマトリクスの最新バージョンが常に用意されており、各リリースおよびサービス パックに合わせて調整されています。
以下に影響する可能性のあるシステム メンテナンス作業を実施する前に、Cisco Technical Assistance Center(TAC)に連絡することができます。
ここでは、さまざまな状況でトラブルシューティング情報を収集する方法について説明します。
「Our Apologies」例外が発生した場合、Administration モジュールの [設定(Settings)] の [デバッグ(Debugging)] オプションでサイトの「デバッグ」をオンにすることができます。
[デバッグ(Debugging)] により、現在のページの URL がページ下部に追加されます。 URL をクリックすると、シスコのサポート担当者にとって有用な追加情報のリンクが表示されます。
終了したら、エンド ユーザを混乱させないよう、デバッグをオフにします。 また、パフォーマンスに悪影響を与える可能性もあります。
アプリケーション ログは、トラブルシューティングを行うための重要なメカニズムです。 このログで「例外」(ボトムアップ方式)を調べることにより、該当するエラー メッセージが見つかることがあります。
クラスタ化された環境では、クラスタ内のすべてのマシンで対象期間内のログ ファイルを参照すると効果的です。
Service Link サーバのログには、その日のすべての Service Link トランザクションの詳細が表示されます。 Business Engine と Service Link 間のインタラクションに関係する問題をトラブルシューティングする場合は、このファイルと Service Catalog サーバ ログを相互に関連付けると有用です。
ログおよび native_stderr.log ファイルからパフォーマンス情報を収集します。
サービス設計時に発生する問題は、誤ったサービス設定に関係していることがあります。 本番環境でのみ発生する問題は、データまたはプラットフォームに依存していることがあります。
Cisco Technical Assistance Center(TAC)から、データベースのダンプを送信するよう依頼されることがあります。このダンプをテスト ラボでインストールすることにより、エラーが発生した環境を正確にエミュレートできます。 顧客には、データベースをシスコ サポート サイトにアップロードして調査できるようにするためのログインおよび資格情報が必要です。
Cisco Technical Assistance Center(TAC)に連絡してください。
WebLogic では、ServiceLink アダプタのログ ファイルがデフォルトで有効にされません。 デフォルトでは、ServiceLink アダプタのすべてのロギングが WebLogic サーバの server.log ファイルに書き込まれます。
ここでは、ServiceLink のアダプタ ログ ファイルを有効にする設定手順について説明します。 この設定手順は、ユーザが ServiceLink WAR の展開後に手動で行う必要があります。
(注) |
この項は、Service Catalog Installer がインストール時に自動的に ServiceLink アダプタ ログ ファイルを設定する JBoss には適用されません。 |
ステップ 1 |
ServiceLink アプリケーションが展開され、WebLogic サーバで実行されている場合は、WebLogic サーバを停止します。 ServiceLink アプリケーションだけを停止することはできません。WebLogic サーバ全体を停止する必要があります。 ServiceLink アプリケーションを展開していない場合、ServiceLink ディレクトリに「ISEE.war」を抽出するまで以下の手順に従います (抽出された WAR 形式で ServiceLink を展開する必要があることに注意してください)。展開を開始する前に、抽出した ServiceLink ディレクトリで、このセクションで説明されている手順を実行します。 つまり、下記のステップ 3 でステージング ディレクトリの代わりに、抽出した ServiceLink ディレクトリに移動します。 |
||
ステップ 2 | ServiceLink WAR を展開したマシンにログインします。 | ||
ステップ 3 |
次のディレクトリに移動します。 <BEA_HOME>\user_projects\domains\<domain_name>\servers\<server_name>\stage\ServiceLink\WEB-INF\classes\config |
||
ステップ 4 |
テキスト エディタを使用して、次のようにファイル「newscalelog.properties」を変更します。
UNIX または Linux の場合: logger.directory=/opt/bea/user_projects/domains/mydomain/servers/server1/logs Windows の場合: logger.directory=C:/bea/user_projects/domains/mydomain/servers/server1/logs
|
||
ステップ 5 |
WebLogic サーバを起動します。
「server1.log」と同じディレクトリに、「isee.log」という新しいログ ファイルといくつかの追加のログ ファイル(ServiceLink アダプタごとに 1 ファイル)が存在しています。 |
ここでは、重大なエラー状態に関する情報を記載しています。 この情報は、個別のエラー メッセージに基づいて示されており、状態ごとに次の情報を示します。
ログの管理も参照してください。
Service Catalog および関連コンポーネントのエラー ログは、次の場所にあります。
コンポーネント |
エラー ログの場所 |
---|---|
アプリケーション サーバ(Application Server) |
|
WebLogic |
<BEA_HOME>/user_projects/domains/<domain>/servers/ <server>/logs/<server>.log |
JBoss |
<JBOSS_HOME>/ServiceCatalogServer/log, <JBOSS_HOME>/ServiceLinkServer/log |
Administration モジュールのサポート ユーティリティを設定してアプリケーション ログ ファイルへの GUI アクセスを有効にしている場合は、前述のログファイルを参照してダウンロードできます。
次のエラー状態は、エラー状態または関連するエラー メッセージに基づいて示されます。
エラー自体はシステム内のいくつかの異なるエラー状態が原因であっても、複数のエラー状態が同じシステム動作を引き起こすことがあります。 たとえば、LDAP サーバに接続できない場合、次に示すいくつかのエラー状態が該当することがあります。 発生しているエラーとエラー メッセージを一致させることが重要です。
すべてのエラーは、Service Catalog サーバ ログ ファイルに書き込まれます。このファイルの動作と場所については、上記の説明を参照してください。
カテゴリ |
説明 |
---|---|
エラー状態 |
Service Catalog は、要求の送信後またはサービス内の最終承認/確認後に、タスク計画を非同期にインスタンス化することができません。 |
エラー メッセージ |
Requisition xxx [Task “<name of task here >”]: We’re sorry but his approval/review cannot be completed at this time because the Service Catalog queue that processes these tasks is temporarily unavailable. Please try again later or contact your Service Catalog system administrator. |
解像度 |
非同期送信/最終承認プロセスを処理する JMS キューが、メッセージを受信するために使用可能かどうかを確認します。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
アプリケーション サーバでデータベースへの接続が失われました。 |
エラー メッセージ |
ERROR [com.celosis.logger.FatalerrorChannel] (8000)SQLException in getConnection:Could not create connection; - nested throwable: (java.sql.SQLException: [newScale][SQLServer JDBC Driver]Error establishing socket. Connection refused: connect); - nested throwable: (org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: [newScale][SQLServer JDBC Driver]Error establishing socket. Connection refused: connect)) Code: 0 State: null. |
解像度 |
RequestCenter データベースを確認します。 RequestCenter データベースが実行されていない場合は、起動します。 このデータベースが起動すると、アプリケーション サーバが自動的に接続されます。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー コード(Error Code) |
LDAPException 91. |
エラー状態 |
LDAP サーバに接続できません。 LDAP サーバが停止しているか、ポート番号が正しくない可能性があります。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPNonSSLConnection] LDAPException in NON-SSL Connection: LDAPException: Unable to connect to server <hostname>:<port> (91) Connect Error java.net.ConnectException: Connection refused: connect |
解像度 |
LDAP サーバが実行されているかどうかを確認します。 実行されていない場合は、LDAP サーバを起動します。 [管理(Administration)] > [ディレクトリ(Directories)] で LDAP システム接続パラメータを確認します。 Connection Port の値が正しいことを確認します。 Service Catalog アプリケーションを再起動する必要はありません。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー コード(Error Code) |
LDAPException 91 |
エラー状態 |
LDAP サーバに接続できません。 ホスト名が正しくない可能性があります。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPNonSSLConnection] LDAPException in NON-SSL Connection: LDAPException: Unable to connect to server <hostname>:<port> (91) Connect Error java.net.UnknownHostException: <hostname> |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] で LDAP システム接続パラメータを確認します。 LDAP Host の値が正しいことを確認します。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー コード(Error Code) |
LDAPException 32 |
エラー状態 |
LDAP サーバに接続できません。 認証済みユーザ ID が正しくない可能性があります。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPSimpleAuth] LDAPException in Simple Auth: LDAPException: No Such Object (32) No Such Object LDAPException: Matched DN: |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] で LDAP システム認証パラメータを確認します。 BindDN の値が正しいことを確認します。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー コード(Error Code) |
LDAPException 49 |
エラー状態 |
LDAP サーバに接続できません。 認証済みパスワードが正しくない可能性があります。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPSimpleAuth] LDAPException in Simple Auth: LDAPException: Invalid Credentials (49) Invalid Credentials |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] で LDAP システム認証パラメータを確認します。 [パスワード(Password)] フィールドは暗号化されているため、既存の値を確認できません。 パスワードの正しい値を入力して、[更新(Update)] をクリックします。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
LDAP サーバに接続できません。 |
エラー メッセージ |
FATAL [LDAPBase] LDAP instance cannot be created netscape.ldap.LDAPException: no host for connection (89) |
解像度 |
LDAP サーバが実行されているかどうかを確認します。 実行されていない場合は、LDAP サーバを起動します。 Service Catalog アプリケーション サーバを再起動する必要はありません。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
LDAP サーバに接続できません。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.LDAPQuery] LDAP netscape.ldap.LDAPException: failed to connect to server ldap://<hostname>:<port> (91) |
解像度 |
LDAP サーバが実行されているかどうかを確認します。 実行されていない場合は、LDAP サーバを起動します。 Service Catalog アプリケーション サーバを再起動する必要はありません。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー状態 |
LDAP サーバで認証に失敗します。 |
エラー メッセージ |
ERROR [com.newscale.comps.user.dao.LDAPUserDataSource] Single Person search failure, exception thrown: null com.newscale.bfw.dataaccess.DataAccessException |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] ページで [データ ソース設定(Data Source Configuration)] を確認します。 Service Catalog アプリケーション サーバを再起動する必要はありません。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
いずれかの必須属性のマッピングに誤りがあります。 そのため、LDAP サーバで個人を検索できません。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.LDAPQuery] LDAP java.lang.RuntimeException: Required LDAP attribute <attribute_name> is missing from the LDAP system. |
解像度 |
ディレクトリ データ マッピング内の属性名を修正します。 Service Catalog アプリケーション サーバを再起動する必要はありません。 |
カテゴリ |
説明 |
---|---|
エラー コード(Error Code) |
LDAPException 32 |
エラー状態 |
LDAP サーバでユーザのベース DN が見つかりません。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPApi] Referral Exception during Result Set iteration: LDAPException: No Such Object (32) No Such Object |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] ページで [LDAPシステムの認証パラメータ(LDAP System Authentication Parameters)] を確認します。 [LDAPユーザのベースDN(LDAP User BaseDN)] の値が正しいことを確認します。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー状態 |
(SSL 接続のみ)SSL 証明書のキーストアが作成されていないため、SSL モードで LDAP サーバに接続できません。 |
エラー メッセージ |
DEBUG [com.newscale.bfw.ldap.util.LDAPConfUtil] The LDAP configuration file “config/<LDAP_System>_TrustCertDB.keystore” does not exist. |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] ページで LDAP システムに適切なサーバ証明書を追加します。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー状態 |
(SSL 接続のみ)キーストアのサーバ証明書が正しくないため、SSL モードで LDAP サーバに接続できません。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPSimpleAuth] LDAPException in Simple Auth: LDAPException: I/O Exception on host <hostname>, port <port number> (91) Connect Error javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found |
解像度 |
証明書のキーストアはすでに存在していますが、この LDAP サーバで使用する正しい証明書が含まれていません。 LDAP サーバに使用する正しい証明書を取得し、[管理(Administration)] > [サイト設定(Site Configuration)] ページでその証明書を同じ LDAP システムに追加します。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー状態 |
[新しいユーザの共通OU(Common OU for new users)] の設定値が欠落しているか、RequestCenter データベースに存在しません。 |
エラー メッセージ |
ERROR [com.newscale.comps.user.dao.LDAPUserDataSource] Error getting Person from Ldap java.lang.NullPointerException at com.newscale.comps.user.dao.LDAPUserDataSource. transferOrgUnitVOToBO(LDAPUserDataSource.java:676) |
解像度 |
[管理(Administration)] > [サイト設定(Site Configuration)] ページで、[LDAPシステム検索設定(LDAP System Lookup Configuration)] をオンにします。 [新しいユーザの共通OU(Common OU for new users)] フィールドに正しい値を選択します。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
<attribute_name> のマッピングに誤りがあります。 このため、LDAP サーバで個人を検出できません。 |
エラー メッセージ |
WARN [com.newscale.bfw.ldap.jldap.JLDAPApi] Required LDAP attribute <attribute_name> is missing from the LDAP system, for DN : ... |
解像度 |
該当する LDAP システムに対して、[ディレクトリマッピング(Directory Mapping)] ページで属性名を修正します。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
いずれかの参照 LDAP システムに接続できません。 (設定フラグが SkipErrorOnLDAPSystem=true であるため、Service Catalog システムではこのエラーが無視されます)。 |
エラー メッセージ |
WARN [com.newscale.bfw.ldap.jldap.JLDAPApi] Referral Exception during Result Set iteration: LDAPReferralException: Search result reference received, and referral following is off (10) |
解像度 |
参照 LDAP サーバが実行されているかどうかを確認します。 参照 LDAP システムの認証と接続を確認します。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
外部データ ディクショナリ データベースに接続できません。 |
エラー メッセージ |
ERROR [STDERR] SQLException while attempting to connect: java.sql.SQLException: [Macromedia][SQLServer JDBC Driver]Error establishing socket. Connection refused: connect. |
解像度 |
外部データ ディクショナリ データベースを確認します。 外部データ ディクショナリ データベースが実行されていない場合は、起動します。 Service Catalog アプリケーションを再起動する必要はありません。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
データベースへの接続が失われました。 |
エラー メッセージ |
ERROR [com.celosis.logger.FatalerrorChannel] (8000)SQLException in getConnection: Could not create connection; - nested throwable: (java.sql.SQLException: [newScale ][SQLServer JDBC Driver]Error establishing socket. Connection refused: connect) |
解像度 |
データベースを確認します。 データベースが実行されていない場合は起動します。 このデータベースが起動すると、アプリケーション サーバが自動的に接続されます。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
外部データ ディクショナリ データベースに接続できません。 |
エラー メッセージ |
ERROR [com.newscale.bfw.udkernel.udsql.UdSqlBean] Message: [newScale][SQLServer JDBC Driver]Connection reset by peer: socket write error. |
解像度 |
外部データ ディクショナリ データベースを確認します。 外部データ ディクショナリ データベースが実行されていない場合は、起動します。 Service Catalog アプリケーションを再起動する必要はありません。 |
Universal Development Methodology(UDM)の標準処理では、サイトがオンラインになった時点で、実装されたサイトごとにこのマトリクスの列を完成させます。 通常、シスコの拡張サービスの成果物には、このマトリクスのソフト コピーが含まれており、管理者はそれを最新に保つ必要があります。
カテゴリ |
サイト名および使用法(開発など) |
---|---|
WebServer |
|
フロント ドア Cisco Prime Service Catalog のURL |
|
管理 Cisco Prime Service Catalog の URL |
|
Host1:ポート |
|
共有環境かどうか |
|
Hardware |
|
使用可能ディスク |
|
オペレーティング システム(Operating System) |
|
OS ログイン/パスワード |
|
WebServer タイプ/バージョン |
|
|
|
AppServer |
|
ホスト 1 |
|
共有環境かどうか |
|
Hardware |
|
使用可能ディスク |
|
オペレーティング システム(Operating System) |
|
サポート ログイン/パスワード |
rcsupport/rc |
インストーラ ログイン/パスワード |
requestcenter/rc |
RC パス |
/apps/rc |
RC.ear パス |
/apps/rc/RC.ear |
ISEE.war パス |
/apps/rc/ISEE.war |
ログ パス |
/logs/rc |
キュー接続ファクトリ |
RCQueueConnectionFactory |
BE 要求キュー |
BEEERequisitionsQueue |
BE 承認キュー |
BEEEAuthorizationsQueue |
BE 受信キュー |
BEEEInboundQueue |
JDK |
|
JDK パス |
/usr/local/java |
アプリケーション コンテナ |
|
タイプ/バージョン |
|
AppHost1 RC/SL JNDI のポート |
|
メール |
|
SMTP Server |
smtpserver.domain.com |
管理者の電子メール アドレス |
|
送信元の電子メール アドレス(From Email Address) |
ServicePortalDev@mailserver.company.com |
|
|
WebLogic |
|
コンソール URL |
|
ユーザ名/パスワード |
|
ノード名 |
|
アプリケーション サーバ(Application Server) |
RequestCenter |
仮想ホスト |
requestcenter_host |
|
|
サービス カタログ(Service Catalog) |
|
インストールされるコンポーネント |
すべて(All) |
マルチキャスト IP |
225.2.2.2 |
インストールされるビルド |
11.2.1.0151 |
Admin ログイン/パスワード |
|
カスタマイゼーション |
|
適用されるパッチ/ホットフィックス |
|
その他のカスタマイゼーション |
|
|
|
データベース |
|
Host1:ポート |
|
共有環境かどうか |
|
Hardware |
|
使用可能ディスク |
|
オペレーティング システム(Operating System) |
|
OS ログイン/パスワード |
|
DB タイプ/バージョン |
|
DB SID/データベース |
RQSTDEV |
テーブルスペース |
RequestCenter(GB 数) |
REDO ログ |
|
DB SA のユーザ名/パスワード |
sa/pwd |
DB RC スキーマ/パスワード |
RCUser/rc |
DB アプリケーションのユーザ名/パスワード |
|
|
|
アドバンス レポート |
|
Cognos ホスト:ポート |
|
Cognos ハードウェア |
|
使用可能ディスク |
|
Cognos OS |
Windows 2008 |
Windows ログイン/パスワード |
rcuser/c1$c0 |
Admin ログイン/パスワード |
admin/admin1234 |
サービス アカウント |
|
パス |
|
ゲートウェイ タイプ(Gateway Type) |
|
Web プロトコル |
|
|
|
データ マートおよびコンテンツ ストア |
|
JNDI 名 |
java:/DATAMARTDS |
DB タイプ/バージョン |
|
DB サーバ:ポート |
|
DB SID/名 |
RCDMDEV |
データ マートのユーザ名/パスワード |
DMUser/dm |
コンテンツ ストア SID/名 |
RCCSDEV |
コンテンツ ストアのユーザ名/パスワード |
CSUser/cs |
テーブルスペース |
RCDataMart(500M) |
Advanced Reporting のオプション |
|
ディクショナリ テーブル |
150 |
サービス テーブル |
50 |
ディクショナリ テーブル パターン |
DM_FDR_DICTIONARYTABLE_ |
サービス テーブル パターン |
DM_FDR_SERVICETABLE_ |
フィールド パターン |
FIELD |
ディクショナリのテキスト タイプ フィールド |
40 |
ディクショナリの数値タイプ フィールド |
10 |
ディクショナリの日付タイプ フィールド |
10 |
サービスのテキスト タイプ フィールド |
80 |
サービスの数値タイプ フィールド |
20 |
サービスの日付タイプ フィールド |
20 |
テキスト フィールドの最大サイズ |
200 |
更新に対する WDDX のリフレッシュ |
はい/いいえ(Yes/No) |
|
|
サービス リンク |
|
ホスト |
localhost |
キュー ホスト:ポート |
localhost:5099 |
ベース URL |
|
キュー接続ファクトリ |
RCQueueConnectionFactory |
送信キュー |
SLOutboundQueue |
受信キュー |
SLInboundQueue |
JMS キューのユーザ名/パスワード |
guest/guest |
JMS ファイル ストア(WLS 専用) |
ServiceLinkFileStore |
JMS ファイル ストア(WLS 専用) |
|
JMS サーバ |
RCServer |
LDAP |
|
サーバ タイプ(Server Type) |
|
LDAP 認証 |
シンプル |
SASL メカニズム |
— |
BindDN |
|
BindDN のパスワード |
|
接続メカニズム |
非 SSL |
SSL タイプ |
— |
LDAP ホスト |
|
接続ポート |
389 |
セキュア ポート |
— |
LDAP ユーザのベース DN |
|
オプションの LDAP フィルタ |
|
目次
この章は次のトピックで構成されています。
この章では、アプリケーション コンポーネントのスタートアップ手順とシャットダウン手順、推奨バックアップ プラクティス、アプリケーション コンポーネントの構成管理とカスタマイズ、継続的な保守タスク、および重要なエラー状態、エラー メッセージ、および解決方法について説明します。
(注) |
<APP_HOME> と指定されている場合は、Service Catalog がインストールされているルート ディレクトリを意味します。 |
Linux Puppet Master、Linux、および Windows のターゲット VM は、直接もしくはプロキシを介してインターネットにアクセスできる必要があります。 または、内部リポジトリに接続するよう VM を設定することもできます。
ゲートウェイ VM は(各ガイドで)説明されているとおりにトラフィックをルーティングするよう設定し、設定後は制限しないようにする必要があります。
(注) |
アプリケーションをインストールするためにターゲット VM のポートをクローズすることはお勧めしません。 ゲートウェイ VM のポートは『Cisco Prime Collaboration Quick Start Guide』の説明に従ってオープンできます。 |
SELinux にインストールされた Puppet Master をホスティングしている Linux VM では、デフォルトのインストールと設定によって、IPTables ルールとともに必要なポート(8140、8139、および 5150)がオープンされます。
Puppet Agent によって VM での ポート アクセスやセキュリティ プロトコルが変更されることはありません。 これらのデバイスを強化すると、関連アプリケーションのインストールまたは実行が失敗する可能性があります。 VM は UCSD のフェンスド コンテナに配置され、アプリケーション障害を回避するために、アクセスはゲートウェイ VM で制御されます。
完全に展開されたシステムのコンポーネントには、Service Catalog、Integration Server(Service Link)、およびAdvanced Reporting(Cognos)が含まれています。 Service Catalog および Integration Server はそれぞれ、Catalog.war および ISEE.war の各展開パッケージ内のアプリケーション サーバに展開されます。
(注) |
各コンポーネントは展開されているとおりにバックアップし、すべてのカスタマイゼーションは展開時または変更時に保存することを推奨します。 |
次のデータベースをバックアップする必要があります。
チューニングに関する次の推奨事項は、多くの Servce Catalog サイトに適用されます。 チューニングに関するこのほかの推奨事項については、各アプリケーション サーバのマニュアルを参照してください。
組織に遠隔地のユーザが多数いる場合は、HTTP 応答の GZIP 圧縮(RFC 1952)をオンにすると役立ちます。RFC 2616 の次のセクションを参照してください。
GZIP 圧縮は、低速または遅延の大きいネットワークを使用するユーザにとって有用です。 ただし、GZIP 圧縮により、サーバとユーザのブラウザにわずかながらオーバーヘッドが発生します。
GZIP 圧縮を有効にするには、以下を実行します。
ステップ 1 |
RequestCenter.war/WEB-INF で web.xml を探します。 たとえば、一般的な場所は次のとおりです。 例: |
ステップ 2 |
次のエントリを検索します(コメントアウトされています)。 例: |
ステップ 3 | コメントを削除します。エントリは次のようになります。 例: |
ステップ 4 | 次のエントリを検索します(コメントアウトされています)。 例: |
ステップ 5 | コメントを削除します。エントリは次のようになります。 例: |
ステップ 6 | ファイルを保存し、アプリケーション サーバを再起動します。 |
Java メモリ設定は、アプリケーション サーバが使用する Java 仮想マシン(JVM)専用の設定です。 "java -h" コマンドと "java -X" コマンドを使用すると、システムで使用可能なすべてのオプションのリストが返されます。 これらのコマンドを発行する場合は、ご利用中のアプリケーション サーバが使用する JVM と同じ JVM を呼び出していることを確認してください。
Service Catalog で「メモリ不足」エラーが発生する場合は、JVM で使用可能な最小および最大のヒープ サイズを管理する Java メモリ スイッチを調整しなければならない場合があります。 たとえば、次の設定は WebLogic に正しく適用されます。
MEM_ARGS="-verbose:gc -Xms1024m -Xmx1024m -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:MaxPermSize=256m"
キュー接続ファクトリの接続数は、JMS サーバの作業負荷に基づいて設定する必要があります。 1 つの Service Catalog インスタンスに推奨される設定は 25 です。 必要な接続数に関して、クラスタのサーバ数に基づいた厳格なルールはありません。 アプリケーション環境に最適な接続設定を実現するには、チューニング作業が必要となります。
JDK を新しいバージョンにアップグレードするには、次の手順を実行します。
Service Catalog データベースを設定およびチューニングする方法に関する主な FAQ のいくつかと、それらの質問への回答を示します。 これらの問題の詳細については、該当するデータベースに固有のマニュアルを参照してください。 これらの FAQ の多くは、SQLServer よりもチューニングの機会が多い Oracle に関するものです。
Oracle データベースのパフォーマンスは次の方法で最適化できます。
次のような設定を適用します。
パラメータ |
値 |
---|---|
perf.__large_pool_size |
16777216 |
*.processes |
300 |
*.pga_aggregate_target |
1059145600 |
*.sga_max_size |
716582400 # 内部で調整されます |
*.sga_target |
716582400 |
*.sort_area_size |
500000000 |
RequestCenter データベースのすべてのテーブルおよびインデックスに関する統計情報を収集するには、DBMS_STATS.GATHER_SCHEMA_STATS コマンドを使用します。 次の例では、"RC User" がスキーマの所有者です。
execute DBMS_STATS.GATHER_SCHEMA_STATS(ownname=>'RCUser',cascade=>TRUE);
「オプティマイザ統計情報の管理」に関する Oracle データベース管理の章では、次の点が推奨されています。
ヒストグラムレベルの統計情報の収集が不可欠なテーブルは、次のとおりです。
各テーブルの統計情報を収集する DBMS_STATS コマンドの例は、次のようになります。
BEGIN DBMS_STATS.GATHER_TABLE_STATS (OWNNAME => 'RCUser', TABNAME => 'TXACTIVITY', METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO'); END;
次のコマンドでスナップショットを有効にします。
ALTER DATABASE <database name> SET READ_COMMITTED_SNAPSHOT ON
揮発性の Service Catalog テーブルには特に、SQLServer DBCC Reindex コマンドを推奨します。 このプロセスは、勤務時間外で定期的にスケジュールする必要があります(一般的には週に 1 度)。
次に示すテーブルは最も揮発性が高く、DBCC Reindex の対象となります。
TxActivity TxActivityAssignment TxAttribute TxCheckList TxChecklistEntry TxComments TxCondition TxDictionaryHTMLBindings TxDocument TxEmailSent TxEventTrigger |
TxEventTriggerParam TxIncident TxInternalOptionList TxInvocation TxInvocationAttribute TxJMSMessage TxJoin TxMultivalue TxObjectDataHTML TxObjectDictionaries TxObjectRelation |
TxPerformerSummary TxProcess TxRequisition TxRequisitionEntry TxRequisitionStep TxRole TxRule TxSatisfaction TxService TxSubscription TxTimer |
Cognos は、すべてのレポートとキューの定義を ContentStore という名前のデータベースに格納します。 Cognos KnowledgeBase には、ContentStore のサイズ変更と維持に関するエントリが格納されます。 特に重要なのは、ContentStore に必要なサイズを算出するために、予測される使用状況の統計に基づいて発行される計算式です。
これらの計算式を組み込んだスプレッドシートは、Cisco Technical Assistance Center(TAC)から入手可能です。 次に例を示します。
コンポーネント |
推定値 |
ユニットあたりの領域(KB) |
合計(KB) |
---|---|---|---|
アクティブ ユーザ数 |
250 |
|
|
レポートを実行する同時ユーザ数(一時ディスク領域要件) |
50 |
100,000 |
5,000,000 |
保存されたレポート 1 ~ 10 ページ(1 ユーザにつき 2、Public 1、MyFolder 1) |
500 |
340 |
170,000 |
保存されたレポート 10 ~ 100 ページ(1 ユーザにつき 9、Public 4、MyFolder 5) |
2250 |
440 |
990,000 |
保存されたビュー 1 ~ 100 行(1 ユーザにつき 3、すべて MyFolder) |
750 |
250 |
187,500 |
保存されたビュー 100 ~ 1000 行(1 ユーザにつき 8、すべて MyFolder) |
2000 |
350 |
700,000 |
フォルダ Public MyFolder(1 ユーザにつき 5) |
1,250 |
|
0 |
FrameMaker モデル(シスコが提供) |
|
|
20,000 |
空のコンテンツ ストア |
1 |
3,000 |
3,000 |
アクティブ スケジュール(50 日 + 125 週) |
175 |
30 |
5,250 |
合計(Total) |
|
|
7,075,750 |
トランザクション データベースは、プレフィックス命名規則を採用した一連のリレーショナル テーブルで構成されます。 次の表は、DBA または本番データベースの保守やチューニングを行う必要がある人への支援として示されています。 これらのテーブルの構造およびコンテンツの所有権はシスコに帰属します。シスコでは、リリースごとにテーブルの名前または構造を自由に変更する権利を留保します。
プレフィックス |
意味 |
使用方法 |
---|---|---|
Cnf |
設定 |
Service Catalog が使用する内部設定情報が含まれるテーブル。一般的に、これらのテーブルは小さく、そのコンテンツは本番環境内でスタティックです。 |
Co |
ポータル コンテンツ |
Portal Manager のコンテンツとページの定義が含まれるテーブル。 |
Def |
定義 |
サービス フォーム、ディクショナリ、チェックリストなど、ユーザが設定可能なオブジェクトのユーザ定義を保持するテーブル。テーブル サイズは実装のサイズによって異なりますが、本番環境では比較的安定しています。通常は、Catalog Deployer の使用を介してのみ変更されます。 |
Dir |
ディレクトリ |
個人および組織の情報を格納するテーブル。ほとんどの場合、テーブル サイズはきわめて小さく(スキル、プロジェクト、役職)、安定しています。個人に関係するテーブルは、組織の規模によって大きく異なります。 |
JMS |
Java Message Service |
内部で使用。 |
Mdr |
メタデータ リポジトリ |
(ユーザー定義の)動的スキーマ(サービス項目、標準、ポータルなど)を使用したテーブルのメタデータを含むテーブル。 |
Si |
サービス項目(Service Item) |
サービス項目のデータを格納するテーブル。 |
St |
標準(Standards) |
標準のデータを格納するテーブル。 |
TX |
トランザクション |
すべてのトランザクションを格納するテーブル。 テーブルが非常に大きくなる可能性があります。テーブルのデータは揮発性です。 |
Uc |
ユーザ コンテンツ |
Portal Manager のカスタム コンテンツを格納するテーブル。 |
UI |
ユーザ インターフェイス |
Service Manager のビュー、ログイン時に表示されるデフォルト モジュール、Service Link フィルタなど、ユーザ インターフェイスに関するユーザ固有のカスタマイゼーションを定義するテーブル。 |
Xtr |
外部 |
Service Link が外部タスクの管理に使用するテーブル。定義テーブル(XtrDef)は非常に小さい場合がありますが、外部タスクのメッセージを格納するテーブルは規模が大きく、急速に肥大化します。 |
XtrEUI |
外部エンド ユーザ統合 |
ディレクトリ統合の定義に使用されるテーブル。 |
分割と消去を通してパフォーマンスを最適化できます。
履歴要求分割機能は、完了した要求(ステータスが「クローズ」、「キャンセル」、「配信キャンセル」、または「拒否」の要求)を履歴トランザクション テーブルに移動します。 履歴要求分割を使用すると、現在のトランザクション テーブルのデータ量が削減されることにより、アプリケーション全体のパフォーマンスが向上します。 この向上は、Service Manager、My Services、および Service Link の各モジュールにおけるタスク、要求、および外部メッセージのフィルタ処理や検索で確認できます。 ETL と要求ワークフロー処理は、現在のトランザクション テーブル内のデータが減少することからも恩恵を受けます。
履歴要求分割は、Administration モジュール内のシステム設定 [履歴要求スケジューラの有効化(Enable Historical Requisitions Scheduler)] によって制御されます。 これが有効になっている場合は、365 日を超えて完了した要求がバックグラウンド プロセスによって履歴トランザクション テーブルに移行されます。 365 日の保存期間は変更可能であり、組織の特定のニーズに合わせて変更できます。
スケジューラが無効になっている場合は、[管理(Administration)] > [ユーティリティ(Utilities)] ページで履歴要求の移行プロセスを一時的に実行することができます。
そのため、My Services と Service Manager の両方の要求ビューが [最近(Recent)] ビューと [履歴(Historical)] ビューに分割されています。 履歴トランザクション テーブルに移行された要求は、[履歴要求ビューの有効化(Enable Historical Requisitions View)] システム設定を選択することによってアクセス可能にできます。 これらの要求は、[マイサービス(My Services)] > [要求(Requisitions)] ページの [履歴(Historical)] タブだけでなく、Service Manager の [履歴要求(Historical Requisitions)] ビューにも表示されます。 UI 経由で履歴要求に関連付けられたタスクや外部メッセージを確認することはできませんが、データは Service Catalog データベースに保存されます。
初めて履歴要求の移行を行う際には、多くの場合、大量のデータを扱います。 アプリケーション ユーザへの影響を軽減するため、オフピーク期間に Administration モジュールから手動でこのプロセスを実行します。
Administration モジュールに移動し、[履歴要求のスケジューラを有効にする(Enable Historical Requisitions Scheduler)] の設定がオフになっていることを確認します。 [ユーティリティ(Utilities)] で、[プロセスの実行(Run Processes)] を開いて目的の締切日を入力します。 任意で、処理する要求のバッチ サイズと最大数を指定します。
バッチ サイズを大きくすると処理時間が短縮されますが、データベース サーバにはより大きな一時領域またはロールバック セグメントが必要になります。 要求の最大数を設定するか、[停止(Stop)] をクリックすると、履歴要求の移行プロセスの時間を制限することができます。 処理の速度と時間は、要求の平均サイズによって異なります。
(注) |
移行プロセスを実行する前に、データベース管理者と協力してリハーサルを行い、初回の実行にかかる時間を推定しておくことを推奨します。 |
履歴トランザクション データは、Reporting 用の ETL プロセスでは抽出されません。 履歴要求分割機能を設定する場合は、次の点を考慮してください。
次の設定は履歴要求分割に適用されます。
reqArchival.poller.enable:アプリケーション インスタンスを使用して履歴要求移行プロセスを実行できるかどうかを制御します。 クラスタ化された Service Catalog 環境では、常に、1 つのノードだけを使用して移行プロセスが実行されます。 サーバが性能の低いマシンの場合やサーバが災害復旧用の場合は、1 つ以上のノードでこのプロパティが "false" に設定されることがあります。
上記ファイル内のその他の設定は、通常の環境では変更しないでください。
Service Catalog には、選択した日付よりも古いトランザクションまたはユーザが指定したその他の条件を満たすトランザクションを削除するトランザクション消去機能があります。 これを使用すると、アプリケーション管理者はテスト ユーザやサンプル サービスを削除する前にテスト要求を削除することができます。 ただし、消去機能では大量データの消去は実行できません。 また、メンテナンス フェーズが長引かないようにする必要があります。
ステップ 1 | 消去スクリプトを実行する前に RequestCenter データベースをバックアップします。 | ||
ステップ 2 | 消去スクリプトを実行するときは、Service Catalog および Service Link サービスを停止します。 | ||
ステップ 3 |
次の場所でユーティリティを探します。 <APP_HOME>\schema\util\purge <APP_HOME> が存在するマシンにデータベース クライアント ソフトウェアがある場合は、そのマシンから消去スクリプトを実行できます。 そうでない場合は、RequestCenter データベースのあるマシン、または前提条件となるデータベース クライアントのある別のマシンに purge フォルダ全体をコピーします。 |
||
ステップ 4 | 次のファイルが purge フォルダに含まれていることを確認します。 | ||
ステップ 5 |
Windows オペレーティング システムの場合は .bat ファイル、UNIX または Linux オペレーティング システムの場合は .sh ファイルを実行します。
|
常に同じフィルタ条件を使用して要求を消去する場合(たとえば、キャンセルされた要求をすべて消去するなど)、この手順は不要です。 ただし、混乱を避けるために前回の実行からの条件を最初にクリアすることをお勧めします。
1 つまたはすべてのフィルタ条件をクリアするには、ClearAllPurgeFilter スクリプトを使用します。 [Purge Filter Name ] が指定されていない場合は、RequestCenter データベースの CnfPurgeFilter テーブルのフィルタ エントリがすべて削除されます。 そうでない場合は、[Purge Filter Name ] が CnfPurgeFilter テーブルに存在すれば指定されたフィルタのみが削除されます。
Oracle:
ClearAllPurgeFilter ORACLE [SID ] [User ] [Password ] [Purge Filter Name(オプション)]
SQL Server:
ClearAllPurgeFilter SQLSERVER [Server ] [Database ] [User ] [Password ] [Purge Filter Name(オプション)]
オプションの [Purge Filter Name ] に指定可能な値は次のとおりです。
1 つまたは複数のフィルタ条件を追加するには、AddPurgeFilter スクリプトを使用します。 要求が削除されるのは、すべての消去条件を満たす場合のみです。 フィルタ条件は RequestCenter データベースの CnfPurgeFilter テーブルに保存されます。
データベースのタイプに合わせて次の構文を使用します。
Oracle:
AddPurgeFilter ORACLE [SID ] [User ] [Password ] [Purge Filter Name ] [Purge Filter Value ]
SQL Server:
AddPurgeFilter SQLSERVER [Server ] [Database ] [User ] [Password ] [Purge Filter Name ] [Purge Filter Value ]
消去フィルタ名 |
説明 |
消去フィルタ値 |
||||
---|---|---|---|---|---|---|
CREATIONSTARTDATE |
この日付以降に作成された消去要求。 |
DD-MON-YYYY 形式の日付。 |
||||
CREATIONENDDATE |
この日付以前に作成された消去要求。 |
DD-MON-YYYY 形式の日付。 |
||||
CLOSEDSTARTDATE |
この日付以降にクローズされた消去要求。 |
DD-MON-YYYY 形式の日付。 |
||||
CLOSEDENDDATE |
この日付以前にクローズされた消去要求。 |
DD-MON-YYYY 形式の日付。 |
||||
REQUISITIONSTATUS |
指定されたステータスの消去要求。 |
可能な値は、PREPARATION、OPEN、ONGOING、CLOSED、CANCELLED、REJECTED、DELIVERY CANCELLED、ORDERED、または ALL です。 |
||||
REQUISITIONID |
要求 ID に基づいて特定の要求を消去します。 |
要求に割り当てられた固有の番号。 |
||||
REQUISITIONRANGE |
要求 ID 範囲に基づいて特定の要求を消去します。 |
開始要求 ID と終了要求 ID、およびその間にダッシュ記号(例:30001-39999)。 |
||||
SERVICEID |
サービス ID に基づいて、特定のサービスを含む要求を消去します。 |
サービスの固有識別子。サービス定義のため、Service Designer の [一般(General)] ページに表示されます。 |
||||
SERVICENAME |
サービス名に基づいて、特定のサービスを含む要求を消去します。 SERVICEID および SERVICENAME フィルタの場合は、すべてのサービス要求を含め、要求全体が削除されます。 個々のエントリ(サービス)レベルではなく、要求レベルで消去が行われます。 |
"Email Service" など、二重引用符で囲まれたサービス名。
|
要求を消去する前に、任意で「リハーサル」を実行して、実際に削除することなく、消去される要求をチェックできます。 これは、フィルタ条件を検証する役割を果たします。
フィルタ条件を満たす要求のリストを表示するには、PurgeRequisitions スクリプトを使用します。
Oracle:
PurgeRequisitions ORACLE [SID ] [User ] [Password ] DRY_RUN [UserName]
SQL Server:
PurgeRequisitions SQLSERVER [Server ] [Database ] [User ] [Password ] DRY_RUN [UserName]
UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。
リハーサルで検出された要求のリストは、RequestCenter データベースの LogPurge テーブルに保存されます。 ログ エントリは実行ごとに RunID が 1 ずつ増分されてテーブルに追加されます。 最も大きい RunID を指定して LogPurge テーブルのエントリをクエリーすると、消去される要求を確認できます。
リハーサルや要求の消去を何度も実行すると、時間とともに LogPurge テーブルが急速に大きくなる可能性があります。 したがって、定期的に LogPurge テーブルを手動で切り捨て、以前の実行のエントリを削除することを推奨します。
ステップ 1 から 3 を繰り返すと、消去条件を修正できます。 消去フィルタ条件が確定したら、実際の要求消去に進むことができます。
要求消去を行うと、タスクと Service Link メッセージを含め、消去フィルタ条件を満たす要求とそれらの要求に関連付けられたすべてのトランザクション データが削除されます。
RequestCenter データベースの LogPurge テーブルには実際の要求消去の結果も追加されます。 実際の要求消去を実行するには、次に示すように、PurgeRequisitions コマンドに PURGE パラメータを指定して使用します。
Oracle:
PurgeRequisitions ORACLE [SID ] [User ] [Password ] PURGE [UserName]
SQL Server:
PurgeRequisitions SQLSERVER [Server ] [Database ] [User ] [Password ] PURGE [UserName]
UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。
ワークフロー消去ユーティリティを使用すると、ワークフロー処理に関連するデータベースから一時データが削除されます。 これらのデータが本番環境で使用されなくなった場合は、これらを削除すればデータベースのサイズを小さくすることができます。 また、消去ユーティリティを定期的に実行すると、全体的なパフォーマンスが改善される可能性があります。
ワークフロー消去ユーティリティは、RequestCenter データベースのストアド プロシージャの形式で提供されます。 データベースの規模が大きい場合、消去ユーティリティの実行には 1 時間以上かかる場合があります。 このため、システムのダウン時またはアクティビティが少ない時間帯に消去を行う必要があります。 データベースでスクリプトの実行にかかる時間を確認するために、サンドボックス環境でのテスト実行が推奨されます。
消去の開始/終了時間を追跡するには、ストアド プロシージャを実行する前に SQL ツールで print ステートメントを表示する設定を有効にします。
ステップ 1 | RequestCenter データベースをバックアップします。 |
ステップ 2 | データベースに対応するクエリー ツール(SQL*Plus など)を使用して、RCUser として RequestCenter データベースに接続します。 |
ステップ 3 |
次のコマンドを実行します。
日付は、DD-MON-YYYY 形式である必要があります。 UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。 実行の終了時に、総経過時間が表示されます。 次に出力の例を示します。 例: Creation/Data population of TxReq_temp- Successful Time taken for TxReq_Temp : .17 s Creation/Data population of TxReqEntry_temp- Successful Time taken for TxReqEntry_Temp : .08 s Creation/Data population of TxSubscription_Temp - Successful Time Taken for TxSubscritpion : 5.39 s Creation/Data population of TxProcess_Temp - Successful Creation/Data population of TxJoin_Temp - Successful Time Taken for TxJoin : .91 s Creation/Data population of TxCondition_Temp - Successful Time Taken for TxCondition : 1.18 s Creation/Data population of TxActivity_Temp - Successful Creation/Data population of TxEventTrigger_Temp - Successful Creation/Data population of TxEventTriggerParam_Temp - Successful Time Taken for TxEventTriggerParam : .33 s ***Creation/Data population of TxEventTrigger - Successful*** ***Creation/Data population of TxProcess - Successful*** Creation/Data population of XtrChannelInfo_Temp - Successful Creation/Data population of XtrChannelParameterSpec_Temp - Successful ***Creation/Data population of XtrChannelParameterSpec - Successful*** Elapsed time: 10.62 s PL/SQL procedure successfully completed. |
ステップ 1 | RequestCenter データベースをバックアップします。 |
ステップ 2 | データベースに対応するクエリー ツール(SQL Server Management Studio など)を使用して、RCUser として RequestCenter データベースに接続します。 |
ステップ 3 |
makecall ディレクトリで、次のコマンドを実行します。★クライアント指示により、原文と異なる訳文に変更★
日付は、DD-MON-YYYY 形式である必要があります。 UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。
実行の終了時に、総経過時間が表示されます。 次に出力の例を示します。 例: (2258 row(s) affected) Creation/Data population of TxReq_Temp- Successful Time taken for TxReq_Temp : 0 s (2639 row(s) affected) Creation/Data population of TxReq_Temp- Successful Time taken for TxReqEntry_Temp : 0 s (56580 row(s) affected) (0 row(s) affected) (56580 row(s) affected) Creation/Data population of TxSubscription_Temp - Successful Time taken for TxSubscription_Temp : 6 s (4551 row(s) affected) (2 row(s) affected) Creation/Data population of TxProcess_Temp - Successful Time taken for TxProcess_Temp : 0 s (4154 row(s) affected) (0 row(s) affected) (4154 row(s) affected) Creation/Data population of TxJoin_Temp - Successful Time taken for TxJoin_Temp : 1 s (9382 row(s) affected) (9382 row(s) affected) Creation/Data population of TxCondition_Temp - Successful Time taken for TxCondition_Temp : 2 s (7017 row(s) affected) Creation/Data population of TxActivity_Temp - Successful Time taken for TxActivity_Temp : 0 s (5528 row(s) affected) Creation/Data population of TxEventTrigger_Temp - Successful Time taken for TxEventTrigger_Temp : 0 s (1202 row(s) affected) Creation/Data population of TxEventTriggerParam_Temp - Successful Time taken for TxEventTriggerParam_Temp : 0 s (5528 row(s) affected) ***Creation/Data population of TxEventTrigger - Successful*** (1202 row(s) affected) ***Creation/Data population of TxEventTriggerParam - Successful*** (4553 row(s) affected) ***Creation/Data population of TxProcess - Successful*** (645 row(s) affected) Creation/Data population of XtrChannelInfo_Temp - Successful Time taken for XtrChannelInfo_Temp : 0 s (8409 row(s) affected) (8409 row(s) affected) ***Creation/Data population of XtrChannelParameterSpec - Successful*** Elapsed time: 11 s |
Service Link メッセージ消去ユーティリティは、データベースから Service Link メッセージを削除します。
これらのメッセージは(サービス フォームの複雑さおよびエージェントの設定に使用されるコンテンツ タイプ オプションに応じて)きわめて大きくなる可能性があるため、メッセージを削除することにより、Service Link 関連のデータを保持するために必要なデータベース サイズが大幅に削減されます。 外部メッセージは変更されないままです。
ステップ 1 | RequestCenter データベースをバックアップします。 |
ステップ 2 | データベースに対応するクエリー ツール(SQL*Plus など)を使用して、RCUser として RequestCenter データベースに接続します。 次のコマンドを実行します。 SET SERVEROUTPUT ON EXECUTE sp_CleanupSlMessageContent( [FromDate], [ToDate], [UserName]); 日付は、DD-MON-YYYY 形式である必要があります。 UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。 実行の終了時に、消去されたメッセージの総数および総経過時間が表示されます。 次に出力の例を示します。 例: Updating messages with MessageStateID 2 (completed) or 3(failed) that are older than 100 daysDone updating 3200 messagesScript Start Time 07/06/2011 02:07:11 and script End Time07/06/2011 02:09:11 |
ステップ 1 | RequestCenter データベースをバックアップします。 |
ステップ 2 |
データベースに対応するクエリー ツール(SQL Server Management Studio など)を使用して、RCUser として RequestCenter データベースに接続します。 次のコマンドを実行します。 EXECUTE sp_PurgeWorkflowTables [FromDate], [ToDate], [UserName] 日付は、DD-MON-YYYY 形式である必要があります。 UserName は、スクリプトを実行するユーザの Service Catalog のログイン名です。 実行の終了時に、総経過時間が表示されます。 次に出力の例を示します。 例: Purge messages with MessageStateID 2 (completed) or 3 (failed) Done updating 1500 messages Script Start Time Jul 6 2011 2.57 PM and script End Time Jul 6 2011 3.57 PM |
配信できなかった電子メール通知は確認または再試行のためにアプリケーション内で保持されます。 削除または再送信するには、Administration モジュールに移動して、[ユーティリティ(Utilities)] で [不達電子メール(Undelivered Emails)] タブを探します。 情報が無効になっているメッセージは削除し、SMTP の一時的な障害が原因で配信されなかったメッセージは再送信します。
管理者はこのアプリケーション ページを定期的に訪問して再送信が必要なメッセージを確認することをお勧めします。 バックログ内に大量のメッセージが残っていると、電子メール通知プロセスが大幅に減速する可能性があります。
ここでは、アプリケーションの保守、WebLogic の管理、および JBoss について説明します。 また、データ ソースの使用と外部データ ディクショナリの「補助テーブル」の作成、キャッシュされたデータ、アプリケーションのセキュリティ、パッチの適用、およびマルチキャスト設定に関する情報も示します。
JBoss アプリケーション サーバを使用した一般的なインストールでは、コマンド ラインまたは設定されていれば Windows サービスから、アプリケーション サーバとともに Cisco Prime Service Catalog を起動および停止できます。
WebLogic の起動方法については、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。
通常の Service Catalog 動作中は、管理サーバを再起動する必要はありません。 ただし、インストール時にカスタム データベース ドライバをインストールする場合には再起動が必要です。
展開に関する詳細を参照する必要がある重要なファイルを次に示します。 このマニュアルに明記されているか、Cisco Technical Assistance Center(TAC)からの指示がないかぎり、プロパティ ファイルと、類似の設定ファイルはすべて読み取り専用だと見なしてください。 これらのプロパティ ファイルのいずれかを変更した場合は、サービスを再起動する必要があります。
ファイル |
説明 |
---|---|
newscale.properties |
このファイルは、インストールまたはアップグレード プロセス中、およびインストーラが実行されるたびに、インストーラによって作成されます。 インストーラによってファイルが作成されると、「RequestCenter.war\WEB-INF\classes\config」フォルダに保存されます。 そのため、.ear ファイルが再展開されると、このファイルも再展開されます。 Service Catalog 管理者はファイルに含まれるデータを保持する必要があります。ただし、新しいバージョンではインストーラによって新たな情報が追加される場合があるため、ファイルのコピーを復元しないでください。 newscale.properties のエントリは次のとおりです。
|
rcjms.properties |
このファイルもまた「RequestCenter.war\WEB-INF\classes\config」フォルダにあります。 これには、アプリケーション内部通信用の JMS 設定が含まれます。 キュー名がアプリケーション サーバ上のキュー名と一致することを確認してください。 |
integrationserver.properties |
このファイルは「ISEE.war\WEB-INF\classes\config」フォルダにあります。 このファイルには、統合サーバ(Service Link)の重要なプロパティが含まれています。 |
Service Catalog はアプリケーション サーバのログ ファイルを保持し、アプリケーションの予期されたアクティビティと予期しないアクティビティをどちらも追跡します。 ログは、オープン ソース(Apache)のロギング メカニズムである log4j をベースとするフレームワークを使用して管理されます。 デフォルトで、ログは「ローリング アペンダー」に設定され、新しいログ ファイルが毎日開かれます。 アプリケーション サーバのタイプによってログ ファイルの内容と設定を調整する機能が異なるため、ログ ファイルの場所もアプリケーション サーバのタイプによって異なります。
次のことを推奨します。
Service Catalog はログ ファイルを保持する必要がありません。 ログ ファイルは、主にエラーが発生した場合のトラブルシューティング ツールとして有用です。 ログ エントリには E(エラー)、W(警告)、I(情報)、D(デバッグ)の 4 種類があり、この順で重大度が低下します。
デフォルト ログ ファイルの形式は Cisco Technical Assistance Center(TAC)で想定する形式であるため、この形式を変更することは推奨しません。 その代わり、顧客は自分たちのニーズを満たす独自のアペンダーを作成できます。
Service Link はシステム全体のログ ファイルに加えて、アダプタ タイプごとに個別のログ ファイルを使用するように設定されています。 これらのログも log4j で管理されます。 Service Link のロギングはデフォルトで有効にされます。 アダプタ固有のログ ファイルは ServiceLink\logs ディレクトリに書き込まれます。
すべてのログを記録する DEBUG レベルを有効にすると、ログのサイズが急激に大きくなります。このため、フル デバッグおよびトレース レベルのロギングを有効にするのは短期間にとどめる必要があります。 システムのパフォーマンスが大幅に低下する可能性があるため、本番システムでのロギングは最小限とし、問題を再現するために必要な期間のみとする必要があります。 詳細については、ログとプロパティを参照してください。
すべてのモジュールは、JNDI(Java Naming and Directory Interface)経由で定義された J2EE データ ソースを利用します。 これらのデータ ソースは正しいデータベースを指し、適切なログイン情報が設定されている必要があります。
次の場合には、追加の JNDI データ ソースが必要です。
Service Catalog とは異なるデータベース タイプの外部データ ソースにアクセスすることは、サービス フォームではサポートされていません(たとえば、Oracle 上で動作する Service Catalog のインスタンスから SQLServer データ ソースへのアクセスや、Service Catalog の任意のインスタンスから Sybase データ ソースへのアクセスなど)。 データ ソースを設定する手順については、『Cisco Prime Service Catalog Installation Guide』を参照してください。この手順はアプリケーション サーバに固有の手順です。
データ ソースを追加する場合は、可能なかぎりシスコのドライバを使用してください。
JBOSS 7.1.1 を使用してカスタム データ ソースを設定できます。
ステップ 1 | JBOSS アプリケーション サーバの JMX 管理コンソールにログインします。 | ||
ステップ 2 | [データソース(Datasources)] を選択します。 | ||
ステップ 3 | [検証(Validation)] タブを選択します。 | ||
ステップ 4 |
[有効な接続チェッカー(Valid Connection Checker)] フィールドに次のデータを入力します。
|
||
ステップ 5 | [一致した場合に検証する(Validate on Match)] チェックボックスをオフにして false に設定します。 | ||
ステップ 6 | [バックグラウンド検証(Background Validation)] チェックボックスをオンにして true に設定します。 | ||
ステップ 7 | [検証ミリ秒(Validation Millis)] に 600000 を入力します。 | ||
ステップ 8 | [保存(Save)] をクリックします。 | ||
ステップ 9 | [プール(Pool)] タブを選択します。 | ||
ステップ 10 | [最小プールサイズ(Min Pool Size)] に 1 と入力し、[最大プールサイズ(Max Pool Size)] に 10 を入力します。 | ||
ステップ 11 | [保存(Save)] をクリックします。 | ||
ステップ 12 | [プロパティ(Properties)] タブを選択します。 | ||
ステップ 13 | [厳密な最小(Strict Minimum)] および [事前入力が有効(Prefill Enabled)] の値として true を入力します。 | ||
ステップ 14 | [保存(Save)] をクリックします。 |
Service Catalog 内の外部ディクショナリは、データベース内の物理テーブルで補助する必要があります。 外部ディクショナリを読み取り専用にすることはできません。 すべての外部ディクショナリは読み取りと書き込みが可能です。 外部ディクショナリに書き込むのはアプリケーションのみにする必要があります。
アプリケーションで要求に外部ディクショナリを関連付けるには、外部キーとして使用可能な数値列を用意する必要があります。 通常、この名前は RequisitionEntryID とします。
次のコードにより、各行に一意の ID を生成するシーケンスが作成されます。 RequisitionEntryID カラムにインデックスを作成すると、Service Manager のパフォーマンスが大幅に最適化されます。
外部ディクショナリの補助テーブルは、Catalog Deployer によって環境間では転送されません。 service.create sequence X_SEQ のコンポーネントとして展開できるのは、ディクショナリ定義のみです。
create table ( X_ID INT CONSTRAINT PK_X primary key, REQUISITION_ENTRY_ID INT, REQUESTORLANID VARCHAR2 (10), REQUESTORNAME VARCHAR2 (50), FUNDINGSOURCECODE VARCHAR2 (15), DATENEEDED DATE, REASONFORCHANGE VARCHAR2 (50), PROJECTNAME VARCHAR2 (50), TOPINITIATIVE VARCHAR2 (5)); create or replace trigger X_it before insert on X for each row declare seq_val number; begin select X_seq.nextval into seq_val from dual; :new.X_ID := seq_val; end;
Service Designer のサービス エクスポート機能は、Service Catalog への接続確立、エクスポートされた XML の取得、XML のファイルへの保存を行い、ユーザにリンクを返します。
アプリケーションが SSL 対応の場合は、ユーザがサービスを XML ドキュメントとしてエクスポートしようとするときに問題が発生します。 アプリケーションに接続するにはサーバへの認証が必要であり、Service Catalog には SSL 証明書が必要です。
Service Catalog が SSL 対応のときにエクスポート サービス 機能を有効にするには、次の手順を実行します。
ステップ 1 | Service Catalog Web サーバで使用する、信頼できるルート CA 証明書を、Base 64 符号化形式でファイルにエクスポートします。 ファイルの拡張子は「.arm」または「.cert」になります。 これは、任意のテキスト エディタで開くことのできる単純なテキスト ファイルです。 |
ステップ 2 | 使用しているアプリケーション サーバの Java インストール環境に付属する CA 証明書キーストアを検索します。 Java インストール環境の CA 証明書キーストアは、cacerts という名前のファイルです。 |
ステップ 3 |
Service Catalog Web サーバの信頼できるルート CA 証明書を Java の cacerts キーストアにインポートします。 Java の keytool ユーティリティも使用できます。
次に、Java の keytool ユーティリティのコマンドライン構文の例を示します。これにより、ルート CA 証明書が cacerts にインポートされます。 例: keytool.exe -import -trustcacerts -alias RC –file <root_cert_file> -keystore C:\jdk1.6.0_12\jre\lib\security\cacerts
ここで、<root_cert_file> は、ステップ 1 でエクスポートした Service Catalog Web サーバのルート CA 証明書を含むファイルのフル パス名です。 keytool プログラムにより、キーストア パスワードの入力が求められます。 Java の新規インストールの場合、cacerts ファイルのデフォルト キーストア パスワードは changeit です。 「changeit」と入力するか、このマシンに Java をインストールしてからパスワードを変更した場合は、その値を入力します。 [この証明書を信頼しますか?(Trust this certificate?)] という質問が 表示された場合は、「y」と入力します。 . |
ステップ 4 | アプリケーション サーバ インスタンスを再起動し、変更を有効にします。 個々のサーバやアプリケーションではなく、このマシンの JBoss と WebLogic を含むインスタンス全体を再起動します。 |
ほとんどのサイト構成の設定は、アクセス高速化のために J2EE システムにキャッシュされます。 J2EE アプリケーションで使用される設定をリロードするには、Administration モジュールの [設定(Settings)] ページで任意のオプションを変更し、[更新(Update)] をクリックします。 これでキャッシュが無効になり、そのページの設定がリロードされます。
Cisco Prime Service Catalog には、Business Engine と呼ばれる独自のワークフロー管理システムが組み込まれています。 Business Engine のアクション(提供計画の管理)は、アプリケーション サーバで発生するため、アプリケーション ユーザはほとんど意識する必要がありません。 ただし、システム管理者には、Business Engine の処理を確認および場合によっては調整するためのユーザ インターフェイスが提供されます。
Site Administrator システム ロールを持っているユーザは、URL の http://<serverName:portNumber>/RequestCenter/businessengine/index.jsp を経由して Business Engine コンソールにアクセスできます。このコンソールの機能は次のとおりです。
このアプリケーションには、他のキャッシング メカニズムもあります。 キャッシュされた値は、アプリケーション データが変更されると自動的にリフレッシュされます。
SSO 経由の外部認証が使用される場合、一般的にユーザ パスワードはデータベースに保存されません。 保存される場合は、一方向の AES 128 ビット ハッシュとなります。 設定ファイルまたはデータベースに保存されたパスワードは、公開/秘密キー暗号化によって暗号化されます。 追加の暗号化はデータには適用されません。
コンフィギュレーション ファイル内のローカル アプリケーションのパスワードは暗号化されます。 Service Link が設定されていると、J2EE コンテナのパスワードは暗号化されずに、いくつかの設定ファイルにプレーン テキストとして保存されます。
URL は符号化されません。データレベルのセキュリティにより、各画面の承認が確認されます。
ここでは、アプリケーション セキュリティについて説明します。
Service Catalog は、多数の証明書を保存できるキーストアをパスワードで保護して保持します。
Web サーバ、または Web サーバの前にあるコンテンツ スイッチでは SSL を実行することが推奨されます(特にエクストラネットをサポートする環境の場合)。
通常、Web サーバからアプリケーション サーバへの通信を暗号化する必要はありません。
いくつかのツールでは、アプリケーションをスキャンして、CGI ベースの送信(GET 形式の送信)がアプリケーションに存在しないことを確認します。
シスコはデータのセキュリティと安全に注目しており、XSS(クロスサイト スクリプティング)攻撃によって発生する脅威をよく認識しています。
Service Catalog では標準の J2EE input-filter-config.xml ファイルを使用して、URL に < > " ' ( ) & ; の文字が含まれないことをチェックします。
このファイルは RequestCenter.war\WEB-INF\config\ にあります。
リリース 9.3.2 以降のインストールでは、悪意のあるファイルからサービス要求を保護するために使用可能なサービス設計機能が多数用意されています。 フォーム ルールとデフォルト値の設定が適用されたフォーム データを傍受しようとする悪意のある試みを阻止するために、サーバ側ルールと特定の編集制御を使用して、ブラウザ クライアントから送信されたデータをオーバーライドまたは検証することができます。 詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。
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 ディレクトリには、これらのスクリプトのアクティビティのログが記録されます。
標準レポートおよび Key Performance Indicator(KPI)をサポートするには、次のスクリプトが必須です。
プログラム |
説明/使用方法 |
---|---|
update_datamart_std.cmd |
Data Manager で指定した ETL ルールに従って、作成済みレポートをサポートするデータベース テーブルにデータを入力します。 これは、データベース コンテンツの差分リフレッシュではなく完全な再ビルドです。 <cognos.root >\c8 \datamanager \log にログ ファイルが作成されます。 |
データ マートをサポートするには、次のプログラムが必須です。
プログラム |
説明/使用方法 |
---|---|
update_datamart.cmd |
Data Manager で指定されたルールを使用して、データ マートのファクト テーブルとディメンション テーブルおよび Demand Center データ マートにデータを入力します。 これは、すべてのスタティックなディメンション データとファクト データの差分リフレッシュです。 <cognos.root >\c8 \datamanager \log にログ ファイルが作成されます。 |
create_model.cmd |
動的に定義されたレポート可能オブジェクト(ディクショナリとサービス)および標準のファクトとディメンションを含む Cognos FrameworkManager モデルを作成します。 静的に定義されたモデル(データ マートで使用される標準のファクトとディメンション)を、レポート可能なサービスとディクショナリを記述する、動的に生成されたメタデータとマージしてモデルが再ビルドされます。 |
publish_fdr_pkg.cmd |
FrameworkManager モデルを Cognos BI サーバに Cognos ScriptPlayer ユーティリティ経由でパブリッシュします。 モデルを作成するプログラム(create_model.cmd)の後に、Service Catalog データ マート リフレッシュの一部として実行する必要があります。 |
レポート可能として指定されたディクショナリおよびサービスは、Java プログラムによってデータ マートに入力されます。 プログラム アクティビティは、アプリケーション サーバの現在のログ ファイルに記録されます。
このプログラムは内部スケジューラ経由で実行されます。 スケジュールの設定は、インストール環境の一部として指定するか、newscale.properties ファイルを編集して変更します。 次のプロパティによってスケジューラが設定されます。 ETL(およびその他のプロセス)は毎日実行することを推奨します。 このジョブの実行中はデータ マートを使用できません。 ETL プロセスはトランザクション ロギングを行いながら実行されます。 トランザクション サイズ(FDR_ETL_RECORDS_PER_BATCH)を増やすことを推奨します。
#Enable ETL Process: 0 or 1 (1=Yes, 0=No) ENABLE_FDR_ETL_PROCESS=0 # FDR_ETL_TRIGGER : 1 for hourly, 2 for daily, 3 for minutes FDR_ETL_TRIGGER=1 #Frequency Hourly FDR_ETL_TRIGGER_FREQUENCY_HOURLY=5 #Daily Time HH:MM (22:30 for 10:30 PM) FDR_ETL_TRIGGER_FREQUENCY_DAILY=22:30 #Frequency in minutes FDR_ETL_TRIGGER_FREQUENCY_MINUTES=1 #Number of records per batch insertion FDR_ETL_RECORDS_PER_BATCH=500
Escalation Manager は、タスクがその運用レベル契約(OLA)を超過したかどうかをモニタリングします。 OLA を超過した場合、エスカレーションが設定されていれば、Escalation Manager はタスクが超過となってから、指定された時間が経過した後に適切な通知を送信します。
Escalation Manager は内部スケジューラ経由で実行されます。 スケジュールの設定は、newscale.properties ファイルを編集して調整できます。 デフォルトでは、Escalation Manager は月曜から金曜までの営業時間中に実行されるよう設定されています。
スケジュール設定は基本的に cron 式であり、必要なスケジュールを「秒 分 時 日 月 曜日」の形式で記述します。 たとえば、"0 0 12 ? * WED" という式は、「毎週水曜日の午後 12 時 00 分」を意味します。
Service Manager はタスク実行者がサービス要求を履行するために使用するモジュールです。
Service Manager を使用すると、ユーザは [フィルタ処理と検索(Filter and Search)] ポップアップ ウィンドウで一致する一連の条件を指定して、目的のタスクまたは要求を検索できます。 デフォルトで、これらの条件では Contains 演算子(たとえば、指定した文字列が名前に含まれるすべてのタスクを検索する機能)がサポートされません。
データベースに対してインデックス化されたクエリーが実行される確率を高めることで、このデフォルト動作でもパフォーマンスが最適化されます。 Contains クエリーを実行する機能をサポートすることは可能ですが、特に大規模なトランザクション データベースなどでは応答時間が最適でなくなる可能性があるため、管理者がこの設定を変更する場合には注意が必要です。 変更の取り消しは、Service Manager のカスタム ビューに影響を与えるため、お勧めしません。
Service Manager のユーザが Contains クエリーを指定できるようにするには、newscale.properties ファイルを編集して次のプロパティ設定を追加します。
# Service Manager will use this flag to control Contains Query in Datatable Filter and Search ContainsQueryInFnS=true
プロパティ ファイルに対するすべての変更と同様に、変更を反映させるためにはサービスを停止して再起動する必要があります。
インストール ログは、インストーラが呼び出されるたびに mmddyyyyhhmm というタイムスタンプ(010720111126 など)を使用して <APP_HOME>/logs フォルダに保存されます。
主なインストール ログを次に示します。
ファイル名 |
目次 |
---|---|
RC_Install |
全般的なインストール ログ。 |
RC_File |
ファイル システムに追加された、あるいはファイル システムから移動または削除されたファイルに関する情報。 |
RC_DbInstall |
データベースのインストールまたはアップグレード プロセス中に実行された SQL スクリプトおよび各スクリプトの実行にかかった時間に関する情報。 |
RC_Sql |
インストール中にデータベースで実行された SQL ステートメントのログ。 インストール中に SQL スクリプトでエラーが発生した場合は、このログが非常に有用な場合があります。ログには、エラーが発生したスクリプトのテキストが含まれ、そのエラーの具体的な内容が示されています。 |
インストール設定は RequestCenter/etc フォルダに記録されます。 今後の Service Catalog インストーラの呼び出しに備えてインストール設定が保存されるように、このフォルダを維持してください。
この設定は setup_options.txt ファイル内で参照できます。
Cisco Prime Service Catalog のシングル クラスタ構成のインストールでは、クラスタ内部のマルチキャスト通信が必要です。 各ノードが同じサブネット上にあるか、スイッチでサブネット間のマルチキャスト ルーティングが有効になっている必要があります。 また、ホスト サーバのネットワーク インターフェイス設定でマルチキャストを有効にする必要があります。
Service Catalog では、複数のマルチキャスト アドレスが使用されますが、これらのアドレスは一意にする必要があります。
ここでは、マルチキャスト接続をテストする方法を説明します。 次のようにして、Node1 が Node2 と通信できるかどうかチェックするテストを実行できます。
Node2 が Node1 と通信できるかどうかもチェックできます。
送信側を Node2、受信側をNode1 として、上記の手順(テスト)を繰り返します。
統合を管理するために、Service Catalog アプリケーションの設定をする際にシステム管理者がとるべき主な統合戦略については、『Cisco Prime Service Catalog Integration Guide』を参照してください。
システムでは複数の LDAP ディレクトリの統合が可能です。 2 つ以上の LDAP ソースのグループが、照会を通じて 1 つの LDAP システムとなります。 照会は、検索でのみサポートされており、バインディングではサポートされていません。 ディレクトリ統合の設定方法については、『Cisco Prime Service Catalog Integration Guide』を参照してください。
ディレクトリ統合を利用すると、統合アーキテクトは LDAP データ ソースに Service Catalog を接続し、個人プロファイル内の対応するフィールドにそのデータ ソースの属性をマッピングできます。 統合により、設計者は LDAP ルックアップをトリガーするイベントと、そのルックアップによって Service Catalog の個人プロファイルもリフレッシュするかを指定できます。 LDAP ルックアップをトリガー可能なイベントには次のようなものがあります。
ディレクトリ統合では、事前に設定されたこれらのイベントと動作に加えて、プログラマがカスタム ディレクトリ インターフェイスを実装して新しい検索機能の追加や検索ロジックの改良ができる API を提供します。
ディレクトリ データは次のような人員のプロファイルの要素にマッピングできます。
4 種類のマッピングを使用できます。
ロケールおよびタイム ゾーンがマッピングされていない場合は、Service Catalog がサーバ デフォルトを使用します。 また、オプション フィールドがマッピングされていない場合は、個人プロファイルで過去に生成された値がそのまま残ります。
カスタム マッピングは、『Cisco Prime Service Catalog Integration Guide』に記載されているパターン マッチング言語(正規表現)経由と Directory Integration API で提供されるインターフェイスに基づくカスタム プラグイン クラス経由で作成できます。
このようなマッピングはすべて、実装ごとに LDAP 統合ドキュメント内で文書化する必要があります。 Service Catalog インスタンスが移行またはアップグレードされた場合、マッピングに必要な Java クラスはすべてカスタマイゼーションとして扱われます。
シングル サインオン機能は、ディレクトリ統合の一部として提供されます。 シングル サインオンに問題が発生した場合は、次の項目をチェックしてトラブルシューティングを開始します。
ISF は Cisco Prime Service Catalog サービス フォームに統合された JavaScript API です。 ISF を使用すれば、ユーザ クレデンシャル、過去にフォームに入力されたデータ、表示された要求のライフ サイクルなどの現在のコンテキストに基づいて、フォームのコンテンツや振る舞いを動的に変更できます。 ISF の詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。
ISF は、Service Catalog リポジトリに保存された JavaScript コードを補完する、アプリケーションまたは Web サーバに保存された JavaScript ライブラリの使用をサポートします。 このようなライブラリを使用する場合は、Service Catalog サイトをアップグレードまたは移行するときに、ライブラリをカスタマイゼーションとして扱う必要があります。
アクティブ フォーム コンポーネント内で使用できるデータ取得ルールにより、アプリケーションで外部リレーショナル データベースまたはアプリケーション データベースからデータを取得し、サービス フォームで使用することができます。 このようなデータは、フォームのフィールドへのデフォルト値の事前入力、ドロップダウン リストの生成、および詳細情報にドリルダウンする場合の値の動的入力に使用できます。 また、ユーザのデータ入力を外部データと照合することもできます。
外部データベースにアクセスするルールの場合は、対応する JEE データ ソースを作成する必要があります。 データ ソースの作成の手順については、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。 Service Catalog サイトをアップグレードまたは移行する場合、このようなデータ ソースはカスタマイゼーションとして扱われます。
Service Link は Integration Server または ISEE(Integration Server Enterprise Edition)とも呼ばれますが、これを使用すると Service Catalog で XML メッセージを使用して他のシステムに同期または非同期の要求を送信できます。 Service Designer で「外部」として設定されたタスクが、Service Link によって処理されます。
Service Link は基礎となるテクノロジーとして JMS キューを使用するので、JMS 設定に問題があると Service Link の動作に悪影響が出る可能性があります。 ほとんどの Service Link トラブルシューティングは、Service Link モジュールを使用して行うことができます。このモジュールには、送受信された個々のメッセージとそれらのメッセージを送受信するタスクをドリルダウンする機能が備わっています。
ここでは、Service Catalog のカスタマイズされたインストール用のシステムの設定と、以降のインストールまたはアップグレードでカスタム コンテンツが削除または上書きされないようにすることに関する情報を示します。
Service Catalog インストール ウィザードの詳細については、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。
Service Catalog インストール ウィザードは WAR を構築すると同時に、次の処理を行います。
展開手順では、WAR ファイル全体がサーバに展開されることが規定されています。 WAR ファイル全体が展開されると、WAR が前回展開されたディレクトリは削除され、そのディレクトリに存在したすべての Service Catalog カスタマイゼーションは失われます。
カスタマイズが失われないようにするために、Service Catalog インストール ウィザードではカスタム コンテンツがインストールに含まれるように指定できます。
手順
ステップ 1 | カスタム コンテンツを含むアーカイブを Zip 形式で作成します。 アーカイブのディレクトリ構造は展開ディレクトリの構造と一致させる必要があります。 |
ステップ 2 |
拡張インストール タイプを使用して 『Cisco Prime Service Catalog Installation and Upgrade Guide』の説明に従って、Service Catalog インストール ウィザードを実行します。 |
ステップ 3 | [アプリケーションサーバの設定(Application Server Configuration)] ページの [拡張オプション(Advanced Options)] をクリックします。 |
ステップ 4 | [拡張オプション(Advanced Options)] ダイアログボックスで、[カスタム コンテンツ(Custom Content)] を選択します。 |
ステップ 5 | [カスタムコンテンツのアーカイブ(Custom content archive)] に、アーカイブ名も含めたフル パスを入力するか、[参照(Browse)] をクリックしてカスタム コンテンツのアーカイブを探し、選択します。 |
ステップ 6 |
[Close(閉じる)] をクリックします。 『Cisco Prime Service Catalog Installation and Upgrade Guide』の説明に従って、インストールを続行します。
Service Catalog インストール ウィザードがインストールを完了する間、アプリケーションの展開ディレクトリ構造にカスタム コンテンツのアーカイブが抽出されます。 |
カスタマイズされたファイルはすべてカスタマイゼーション アーカイブに含まれている必要があります。 実装内のすべてのサイトで、次のようなカスタマイズされたファイルが必要な場合があります。
カスタマイズ可能なコンポーネント |
ディレクトリ/ファイル |
---|---|
カスタム スタイル シート、ヘッダー、フッター |
RequestCenter.war\custom\*\custom.css RequestCenter.war\custom\*\portal-custom-header.css RequestCenter.war\custom\*\images\ RequestCenter.war\custom\*\header.html、footer.html(カスタム スタイル シートがインストールされているすべてのディレクトリ) |
ISF ライブラリ |
RequestCenter.war\isfcode\* |
カスタム クラス |
RequestCenter.war\WEB-INF\classes\(ディレクトリ統合カスタマイゼーションに関連するクラスなどのカスタム クラス) |
手作業で編集されたプロパティ ファイル(このような変更もサイト固有のものである可能性があります) |
newscale.properties rcjms.properties integrationserver.properties newscalelog.properties |
通常、Service Catalog 実装は複数のサイトで構成され、それぞれのサイトが異なる役割を果たします。
サイト |
使用方法 |
---|---|
開発 |
サービス定義が開発され、単体テストが行われます。カスタマイゼーションが最初に適用されます。 |
テスト |
開発アクティビティから干渉されることのない、制御された環境。ここでは、品質保証または他の担当者が Service Catalog をテストします。 |
Production |
ユーザ コミュニティが Service Catalog からサービスを要求でき、IT チームがサービス要求を満たすことができる本番環境。 |
Catalog Deployer モジュールは、メタデータ(サービス定義)およびリポジトリに保存されている組織データ(人員、組織、および関連するエンティティ)の設定管理を行います。 詳細については、『Cisco Prime Service Catalog Designer Guide』で Catalog Deployer のマニュアルを参照してください。
次のように、展開中に 1 つのサイトから別のサイトに Service Catalog OLTP データベースをコピーできます。
1 つのサイトから別のサイトに Service Catalog OLTP データベースをコピーするには、次の手順を実行します。
ステップ 1 | ターゲット環境の Service Catalog と Service Link のサービスを停止します。 | ||
ステップ 2 | ターゲット データベースの最新のバックアップ コピーがあることを確認します。 | ||
ステップ 3 | 必要に応じて、宛先からのエクスポート ファイルを、ターゲット データベース サーバにアクセスできるファイル システムにコピーします。 | ||
ステップ 4 | ターゲット データベースにデータをインポートします。
|
||
ステップ 5 | 両サイトが 2 つの異なる Cognos レポート サーバにアクセスしている場合は、各サイトの「CognosServer」の名前を指定する CnfParams テーブルのエントリを更新して、更新内容をコミットします。 | ||
ステップ 6 | ターゲット環境の Service Catalog と Service Link のサービスを再起動します。 | ||
ステップ 7 | プロパティを現在のサイトに設定します。 [Entity Homes] の指定が異なる場合、またはサイトの保護レベルが異なる場合は手動で変更を行い、変更を保存します。 |
||
ステップ 8 | 両サイトが 2 つの異なる LDAP ディレクトリに接続している場合は、ディレクトリ統合のデータ ソース定義を適宜変更します。 | ||
ステップ 9 | Service Link エージェントの接続プロパティをすべてチェックし、ターゲット環境に合わせて変更します。 | ||
ステップ 10 | 手作業での追加処理がある場合はそれを実行し、データを調整します。 たとえば、一部のユーザ、グループ、または組織に権限を追加したり、権限を取り消したりする場合があります。 | ||
ステップ 11 | メンテナンスが完了したことをユーザに通知します。 |
ここでは、サービス リンクの SSL の設定について説明します。
Service Link サービスの SSL の有効化には、次の作業が必要です。
VeriSign や Thawte のような既知の認証局によって署名された証明書を取得する場合は、これらの認証局のいずれかの署名者証明書を、ほとんどのクライアント プログラムがすでに認識しているという利点があります。
Service Link サービスに自己署名証明書を使用する場合は、Web インターフェイス経由で Service Link と通信するすべての外部システムと、署名者証明書を交換する必要があります。
たとえば、受信アダプタに http/ws アダプタを使用する Service Link エージェントに外部システムが応答メッセージを送信する場合、その外部システムは https URL 経由で Service Link に接続するクライアントとして機能するため、正しい SSL 接続を行うために信頼できるハンドシェイクを完了する方法を把握している必要があります。
そのためには、Service Link サービスで使用される証明書の署名者を外部システムが認識している必要があります。 このことを実現するため、外部システムの信頼できる認証局キーストアに Service Link の署名者証明書をインポートしておきます。 詳細については、この章の後半を参照してください。
(注) |
Service Link は、サーバとしては SSL ハンドシェイク時のクライアント証明書認証をサポートしていません。 |
Service Link の SSL を有効にすると、Service Link のセキュア ポートはオンになりますが、非セキュア ポートはオフになりません。 非セキュア ポートをオフにしない場合、外部システムは引き続き http URL 経由で Service Link と通信できます。 非セキュア ポートをオフにする場合は、Service Link サービスとのすべての通信で https URL を使用する必要があります。
Service Link サービスのセキュア ポートと非セキュア ポートの両方を使用して、ファイアウォール システムなどの別のメカニズムを介して非セキュア ポートへのアクセスを制御することができます。
たとえば、Two-JBoss-Server トポロジでは、Service Catalog アプリケーションが(別の JBoss サーバ上で動作している)Service Link サービスの「クライアント」でもあります。 実行時に、Service Catalog が URL の http://<SL_servername >:6080 を介して Service Link サービスに接続する必要があります。 非セキュア ポート 6080 が Service Link サービスに対してオフになっている場合は、https アドレス、つまり、https://<SL_servername >:6443 を介して Service Link に接続するように Service Catalog を設定する必要があります。
そこで、Service Link サービスの非セキュア ポート 6080 とセキュア ポート 6443 の両方をオンにするというシナリオが考えられます。 Service Catalog は、http://<SL_servername >:6080 を介して Service Link に接続できますが、他の外部システムは https://<SL_servername >:6443 を介して Service Link と通信する必要があります。 ファイアウォール システムを設定すると、すべての外部システムからのポート 6080 へのアクセスを拒否できます。
ここでは、アプリケーション サーバの非セキュア ポートをオフにする方法や、非セキュア ポート番号へのアクセスを拒否するようにファイアウォール システムを設定する方法については説明しません。 必要な情報を入手するには、システム管理者またはご使用のアプリケーション サーバのベンダーに問い合わせてください。
Service Link が Service Catalog とは別のアプリケーション サーバに展開されている場合(クラスタ化された WebLogic 環境や Two-JBoss-Server トポロジの場合)に、Service Link の SSL を有効にするには、Service Link が動作しているアプリケーション サーバの証明書とセキュア ポート番号のみを設定します。
Service Link サービスの保護に使用可能なデジタル証明書は入手済みであるとします。 この証明書は自己署名するか、または VeriSign のようなサードパーティ認証局から取得できます。 いずれの場合も、デジタル証明書はアプリケーション サーバからアクセス可能な Java キーストア(jks ファイル)にインポートする必要があります。 また、署名者証明書(証明書の公開キーとも呼ばれます)は、SSL モードで Service Link サービスと通信する外部システムに提供できるように、「Base64 エンコード ASCII」形式のファイルにエクスポートする必要があります。
(注) |
このマニュアルでは、キーストア ファイルの作成方法や Web サーバまたはアプリケーション サーバ用の証明書の要求方法は説明しません。 この項の手順では、Service Link が稼動しているアプリケーション サーバに対して SSL を有効にするために使用されるデジタル証明書を含むキーストア ファイルがすでに作成済みであるとします。 説明を容易にするため、使用するキーストア ファイルの名前は「slkeystore.jks」とします。 証明書は「servicelink」というエイリアスの下に格納されています。 このキーストア ファイルを開くためのパスワードは「slpassword」です。 |
さらに、「slsigner.cer」という名前のファイルに「Base64 エンコード ASCII」形式で署名者証明書がエクスポートされているものとします。 「Base64 エンコード ASCII」形式の例を以下に示します。
-----BEGIN CERTIFICATE----- MIICPDCCAaUCBE17w1cwDQYJKoZIhvcNAQEEBQAwZTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB MRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1NjYWxlMQswCQYDVQQLEwJRQTEVMBMG A1UEAxMMS2hhbmcgTmd1eWVuMB4XDTExMDMxMjE5MDI0N1oXDTIxMDMwOTE5MDI0N1owZTELMAkG A1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1Nj YWxlMQswCQYDVQQLEwJRQTEVMBMGA1UEAxMMS2hhbmcgTmd1eWVuMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDhTxg2RwarD6Wn4iqYeOOk3ykfXzZiDArf/X63omXquTmN0Up+mg6oJmPAfqJA l7k4+Dn7dfVtAc4h8qra7PBeBU48zrzRqZd6VAK07rz++CilQto64mHXYVomb5vWPGeKA41j9vlv ENj/tE/6++IqbwnxAqeZtY3EvEM7dcCWDwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAAaqCnfEAovy Uf2S+oAXYDo5N387a035APsz5iiUM5oiKR/KW3oRz/v0P0I/o3n312kDIJ01111pl6qpZRtPEsr1 b00Tu1cXfPmizEtz0ole606qDS+DzkS1+YYz2mLL2Zq40d1EPsMolyqyUmyq3GHaEnuhWemcv2aA wGFgbQYd -----END CERTIFICATE-----
ここでは、証明書ファイルをインストールする手順および各種アプリケーション サーバの SSL を設定する手順について説明します。
ステップ 1 | Service Link アプリケーションが稼働している JBoss サーバを停止します。 | ||
ステップ 2 | 「<JBOSS_DIR>\ServiceLinkServer\configuration」ディレクトリに「slkeystore.jks」ファイルをコピーします。ここで、<JBOSS_DIR> は、Service Link アプリケーションが展開される JBoss サーバのインストール ディレクトリです。 | ||
ステップ 3 | ファイル「<JBOSS_DIR>\ServiceLinkServer\configuration\standalone-full.xml」のバックアップを作成します。 テキスト エディタを使用してファイル「standalone-full.xml」を開きます。 特殊なキャリッジ リターン文字またはその他の書式設定文字をファイルに挿入しないテキスト エディタを使用してください。 | ||
ステップ 4 |
ファイル「standalone-full.xml」で次の行を検索します: 例: <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> その行のすぐ下に次の 3 行を挿入します: 例: <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true"> <ssl name="ssl" key-alias="servicelink" password="slpassword" certificate-key-file="../ServiceLinkServer/configuration/slkeystore.jks"/> </connector>
ファイル「standalone-full.xml」で次の文字列を検索します: 例: <socket-binding name="https" port= |
||
ステップ 5 | ポート番号の値を書き留めます。 これは、SSL モードで JBoss サーバによって使用されるセキュア ポート番号です。 | ||
ステップ 6 | Service Catalog アプリケーションが実行されている JBoss サーバを停止し、「<JBOSS_DIR>\ServiceCatalogServer\deployments\RequestCenter.war\WEB-INF\classes\config」ディレクトリに移動します。 | ||
ステップ 7 |
テキスト エディタを使用してファイル「newscale.properties」を開き、次のパラメータを検索します: 例: isee.base.url=
|
||
ステップ 8 | このパラメータの値を http://<hostname>:<nonsecure_port_number> から https://<hostname>:<secure_port_number> に変更します。 | ||
ステップ 9 |
ファイル「slsigner.cer」を「<JAVA_HOME>\jre\lib\security」ディレクトリにコピーします。ここで、<JAVA_HOME> は JDK 6 のインストール ディレクトリです。 ファイル「slsigner.cer」に CA 証明書が含まれていると仮定しています。 |
||
ステップ 10 | コマンド プロンプト ウィンドウまたはコンソール ウィンドウを開き、「<JAVA_HOME>\jre\lib\security」ディレクトリに移動します。 | ||
ステップ 11 |
次のコマンドを実行して、JDK 6 によって使用される信頼できる証明書キーストアに CA ルート証明書をインポートします。 例: <JAVA_HOME>\bin\keytool -import -trustcacerts -file slsigner.cer -alias servicelink -keystore cacerts -storepass changeit
|
||
ステップ 12 | ServiceCatalogServer と ServiceLinkServers の両方を起動し、管理者ユーザとして、または Service Link モジュールにアクセスできるユーザーとして Service Catalog URL に接続します。 | ||
ステップ 13 | Service Link のホームページを開き、「Service Link Status」のセクションで、接続が緑色のステータスであり、SSL アイコンとセキュア ポート番号の両方が表示されていることを確認します。 | ||
ステップ 14 | HTTP/WS アダプタを使用する Service Link エージェントに受信ドキュメントを送信する外部システムは、すべて次のように更新する必要があります: |
ステップ 1 |
Service Link が動作している WebLogic マシンの「<JAVA_HOME>\jre\lib\security」ディレクトリに、証明書キーストア ファイル「slkeystore.jks」をコピーします。
<JAVA_HOME> が、WebLogic アプリケーション サーバが使用する正しい Java ディレクトリであることを確認してください。 「<WL_HOME>\common\bin」ディレクトリの下にある「commEnv.cmd」ファイル内の JAVA_HOME 設定を検索します(UNIX または Linux では「commEnv.sh」を検索します)。 例:set JAVA_HOME= C:\Program Files\Java\jdk1.7.0\ |
||||||||||||||||||||||
ステップ 2 | WebLogic 管理コンソールにログインし、[<ドメイン>] > [環境(Environment)] > [サーバ(Servers)] に移動します。 | ||||||||||||||||||||||
ステップ 3 | Service Link の WebLogic サーバの名前をクリックし、設定を開きます。それから [設定(Configuration)] >[キーストア(Keystores)] サブタブをクリックします。 | ||||||||||||||||||||||
ステップ 4 |
[キーストア(Keystores)] ページで次の値を入力します。
[Java標準トラストキーストアパスフレーズ(Java Standard Trust Keystore Passphrase)] については、「cacerts」キーストア ファイルのパスワードがまだデフォルト値の「changeit」であると仮定しています。 使用する環境で「cacerts」のパスワードが変更されている場合は、それを適切な値に置き換えてください。 |
||||||||||||||||||||||
ステップ 5 | [保存(Save)] をクリックしてから、[設定(Configuration)] > [SSL] サブタブをクリックします。 | ||||||||||||||||||||||
ステップ 6 | [SSL] ページで次の値を入力します。 | ||||||||||||||||||||||
ステップ 7 | [保存(Save)] をクリックしてから、[設定(Configuration)] > [一般(General)] サブタブをクリックします。 | ||||||||||||||||||||||
ステップ 8 | [一般(General)] ページで次の値を入力します。 | ||||||||||||||||||||||
ステップ 9 | [保存(Save)] をクリックし、Service Link が展開されている WebLogic サーバを再起動します。 | ||||||||||||||||||||||
ステップ 10 |
ログ ファイル「<WL_servername>.out」に次のようなメッセージがあることを確認し、WebLogic サーバがセキュア ポート(9443)で起動したことを確認します。 例: <Notice> <Security> <BEA-090171> <Loading the identity certificate and private key stored under the alias hydra2 from the jks keystore file C:\jdk160_23\jre\lib\security\slkeystore.> <Notice> <Server> <BEA-002613> <Channel "DefaultSecure" is now listening on 192.168.21.72:9443 for protocols iiops, t3s, ldaps, https.> これで、Service Link サービスが SSL に対応しました。 |
||||||||||||||||||||||
ステップ 11 |
servicelink 証明書用の署名者証明書を含む「slsigner.cer」ファイルをすでに作成済みの場合は、このステップを省略します。 そうでない場合は、次の手順を実行して署名者証明書をエクスポートできます。 署名者証明書をエクスポートするには、いくつかの方法があります。次の手順は、Sun JDK 6 インストールに付属する「keytool.exe」ユーティリティを使用して証明書をエクスポートする方法の 1 つに過ぎません。 |
||||||||||||||||||||||
ステップ 12 |
Service Link サービスの非セキュア ポートを無効にする場合は、Service Link サービスと通信する外部システムを管理するシステム管理者に「slsigner.cer」ファイルを送信します。 その外部システムでは、2 つの設定を行う必要があります。
|
ステップ 1 |
Service Link サービスの非セキュア ポートを無効にするには、Service Catalog サービスの信頼できる Java 認証局キーストアに署名者証明書をインポートする必要があります。 これは、クラスタに属していない、独立した WebLogic サーバで Service Link が動作するためです (Service Catalog および Business Engine のみ、クラスタにインストールできます)。Service Catalog は、実行時に Service Link サービスに接続する「クライアント」として機能します。 |
ステップ 2 |
Service Catalog の信頼できる Java CA キーストアに署名者証明書をインポートするには、次の手順を実行します。
|
Service Link エージェントが HTTP/WS アダプタを使用して外部システムに送信メッセージを送信する場合、エージェントは外部 Web サーバに http 要求または Web サービス要求を送信するクライアントとして機能します。 外部 Web サーバが SSL 対応の場合、この Web サーバとセキュアな接続を確立するためには、Service Link にある設定が必要な場合があります。
(注) |
Service Link が複数の SSL 対応 Web サーバに接続している場合は、外部 Web サーバごとに 1 つずつの複数の署名者証明書をインポートする必要があります。クライアントとしての Service Link は、SSL ハンドシェイク時にクライアント証明書認証をサポートしません。 |
以降の項で、設定手順について詳しく説明します。
ステップ 1 | Service Link にアクセスできるユーザとして Cisco Prime Service Catalog にログインし、Service Link モジュールに移動して [統合の管理(Manage Integrations)] タブをクリックします。 |
ステップ 2 | 設定するエージェントを選択し、そのエージェントの [発信プロパティ(Outbound Properties)] ページを開きます。 |
ステップ 3 | [HttpOutboundAdapter.RoutingURL] フィールドで、https アドレスおよびセキュア ポート番号を入力します(たとえば、https://192.168.21.202:8444/HTTPSimulator/ など)。 |
ステップ 4 | [HttpOutboundAdapter.AcceptUntrustedURL] フィールドの値を [false] に設定して、セキュアな接続が行われるようにします。 |
ステップ 5 | [保存(Save)] をクリックし、[エージェントの制御(Control Agents)] タブを開いてエージェントを再起動します。 |
アプリケーション サーバ固有の手順を実行する前に、次の手順を実行する必要があります。
(注) |
外部 Web サーバ証明書の署名者が VeriSign や Thawte などの既知の認証局の場合は、Sun JDK で認識されている可能性が高いため、この手順を省略することができます。 |
-----BEGIN CERTIFICATE----- MIICPDCCAaUCBE17w1cwDQYJKoZIhvcNAQEEBQAwZTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNB MRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1NjYWxlMQswCQYDVQQLEwJRQTEVMBMG A1UEAxMMS2hhbmcgTmd1eWVuMB4XDTExMDMxMjE5MDI0N1oXDTIxMDMwOTE5MDI0N1owZTELMAkG A1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTYW4gTWF0ZW8xETAPBgNVBAoTCG5ld1Nj YWxlMQswCQYDVQQLEwJRQTEVMBMGA1UEAxMMS2hhbmcgTmd1eWVuMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDhTxg2RwarD6Wn4iqYeOOk3ykfXzZiDArf/X63omXquTmN0Up+mg6oJmPAfqJA l7k4+Dn7dfVtAc4h8qra7PBeBU48zrzRqZd6VAK07rz++CilQto64mHXYVomb5vWPGeKA41j9vlv ENj/tE/6++IqbwnxAqeZtY3EvEM7dcCWDwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAAaqCnfEAovy Uf2S+oAXYDo5N387a035APsz5iiUM5oiKR/KW3oRz/v0P0I/o3n312kDIJ01111pl6qpZRtPEsr1 b00Tu1cXfPmizEtz0ole606qDS+DzkS1+YYz2mLL2Zq40d1EPsMolyqyUmyq3GHaEnuhWemcv2aA wGFgbQYd -----END CERTIFICATE-----
署名者証明書をインポートする手順は、Service Link が動作しているアプリケーション サーバ(JBoss 7.1.1 の設定、WebLogic 10.3.6(11g)の設定、または トラブルシューティング(Troubleshooting))によって異なります。
ステップ 1 | Service Link マシンの一時ディレクトリに(外部システムの)署名者証明書ファイルをコピーします。 たとえば、署名者証明書ファイルが「extws.cer」の場合は、このファイルを Service Link マシンの「C:\temp\extws.cer」にコピーします。 | ||
ステップ 2 | Service Link マシンのディレクトリ「<JAVA_HOME >\jre\lib\security」で、ファイル「cacerts」を見つけます。ここで、<JAVA_HOME > は Sun JDK 6 インストールのルート ディレクトリです。 このファイルは、Sun JDK 6 インストールに同梱されている、信頼できる CA キーストアです。 | ||
ステップ 3 | コマンド プロンプト ウィンドウまたはコンソール ウィンドウで次のコマンドを実行して、署名者証明書を「cacerts」キーストアにインポートします。 例: cd <JAVA_HOME>\jre\lib\security <JAVA_HOME>\bin\keytool -import -trustcacerts -alias extws –noprompt -file C:\temp\extws.cer -keystore cacerts -storepass changeit
|
||
ステップ 4 | Service Link サービスを再起動します。 |
ステップ 1 |
Service Link サービスが稼働している WebLogic マシンの一時ディレクトリに(外部システムの)署名者証明書ファイルをコピーします。 たとえば、署名者証明書ファイルが「extws.cer」の場合は、このファイルを Service Link マシンの「/tmp/extws.cer」にコピーします。 クラスタ化された WebLogic 環境では、クラスタに属していない WebLogic サーバに Service Link を展開する必要があります。 したがって、必ず Service Link に適した WebLogic サーバを特定してください。 |
||
ステップ 2 |
Service Link マシンのディレクトリ「<JAVA_HOME>/jre/lib/security」で、ファイル「cacerts」を見つけます。ここで、<JAVA_HOME > は Sun JDK 6 インストールのルート ディレクトリです。 このファイルは、Sun JDK 6 インストールに同梱されている、信頼できる CA キーストアです。 <JAVA_HOME> が、WebLogic アプリケーション サーバが使用する正しい Java ディレクトリであることを確認してください。 これを行うには、「<WL_HOME>/common/bin」ディレクトリにある「commEnv.sh」(Windows の場合は「commEnv.cmd」)で、JAVA_HOME 設定を探します。 たとえば、JAVA_HOME="/opt/jdk1.6.0_23" などが該当します。 |
||
ステップ 3 |
コマンド プロンプト ウィンドウで次のコマンドを実行して、署名者証明書を「cacerts」キーストアにインポートします。 例: cd <JAVA_HOME>/jre/lib/security <JAVA_HOME>/bin/keytool -import -trustcacerts -alias extws –noprompt -file /tmp/extws.cer -keystore cacerts -storepass changeit
|
||
ステップ 4 | Service Link が展開されている WebLogic サーバを再起動します。 |
ここでは、送信電子メールを制限する方法、および電子メールの生成を制御する方法について説明します。 また、サポートに関するご質問や、システム環境およびエラー情報の追跡方法についてシスコに連絡する場合の情報も記載しています。
アプリケーション テンプレートをオーダーすると、オーケストレーション コンポーネントにより、[マイスタッフ(My Stuff)] の [コメントと履歴(Comments and History)] にテンプレート プロビジョニングの進行状況をトラッキングするためのオプションが表示されます。
(組み込みの)クラウド オーケストレーション サービスは、Prime Service Catalog の実行中に再起動されると、Prime Service Catalog に再接続し、AMQP のエクスチェンジを検出し、AMQP メッセージのモニタリングを再開します。
一方、Prime Service Catalog がクラウド オーケストレーション サービスの実行中に再起動されると、クラウド オーケストレーション サービスは Prime Service Catalog が実行を再開したときに再接続します。
(アプリケーション テンプレートの)オーダーが送信されると、クラウド オーケストレーション エンジン(Heat エンジン)がアプリケーション テンプレートのプロビジョニングを開始する前に、このエンジンのステータスがチェックされます。
(注) |
クラウド オーケストレーション エンジンはフォールト トレラントではありません。インフラストラクチャ テンプレートのプロビジョニング中にエンジンが停止すると、プロビジョニングは中断され、後でエンジンが再起動されても復旧できません。 |
クラウド オーケストレーション エンジンとオーケストレーション サービスの再起動
sudo service openstack-keystone restart sudo service openstack-heat-api restart sudo service openstack-heat-api-cfn restart sudo service openstack-heat-engine restart sudo service amqp-service restart sudo service psc-orchestration restart
ログ ファイル
次のトレースが一般的にモニタリングされます。
データベースの相互作用 |
com.newscale.bfw.udkernel.udsql.UdSqlBean com.newscale.bfw.udkernel.util.UdKernelUtil
|
LDAP の相互作用 |
com.newscale.bfw.ldap.jldap.JLDAPApi
|
クラスタリングの問題 |
com.opensymphony.oscache.plugins.clustersupport.AbstractBroadcastingListener com.opensymphony.oscache.plugins.clustersupport.JavaGroupsBroadcastingListener
|
サービス設計のテスト時や非本番環境では、送信電子メールを制限することがあります。
送信電子メール機能を制限することにより、実際の実行者やサービスをオーダーした顧客に対して電子メールの送信を制限したり、禁止したりすることができます。
開発環境ですべての電子メール テンプレートを「仮のアドレス」に変更することは、実際には行うべきではありません。 まず、これには非常に時間がかかります。 さらに重要なのは、テンプレート アドレスを元に戻したときに、多くのテストが無効になってしまう点です。このため、正しい受信者が適切な電子メールを受け取ることを確認する必要があります。
テンプレートで名前空間変数のみを使用し、非本番環境のユーザがディレクトリ統合によってリフレッシュされる場合は、LDAP マッピングを変更して、同じ電子メール アドレスまたは類似した仮のアドレスをユーザ全員に与えることができます。次に例を示します。
User@<company>.com または
reqcentertest@<company>.com
これには、次のようなマッピングを使用します。
expr:#cn#=(cannotmatch)?(neverthis):requestcenter@<company>.com
ただし、この方法でも、電子メールが正確に配信されることを十分にテストすることはできません。
より確実な対応策は、開発インスタンスや他のインスタンス専用に、電子メールがボックスの外部には配信されない SMTP(電子メール)サーバを使用することです。 開発サーバおよびテスト サーバに対して、(仮であるかどうかにかかわらず)すべての電子メールを標準メールボックス(rctestmailbox@company.com など)に配信する SMTP サーバを設定できます。 この方法では、Service Catalog 設定を変更する必要がないため、電子メールのテストが非常に簡単になります。 プロジェクト チームは、そのテスト メールボックスを開くことができるだけで十分です。
この方法では、受信者をオーバーライドしてテスト用の電子メール ボックスに転送する別個のテスト SMTP サーバをユーザが設定する必要があります。 本番環境では、本番 SMTP サーバを指定する必要があります。
この方法を使用する場合は、これらのフィールドの名前空間式や他のロジックをテスターが検証できるようにするために、宛先および CC のアドレスを <!-- Comment --> タグで囲んで電子メール テンプレートの HTML 本文に追加します。
Service Catalog では、送信電子メールのエンベロープが制御され、デフォルトで 1 つのメッセージが複数の受信者に送信されます。 複数受信者のメッセージが同じ SMTP サーバに送信されます。
代わりに、単一受信者の電子メールを送信すると、CPU とネットワーク帯域幅の使用率への悪影響を最小限に抑えることができます。 これは、newscale.properties ファイルの次の設定によって有効になります。
Email.One.Per.Recipient=true
この設定は、1 人の受信者が無効であるためにメッセージ全体が拒否される SMTP サーバの問題を避けるためにだけ使用します。
SMTP 接続は、10 回(デフォルト)試行され、Email.ServerDownCount プロパティで設定されます。 SMTP ホストへの接続再試行は Email.RescheduleOffset プロパティで指定された時間(ミリ秒)だけ一時停止されます。
加えて、設定限度を超えるように設定されたメールボックス、電子メール バウンスなどの配信に関する問題が発生した場合は、Email.RetryCount プロパティのデフォルト設定(現在のデフォルトは 4)に基づいて再試行されます。
環境マトリクスの例に示すようなマトリクスを使用して、使用している環境のシステムを文書に記録しておくことを推奨します。
シスコでは、各バージョンの Service Catalog が認定されているソフトウェアの詳細を示すサポート マトリクスを発行しています。 Cisco Technical Assistance Center(TAC)に、このマトリクスの最新バージョンが常に用意されており、各リリースおよびサービス パックに合わせて調整されています。
以下に影響する可能性のあるシステム メンテナンス作業を実施する前に、Cisco Technical Assistance Center(TAC)に連絡することができます。
ここでは、さまざまな状況でトラブルシューティング情報を収集する方法について説明します。
「Our Apologies」例外が発生した場合、Administration モジュールの [設定(Settings)] の [デバッグ(Debugging)] オプションでサイトの「デバッグ」をオンにすることができます。
[デバッグ(Debugging)] により、現在のページの URL がページ下部に追加されます。 URL をクリックすると、シスコのサポート担当者にとって有用な追加情報のリンクが表示されます。
終了したら、エンド ユーザを混乱させないよう、デバッグをオフにします。 また、パフォーマンスに悪影響を与える可能性もあります。
アプリケーション ログは、トラブルシューティングを行うための重要なメカニズムです。 このログで「例外」(ボトムアップ方式)を調べることにより、該当するエラー メッセージが見つかることがあります。
クラスタ化された環境では、クラスタ内のすべてのマシンで対象期間内のログ ファイルを参照すると効果的です。
Service Link サーバのログには、その日のすべての Service Link トランザクションの詳細が表示されます。 Business Engine と Service Link 間のインタラクションに関係する問題をトラブルシューティングする場合は、このファイルと Service Catalog サーバ ログを相互に関連付けると有用です。
サービス設計時に発生する問題は、誤ったサービス設定に関係していることがあります。 本番環境でのみ発生する問題は、データまたはプラットフォームに依存していることがあります。
Cisco Technical Assistance Center(TAC)から、データベースのダンプを送信するよう依頼されることがあります。このダンプをテスト ラボでインストールすることにより、エラーが発生した環境を正確にエミュレートできます。 顧客には、データベースをシスコ サポート サイトにアップロードして調査できるようにするためのログインおよび資格情報が必要です。
Cisco Technical Assistance Center(TAC)に連絡してください。
WebLogic では、ServiceLink アダプタのログ ファイルがデフォルトで有効にされません。 デフォルトでは、ServiceLink アダプタのすべてのロギングが WebLogic サーバの server.log ファイルに書き込まれます。
ここでは、ServiceLink のアダプタ ログ ファイルを有効にする設定手順について説明します。 この設定手順は、ユーザが ServiceLink WAR の展開後に手動で行う必要があります。
(注) |
この項は、Service Catalog Installer がインストール時に自動的に ServiceLink アダプタ ログ ファイルを設定する JBoss には適用されません。 |
ステップ 1 |
ServiceLink アプリケーションが展開され、WebLogic サーバで実行されている場合は、WebLogic サーバを停止します。 ServiceLink アプリケーションだけを停止することはできません。WebLogic サーバ全体を停止する必要があります。 ServiceLink アプリケーションを展開していない場合、ServiceLink ディレクトリに「ISEE.war」を抽出するまで以下の手順に従います (抽出された WAR 形式で ServiceLink を展開する必要があることに注意してください)。展開を開始する前に、抽出した ServiceLink ディレクトリで、このセクションで説明されている手順を実行します。 つまり、下記のステップ 3 でステージング ディレクトリの代わりに、抽出した ServiceLink ディレクトリに移動します。 |
||
ステップ 2 | ServiceLink WAR を展開したマシンにログインします。 | ||
ステップ 3 |
次のディレクトリに移動します。 <BEA_HOME>\user_projects\domains\<domain_name>\servers\<server_name>\stage\ServiceLink\WEB-INF\classes\config |
||
ステップ 4 |
テキスト エディタを使用して、次のようにファイル「newscalelog.properties」を変更します。
UNIX または Linux の場合: logger.directory=/opt/bea/user_projects/domains/mydomain/servers/server1/logs Windows の場合: logger.directory=C:/bea/user_projects/domains/mydomain/servers/server1/logs
|
||
ステップ 5 |
WebLogic サーバを起動します。
「server1.log」と同じディレクトリに、「isee.log」という新しいログ ファイルといくつかの追加のログ ファイル(ServiceLink アダプタごとに 1 ファイル)が存在しています。 |
ここでは、重大なエラー状態に関する情報を記載しています。 この情報は、個別のエラー メッセージに基づいて示されており、状態ごとに次の情報を示します。
ログの管理も参照してください。
Service Catalog および関連コンポーネントのエラー ログは、次の場所にあります。
コンポーネント |
エラー ログの場所 |
---|---|
アプリケーション サーバ(Application Server) |
|
WebLogic |
<BEA_HOME>/user_projects/domains/<domain>/servers/ <server>/logs/<server>.log |
JBoss |
<JBOSS_HOME>/ServiceCatalogServer/log, <JBOSS_HOME>/ServiceLinkServer/log |
Administration モジュールのサポート ユーティリティを設定してアプリケーション ログ ファイルへの GUI アクセスを有効にしている場合は、前述のログファイルを参照してダウンロードできます。
次のエラー状態は、エラー状態または関連するエラー メッセージに基づいて示されます。
エラー自体はシステム内のいくつかの異なるエラー状態が原因であっても、複数のエラー状態が同じシステム動作を引き起こすことがあります。 たとえば、LDAP サーバに接続できない場合、次に示すいくつかのエラー状態が該当することがあります。 発生しているエラーとエラー メッセージを一致させることが重要です。
すべてのエラーは、Service Catalog サーバ ログ ファイルに書き込まれます。このファイルの動作と場所については、上記の説明を参照してください。
カテゴリ |
説明 |
---|---|
エラー状態 |
Service Catalog は、要求の送信後またはサービス内の最終承認/確認後に、タスク計画を非同期にインスタンス化することができません。 |
エラー メッセージ |
Requisition xxx [Task “<name of task here >”]: We’re sorry but his approval/review cannot be completed at this time because the Service Catalog queue that processes these tasks is temporarily unavailable. Please try again later or contact your Service Catalog system administrator. |
解像度 |
非同期送信/最終承認プロセスを処理する JMS キューが、メッセージを受信するために使用可能かどうかを確認します。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
アプリケーション サーバでデータベースへの接続が失われました。 |
エラー メッセージ |
ERROR [com.celosis.logger.FatalerrorChannel] (8000)SQLException in getConnection:Could not create connection; - nested throwable: (java.sql.SQLException: [newScale][SQLServer JDBC Driver]Error establishing socket. Connection refused: connect); - nested throwable: (org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: [newScale][SQLServer JDBC Driver]Error establishing socket. Connection refused: connect)) Code: 0 State: null. |
解像度 |
RequestCenter データベースを確認します。 RequestCenter データベースが実行されていない場合は、起動します。 このデータベースが起動すると、アプリケーション サーバが自動的に接続されます。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー コード(Error Code) |
LDAPException 91. |
エラー状態 |
LDAP サーバに接続できません。 LDAP サーバが停止しているか、ポート番号が正しくない可能性があります。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPNonSSLConnection] LDAPException in NON-SSL Connection: LDAPException: Unable to connect to server <hostname>:<port> (91) Connect Error java.net.ConnectException: Connection refused: connect |
解像度 |
LDAP サーバが実行されているかどうかを確認します。 実行されていない場合は、LDAP サーバを起動します。 [管理(Administration)] > [ディレクトリ(Directories)] で LDAP システム接続パラメータを確認します。 Connection Port の値が正しいことを確認します。 Service Catalog アプリケーションを再起動する必要はありません。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー コード(Error Code) |
LDAPException 91 |
エラー状態 |
LDAP サーバに接続できません。 ホスト名が正しくない可能性があります。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPNonSSLConnection] LDAPException in NON-SSL Connection: LDAPException: Unable to connect to server <hostname>:<port> (91) Connect Error java.net.UnknownHostException: <hostname> |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] で LDAP システム接続パラメータを確認します。 LDAP Host の値が正しいことを確認します。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー コード(Error Code) |
LDAPException 32 |
エラー状態 |
LDAP サーバに接続できません。 認証済みユーザ ID が正しくない可能性があります。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPSimpleAuth] LDAPException in Simple Auth: LDAPException: No Such Object (32) No Such Object LDAPException: Matched DN: |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] で LDAP システム認証パラメータを確認します。 BindDN の値が正しいことを確認します。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー コード(Error Code) |
LDAPException 49 |
エラー状態 |
LDAP サーバに接続できません。 認証済みパスワードが正しくない可能性があります。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPSimpleAuth] LDAPException in Simple Auth: LDAPException: Invalid Credentials (49) Invalid Credentials |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] で LDAP システム認証パラメータを確認します。 [パスワード(Password)] フィールドは暗号化されているため、既存の値を確認できません。 パスワードの正しい値を入力して、[更新(Update)] をクリックします。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
LDAP サーバに接続できません。 |
エラー メッセージ |
FATAL [LDAPBase] LDAP instance cannot be created netscape.ldap.LDAPException: no host for connection (89) |
解像度 |
LDAP サーバが実行されているかどうかを確認します。 実行されていない場合は、LDAP サーバを起動します。 Service Catalog アプリケーション サーバを再起動する必要はありません。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
LDAP サーバに接続できません。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.LDAPQuery] LDAP netscape.ldap.LDAPException: failed to connect to server ldap://<hostname>:<port> (91) |
解像度 |
LDAP サーバが実行されているかどうかを確認します。 実行されていない場合は、LDAP サーバを起動します。 Service Catalog アプリケーション サーバを再起動する必要はありません。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー状態 |
LDAP サーバで認証に失敗します。 |
エラー メッセージ |
ERROR [com.newscale.comps.user.dao.LDAPUserDataSource] Single Person search failure, exception thrown: null com.newscale.bfw.dataaccess.DataAccessException |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] ページで [データ ソース設定(Data Source Configuration)] を確認します。 Service Catalog アプリケーション サーバを再起動する必要はありません。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
いずれかの必須属性のマッピングに誤りがあります。 そのため、LDAP サーバで個人を検索できません。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.LDAPQuery] LDAP java.lang.RuntimeException: Required LDAP attribute <attribute_name> is missing from the LDAP system. |
解像度 |
ディレクトリ データ マッピング内の属性名を修正します。 Service Catalog アプリケーション サーバを再起動する必要はありません。 |
カテゴリ |
説明 |
---|---|
エラー コード(Error Code) |
LDAPException 32 |
エラー状態 |
LDAP サーバでユーザのベース DN が見つかりません。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPApi] Referral Exception during Result Set iteration: LDAPException: No Such Object (32) No Such Object |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] ページで [LDAPシステムの認証パラメータ(LDAP System Authentication Parameters)] を確認します。 [LDAPユーザのベースDN(LDAP User BaseDN)] の値が正しいことを確認します。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー状態 |
(SSL 接続のみ)SSL 証明書のキーストアが作成されていないため、SSL モードで LDAP サーバに接続できません。 |
エラー メッセージ |
DEBUG [com.newscale.bfw.ldap.util.LDAPConfUtil] The LDAP configuration file “config/<LDAP_System>_TrustCertDB.keystore” does not exist. |
解像度 |
[管理(Administration)] > [ディレクトリ(Directories)] ページで LDAP システムに適切なサーバ証明書を追加します。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー状態 |
(SSL 接続のみ)キーストアのサーバ証明書が正しくないため、SSL モードで LDAP サーバに接続できません。 |
エラー メッセージ |
ERROR [com.newscale.bfw.ldap.jldap.JLDAPSimpleAuth] LDAPException in Simple Auth: LDAPException: I/O Exception on host <hostname>, port <port number> (91) Connect Error javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found |
解像度 |
証明書のキーストアはすでに存在していますが、この LDAP サーバで使用する正しい証明書が含まれていません。 LDAP サーバに使用する正しい証明書を取得し、[管理(Administration)] > [サイト設定(Site Configuration)] ページでその証明書を同じ LDAP システムに追加します。 |
カテゴリ(Category) |
説明(Description) |
---|---|
エラー状態 |
[新しいユーザの共通OU(Common OU for new users)] の設定値が欠落しているか、RequestCenter データベースに存在しません。 |
エラー メッセージ |
ERROR [com.newscale.comps.user.dao.LDAPUserDataSource] Error getting Person from Ldap java.lang.NullPointerException at com.newscale.comps.user.dao.LDAPUserDataSource. transferOrgUnitVOToBO(LDAPUserDataSource.java:676) |
解像度 |
[管理(Administration)] > [サイト設定(Site Configuration)] ページで、[LDAPシステム検索設定(LDAP System Lookup Configuration)] をオンにします。 [新しいユーザの共通OU(Common OU for new users)] フィールドに正しい値を選択します。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
<attribute_name> のマッピングに誤りがあります。 このため、LDAP サーバで個人を検出できません。 |
エラー メッセージ |
WARN [com.newscale.bfw.ldap.jldap.JLDAPApi] Required LDAP attribute <attribute_name> is missing from the LDAP system, for DN : ... |
解像度 |
該当する LDAP システムに対して、[ディレクトリマッピング(Directory Mapping)] ページで属性名を修正します。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
いずれかの参照 LDAP システムに接続できません。 (設定フラグが SkipErrorOnLDAPSystem=true であるため、Service Catalog システムではこのエラーが無視されます)。 |
エラー メッセージ |
WARN [com.newscale.bfw.ldap.jldap.JLDAPApi] Referral Exception during Result Set iteration: LDAPReferralException: Search result reference received, and referral following is off (10) |
解像度 |
参照 LDAP サーバが実行されているかどうかを確認します。 参照 LDAP システムの認証と接続を確認します。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
外部データ ディクショナリ データベースに接続できません。 |
エラー メッセージ |
ERROR [STDERR] SQLException while attempting to connect: java.sql.SQLException: [Macromedia][SQLServer JDBC Driver]Error establishing socket. Connection refused: connect. |
解像度 |
外部データ ディクショナリ データベースを確認します。 外部データ ディクショナリ データベースが実行されていない場合は、起動します。 Service Catalog アプリケーションを再起動する必要はありません。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
データベースへの接続が失われました。 |
エラー メッセージ |
ERROR [com.celosis.logger.FatalerrorChannel] (8000)SQLException in getConnection: Could not create connection; - nested throwable: (java.sql.SQLException: [newScale ][SQLServer JDBC Driver]Error establishing socket. Connection refused: connect) |
解像度 |
データベースを確認します。 データベースが実行されていない場合は起動します。 このデータベースが起動すると、アプリケーション サーバが自動的に接続されます。 |
カテゴリ |
説明 |
---|---|
エラー状態 |
外部データ ディクショナリ データベースに接続できません。 |
エラー メッセージ |
ERROR [com.newscale.bfw.udkernel.udsql.UdSqlBean] Message: [newScale][SQLServer JDBC Driver]Connection reset by peer: socket write error. |
解像度 |
外部データ ディクショナリ データベースを確認します。 外部データ ディクショナリ データベースが実行されていない場合は、起動します。 Service Catalog アプリケーションを再起動する必要はありません。 |
Universal Development Methodology(UDM)の標準処理では、サイトがオンラインになった時点で、実装されたサイトごとにこのマトリクスの列を完成させます。 通常、シスコの拡張サービスの成果物には、このマトリクスのソフト コピーが含まれており、管理者はそれを最新に保つ必要があります。
カテゴリ |
サイト名および使用法(開発など) |
---|---|
WebServer |
|
フロント ドア Cisco Prime Service Catalog のURL |
|
管理 Cisco Prime Service Catalog の URL |
|
Host1:ポート |
|
共有環境かどうか |
|
Hardware |
|
使用可能ディスク |
|
オペレーティング システム(Operating System) |
|
OS ログイン/パスワード |
|
WebServer タイプ/バージョン |
|
|
|
AppServer |
|
ホスト 1 |
|
共有環境かどうか |
|
Hardware |
|
使用可能ディスク |
|
オペレーティング システム(Operating System) |
|
サポート ログイン/パスワード |
rcsupport/rc |
インストーラ ログイン/パスワード |
requestcenter/rc |
RC パス |
/apps/rc |
RC.ear パス |
/apps/rc/RC.ear |
ISEE.war パス |
/apps/rc/ISEE.war |
ログ パス |
/logs/rc |
キュー接続ファクトリ |
RCQueueConnectionFactory |
BE 要求キュー |
BEEERequisitionsQueue |
BE 承認キュー |
BEEEAuthorizationsQueue |
BE 受信キュー |
BEEEInboundQueue |
JDK |
|
JDK パス |
/usr/local/java |
アプリケーション コンテナ |
|
タイプ/バージョン |
|
AppHost1 RC/SL JNDI のポート |
|
メール |
|
SMTP Server |
smtpserver.domain.com |
管理者の電子メール アドレス |
|
送信元の電子メール アドレス(From Email Address) |
ServicePortalDev@mailserver.company.com |
|
|
WebLogic |
|
コンソール URL |
|
ユーザ名/パスワード |
|
ノード名 |
|
アプリケーション サーバ(Application Server) |
RequestCenter |
仮想ホスト |
requestcenter_host |
|
|
サービス カタログ(Service Catalog) |
|
インストールされるコンポーネント |
すべて(All) |
マルチキャスト IP |
225.2.2.2 |
インストールされるビルド |
11.2.1.0151 |
Admin ログイン/パスワード |
|
カスタマイゼーション |
|
適用されるパッチ/ホットフィックス |
|
その他のカスタマイゼーション |
|
|
|
データベース |
|
Host1:ポート |
|
共有環境かどうか |
|
Hardware |
|
使用可能ディスク |
|
オペレーティング システム(Operating System) |
|
OS ログイン/パスワード |
|
DB タイプ/バージョン |
|
DB SID/データベース |
RQSTDEV |
テーブルスペース |
RequestCenter(GB 数) |
REDO ログ |
|
DB SA のユーザ名/パスワード |
sa/pwd |
DB RC スキーマ/パスワード |
RCUser/rc |
DB アプリケーションのユーザ名/パスワード |
|
|
|
アドバンス レポート |
|
Cognos ホスト:ポート |
|
Cognos ハードウェア |
|
使用可能ディスク |
|
Cognos OS |
Windows 2008 |
Windows ログイン/パスワード |
rcuser/c1$c0 |
Admin ログイン/パスワード |
admin/admin1234 |
サービス アカウント |
|
パス |
|
ゲートウェイ タイプ(Gateway Type) |
|
Web プロトコル |
|
|
|
データ マートおよびコンテンツ ストア |
|
JNDI 名 |
java:/DATAMARTDS |
DB タイプ/バージョン |
|
DB サーバ:ポート |
|
DB SID/名 |
RCDMDEV |
データ マートのユーザ名/パスワード |
DMUser/dm |
コンテンツ ストア SID/名 |
RCCSDEV |
コンテンツ ストアのユーザ名/パスワード |
CSUser/cs |
テーブルスペース |
RCDataMart(500M) |
Advanced Reporting のオプション |
|
ディクショナリ テーブル |
150 |
サービス テーブル |
50 |
ディクショナリ テーブル パターン |
DM_FDR_DICTIONARYTABLE_ |
サービス テーブル パターン |
DM_FDR_SERVICETABLE_ |
フィールド パターン |
FIELD |
ディクショナリのテキスト タイプ フィールド |
40 |
ディクショナリの数値タイプ フィールド |
10 |
ディクショナリの日付タイプ フィールド |
10 |
サービスのテキスト タイプ フィールド |
80 |
サービスの数値タイプ フィールド |
20 |
サービスの日付タイプ フィールド |
20 |
テキスト フィールドの最大サイズ |
200 |
更新に対する WDDX のリフレッシュ |
はい/いいえ(Yes/No) |
|
|
サービス リンク |
|
ホスト |
localhost |
キュー ホスト:ポート |
localhost:5099 |
ベース URL |
|
キュー接続ファクトリ |
RCQueueConnectionFactory |
送信キュー |
SLOutboundQueue |
受信キュー |
SLInboundQueue |
JMS キューのユーザ名/パスワード |
guest/guest |
JMS ファイル ストア(WLS 専用) |
ServiceLinkFileStore |
JMS ファイル ストア(WLS 専用) |
|
JMS サーバ |
RCServer |
LDAP |
|
サーバ タイプ(Server Type) |
|
LDAP 認証 |
シンプル |
SASL メカニズム |
— |
BindDN |
|
BindDN のパスワード |
|
接続メカニズム |
非 SSL |
SSL タイプ |
— |
LDAP ホスト |
|
接続ポート |
389 |
セキュア ポート |
— |
LDAP ユーザのベース DN |
|
オプションの LDAP フィルタ |
|