サイト全体の設定
サイト全体の設定

目次

サイト全体の設定

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

サイト全体の設定

概要

会社のルールやビジネス プラクティスに合わせて Administration モジュールのさまざまな振る舞いをセットアップすることができます。

Administration モジュールから次のようなタスクを実行できます。

  • エンタープライズ ディレクトリなどのユーザ データのソースにリンクして、そのソースからのデータを利用します。
  • 承認および確認のポリシーとワークフローを定義します。
  • 承認および提供のプロセスで使用される電子メール通知テンプレートを定義します。
  • 標準の値リストを修正し、使用可能な言語を指定します。
  • サイト全体の設定をカスタマイズします。たとえば、特定の組織単位または組織単位のグループで使用されるカスタム スタイル シートを確立します。
  • ログ ファイル、消去、バージョン情報、およびフォーム データの表示に関するサポート ユーティリティにアクセスします。

ユーザ情報の同期

ディレクトリとは、ユーザ データのリポジトリのことです。 Administration では、エンタープライズ ディレクトリなどのユーザ データのソースにリンクしてそのソースからのデータを利用するようにシステムを設定できます。 具体的には、ユーザ プロファイル情報をディレクトリ サーバ データベースと同期させることができます。

ディレクトリ統合の詳細(統合に必要な情報を整理するためのワークシート、詳細なマッピング情報、特別な考慮事項など)については、『Cisco Prime Service Catalog Integration Guide』を参照してください。

サイト全体の承認の設定

Administration モジュールの [承認(Authorizations)] タブで、承認と確認の有効化および無効化と、サイト全体の承認のセットアップができます。 このようなサイト全体の承認は、個々の組織やサービスまたはサービス グループに対して確立済みの承認に加えて、またはその代わりとして使用できます。

承認は、割り当てられた承認者に対してサービス要求の拒否または承認を求めるタスクです。 確認は、実行者に対して提供プロセスのステップの確認を求めるタスクです。

Service Catalog では、複数のタイプの承認と確認をサポートしています。

表 1 承認

ファイナンシャル承認

要求されたサービスまたは項目が予算内であるかどうかを判断する承認。 この承認は、組織単位レベルでは上書きできません。

部門承認

事業単位マネージャによる購買承認のための承認。

部門確認

部門で要求されたサービスまたは項目が適切であるかどうかの確認。

サービス グループの承認

サービス チーム マネージャによる購買承認のための承認。 通常、サービス チーム マネージャは、自分のサービス チームに所属する人を承認します。

サービス グループの確認

サービス グループで要求されたサービスまたは項目が適切であるかどうかの確認。

承認構造の設定

承認プロセスの設定は、次の 3 つの手順で構成されます。

  1. Administration モジュールの [承認(Authorizations)] タブで、使用可能にする承認のタイプおよび実行順序を指定します。 (承認の有効化を参照)。
  2. 有効になっている各タイプの承認の詳細を指定します。 (承認の詳細の指定を参照)。
  3. 任意で、必要な承認が遅れた場合に実行するエスカレーション プロシージャを指定します。 (遅延タスクの通知を参照)。
承認の有効化

Administration モジュールの [承認(Authorizations)] タブで、1 つのサイトに対して最大 5 つの承認タイプを有効にできます。

承認タイプのステータスを変更するには、変更する承認タイプの [アクション(Action)] 列で [編集(Edit)] をクリックし、[ステータス(Status)] ドロップダウン メニューから [有効化(Enable)] または [無効化(Disable)] を選択します。 実行順序を変更するには、[アクション(Action)] 列で上矢印または下矢印をクリックして正しい順序にします。

承認の詳細の指定

承認または確認のタイプが有効になっている場合は、このタイプに対して詳細を指定できます。 承認の詳細は、次のように定義できます。

  • サイト レベル([管理(Administration)] > [承認(Authorizations)])
  • Departmental Authorizations/Reviews の組織単位([Organization Designer] > [組織単位(Org Units)] > [承認(Authorizations)])
  • Service Group Authorizations/Reviews のサービス グループまたはサービス単位([Service Designer] > [承認(Authorizations)])

Departmental Authorizations/Reviews の場合、次の選択肢があります。

  • サイトの承認構造のみを使用(Use site authorization structure only)
  • 部門レベルの承認のみを使用(サイトレベルは使用しない)(Use departmental level authorization only (Will not use site level))
  • サイトレベルと部門レベルの承認構造を両方使用(Use both site and departmental level authorizations structures)

Service Group Authorizations/Reviews の場合、次の選択肢があります。

  • サービス グループの承認構造を使用(Use service group authorization structure only)
  • サービス レベルの承認のみを使用(サービス グループ レベルの承認は使用しない)(Use service level authorization only (will not use service group-level))
  • サービス グループ レベルとサービス レベルの承認構造を両方使用(Use both service group level and service level authorizations structures)

[サイトの承認構造のみを使用(Use site authorization structure only)] または [サービス グループの承認構造を使用(Use service group authorization structure only)] オプションを選択した場合、それ以上の手順は必要ありません。 それ以外の場合は、設定する承認タイプを選択できます。

  • Authorization(Departmental または Service Group):承認時間内で承認が順に実行されます。 各承認者は、要求を拒否または承認する必要があります。 要求が承認されると、次の承認または提供プロセスの次のステップに渡されます。 要求がキャンセルされると、以降のタスクは実行されません。
  • Review(Departmental または Service Group):確認プロセスは、承認時間内で同時に実行されます。 確認者は、[OK] をクリックするだけで要求を確認したことを示すことができます。確認者には、提供を停止する権限はありません。

(注)  


すべての承認タスクと確認タスクは、提供プロセスが開始する前に完了する必要があります。

Administration モジュールの [承認(Authorizations)] タブで、編集する承認または確認の横にある [アクション(Actions)] カラムの [編集(Edit)] をクリックします。 選択する承認タイプに基づいて、[承認 – 逐次的プロセス(Authorizations – Sequential Process)] または [確認 – 同時プロセス(Reviews – Concurrent Process)] サブタブが表示されます。

次の表に、[詳細(Details)] 画面のフィールドを示します(これらのサブタブの [追加(Add)] をクリックした後、またはサブタブの [名前(Name)] フィールドの左にあるチェックボックスをクリックして定義済みの承認/確認ロールを選択した後に表示されます)。 [更新(Update)] をクリックして変更を保存します。 アスタリスク(*)の付いたフィールドは必須フィールドです。

表 2 逐次的プロセス - 承認

フィールド

説明

名前(Name)*

承認者または確認者によって実行されている新しい役割の名前。

期間(Duration)*

タスクの承認または確認に割り当てられる時間(時間単位)。

件名(Subject)*

この役割が実行する承認タスクまたは確認タスクの名前。 この値は、Service Manager で承認者または確認者に対して [タスクリスト(Task List)] に表示されます。

タスクのタイトルには名前空間変数を使用できます。 ハッシュ マーク(#)で囲まれた文字列は、名前空間変数であることを示します。 この変数は、オーダー中のサービス名で置き換えられます。 詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。

実行(Effort)*

確認または承認の実行所要時間。 通常、[時間(Duration)] よりも小さい値になります。

ワークフロータイプ(Workflow Type)

承認者がシステム内のユーザである場合は、[internal] を選択します。または、使用可能な外部ワークフローを選択して、Service Link タスク経由で承認を実行します。

Assign

ドロップダウン メニューから、次のいずれかを選択します。

  • [役職から(From a position)]:承認または確認は、指定された役職を現在保持している人によって実行されます。
  • [人/キュー(A person/queue)]:承認または確認は、指定されたユーザまたはキューによって実行されます。
  • [式から(From an expression)]:[割り当て先(Assign to)] フィールドに入力された式に基づいて承認または確認が実行されます。

割り当て先(Assign to)

をクリックして、[割り当て(Assign)] フィールドの選択内容に対応する値を選択します。 [式から(From an expression)] を選択した場合は、式を入力します。 式の構文については、『Cisco Prime Service Catalog Designer Guide』を参照してください。

エスカレーション階層(Escalation Tiers)

次のいずれかをクリックします。

  • [すべて使用(Use all)]:このプロセスに対して設定されているすべてのエスカレーションが使用されます。
  • [使用数を指定(Use only)]:この承認プロセスまたは確認プロセスに対して設定されているすべてのエスカレーション層を使用しない場合は、使用する層の数を入力します。

条件

承認するために満たす必要がある条件を含む式。 True または False を使用して、タスクが発生するかどうかを示します。 式を入力しない場合は、デフォルト値が True になり、承認が常に実行されます。

使用している式が動作することを検証するには、[確認(Validate)] をクリックします。 検証では構文チェックのみが実行され、参照データが実際に要求に存在するかどうかはチェックされません。

次の場合に条件を評価(Evaluate condition when)

次のいずれかを選択します。

  • 承認フェーズが開始されたとき(条件の評価が「false」になると、時間はゼロとして計算されます。)(Authorization phase starts (if condition evaluates to "false", times will be computed as zero).) [条件(Condition)] フィールドに入力した条件は、承認フェーズが開始した時点でアクティブになります。
  • [タスクがアクティブになったとき(時間は影響を受けませんが、スケジューリングはこれらのタスクを使用して行われます)(Task becomes active (times will not be affected, scheduling will be done by using these efforts))]:[条件(Condition)] フィールドに入力した条件は、承認フェーズが完了し、承認後のタスクが開始した時点でアクティブになります。

承認/確認が進むときに式を再評価(Re-evaluate expression as authorizations/reviews proceed)

承認タスクが完了するたびに実行者名またはタスク名を再評価し、必要に応じて更新するには、このチェックボックスをオンにします。 承認期日は変わりません。 この設定は、実行者が式によって割り当てられ、その式に使用するフィールド値の変更を前の承認ステップで承認者に許可した可能性がある場合に使用してください。

承認や確認が開始されたときに通知(Notify when authorization/review starts)

電子メール テンプレートは全フェーズで適切に自動送信されます。 システムで使用できる電子メール テンプレートのリストがドロップダウン リストに表示されます。

承認や確認が完了したときに通知(Notify when authorization/review completes)

要求や活動がキャンセルされたときに通知(Notify when requisition/activity is canceled)

要求や活動が拒否されたときに通知(Notify when requisition/activity is rejected)

タスクがスケジュール変更されたときに通知(Notify when task is rescheduled)

タスクが再割り当てされたときに通知(Notify when task is reassigned)

外部タスクが失敗したときに通知(Notify when external tasks fail)

遅延タスクの通知

エスカレーションとは、指定された期間内に実行されなかったアクティビティにフラグを立て、解決のために適切な実行者、スーパーバイザ、または顧客に送信するプロセスのことです。 受信者は、遅延タスクの通知を電子メール形式で受け取ります。

エスカレーション プロセスをセットアップする場合は、次の点に注意してください。

  • エスカレーション リストの各行は、層を表します。 層はいくつでも指定できます。[追加(Add)] をクリックして、別の層を追加します。 (対応するチェックボックスをオンにして [削除(Delete)] をクリックすると、層を削除できます)。
  • 最初の層は、タスクが標準期間を超えた場合に最初に通知されるグループを表します。 時間([(時間)後(After (hours))])は、期日が過ぎて通知が送信されるまでの時間数を表します。
  • 最初の通知後の、後続の層に指定された時間は、前のエスカレーション以降の経過時間を表します。 たとえば、2 番目の層の時間が 8 時間である場合、最初の通知の送信後に解決されず 8 時間が経過すると、2 番目のグループに通知が送信されます。
  • 層ごとに 3 人までの受信者がエスカレーション通知を受信できます。 [受信者(Recipient)] ボックスごとに、有効な電子メール アドレスをカンマで区切って入力します。 #変数# タイプの名前空間参照も使用できます。 たとえば、#Perfomer.Manager.Email# は、タスク実行者のマネージャに通知を送信します。
    • 受信者ごとに、対応するドロップダウン ボックスを使用して、受信者への通知に使用する電子メールを選択します。 通知は、Administration モジュールで作成されたテンプレートから派生します。

実際には、エスカレーションは、ワークフロー マネージャである Business Engine の一部である Escalation Manager によって送信されます。 デフォルトでは、通常の勤務時間中に、関連するエスカレーションが指定された遅延タスクが、Escalation Manager により 1 時間に 1 回(正時)チェックされます。 したがって、上記で示しているように、承認が指定時間遅れた後で電子メール通知が送信されるというのは必ずしも正確でありません。 通知が実際に送信されるのは、エスカレーション期間が期限切れとなった後で Escalation Manager による遅延タスクのチェックが次に行われたときです。 たとえば、承認が午後 12:30 に予定されており、エスカレーション通知をその 1 時間後(午後 1:30)に送信するよう設定されている場合、通知が実際に送信されるのは、Escalation Manager の実行が次に行われる午後 2 時となります。

管理者は、Escalation Manager の設定を変更できます。 詳細は、Prime Service Catalog の保守を参照してください。

Email Templates

Service Catalog には、事前設定の電子メール テンプレートのセットが含まれています。 発生したイベントへの応答として自動的にテンプレートを送信するように、サービスの提供計画をセットアップできます。 Administration モジュールでは、電子メール通知に使用されるテンプレートを新規に作成したり、提供されたテンプレートを修正したりすることができます。 この電子メールは、受信者に承認と提供のプロセス中のステップを通知するのに使用されます。

Service Catalog で使用されるテンプレートは、[全般(General)] リンクの下にあります。 Demand Center で使用されるテンプレートは、[契約電子メールテンプレート(Agreement Email Templates)] の下にあります。 発生したイベントへの応答として自動的にテンプレートを送信するように、Administration を設定できます。 たとえば、あるサービスでマネージャからの承認が必要であるときに、システムからこのマネージャに、サービス要求の承認が必要であることを通知する電子メールを送信できます。 付属のテンプレートを変更することも、組織に適したテンプレートを追加することもできます。

電子メール テンプレートの表示

電子メール テンプレートの情報を表示するには、次の方法のいずれかを使用します。

  • [ホーム(Home)] ページの [Eメールテンプレートの管理(Manage Email Templates)] をクリックします。 [Eメールテンプレート(Email Templates)] ナビゲーション ペインで、開いて表示するテンプレートの名前をクリックします。
  • ナビゲーション バーの [通知(Notifications)] をクリックします。 [Eメールテンプレート(Email Templates)] ナビゲーション ペインで、開いて表示するテンプレートの名前をクリックします。

テンプレート名をクリックすると、テンプレートのスタイル設定オプションと内容が表示されます。 次に示すのはサンプルの Service Catalog テンプレートです。

図 1. [Eメールテンプレート(Email Templates)] ページ

テンプレートの設定

電子メール テンプレートを設定するには、次の情報を入力します。

表 3 電子メール テンプレート フィールド

フィールド

説明

[名前(Name)]

新しい電子メールのテンプレートの名前。

Subject

電子メールの件名。名前空間を使用できます。

送信元(From)

送信者の有効な電子メール アドレス。

To

受信者の有効な電子メール アドレス。複数の受信者はセミコロンで区切ることができます。通常は、名前空間を使用します。

タイプ(Type)

Service Catalog または Demand Center。

[言語(Language)]

表示言語。

[HTML部分(HTML Part)]

クリックすると、HTML 対応電子メール システムで表示される形式でテンプレートが表示されます。 クリックすると、電子メール テンプレートの書式を設定するための HTML エディタ ツールが表示されます。

[テキスト部分(Text Part)]

クリックすると、テンプレートの書式設定に使用される HTML タグとテキストが表示されます。

作成した電子メール テンプレートで使用しないものは削除できます。 事前設定テンプレートは削除できません。

Service Catalog は、テキスト部分と HTML 部分の両方がある MIME マルチパート メッセージの形式で電子メール通知を送信します。 多くの電子メール クライアントは、テキスト部分を無視し、HTML 部分を表示します。

HTML エディタの使用手順については、『Cisco Prime Service Catalog Designer Guide』を参照してください。

名前空間の使用

動的なデータ コンテンツのある電子メールのフォーマットの詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。

通知の受信者は、その電子メールの送信をトリガーするイベントによって異なります。 たとえば、顧客(#Requisition.Customer.Email#)は一般に、要求のステータスが大きく変化したことについて通知を受け取ります。

イベントが承認または確認である場合は、承認者の代理者(#Requisition.Alternate.Email#)も受信者リストに含めるのが賢明である可能性があります。 現時点で代理者が 1 人も指名されていない場合は、名前空間の値はブランクとなりますが、通知の外観には影響しません。

一覧

Administration では、サイト内のさまざまな場所や関連レポートで使用される標準の値リストに修正を加えたり、使用可能な言語を指定したりすることができます。

[一覧表示(Lists)] タブを使用して、次のリストを設定します。

表 4 リスト フィールド

リスト名

説明

コスト ドライバ

コスト ドライバは、Service Designer でサービスのコスト詳細を設定するときに使用できます。

目的

目標リストは、Service Designer で目標を作成するときにドロップダウン リストで使用可能な目標基準の設定に使用されます。

測定単位(Unit of Measure)

測定単位は、Service Designer で目標を設定するときに基準と組み合わせて使用されます。

[言語(Language)]

言語リストは、ユーザ プロファイルや個人情報内の [表示言語(Preferred Language)] ドロップダウン リストで選択可能な言語のリストを管理するために使用されます。 詳細については、[言語(Language)]を参照してください。

[言語(Language)]

Service Catalog モジュールは、複数の言語で利用できます。 言語リストは、ユーザが個人プロファイルの [表示言語(Preferred Language)] ドロップダウン リストで選択可能な言語のリストを管理するのに使用されます(言語設定を参照)。 デフォルトでは、[使用する言語(Preferred Language)] ドロップダウン リストで使用できるのは [英語(米国)(US English)] のみです。 他の言語を使用できるようにするには、言語リストにその言語を追加します。 [追加(Add)] をクリックし、言語をドロップダウン リストから選択してから [更新(Update)] をクリックします。 その他の設定手順は必要ありません。

Service Catalog でサポートされている言語は次のとおりです。

  • 英語(米国)
  • ドイツ語
  • フランス語
  • スペイン語
  • オランダ語
  • 中国語(簡体字)
  • 中国語(繁体字)
  • ポルトガル語(ブラジル)
  • 日本語
  • 韓国語

他のすべてのモジュールのローカリゼーションについては、『Cisco Prime Service Catalog Designer Guide』の「Localizing Service Catalog Strings」の章を参照してください。

サイト設定

Administration では、さまざまな動作を、自組織のポリシーや業務慣習に適合するようにカスタマイズできます。 これらのオプションを設定するには、[設定(Settings)] タブをクリックします。 [設定(Settings)] タブに表示されるオプションは次のとおりです。

表 5 [サイト設定(Site Settings)] ページ

ページ

説明

カスタマイゼーション

さまざまなモジュールの、サイト全体の設定を指定します。

個人ポップアップ

個人検索の実行時に表示される情報のタイプを設定します。

Entity Homes

同じ実装の各サイト上で修正可能な定義データを指定します。

デバッグ設定

デバッグ情報をユーザ インターフェイス内に表示するかどうかを指定します。

アプリケーションのロケール

すべての新規ユーザーが更新された言語および対応する通貨を使用するようにします。

パスワード ポリシー

パスワード設定のポリシーを定義します。

カスタム スタイル

適用する組織を定義および指定します。

データ ソース レジストリ

アプリケーションに登録されているデータ ソースが表示されます。

カスタマイゼーション

カスタマイゼーションを使用すれば、組織の業務慣習に合わせてオプションを設定できます。 カスタマイゼーション設定は、影響を受けるモジュールや各設定によって付与される機能に応じて、いくつかのグループに分かれています。

カスタマイゼーションに使用できる値は次のとおりです。

表 6 カスタマイゼーション

KpiSourceOfData

KPI チャートのデータ取得元を制御します。 「Datamart」に設定する必要があります。

SessionTimeOut

セッション タイムアウトを設定します。デフォルトは 20 分です。2 時間(240 分)以下の任意の長さに設定できます。

API SessionTimeout

すべての API のセッション タイムアウトを設定します。 nsAPI がクレデンシャルを使用して直接(nsAPI ログインを呼び出すことなく)呼び出された場合は、応答の送信後に自動的にセッションが終了する必要があります。

Attachment Maximum Size

サービス要求の添付ファイルとしてアップロードできるファイルの最大サイズを設定します。 0 はサイズ上限なしを示します。

Attachment File Type Restrictions

添付が許可/禁止されているファイル タイプを定義します。 これはファイル拡張子をカンマで区切ったリストとして定義します(例:.exe, .bmp, .zip)。

Order Confirmation Email Template

顧客が要求を送信したときに送信される電子メール通知。

Image Maximum Size

アップロード可能なファイルの最大サイズを設定します。attachment 0 は最大サイズなしを意味します。

Image Types Allowed

許可されるイメージ タイプを定義します。 カンマで区切ったファイル拡張子のリストとして指定します。 例:.jpg,.img,.bmp。 デフォルトで許可されるイメージ タイプは、.jpg、.png、.gif、.jpeg、.tiff、.exif、および .svg です。

非同期送信/最終承認

Service Catalog は、サービス要求を処理するために、トランザクショナル データベース内に一連のレコードを作成する必要があります。これらのレコードは、サービス ワークフローを構成する承認および提供タスクに対応しています。 複雑な提供計画の場合は、これらのタスクを作成して、割り当てられた参加者、それぞれの作業カレンダー、および指定のタスク期間に基づいてすべてのタスクのスケジュール上の開始日および終了日を計算するには、かなりの時間がかかることがあり、その間ユーザ(要求者または最終承認)は、自分のサービス要求送信の処理が完了したことの確認を待つ必要があります。

この待ち時間をなくすため、Service Catalog には非同期タスク インスタンス化を実装するオプションが用意されています。 つまり、要求が送信されたとき(または、要求に承認または確認がある場合に最終承認が完了したとき)に、Service Catalog はサービス要求の更新(または作成)のみを行うため、ユーザは次に進めるようになります。 残りの処理(タスクの作成と期限の計算)は、バックグラウンドで非同期に実行されます。

この結果、ユーザ インターフェイスには、待ち時間がなくなるという大きな変更が加えられ、他にもいくつかの小さな変更があります。 要求の送信後、Business Engine によって処理されるまで、ステータスは [発注済み(Ordered)] になります。 その後、ステータスは [進行中(Ongoing)] になります。

万一、Service Catalog による全タスクの作成中にエラーが発生した場合は、通知の電子メールを関係者に送信できます。 2 つの電子メール テンプレートを指定できます。1 つ目は要求の送信が失敗した場合に使用され、2 つ目は最後の承認が正しく処理できなかった場合に使用されます。 テンプレートを設計するには、Administration モジュールの [通知(Notifications)] オプションを使用します。テンプレートと各イベントを関連付けるには、[管理(Administration)] > [設定(Settings)] > [カスタマイズ(Customizations)] の設定を使用します。 失敗した要求の表示と再試行のための送信は、[管理デバッグ(Administration Debugging)] ページで行います。 詳細については、非同期送信メッセージのモニタリングを参照してください。

非同期タスクのインスタンス化は、デフォルトではオフになっています。 この動作をアクティブにするには、[管理(Administration)] > [設定(Settings)] > [カスタマイズ(Customizations)] の [共通(Common)] セクションにある [非同期での送信、承認、および確認(Submit, Approve and Review Asynchronously)] の設定をオンにする必要があります。

表 7 Email Templates

オーダーの失敗 E メール テンプレート

オーダー送信プロセスが予期せず異常終了したときに送信される電子メール。 このエントリが効力を持つのは、[非同期でのタスクの送信、承認、および確認(Submit, Approve and Review Tasks Asynchronously)] の設定がオンの場合のみです。

承認の失敗 E メール テンプレート

ユーザが実行した承認または確認のタスクが予期せず異常終了した場合に送信される電子メール。 このエントリが効力を持つのは、[非同期でのタスクの送信、承認、および確認(Submit, Approve and Review Tasks Asynchronously)] の設定がオンの場合のみです。

ブラウザ キャッシュの設定

この設定は、本番環境においてほとんど変更されることのないアプリケーション ファイルをブラウザ キャッシュに格納できるようにします。 この機能を使用すると、キャッシュ済みのオブジェクトが利用されるため、遠隔地にいるユーザのページ読み込み時間が大幅に改善される可能性があります。リフレッシュが要求されるのは、バージョンの変更が検出されたときのみです。

ブラウザ キャッシュが有効な場合は、最後にアクセスされたバージョンを記録するための Cookie がブラウザ クライアント内に作成されます。次のタイプのオブジェクトについては、キャッシュされたバージョンをアプリケーションで利用できます。

  • 画像(*.gif、*.jpg、*.png、*.bmp)
  • スタイル シート(*.css)
  • ISF ライブラリ(RequestCenter.war の下に展開される *.js および *.cfm。streamJS.jsStream によって条件付きルールのために実行時に生成される JavaScript やユーザ定義の JavaScript は含まれません)
  • HTML(*.html、*.htm)ページ

アプリケーション変更イベントが発生した場合(たとえば、変更されたイメージを持つサービスを Catalog Deployer を使用して展開するなど)、管理者はバージョン番号を増加させることで、ユーザにブラウザ キャッシュの削除を要求することができます。

ユーザのブラウザ Cookie に記録されているバージョンが、[管理(Administration)] 設定のものと異なる場合は、ユーザにブラウザ キャッシュの削除を要求する通知が表示されます。 ブラウザ キャッシュが削除されたら、[再ログイン(Login Again)](シングル サインオンが有効な場合は [続行(Continue)])をクリックしてアプリケーションにアクセスできます。

JMS クレデンシャル

アプリケーションのインストール時に、JMS ユーザ名とパスワードの値が初めて収集されます。 それ以降にアプリケーション サーバ側でクレデンシャルが変更された(企業のパスワード ポリシーやその他の要件で必要とされたため)場合は、更新された値をここに入力して、Prime Service Catalog アプリケーションが JMS キューへのアクセスを継続できるようにする必要があります。

VSOC の設定

VSOC の設定は VSOC ソリューションに使用されます。シスコの指示がない限り、変更しないでください。

AMQP の設定

AMQP ユーザ名とパスワードを他の AMQP 設定と一緒に使用して、RabbitMQ サーバとの接続を確立することができます。 AMQP 公開キーは重要なフィールドを保護するために使用されます。この保護されたフィールドは対応する秘密キーを使用して外部システムで復号化されます。 AMQP セキュア文字列形式はデータの暗号化形式です。 デフォルトのセキュア文字列形式はバイトです。 外部システムにサービス要求を発行するための AMQP タスクの設定方法については、『Cisco Prime Service Catalog 11.0 Designer Guide』を参照してください。


(注)  


一度に接続可能な AMQP は 1 つだけです。
共通設定

共通設定は、複数のモジュールの振る舞いに影響を及ぼします。

表 8 共通設定

カスタムヘッダーフッターの有効化(Enable Custom Header Footer)

カスタム ヘッダーとフッターを有効にします。

デフォルトはオフです。

カスタムスタイルシートの有効化(Enable Custom Style Sheets)

カスタム スタイル シートをサイトの書式設定に使用します。ロゴ、カラー スキーム、フォントなどの HTML 属性を変更できます。

デフォルトはオフです。

ディレクトリ統合

外部のデータソースでユーザを検索して、そのユーザをサイトにインポートするディレクトリ機能を有効にします。

デフォルトはオフです。

サイト管理者URLの制限(Restrict Site Administrator URL)

Site Administrator ロールを持つユーザのみにログインを許可します。管理用 URL を使用し、シングル サインオンをバイパスします。

デフォルトはオフです。

イメージパス置換の使用(Use Image Path Replacement)

プレゼンテーション イメージ URL のサーバ部分の代わりに動的変数を使用します。

デフォルトはオフです。

強力な暗号化の使用(Use Strong Encryption)

フォーム データおよびドキュメント添付ファイルに高度暗号化を使用します。 使用は推奨されません。

デフォルトはオフです。

KPIポートレットの表示(Show KPI Portlet)

Key Performance Indicator(KPI)ポートレット機能をオンまたはオフにします。 この機能がオンの場合は、My Services Executive を実行できるユーザの My Services ホームページに KPI が表示されます。 Reporting モジュールへのアクセス権限を持つユーザは、KPI をいつでも、Reporting ダッシュボードで見ることができます。

デフォルトはオフです。

非同期送信、承認、および確認(Submit, Approve, and Review Asynchronously)

要求の送信と、承認と確認の完了のバックグラウンド処理を有効または無効にします。

デフォルトはオフです。

標準テーブルのエントリ(データ)の展開(Deploy Entries (data) in Standards Tables)

Catalog Deployer パッケージを作成するときに、標準テーブルの定義に加えて、そのテーブルからのエントリ(データ)も含めるかどうかを指定します。 標準データがパッケージ展開によって上書きされないようにするには、これをオフのままにします。

デフォルトはオンです。

ログイン名の表示(Show Login Name)

個人ログイン名を個人プロファイルの表示ポップアップ ページに表示するかどうかを指定します。

デフォルトはオフです。

暗号化パスワードの許可(Accept encrypted Password)

有効にした場合は、受信 HTTP 要求に使用されるパスワードを暗号化形式にする必要があります。

デフォルトはオフです。

履歴要求ビューの有効化(Enable Historical Requisitions View)

有効にした場合は、My Services と Service Manager で履歴要求にアクセスできます。

デフォルトはオフです。

履歴要求スケジューラの有効化(Enable Historical Requisitions Scheduler)

365 日を超えて完了した要求は、デフォルトで履歴トランザクション テーブルに移行されます。 このスケジューラは、デフォルトで、30 分ごとに 100 のバッチ サイズで 1000 の要求を処理します。 これらのプロパティは、newscale.properties ファイルで設定可能で、特定の組織のニーズに合わせて変更できます。

有効にした場合は、クローズ済み要求がアーカイブされます。

デフォルトはオフです。

詳細については、プロセスの実行を参照してください。ディレクトリ統合の詳細については、『Csco Prime Service Catalog Integration Guide』を参照してください。

サービスカタログの有効化(Enable Service Catalog)

この設定がオンになっている場合は、モジュール メニューに、[マイサービス(My Services)] の代わりに、[サービスカタログ(Service Catalog)] と [オーダー管理(Order Management)] が表示されます。 この共通設定は、プロファイル設定を変更することによって、上書きできます。

デフォルトはオンです。

スタイル関連の設定

カスタム スタイル シートやヘッダーとフッターをオンにすることは、Web ページの外観カスタマイズの最初のステップに過ぎません。 管理者は、使用するスタイルを設計して、該当するファイルを適切なサーバにアップロードする必要があります。また、Administration のオプションを使用してスタイルをサイトに、またはサイト内の特定の組織に関連付ける必要があります。

ディレクトリ統合関連の設定

ディレクトリ統合をオンにすることは、Service Catalog とエンタープライズ LDAP ディレクトリとの統合の最初のステップに過ぎません。統合によって、ディレクトリに格納されている個人および組織のデータが Service Catalog で使用できるようになるほか、そのディレクトリを使用した外部認証やシングル サインオンも可能になります。 ディレクトリ統合を一時的にオフにするには、この設定を「オフ」にします。

ディレクトリ統合の設定では、外部認証またはシングル サインオンを、トラブルシューティングやテストなどの理由のためにオーバーライドすることもできます。 管理目的でこのようにオーバーライドすることができるのは、一般的に、Site Administrator 特権を持つユーザに限定されます。

ディレクトリ統合の詳細については、『Cisco Prime Service Catalog Integration Guide』を参照してください。

Catalog Deployer 関連の設定

Catalog Deployer によってサービスが展開されるときに、そのサービスで参照される標準の定義(一般的には、データ取得ルールの形を取ります)が自動的に展開され、その標準に対応するエントリ(データ)も展開されます。 [標準テーブルのエントリ(データ)の展開(Deploy Entries (data) in Standards Tables)] 設定を使用すると、この動作をオーバーライドすることができます。 [いいえ(No)] に設定されている場合は、Catalog Deployer によって標準データがターゲット環境に展開されることはありません。 ターゲット環境へのデータ読み込みには別の方法(Lifecycle Center を使用して手作業で入力するか、標準データをインポートする)が使用されると想定されます。

詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。

My Services の設定

My Services の設定は、My Services モジュールの動作と外観を制御します。

表 9 My Services の設定

フィールド

説明

My Servicesで計画を表示する(Show Plan In My Services)

サービスの提供計画のタスクのステータスが、そのサービスを要求した顧客に表示されるようにします。

デフォルトはオフです。

数量の更新を許可する(Allow Update Quantity)

My Services ユーザがサービス要求の数量を更新できます。

デフォルトはオフです。

検索でカテゴリを使用する(Use Categories In Search)

My Services の検索機能にカテゴリ名を追加します。 一致するカテゴリに含まれるサービスが検索結果に表示されます。

デフォルトはオンです。

空のカテゴリを表示する(Display Empty Category)

サービスが含まれていないカテゴリを My Services ポータルに表示するかどうかを指定します。

デフォルトはオフです。

フォームモニタを表示しない(Hide Form Monitor)

サービス フォーム ディクショナリ モニタを表示または非表示にします。

デフォルトはオフです。

承認ポートレットを表示する(View Authorization Portlet)

My Services の [承認(Authorization)] ポートレット機能をオンまたはオフにします。 有効になっている場合は、すべてのユーザに対して [承認(Authorization)] ポートレットが表示されます。 この設定よりも、各ユーザのプロファイル内の対応する設定の方が優先されます。

デフォルトはオンです。

サービス項目ポートレットを表示する(View Service Items Portlet)

My Services の [サービス項目(Service Items)] ポートレット機能をオンまたはオフにします。 有効になっている場合は、すべてのユーザに対して [サービス項目(Service Items)] ポートレットが表示されます(ユーザが自分のプロファイルの中でオフにした場合を除く)。

デフォルトはオフです。

共通タスクポートレットを表示する(View Common Tasks Portlet)

My Services の [共通タスク(Common Tasks)] ポートレット機能をオンまたはオフにします。 有効になっている場合は、すべてのユーザに対して [共通タスク(Common Tasks)] ポートレットが表示されます。

デフォルトはオンです。

要求ポートレットを表示する(View Requisitions Portlet)

My Services の [要求(Requisitions)] ポートレット機能をオンまたはオフにします。 有効になっている場合は、すべてのユーザに対して [要求(Requisitions)] ポートレットが表示されます。

デフォルトはオンです。

すべてのユーザに代理オーダーを許可する(Allow Order On Behalf For All Users)

代理オーダー機能へのアクセス権をすべてのユーザに付与します。

(注)      この設定は今後のバージョンで廃止になる場合があります。 また、代理オーダー権限の付与はロール経由で行うことを強くお勧めします。

デフォルトはオフです。

代理オーダーのすべてのユーザを表示する(Show All Users For Order On Behalf)

代理オーダー機能を使用するユーザが、組織単位や個人の代理オーダー権限設定とは無関係に、サイト内の任意のユーザの代理でサービスをオーダーできるようになります。

デフォルトはオフです。

承認タスクをポップアップで開く(Open Authorization Task in a popup)

有効になっている場合は、My Services の承認タスクが別のポップアップ ウィンドウに表示されます。

デフォルトはオフです。

請求先OUの選択を許可する(Allow Bill To OU Selection)

My Services ユーザが、サービス要求内の請求先組織単位を変更できるようにします。

デフォルトはオフです。

Form Monitor

Form Monitor は、サービス フォームの右側に表示されます。 ここには、フォーム内のディクショナリが表示されます。 ディクショナリのチェックが行われるのは、そのディクショナリ内のすべての必須フィールドに値が入力されたときです。 必須フィールドのステータス チェックは、グリッド ディクショナリには適用されません。

サービス フォームの表示後にディクショナリがルールまたは ISF コードによって非表示にされると混乱を招くおそれがあります。そのディクショナリは引き続き Form Monitor に表示されているためです。

[承認(Authorizations)] ポートレット

[承認(Authorizations)] ポートレットでは、現在のユーザに割り当てられたすべての承認をすばやく表示してアクセスできます。 承認を表示可能なユーザの場合は、このポートレットが [マイサービス(My Services)] 画面の左側に表示されます。

[承認(Authorizations)] ポートレットは、最新の 5 つの承認のクイック ビューと現在のユーザに割り当てられたすべての承認を表示する手段を提供します。 承認にアクセスする方法としては他にも、[共通タスク(Common Tasks)] > [承認(Authorizations)] リンクと My Services モジュールのナビゲーション バーの [承認(Authorizations)] タブがあります。

[サービス項目(Service Items)] ポートレット

[サービス項目(Service Items)] ポートレットでは、現在のユーザに割り当てられたサービス項目が表示され、任意のサービス項目にすばやくアクセスできます。 このポートレットを使用できるのは、Lifecycle Center のライセンスを取得済みのサイトのみです。

[サービス項目(Service Items)] ポートレットには、プロビジョニング済みサービス項目のうち最新の 5 件が表示され、現在のユーザに割り当てられているすべてのサービス項目を表示することもできます。 サービス項目にアクセスする方法としては他にも、My Services モジュールのナビゲーション バーの [サービス項目(Service Items)] タブがあります。

[要求(Requisitions)] ポートレット

[要求(Requisitions)] ポートレットには、送信済みで進行中の要求のうち最新の 5 件が表示され、ここから要求にアクセスできます。 有効にした場合は、このポートレットが [マイサービス(My Services)] 画面の左側に表示されます。

要求にアクセスする方法としては他にも、My Services モジュールのナビゲーション バーの [要求(Requisitions)] タブがあります。

[共通タスク(Common Tasks)] ポートレット

[共通タスク(Common Tasks)] ポートレットには、My Services アクションのうち、よく使用されるものへのショートカットが表示されます。 有効にした場合は、このポートレットが [マイサービス(My Services)] 画面の左側に表示されます。

My Services のポートレット

My Services のポートレット(承認、サービス項目、要求、および共通タスク用)は事前設定済みです。 My Services ホームページの左側に、すべてを表示することも、一部だけを表示することも、すべてを非表示にすることもできます。 My Services のポートレットを非表示にする場合は、ページのコンテンツ部分(Service Catalog)が拡張してページ幅いっぱいに表示されます。

My Services のポートレットのコンテンツと外観は、上記のとおりに事前設定されています。 ポートレットの用途や外観をさらにカスタマイズするには、Cisco Portal Designer を使用します。詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。

Service Manager の設定

Service Manager の設定は、Service Manager モジュールの外観と動作に影響を及ぼします。

表 10 Service Manager の設定

設定

説明

タスクリンクを表示(Show Task Link)

提供プロセスのタスクを表示するときに、すべてのタスクにハイパーリンクを設定します。ユーザが計画内の他のタスクにすばやくジャンプできるようになります。

デフォルトはオンです。

関連タスクをデフォルトで待機(Related Tasks Default To Wait)

Ad-Hoc タスクを作成するときに、現在のタスクを一時停止するオプションを設定します。 これよりも優先する設定を、Ad-Hoc タスクの作成時に指定できます。

デフォルトはオフです。

Ad-Hoc タスクの電子メールを有効にする(Enable Ad-Hoc Task Email)

有効化すると、新規作成された Ad-Hoc タスクの実行者宛てに、Ad-Hoc タスク開始を通知する電子メールが Service Catalog によって自動的に送信されます。

デフォルトはオンです。

未定義のロールを表示(Show Undefined Roles)

モニタ タスクのスタッフ割り当てセクションに、サービス提供計画内でまだ定義されていないロールを表示します。

デフォルトはオフです。

サービス実行者は実行者全員を検索可能(Service Performers Can Search All Performers)

有効化すると、ユーザが実行者検索機能を使用するときに、Service Manager へのアクセス権を持つ他のすべての人を検索できるようになります。 それ以外の場合は、ユーザと同じサービス チーム内の人に限定されます。

デフォルトはオフです。

タスク スーパーバイザにタスクをキャンセルを許可(Allow Task Supervisors To Cancel Tasks)

タスク スーパーバイザが、サービスを管理するために割り当てられている提供タスクをキャンセルまたはスキップできるようになります。

デフォルトはオフです。

外部タスクの完了を有効にする(Enable completion of external tasks)

Ongoing ステータスの外部タスクを Service Manager で表示して完了させることができるようになります。 このようなタスクは一般的に、Service Link モジュールの [トランザクションを表示(View Transactions)] にのみ表示されます。 この設定は、この設定が有効であるときに提供計画に追加された、すべての外部タスクに適用されます。 そのタスクは、後でこの設定が無効になった場合でも、Service Manager で完了させることができます。 システム管理者は、設定の整合性を保つ必要があります。

デフォルトはオフです。

バンドルデータを表示(Show Bundle Data)

バンドルされたサービスの場合に、そのサービス内のどのタスクのときも、すべてのディクショナリの複合オーダー フォームを [データ(Data)] ページに表示します。 無効なときは、選択された組み込みサービスに対するディクショナリのみが表示されます。

デフォルトはオンです。

タスクをポップアップで開く(Open Task in a popup)

有効化すると、Service Manager のタスクが別のポップアップ ウィンドウに表示されます。 このようにすると、ユーザがプライマリのウィンドウにタスク リストを表示し、選択したタスクの詳細をセカンダリのウィンドウに表示することができるようになります。 タスク リストがリフレッシュされるのは、[リフレッシュ(Refresh)] がクリックされたときや、ページが再読み込みされたときです。 タスク リストのリフレッシュ頻度を下げると、アプリケーションへの負荷が低下するため、全体的なアプリケーション パフォーマンスの向上に役立ちます。

(注)      バージョン 9.3.2 以降、このオプションが有効な場合は Service Manager モジュールから要求番号をクリックすると、対応するタスクのポップアップ ウィンドウが開きます。 [ホーム(Home)] をクリックするか、メイン ウィンドウからリフレッシュすると、タスク ポップアップ ウィンドウは自動的に閉じます。

デフォルトはオフです。

Service Link の設定

[メッセージを圧縮(Compress Messages)] 設定は、Service Link のメッセージ(内部 nsXML メッセージと外部メッセージの両方)をリポジトリ内に保持するときに圧縮するかどうかを制御します。 内部 nsXML メッセージはかなり大きくなることがあるため、圧縮が推奨されます。 Service Link のメッセージ保存に必要な領域の量を縮小するその他の手段としては、メッセージ コンテンツを最小化するようエージェントを設定する方法や、完了したタスクのメッセージを定期的に消去する方法があります。 これらのオプションの詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。

表 11 圧縮の設定

設定

説明

メッセージの圧縮(Compress Messages)

このフラグがオンのときは、データベース内のメッセージが圧縮されます。 メッセージに使用される領域は小さくなりますが、人間には判読が難しくなります。

デフォルトはオンです。

次の認証設定によって、HTTP/WS アダプタ、Web Service Listener アダプタ、Service Item Listener アダプタ経由で受信した Service Link HTTP 受信要求の認証を制御します。

表 12 HTTP の設定

設定

説明

HTTP 受信要求の認証(Inbound HTTP Request Authentication)

有効にした場合、Service Link の受信要求すべてに認証が必要です。

デフォルトはオンです。

AMQP 用の RabbitMQ サーバへの接続

Prime Service Catalog では、RabbitMQ サーバを使用して AMQP を実装し、システム間のメッセージのルーティングを実行します。

以下の手順を使用して、RabbitMQ サーバに接続します。 接続を確立したら、Service Designer で他のアプリケーションやシステムにサービス要求を発行するように AMQP タスクを設定できます。 サービス要求を使用するシステムの例として、要求を受け取り、履行ワークフローを実行する Cisco Process Orchestrator を挙げることができます。

他のアプリケーションやシステムにサービス要求を発行する AMQP タスクの設定方法の詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。

また、この設定は、要求者に RabbitMQ の詳細を返すために、Overview API によっても使用されます。

はじめる前に
  • RabbitMQ サーバがインストールされ、動作可能であることを確認します。
  • 脆弱性を回避するため、AMQP を使用して Prime Service Catalog からのサービス要求を使用するシステムが TLS v1.2 を使用して RabbitMQ サーバに接続されていることを確認します。
  • SSL がサポートされている場合、必要なポートを有効にし、必要な設定変更を行います。 RabbitMQ サーバの SSL の有効化の詳細については、RabbitMQ のマニュアルを参照してください。

    ステップ 1   [管理(Administration)] > [設定(Settings)] > [AMQP] オプションを選択し、以下の表に示すように AMQP の詳細を入力します。
    ステップ 2   設定を保存し、[AMQP接続のテスト(Test AMQP Connection)] をクリックして検証します。
    (注)     

    一度に接続可能な AMQP は 1 つだけです。


    表 13 AMQP の設定

    フィールド

    説明

    AMQPユーザ名(AMQP Username)

    RabbitMQ サーバに接続するユーザ名を入力します。

    AMQPパスワード(AMQP Password)

    RabbitMQ サーバに接続するパスワードを入力します。

    AMQPホスト(AMQP Host)

    RabbitMQ がインストールされているサーバの IP アドレスまたは名前を入力します。

    AMQPポート(AMQP Port)

    Prime Service Catalog に接続するための RabbitMQ のポート番号が表示されます。 このフィールドは、[AMQPポートタイプ(AMQP Port Type)] で選択したポート番号に基づいて、自動的に入力されます。 デフォルトは 5672 です。

    (注)      設定されたポートがデフォルトで設定されているポートと異なる場合は、そのポートを変更して [更新(Update)] ボタンをクリックし、同じポートを保存できます。

    AMQPポートタイプ(AMQP Port Type)

    Prime Service Catalog に接続するための RabbitMQ のポート タイプを選択します。

    デフォルトは [TCP] です。

    AMQP公開キー(AMQP Public Key)

    AMQP 公開キーは重要なフィールドを保護するために使用されます。この保護されたフィールドは対応する秘密キーを使用して外部システムで復号化されます。

    AMQPセキュア文字列の形式(AMQP Secure String Format)

    AMQP セキュア文字列形式はデータの暗号化形式です。 デフォルトのセキュア文字列形式はバイトです。

    AMQPサーバ停止通知(AMQP Server Down Notification)

    サービス要求のオーダー時に AMQP サーバが停止した場合に、1 人以上のユーザに通知する電子メール テンプレートを選択します。 システムは、事前、事後、またはメインのタスクのいずれかの電子メール通知を生成します。

    RabbitMQ サーバ上の AMQP タスクとキューの管理

    Prime Service Catalog には、RabbitMQ サーバで管理する代わりに、RabbitMQ サーバ上の AMQP タスク キューへのアクセスを許可する管理ユーティリティが組み込まれています。 このコンソールには、[管理(Administration)] > [ユーティリティ(Utilities)] > [AMQPトピック(AMQP Topics)] からアクセスできます。 使用可能なすべてのタスクを表示し、不要なタスクを削除できます。 次の条件のいずれかに基づいて使用可能なタスクを絞り込むことができます。

    • すべてのやり取り:RabbitMQ サーバ上のすべてのやり取りを列挙します。

    • 使用中のやり取り:進行中またはアクティブ状態にあるサービス要求のやり取りとサービス定義時点のやり取り。

    • 孤立やり取り: サービス定義への参照を含まないやり取りまたは外部システムで作成されたやり取り。

    個人ポップアップ

    [個人ポップアップ(Person Popup)] では、ユーザが個人検索を実行したときに表示される [個人ポップアップ(Person Popup)] ウィンドウに、どのデータを表示するかを設定できます。 個人検索は次の場合に実行できます。

    • 他の個人の代理でオーダーするとき
    • 個人ベースのディクショナリまたは個人タイプ フィールドをサービス フォームで使用するとき
    • ユーザが一時的な代理承認者を選択するとき

    見出しをどのように表示するか、および各フィールドにどの情報を表示するかを指定できます。 デフォルトでは、[名前(Name)] にはその個人の姓名を定義する文字列が表示されます。 個人に関する情報フィールドは、最大 4 つ定義できます。

    [名前(Name)] 以外のフィールドは表示から除外できます。除外するには、カラム見出しおよび対応する個人データを空白にします。

    図 2. 個人ポップアップ

    上記のとおりに [個人ポップアップ(Person Popup)] で定義すると、個人検索ポップアップは次のように表示されます。

    図 3. 検索結果

    Entity Homes

    Entity Homes 機能は、会社の変更管理ポリシーを施行するための手段を提供します。 マルチサイト実装(開発、テスト、および本番)の場合は、特定のエンティティ タイプを修正できる場所を切り分けて、そのエンティティのための記録システムを作成することもできます。 これは、コンテンツ変更を管理するための一般的なアプローチの 1 つです。 たとえば、サービス定義の変更は開発サイト上のみで許可し、Catalog Deployer および関連ツールを使用して変更を本番に昇格させます。 この場合は、サービス定義の記録システム、つまり「ホーム」は開発となります。

    Entity Homes 設定は実質的に、「なし」以外のサイト保護レベルがサイトに割り当てられるまでは単に文書化を行うだけです。

    表 14 Entity Homes

    設定

    説明)

    なし

    このサイト上で保護が有効になりません。

    作成のみ(Create only)

    このサイト上ではホーム以外のエンティティの作成はできません。

    作成、変更(Create, Modify)

    このサイト上ではホーム以外のエンティティの作成や変更はできません。

    作成、変更、削除(Create, Modify, Delete)

    このサイト上ではホーム以外のエンティティの作成、変更、および削除はできません。

    サイト保護レベルによって、Service Designer や Organization Designer でユーザがエンティティを変更するページの外観と動作が決まります。 これは、ロールを介して、または権限の直接割り当てを介してユーザに付与されている機能や権限よりも優先されます。 たとえば、ユーザにサイト内のサービス定義の管理機能が付与されているが、サービス定義に関する Entity Homes 設定ではそのサイトでの更新が許可されていない場合は、そのユーザが更新を行うことはできません。

    Entity Homes モジュールと Catalog Deployer モジュールを組み合わせると、ビジネスの要件を満たす変更管理プロセスとポリシーを確立できます。 Entity Homes のセットアップと Catalog Deployer の使用に関する詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。

    デバッグ設定

    デバッグ設定を使用すると、デバッグ情報を表示するようにシステムを設定できます。これは、問題の診断に役立ち、Cisco Technical Assistance Center(TAC)の参考にもなります。

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

    [デバッグ(Debug)] 設定をオンにすると、標準画面に追加情報が表示されます。 この設定は一般的に、開発環境や QA のインストールで、または一時的に本番インスタンスで作業するときに、それまでに発見された問題の詳細情報を収集する場合にのみ使用します。

    表 15 デバッグの設定

    設定

    説明

    デバッグ(Debug)

    オンにすると、基本的なデバッグ情報がユーザに対して表示されます(現在のページの URL とパラメータや、エラーの場合のスタック トレースなど)。

    ディレクトリマップテスト(Directory Map Testing)

    ディレクトリ統合で使用されるマッピングのテストができるようになります。 詳細については、『Cisco Prime Service Catalog Integration Guide』を参照してください。

    非同期送信メッセージのモニタリング

    メッセージ モニタが使用されるのは、[タスクの非同期送信、承認、および確認(Submit, Approve and Review Tasks Asynchronously)] 設定がオンの場合のみです。 万一 Service Catalog での要求送信やタスク承認要求の非同期処理においてエラーが発生したときは、失敗を示すメッセージが内部のメッセージ モニタ セクションに表示されます。

    表示されたエラー メッセージに基づいて根底にある問題を修正してから、失敗を示すメッセージの処理を再開するには、[再試行(Retry)] をクリックします。

    アプリケーションのロケール

    ローカライズ中に Localization モジュールに新しい言語を追加した場合は、既存および新規のユーザすべてに対して言語の更新を行う必要があります。

    [アプリケーションのロケール(Application Locale)] の設定は、新規ユーザを作成する際の設定に使用されます。 設定して保存した後は、作成されるユーザにこのデフォルト設定が適用されます。 ただし、これらの設定はユーザの作成時に上書きできます。

    アプリケーションのローカライズの詳細については、『Cisco Prime Service Catalog Designer Guide』の「Localizing Service Catalog Strings」の章を参照してください。

    新しい言語および対応する通貨をすべてのユーザに対して有効化するには、次の手順を実行します。


      ステップ 1   [管理(Administration)] > [設定(Settings)] > [アプリケーションのロケール(Application Locale)] を選択します。
      ステップ 2   次のフィールドで適宜選択します。
        • [言語(Language)]:ドロップダウン リストから新しい言語を選択します。
        • [通貨のロケール(Currency Locale)]:対応するロケールを選択します。 たとえば、選択したロケールがドイツ語の場合、金額表示のフォーマット例はドイツ固有のものになります。
        • [金額の通貨記号(Currency Symbol for Money)]:このフィールドでは、金額に通貨記号を表示するかどうかを制御します。
      ステップ 3   [更新(Update)] をクリックします。

      パスワード ポリシー

      悪意ある試みを防ぐ強力なパスワードをアプリケーションに設定する必要があります。 強力なパスワードは、さまざまな脅威や脆弱性からアプリケーションとデータを保護します。 アプリケーションにパスワード ポリシーを適用し、ユーザが強力なパスワードを使用し、頻繁に変更することを推奨します。

      ユーザ管理および認証のために、LDAP またはローカル データベースのいずれかとアプリケーションを統合します。 LDAP ユーザ パスワードは外部システムの一部(つまり、Prime Service Catalog の外部)になり、別個に管理および制御されます。 したがって、LDAP ユーザがシングル サインオンや外部ユーザ認証でログインするときには、これらのパスワード ポリシーは適用されません。

      ユーザの管理にローカル アプリケーション認証を使用している場合、Prime Service Catalog 管理モジュールでパスワード ポリシーを設定して、エンド ユーザがアプリケーションにより安全にアクセスできるようにする必要があります。 パスワードの変更時にアプリケーションによってパスワード ポリシーが適用され、ポリシー違反がある場合はエラー メッセージが表示されます。

      パスワード ポリシーはデフォルトで有効です。 要件に応じてポリシーを変更または無効化できます。 パスワード ポリシーに加えた変更は、次回のログイン検証時にユーザに適用されます。

      ユーザが表 1に記載されているパスワード ポリシーに違反すると、ユーザ アカウントがロックされ、ユーザはパスワードをリセットするためシステム管理者に問い合わせる必要があります。 パスワードのリセットの詳細については、人員の設定を参照してください。

      パスワード ポリシーを設定または更新するには、次の手順を実行します。


        ステップ 1   [管理(Administration)] > [設定(Settings)] > [パスワードポリシー(Password Policies)] を選択します。
        ステップ 2   表 1ごとにポリシーを更新します。
        ステップ 3   [送信(Submit)] をクリックします。
        (注)      [リセット(Reset)] をクリックすると、パスワード ポリシー設定がデフォルト値に戻ります。
        表 16 パスワード ポリシー設定の表

        ポリシー

        説明

        設定のデフォルト値と例

        長さのポリシー

        このポリシーは、パスワードに使用できる文字の最小数および最大数を指定します。

        デフォルト値:

        • [必須の最小長(Minimum Required Length)]は 4 です。
        • [許容される最大長(Maximum Allowed Length)]は 127 です。

        許容される文字数は 4 ~ 127 文字数です。

        これは以下に適用されます。

        • Prime Service Catalo にログオンする際の [パスワードの変更(Change Password)] リンク。
        • [Organization Designer] > [ユーザ(People)] > [一般(General)] からアクセスする [パスワード(Password)] フィールド。

        パスワードの有効期限ポリシー

        このポリシーは、パスワードの変更が必要になるまでの期間を指定します。 目的は、ユーザにパスワードを定期的に変更させることにあります。 通常、セキュリティが非常に重要な場合は短い期間を使用します。セキュリティがそれほど重要でない場合は長い期間を使用します。

        デフォルト値:

        • [パスワードライフタイム(Password Lifetime)]:365 日間
        • [有効期限前の警告期間(Warning Period Before Expiry)]:14 日間
        • [猶予期間(Grace Period)]:3 日間
        • [有効期限で無期限にロックアウトする(Permanently Lockout on Expiry)]:ユーザ アカウントを無期限にロックする場合は、チェックボックスをオンにします。 この場合、ユーザがパスワードをリセットするには、管理者に連絡する必要があります。 表 1で説明されているように、[IsLocked] フィールドを選択解除した後に、管理者がパスワードをリセットできます。

        次に例を示します。

        • [パスワードライフタイム(Password Lifetime)]:10 日間
        • [有効期限前の警告期間(Warning Period Before Expiry)]:3 日間
        • [猶予期間(Grace Period)]:2 日間

        ユーザが 4 月 20 日にパスワードを更新したとします。

        • パスワードの有効期限は 4 月 30 日です。
        • ユーザは 4 月 27 日に警告メッセージを受け取ります。
        • ユーザ アカウントは 5 月 2 日までアクティブで、5 月 3 日から、ユーザが自分のパスワードをリセットするまでロックされます。

        これは以下に適用されます。

        • HTTPS/WS 受信アダプタ
        • SIM タスク受信
        • タスク サービス SOAP/RAPI
        • ユーザ インターフェイス、NSAPI、および RAPI を介したユーザ ログイン

        再試行ポリシー

        • このポリシーは、ユーザ アカウントがロックアウトされるまでに、ユーザが無効なパスワードでアプリケーションへのログインを試行できる最大回数を指定します。
        • また、ユーザがパスワードをリセットするまでに、ユーザ アカウントをロックする回数も設定できます。 ユーザはロックされている期間中にパスワードをリセットできません。また、パスワードのロックを解除するには、システム管理者に連絡する必要があります。

        ユーザ パスワードのリセットの詳細については、人員の一般情報の [ログインしたユーザのパスワード(LoggedIn User Password)] フィールドを参照してください。

        デフォルトの値は次のとおりです。

        • [ロックアウト期間(Lockout Period)]:15 分間。

        [ロックアウト期間(Lockout Period)] にその他の値を設定するには、ドロップダウン リストから値を選択します。 [無期限ロックアウト(Permanent Lockout)] を選択している場合、ユーザ アカウントを無期限にロックする場合は、チェックボックスをオンにします。 この場合、ユーザがパスワードをリセットするには、管理者に連絡する必要があります。 表 1で説明されているように、[IsLocked] フィールドを選択解除した後に、管理者がパスワードをリセットできます。

        • [失敗試行回数(Unsuccessful Attempts)]:5

        たとえば、4 回目の失敗時にユーザ アカウントがロックされ、ユーザは 15 分間アプリケーションにアクセスできません。

        これは以下に適用されます。

        • HTTPS/WS 受信アダプタ
        • SIM タスク受信
        • タスク サービス SOAP/RAPI
        • ユーザ インターフェイス、NSAPI、および RAPI を介したユーザ ログイン

        パスワード評価ポリシー

        パスワードの強度を定義します。 パスワードのリセット時に、アプリケーションはパスワードの強度を判別し、そのパスワードが最小強度の基準を満たしていない場合に、エラー メッセージを表示します。

        パスワード評価ポリシーは、「NIST SP 800-63」標準から派生し、正規表現を使用します。

        (注)      NIST SP800-63 におけるディクショナリ チェックのエントロピーは考慮されません。

        アプリケーションは、Regex に記載されている正規表現に基づいて、[最初の位置(First Position)] の文字位置から [最後の位置(Last Position)] の文字位置までパスワードを評価します。 パスワードのスコアは合計スコア値から算出されます。これが [最小パスワード強度(Minimum Password Strength)] の値以上である場合、アプリケーションはパスワードを受け入れます。

        デフォルト値は表 2に記載されています。

        [最初の位置(First Position)]:評価する最初の位置を入力します。アプリケーションは [最初の位置(First Position)] で指定されている n 番目の文字から評価します(この n はパスワードの文字位置を定義する整数です)。

        [最後の位置(Last Position)]:評価時に考慮する最後の位置を入力します。アプリケーションは [最後の位置(Last Position)] で指定されている x 番目の文字で評価を停止します(この x はパスワードの文字位置を定義する整数です)。

        [Regex]:アプリケーションが評価する必要のある正規表現を入力します。

        [スコア(Score)]:パスワードのスコアを定義します。 アプリケーションは、最初の位置から最後の位置までの文字について、Regex が真と評価された場合にスコアを適用します。

        [スコアタイプ(Score Type)]:スコア タイプが次のいずれであるかを選択します。

        • [文字ごと(Per Character)]:最初の位置から最後の位置までの文字数でスコアが乗算されます。
        • [固定長(Fixed Length)]:スコアは評価対象となる文字に対して定義したとおりになります。

        [推奨される最小パスワード強度(Minimum Password Strength Recommended)]:スコア値を入力します。 パスワードは受け入れられる合計スコア値以上である必要があります。 デフォルト値は 12 です。

        [説明(Description)]:[設定(Configuration)] 表に入力した値は、ユーザが理解できるように書き換えられます。

        さらに行を追加してパスワード評価ポリシーを設定する場合、[追加(Add)] をクリックします。

        これは、Organization Designer、ディレクトリ統合のインポート イベント、および提供計画で使用可能なディレクトリ タスクを介して実行されるパスワードの変更やユーザの更新に当てはまります。

        表 17 パスワード評価ポリシーのデフォルト設定表

        行番号

        最初の位置

        最後の位置

        Regex

        スコア

        スコア タイプ

        1

        1

        1

        .

        4

        文字ごと(Per Character)

        2

        2

        8

        .

        2

        文字ごと(Per Character)

        3

        9

        20

        .

        1.5

        文字ごと(Per Character)

        4

        21

        文字列の末尾

        .

        1

        固定長(Fixed Length)

        5

        1

        文字列の末尾

        [^a-z]+

        6

        固定長


        パスワード評価ポリシーの例

        Catalog@2014 というパスワードについて検証します。 表 1の表に、表 2に記載されている設定に基づいてパスワード評価ポリシーを計算する方法を示します。

        表 18 パスワード評価ポリシーの例

        行番号

        最初の文字位置と最後の文字位置

        文字

        文字タイプ別のスコア

        合計得点

        1

        1 から 1 まで

        C

        文字単位で 4 点

        4

        2

        2 から 8 まで

        atalog@

        文字単位で 2 点

        14

        3

        9 から 20 まで

        2014

        文字単位で 1.5 点

        6

        4

        21 から文字列の最後まで

        パスワードは 20 文字以上にならないため考慮されません。

        1

        0

        5

        1 から文字列の最後まで

        Catalog@2014

        6

        6

        合計スコア = 30 は 12、つまり、推奨最小パスワード強度を超えています。

        結果:受け入れ可能なパスワード

        データ ソース レジストリ

        Service Catalog は、データ ソース レジストリで定義されたデータ ソースを使用して、アプリケーションにアクセスしたり、リレーショナル データベースに保存されたユーザ データにアクセスしたりします。 デフォルトで、Service Catalog インスタンスには 2 つのデータ ソースがあります。1 つはトランザクショナル データへのアクセス用で、もう 1 つはデータ マートおよびレポーティングのオプションへのアクセス用です。 加えて、管理者は外部ディクショナリ、SQL オプション リスト、アクティブ フォーム データ取得ルールなどのコンポーネントをサポートするための追加データ ソースを作成できます。

        データ ソース レジストリには、使用可能なすべてのデータ ソースが一覧表示されます。 データ ソースを作成するには、『Cisco Prime Service Catalog Installation and Upgrade Guide』を参照してください。

        サポート ユーティリティ

        次のサポート ユーティリティがあります。


        (注)  


        サポート ユーティリティを表示して使用するには、[サポートユーティリティの使用(Use Support Utilities)] 機能がユーザに対して有効になっている必要があります(Administration の機能を参照)。

        ログとプロパティ

        選択されていない場合は、[ログとプロパティ(Logs and Properties)] をクリックして、[ログとプロパティ(Logs and Properties)] ページを表示します。


        (注)  


        ログとプロパティを表示して使用するには、「サポート ユーティリティの使用」機能と「ログとプロパティ ファイルへのアクセス」機能が有効になっている必要があります(Administration の機能を参照)。
        ログおよび宛先フォルダの設定

        ログおよびプロパティを使用するには、アプリケーション サーバのログ フォルダを指定する必要があります。 また、圧縮済み Zip ファイル(ログおよびプロパティのファイルが格納されます)を保存するための宛先フォルダも作成して指定する必要があります。実行後に、ここからファイルを削除します。 ファイル タイプごとに別の宛先フォルダを作成して指定できます。

        宛先およびログ フォルダを指定するには、次の手順を実行します。


          ステップ 1   新しい宛先フォルダを 1 つ(またはファイル タイプごとに 1 つずつ)作成します。 このフォルダは任意の場所に配置できます。
          ステップ 2   宛先フォルダの場所と最大サイズの指定は、support.properties ファイルで行います。 2 つの support.properties ファイルがあります。1 つは Service Catalog 用で、もう 1 つは Service Link 用です。

          これらの support.properties ファイルの場所は、次の展開済みディレクトリです。

          • Service Catalog:RequestCenter.war/WEB-INF/classes/config/
          • Service Link:ISEE.war/WEB-INF/classes/config
          (注)      上記のパスは、Linux 環境用です。

          support.properties ファイルをテキスト エディタで開きます。

          Linux 環境の support.properties ファイルの例を次に示します。

          (注)      Service Catalog の support.properties ファイルの場合は、Service Catalog のエントリのみが使用され、Service Link のエントリは無視されます。 Service Link の support.properties ファイルの場合は、Service Link のエントリのみが使用され、Service Catalog のエントリは無視されます。 大きなファイルが圧縮された場合のアプリケーションのクラッシュを防ぐために、宛先フォルダはアプリケーションのインストール ディレクトリの外に配置する必要があります。

          図 5. プロパティのサポート

          ステップ 3   宛先フォルダのフル ディレクトリ パスを「*.destinationFolder.location」パラメータに対して入力します。 UNIX/Linux の場合は、スラッシュを 1 つだけ使用してディレクトリを区切ります。たとえば、/opt/CiscoServicePortal/RC_log_dest となります。 Windows の場合は、二重バックスラッシュを使用してディレクトリを区切ります。たとえば、C:\\CiscoServicePortal\\RC_log_dest となります。

          上記の例では、

          「C:\\CiscoServicePortal\\RC_log_dest」が Service Catalog のログ ファイルの宛先フォルダとして設定されます。

          ステップ 4   WebLogic サーバの場合は、アプリケーション サーバのログ ディレクトリのフル ディレクトリ パスを「*.log.location」パラメータに入力します。 JBoss の場合は、「*.log.location」パラメータをブランクのままにしてください。
          ステップ 5   宛先フォルダの最大サイズを「*.destinationFolder.size.limit」パラメータで設定します。 宛先フォルダの最大サイズの単位は GB です。 端数も使用できます。 たとえば、500 MB 使用する場合は 0.5 と入力し、250 MB の場合は 0.25 と入力します。 このフォルダ内のファイルがこのサイズを超過すると、エラー メッセージが表示されます。

          上記の例では、

          1 によって宛先フォルダの最大サイズが 1 GB に設定されます。

          ステップ 6   support.properties ファイルを保存します。
          ステップ 7   Service Catalog サーバを再起動します。

          ファイルの表示とダウンロード

          ファイルを表示およびダウンロードするには、次の手順を実行します。


            ステップ 1   [ログおよびプロパティ(Logs and Properties)] ページで、ファイル タイプを左上のドロップダウン メニューから選択します。

            選択できるファイル タイプは 4 つあります。

            • Service Catalog:ログ ファイル

            • Service Link:ログ ファイル

            • Service Catalog:プロパティ ファイル

            • Service Link:プロパティ ファイル

            ステップ 2   上部ペインのファイルをクリックして選択します。 必要に応じて、[更新(Refresh)] をクリックして最新のファイルを表示します。
            ステップ 3   ファイルを表示するには、最後の何行を表示するかを上部ペインの下部にあるドロップダウン メニューで選択してから、[表示(View)] をクリックします。

            ファイルがポップアップ ウィンドウで開きます。

            ステップ 4   [閉じる(Close)] をクリックしてウィンドウを閉じます。
            ステップ 5   選択したファイル(複数のファイルを選択するには Ctrl キーを押した状態でクリックします)を特定の場所にダウンロードするには、[圧縮(Compress)] をクリックします。
            ステップ 6   下部ペインで [更新(Refresh)] をクリックすると、下部ペインに圧縮ファイルが表示されます。 ファイルは Zip 形式で圧縮され、タイム スタンプが名前に追加されます。 ファイルが複数の場合は、Zip ファイルが 1 つだけ作成され(名前はファイル タイプとタイム スタンプのみから生成されます)、選択したファイルすべてがこの中に格納されます。
            (注)      同じファイルが再び圧縮された場合は、異なるタイム スタンプの新しいファイルが作成され、以前の圧縮ファイルは上書きされません。
            ステップ 7   下部ペインで、1 つのファイルのダウンロード アイコンをクリックします。

            [ファイルのダウンロード(File Download)] ダイアログ ボックスが表示されます。 [保存] をクリックします。

            ステップ 8   場所を選択してファイルを保存するための [名前を付けて保存(Save As)] ダイアログ ボックスが表示されます。
            ステップ 9   希望する場所まで移動して、[保存(Save)] をクリックします。
            ステップ 10   ファイルを保存した後で、選択した圧縮ファイル(複数のファイルを選択するには Ctrl キーを押した状態でクリックします)を下部ペインから削除するには、[削除(Delete)] をクリックします。

            消去ユーティリティ

            [管理(Administration)] > [ユーティリティ(Utilities)] > [消去ユーティリティ(Purge Utilities)] を選択して [消去ユーティリティ(Purge Utilities)] を表示します。


            (注)  


            [消去ユーティリティ(Purge Utilities)] を表示して使用するには、[サポートユーティリティを使用する(Use Support Utilities)] と [消去ユーティリティにアクセスする(Access Purge Utilities)] の両方の機能がユーザに対して有効になっている必要があります(Administration の機能を参照)。

            3 種類の消去ユーティリティを以下に示します。

            • [要求(Requisition)] - この要求消去ユーティリティは、選択された日付より古い要求、またはユーザが指定したその他の基準に一致する要求を削除します。 これを使用すると、アプリケーション管理者はテスト ユーザやサンプル サービスを削除する前にテスト要求を削除することができます。 また、保持する必要がなくなった古い要求を削除するなど、データベース サイズを制御するハウスキーピングの目的で要求消去ユーティリティを使用することもできます。 ただし、要求消去ユーティリティは、一括データ削除には適していません。その他のアプリケーション ユーザのシステム応答時間に影響を及ぼさないように注意して使用する必要があります。

            要求消去ユーティリティによって、タスクと Service Link メッセージを含め、消去フィルタ条件を満たす要求とそれらの要求に関連付けられたすべてのトランザクション データが削除されます。 RequestCenter データベースの LogPurge テーブルには実際の要求消去の結果も追加されます。

            • [Service Link] – Service Link 消去ユーティリティはデータベースからの nsXML メッセージを削除します。 これらのメッセージは(サービス フォームの複雑さおよびエージェントの設定に使用されるコンテンツ タイプ オプションに応じて)きわめて大きくなる可能性があるため、メッセージを削除することにより、Service Link 関連のデータを保持するために必要なデータベース サイズが大幅に削減されます。
            • [Business Engine] – Business Engine 消去ユーティリティは、ワークフロー処理に関連するデータベースからの一時データを削除します。 このデータが本番環境で使用されなくなった場合は、これらを削除することによりデータベースのサイズを小さくすることができます。 また、この消去ユーティリティを定期的に実行すると、全体的なパフォーマンスが改善される可能性があります。

            データベースの規模が大きい場合、Business Engine 消去ユーティリティの実行には 1 時間以上かかる場合があります。 したがって、アクティビティが少ない時間帯に消去を行う必要があります。 データベースでユーティリティの実行にかかる時間を確認するために、サンドボックス環境でのテスト実行が推奨されます。

            消去を実行するには、次の手順を実行します。


              ステップ 1   [要求(Requisition)]、[Service Link]、または [Business Engine] の横にあるオプション ボタンをクリックして消去の種類を選択します。
              ステップ 2   消去するデータをフィルタリングする日付範囲を入力します。 要求消去の場合、オプションで [要求ID(Requisition ID)]、[要求ステータス(Requisition Status)]、および [サービス名(Service Name)] によってデータをフィルタリングすることもできます。
              ステップ 3   (オプション)要求消去を実行する前に、[分析(Analyze)] をクリックして「リハーサル」消去を実行します。 [OK] をクリックして、先へ進みます。 これによって、実際には削除を行わず、削除される要求を確認できます。 これは、フィルタ条件が有効であることを検証する役割を果たします。 ステップ 7 に進みます。
              ステップ 4   [消去(Purge)] をクリックして、消去を開始します。
              ステップ 5   [はい(Yes)] をクリックして続行します。
              ステップ 6   消去が開始されます。 [OK] をクリックします。
              ステップ 7   一定時間が経過した後に [更新(Refresh)] をクリックします。 消去または分析が完了すると、新しい日時エントリが、[消去履歴(Purge History)] ペインのリスト上部に追加されます。 新しい消去完了日時エントリを表示するには、画面を更新する必要があります。
              ステップ 8   [消去履歴(Purge History)] ペインで、消去完了日時エントリをクリックし、右側の [ログコンテンツ(Log Content)] ペインにある消去または分析情報を確認します。
              ステップ 9   要求消去の分析を実行した場合(ステップ 3)、前述のステップ 4 に戻り実際の消去を開始します。

              消去を実行する際のパフォーマンスに関する考慮事項

              消去は Service Catalog アプリケーションの稼働中に実行できます。 ただし、ピーク時間は消去操作の数を制限し、代わりに時間外に大量の消去を行うよう計画する必要があります。

              スケジュール実行可能な SQL スクリプトやバッチ プログラムの消去ユーティリティもあります。 詳細については、消去と分割によるパフォーマンスの最適化 を参照してください。

              バージョン履歴

              [管理(Administration)] > [ユーティリティ(Utilities)] > [バージョン履歴(Version History)] をクリックすると、[バージョン履歴(Version History)] ページが表示されます。


              (注)  


              バージョン履歴を表示および使用するには、[サポートユーティリティ(Use Support Utilities)] と [バージョン履歴へのアクセス(Access Version History)] の両方の機能がユーザに対して有効になっている必要があります(Administration の機能を参照)。

              [バージョン履歴(Version History)] ページには、Service Catalog の現在の製品バージョン番号と、ビルドのアップグレードおよびパッチのバージョン履歴が表示されます。

              Form Data Viewer

              Form Data Viewer ページを表示するには、[管理(Administration)] > [ユーティリティ(Utilities)] > [Form Data Viewer] の順にクリックします。


              (注)  


              Form Data Viewer を表示して使用するには、ユーザの「サポート ユーティリティの使用」と「Form Data Viewer へのアクセス」の両方の機能を有効にする必要があります(Administration の機能を参照)。

              主に、サービス設計者がサービスの設計を検証するために使用する Form Data Viewer では、保存または送信された要求内で実際にサービス フォームに保存された値を確認することができます。 これは、フォームのロード中にサービス フォームに関連付けられたフォーム ルールが適用されている場合に役に立ちます。 この場合、ユーザ インターフェイスに表示されている内容は、保存されている実際の内容を反映していません。

              下の表の保存された値を表示するには、要求エントリ番号を入力して、[取得(Retrieve)] をクリックします。 値を Excel スプレッドシートにエクスポートしてさらに分析するには、[Excelにエクスポート(Export to Excel)] をクリックします。

              要求エントリ番号は、My Services の [サービスの編集(Edit Service)] ページまたは [サービスステータス(Service Status)] ページを開いている間のブラウザ URL で確認できます。 これは、「reqentryid」として示されています。

              不達電子メール

              [不達電子メール(Undelivered Email)] ユーティリティは、受信者に配信されなかった承認、確認、または通知メールのリストを提供します。 不達電子メールを適切に確認、再送信、または削除できます。

              不達電子メールを再送信するには、次の手順を実行します。


                ステップ 1   [管理(Administration)] > [ユーティリティ(Utilities)] > [不達電子メール(UnDelivered Email)] を選択します。
                ステップ 2   要求 ID をクリックするか、[検索(Search)] タブを使用して要求を検索します。
                ステップ 3   [メッセージ(Message)] ウィンドウでメールを確認します。
                ステップ 4   [Resend(再送信)] をクリックします。

                プロセスの実行

                このユーティリティを使用して、履歴要求を一時的に履歴データ テーブルに移行できます。 オフピーク期間の手動移行プロセスによって、システムのオーバーヘッドが減少します。

                newscale.properties ファイルで設定されている値が、締切日、バッチ サイズ、および最大要求数の各フィールドに表示されます。 設定をさらに編集してから、[開始(Start)] をクリックしてスケジューラを有効にすることができます。

                処理の速度と時間は、要求の平均サイズによって異なります。 本番環境で移行プロセスを実行する前に、データベース管理者と協力して試験実行を行い、初回の実行にかかる時間を見積もってください。 詳細については、消去と分割によるパフォーマンスの最適化を参照してください。

                移行プロセスを開始するには、次の手順を実行します。


                  ステップ 1   [管理(Administration)] > [ユーティリティ(Utilities)] > [プロセスの実行(Run Processes)] を選択します。
                  ステップ 2   カレンダーを使用して締切日を選択します。
                  ステップ 3   バッチ サイズと処理できる最大要求数を入力することもできます。
                  ステップ 4   [開始(Start)] をクリックして移行プロセスを開始します。

                  [管理(Administration)] > [設定(Settings)] タブの [履歴要求スケジューラの有効化(Enable Historical Requisitions Scheduler)] の設定がオフになっていることを確認してください。 履歴移行を処理するには、履歴スケジューラを有効にする方法と、プロセス実行ユーティリティを使用する方法のいずれかを選択できます。


                  移行プロセスの停止

                    ステップ 1   [管理(Administration)] > [ユーティリティ(Utilities)] > [プロセスの実行(Run Processes)] を選択します。
                    ステップ 2   [停止(Stop)] をクリックして、スケジューラまたはユーティリティを使用して有効にした移行プロセスを終了します。

                    サービス設計の変更履歴の有効化

                    複数のユーザがアクティブ フォームでサービスを作成する場合、各ユーザが実行した変更内容を把握することは困難です。 Prime Service Catalog では、[サービス設計の変更履歴(Service Design Change History)] オプションを使用して、サービス設計でのそれらの変更を追跡できます。 これによって、Service Designer でユーザが変更の詳細にアクセスできるようになります。 サービス設計の変更履歴を追跡する方法の詳細については、『Cisco Prime Service 11.0 Catalog Designer Guide』を参照してください。

                    [サービス設計の変更履歴(Service Design Change History)] オプションを有効および無効にするには、特定のロールの権限が必要です。

                    (注)  


                    Oracle データベースを使用する Prime Service Catalog のインストールでは、このタブにアクセスできません。 これは、Oracle が変更データ キャプチャ機能のサポートを停止したためです。


                    はじめる前に

                    Prime Service Catalog をインストールした後で、以下のスクリプトを実行します。

                    • SQL の場合、次を実行します。AuditLogAdministrationScript-SQL.Sql

                    これらのスクリプトは、インストール ディレクトリ /schema の下のユーティリティ フォルダで使用できます。

                    サービス設計の変更履歴を有効または無効にするには、次の手順を実行します。


                      ステップ 1   [管理(Administration)] > [ユーティリテ(Utilities)] > [サービス設計の変更履歴(Service Design Change History)] を選択します。
                      ステップ 2   サービス設計の変更履歴を有効または無効にする特権を持つユーザのデータベース資格情報のユーザ名パスワードを入力します。
                      ステップ 3   変更履歴のキャプチャを開始するには [有効化(Enable)] をクリックし、変更履歴のキャプチャを停止するには [無効化(Disable)] をクリックします。


                      (注)  


                      サービス設計の変更履歴を無効にすると、Prime Service Catalog はアーカイブされたデータをデータベースから削除します。

                      SQL クライアントから変更履歴を手動で有効または無効にできます。 SQL Server の変更履歴を手動で有効または無効にする方法の詳細については、MSDN ライブラリを参照してください。