Prime Service Catalog の保守
Prime Service Catalog の保守

目次

Prime Service Catalog の保守

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

Prime Service Catalog の保守

この章では、アプリケーション コンポーネントのスタートアップ手順とシャットダウン手順、推奨バックアップ プラクティス、アプリケーション コンポーネントの構成管理とカスタマイズ、継続的な保守タスク、および重要なエラー状態、エラー メッセージ、および解決方法について説明します。


(注)  


<APP_HOME> と指定されている場合は、Service Catalog がインストールされているルート ディレクトリを意味します。

システムの強化

Linux Puppet Master、Linux、および Windows のターゲット VM は、直接もしくはプロキシを介してインターネットにアクセスできる必要があります。 または、内部リポジトリに接続するよう VM を設定することもできます。

ゲートウェイ VM は(各ガイドで)説明されているとおりにトラフィックをルーティングするよう設定し、設定後は制限しないようにする必要があります。

Puppet Master やエージェントをインストールした後で、特定のポートをブロックするファイアウォールや SELinux ルールを実装しないでください。 アプリケーション固有のポートの詳細については、(引用が必要)を参照してください。

(注)  


アプリケーションをインストールするためにターゲット 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 の各展開パッケージ内のアプリケーション サーバに展開されます。


(注)  


各コンポーネントは展開されているとおりにバックアップし、すべてのカスタマイゼーションは展開時または変更時に保存することを推奨します。
  • バックアップ操作は定期的にスケジュールする必要があります。

次のデータベースをバックアップする必要があります。

  • トランザクション・データベース(デフォルトでは Service Catalog)。本番データのみでなく、設定サービス、サービス コンポーネント、およびその他のアプリケーション オブジェクトのメタデータが保存されています。
  • 分析データベース。標準レポートの作成用データおよび、Service Catalog と Demand Center のデータ マート用データが保存されています。
  • コンテンツ保存データベース。ビジネス視点のレポート環境で使用可能なユーザ生成コンテンツが保存されています。 このようなコンテンツには、すべてのレポートの定義(Service Catalog から提供された定義と Advanced Reporting のユーザから書き込まれた定義)、レポートのビュー、スケジュール、および任意のレポートから生成された保存済みのレポートが含まれます。

アプリケーション サーバのチューニング

チューニングに関する次の推奨事項は、多くの Servce Catalog サイトに適用されます。 チューニングに関するこのほかの推奨事項については、各アプリケーション サーバのマニュアルを参照してください。

Service Catalog の圧縮の設定

組織に遠隔地のユーザが多数いる場合は、HTTP 応答の GZIP 圧縮(RFC 1952)をオンにすると役立ちます。RFC 2616 の次のセクションを参照してください。

  • セクション 3.5:Content-coding
  • セクション 14.3:Accept-Encoding
  • セクション 14.11:Content-Encoding

GZIP 圧縮は、低速または遅延の大きいネットワークを使用するユーザにとって有用です。 ただし、GZIP 圧縮により、サーバとユーザのブラウザにわずかながらオーバーヘッドが発生します。

GZIP 圧縮を有効にするには、以下を実行します。


    ステップ 1   RequestCenter.war/WEB-INF で web.xml を探します。 たとえば、一般的な場所は次のとおりです。

    例:
    • C:\jboss-as-7.1.1.Final\ServiceCatalogServer\deployments\RequestCenter.war\WEB-INF
      
    ステップ 2   次のエントリを検索します(コメントアウトされています)。

    例:
    • <!--filter><filter-name>CompressingFilter</filter-name><filter-class>com.planetj.servlet.filter.compression.CompressingFilter
      </filter-class></filter-->
      
    ステップ 3   コメントを削除します。エントリは次のようになります。

    例:
    • <filter><filter-name>CompressingFilter</filter-name><filter-class>com.planetj.servlet.filter.compression.CompressingFilter
      </filter-class></filter>
      
    ステップ 4   次のエントリを検索します(コメントアウトされています)。

    例:
    • <!--filter-mapping id="newscale_gzip_filter_1"><filter-name>CompressingFilter</filter-name><url-pattern>/*</url-pattern>
      </filter-mapping-->
      
    ステップ 5   コメントを削除します。エントリは次のようになります。

    例:
    • <!--filter-mapping id="newscale_gzip_filter_1"><filter-name>CompressingFilter</filter-name><url-pattern>/*</url-pattern>
      </filter-mapping-->
      
    ステップ 6   ファイルを保存し、アプリケーション サーバを再起動します。

    Java メモリ設定の変更

    Java メモリ設定は、アプリケーション サーバが使用する Java 仮想マシン(JVM)専用の設定です。 "java -h" コマンドと "java -X" コマンドを使用すると、システムで使用可能なすべてのオプションのリストが返されます。 これらのコマンドを発行する場合は、ご利用中のアプリケーション サーバが使用する JVM と同じ JVM を呼び出していることを確認してください。

    • 必要に応じて -ms -mx(通常は、JVM 内のヒープとして 1 GB のメモリが予約されます)。
    • -server モードが Oracle JVM に推奨されています。
    • 一般的な変更として、引数 --XX:MaxPermSize=128m を指定して、ガベージ コレクタの永続的世代の最大サイズを 128 MB に増やします。

    Service Catalog で「メモリ不足」エラーが発生する場合は、JVM で使用可能な最小および最大のヒープ サイズを管理する Java メモリ スイッチを調整しなければならない場合があります。 たとえば、次の設定は WebLogic に正しく適用されます。

    MEM_ARGS="-verbose:gc -Xms1024m -Xmx1024m
     -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:MaxPermSize=256m" 
    

    JMS Queue 接続ファクトリ設定

    キュー接続ファクトリの接続数は、JMS サーバの作業負荷に基づいて設定する必要があります。 1 つの Service Catalog インスタンスに推奨される設定は 25 です。 必要な接続数に関して、クラスタのサーバ数に基づいた厳格なルールはありません。 アプリケーション環境に最適な接続設定を実現するには、チューニング作業が必要となります。

    JDK のアップグレードと置き換え

    JDK を新しいバージョンにアップグレードするには、次の手順を実行します。

    • <APP_HOME>/bin ディレクトリで「setEnv.cmd」という名前のスクリプトを編集し、新しい JDK へのパスを指定します。
    • スタートアップ スクリプトを使用している顧客の場合は、改訂された setEnv.cmd ファイルを保存した後、サーバを再起動します。
    • Windows サービスを使用している顧客の場合は、Windows サービスを停止し、(<APP_HOME>\bin\uninstall*.cmd のスクリプトを使用して)Windows サービスをアンインストールした後、(<APP_HOME>\bin\install*.cmd のスクリプトを使用して)そのサービスを再度インストールします。

    データベースのチューニング

    Service Catalog データベースを設定およびチューニングする方法に関する主な FAQ のいくつかと、それらの質問への回答を示します。 これらの問題の詳細については、該当するデータベースに固有のマニュアルを参照してください。 これらの FAQ の多くは、SQLServer よりもチューニングの機会が多い Oracle に関するものです。

    • Oracle および SQLServer のどちらの場合も、RAID 5 ではなく、RAID 1+0(ストライプ化 + ミラー化)ディスクにデータベース ファイルをインストールすることが推奨されます。これが、ソフトウェアのインストールに推奨される選択肢です。
    • Oracle データベースは、ローカル管理表領域(LMT)および自動セグメント領域管理(ASSM)を使用するように設定する必要があります。 これらのテクノロジーによって、テーブルまたはテーブルスペースのパラメータ(PCTUSED、PCTFREE、INITIALEXTENT、NEXTEXTENT)が正しく指定されないというこれまでの問題が解消されます。
    • OLTP Service Catalog および OLAP データベース(標準レポートと Service Catalog データ マート)用には別々のデータベースまたはインスタンスを使用します。 10g よりも前のリリースの Oracle の場合、ブロック サイズの異なるテーブルスペースを作成するには、このことが必須でした。 10g 以降の場合でも、OLTP データベースと OLAP データベースの大きく異なるアクティビティに合わせて設定パラメータを調整できるように、 このことが推奨されます。 Oracle DBA は、データ ウェアハウスのデータベース管理について詳しく書かれた Oracle のマニュアルを読む必要があります。

    Service Catalog 固有の推奨事項

    • OLTP データベースの場合は、REQUESTCENTER という名前のプライマリ テーブルスペースを作成します。 このテーブルスペースには 1 ユーザにつき 10 MB、最小サイズ 500 MB を指定します。 組織のベスト プラクティスに合ったエクステント管理の戦略をデータベース管理者が選択する必要があります。
    • 必要なデータベース ストレージを非常におおまかに見積もると、完了した要求ごとに 500 KB となります。 これは、サービス フォームの複雑さ、承認構造、および提供計画によって大きく異なります。
    • 多数の Service Link タスクを含むサイトでは、Service Link メッセージの保存が原因でデータベース サイズが非常に大きくなることがあります。 最新バージョンの Service Catalog には、これらのメッセージを圧縮するさらに効率的なアルゴリズムと、メッセージ コンテキストを設定する方法が追加されています。 詳細については、『Cisco Prime Service Catalog Integration Guide』を参照してください。 完了したタスクの Service Link メッセージを消去するデータベース スクリプトが RequestCenter データベースのストアド プロシージャとして用意されており、ワンタイム ジョブとして実行したり、定期的に実行したりできます。

    Oracle のチューニング

    Oracle データベースのパフォーマンスは次の方法で最適化できます。

    • OLTP データベース(テーブルとインデックス)の統計情報を定期的に収集します。 これは Oracle Enterprise Manager(OEM)を介して自動化できます。
    • カラムレベルのヒストグラム分析を実行して、Service Manager のインデックスをさらに最適化します。
    • Service Catalog データ マートがリフレッシュされた後に、データ マートの統計情報を収集します。
    • テーブル割り当て、テーブルスペースのフラグメンテーション、および行連鎖を確認します。
    • クエリーのパフォーマンスをモニタリングするために SELECT_CATALOG_ROLE へのアクセス権を付与します。

    次のような設定を適用します。

    表 1 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 でテーブルの統計情報を収集する場合、テーブル内のカラムのデータ分布に関する情報が収集されます。 データ分布に関する最も基本的な情報は、列の最大値と最小値です。 ただし、カラム内のデータがスキューしている場合、このレベルの統計情報ではオプティマイザのニーズからすると不十分な可能性があります。 スキューしたデータ分布の場合は、指定した列のデータ分布を記述する列統計の一部として、ヒストグラムを作成することもできます。
    • ヒストグラムは、DBMS_STATS 収集プロシージャの METHOD_OPT 引数を使用して指定されます。 Oracle Corporation では、METHOD_OPT を FOR ALL COLUMNS SIZE AUTO に設定することを推奨しています。 この設定を使用すると、ヒストグラムを必要とするカラムおよび各ヒストグラムのバケット数(サイズ)が、Oracle によって自動的に決定されます。 また、ヒストグラムが必要なカラムと各ヒストグラムのサイズは手動で指定することもできます。

    ヒストグラムレベルの統計情報の収集が不可欠なテーブルは、次のとおりです。

    • TxActivity
    • TxProcess
    • TxRequisition
    • TxRequisitionEntry
    • DirPerson
    • DirOrganizationalUnit
    • UIEntry

    各テーブルの統計情報を収集する DBMS_STATS コマンドの例は、次のようになります。

    BEGIN
      DBMS_STATS.GATHER_TABLE_STATS (OWNNAME => 'RCUser',       TABNAME => 'TXACTIVITY', 
          METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO');
    END;

    SQLServer のチューニング

    次のコマンドでスナップショットを有効にします。

    ALTER DATABASE <database name> SET READ_COMMITTED_SNAPSHOT ON 
    

    揮発性の Service Catalog テーブルには特に、SQLServer DBCC Reindex コマンドを推奨します。 このプロセスは、勤務時間外で定期的にスケジュールする必要があります(一般的には週に 1 度)。

    次に示すテーブルは最も揮発性が高く、DBCC Reindex の対象となります。

    表 2 SQLServer コマンド

    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 データベース コンポーネントのサイジング

    Cognos は、すべてのレポートとキューの定義を ContentStore という名前のデータベースに格納します。 Cognos KnowledgeBase には、ContentStore のサイズ変更と維持に関するエントリが格納されます。 特に重要なのは、ContentStore に必要なサイズを算出するために、予測される使用状況の統計に基づいて発行される計算式です。

    これらの計算式を組み込んだスプレッドシートは、Cisco Technical Assistance Center(TAC)から入手可能です。 次に例を示します。

    表 3 Cognos データベース コンポーネント

    コンポーネント

    推定値

    ユニットあたりの領域(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

    OLTP データベース テーブル

    トランザクション データベースは、プレフィックス命名規則を採用した一連のリレーショナル テーブルで構成されます。 次の表は、DBA または本番データベースの保守やチューニングを行う必要がある人への支援として示されています。 これらのテーブルの構造およびコンテンツの所有権はシスコに帰属します。シスコでは、リリースごとにテーブルの名前または構造を自由に変更する権利を留保します。

    表 4 OLTP データベース テーブル

    プレフィックス

    意味

    使用方法

    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 プロセスでは抽出されません。 履歴要求分割機能を設定する場合は、次の点を考慮してください。

    • 通常、ETL プロセスは頻繁に実行するようにスケジュールされます。 そのため、要求データは履歴テーブルに移行される前にデータマートに収集されます。 データマートでデータ損失が発生しないことを保証するには、履歴要求保存期間を ETL プロセスの頻度を超える値に設定します。 たとえば、ETL が 30 日ごとに実行されるように設定されている場合は、履歴要求保存期間を 31 日以上に設定する必要があります。
    • 履歴トランザクション データを移行するプロセスは、最新の ETL プロセスのタイムスタンプが締切日よりも前であることを検出すると、自動的に一時停止されます。 たとえば、最後の ETL 実行が 5 月 1 日の午後 12 時のときに、移行で 5 月 1 日の午後 12 時 30 分より前に完了した要求が選択されると、直ちに、移行プロセスが終了します。 これにより、データが、移行前に、データマートに抽出するための現在のトランザクション テーブルに保存されることが保証されます。
    • 組織で過去に遡ったデータを収集する(ディクショナリやサービスを事後報告可能にする場合など)ためにデータマートを再構築しなければならない場合は、ETL プロセスを再実行しても変更が履歴トランザクションに反映されません。 実際には、履歴データを消去するとデータマートで回復できなくなります。 このようなデータマートの再構築プロセスが使用可能なことを保証するには、データ保存期間を遡及的変更のプロビジョニングを含む期間に設定します。 加えて、データマートが上記理由による再構築プロセスで空にならないようにする必要があります。 ETL の再実行中に削除してデータマートに再挿入できるのは、現在のトランザクション テーブルで使用可能なデータの部分だけです。
    履歴要求処理の主要な設定

    次の設定は履歴要求分割に適用されます。

    1. newscale.properties ファイル(RequestCenter.ear/config ディレクトリに配置)
    2. reqArchival.poller.cron:履歴データを移行するバックグラウンド プロセスの頻度を制御します。 標準の cron 構文を使用し、30 分ごとに実行するようにスケジュールされます。
    3. reqArchival.process.maxRecords:実行ごとに処理する要求の最大数を制御します。 定期保守でプロセスをより長い時間実行させたい場合は、高い数値に設定します。
    4. reqArchival.cutOffDate.days:現在のトランザクション テーブル内の完了した要求の保存期間を制御します。 デフォルトで、この保存期間は 365 日に設定されます。
    5. reqArchival.process.batchSize:データベース コミットごとに含まれる履歴要求の数を制御します。 バッチ サイズが大きいほど処理時間は短くなりますが、データベース サーバで必要な一時スペースまたはロールバック セグメントの容量が増えます。

    1. support.properties ファイル(RequestCenter.ear/config ディレクトリに配置)

    reqArchival.poller.enable:アプリケーション インスタンスを使用して履歴要求移行プロセスを実行できるかどうかを制御します。 クラスタ化された Service Catalog 環境では、常に、1 つのノードだけを使用して移行プロセスが実行されます。 サーバが性能の低いマシンの場合やサーバが災害復旧用の場合は、1 つ以上のノードでこのプロパティが "false" に設定されることがあります。

    上記ファイル内のその他の設定は、通常の環境では変更しないでください。

    要求の消去

    Service Catalog には、選択した日付よりも古いトランザクションまたはユーザが指定したその他の条件を満たすトランザクションを削除するトランザクション消去機能があります。 これを使用すると、アプリケーション管理者はテスト ユーザやサンプル サービスを削除する前にテスト要求を削除することができます。 ただし、消去機能では大量データの消去は実行できません。 また、メンテナンス フェーズが長引かないようにする必要があります。

    ソフトウェア要件
    • 消去スクリプトを実行するデータベース クライアント
    • Oracle の場合は sqlplus がインストールされ、RequestCenter のデータベースに接続するように設定されている必要があります。
    • SQL Server の場合は osql です。
    消去を実行するシステムの準備

      ステップ 1   消去スクリプトを実行する前に RequestCenter データベースをバックアップします。
      ステップ 2   消去スクリプトを実行するときは、Service Catalog および Service Link サービスを停止します。
      ステップ 3   次の場所でユーティリティを探します。

      <APP_HOME>\schema\util\purge

      <APP_HOME> が存在するマシンにデータベース クライアント ソフトウェアがある場合は、そのマシンから消去スクリプトを実行できます。 そうでない場合は、RequestCenter データベースのあるマシン、または前提条件となるデータベース クライアントのある別のマシンに purge フォルダ全体をコピーします。

      ステップ 4   次のファイルが purge フォルダに含まれていることを確認します。
      • AddPurgeFilter.bat

      • AddPurgeFilter.sh

      • ClearAllPurgeFilter.bat

      • ClearAllPurgeFilter.sh

      • PurgeRequisitions.bat

      • PurgeRequisitions.sh

      ステップ 5   Windows オペレーティング システムの場合は .bat ファイル、UNIX または Linux オペレーティング システムの場合は .sh ファイルを実行します。
      注意       

      Service Catalog のサービス パックを適用してある場合は、ステップ 3(上記)を繰り返して、必ず最新バージョンの消去スクリプトを使用してください。サービス パックに含まれるスクリプトは、変更されている場合があります。


      要求の消去

      要求の消去は、次の手順で構成されます。


        ステップ 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 ] に指定可能な値は次のとおりです。

        • CREATIONSTARTDATE
        • CREATIONENDDATE
        • CLOSEDSTARTDATE
        • CLOSEDENDDATE
        • REQUISITIONSTATUS
        • REQUISITIONID
        • REQUISITIONRANGE
        • SERVICEID
        • SERVICENAME
        消去フィルタ条件の追加

        1 つまたは複数のフィルタ条件を追加するには、AddPurgeFilter スクリプトを使用します。 要求が削除されるのは、すべての消去条件を満たす場合のみです。 フィルタ条件は RequestCenter データベースの CnfPurgeFilter テーブルに保存されます。

        データベースのタイプに合わせて次の構文を使用します。

        • [SID] は Oracle データベースの ORACLE_SID です
        • [Server] は SQL Server データベースのサーバ名です
        • [User] は「RCUser」です
        • [Password] は「RCUser」のパスワードです
        • [Purge Filter Name] および [Purge Filter Value] に指定できる値については、パラメータ表を参照してください。

        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 ]

        表 5 消去フィルタ条件

        消去フィルタ名

        説明

        消去フィルタ値

        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" など、二重引用符で囲まれたサービス名。

        (注)      この消去フィルタ値は完全一致する必要があり、大文字と小文字を区別します。

        (注)      UNIX または Linux オペレーティング システムでは、サービス名にスペースが含まれている場合はこの消去フィルタを使用しないでください。
        消去のフィルタ条件の検証

        要求を消去する前に、任意で「リハーサル」を実行して、実際に削除することなく、消去される要求をチェックできます。 これは、フィルタ条件を検証する役割を果たします。

        フィルタ条件を満たす要求のリストを表示するには、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 データベースのユーティリティを使用したワークフローの消去

        Oracle データベースでユーティリティを実行するには、次の手順を実行します。


          ステップ 1   RequestCenter データベースをバックアップします。
          ステップ 2   データベースに対応するクエリー ツール(SQL*Plus など)を使用して、RCUser として RequestCenter データベースに接続します。
          ステップ 3   次のコマンドを実行します。
          • SET SERVEROUTPUT ON

          • EXECUTE sp_PurgeWorkflowTables ([FromDate], [ToDate], [UserName]);

          日付は、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 データベースのユーティリティを使用したワークフローの消去

          SQL Server データベースでユーティリティを実行するには、次の手順を実行します。


            ステップ 1   RequestCenter データベースをバックアップします。
            ステップ 2   データベースに対応するクエリー ツール(SQL Server Management Studio など)を使用して、RCUser として RequestCenter データベースに接続します。
            ステップ 3   makecall ディレクトリで、次のコマンドを実行します。★クライアント指示により、原文と異なる訳文に変更★
            • EXECUTE sp_PurgeWorkflowTables [FromDate], [ToDate], [UserName]

            日付は、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 メッセージを削除します。

            これらのメッセージは(サービス フォームの複雑さおよびエージェントの設定に使用されるコンテンツ タイプ オプションに応じて)きわめて大きくなる可能性があるため、メッセージを削除することにより、Service Link 関連のデータを保持するために必要なデータベース サイズが大幅に削減されます。 外部メッセージは変更されないままです。

            Oracle データベースのユーティリティを使用したメッセージの消去

            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 データベースのユーティリティを使用したメッセージの消去

              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 Server の再起動

                Cognos コンポーネントに依存する Advanced Reporting のすべてのインストールは Windows システム上にあるため、Cognos Configuration Manager から、または Windows サービスを使用して Cognos アプリケーションを再起動する手順は、どちらも Windows 固有のタスクです。

                システムを再起動するには、次の手順を実行します。


                  ステップ 1   [スタート(Start)] > [すべてのプログラム(All Programs)] > [IBM Cognos 8-64] > [IBM Cognos 構成(IBM Cognos Configuration)] を選択します。
                  ステップ 2   [アクション(Actions)] > [再起動(Restart)] を選択します。

                  Windows サービスを使用した再起動

                  次のサービスを停止して再起動します。

                  • IBM Cognos 10.2.1:レポーティングのオプションすべてに必要
                  アプリケーションの展開

                  Service Catalog 用の .war ファイルはファイル システムに展開されます。 このファイルの正確な場所は、アプリケーション サーバによって異なります。 Service Link アプリケーションは、.war ファイルの ISEE.war(Integration Server Enterprise Edition)として提供されます。

                  起動およびシャットダウンの手順

                  ここでは、アプリケーション サーバの起動とシャットダウンの手順について説明します。対象となるサーバは次のとおりです。

                  • Cisco Prime Service Catalog アプリケーション
                  • Cisco Prime Service Catalog Integration サーバ(Service Link)
                  • Reporting サーバ
                  Prime Service Catalog、Service Link、Reporting サーバの再起動

                  サーバを再起動するには、アプリケーション サーバのサーバ コンソール、またはコマンドライン スクリプトを適宜使用します。 管理者が開発環境でスクリプトを使用できるようにしてください。

                  重要な設定ファイル

                  展開に関する詳細を参照する必要がある重要なファイルを次に示します。 このマニュアルに明記されているか、Cisco Technical Assistance Center(TAC)からの指示がないかぎり、プロパティ ファイルと、類似の設定ファイルはすべて読み取り専用だと見なしてください。 これらのプロパティ ファイルのいずれかを変更した場合は、サービスを再起動する必要があります。

                  ファイル

                  説明

                  newscale.properties

                  このファイルは、インストールまたはアップグレード プロセス中、およびインストーラが実行されるたびに、インストーラによって作成されます。 インストーラによってファイルが作成されると、「RequestCenter.war\WEB-INF\classes\config」フォルダに保存されます。 そのため、.ear ファイルが再展開されると、このファイルも再展開されます。 Service Catalog 管理者はファイルに含まれるデータを保持する必要があります。ただし、新しいバージョンではインストーラによって新たな情報が追加される場合があるため、ファイルのコピーを復元しないでください。 newscale.properties のエントリは次のとおりです。

                  • udk.datasource.jndi:RC データベースの JNDI 名
                  • udk.datamart.jndi:データ マート データベースの JNDI 名
                  • すべての登録済み EJB
                  • ObjectCache.Application.URL:送信された電子メール内のアプリケーションへの URL 参照
                  • ObjectCache.email.host:メール リレーの SMTP ホスト
                  • Container.Datasource:RequestCenter データベースの JNDI 名
                  • Scheduler.EscalationManagerSchedule:エスカレーション評価のスケジュール

                  rcjms.properties

                  このファイルもまた「RequestCenter.war\WEB-INF\classes\config」フォルダにあります。 これには、アプリケーション内部通信用の JMS 設定が含まれます。 キュー名がアプリケーション サーバ上のキュー名と一致することを確認してください。

                  integrationserver.properties

                  このファイルは「ISEE.war\WEB-INF\classes\config」フォルダにあります。 このファイルには、統合サーバ(Service Link)の重要なプロパティが含まれています。

                  ログの管理

                  Service Catalog はアプリケーション サーバのログ ファイルを保持し、アプリケーションの予期されたアクティビティと予期しないアクティビティをどちらも追跡します。 ログは、オープン ソース(Apache)のロギング メカニズムである log4j をベースとするフレームワークを使用して管理されます。 デフォルトで、ログは「ローリング アペンダー」に設定され、新しいログ ファイルが毎日開かれます。 アプリケーション サーバのタイプによってログ ファイルの内容と設定を調整する機能が異なるため、ログ ファイルの場所もアプリケーション サーバのタイプによって異なります。

                  次のことを推奨します。

                  • ログを毎日ローテーション(これはデフォルトの動作です)
                  • 1 か月分のログを「オンライン」で維持
                  • 企業で指定した保持期間よりも古くなったログをバックアップまたは削除

                  Service Catalog はログ ファイルを保持する必要がありません。 ログ ファイルは、主にエラーが発生した場合のトラブルシューティング ツールとして有用です。 ログ エントリには E(エラー)、W(警告)、I(情報)、D(デバッグ)の 4 種類があり、この順で重大度が低下します。

                  デフォルト ログ ファイルの形式は Cisco Technical Assistance Center(TAC)で想定する形式であるため、この形式を変更することは推奨しません。 その代わり、顧客は自分たちのニーズを満たす独自のアペンダーを作成できます。

                  Service Link はシステム全体のログ ファイルに加えて、アダプタ タイプごとに個別のログ ファイルを使用するように設定されています。 これらのログも log4j で管理されます。 Service Link のロギングはデフォルトで有効にされます。 アダプタ固有のログ ファイルは ServiceLink\logs ディレクトリに書き込まれます。

                  • dbadapter.log
                  • fileadapter.log
                  • httpadapter.log
                  • msadapter.log
                  • mqadapter.log
                  • remedyadapter.log
                  • vmwareadapter.log
                  • wslisteneradapter.log

                  すべてのログを記録する DEBUG レベルを有効にすると、ログのサイズが急激に大きくなります。このため、フル デバッグおよびトレース レベルのロギングを有効にするのは短期間にとどめる必要があります。 システムのパフォーマンスが大幅に低下する可能性があるため、本番システムでのロギングは最小限とし、問題を再現するために必要な期間のみとする必要があります。 詳細については、ログとプロパティを参照してください。

                  WebLogic のロギング

                  WebLogic では、Cisco Prime Service Catalog は WebLogic のロギング設定に基づいてメッセージをルーティングします。デフォルトでは、すべてが WebLogic サーバ ログにロギングされます。通常は次のようなパスにあります。

                  /apps/bea/user_projects/domains/cisco/servers/nsServer/logs/nsServer.log

                  デフォルトのログ レベルは INFO に設定されています。このレベルは WLS コンソール経由で調整可能です。

                  JBoss のロギング

                  JBoss ログは、"<JBOSS_DIR>/standalone/log" フォルダに配置されています。 ロギング動作を決定する logging.properties ファイルは、"<JBOSS_DIR>\standalone\configuration" フォルダに配置されています。 Log4j.xml は、現在はアプリケーションのロギングの制御には使用されていません。

                  データ ソースの設定

                  すべてのモジュールは、JNDI(Java Naming and Directory Interface)経由で定義された J2EE データ ソースを利用します。 これらのデータ ソースは正しいデータベースを指し、適切なログイン情報が設定されている必要があります。

                  次の場合には、追加の JNDI データ ソースが必要です。

                  • 外部ディクショナリが使用される。
                  • データ取得ルールから、または SQL ステートメントかリレーショナル データベース テーブルに基づくサービス定義のオプション リストから、カスタマー固有のデータ ソースにアクセスする。

                  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)] フィールドに次のデータを入力します。
                    • Select 1(SQL サーバの場合)
                    • Select 1 from dual;(Oracle サーバの場合)
                    (注)     

                    SQL の断続的な切断を防ぐため、データ ソースを設定する際に、[有効な接続チェッカー(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 とします。

                    補助テーブルを作成する SQL リストの例

                    次のコードにより、各行に一意の 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;

                    SSL または NTLM 経由でのサービス エクスポートの設定

                    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 という名前のファイルです。
                      • JBoss の場合、cacerts は <JAVA_HOME>\jre\lib\security にあります。 .

                      ステップ 3   Service Catalog Web サーバの信頼できるルート CA 証明書を Java の cacerts キーストアにインポートします。 Java の keytool ユーティリティも使用できます。
                      • keytool.exe プログラムは <JAVA_HOME>/bin ディレクトリにあります。

                      次に、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)] をクリックします。 これでキャッシュが無効になり、そのページの設定がリロードされます。

                      Business Engine のキャッシング

                      Cisco Prime Service Catalog には、Business Engine と呼ばれる独自のワークフロー管理システムが組み込まれています。 Business Engine のアクション(提供計画の管理)は、アプリケーション サーバで発生するため、アプリケーション ユーザはほとんど意識する必要がありません。 ただし、システム管理者には、Business Engine の処理を確認および場合によっては調整するためのユーザ インターフェイスが提供されます。

                      Site Administrator システム ロールを持っているユーザは、URL の http://<serverName:portNumber>/RequestCenter/businessengine/index.jsp を経由して Business Engine コンソールにアクセスできます。このコンソールの機能は次のとおりです。

                      • Business Engine 設定の表示
                      • オブジェクト キャッシュの削除
                      • Escalation Manager の強制実行
                      • トランザクション キャッシュ ログの表示

                      このアプリケーションには、他のキャッシング メカニズムもあります。 キャッシュされた値は、アプリケーション データが変更されると自動的にリフレッシュされます。

                      Prime Service Catalog データベースの保護

                      SSO 経由の外部認証が使用される場合、一般的にユーザ パスワードはデータベースに保存されません。 保存される場合は、一方向の AES 128 ビット ハッシュとなります。 設定ファイルまたはデータベースに保存されたパスワードは、公開/秘密キー暗号化によって暗号化されます。 追加の暗号化はデータには適用されません。

                      コンフィギュレーション ファイル内のローカル アプリケーションのパスワードは暗号化されます。 Service Link が設定されていると、J2EE コンテナのパスワードは暗号化されずに、いくつかの設定ファイルにプレーン テキストとして保存されます。

                      URL は符号化されません。データレベルのセキュリティにより、各画面の承認が確認されます。

                      アプリケーションの保護

                      ここでは、アプリケーション セキュリティについて説明します。

                      • LDAP サーバからの SSL 証明書の取得。
                      • LDAP サーバが SLDAP 接続をサポートすることの確認(通常はポート 636)。

                      Service Catalog は、多数の証明書を保存できるキーストアをパスワードで保護して保持します。

                      Web サーバ、または Web サーバの前にあるコンテンツ スイッチでは SSL を実行することが推奨されます(特にエクストラネットをサポートする環境の場合)。

                      通常、Web サーバからアプリケーション サーバへの通信を暗号化する必要はありません。

                      Advanced Reporting での CGI サポートの削除

                      いくつかのツールでは、アプリケーションをスキャンして、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)をサポートするには、次のスクリプトが必須です。

                      表 6 標準レポートのサポート

                      プログラム

                      説明/使用方法

                      update_datamart_std.cmd

                      Data Manager で指定した ETL ルールに従って、作成済みレポートをサポートするデータベース テーブルにデータを入力します。 これは、データベース コンテンツの差分リフレッシュではなく完全な再ビルドです。 <cognos.root >\c8 \datamanager \log にログ ファイルが作成されます。

                      データ マートをサポートするには、次のプログラムが必須です。

                      表 7 データ マートのサポート

                      プログラム

                      説明/使用方法

                      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 を使用したタスクのモニタリング

                      Escalation Manager は、タスクがその運用レベル契約(OLA)を超過したかどうかをモニタリングします。 OLA を超過した場合、エスカレーションが設定されていれば、Escalation Manager はタスクが超過となってから、指定された時間が経過した後に適切な通知を送信します。

                      Escalation Manager は内部スケジューラ経由で実行されます。 スケジュールの設定は、newscale.properties ファイルを編集して調整できます。 デフォルトでは、Escalation Manager は月曜から金曜までの営業時間中に実行されるよう設定されています。

                      スケジュール設定は基本的に cron 式であり、必要なスケジュールを「秒 分 時 日 月 曜日」の形式で記述します。 たとえば、"0 0 12 ? * WED" という式は、「毎週水曜日の午後 12 時 00 分」を意味します。

                      Service Manager を使用したサービス要求の履行

                      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 フォルダに保存されます。

                      主なインストール ログを次に示します。

                      表 8 インストール ログ ファイル

                      ファイル名

                      目次

                      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 と通信できるかどうかチェックするテストを実行できます。

                      1. 有効な未使用のマルチキャスト アドレスおよびポートを選択します。
                      2. Node2:java -classpath .:./javagroups-all.jar org.javagroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555
                      3. Node1:java -classpath .:./javagroups-all.jar org.javagroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555
                      4. Node1 にプロンプト「>」が表示されます。
                      5. 何かテキストを入力して、Enter キーを押します。
                      6. 入力したテキストが 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 ルックアップをトリガー可能なイベントには次のようなものがあります。

                      • ログイン後の認証(Service Catalog 画面経由またはシングル サインオン経由)
                      • 代理オーダーの個人検索
                      • 個人タイプ フィールド内のフォーム データの個人検索
                      • 代理オーダーまたは個人検索経由で事前選択された人物の上司に関する個人情報の検索

                      ディレクトリ統合では、事前に設定されたこれらのイベントと動作に加えて、プログラマがカスタム ディレクトリ インターフェイスを実装して新しい検索機能の追加や検索ロジックの改良ができる API を提供します。

                      ディレクトリ マッピング

                      ディレクトリ データは次のような人員のプロファイルの要素にマッピングできます。

                      • 基本および拡張個人属性(場所と連絡先情報を含む)
                      • 1 つ以上の組織
                      • 1 つ以上のグループ
                      • 1 つ以上のロール

                      4 種類のマッピングを使用できます。

                      • 単純マッピング。 ディレクトリ属性と個人フィールド間の 1 対 1 のマッピング。
                      • 複合マッピング。 2 つ以上のディレクトリ属性を使用して、個人フィールドの値を取得します。
                      • 表現マッピング。 1 つまたは複数のディレクトリ属性に関連する正規表現を使用して、個人フィールドの値を条件付きで取得します。
                      • Directory Integration API による Java クラス経由のマッピング。 現在の個人の現在のディレクトリ データ ソースで使用できるディレクトリ属性に基づいて、Java プラグインで個人フィールドの値を取得します。

                      ロケールおよびタイム ゾーンがマッピングされていない場合は、Service Catalog がサーバ デフォルトを使用します。 また、オプション フィールドがマッピングされていない場合は、個人プロファイルで過去に生成された値がそのまま残ります。

                      カスタム マッピング

                      カスタム マッピングは、『Cisco Prime Service Catalog Integration Guide』に記載されているパターン マッチング言語(正規表現)経由と Directory Integration API で提供されるインターフェイスに基づくカスタム プラグイン クラス経由で作成できます。

                      このようなマッピングはすべて、実装ごとに LDAP 統合ドキュメント内で文書化する必要があります。 Service Catalog インスタンスが移行またはアップグレードされた場合、マッピングに必要な Java クラスはすべてカスタマイゼーションとして扱われます。

                      カスタム コード

                      Directory Integration API で提供されるインターフェイスを使用すると、ディレクトリ統合イベントによって提供される事前設定の動作をカスタム Java クラスが置き換えまたは補完できます。 インスタンスが移行またはアップグレードされた場合、このようなクラスはカスタマイゼーションとして扱われます。

                      さらに、カスタム クラスが JAR ファイルのサポートを必要とする場合は、これらをアプリケーション サーバにインストールし、カスタマイズとして扱う必要があります。 インストールの手順はアプリケーション サーバごとに異なります。

                      シングル サインオンのトラブルシューティング

                      シングル サインオン機能は、ディレクトリ統合の一部として提供されます。 シングル サインオンに問題が発生した場合は、次の項目をチェックしてトラブルシューティングを開始します。

                      • LDAP または Junction/SiteMinder エージェントの設定など、環境に関連する変更を確認します。
                      • Service Catalog が管理目的でのオーバーライドでもアクセス可能かどうかを確認します。
                      • Service Catalog サービスを再起動します。
                      シングル サインオン:NTLM の設定

                      多くの環境で Windows 認証を使用しています。 IIS は統合 Windows 認証(IWA)をサポートし、ログインしたユーザの DOMAIN\UserName をパラメータとして渡します。

                      要件
                      • IWA を有効化した後に(Windows サービスで)IIS Admin サービスを再起動する。
                      • Service Catalog にアクセスするときの有効なドメイン アカウント。
                      • DOMAIN 情報を除去する SSO の設定

                      対話型サービス フォーム(ISF)

                      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 を使用した外部システムとの統合

                      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 の展開
                      • インストール時に選択した設定に基づく .properties ファイルの変更
                      • カスタマイゼーション ファイル内のマージ(インストール パラメータの一部として指定されている場合)
                      • WAR の再圧縮
                      • 宛先またはフォルダへの 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 インストール ウィザードがインストールを完了する間、アプリケーションの展開ディレクトリ構造にカスタム コンテンツのアーカイブが抽出されます。


                        実装全体のカスタム ファイル

                        カスタマイズされたファイルはすべてカスタマイゼーション アーカイブに含まれている必要があります。 実装内のすべてのサイトで、次のようなカスタマイズされたファイルが必要な場合があります。

                        表 9 カスタム コンポーネント

                        カスタマイズ可能なコンポーネント

                        ディレクトリ/ファイル

                        カスタム スタイル シート、ヘッダー、フッター

                        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 スクリプトがカスタマー サポートから提供される場合があります。 ホットフィックスは、次の製品リリースに追加されるまではカスタマイゼーションとして扱い、ソフトウェア アップグレードまたは再インストールに含める必要があります。

                        Catalog Deployer を使用した設定の管理

                        通常、Service Catalog 実装は複数のサイトで構成され、それぞれのサイトが異なる役割を果たします。

                        表 10 複数のサイト

                        サイト

                        使用方法

                        開発

                        サービス定義が開発され、単体テストが行われます。カスタマイゼーションが最初に適用されます。

                        テスト

                        開発アクティビティから干渉されることのない、制御された環境。ここでは、品質保証または他の担当者が 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   ターゲット データベースにデータをインポートします。
                            (注)      SQLServer の場合は、新たにインポートされるデータベースに存在するログインおよびユーザが、Service Catalog のこのインスタンスに必要な資格情報と一致することを確認します。 必要に応じて新しいログインを作成したり、既存のログインをデータベース所有者に関連付けたりして、このユーザが適切な権限を持つようにします。 Oracle の場合は、新しくインポートされるデータベースに適切なユーザが存在し、Service Catalog のインストーラで指定されたように特権が付与されていることを確認します。
                            ステップ 5   両サイトが 2 つの異なる Cognos レポート サーバにアクセスしている場合は、各サイトの「CognosServer」の名前を指定する CnfParams テーブルのエントリを更新して、更新内容をコミットします。
                            ステップ 6   ターゲット環境の Service Catalog と Service Link のサービスを再起動します。
                            ステップ 7   [管理(Administration)] > [Entity Homes] > [SiteProtectionこのサイト(SiteProtection This Site Is)] プロパティを現在のサイトに設定します。 [Entity Homes] の指定が異なる場合、またはサイトの保護レベルが異なる場合は手動で変更を行い、変更を保存します。
                            ステップ 8   両サイトが 2 つの異なる LDAP ディレクトリに接続している場合は、ディレクトリ統合のデータ ソース定義を適宜変更します。
                            ステップ 9   Service Link エージェントの接続プロパティをすべてチェックし、ターゲット環境に合わせて変更します。
                            ステップ 10   手作業での追加処理がある場合はそれを実行し、データを調整します。 たとえば、一部のユーザ、グループ、または組織に権限を追加したり、権限を取り消したりする場合があります。
                            ステップ 11   メンテナンスが完了したことをユーザに通知します。

                            Service Link 受信ドキュメントの SSL の設定

                            ここでは、サービス リンクの SSL の設定について説明します。

                            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 の 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 を設定する手順について説明します。

                            JBoss 7.1.1 の場合

                              ステップ 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>

                              (注)      上記のエントリでは、キーストア ファイル名は「slkeystore.jks」、証明書のエイリアスは「servicelink」、キーストア ファイルを開くパスワードは「slpassword」であると仮定しています。

                              ファイル「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=
                              
                              (注)      Service Catalog アプリケーションは、この URL を介して Service Link アプリケーションと通信します。 この Service Link の URL が SSL 対応になったため、アドレスを https アドレスに変更する必要があります。また、ポート番号は Service Link 用に JBoss サーバによって使用されるセキュア ポート番号に変更する必要があります。
                              ステップ 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
                              
                              (注)      上記のエントリでは、「slsigner.cer」は CA ルート証明書を含むファイルの名前、「servicelink」はエイリアス、「cacerts」は JDK 6 の信頼できるキーストア ファイルの名前、「changeit」はキーストア ファイル「cacerts」を開くパスワードであると仮定しています。
                              ステップ 12   ServiceCatalogServer と ServiceLinkServers の両方を起動し、管理者ユーザとして、または Service Link モジュールにアクセスできるユーザーとして Service Catalog URL に接続します。
                              ステップ 13   Service Link のホームページを開き、「Service Link Status」のセクションで、接続が緑色のステータスであり、SSL アイコンとセキュア ポート番号の両方が表示されていることを確認します。
                              ステップ 14   HTTP/WS アダプタを使用する Service Link エージェントに受信ドキュメントを送信する外部システムは、すべて次のように更新する必要があります:
                              1. 受信ルーティング URL では、https アドレスおよびセキュア ポート番号を使用する必要があります。
                              2. Service Link の署名者証明書(ファイル slsigner.cer に含まれる)は、外部システムの信頼できる CA ルート証明書キーストアにインポートする必要があります。

                              WebLogic 10.3.6 の場合

                              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:\Program Files\Java\jdk1.7.0\

                                ステップ 2   WebLogic 管理コンソールにログインし、[<ドメイン>] > [環境(Environment)] > [サーバ(Servers)] に移動します。
                                ステップ 3   Service Link の WebLogic サーバの名前をクリックし、設定を開きます。それから [設定(Configuration)] >[キーストア(Keystores)] サブタブをクリックします。
                                ステップ 4   [キーストア(Keystores)] ページで次の値を入力します。

                                (注)      <JAVA_HOME> を Java ディレクトリのフル パス名で置き換えます。 (読み取り専用フィールドの場合、表示される値が正しいことを確認します)。
                                表 11 キーストア フィールド

                                フィールド

                                キーストア(Keystores)

                                カスタム ID および Java 標準トラスト

                                カスタムIDキーストア(Custom Identity Keystore)

                                <JAVA_HOME>\lib\security\slkeystore

                                カスタムIDキーストアタイプ(Custom Identity Keystore Type)

                                jks

                                カスタムIDキーストアパスフレーズ(Custom Identity Keystore Passphrase)

                                slpassword

                                カスタムIDキーストアパスフレーズの確認(Confirm Custom Identity Keystore Passphrase)

                                slpassword

                                Java標準トラストキーストア(Java Standard Trust Keystore)

                                <JAVA_HOME>\lib\security\cacerts

                                Java標準トラストキーストアタイプ(Java Standard Trust Keystore Type)

                                jks

                                Java標準トラストキーストアパスフレーズ(Java Standard Trust Keystore Passphrase)

                                changeit

                                Java標準トラストキーストアパスフレーズの確認(Confirm Java Standard Trust Keystore Passphrase)

                                changeit

                                [Java標準トラストキーストアパスフレーズ(Java Standard Trust Keystore Passphrase)] については、「cacerts」キーストア ファイルのパスワードがまだデフォルト値の「changeit」であると仮定しています。 使用する環境で「cacerts」のパスワードが変更されている場合は、それを適切な値に置き換えてください。

                                ステップ 5   [保存(Save)] をクリックしてから、[設定(Configuration)] > [SSL] サブタブをクリックします。
                                ステップ 6   [SSL] ページで次の値を入力します。
                                表 12 SSL フィールド

                                フィールド

                                IDとトラストの場所(Identity and Trust Locations)

                                キーストア(Keystores)

                                公開キーエイリアス(Private Key Alias)

                                servicelink

                                公開キーパスフレーズ(Private Key Passphrase)

                                slpassword

                                公開キーパスフレーズの確認(Confirm Private Key Passphrase)

                                slpassword

                                ステップ 7   [保存(Save)] をクリックしてから、[設定(Configuration)] > [一般(General)] サブタブをクリックします。
                                ステップ 8   [一般(General)] ページで次の値を入力します。
                                • [SSLリスニングポートの有効化(SSL Listen Port Enabled)] チェックボックスをオンにします。

                                • [SSLリスニングポート(SSL Listen Port)] = <9443 など、使用できるポート番号を入力>

                                ステップ 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 つに過ぎません。
                                1. コマンド プロンプト ウィンドウで次のコマンドを実行します。

                                  例:
                                  cd <JAVA_HOME>\jre\lib\security
                                  <JAVA_HOME>\bin\keytool -export -rfc -file slsigner.cer -alias servicelink -keystore slkeystore.jks -storepass slpassword
                                  
                                2. 「slsigner.cer」ファイルが有効であることを確認するには、次のコマンドを実行します。

                                  例:
                                  <JAVA_HOME>\bin\keytool –printcert –file slsigner.cer
                                  
                                ステップ 12   Service Link サービスの非セキュア ポートを無効にする場合は、Service Link サービスと通信する外部システムを管理するシステム管理者に「slsigner.cer」ファイルを送信します。 その外部システムでは、2 つの設定を行う必要があります。
                                1. Service Link URL は、セキュア ポート番号と共に http から https アドレスに変更する必要があります。 たとえば、変更前は次のような Service Link URL であるとします。

                                  例:
                                  http://<sl_servername>:9001/IntegrationServer/ishttplistener/ <agent_name>
                                  

                                  これを次のように変更する必要があります。



                                  例:
                                  https
                                  ://<sl_servername>:9443
                                  /IntegrationServer/ishttplistener/<agent_name>
                                  
                                2. Service Link サービスとの SSL 接続時に信頼できるハンドシェイクを確立できるように、servicelink 証明書の署名者証明書(つまり、「slsigner.cer」ファイルの内容)を外部システムの信頼できる Java 認証局キーストアにインポートする必要があります。

                                クラスタ化された WebLogic 環境の場合

                                  ステップ 1   Service Link サービスの非セキュア ポートを無効にするには、Service Catalog サービスの信頼できる Java 認証局キーストアに署名者証明書をインポートする必要があります。

                                  これは、クラスタに属していない、独立した WebLogic サーバで Service Link が動作するためです (Service Catalog および Business Engine のみ、クラスタにインストールできます)。Service Catalog は、実行時に Service Link サービスに接続する「クライアント」として機能します。

                                  ステップ 2   Service Catalog の信頼できる Java CA キーストアに署名者証明書をインポートするには、次の手順を実行します。
                                  1. Service Catalog アプリケーションが動作している WebLogic クラスタ ノードのいずれかにログインします。
                                  2. 「<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」を検索します)。 次に例を示します。



                                    例:
                                    set JAVA_HOME=C:\jdk170
                                    
                                  3. 「<JAVA_HOME>\jre\lib\security」ディレクトリに「slsigner.cert」ファイルをコピーします。
                                  4. コマンド プロンプト ウィンドウで次のコマンドを実行して、署名者証明書を「cacerts」キーストアにインポートします。

                                    例:
                                    cd <JAVA_HOME>\jre\lib\security
                                    <JAVA_HOME>\bin\keytool -import -trustcacerts -alias servicelink –noprompt -file slsigner.cer -keystore cacerts -storepass changeit
                                    

                                    上記のコマンドでは、「cacerts」キーストア ファイルのパスワードはまだデフォルト値の「changeit」です。 使用する環境で「cacerts」のパスワードが変更されている場合は、それを適切な値に置き換えてください。

                                  5. Service Catalog が展開されている WebLogic クラスタのすべてのノードの「<JAVA_HOME>\jre\lib\security」ディレクトリに、前のステップで更新した「cacerts」ファイルをコピーします。 たとえば、WebLogic クラスタに 3 つのノードが含まれており、各ノードが別のマシンである場合は、このマシンから「cacerts」ファイルを他の 2 つのマシンにコピーします。
                                  6. 「<BEA_HOME>\user_projects\domains\<domain_name>\servers\<servername>\stage\RequestCenter\config」ディレクトリの下にある「newscale.properties」ファイルを次のように変更します。

                                    次のパラメータを検索します。



                                    例:
                                    isee.base.url=http://<hostname>:9001
                                    

                                    これを次のように変更します。



                                    例:
                                    isee.base.url=https
                                    ://<hostname>:9443
                                    
                                  7. Service Catalog が展開されている WebLogic クラスタのノードごとにステップ(f)を繰り返します。
                                  8. Service Catalog の WebLogic クラスタを再起動します。

                                    ステップ 1 を実行しないようにするために、Service Link サービスの非セキュア ポートおよびセキュア ポートをどちらもオンにする場合があります。 この方法では、Service Catalog アプリケーションは非セキュアな URL (http://<hostname>:9001)を使用しても Service Link に接続できますが、すべての外部システムからの非セキュア ポートへのアクセスをブロックする手段(ファイアウォール システムなど)を検討することをお勧めします。


                                  Service Link 送信ドキュメントの SSL の設定

                                  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 ハンドシェイク時にクライアント証明書認証をサポートしません。

                                  以降の項で、設定手順について詳しく説明します。

                                  SSL の発信 URL の指定


                                    ステップ 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)] タブを開いてエージェントを再起動します。

                                    信頼できる CA キーストアへの署名者証明書のインポート

                                    アプリケーション サーバ固有の手順を実行する前に、次の手順を実行する必要があります。


                                    (注)  


                                    外部 Web サーバ証明書の署名者が VeriSign や Thawte などの既知の認証局の場合は、Sun JDK で認識されている可能性が高いため、この手順を省略することができます。
                                    • 外部 Web サーバの署名者証明書をファイルで取得します。 これを行うには、外部 Web サーバを管理するシステム管理者に連絡し、その Web サーバのセキュリティ保護に使用するデジタル証明書の署名者証明書(公開キー)をエクスポートするよう依頼します。 署名者証明書は、「Base64 エンコード ASCII」形式でエクスポートする必要があります。 次に、Base64 エンコード署名者証明書の例を示します。
                                    -----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))によって異なります。

                                    JBoss 7.1.1 の設定

                                    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
                                      

                                      (注)      上記の「keytool」コマンドでは、「cacerts」キーストア ファイルのパスワードがまだデフォルト値の「changeit」であると仮定しています。 使用している環境で、パスワードを正しい値に置き換えます。 –alias パラメータについては、値「extws」を、この署名者証明書に使用する適切なエイリアスに置き換えることができます。 複数の署名者証明書をインポートする場合は、署名者証明書ごとに一意のエイリアス名を割り当てる必要があります。

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

                                      WebLogic 10.3.6(11g)の設定

                                      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
                                        

                                        (注)      上記の「keytool」コマンドでは、「cacerts」キーストア ファイルのパスワードがまだデフォルト値の「changeit」であると仮定しています。 使用している環境で、パスワードを正しい値に置き換えます。 –alias パラメータについては、値「extws」を、この署名者証明書に使用する適切なエイリアスに置き換えることができます。 複数の署名者証明書をインポートする場合は、署名者証明書ごとに一意のエイリアス名を割り当てる必要があります。

                                        ステップ 4   Service Link が展開されている WebLogic サーバを再起動します。

                                        トラブルシューティング(Troubleshooting)

                                        ここでは、送信電子メールを制限する方法、および電子メールの生成を制御する方法について説明します。 また、サポートに関するご質問や、システム環境およびエラー情報の追跡方法についてシスコに連絡する場合の情報も記載しています。

                                        アプリケーションのプロビジョニング プロセスの追跡およびトラブルシューティング

                                        アプリケーション テンプレートをオーダーすると、オーケストレーション コンポーネントにより、[マイスタッフ(My Stuff)] の [コメントと履歴(Comments and History)] にテンプレート プロビジョニングの進行状況をトラッキングするためのオプションが表示されます。

                                        (組み込みの)クラウド オーケストレーション サービスは、Prime Service Catalog の実行中に再起動されると、Prime Service Catalog に再接続し、AMQP のエクスチェンジを検出し、AMQP メッセージのモニタリングを再開します。

                                        一方、Prime Service Catalog がクラウド オーケストレーション サービスの実行中に再起動されると、クラウド オーケストレーション サービスは Prime Service Catalog が実行を再開したときに再接続します。

                                        (アプリケーション テンプレートの)オーダーが送信されると、クラウド オーケストレーション エンジン(Heat エンジン)がアプリケーション テンプレートのプロビジョニングを開始する前に、このエンジンのステータスがチェックされます。

                                        クラウド オーケストレーション エンジンまたはクラウド オーケストレーション エンジン API サービスが停止している場合、クラウド オーケストレーション サービスは Prime Service Catalog における要求をキャンセルし、その要求について [コメント(Comments)] に次のログを書き込みます:Heatエンジンサービスが停止しています。詳細:<サービスステータスの詳細>(Heat Engine service is down. Details: <More information on the service status>)

                                        (注)  


                                        クラウド オーケストレーション エンジンはフォールト トレラントではありません。インフラストラクチャ テンプレートのプロビジョニング中にエンジンが停止すると、プロビジョニングは中断され、後でエンジンが再起動されても復旧できません。


                                        クラウド オーケストレーション エンジンとオーケストレーション サービスの再起動

                                        [Shelladmin] メニューからのルートへのアクセスを有効にし、ルートとしてログインし([Shelladmin] メニューのオプションを使用)、次のコマンドを実行し、ログ ファイルなどを表示します。 (もしくは [サービスステータスを表示(Display Service Status)] オプションを使用することで、次のサービスを含むすべてのサービスのステータスを表示できます)
                                        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 
                                        

                                        ログ ファイル

                                        [管理(Administration)] > [ユーティリティ(Utilities)] > [ログとプロパティ(Logs and Properties)] で [Request Center - ログ ファイル(Request Center - Log Files)] を選択すると、オーケストレーション サービスと Heat エンジンのログを確認できます。
                                        • オーケストレーション ログは /var/log/cisco/psc/psc-orchestration.log にあります

                                        • クラウド オーケストレーション(Heat)エンジンのログは /var/log/heat/engine.log にあります

                                        一般的にモニタリングされるトレース

                                        次のトレースが一般的にモニタリングされます。

                                        データベースの相互作用

                                        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)へのお問い合わせ

                                        以下に影響する可能性のあるシステム メンテナンス作業を実施する前に、Cisco Technical Assistance Center(TAC)に連絡することができます。

                                        • サーバ オペレーティング システムのパッチおよびアップグレード
                                        • データベース サーバのパッチおよびアップグレード
                                        • Service Catalog アプリケーション サーバのパッチおよびアップグレード:更新がシスコでサポートされていることを最初に確認してください。
                                        • LDAP ディレクトリ ツリー構造の変更
                                        • シングル サインオン システムのアップグレード
                                        トラブルシューティング情報の収集

                                        ここでは、さまざまな状況でトラブルシューティング情報を収集する方法について説明します。

                                        サイトのデバッグ

                                        「Our Apologies」例外が発生した場合、Administration モジュールの [設定(Settings)] の [デバッグ(Debugging)] オプションでサイトの「デバッグ」をオンにすることができます。

                                        図 1. [デバッグ(Debugging)] ページ

                                        [デバッグ(Debugging)] により、現在のページの URL がページ下部に追加されます。 URL をクリックすると、シスコのサポート担当者にとって有用な追加情報のリンクが表示されます。

                                        図 2. 下部の URL

                                        終了したら、エンド ユーザを混乱させないよう、デバッグをオフにします。 また、パフォーマンスに悪影響を与える可能性もあります。

                                        アプリケーション ログは、トラブルシューティングを行うための重要なメカニズムです。 このログで「例外」(ボトムアップ方式)を調べることにより、該当するエラー メッセージが見つかることがあります。

                                        クラスタ化された環境では、クラスタ内のすべてのマシンで対象期間内のログ ファイルを参照すると効果的です。

                                        Service Link のログ ファイル

                                        Service Link サーバのログには、その日のすべての Service Link トランザクションの詳細が表示されます。 Business Engine と Service Link 間のインタラクションに関係する問題をトラブルシューティングする場合は、このファイルと Service Catalog サーバ ログを相互に関連付けると有用です。

                                        Performance

                                        ログおよび native_stderr.log ファイルからパフォーマンス情報を収集します。

                                        サービス設計およびプラットフォームの依存性

                                        サービス設計時に発生する問題は、誤ったサービス設定に関係していることがあります。 本番環境でのみ発生する問題は、データまたはプラットフォームに依存していることがあります。

                                        Cisco Technical Assistance Center(TAC)から、データベースのダンプを送信するよう依頼されることがあります。このダンプをテスト ラボでインストールすることにより、エラーが発生した環境を正確にエミュレートできます。 顧客には、データベースをシスコ サポート サイトにアップロードして調査できるようにするためのログインおよび資格情報が必要です。

                                        Cisco Technical Assistance Center(TAC)に連絡してください。

                                        • 解決策について
                                          • ドキュメント ライブラリへのアクセスを取得する
                                          • アップグレードおよびパッチを確認する
                                          • 一般的な問題に対する回答を確認する
                                        • ケースについて
                                          • 新しいケースを記録する
                                          • ケースのステータスを確認する
                                          • ケースの調査に関するコメントを確認および更新する
                                          • ログおよびファイルを添付する

                                        ServiceLink アプリケーションのアダプタ ログ ファイルの有効化

                                        WebLogic では、ServiceLink アダプタのログ ファイルがデフォルトで有効にされません。 デフォルトでは、ServiceLink アダプタのすべてのロギングが WebLogic サーバの server.log ファイルに書き込まれます。

                                        ここでは、ServiceLink のアダプタ ログ ファイルを有効にする設定手順について説明します。 この設定手順は、ユーザが ServiceLink WAR の展開後に手動で行う必要があります。


                                        (注)  


                                        この項は、Service Catalog Installer がインストール時に自動的に ServiceLink アダプタ ログ ファイルを設定する JBoss には適用されません。
                                        WebLogic 11g の場合

                                          ステップ 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」を変更します。
                                          1. 「logger.class.name=com.newscale.bfw.logging.LogUtilCommonsImpl」の行がコメントアウトされていないことを確認します。
                                          2. 「logger.directory=」の前のコメント記号を削除し、ServiceLink アプリケーションが展開されている WebLogic サーバの正しいログ ディレクトリを入力します。 これは WebLogic サーバの「server.log」が存在するディレクトリである必要があります。 次に例を示します。

                                          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

                                          (注)      Windows では、ディレクトリの区切り文字としてバックスラッシュ(\)ではなく、スラッシュを使用します。
                                          ステップ 5   WebLogic サーバを起動します。

                                          「server1.log」と同じディレクトリに、「isee.log」という新しいログ ファイルといくつかの追加のログ ファイル(ServiceLink アダプタごとに 1 ファイル)が存在しています。


                                          Errors

                                          ここでは、重大なエラー状態に関する情報を記載しています。 この情報は、個別のエラー メッセージに基づいて示されており、状態ごとに次の情報を示します。

                                          • エラー状態
                                          • エラー メッセージ
                                          • 考えられる原因
                                          • エラー ログの場所
                                          • 推奨される解決策

                                          ログの管理も参照してください。

                                          エラー ログの場所

                                          Service Catalog および関連コンポーネントのエラー ログは、次の場所にあります。

                                          表 13 エラー ログのパス

                                          コンポーネント

                                          エラー ログの場所

                                          アプリケーション サーバ(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 サーバ ログ ファイルに書き込まれます。このファイルの動作と場所については、上記の説明を参照してください。

                                          非同期送信/承認を実行できない
                                          表 14 送信/承認エラー

                                          カテゴリ

                                          説明

                                          エラー状態

                                          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 キューが、メッセージを受信するために使用可能かどうかを確認します。

                                          アプリケーション サーバでデータベースへの接続が失われる
                                          表 15 接続損失エラー

                                          カテゴリ

                                          説明

                                          エラー状態

                                          アプリケーション サーバでデータベースへの接続が失われました。

                                          エラー メッセージ

                                          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 データベースが実行されていない場合は、起動します。 このデータベースが起動すると、アプリケーション サーバが自動的に接続されます。

                                          LDAP サーバに接続できない - 不正なポート
                                          表 16 

                                          カテゴリ(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 アプリケーションを再起動する必要はありません。

                                          LDAP サーバに接続できない - 不正なホスト名
                                          表 17 

                                          カテゴリ(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 の値が正しいことを確認します。

                                          LDAP サーバに接続できない - LDAPException 32
                                          表 18 

                                          カテゴリ(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 の値が正しいことを確認します。

                                          LDAP サーバに接続できない - LDAPException 49
                                          表 19 

                                          カテゴリ(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 サーバに接続できない
                                          表 20 

                                          カテゴリ

                                          説明

                                          エラー状態

                                          LDAP サーバに接続できません。

                                          エラー メッセージ

                                          FATAL [LDAPBase] LDAP instance cannot be created netscape.ldap.LDAPException: no host for connection (89)

                                          解像度

                                          LDAP サーバが実行されているかどうかを確認します。 実行されていない場合は、LDAP サーバを起動します。

                                          Service Catalog アプリケーション サーバを再起動する必要はありません。

                                          LDAP サーバに接続できない
                                          表 21 

                                          カテゴリ

                                          説明

                                          エラー状態

                                          LDAP サーバに接続できません。

                                          エラー メッセージ

                                          ERROR [com.newscale.bfw.ldap.LDAPQuery] LDAP netscape.ldap.LDAPException: failed to connect to server ldap://<hostname>:<port> (91)

                                          解像度

                                          LDAP サーバが実行されているかどうかを確認します。 実行されていない場合は、LDAP サーバを起動します。

                                          Service Catalog アプリケーション サーバを再起動する必要はありません。

                                          LDAP サーバで認証できない
                                          表 22 

                                          カテゴリ(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)] を確認します。

                                          次のパラメータを確認して、必要に応じて修正します。
                                          • BindDN

                                          • [パスワード(Password)]

                                          • User BaseDN

                                          Service Catalog アプリケーション サーバを再起動する必要はありません。

                                          属性名のマッピングに誤りがある
                                          表 23 

                                          カテゴリ

                                          説明

                                          エラー状態

                                          いずれかの必須属性のマッピングに誤りがあります。 そのため、LDAP サーバで個人を検索できません。

                                          エラー メッセージ

                                          ERROR [com.newscale.bfw.ldap.LDAPQuery] LDAP java.lang.RuntimeException: Required LDAP attribute <attribute_name> is missing from the LDAP system.

                                          解像度

                                          ディレクトリ データ マッピング内の属性名を修正します。 Service Catalog アプリケーション サーバを再起動する必要はありません。

                                          LDAP サーバでユーザのベース DN が欠落している
                                          表 24 

                                          カテゴリ

                                          説明

                                          エラー コード(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)] の値が正しいことを確認します。

                                          SSL モードで LDAP サーバに接続できない
                                          表 25 

                                          カテゴリ(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 システムに適切なサーバ証明書を追加します。

                                          SSL モードで LDAP サーバに接続できない
                                          表 26 

                                          カテゴリ(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 システムに追加します。

                                          [新しいユーザの共通OU(Common OU for new users)] の設定値が欠落している
                                          表 27 

                                          カテゴリ(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)] フィールドに正しい値を選択します。

                                          LDAP サーバでユーザが見つからない
                                          表 28 

                                          カテゴリ

                                          説明

                                          エラー状態

                                          <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 システムに接続できない
                                          表 29 

                                          カテゴリ

                                          説明

                                          エラー状態

                                          いずれかの参照 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 システムの認証と接続を確認します。

                                          外部データ ディクショナリ データベースに接続できない
                                          表 30 

                                          カテゴリ

                                          説明

                                          エラー状態

                                          外部データ ディクショナリ データベースに接続できません。

                                          エラー メッセージ

                                          ERROR [STDERR] SQLException while attempting to connect: java.sql.SQLException: [Macromedia][SQLServer JDBC Driver]Error establishing socket. Connection refused: connect.

                                          解像度

                                          外部データ ディクショナリ データベースを確認します。 外部データ ディクショナリ データベースが実行されていない場合は、起動します。

                                          Service Catalog アプリケーションを再起動する必要はありません。

                                          データベースへの接続が失われた
                                          表 31 

                                          カテゴリ

                                          説明

                                          エラー状態

                                          データベースへの接続が失われました。

                                          エラー メッセージ

                                          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)

                                          解像度

                                          データベースを確認します。 データベースが実行されていない場合は起動します。 このデータベースが起動すると、アプリケーション サーバが自動的に接続されます。

                                          外部データ ディクショナリ データベースに接続できない
                                          表 32 

                                          カテゴリ

                                          説明

                                          エラー状態

                                          外部データ ディクショナリ データベースに接続できません。

                                          エラー メッセージ

                                          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)の標準処理では、サイトがオンラインになった時点で、実装されたサイトごとにこのマトリクスの列を完成させます。 通常、シスコの拡張サービスの成果物には、このマトリクスのソフト コピーが含まれており、管理者はそれを最新に保つ必要があります。

                                          表 33 クライアント サービス カタログの構成

                                          カテゴリ

                                          サイト名および使用法(開発など)

                                          WebServer

                                          フロント ドア Cisco Prime Service Catalog のURL

                                          https:/​/​scdev/​RequestCenter/​

                                          管理 Cisco Prime Service Catalog の URL

                                          https:/​/​scdevadmin/​RequestCenter/​

                                          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

                                          http:/​/​subdomain.domain.com:80

                                          キュー接続ファクトリ

                                          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 フィルタ