この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
• 「概要」
• 「統合の管理」
• 「Service Link アダプタの追加インストール」
• 「Service Link 受信ドキュメントの SSL の設定」
• 「Service Link 送信ドキュメントの SSL の設定」
• 「エラー」
• アプリケーション コンポーネントの起動およびシャットダウンの手順
• アプリケーション コンポーネントの設定管理およびカスタマイズ
この章は、システム管理者と、Cisco Service Portal(Service Portal)のサポートを担当するその他の IT 専門技術者を対象としています。この章では、企業のシステム管理に精通していることを前提としています。
<APP_HOME> と指定されている場合は、Service Portal がインストールされているルート ディレクトリを示しています。
ここでは、アプリケーション サーバの起動とシャットダウンの手順について説明します。対象となるサーバは次のとおりです。
• Request Center(Demand Center、Lifecycle Center、および Portal Manager を含む)
• Request Center Integration Server(Service Link)
JBoss アプリケーション サーバを使用した標準インストール環境の場合、Request Center はアプリケーション サーバとともに開始および停止されます。
<APP_HOME>/bin ディレクトリにインストールされた一連のコマンドを使用すると、Request Center のサービスを起動および停止したり、それらのサービスをインストールまたはアンインストールしたりできます。
|
|
WebSphere の起動方法の詳細については、『 Cisco Service Portal Installation Guide 』を参照してください。
ネットワーク クラスタ構成で展開する場合は、ノード マネージャの再起動が必要になる場合があります。サーバを再起動できない場合でも、ほとんどは WebSphere 管理コンソールを使用して Request Center および Service Link の各アプリケーションを再起動すれば十分です。
WebLogic の起動方法の詳細については、『 Cisco Service Portal Installation Guide 』を参照してください。
Service Portal の通常動作時に管理サーバを再起動する必要はありません。ただし、インストール時にカスタム データベース ドライバをインストールする場合には再起動が必要です。
Cognos コンポーネントに依存する Advanced Reporting のすべてのインストールは Windows システム上にあるため、Cognos Configuration Manager から、または Windows サービスを使用して Cognos アプリケーションを再起動する手順は、どちらも Windows 固有のタスクです。
システムを再起動するには、Cognos Configuration Manager を起動した後、次の手順を実行します。
ステップ 1 [Program Files] > [Cognos Tools] > [Configuration Manager] の順に選択します。
ステップ 2 [Star Tab] > [Open Current Configuration] をクリックします。
ステップ 3 マシン名(ツリーの最上位ノード)を選択して右クリックし、[Stop]/[Start] を選択します。
ここでは、継続的なメンテナンス タスクの実行方法について説明します。
完全に展開されたシステムのコンポーネントには、Request Center、Integration Server(Service Link)、および Advanced Reporting(Cognos)が含まれています。Request Center および Integration Server はそれぞれ、Request Center.ear および ISEE.war の各展開パッケージ内のアプリケーション サーバに展開されます。
各コンポーネントは展開されているとおりにバックアップし、すべてのカスタマイゼーションは展開時または変更時に保存することを推奨します。(詳細については、「Service Link アダプタの追加インストール」を参照してください)。
データベースの定期的なスケジュール バックアップも推奨されます。次の 3 つのデータベースをバックアップする必要があります。
• トランザクション データベース(デフォルトでは Request Center)。実稼動データのみでなく、設定サービス、サービス コンポーネント、およびその他のアプリケーション オブジェクトのメタデータも保存されています。
• 分析データベース。標準レポートの作成用データおよび Request Center と Demand Center のデータ マート用データが保存されています。
• 「コンテンツ保存」データベース。ビジネス視点のレポート環境で使用可能なユーザ生成コンテンツが保存されています。このようなコンテンツには、すべてのレポートの定義(Service Portal から提供された定義と Advanced Reporting のユーザから書き込まれた定義)、レポートのビュー、スケジュール、および任意のレポートから生成された保存済みのレポートが含まれます。
チューニングの推奨事項に関する追加情報については、アプリケーション サーバ固有のマニュアルを参照してください。次に示す推奨事項は、多くの Service Portal サイトに適用できることがわかっています。
組織に遠隔地のユーザが多数いる場合は、HTTP 応答の GZIP 圧縮(RFC 1952)をオンにすると役立ちます。RFC 2616 の次のセクションを参照してください。
• セクション 14.11:Content-Encoding
GZIP 圧縮は、低速または遅延の大きいネットワークを使用するユーザにとって有用です。ただし、GZIP 圧縮により、サーバとユーザのブラウザにわずかながらオーバーヘッドが発生します。
GZIP 圧縮をイネーブルにするには、次の手順を実行します。
ステップ 1 RequestCenter.war/WEB-INF で web.xml を探します。たとえば、標準では次の場所にあります。
ステップ 2 次のエントリを検索します(コメントアウトされています)。
ステップ 3 コメントを削除します。エントリは次のようになります。
ステップ 4 次のエントリを検索します(コメントアウトされています)。
ステップ 5 コメントを削除します。エントリは次のようになります。
Java のメモリ設定は、アプリケーション サーバが使用する Java 仮想マシン(JVM)専用の設定です。「java -h」コマンドおよび「java -X」コマンドを使用すると、システムで使用可能なすべてのオプションのリストが返されます。これらのコマンドを発行する場合は、アプリケーション サーバが使用する JVM と同じ JVM を呼び出していることを確認してください。
• 必要に応じて -ms -mx(通常は、JVM 内のヒープとして 1 GB のメモリが予約されます)。
• Sun JVM には -server モードが推奨されます。
• 一般的な変更として、引数 --XX:MaxPermSize=128m を指定して、ガベージ コレクタの永続的世代の最大サイズを 128 MB に増やします。
Service Portal で「out of memory」エラーが発生する場合は、JVM で使用可能な最小および最大のヒープ サイズを管理する Java メモリ スイッチのチューニングが必要な場合があります。たとえば、次の設定は WebLogic に正しく適用されます。
この設定では、HTTP または AJP コネクタによって作成される要求処理スレッドの最大数を制御します。したがって、この設定により、同時に処理可能な要求の最大数が決まります。デフォルトのスレッド数を使い果たし、ISAPI がクラッシュするようなまれなケースでは、次の手順で最大スレッドを変更します。
• <NS_HOME>/jboss-4.2.3.GA/server/RequestCenter/deploy/jboss-web.deployer ディレクトリで「server.xml」という名前のファイルを編集します。
JDK を新しいバージョンにアップグレードするには、次の手順を実行します。
• <APP_HOME>/bin ディレクトリで「setEnv.cmd」という名前のスクリプトを編集し、新しい JDK へのパスを指定します。
• スタートアップ スクリプトを使用している顧客の場合は、改訂された setEnv.cmd ファイルを保存した後、サーバを再起動します。
• Windows サービスを使用している顧客の場合は、Windows サービスを停止し、(<APP_HOME>¥bin¥uninstall*.cmd のスクリプトを使用して)Windows サービスをアンインストールした後、(<APP_HOME>¥bin¥install*.cmd のスクリプトを使用して)そのサービスを再度インストールします。
Service Portal データベースのデータベース チューニングは、「具体的なデータベース タイプ(Oracle または SQLServer)のチューニングに一般的なベスト プラクティスを使用する」という一文に要約できます。
ただし、Service Portal データベースを設定およびチューニングする方法に関する主な FAQ のいくつかと、それらの質問への回答を示すことができます。これらの問題の詳細については、該当するデータベースに固有のマニュアルを参照してください。これらの FAQ の多くは、SQLServer よりもチューニングの機会が多い Oracle に関するものです。
• Oracle および SQLServer のどちらの場合も、RAID 5 ではなく、RAID 1+0(ストライプ化 + ミラー化)ディスクにデータベース ファイルをインストールすることが推奨されます。これが、ソフトウェアのインストールに推奨される選択肢です。
• Oracle データベースは、ローカル管理表領域(LMT)および自動セグメント領域管理(ASSM)を使用するように設定する必要があります。これらのテクノロジーによって、テーブルまたはテーブルスペースのパラメータ(PCTUSED、PCTFREE、INITIALEXTENT、NEXTEXTENT)が正しく指定されないというこれまでの問題が解消されます。
• OLTP Service Catalog および OLAP データベース(標準レポートと Service Portal データ マート)用には別々のデータベースまたはインスタンスを使用します。10g よりも前のリリースの Oracle の場合、ブロック サイズの異なるテーブルスペースを作成するには、このことが必須でした。10g 以降の場合でも、OLTP データベースと OLAP データベースの大きく異なるアクティビティに合わせて設定パラメータを調整できるように、このことが推奨されます。Oracle DBA は、データ ウェアハウスのデータベース管理について詳しく書かれた Oracle のマニュアルを読む必要があります。
• OLTP データベースの場合は、REQUESTCENTER という名前のプライマリ テーブルスペースを作成します。このテーブルスペースには 1 ユーザにつき 10 MB、最小サイズ 500 MB を指定します。データベース管理者は、組織のベスト プラクティスに最適なエクステント管理方針を選択する必要があります。
• 必要なデータベース ストレージを非常におおまかに見積もると、完了した要求ごとに 500 kb となります。これは、サービス フォームの複雑さ、承認構造、および提供計画によって大きく異なります。
• 多数の Service Link タスクを含むサイトでは、Service Link メッセージの保存が原因でデータベース サイズが非常に大きくなることがあります。最新バージョンの Service Portal には、これらのメッセージを圧縮するさらに効率的なアルゴリズムと、メッセージ コンテキストを設定する方法が追加されています。詳細については、『 Cisco Service Portal Integration Guide 』を参照してください。完了したタスクの Service Link メッセージを消去するデータベース スクリプトが RequestCenter データベースのストアド プロシージャとして用意されており、ワンタイム ジョブとして実行したり、定期的に実行したりできます。
• OLTP データベース(テーブルとインデックス)の統計情報を定期的に収集します。これは 10g Oracle Enterprise Manager(OEM)を介して自動化できます。
• カラムレベルのヒストグラム分析を実行して、Request Center Service Manager のインデックスをさらに最適化します。
• Service Portal データ マートがリフレッシュされた後に、データ マートの統計情報を収集します。
• テーブル割り当て、テーブルスペースのフラグメンテーション、および行連鎖を確認します。
• クエリーのパフォーマンスをモニタリングするために SELECT_CATALOG_ROLE へのアクセス権を付与します。
• Oracle 10g の場合は次のような設定を適用します。
|
|
RequestCenter データベースのすべてのテーブルおよびインデックスに関する統計情報を収集するには、DBMS_STATS.GATHER_SCHEMA_STATS コマンドを使用します。次の例では、「RC User」がスキーマの所有者です。
「Managing Optimizer Statistics」に関する Oracle データベース管理の章では、次の点を推奨しています。
• DBMS_STATS でテーブルの統計情報を収集する場合、テーブル内のカラムのデータ分布に関する情報が収集されます。データ分布に関する最も基本的な情報は、カラムの最大値と最小値です。ただし、カラム内のデータがスキューしている場合、このレベルの統計情報ではオプティマイザのニーズからすると不十分な可能性があります。スキューしたデータ分布の場合は、指定したカラムのデータ分布を記述するカラム統計の一部として、ヒストグラムを作成することもできます。
• ヒストグラムは、DBMS_STATS 収集プロシージャの METHOD_OPT 引数を使用して指定されます。Oracle Corporation では、METHOD_OPT を FOR ALL COLUMNS SIZE AUTO に設定することを推奨しています。この設定を使用すると、ヒストグラムを必要とするカラムおよび各ヒストグラムのバケット数(サイズ)が、Oracle によって自動的に決定されます。また、ヒストグラムが必要なカラムと各ヒストグラムのサイズは手動で指定することもできます。
ヒストグラムレベルの統計情報の収集が不可欠なテーブルは、次のとおりです。
各テーブルの統計情報を収集する DBMS_STATS コマンドの例は、次のようになります。
SQLServer 2005 の場合は、次のコマンドでスナップショットをイネーブルにします。
特に Service Portal の揮発性テーブルの場合は、SQLServer の DBCC Reindex コマンドが推奨されます。このプロセスは、勤務時間外で定期的にスケジュールする必要があります(一般的には週に 1 度)。
次に示すテーブルは最も揮発性が高く、DBCC Reindex の対象となります。
Cognos では、すべてのレポートおよびクエリーの定義が ContentStore というデータベース内に格納されます。Cognos KnowledgeBase には、ContentStore のサイズ変更と維持に関するエントリが格納されます。特に重要なのは、ContentStore に必要なサイズを算出するために、予測される使用状況の統計に基づいて発行される計算式です。
これらの計算式を組み込んだスプレッドシートは、Cisco Technical Assistance Center(TAC)から入手可能です。次に例を示します。
|
|
|
|
トランザクション データベースは、プレフィックス命名規則を採用した一連のリレーショナル テーブルで構成されます。では、これらのプレフィックスの厳密な意味は何でしょうか。DBA または実稼動データベースの維持やチューニングが必要な人への支援として、次の表を示します。これらのテーブルの構造およびコンテンツの所有権はシスコに帰属します。シスコでは、リリースごとにテーブルの名前または構造を自由に変更する権利を留保します。
ここでは、Service Portal の次の J2EE アプリケーション コンポーネントに関する情報を提供します。
• Request Center:このコンポーネントは、アプリケーションの中核を構成します(Request Center、Demand Center、Lifecycle Center、Portal Manager の各製品でユーザに表示されるあらゆる画面、すべての検査、ヘルプ画面、および API)。
• Service Link(IS または ISEE):これは Integration Server です。エージェントおよびアダプタを使用して、さまざまなサードパーティ システムとの統合を可能にします。
ここでは、アプリケーションの展開方法、重要な設定ファイル、WebSphere、WebLogic、JBoss の管理、および ColdFusion の管理方法について説明します。また、データ ソースの使用と外部データ ディクショナリの「補助テーブル」の作成、キャッシュされたデータ、アプリケーションのセキュリティ、パッチの適用、およびマルチキャスト設定に関する情報も示します。
Request Center の .ear ファイルはファイル システムに展開されます。このファイルには、Request Center サービスのプレゼンテーション レイヤとなる .war ファイルが含まれています。これらのファイルの正確な場所は、アプリケーション サーバによって異なります。たとえば、WebSphere 実装の場合、通常、これらのファイルは次のようなパスの下にあります。
/apps/WebSphere/AppServer/profiles/newScale/installedApps/Cell/RequestCenter.ear
Service Link アプリケーションは ISEE.war という .war ファイルとして提供されます(Integration Server Enterprise Edition)。WebSphere アプリケーション サーバでは、スタンドアロンの .war ファイルが .ear に自動的に「ラップ」されます。
サーバを再起動するには、アプリケーション サーバのサーバ コンソール、またはコマンドライン スクリプトを適宜使用します。必ず展開環境で管理者がスクリプトを使用できるようにしてください。
展開に関して詳細を参照する必要がある重要なファイルを次に示します。このマニュアルに明記されているか、Cisco Technical Assistance Center(TAC)からの指示がないかぎり、プロパティ ファイルと、類似の設定ファイルはすべて読み取り専用だと見なしてください。これらのプロパティ ファイルのいずれかを変更した場合は、サービスを再起動する必要があります。
このファイルは、インストールまたはアップグレード プロセス中、およびインストーラが実行されるたびに、インストーラによって作成されます。インストーラによってファイルが作成されると、RequestCenter.ear/config フォルダに保存されます。したがって、ear が再展開されると、このファイルも常に再展開されます。Request Center 管理者はファイルに含まれるデータを保持する必要があります。ただし、新しいバージョンではインストーラによって新たな情報が追加されている場合があるため、単純にファイルをコピーして復元することは しないで ください。newscale.properties のエントリは次のとおりです。
• udk.datasource.jndi:RC データベースの JNDI 名
このファイルは RequestCenter.ear のルートにあります。be.properties のエントリは次のとおりです。
• ObjectCache.Application.URL:送信された電子メールに含まれる Request Center への URL 参照
• ObjectCache.email.host:メール リレーの SMTP ホスト
このファイルも RequestCenter.ear のルートにあります。これには、Request Center の内部通信用の JMS 設定が含まれます。キュー名がアプリケーション サーバ上のキュー名と一致することを確認してください。
このファイルは、JBoss システムの <APP_HOME>/jboss-4.2.3.GA/server/ServiceLink/conf フォルダにあります。WebSphere および WebLogic アプリケーション サーバの場合、このファイルは ISEE.war/WEB-INF/classes フォルダにあります。このファイルには、統合サーバ(Service Link)の重要なプロパティが含まれています。
Service Portal はアプリケーション サーバのログ ファイルを保持し、アプリケーションの予期されたアクティビティと予期しないアクティビティをどちらも追跡します。ログは、オープン ソース(Apache)のロギング メカニズムである log4j をベースとするフレームワークを使用して管理されます。デフォルトではログに「rolling appender」が設定されており、新しいログ ファイルが毎日開かれます。アプリケーション サーバのタイプによってログ ファイルの内容と設定を調整する機能が異なるため、ログ ファイルの場所もアプリケーション サーバのタイプによって異なります。
• 企業で指定した保持期間よりも古くなったログをバックアップまたは削除
Service Portal はログ ファイルを保持する必要がありません。ログ ファイルは、主にエラーが発生した場合のトラブルシューティング ツールとして有用です。
デフォルト ログ ファイルの形式は Cisco Technical Assistance Center(TAC)で想定する形式であるため、この形式を変更することは推奨しません。その代わり、顧客は自分たちのニーズを満たす独自のアペンダーを作成できます。
Service Link はシステム全体のログ ファイルに加えて、アダプタ タイプごとに個別のログ ファイルを使用するように設定されています。これらのログも log4j で管理されます。Service Link のロギングはデフォルトでイネーブルになっています。ServiceLink¥logs ディレクトリに書き込まれるアダプタ固有のログ ファイルを次に示します。
ロギングのシステム パフォーマンスが問題になる場合があります。すべてのログを記録する DEBUG レベルをイネーブルにすると、ログのサイズが急激に大きくなります。このため、フル デバッグおよびトレース レベルのロギングをイネーブルにするのは短期間にとどめる必要があります。システムのパフォーマンスが大幅に低下する可能性があるため、実稼動システムでのロギングは最小限とし、問題を再現するために必要な期間のみとする必要があります。
ログ エントリには E (エラー)、 W (警告)、 I (情報)、 D (デバッグ)の 4 種類があり、この順で重大度が低下します。ログの一部分の例は、次のようになります。
Request Center はほとんどのメッセージを STDOUT に転送し、WebSphere はこれを SystemOut.log にログ記録します。SystemErr.log には、すべての WebSphere エラーおよび Request Center のタイミングとメモリ使用状況に関する情報が含まれます。通常はどちらのログも次のようなパスにあります。
/apps/WebSphere/AppServer/profiles/cisco/logs/server1
トレースは、アプリケーションの特定領域に焦点を当ててイネーブルにすることができます。サーバのトレース ログは、特定の Java クラスまたはパッケージに対してイネーブルにすることができます。一般的なロギングとトレーシングは、WebSphere で認識されるすべての公開クラスについてイネーブルになります。その他の非公開クラスを追加することもできます(ただし、ロギングが必要となる状況に応じて、ケースバイケースで Cisco Technical Assistance Center(TAC)が具体的なクラス名を指定する必要があります)。
実行時ロギングは、WebSphere 管理コンソールの GUI を使用して選択できるオプションです。実行時ロギングを行うと、サーバまたはアプリケーションを再起動やリブートすることなく、選択したクラスのロギングおよびトレーシングをイネーブルにすることができます。
通常、すべてのログ ファイルおよび場所は log4j.xml ファイルで定義されます。ただし、WebSphere ではこの点もさらに制御できます。WebSphere のほぼすべてのロギングについて、SystemOut.log ファイル、およびこのファイルがあるディレクトリの他のすべてのログ ファイルがトラブルシューティングに関係し、このために必要となります。場合によっては、アダプタのログ ファイルも存在します。通常、Service Link サーバの SystemOut.log ファイルが生成された場所には、これらが常に生成されます(クラスタで動作している場合)。クラスタ内の各ノードには独自の SystemOut.log および関連ログ ファイルがあるため、これらのファイルがトラブルシューティングに必要になる場合があります。
トレースのパラメータと場所に関するログ ファイルのプロパティは、WebSphere 管理コンソールまたは WebSphere サーバに関連付けられた log4j.xml、あるいはその両方の設定で制御されます。ロギングの有効化は非常に直感的で、WebSphere 管理者が実行できる重要な操作です。
WebLogic では、Request Center は WebLogic のロギング設定に従ってメッセージを転送します。デフォルトでは、すべてのロギングが WebLogic サーバのログに書き込まれます。通常、このログは次のようなパスにあります。
/apps/bea/user_projects/domains/cisco/servers/nsServer/logs/nsServer.log
JBoss のログは <APP_HOME>/jboss-4.2.3.GA/server/RequestCenter/log/ の下にあります。ロギング動作を決定する jboss-log4j.xml ファイルは <APP_HOME>/jboss-4.2.3.GA/server/RequestCenter/conf の下にあります。
Request Center はほとんどのメッセージを STDOUT に転送し、JBoss はこれを jboss_out.log にログ記録します。JBoss_err.log には、すべての JBoss エラーおよび Request Center のタイミングとメモリ使用状況に関する情報が含まれます。
パフォーマンスを改善するには、次の内容を追加して jboss-log4j.xml を変更します。
この変更により、デバッグ呼び出しがより早く捕捉されるようになり、J2EE コンテナ内で多くのコンテキスト スイッチが不要になります。
Catalog Deployer およびサービスのインポート/エクスポートは ColdFusion MX 6.1 のページを利用します。これらのページは、JEE コンテナで動作する ColdFusion アプリケーションによって解釈されます。ColdFusion 管理者は、次の場所からアクセスできます。
http://<host>:<port>/RequestCenter/CFIDE/Administrator/index.cfm
ColdFusion 管理者は、主に Catalog Deployer で使用するデータ ソースの追加および削除に利用されます。
Service Portal では、デフォルトで ColdFusion の「Request Center」データ ソースをインストールおよび使用します。また、Catalog Deployer は ColdFusion データ ソースを使用して展開サイトにアクセスします。展開マネージャはこのようなデータ ソースを作成し、展開パッケージのサイト間送信をイネーブルにする必要があります。
アプリケーション内のすべてのデータ ソースでは、大文字と小文字が区別されます。
ColdFusion データ ソースの作成には ColdFusion 管理者を使用します。手順の詳細については、『 Cisco Service Portal Installation Guide 』を参照してください。次に要約を示します。
ステップ 1 ColdFusion 管理 URL(http://<hostname>:<port>/RequestCenter/CFIDE/Administrator/index.cfm)に接続します。
ステップ 2 パスワード「A$ta1aV1$ta」を使用してログインします。
ステップ 3 左側のパネルで [Data Sources] リンクをクリックします。
ステップ 4 既存のデータ ソースを変更または確認するには、右側のパネルでデータ ソース名をクリックします。新しいデータ ソースを作成するには、データ ソース名を入力してドライバ タイプを選択し、[Add] をクリックします。データ ソース名は、Administration の [Entity Homes] 画面で指定されたサイト名と一致している必要があります。
ステップ 5 サーバ、ポート、データベース名または SID、ユーザ名、およびパスワードに値を入力します。
ステップ 7 [Verify All Connections] ボタンを使用して、ColdFusion データ ソースの接続を確認します。
すべてのモジュールは、JNDI(Java Naming and Directory Interface)経由で定義された J2EE データ ソースを利用します。これらのデータ ソースは正しいデータベースを指し、適切なログイン情報が設定されている必要があります。JBoss の場合、JNDI データ ソースは <APP_HOME>¥jboss-4.2.3.GA¥server¥RequestCenter¥deploy ディレクトリにあります。
インストーラにより、次の 2 つのデータ ソースが自動的に作成されます。
• トランザクション データ ソース。バージョン 2008.x 以降で作成されたインストール環境の場合、これには requestcenter-ds.xml という名前が付けられます。以前のバージョンからアップグレードされたインストール環境の場合、データ ソース名には基礎となるデータベースが反映されます(oracle-ds.xml または mssql-ds.xml)。
• データ取得ルールから、または SQL ステートメントかリレーショナル データベース テーブルに基づくサービス定義のオプション リストから、カスタマー固有のデータ ソースにアクセスする。
Service Portal とは異なるデータベース タイプの外部データ ソースにアクセスすることは、サービス フォームではサポートされていません(たとえば、Oracle 上で動作する Service Portal のインスタンスから SQLServer データ ソースへのアクセスや、Service Portal の任意のインスタンスから Sybase データ ソースへのアクセスなど)。
データ ソースを設定する手順については、『 Cisco Service Portal Installation Guide 』を参照してください。この手順はアプリケーション サーバに固有の手順です。
データ取得ルールまたはオプション リストからアクセスされるすべてのデータ ソースには、対応する JNDI データ ソースが必要です。Request Center モジュールからアクセスされるデータを含む新規のデータ ソースを、J2EE アプリケーション サーバのデータ ソースに追加します。
追加のデータ ソース定義は <APP_HOME>¥jboss-4.2.3.GA¥server¥RequestCenter¥deploy ディレクトリに存在する必要があります。新規のデータ ソースを作成する最も簡単な方法は、Request Center データ ソースの XML ファイルをコピーし、必要に応じて JNDI 名と接続条件を変更することです。
通常、SQLServer データベースのデータ ソース定義にはサーバ名とポート番号が必要です。ただし、この方法は、動的なポート番号を使用する名前付きインスタンスの場合にうまくいきません。このようなインスタンスにアクセスするには、データベース名またはインスタンス名を指定して、ポート番号を省略します。
• WebSphere の JDBC プロバイダーを使用します。安定性の理由から、RAR 展開のサポートは廃止されました。
• プロバイダーの追加後、またはデータ ソースに変更を行った後はノードおよび Node Manager を再起動します。
Request Center 内の外部ディクショナリには、データベースの物理テーブルによる「補助」が必要です。外部ディクショナリを読み取り専用にすることはできません。すべての外部ディクショナリは読み取りと書き込みが可能です。外部ディクショナリに書き込みができるのは Request Center のみです。
Request Center が外部ディクショナリを要求に関連付ける場合、外部キーとして使用できる数値カラムを用意しておく必要があります。通常、この名前は RequisitionEntryID です。
次のコードにより、各行に一意の ID を生成するシーケンスが作成されます。RequisitionEntryID カラムにインデックスを作成すると、Service Manager のパフォーマンスが大幅に最適化されます。
外部ディクショナリの補助テーブルは、Catalog Deployer によって環境全体には転送されません。サービスのコンポーネントとして展開できるのは、ディクショナリ定義のみです。
メンテナンス リリースの適用に関する詳細情報については、リリースに付属するリリース ノートを参照してください。パッチの場合は readme ファイルに記載されています。
パッチによっては、現在インストールされている展開環境にコンテンツを追加するか、その環境のコンテンツを置き換える必要があるものもあります。この場合、readme 内の説明には、順を追った実行手順と置き換えが必要なソフトウェアが示されています。
メンテナンス リリースおよび特定のパッチでは、展開された Service Portal 環境を完全にアップグレードまたは再インストールする必要がある場合があります。この場合は、すべてのカスタマイゼーションを保持し、アップグレードまたは再インストール後にそれらを再度適用してください。
Service Designer のサービス エクスポート機能は、Request Center への接続確立、エクスポートされた XML の取得、XML のファイルへの保存を行い、ユーザにリンクを返します。
アプリケーションが SSL 対応の場合は、ユーザがサービスを XML ドキュメントとしてエクスポートしようとするときに問題が発生します。Request Center への接続ではサーバに対する認証を行う必要があり、Request Center には SSL 証明書が必要です。Request Center が SSL 対応の場合は、次の手順に従って「サービスのエクスポート」機能をイネーブルにします。
ステップ 1 Request Center Web サーバで使用する、信頼できるルート CA 証明書を、Base 64 符号化形式でファイルにエクスポートします。多くの場合、ファイルの拡張子は「.arm」または「.cert」になります。これは、任意のテキスト エディタで開くことのできる単純なテキスト ファイルです。
ステップ 2 使用している Request Center マシンの Java インストール環境に付属する CA 証明書キーストアを検索します。Java インストール環境の CA 証明書キーストアは、cacerts という名前のファイルです。
• JBoss の場合、cacerts は <JAVA_HOME>¥jre¥lib¥security にあります。
• WebSphere の場合、cacerts <WAS_HOME>/java/jre/lib/security にあります。
ステップ 3 Request Center Web サーバの信頼できるルート CA 証明書を Java の cacerts キーストアにインポートします。Java の keytool ユーティリティか、WebSphere 環境の場合は IBM の ikeyman ユーティリティのいずれかを使用できます。
• keytool.exe プログラムは <JAVA_HOME>/bin ディレクトリにあります。WebSphere の場合、Java の keytool.exe プログラムは <WAS_HOME>/java/jre/bin ディレクトリにあります。
次に、Java の keytool ユーティリティのコマンドライン構文の例を示します。これにより、ルート CA 証明書が cacerts にインポートされます。
ここで、<root_cert_file> は、ステップ 1 でエクスポートした Request Center Web サーバのルート CA 証明書を含むファイルのフル パス名です。
keytool プログラムにより、キーストア パスワードの入力が求められます。Java の新規インストールの場合、「cacerts」ファイルのデフォルト キーストア パスワードは「changeit」です。「 changeit 」と入力するか、このマシンに Java をインストールしてからパスワードを変更した場合は、その値を入力します。
「Trust this certificate?」という質問が表示されたら、「 y 」を入力します。
アプリケーション サーバのインスタンスを再起動して変更を反映します。個々のサーバやアプリケーションではなく、このマシンの JBoss、WebSphere、または WebLogic のインスタンス全体を再起動してください。
ほとんどのサイト構成の設定は、アクセス高速化のために J2EE システムにキャッシュされます。J2EE アプリケーションで使用される設定をリロードするには、Administration モジュールの [Settings] ページで任意のオプションを変更し、[Update] ボタンをクリックします。これでキャッシュが無効になり、そのページの設定がリロードされます。
Request Center には独自のワーク フロー管理システムが備わっており、これは「Business Engine」と呼ばれることがあります。Business Engine の処理(提供計画の管理)は「背後」、つまりアプリケーション サーバで行われるため、その処理の大部分はアプリケーション ユーザに意識されません。ただし、システム管理者には、Business Engine の処理を確認および場合によっては調整するためのユーザ インターフェイスが提供されます。
Site Administrator のシステム ロールを持つユーザは、http://<serverName:portNumber>/RequestCenter/businessengine/index.jsp の URL 経由で Business Engine コンソールにアクセスできます。ここでは、次の作業を実行できます。
SSO 経由の外部認証が使用される場合、一般的にユーザ パスワードはデータベースに保存されません。保存される場合は、一方向の MD-5 ハッシュとなります。設定ファイルまたはデータベースに保存されたパスワードは、公開/秘密キー暗号化によって暗号化されます。追加の暗号化はデータには適用されません。
Administration モジュールの設定に用意されている [UseStrongEncryption] オプションを使用すると、あらゆる形式のデータの AES 128 ビット暗号化が制御されますが、パフォーマンスが低下する場合があります。データは暗号化の前に圧縮されます。この設定は、一度イネーブルにすると変更することができません。フォーム データを含め、Service Portal データ マートを使用するサイトでは使用できません。
設定ファイル内のデータベース パスワードは暗号化されます。Service Link が設定されていると、J2EE コンテナのパスワードは暗号化されずに、いくつかの設定ファイルにプレーン テキストとして保存されます。
URL は符号化されません。データレベルのセキュリティにより、各画面の承認が確認されます。バージョン 2006.1+ では URL 符号化および暗号化がイネーブルになり、符号化されていない URL はサーバで拒否されます。
Web サーバ、または Web サーバの前にあるコンテンツ スイッチでは SSL を実行することが推奨されます(特にエクストラネットをサポートする環境の場合)。
いくつかのツールでは、アプリケーションをスキャンして、CGI ベースの送信(GET 形式の送信)がアプリケーションに存在しないことを確認します。
シスコはデータのセキュリティと安全に注目しており、XSS(クロスサイト スクリプティング)攻撃によって発生する脅威をよく認識しています。
Request Center では標準の J2EE input-filter-config.xml ファイルを使用して、URL に < > " ' ( ) & ; の文字が含まれないことをチェックします。
Reporting および Advanced Reporting モジュールは、Request Center と Demand Center のデータ マートを維持し、ユーザが使用可能な標準のレポートと KPI を生成するスクリプトを必要とします。
Cognos DataManager ETL から生成された Service Portal Extract-Transform-Load(ETL)スクリプトは、Service Portal から提供される作成済みレポートの実行と、データ マートにあるフォームに依存しないすべてのデータをサポートするデータベースに対する入力を制御します。
追加コマンド ファイルにより、Cognos QueryStudio と Report Studio(Ad-Hoc Reports および Report Designer)で使用されるフレームワークの生成が完了し、Request Center および Demand Center のデータ マートでアドホック レポーティングが可能になります。
これらのスクリプトは、同じ呼び出しとロギングのフレームワークを共有します。これらは、Cognos サーバに配置して実行される Windows .cmd ファイルとして使用できます。任意のエンタープライズ スケジューラ経由で実行をスケジュールできます。Cognos サーバの newScale¥log ディレクトリには、これらのスクリプトのアクティビティのログが記録されます。
標準レポートおよび Key Performance Indicator(KPI)をサポートするには、次のスクリプトが必須です。
|
|
Data Manager で指定した ETL ルールに従って、作成済みレポートをサポートするデータベース テーブルにデータを入力します。これは、データベース コンテンツの差分リフレッシュではなく完全な再ビルドです。< cognos.root >¥ c8 ¥ datamanager ¥log にログ ファイルが生成されます。 |
データ マートをサポートするには、次のプログラムが必須です。
レポート可能として指定されたディクショナリおよびサービスは、Java プログラムによってデータ マートに入力されます。プログラムのアクティビティは、アプリケーション サーバの現在のログ ファイルに記録されます。
このプログラムは内部スケジューラ経由で実行されます。スケジュールの設定は、インストール環境の一部として指定するか、newscale.properties ファイルを編集して変更します。次のプロパティによってスケジューラが設定されます。ETL(およびその他のプロセス)は毎日実行することを推奨します。このジョブの実行中はデータ マートを使用できません。ETL プロセスはトランザクション ロギングを行いながら実行されます。トランザクション サイズ(FDR_ETL_RECORDS_PER_BATCH)を増やすことを推奨します。
Escalation Manager は、タスクがその運用レベル契約(OLA)を超過したか、および超過したタイミングをモニタリングします。OLA を超過した場合、エスカレーションが設定されていれば、Escalation Manager はタスクが超過となってから、指定された時間が経過した後に適切な通知を送信します。
Escalation Manager は内部スケジューラ経由で実行されます。スケジュールの設定は、be.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 ファイルを編集して次のプロパティ設定を追加します。
Relationship Manager は、事業単位の経営幹部向けに調整された、サービス オファリングのポートフォリオを管理する場合に使用するモジュールです。newscale.properties ファイルの設定を編集すると、カルーセル表示の有無を切り替えて表示するように Relationship Manager の [Home] ページを設定できます。
インストール設定は RequestCenter/etc フォルダに記録されます。将来 Service Portal インストーラを呼び出す場合に備えてインストール設定が「記憶」されるように、このフォルダを保持してください。
この設定は setup_options.txt ファイル内で参照できます。次に例を示します。
インストーラが呼び出されるたびに、処理されたアクションのログが mmddyyyyhhmm というタイムスタンプ(たとえば、010720111126 など)を付けて <APP_HOME>/logs フォルダに書き込まれます。重要なインストール ログを次に示します。
Request Center を単一クラスタ化したインストール環境では、クラスタ内通信のためにマルチキャストが必要となります。各ノードが同じサブネット上にあるか、スイッチでサブネット間のマルチキャスト ルーティングがイネーブルになっている必要があります。また、ホスト サーバのネットワーク インターフェイス設定でマルチキャストをイネーブルにする必要があります。
Request Center では複数のマルチキャスト アドレスを使用しますが、これらのアドレスは一意である必要があります。
• 有効な未使用のマルチキャスト アドレスおよびポートを選択します。
• Node2:java -classpath .:./javagroups-all.jar org.javagroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555
• Node1:java -classpath .:./javagroups-all.jar org.javagroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555
Service Portal には、選択した日付よりも古いトランザクションまたはユーザが指定したその他の条件を満たすトランザクションを削除するトランザクション消去機能があります。これを使用すると、アプリケーション管理者はテスト ユーザやサンプル サービスを削除する前にテスト要求を削除することができます。また、保持する必要がなくなった古い要求を削除するなど、データベース サイズを制御するハウスキーピングの目的で消去スクリプトを使用することもできます。ただし、消去スクリプトは大量のデータを削除するようには最適化されていないため、メンテナンス時間が長くならないように注意して使用する必要があります。
消去ユーティリティ用のソフトウェアとして、消去スクリプトが実行されるマシン上にデータベース クライアントがあることが前提条件です。Oracle の場合は、「sqlplus」がインストールされ、RequestCenter データベースに接続するよう設定されている必要があります。SQL Server の場合は「osql」が必要です。
ステップ 1 消去スクリプトを実行する前に RequestCenter データベースをバックアップします。
ステップ 2 消去スクリプトを実行するときは Request Center および Service Link の各サービスを停止します。
<APP_HOME>¥ schema ¥ util ¥ purge
ステップ 4 <APP_HOME> が存在するマシンに前提条件のデータベース クライアント ソフトウェアがある場合は、このマシンから消去スクリプトを実行できます。そうでない場合は、RequestCenter データベースのあるマシン、または前提条件となるデータベース クライアントのある別のマシンに purge フォルダ全体をコピーします。
ステップ 5 次のファイルが purge フォルダに含まれていることを確認します。
ステップ 6 Windows オペレーティング システムの場合は .bat ファイル、UNIX または Linux オペレーティング システムの場合は .sh ファイルを実行します。
常に同じフィルタ条件を使用して要求を消去する場合(たとえば、キャンセルされた要求をすべて消去するなど)、この手順は不要です。ただし、適切な方法として、混乱を避けるために前の実行の条件を先にクリアすることを推奨します。
1 つまたはすべてのフィルタ条件をクリアするには、 ClearAllPurgeFilter スクリプトを使用します。[ Purge Filter Name ] が指定されていない場合は、RequestCenter データベースの CnfPurgeFilter テーブルのフィルタ エントリがすべて削除されます。そうでない場合は、[ Purge Filter Name ] が CnfPurgeFilter テーブルに存在すれば指定されたフィルタのみが削除されます。
ClearAllPurgeFilter ORACLE [ SID ] [ User ] [ Password ] [ Purge Filter Name (オプション)]
ClearAllPurgeFilter SQLSERVER [ Server ] [ Database ] [ User ] [ Password ] [ Purge Filter Name (オプション)]
1 つまたは複数のフィルタ条件を追加するには、 AddPurgeFilter スクリプトを使用します。要求が削除されるのは、すべての消去条件を満たす場合のみです。フィルタ条件は RequestCenter データベースの CnfPurgeFilter テーブルに保存されます。
使用するデータベース タイプに対応する下記のコマンド構文を使用します。
• [ SID ] は Oracle データベースの ORACLE_SID です。
• [ Server ] は SQL Server データベースのサーバ名です。
• [ Password ] は「RCUser」のパスワードです。
• [ Purge Filter Name ] および [ Purge Filter Value ] に指定できる値については、パラメータ表を参照してください。
AddPurgeFilter ORACLE [ SID ] [ User ] [ Password ] [ Purge Filter Name ] [ Purge Filter Value ]
AddPurgeFilter SQLSERVER [ Server ] [ Database ] [ User ] [ Password ] [ Purge Filter Name ] [ Purge Filter Value ]
要求を消去する前にオプションで「リハーサル」を実行すると、実際に要求を削除することなく、どの要求が削除されるかを確認できます。これは、フィルタ条件が有効であることを検証する役割を果たします。
フィルタ条件を満たす要求のリストを表示するには、 PurgeRequisitions スクリプトを使用します。
PurgeRequisitions ORACLE [ SID ] [ User ] [ Password ] PURGE
PurgeRequisitions SQLSERVER [ Server ] [ Database ] [ User ] [ Password ] PURGE
リハーサルで検出された要求のリストは、RequestCenter データベースの LogPurge テーブルに保存されます。ログ エントリは実行ごとに RunID が 1 ずつ増分されてテーブルに追加されます。最も大きい RunID を指定して LogPurge テーブルのエントリをクエリーすると、消去される要求を確認できます。
リハーサルや要求の消去を何度も実行すると、時間とともに LogPurge テーブルが急速に大きくなる可能性があります。したがって、定期的に LogPurge テーブルを手動で切り捨て、以前の実行のエントリを削除することを推奨します。
ステップ 1 から 3 を繰り返すと、消去条件を修正できます。消去フィルタ条件が確定したら、実際の要求消去に進むことができます。
要求消去を行うと、タスクと Service Link メッセージを含め、消去フィルタ条件を満たす要求とそれらの要求に関連付けられたすべてのトランザクション データが削除されます。
RequestCenter データベースの LogPurge テーブルには実際の要求消去の結果も追加されます。実際の要求消去を実行するには、次に示すように、同じ PurgeRequisitions コマンドに PURGE パラメータを指定して使用します。
PurgeRequisitions ORACLE [ SID ] [ User ] [ Password ] PURGE
PurgeRequisitions SQLSERVER [ Server ] [ Database ] [ User ] [ Password ] PURGE
ワークフロー消去ユーティリティを使用すると、ワークフロー処理に関連するデータベースから一時データが削除されます。これらのデータが実稼動環境で使用されなくなった場合は、これらを削除すればデータベースのサイズを小さくすることができます。また、消去ユーティリティを定期的に実行すると、全体的なパフォーマンスが改善される可能性があります。
ワークフロー消去ユーティリティは、RequestCenter データベースのストアド プロシージャの形式で提供されます。データベースの規模が大きい場合、消去ユーティリティの実行には 1 時間以上かかる場合があります。このため、システムのダウン時またはアクティビティが少ない時間帯に消去を行う必要があります。データベースでスクリプトの実行にかかる時間を確認するために、サンドボックス環境でのテスト実行が推奨されます。
消去の開始/終了時間を追跡するには、ストアド プロシージャを実行する前に SQL ツールで print ステートメントを表示する設定をイネーブルにします。
Oracle データベースでユーティリティを実行するには、次の手順を実行します。
ステップ 1 RequestCenter データベースをバックアップします。
ステップ 2 データベースに対応するクエリー ツール(SQL*Plus など)を使用して、RCUser として RequestCenter データベースに接続します。
• EXECUTE sp_PurgeWorkflowTables;
実行の終了時に総経過時間が表示されます。次に出力の例を示します。
SQL Server データベースでユーティリティを実行するには、次の手順を実行します。
ステップ 1 RequestCenter データベースをバックアップします。
ステップ 2 データベースに対応するクエリー ツール(SQL Server Management Studio など)を使用して、RCUser として RequestCenter データベースに接続します。
• EXECUTE sp_PurgeWorkflowTables
実行の終了時に総経過時間が表示されます。次に出力の例を示します。
Service Link メッセージ消去ユーティリティを使用すると、データベースから nsXML メッセージが削除されます。これらのメッセージは(サービス フォームの複雑さおよびエージェントの設定に使用されるコンテンツ タイプ オプションに応じて)きわめて大きくなる可能性があるため、メッセージを削除することにより、Service Link 関連のデータを保持するために必要なデータベース サイズが大幅に削減されます。外部メッセージは変更されないままです。
Oracle データベースでユーティリティを実行するには、次の手順を実行します。
ステップ 1 RequestCenter データベースをバックアップします。
ステップ 2 データベースに対応するクエリー ツール(SQL*Plus など)を使用して、RCUser として RequestCenter データベースに接続します。
EXECUTE exec sp_CleanupSlMessageContent (<n>);
ここで、<n> は成功/失敗した Service Link メッセージが保持される日数です。-1 は成功/失敗したメッセージがすべて消去されることを意味します。
実行の終了時に、消去されたメッセージの総数および総経過時間が表示されます。次に出力の例を示します。
SQL Server データベースでユーティリティを実行するには、次の手順を実行します。
ステップ 1 RequestCenter データベースをバックアップします。
ステップ 2 データベースに対応するクエリー ツール(SQL Server Management Studio など)を使用して、RCUser として RequestCenter データベースに接続します。
EXECUTE sp_CleanupSlMessageContent <n>
ここで、<n> は成功/失敗した Service Link メッセージが保持される日数です。-1 は成功/失敗したメッセージがすべて消去されることを意味します。
実行の終了時に総経過時間が表示されます。次に出力の例を示します。
Service Portal 統合ポイントの詳細については、『Cisco Service Portal Integration Guide』を参照してください。ここでは、システム管理者が Service Portal アプリケーションの設定時に推進できる重要な統合戦略の概要を示します。
シングル サインオンを使用すると、ユーザがログイン画面をバイパスし、ポータルまたはその他のアプリケーションから Service Portal に直接アクセスできます。
JavaScript の関数は、サードパーティ システムと通信してフォーム情報を収集、検証、または配信し、フォームの外観や動作を動的に変更します。
Service Link は HTTP、ファイル、データベース、MQ と JMS のアダプタによる非同期メッセージングを提供します。外部タスクにより、Service Link エージェントが別のシステムにコマンドを発行して応答を待機するようにトリガーされます。
サードパーティ アプリケーションにより、Requisition API(RAPI)を使用して Request Center 内で処理が開始されます。
例:財務システムで給与支払小切手をキャンセルすると、Request Center でオフボーディング プロセスの開始および管理が行われ、アカウントがディセーブルになり資産が回収されます。
システムでは複数の LDAP ディレクトリの統合が可能です。2 つ以上の LDAP ソースのグループが、照会を通じて 1 つの LDAP システムとなります。ディレクトリ統合の設定に関する詳細については、『 Cisco Service Portal Integration Guide 』を参照してください。
ディレクトリ統合を利用すると、統合アーキテクトは LDAP データ ソースに Service Portal を接続し、個人プロファイル内の対応するフィールドにそのデータ ソースの属性をマッピングできます。統合により、設計者は LDAP ルックアップをトリガーするイベントと、そのルックアップによって Service Portal の個人プロファイルもリフレッシュするかを指定できます。LDAP ルックアップをトリガーできるイベントには次のようなものがあります。
• ログイン後の認証(Service Portal 画面経由またはシングル サインオン経由)
• 代理オーダーまたは個人検索経由で事前選択された人物のマネージャに関する個人情報のルックアップ
ディレクトリ統合では、事前に設定されたこれらのイベントと動作に加えて、プログラマがカスタム ディレクトリ インターフェイスを実装して新しい検索機能の追加や検索ロジックの改良ができる API を提供します。
ディレクトリ データは次のような個人プロファイルの要素にマッピングできます。
• 単純マッピング。ディレクトリ属性と個人フィールド間の 1 対 1 のマッピング。
• 複合マッピング。2 つ以上のディレクトリ属性を使用して、個人フィールドの値を取得します。
• 表現マッピング。1 つまたは複数のディレクトリ属性に関連する正規表現を使用して、個人フィールドの値を条件付きで取得します。
• Directory Integration API による Java クラス経由のマッピング。現在の人物の現在のディレクトリ データ ソースで使用できるディレクトリ属性に基づいて、Java プラグインで個人フィールドの値を取得します。
ロケールおよびタイム ゾーンがマッピングされていない場合、Service Portal ではサーバのデフォルトを使用します。
カスタム マッピングは、『 Cisco Service Portal Integration Guide 』に記述されているパターン マッチング言語(正規表現)経由、および Directory Integration API で提供されるインターフェイスを使用するカスタム プラグイン クラス経由で作成できます。
このようなマッピングは、実装ごとに LDAP 統合ドキュメントにすべて文書化する必要があります。Service Portal インスタンスが移行またはアップグレードされた場合、マッピングに必要な Java クラスはすべてカスタマイゼーションとして扱われます。
Directory Integration API で提供されるインターフェイスを使用すると、ディレクトリ統合イベントによって提供される事前定義の動作をカスタム Java クラスが置き換えまたは補完できます。インスタンスが移行またはアップグレードされた場合、このようなクラスはカスタマイゼーションとして扱われます。
さらに、カスタム クラスが JAR ファイルのサポートを必要とする場合は、これらをアプリケーション サーバにインストールし、カスタマイゼーションとして扱う必要があります。インストールの手順はアプリケーション サーバごとに異なります。
ステップ 1 サードパーティの JAR を WAS 外部のフォルダにコピーします。
ステップ 2 WAS コンソールで [Environment] > [Shared Libraries] に移動します。[Cell] スコープを参照します。これで、セル内のすべてエンティティからライブラリが認識されます。(必要に応じてスコープを変更できます)。[New] をクリックして JAR の参照名を入力し、[Classpath] に JAR のフル パスを入力します。これを JAR ごとに繰り返します。変更を保存します。
ステップ 3 [Applications] > [Enterprise Applications] に移動して、アプリケーションを選択します。[Configuration] タブで [Additional Properties] > [Libraries] に移動します。[Add] ボタンをクリックして、作成した各ライブラリを追加します。変更を保存してアプリケーションを再起動します。
ステップ 1 RequestCenter.ear¥フォルダにサードパーティの JAR を追加します。
ステップ 2 サードパーティの各 JAR について、RequestCenter.ear¥META-INF¥application.xml にモジュール参照を追加します。
ステップ 3 Request Center サービスを再起動します。
シングル サインオンに問題が発生した場合は、次の項目をチェックしてトラブルシューティングを開始します。
• LDAP または Junction/SiteMinder エージェントの設定など、環境に関連する変更を確認します。
• まだ Administrative Override 経由で Service Portal にアクセスできるかどうかを確認します。
多くの環境で Windows 認証を使用しています。IIS は統合 Windows 認証(IWA)をサポートし、ログインしたユーザの DOMAIN¥UserName をパラメータとして渡します。
• IWA をイネーブル化した後に(Windows サービスで)IIS Admin サービスの再起動。
ISF は、Request Center サービス フォームに統合された JavaScript API です。ISF を使用すると、ユーザの資格情報を含む現在のコンテキスト、フォームに入力済みのデータ、または表示された要求のライフ サイクルに基づいて、フォームのコンテンツまたは動作を動的に変更できます。ISF の詳細については、『 Cisco Service Portal Designer Guide 』を参照してください。
ISF は、Service Portal リポジトリに保存された JavaScript コードを補完する、アプリケーションまたは Web サーバに保存された JavaScript ライブラリの使用をサポートします。このようなライブラリを使用する場合は、Service Portal サイトをアップグレードまたは移行するときに、ライブラリをカスタマイゼーションとして扱う必要があります。
アクティブ フォーム コンポーネント内で使用できるデータ取得ルールにより、Request Center で外部リレーショナル データベースまたはアプリケーション データベースからデータを取得し、サービス フォームで使用することができます。このようなデータは、フォームのフィールドへのデフォルト値の事前入力、ドロップダウン リストの生成、および詳細情報にドリルダウンする場合の値の動的入力に使用できます。また、ユーザのデータ入力を外部データと照合することもできます。
外部データベースにアクセスするルールの場合は、対応する JEE データ ソースを作成する必要があります。データ ソースを作成する手順については、『 Cisco Service Portal Installation Guide 』を参照してください。Service Portal サイトをアップグレードまたは移行する場合、このようなデータ ソースはカスタマイゼーションとして扱われます。
Service Link は Integration Server または ISEE(Integration Server Enterprise Edition)とも呼ばれますが、これを使用すると Request Center で XML メッセージを使用して他のシステムに同期または非同期の要求を送信できます。
Service Designer で「外部」として設定されたタスクが、Service Link によって処理されます。
Service Link は基盤のテクノロジーとして JMS キューを使用するので、JMS 設定に問題があると Service Link の動作に悪影響が出る可能性があります。ほとんどの Service Link トラブルシューティングは、Service Link モジュールを使用して行うことができます。このモジュールには、送受信された個々のメッセージとそれらのメッセージを送受信するタスクをドリルダウンする機能が備わっています。
ここでは、Service Portal のインストールのカスタマイズのためのシステム設定と、その後のインストールやアップグレードのときにカスタム コンテンツが削除または上書きされないようにするためのシステム設定に関する情報を示します。
インストーラの詳細については、『 Cisco Service Portal Installation Guide 』を参照してください。
• インストール時に選択した設定に基づく .properties ファイルの変更
• カスタマイゼーション ファイル内のマージ(インストール パラメータの一部として指定されている場合)
• 宛先またはフォルダへの EAR のパブリッシュによる展開(WebSphere および WebLogic の場合)
展開手順では、EAR ファイル全体がサーバに展開されることが規定されています。EAR ファイル全体が展開されると、EAR が前回展開されたディレクトリは削除され、そのディレクトリに存在したすべての Service Portal カスタマイゼーションは失われます。
カスタマイゼーションが失われないようにするために、インストーラではカスタム コンテンツがインストールに含まれるように指定できます。
ステップ 1 カスタム コンテンツを含むアーカイブを作成します。アーカイブのディレクトリ構造は展開ディレクトリの構造と一致させる必要があります。
ステップ 2 『 Cisco Service Portal Installation Guide 』の説明に従ってインストーラを実行し、[Options] 画面が表示されるまですべての手順を完了します。
ステップ 3 [Include custom content?] オプションを選択します。
ステップ 4 「 Y 」を押して、カスタム コンテンツを含めることを確定します。
[Include Custom Content?] の下に [Custom content archive path] オプションが表示されます。
ステップ 5 [Custom content archive path] オプションを選択します。
インストーラから、アーカイブのパスを入力するよう求められます。
ステップ 6 アーカイブの名前を含め、アーカイブのフル パスを入力します。
ステップ 7 『 Cisco Service Portal Installation Guide 』の説明に従ってインストールを続行します。
インストーラがインストールを完了する間、アプリケーションの展開ディレクトリ構造にカスタム コンテンツのアーカイブが抽出されます。
Service Link Adapter Development Kit(ADK)、または Service Adapter Kit のいずれかを使用して作成されたカスタム Service Link アダプタのインストールには、同様のインストール オプションを使用できます。このオプションの詳細については、「Service Link アダプタの追加インストール」を参照してください。
カスタマイズされたファイルはすべてカスタマイゼーション アーカイブに含まれている必要があります。実装内のすべてのサイトで、次のようなカスタマイズ済みファイルが必要になる場合があります。
カスタマイズされたコンテンツは、サイトまたは環境に固有のものとなる場合があります。さまざまな環境でのアップグレードを容易にするには、ビルド スクリプトで環境固有のファイルを追跡できるようにします。
次の設定を変更した場合は、適切なファイルを変更しなければ変更が伝播されません。
|
|
データベースは、Cisco が提供する API 以外では変更しないでください。ただし、一部のスクリプトはデータベースに対して直接実行する必要がある場合があります。
外部ディクショナリはデータベース テーブルとして保存されます。これらのディクショナリを変更した場合は、必ず DDL スクリプトを実行して対応するテーブルを修正する必要があります。
手動による実行が必要なパッチまたはホットフィックスの一部として、SQL スクリプトがカスタマー サポートから提供される場合があります。ホットフィックスは、次の製品リリースに追加されるまではカスタマイゼーションとして扱い、ソフトウェア アップグレードまたは再インストールに含める必要があります。
通常、Service Portal 実装は複数のサイトで構成され、それぞれのサイトが異なる役割を果たします。
|
|
開発アクティビティから干渉されることのない、制御された環境。ここでは、品質保証または他の担当者がサービス カタログをテストします。 |
|
ユーザ コミュニティがサービス カタログからサービスを要求でき、IT チームがサービス要求を満たすことができる実稼動環境。 |
この章の前半では、Service Portal リポジトリの外部にある設定項目の管理について説明しました。上記のガイドラインに従うと、Service Portal ソフトウェアに適用済みのカスタマイゼーションを失うことなく、このソフトウェアをアップグレードできます。ただし、これらのガイドラインには、クライアントから提供されたコンテンツ(サービス定義や個人プロファイルなど)をサイト間で移行する必要性についての説明がありません。この機能は Catalog Deployer で提供されています。
Catalog Deployer モジュールは、メタデータ(サービス定義)およびリポジトリに保存されている組織データ(人、組織、および関連するエンティティ)の設定管理を行います。
展開中の特定のタイミングで、Service Portal OLTP データベースをサイト間でコピーすることが望ましい場合があります。次に例を示します。
• テスト サイトまたは実稼動サイトを初めてインストールするときは、開発サイト全体を新しい環境にコピーする可能性があります。
• 実稼動サイトが稼動してしばらく経過したら、すべてのユーザ アクティビティをテスト環境にコピーして、実際のパフォーマンスまたはボリュームを調査する必要があります。
ステップ 2 ソース環境の Request Center および Service Link のサービスを停止します。
ステップ 3 ソース データベースをエクスポートします。データのソースおよびエクスポートの日付を追跡できる命名規則を決定します。
ステップ 4 システムのシャットダウンを実行できない場合は、Oracle エクスポートの -consistent フラグを使用します。
ステップ 5 Request Center および Service Link のサービスを再起動します。
ステップ 1 ターゲット環境の Request Center および Service Link のサービスを停止します。
ステップ 2 ターゲット データベースの最新のバックアップ コピーがあることを確認します。
ステップ 3 必要に応じて、宛先からのエクスポート ファイルを、ターゲット データベース サーバにアクセスできるファイル システムにコピーします。
ステップ 4 ターゲット データベースにデータをインポートします。
ステップ 5 SQLServer の場合は、新たにインポートされるデータベースに存在するログインおよびユーザが、Service Portal のこのインスタンスに必要な資格情報と一致することを確認します。必要に応じて新しいログインを作成したり、既存のログインをデータベース所有者に関連付けたりして、このユーザが適切な権限を持つようにします。Oracle の場合は、新しくインポートされるデータベースに適切なユーザが存在し、Service Portal インストーラで指定されたように特権が付与されていることを確認します。
ステップ 6 両サイトが 2 つの異なる Cognos レポート サーバにアクセスしている場合は、各サイトの「CognosServer」の名前を指定する CnfParams テーブルのエントリを更新して、更新内容をコミットします。
ステップ 7 ターゲット環境の Request Center および Service Link のサービスを再起動します。
ステップ 8 [Administration] > [Entity Homes] > [SiteProtection] の [This Site Is] プロパティを現在のサイトに設定します。[Entity Homes] の指定が異なる場合、またはサイトの保護レベルが異なる場合は手動で変更を行い、変更を保存します。
ステップ 9 両サイトが 2 つの異なる LDAP ディレクトリに接続している場合は、ディレクトリ統合のデータ ソース定義を適宜変更します。
ステップ 10 Service Link エージェントの接続プロパティをすべてチェックし、ターゲット環境に合わせて変更します。
ステップ 11 手作業での追加処理がある場合はそれを実行し、データを調整します。たとえば、一部のユーザ、グループ、または組織に権限を追加したり、権限を取り消したりする場合があります。
ステップ 12 メンテナンスが完了したことをユーザに通知します。
Service Link にはいくつかのデフォルト アダプタが付属しています。一連のデフォルト Service Link アダプタを拡張する場合、顧客はカスタム アダプタを作成するか、または Service Link と連携するように設計されたサービス アダプタを購入します。ここでは、Service Portal のインストール時に、顧客が作成したカスタム アダプタおよび Service Link のサービス アダプタをインストールする方法について説明します。
インストール時に Advanced Services アダプタまたはカスタム アダプタをインストールするには、次の手順を実行します。
ステップ 1 Cisco Advanced Services からアダプタ アーカイブを入手してハード ディスクにコピーするか、カスタム Service Link アダプタを含むアーカイブを作成してハード ディスクにコピーします。カスタム アダプタの詳細については、『 Cisco Service Portal Integration Guide 』を参照してください。
ステップ 2 『 Cisco Service Portal Installation Guide 』の説明に従ってインストーラを実行し、[Options] 画面が表示されるまですべての手順を完了します。
ステップ 3 [Include Custom Adapters?] オプションを選択します。
ステップ 4 「 Y 」を押して、カスタム Service Link アダプタを含めることを確定します。
[Include Custom Adapter?] オプションの下に [Custom adapter archive path] オプションが表示されます。
ステップ 5 [Custom adapter archive path] オプションを選択します。
インストーラから、アーカイブのパスを入力するよう求められます。
ステップ 6 アーカイブの名前を含め、アーカイブのフル パスを入力します。
ステップ 7 『 Cisco Service Portal Installation Guide 』の説明に従ってインストールを続行します。
インストーラがインストールを完了する間、アプリケーションの展開ディレクトリ構造にカスタム コンテンツのアーカイブが抽出されます。
ステップ 8 インストールする追加の Service Link アダプタごとに上記の手順を繰り返します。複数の追加 Service Link アダプタを一度にインストールすることはできません。
Service Link サービスの SSL をイネーブルにするには、次の作業が必要です。
• 自己署名のデジタル証明書または VeriSign などの既知の CA が署名したデジタル証明書の取得。
• Service Link サービスが動作するアプリケーション サーバのセキュア ポート番号の設定。
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 サービスのセキュア ポートと非セキュア ポートを両方使用し、ファイアウォール システムなどの別のメカニズムによって非セキュア ポートへのアクセスを制御することは可能です。たとえば、JBoss 環境の Request Center アプリケーションは、(別の JBoss サーバ上で動作する)Service Link サービスの「クライアント」でもあります。実行時には、Request Center が URL http://< SL_servername >:8089 を使用して Service Link サービスに接続する必要があります。Service Link サービスで非セキュア ポート 8089 がオフにされている場合は、https アドレス(つまり、 https :// <SL_servername >: 8443 )経由で Service Link に接続するように Request Center を設定する必要があります。このため、Service Link サービスの非セキュア ポート 8089 およびセキュア ポート 8443 をどちらもオンにするというシナリオが考えられます。Request Center は http://< SL_servername >:8089 経由で Service Link に接続可能ですが、その他の外部システムは https://< SL_servername >:8443 経由でのみ Service Link と通信ができます。ファイアウォール システムを設定すると、すべての外部システムからのポート 8089 へのアクセスを拒否できます。
ここでは、アプリケーション サーバの非セキュア ポートをオフにする方法や、非セキュア ポート番号へのアクセスを拒否するようにファイアウォール システムを設定する方法については説明 しません 。必要な情報を入手するには、システム管理者またはご使用のアプリケーション サーバのベンダーに問い合わせてください。
JBoss 環境の Service Link は独立した JBoss サーバ上で動作します。Service Link の SSL をイネーブルにするには、Service Link が動作している JBoss サーバの証明書およびセキュア ポート番号を設定します。
クラスタ化されていない WebLogic 環境または WebSphere 環境では、Request Center アプリケーションと同じ WebLogic サーバまたは WebSphere サーバに Service Link を展開します。Service Link の SSL をイネーブルにするには、実質的には Service Link と Request Center のサービスがどちらも動作している WebLogic サーバまたは WebSphere サーバと同じサーバの証明書およびセキュア ポート番号を設定します。
クラスタ化された WebLogic 環境または WebSphere 環境では、クラスタに属していない、独立した WebLogic サーバまたは WebSphere サーバに Service Link を展開する必要があります。(Request Center および Business Engine のみがクラスタに展開されます)。このため、Service Link の SSL をイネーブルにするには、Service Link が動作している WebLogic サーバまたは WebSphere サーバの証明書およびセキュア ポート番号のみを設定します。
Service Link サービスの保護に使用できるデジタル証明書は取得済みであると仮定します。この証明書は自己署名するか、または VeriSign のようなサードパーティ認証局から取得できます。いずれの場合も、デジタル証明書はアプリケーション サーバからアクセス可能な Java キーストア(jks ファイル)にインポートする必要があります。また、署名者証明書(証明書の公開キーとも呼ばれます)は、SSL モードで Service Link サービスと通信する外部システムに提供できるように、「Base64 で符号化された ASCII」形式のファイルにエクスポートする必要があります。
このマニュアルの後半の手順では、すでにデジタル証明書が格納されている有効なキーストア ファイルから開始することを想定します。説明を容易にするため、使用するキーストア ファイルの名前は「 slkeystore.jks 」とします。証明書は「 servicelink 」というエイリアスの下に格納されています。このキーストア ファイルを開くためのパスワードは「 slpassword 」です。
さらに、「 slsigner.cer 」という名前のファイルに「Base64 で符号化された ASCII」形式で署名者証明書がエクスポートされているものとします。「Base64 で符号化された ASCII」形式とは、次の例のような形式のことです。
ここでは、証明書ファイルをインストールする手順および各種アプリケーション サーバの SSL を設定する手順について説明します。
Service Link マシンの「管理者」ユーザとして次の手順を実行します。
ステップ 1 Service Link マシンの「<APP_HOME>¥jboss-4.2.3.GA¥server¥ServiceLink¥conf」ディレクトリに証明書キーストア ファイル「slkeystore.jks」をコピーします。
ステップ 2 「<APP_HOME>¥jboss-4.2.3.GA¥server¥ServiceLink¥deploy¥jboss-web.deployer¥server.xml」ファイルを次のように変更します。
次のように変更します( コメントのカッコを削除し、keystoreFile 変数および keystorePass 変数を追加します。ディレクトリ パスではバックスラッシュではなくフォワード スラッシュを使用します )。
ステップ 3 マシンでポート 8443 が使用されていないことを確認します。このポートが使用されている場合は、使用できる別のポート番号に「接続ポート」を変更します。
ステップ 4 Service Link サービスを再起動します。
ステップ 5 「<APP_HOME>¥jboss-4.2.3.GA¥server¥ServiceLink¥log¥server.log」ログ ファイルを参照して次のメッセージがあることを確認し、ServiceLink サービスがポート 8443 で起動したことを確認します。
これで、Service Link サービスが SSL に対応しました。
ステップ 6 servicelink 証明書用の署名者証明書を含む「slsigner.cer」ファイルをすでに作成済みの場合は、このステップを省略します。そうでない場合は、次の手順を実行して署名者証明書をエクスポートします。署名者証明書をエクスポートするには、いくつかの方法があります。次の手順は、Sun JDK 6 インストールに付属する「keytool.exe」ユーティリティを使用して証明書をエクスポートする方法の 1 つに過ぎません。
a. コマンド プロンプト ウィンドウで次のコマンドを実行します。
b. 「slsigner.cer」ファイルが有効であることを確認するには、次のコマンドを実行します。
ステップ 7 Service Link サービスの非セキュア ポート(8089)をディセーブルにする場合は、Service Link サービスと通信する外部システムを管理するシステム管理者に「slsigner.cer」ファイルを送信します。その外部システムでは、2 つの設定を行う必要があります。
a. Service Link URL を、http アドレスからセキュア ポート番号を使用する https アドレスに変更する必要があります。たとえば、変更前は次のような Service Link URL であるとします。
b. Service Link サービスとの SSL 接続時に信頼できるハンドシェイクを確立できるように、 servicelink 証明書の署名者証明書(つまり、「slsigner.cer」ファイルの内容)を外部システムの 信頼できる Java 認証局キーストア にインポートする必要があります。
ステップ 8 Service Link の非セキュア ポートをディセーブルにする場合は、Request Center サービスの 信頼できる Java 認証局キーストア にも署名者証明書をインポートする必要があります。これは、Request Center アプリケーションが独立した JBoss サーバ上で動作しており、実行時には Service Link サービスに接続する「クライアント」として機能するためです。Request Center の 信頼できる Java CA キーストア に署名者証明書をインポートするには、次の手順を実行します。
a. Request Center マシンに「管理者」ユーザとしてログインします。
b. 「< JAVA_HOME >¥jre¥lib¥security」ディレクトリで「 cacerts 」ファイルを探します。ここで、< JAVA_HOME > は Sun JDK 6 インストール環境のルート ディレクトリです。このファイルは、Sun JDK 6 インストールに同梱されている、 信頼できる CA キーストア です。
<JAVA_HOME> が、JBoss アプリケーション サーバが使用する正しい Java ディレクトリであることを確認してください。これを確認するには、「<APP_HOME>¥bin」ディレクトリの下にある「setEnv.cmd」ファイル内の JAVA_HOME 設定を検索します。たとえば、set JAVA_HOME=C:¥jdk1.6.0_23 などが該当します。
c. 「< JAVA_HOME >¥jre¥lib¥security」ディレクトリに「slsigner.cert」ファイルをコピーします。
d. コマンド プロンプト ウィンドウで次のコマンドを実行して、署名者証明書を「cacerts」キーストアにインポートします。
上記のコマンドでは、「cacerts」キーストア ファイルのパスワードがまだデフォルト値の「changeit」であると仮定しています。使用する環境で「cacerts」のパスワードが変更されている場合は、それを適切な値に置き換えてください。
e. 「<APP_HOME>¥jboss-4.2.3.GA¥server¥RequestCenter¥deploy¥RequestCenter.ear¥config」ディレクトリの下の「 newscale.properties 」ファイルを次のように変更します。
f. Request Center サービスを再起動します。
ステップ 9 ステップ 8 を実行しないようにするために、Service Link サービスの非セキュア ポート 8089 およびセキュア ポート 8443 をどちらもオンにする場合があります。このようにすると、Request Center アプリケーションは非セキュア URL(http://< hostname >:8089)を使用して引き続き Service Link に接続できます。ただし、外部システムからの非セキュア ポート 8089 へのアクセスをブロックするために、(ファイアウォール システムなど)なんらかの対策を立てることもできます。
WebLogic 管理コンソールにアクセスできるユーザで次の手順を実行します。
ステップ 1 Service Link が動作している WebLogic マシンの「< JAVA_HOME >¥jre¥lib¥security」ディレクトリに、証明書キーストア ファイル「slkeystore.jks」をコピーします。
(注) クラスタ化された WebLogic 環境では、クラスタに属していない WebLogic サーバに Service Link を展開する必要があります。したがって、必ず Service Link に適した WebLogic サーバを特定してください。
<JAVA_HOME> が、WebLogic アプリケーション サーバが使用する正しい Java ディレクトリであることを確認してください。「<WL_HOME>¥common¥bin」ディレクトリの下にある「commEnv.cmd」ファイル内の JAVA_HOME 設定を検索します(UNIX または Linux では「commEnv.sh」を検索します)。たとえば、 set JAVA_HOME=C:¥jdk160_23 などが該当します。
ステップ 2 WebLogic 管理コンソールにログインし、[< domain >] > [Environment] > [Servers] に移動します。
ステップ 3 Service Link 用の WebLogic サーバの名前をクリックして、その設定を開きます。
ステップ 4 [Configuration] > [Keystores] サブタブを選択します。
ステップ 5 [Keystores] ページで次の値を入力します。< JAVA_HOME > を Java ディレクトリのフル パス名で置き換えます。(読み取り専用フィールドの場合、表示された値が正しいことを確認します)。
|
|
[Java Standard Trust Keystore Passphrase] については、「cacerts」キーストア ファイルのパスワードがまだデフォルト値の「changeit」であると仮定しています。使用する環境で「cacerts」のパスワードが変更されている場合は、それを適切な値に置き換えてください。
ステップ 7 [Configuration] > [SSL] サブタブを選択します。
ステップ 10 [Configuration] > [General] サブタブを選択します。
ステップ 11 [General] ページで次の値を入力します。
• [SSL Listen Port Enabled] チェックボックスをオンにします。
• [SSL Listen Port] = < 9443 など、使用できるポート番号を入力 >
ステップ 13 Service Link が展開されている WebLogic サーバを再起動します。
ステップ 14 「< WL_servername >.out」ログ ファイルを参照して次のようなメッセージがあることを確認し、WebLogic サーバがセキュア ポート(9443)で起動したことを確認します。
これで、Service Link サービスが SSL に対応しました。
ステップ 15 servicelink 証明書用の署名者証明書を含む「slsigner.cer」ファイルをすでに作成済みの場合は、このステップを省略します。そうでない場合は、次の手順を実行して署名者証明書をエクスポートできます。署名者証明書をエクスポートするには、いくつかの方法があります。次の手順は、Sun JDK 6 インストールに付属する「keytool.exe」ユーティリティを使用して証明書をエクスポートする方法の 1 つに過ぎません。
a. コマンド プロンプト ウィンドウで次のコマンドを実行します。
b. 「slsigner.cer」ファイルが有効であることを確認するには、次のコマンドを実行します。
ステップ 16 Service Link サービスの非セキュア ポートをディセーブルにする場合は、Service Link サービスと通信する外部システムを管理するシステム管理者に「slsigner.cer」ファイルを送信します。その外部システムでは、2 つの設定を行う必要があります。
a. Service Link URL を、http アドレスからセキュア ポート番号を使用する https アドレスに変更する必要があります。たとえば、変更前は次のような Service Link URL であるとします。
b. Service Link サービスとの SSL 接続時に信頼できるハンドシェイクを確立できるように、 servicelink 証明書の署名者証明書(つまり、「slsigner.cer」ファイルの内容)を外部システムの 信頼できる Java 認証局キーストア にインポートする必要があります。
ステップ 1 Service Link サービスの非セキュア ポートをディセーブルにする場合は、Request Center サービスの 信頼できる Java 認証局キーストア にも署名者証明書をインポートする必要があります。これは、クラスタに属していない、独立した WebLogic サーバで Service Link が動作するためです。(Request Center および Business Engine のみ、クラスタにインストールできます)。Request Center は、実行時に Service Link サービスに接続する「クライアント」として機能します。Request Center の 信頼できる Java CA キーストア に署名者証明書をインポートするには、次の手順を実行します。
a. Request Center アプリケーションが動作している WebLogic クラスタ ノードのいずれかにログインします。
b. 「< JAVA_HOME >¥jre¥lib¥security」ディレクトリで「 cacerts 」ファイルを探します。ここで、< JAVA_HOME > は Sun JDK 6 インストール環境のルート ディレクトリです。このファイルは、Sun JDK 6 インストールに同梱されている、信頼できる CA キーストアです。
<JAVA_HOME> が、WebLogic アプリケーション サーバが使用する正しい Java ディレクトリであることを確認してください。これを確認するには、「<WL_HOME>¥common¥bin」ディレクトリの下にある「commEnv.cmd」ファイル内の JAVA_HOME 設定を検索します(UNIX または Linux では「commEnv.sh」を検索します)。次に例を示します。
c. 「< JAVA_HOME >¥jre¥lib¥security」ディレクトリに「slsigner.cert」ファイルをコピーします。
d. コマンド プロンプト ウィンドウで次のコマンドを実行して、署名者証明書を「cacerts」キーストアにインポートします。
上記のコマンドでは、「cacerts」キーストア ファイルのパスワードはまだデフォルト値の「changeit」です。使用する環境で「cacerts」のパスワードが変更されている場合は、それを適切な値に置き換えてください。
e. Request Center が展開されている WebLogic クラスタのすべてのノードの「< JAVA_HOME >¥jre¥lib¥security」ディレクトリに、前のステップで更新した「cacerts」ファイルをコピーします。たとえば、WebLogic クラスタに 3 つのノードが含まれており、各ノードが別のマシンである場合は、このマシンから「cacerts」ファイルを他の 2 つのマシンにコピーします。
f. 「< BEA_HOME >¥user_projects¥domains¥< domain_name >¥servers¥< servername >¥stage¥RequestCenter¥config」ディレクトリの下にある「 newscale.properties 」ファイルを次のように変更します。
g. Request Center が展開されている WebLogic クラスタのノードごとにステップ(f)を繰り返します。
h. Request Center の WebLogic クラスタを再起動します。
ステップ 2 ステップ 1 を実行しないようにするために、Service Link サービスの非セキュア ポートおよびセキュア ポートをどちらもオンにする場合があります。このようにすると、Request Center アプリケーションが非セキュア URL(http://< hostname >:9001)を使用して引き続き Service Link に接続できます。ただし、すべての外部システムからの非セキュア ポートへのアクセスをブロックするために、(ファイアウォール システムなど)なんらかの対策を立てることもできます。
インストール時には、WebSphere サーバの非セキュア ポート( WC_defaulthost )およびセキュア ポート( WC_defaulthost_secure )がどちらも WebSphere セットアップ プログラムによって自動的に設定されます。また、WebSphere サーバの「 default 」という名前のエイリアスの下に、自己署名証明書(有効期限 1 年)も自動的にインストールされます。次のいずれかを実行するよう選択できます。
• Service Link が動作している WebSphere サーバの「 default 」自己署名証明書を使用する。
• この章の最初で作成した「slkeystore.jks」ファイルの証明書を使用する。
• WebSphere サーバ用に別の自己署名証明書をする。
このマニュアルでは、WebSphere サーバ用の自己署名証明書を作成する方法は説明しません。ただし、以降のセクションには、(a)既存の「 default 」証明書を使用する方法、または(b)「slkeystore.jks」ファイルの証明書を使用する方法についての説明があります。
どの証明書を使用するかを選択する前に、まず次のセクションで説明する手順を実行し、Service Link が動作している WebSphere サーバで使用されているセキュア ポート番号およびキーストアを特定する必要があります。
ステップ 1 WebSphere 管理コンソールにログインし、[Servers] > [Application servers] に移動します。
ステップ 2 Service Link が展開されている WebSphere サーバの名前をクリックします。
クラスタ化された WebSphere 環境では、クラスタに属していない WebSphere サーバに Service Link を展開する必要があります。必ず Service Link に適した WebSphere サーバを特定してください。
ステップ 3 [Configuration] タブの [Ports] ノードを展開します。
ステップ 4 [WC_defaulthost] および [WC_defaulthost_secure] に設定されているポート番号を特定します。「WC_defaulthost」のポート番号は非セキュア ポート、「WC_defaulthost_secure」のポート番号はセキュア ポートです。後で必要になるため、セキュア ポート番号を書き留めます。
ステップ 5 [Security] > [SSL certificate and key management] に移動します。
ステップ 6 [Manage endpoint security configurations] をクリックします。
ステップ 7 [Inbound] > [< cell_name >] > [nodes] > [< node_name >] > [servers] > [< SL_server >] を展開します。ここで、< SL_server > は Service Link が展開されている WebSphere サーバです。
(注) クラスタ化された WebSphere 環境では、クラスタに属していない WebSphere サーバに Service Link を展開する必要があります。したがって、必ず Service Link に適したサーバを特定してください。
次のスクリーンショットおよびこのセクションの以降のスクリーンショットは単なる例です。WebSphere 環境は、<cell_name>、<node_name>、および <SL_server> によって表示が異なります。
ステップ 8 [< SL_server >] リンクをクリックして、その設定ページを開きます。[Inherited SSL configuration name] フィールドに表示されている値を確認します。たとえば、次のスクリーンショットでは、[Inherited SSL configuration name] フィールドには「NodeDefaultSSLSettings」の値が設定されています。
ステップ 9 右側にある [Related Items] セクションで、[SSL configuration] をクリックしてから [NodeDefaultSSLSettings] をクリックします。
ステップ 10 [NodeDefaultSSLSettings] ページで次の値を設定して [OK] をクリックします。
|
|
ステップ 11 [Save directly to the master configuration] をクリックします。
ステップ 12 [NodeDefaultSSLSettings] ページを再度開き(上記のスクリーンショットを参照)、右側にある [Related Items] セクションで [Key stores and certificates] をクリックします。
ステップ 13 [NodeDefaultKeyStore] をクリックします。
ステップ 14 [Additional Properties] セクションで [Personal certificates] をクリックします。
ステップ 15 「 default 」エイリアスを検索し、証明書の有効期限が切れていないことを確認します。
ステップ 16 「 default 」証明書の有効期限が切れておらず、この証明書を Service Link サービスに使用する場合は、下記の「「default」証明書の使用」に進みます。
ステップ 17 一方、このセクションの最初で「slkeystore.jks」ファイルに作成した証明書を使用する場合は、「「slkeystore.jks」ファイルの使用」に進みます。
ステップ 1 [Personal certificates] ページで、「 default 」エイリアスの前にあるチェックボックスをオンにしてから [Extract] ボタンをクリックします。
|
|
ステップ 4 Service Link が展開されている WebSphere サーバを再起動します。
ステップ 5 「SystemOut.log」ログ ファイルを参照して次のようなメッセージがあることを確認し、WebSphere サーバがセキュア ポート(つまり、ポート 9443)で起動したことを確認します。
これで、Service Link サービスが SSL に対応し、「 default 」証明書を使用するようになりました。
ステップ 6 Service Link サービスの非セキュア ポートをディセーブルにする場合は、外部システムを管理するシステム管理者に「C:¥temp¥default_signer.cer」ファイルを送信します。このファイルには、「 default 」証明書の署名者証明書が格納されています。この証明書は、SSL 接続時に外部システムが Service Link サービスと信頼できるハンドシェイクを確立できるように、外部システムのトラストストアにインポートする必要があります。また、外部システムは Service Link サービスの https URL に接続する必要があります。たとえば、変更前の Service Link URL が「http://< servername >:9080/IntegrationServer/ishttplistener/< agent_name >」であるとします。この URL は、「https://< servername >:9443/IntegrationServer/ishttplistener/< agent_name >」に変更する必要があります。
ステップ 1 WebSphere Administration Server が動作しているマシンの一時ディレクトリに、(この章の最初で作成した)「slkeystore.jks」ファイルをコピーします。たとえば、ファイルを C:¥temp¥slkeystore.jks にコピーします。
ステップ 2 [Personal certificates] ページで [Import] ボタンをクリックします。
|
|
ステップ 5 [Save directly to the master configuration] をクリックします。
ステップ 6 「servicelink」証明書が正しくインポートされたことを確認します。
ステップ 7 現在のページの上部にあるブレッドクラムで WebSphere サーバの名前をクリックします。たとえば、次のスクリーンショットでは、ブレッドクラム内の [server1] リンクをクリックします。
|
|
ステップ 10 [Save directly to the master configuration] をクリックします。
ステップ 11 Service Link が展開されている WebSphere サーバを再起動します。
ステップ 12 「SystemOut.log」ログ ファイルを参照して次のようなメッセージがあることを確認し、WebSphere サーバがセキュア ポート(つまり、ポート 9443)で起動したことを確認します。
これで、Service Link サービスが SSL に対応し、「slkeystore.jks」ファイルからインポートした「servicelink」証明書を使用するようになりました。
ステップ 13 Service Link サービスの非セキュア ポートをディセーブルにする場合は、外部システムを管理するシステム管理者に(この章の最初で作成した)「slsigner.cer」ファイルを送信します。このファイルには、「servicelink」証明書の署名者証明書が格納されています。この証明書は、SSL 接続時に外部システムが Service Link サービスと信頼できるハンドシェイクを確立できるように、外部システムのトラストストアにインポートする必要があります。また、外部システムは Service Link アプリケーションの https URL に接続する必要があります。たとえば、変更前の Service Link URL が「http://< servername >:9080/IntegrationServer/ishttplistener/< agent_name >」であるとします。この URL は、「https://< servername >:9443/IntegrationServer/ishttplistener/< agent_name >」に変更する必要があります。
ステップ 14 「slsigner.cer」ファイルを作成していない場合は、次の手順を実行すると、ここでこのファイルを作成できます。
a. [Key stores and certificates] > [NodeDefaultKeyStore] > [Personal certificates] ページに移動します。
b. 「servicelink」エイリアスの前にあるチェックボックスをオンにしてから、[Extract] ボタンをクリックします。
|
|
Service Link サービスの非セキュア ポートをディセーブルにする場合は、Request Center サービスの 信頼できる Java 認証局キーストア にも署名者証明書をインポートする必要があります。これは、クラスタに属していない、独立した WebSphere サーバで Service Link が動作するためです。(Request Center および Business Engine のみ、クラスタにインストールできます)。Request Center は、実行時に Service Link サービスに接続する「クライアント」として機能します。Request Center のトラストストアに署名者証明書をインポートするには、次の手順を実行します。
ステップ 1 WebSphere 管理コンソールにログインし、[Security] > [SSL certificate and key management] に移動します。
ステップ 2 [Manage endpoint security configurations] をクリックします。
ステップ 3 [Outbound] > [< cell_name >] > [clusters] > [< cluster_name >] を展開します。ここで、< cluster_name > は Request Center アプリケーションが展開されている WebSphere クラスタです。
次のスクリーンショットおよびこのセクションの以降のスクリーンショットは単なる例です。WebSphere 環境は <cell_name> および <cluster_name> によって表示が異なります。
ステップ 4 [<cluster_name>] リンクをクリックして、その設定ページを開きます。[Inherited SSL configuration name] フィールドに表示されている値を確認します。たとえば、次のスクリーンショットでは、[Inherited SSL configuration name] フィールドには「CellDefaultSSLSettings」の値が設定されています。
ステップ 5 右側にある [Related Items] セクションで、[SSL configuration] をクリックしてから [CellDefaultSSLSettings] をクリックします。
ステップ 6 [Trust store name] フィールドの値をチェックします。たとえば、この値は「CellDefaultTrustStore」などに設定されます。
ステップ 7 右側にある [Related Items] の [Key stores and certificates] をクリックします。
ステップ 8 [CellDefaultTrustStore] をクリックします。
ステップ 9 右側の [Signer certificates] をクリックします。
ステップ 11 次の値を入力し、[OK] をクリックします。
|
|
ステップ 12 [Save directly to the master configuration] をクリックします。
ステップ 13 「RequestCenter.ear¥config¥」ディレクトリの下の「 newscale.properties 」ファイルを次のように変更します。
ステップ 14 Request Center が展開されている WebSphere クラスタのノードごとにステップ 13 を繰り返します。
ステップ 15 Request Center の WebSphere クラスタを再起動します。
ステップ 16 上記のステップ 1 を実行しないようにするために、Service Link サービスの非セキュア ポートおよびセキュア ポートをどちらもオンにする場合があります。このようにすると、(WebSphere クラスタで動作している)Request Center アプリケーションが非セキュア URL(http://< hostname >:9080)を使用して引き続き Service Link に接続できます。ただし、すべての外部システムからの非セキュア ポートへのアクセスをブロックするために、(ファイアウォール システムなど)なんらかの対策を立てることもできます。
Service Link エージェントが http/ws アダプタを使用して外部システムに送信メッセージを送信する場合、エージェントは外部 Web サーバに http 要求または Web サービス要求を送信するクライアントとして機能します。外部 Web サーバが SSL 対応の場合、この Web サーバとセキュアな接続を確立するためには、Service Link にある設定が必要な場合があります。
• Service Link エージェントの送信 URL は、外部 Web サーバの https アドレスおよびセキュア ポート番号を指す必要があります。
• SSL 経由で信頼できるハンドシェイクを確立するには、外部 Web サーバのデジタル証明書を検証できる有効な署名者証明書(公開キー証明書)がクライアント(つまり、Service Link サービス)に必要です。外部 Web サーバの証明書が VeriSign などの既知の認証局(CA)によって署名されていないと、多くの場合は SSL ハンドシェイク時に Service Link が外部 Web サーバの証明書を検証できず、接続に失敗します。この場合は、Service Link サービスが使用する 信頼できる認証局キーストア を署名者証明書にインポートする必要があります。
(注) Service Link が複数の SSL 対応 Web サーバに接続している場合は、外部 Web サーバごとに 1 つずつ、複数の署名者証明書をインポートする必要がある場合があります。
Service Link は、クライアントとしては SSL ハンドシェイク時のクライアント証明書認証をサポートしていません。
ステップ 1 Service Link にアクセスできるユーザとして Request Center にログインします。
ステップ 2 Service Link モジュールに移動して、[Manage Integrations] タブを選択します。
ステップ 4 エージェントの [Outbound Properties] ページを開きます。
ステップ 5 [HttpOutboundAdapter.RoutingURL] フィールドで、https アドレスおよびセキュア ポート番号を入力します(たとえば、https://192.168.21.202:8444/HTTPSimulator/ など)。
ステップ 6 [HttpOutboundAdapter.AcceptUntrustedURL] フィールドの値を [false] に設定して、セキュアな接続が行われるようにします。
署名者証明書をインポートする手順は、Service Link が動作しているアプリケーション サーバ(「JBoss 4.2.3」、「WebLogic 10.3」、または 「WebSphere 7」)によって異なります。アプリケーション サーバ固有の手順を実行する前に、次の手順を実行する必要があります。
• 外部 Web サーバの署名者証明書をファイルから取得します。これを行うには、外部 Web サーバを管理するシステム管理者に連絡し、その Web サーバのセキュリティ保護に使用するデジタル証明書の署名者証明書(公開キー)をエクスポートするよう依頼します。署名者証明書は、「 Base64 で符号化された ASCII 」形式でエクスポートする必要があります。次に、Base64 で符号化された証明書の例を示します。
(注) 外部 Web サーバの証明書の署名者が、VeriSign や Thawte などのよく知られた認証局である場合、既知の多くの CA 署名者は Sun JDK ですでに認識済みであるため、ほとんどの場合にはこの手順をスキップできます。WebSphere 信頼ストアにはサードパーティの認証局署名者が含まれていないため、WebSphere ではこの手順を完了する必要があります。
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 キーストア です。
(注) <JAVA_HOME> が、JBoss アプリケーション サーバで使用する Java ディレクトリであることを確認します。「<APP_HOME>¥bin」ディレクトリにあるファイル「setEnv.cmd」で、JAVA_HOME 設定を探します。たとえば、set JAVA_HOME=C:¥jdk1.6.0_23 などが該当します。
ステップ 3 [Command Prompt] ウィンドウで次のコマンドを実行して、署名者証明書を「cacerts」キーストアにインポートします。
(注) 上記のコマンドでは、「cacerts」キーストア ファイルのパスワードがまだデフォルト値の「changeit」であると仮定しています。使用している環境で、パスワードを正しい値に置き換えます。-alias パラメータについては、値「extws」を、この署名者証明書に使用する適切なエイリアスに置き換えることができます。複数の署名者証明書をインポートする場合は、署名者証明書ごとに一意のエイリアス名を割り当てる必要があります。
ステップ 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 [Command Prompt] ウィンドウで次のコマンドを実行して、署名者証明書を「cacerts」キーストアにインポートします。
(注) 上記のコマンドでは、「cacerts」キーストア ファイルのパスワードがまだデフォルト値の「changeit」であると仮定しています。使用している環境で、パスワードを正しい値に置き換えます。-alias パラメータについては、値「extws」を、この署名者証明書に使用する適切なエイリアスに置き換えることができます。複数の署名者証明書をインポートする場合は、署名者証明書ごとに一意のエイリアス名を割り当てる必要があります。
WebSphere 管理コンソールにアクセスできるユーザとして、次の手順を実行します。
ステップ 1 WebSphere 管理サーバが稼動しているマシンの一時ディレクトリに(外部システムの)署名者証明書ファイルをコピーします。たとえば、署名者証明書ファイルが「extws.cer」の場合は、このファイルを WebSphere マシンの「C:¥temp¥extws.cer」にコピーします。
ステップ 2 WebSphere 管理コンソールにログインし、[Security] > [SSL certificate and key management] に移動します。
ステップ 3 [Manage endpoint security configurations] をクリックします。
ステップ 4 [Outbound] > [< cell_name >] > [nodes] > [< node_name >] > [servers] > [< SL_server >] を展開します。ここで、< SL_server > は Service Link が展開されている WebSphere サーバです。
クラスタ化された WebSphere 環境では、クラスタに属していない WebSphere サーバに Service Link を展開する必要があります。したがって、必ず Service Link に適した WebSphere サーバを特定してください。
このセクションのすべてのスクリーンショットでは、<cell_name>、<node_name> および <SL_server> で値の例を示しています。使用している WebSphere 環境に応じて、これらの値を置き換えてください。
ステップ 5 [< SL_server >] リンクをクリックして、その設定ページを開きます。[Inherited SSL configuration name] フィールドに表示されている値を確認します。たとえば、次のスクリーンショットでは、[Inherited SSL configuration name] フィールドには「NodeDefaultSSLSettings」の値が設定されています。
ステップ 6 右側にある [Related Items] セクションで、[SSL configuration] をクリックしてから [NodeDefaultSSLSettings] をクリックします。
ステップ 7 [NodeDefaultSSLSettings] ページで次の値を設定して [OK] をクリックします。
|
|
ステップ 8 [Save directly to the master configuration] をクリックします。
ステップ 9 (上記のスクリーンショットに示す)[NodeDefaultSSLSettings] ページをもう一度開き、右側の [Related Items] セクションで [Key stores and certificates] をクリックします。
ステップ 10 [NodeDefaultTrustStore] をクリックします。
ステップ 11 右側の [Additional Properties] セクションで、[Signer certificates] をクリックします。
ステップ 13 次の値を入力し、[OK] をクリックします。
|
|
ステップ 14 [Save directly to the master configuration] をクリックします。
ステップ 15 新しく追加した証明書(この例では「extws」)の情報が正しいことを確認します。
ステップ 16 Service Link が展開されている WebSphere サーバを再起動します。
ここでは、WebSphere トレースに関する情報、送信電子メールを制限する方法、および電子メールの生成を制御する方法について説明します。また、サポートに関するご質問や、システム環境およびエラー情報の追跡方法についてシスコに連絡する場合の情報も記載しています。
com.opensymphony.oscache.plugins.clustersupport.AbstractBroadcastingListener
com.opensymphony.oscache.plugins.clustersupport.JavaGroupsBroadcastingListener
システムで WebSphere トレースをイネーブルにするには、次の手順を実行します。
ステップ 1 [Logging and Tracing] > [ Yourserver ] > [Configuration] に移動します。
ステップ 3 表示されるツリーの項目で、[Servlet_Engine] ノードを展開します。
ステップ 5 [Apply] をクリックし、[Close] をクリックします。
ステップ 7 設定の変更をマスター設定に保存し、Webapp を再起動します。
サービス設計のテスト時や非実稼動環境の場合には、送信電子メールを制限することがあります。
送信電子メール機能を制限することにより、実際の実行者やサービスをオーダーした顧客に対して電子メールの送信を制限したり、禁止したりすることができます。
開発環境ですべての電子メール テンプレートを「仮のアドレス」に変更することは、実際には行うべきではありません。まず、これには非常に時間がかかります。さらに重要なのは、テンプレート アドレスを元に戻したときに、多くのテストが無効になってしまう点です。このため、正しい受信者が適切な電子メールを受け取ることを確認する必要があります。
テンプレートで名前空間変数のみを使用し、非実稼動環境のユーザがディレクトリ統合によってリフレッシュされる場合は、LDAP マッピングを変更して、同じ電子メール アドレスまたは類似した仮のアドレスをユーザ全員に与えることができます。次に例を示します。
ただし、この方法でも、電子メールが正確に配信されることを十分にテストすることはできません。
より確実な対応策は、開発インスタンスや他のインスタンス専用に、電子メールがボックスの外部には配信されない SMTP(電子メール)サーバを使用することです。開発サーバおよびテスト サーバに対して、(仮であるかどうかにかかわらず)すべての電子メールを標準メールボックス(rctestmailbox@company.com など)に配信する SMTP サーバを設定できます。この方法では、Request Center 設定を変更する必要がないため、電子メールのテストが非常に簡単になります。プロジェクト チームは、そのテスト メールボックスを開くことができるだけで十分です。
この方法では、受信者をオーバーライドしてテスト用の電子メール ボックスに転送する別個のテスト SMTP サーバを顧客が設定できる必要があります。 実稼動環境では、実稼動 SMTP サーバをポイントする必要があります。
この方法を使用する場合は、これらのフィールドの名前空間式や他のロジックをテスターが検証できるようにするために、宛先および CC のアドレスを <!-- Comment --> タグで囲んで電子メール テンプレートの HTML 本文に追加します。
Request Center では、送信電子メールのエンベロープが制御され、デフォルトでは 1 つのメッセージが複数の受信者に送信されます。複数受信者のメッセージが同じ SMTP サーバに送信されます。
代わりに、単一受信者の電子メールを送信すると、CPU およびネットワーク帯域幅の使用率への悪影響を最小限に抑えることができます。これは、be.properties ファイルの次の設定によってイネーブルになります。
この設定は、1 人の受信者が無効であるためにメッセージ全体が拒否されるという SMTP サーバの問題を避けるためにだけ使用します。
SMTP 接続は、Email.ServerDownCount=10 回試行された後で、Email.RescheduleOffset(ミリ秒)間一時停止します。
メールボックスの空き領域なし、バウンス、または他の配信に関する問題は、Email.RetryCount=4 の設定に基づいて再試行されます。
長時間の停電や Service Link アプリケーションの不正な設定が原因で、外部タスクが Service Link で対応する送信メッセージを作成しないことがあります。
根底にある問題が Service Link で解決され、アプリケーションが稼動したら、問題のある外部タスクを Service Link に対して再発行し、送信メッセージを作成して提供計画を続行できます。再発行ユーティリティは、次のサイトからアクセスできます。
http:// <host>:<port>//RequestCenter/nccutil/TriggerMessageToSL.jsp
1 つまたは複数の送信 Service Link メッセージが欠落している要求の要求 ID を入力します。要求に関連付けられているすべての承認タスクと提供タスクが評価され、再発行を必要とするタスクのみが処理されて送信メッセージが作成されます。
「環境マトリクスの例」に示すようなマトリクスを使用して、使用している環境のシステムを文書に記録しておくことを推奨します。
シスコでは、各バージョンの Service Portal が認定されているソフトウェアの詳細を示すサポート マトリクスを発行しています。Cisco Technical Assistance Center(TAC)には、このマトリクスの最新バージョンが常に用意されており、各リリースおよびサービス パックに合わせて調整されています。
次の操作に影響する可能性があるシステム メンテナンス タスクを行う前に、Cisco Technical Assistance Center(TAC)にご連絡ください。
• サーバ オペレーティング システムのパッチおよびアップグレード
• Service Portal アプリケーション サーバのパッチおよびアップグレード:更新がシスコでサポートされていることを最初に確認してください。
「Our Apologies」例外が発生した場合、Administration モジュールの [Settings] の [Debugging] オプションでサイトのデバッグをオンにすることができます。
[Debugging] により、現在のページの URL がページ下部に追加されます。URL をクリックすると、シスコのサポート担当者にとって有用な追加情報のリンクが表示されます。
操作が終了したらデバッグをオフにしてください。このようにしないと、エンドユーザを困惑させる原因となります。また、パフォーマンスに悪影響を与える可能性もあります。
アプリケーション ログは、トラブルシューティングを行うための重要なメカニズムです。このログで「例外」(ボトムアップ方式)を調べることにより、該当するエラー メッセージが見つかることがあります。
Service Link サーバのログには、その日のすべての Service Link トランザクションの詳細が表示されます。Business Engine と Service Link 間のインタラクションに関係する問題をトラブルシューティングする場合は、このファイルと Request Center サーバ ログを相互に関連付けると有用です。
サービス設計時に発生する問題は、誤ったサービス設定に関係していることがあります。実稼動環境でのみ発生する問題は、データまたはプラットフォームに依存していることがあります。Cisco Technical Assistance Center(TAC)から、データベースのダンプを送信するよう依頼されることがあります。このダンプをテスト ラボでインストールすることにより、エラーが発生した環境を正確にエミュレートできます。顧客には、データベースをシスコ サポート サイトにアップロードして調査できるようにするためのログインおよび資格情報が必要です。
Administration モジュール設定の [Debugging] オプションでサイトのデバッグをオンにします。
[Debugging] により、現在のページの URL がページ下部に追加されます。URL をクリックすると、追加情報のリンクが表示されます。操作が終了したらデバッグをオフにしてください。このようにしないと、エンドユーザを困惑させる原因となります。また、パフォーマンスに悪影響を与える可能性もあります。
アプリケーション ログは、トラブルシューティングを行うための重要なメカニズムです。このログで「例外」(ボトムアップ方式)を調べることにより、該当するエラー メッセージが見つかることがあります。
Service Link サーバのログには、その日のすべてのトランザクションの詳細が表示されます。Business Engine と Service Link 間のインタラクションに関係する問題をトラブルシューティングする場合は、このファイルと Request Center ログを相互に関連付けると有用です。
ここでは、重大なエラー状態に関する情報を記載しています。この情報は、個別のエラー メッセージに基づいて示されており、状態ごとに次の情報を示します。
Service Portal および関連コンポーネントのエラー ログは、次の場所にあります。
|
|
|
|
||
<BEA_HOME>/user_projects/domains/<domain>/servers/<server>/logs/<server>.log |
||
<WAS_HOME>/profiles/<profilename>/logs/server1/SystemOut.log |
||
|
次のエラー状態は、エラー状態または関連するエラー メッセージに基づいて示されます。
エラー自体はシステム内のいくつかの異なるエラー状態が原因であっても、複数のエラー状態が同じシステム動作を引き起こすことがあります。たとえば、LDAP サーバに接続できない場合、次に示すいくつかのエラー状態が該当することがあります。発生しているエラーとエラー メッセージを一致させることが重要です。
すべてのエラーは、Request Center サーバ ログ ファイルに書き込まれます。このファイルの動作と場所については、上記の説明を参照してください。
ERROR [com.newscale.bfw.ldap.jldap.JLDAPSimpleAuth] LDAPException in Simple Auth: |
|
[Administration] > [Directories] で [LDAP System Authentication Parameters] を確認します。[BindDN] の値が正しいことを確認します。 |
FATAL [LDAPBase] LDAP instance cannot be created netscape.ldap.LDAPException: no host for connection (89) |
|
ERROR [com.newscale.bfw.ldap.LDAPQuery] LDAP netscape.ldap.LDAPException: failed to connect to server ldap://<hostname>:<port> (91) |
|
ERROR [com.newscale.comps.user.dao.LDAPUserDataSource] Single Person search failure, exception thrown: null |
|
[Administration] > [Directories] ページで [Data Source Configuration] を確認します。 |
WARN [com.newscale.bfw.ldap.jldap.JLDAPApi] Required LDAP attribute <attribute_name> is missing from the LDAP system, for DN : ... |
|
Universal Development Methodology(UDM)の標準処理では、サイトがオンラインになった時点で、実装されたサイトごとにこのマトリクスの列を完成させます。通常、Cisco Advanced Services の成果物には、このマトリクスのソフト コピーが含まれており、管理者はそれを最新に保つ必要があります。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|