この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章は次のトピックで構成されています。
会社のルールやビジネス プラクティスに合わせて Administration モジュールのさまざまな振る舞いをセットアップすることができます。
Administration モジュールから次のようなタスクを実行できます。
ディレクトリとは、ユーザ データのリポジトリのことです。 Administration では、エンタープライズ ディレクトリなどのユーザ データのソースにリンクしてそのソースからのデータを利用するようにシステムを設定できます。 具体的には、ユーザ プロファイル情報をディレクトリ サーバ データベースと同期させることができます。
ディレクトリ統合の詳細(統合に必要な情報を整理するためのワークシート、詳細なマッピング情報、特別な考慮事項など)については、『Cisco Prime Service Catalog Integration Guide』を参照してください。
Administration モジュールの [承認(Authorizations)] タブで、承認と確認の有効化および無効化と、サイト全体の承認のセットアップができます。 このようなサイト全体の承認は、個々の組織やサービスまたはサービス グループに対して確立済みの承認に加えて、またはその代わりとして使用できます。
承認は、割り当てられた承認者に対してサービス要求の拒否または承認を求めるタスクです。 確認は、実行者に対して提供プロセスのステップの確認を求めるタスクです。
Service Catalog では、複数のタイプの承認と確認をサポートしています。
ファイナンシャル承認 |
要求されたサービスまたは項目が予算内であるかどうかを判断する承認。 この承認は、組織単位レベルでは上書きできません。 |
部門承認 |
事業単位マネージャによる購買承認のための承認。 |
部門確認 |
部門で要求されたサービスまたは項目が適切であるかどうかの確認。 |
サービス グループの承認 |
サービス チーム マネージャによる購買承認のための承認。 通常、サービス チーム マネージャは、自分のサービス チームに所属する人を承認します。 |
サービス グループの確認 |
サービス グループで要求されたサービスまたは項目が適切であるかどうかの確認。 |
承認プロセスの設定は、次の 3 つの手順で構成されます。
Administration モジュールの [承認(Authorizations)] タブで、1 つのサイトに対して最大 5 つの承認タイプを有効にできます。
承認タイプのステータスを変更するには、変更する承認タイプの [アクション(Action)] 列で [編集(Edit)] をクリックし、[ステータス(Status)] ドロップダウン メニューから [有効化(Enable)] または [無効化(Disable)] を選択します。 実行順序を変更するには、[アクション(Action)] 列で上矢印または下矢印をクリックして正しい順序にします。
承認または確認のタイプが有効になっている場合は、このタイプに対して詳細を指定できます。 承認の詳細は、次のように定義できます。
Departmental Authorizations/Reviews の場合、次の選択肢があります。
Service Group Authorizations/Reviews の場合、次の選択肢があります。
[サイトの承認構造のみを使用(Use site authorization structure only)] または [サービス グループの承認構造を使用(Use service group authorization structure only)] オプションを選択した場合、それ以上の手順は必要ありません。 それ以外の場合は、設定する承認タイプを選択できます。
(注) |
すべての承認タスクと確認タスクは、提供プロセスが開始する前に完了する必要があります。 |
Administration モジュールの [承認(Authorizations)] タブで、編集する承認または確認の横にある [アクション(Actions)] カラムの [編集(Edit)] をクリックします。 選択する承認タイプに基づいて、[承認 – 逐次的プロセス(Authorizations – Sequential Process)] または [確認 – 同時プロセス(Reviews – Concurrent Process)] サブタブが表示されます。
次の表に、[詳細(Details)] 画面のフィールドを示します(これらのサブタブの [追加(Add)] をクリックした後、またはサブタブの [名前(Name)] フィールドの左にあるチェックボックスをクリックして定義済みの承認/確認ロールを選択した後に表示されます)。 [更新(Update)] をクリックして変更を保存します。 アスタリスク(*)の付いたフィールドは必須フィールドです。
フィールド |
説明 |
---|---|
名前(Name)* |
承認者または確認者によって実行されている新しい役割の名前。 |
期間(Duration)* |
タスクの承認または確認に割り当てられる時間(時間単位)。 |
件名(Subject)* |
この役割が実行する承認タスクまたは確認タスクの名前。 この値は、Service Manager で承認者または確認者に対して [タスクリスト(Task List)] に表示されます。 タスクのタイトルには名前空間変数を使用できます。 ハッシュ マーク(#)で囲まれた文字列は、名前空間変数であることを示します。 この変数は、オーダー中のサービス名で置き換えられます。 詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。 |
実行(Effort)* |
確認または承認の実行所要時間。 通常、[時間(Duration)] よりも小さい値になります。 |
ワークフロータイプ(Workflow Type) |
承認者がシステム内のユーザである場合は、[internal] を選択します。または、使用可能な外部ワークフローを選択して、Service Link タスク経由で承認を実行します。 |
Assign |
ドロップダウン メニューから、次のいずれかを選択します。 |
割り当て先(Assign to) |
をクリックして、[割り当て(Assign)] フィールドの選択内容に対応する値を選択します。 [式から(From an expression)] を選択した場合は、式を入力します。 式の構文については、『Cisco Prime Service Catalog Designer Guide』を参照してください。 |
エスカレーション階層(Escalation Tiers) |
次のいずれかをクリックします。 |
条件 |
承認するために満たす必要がある条件を含む式。 True または False を使用して、タスクが発生するかどうかを示します。 式を入力しない場合は、デフォルト値が True になり、承認が常に実行されます。 使用している式が動作することを検証するには、[確認(Validate)] をクリックします。 検証では構文チェックのみが実行され、参照データが実際に要求に存在するかどうかはチェックされません。 |
次の場合に条件を評価(Evaluate condition when) |
次のいずれかを選択します。
|
承認/確認が進むときに式を再評価(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) |
エスカレーションとは、指定された期間内に実行されなかったアクティビティにフラグを立て、解決のために適切な実行者、スーパーバイザ、または顧客に送信するプロセスのことです。 受信者は、遅延タスクの通知を電子メール形式で受け取ります。
エスカレーション プロセスをセットアップする場合は、次の点に注意してください。
実際には、エスカレーションは、ワークフロー マネージャである Business Engine の一部である Escalation Manager によって送信されます。 デフォルトでは、通常の勤務時間中に、関連するエスカレーションが指定された遅延タスクが、Escalation Manager により 1 時間に 1 回(正時)チェックされます。 したがって、上記で示しているように、承認が指定時間遅れた後で電子メール通知が送信されるというのは必ずしも正確でありません。 通知が実際に送信されるのは、エスカレーション期間が期限切れとなった後で Escalation Manager による遅延タスクのチェックが次に行われたときです。 たとえば、承認が午後 12:30 に予定されており、エスカレーション通知をその 1 時間後(午後 1:30)に送信するよう設定されている場合、通知が実際に送信されるのは、Escalation Manager の実行が次に行われる午後 2 時となります。
管理者は、Escalation Manager の設定を変更できます。 詳細は、Prime Service Catalog の保守を参照してください。
Service Catalog には、事前設定の電子メール テンプレートのセットが含まれています。 発生したイベントへの応答として自動的にテンプレートを送信するように、サービスの提供計画をセットアップできます。 Administration モジュールでは、電子メール通知に使用されるテンプレートを新規に作成したり、提供されたテンプレートを修正したりすることができます。 この電子メールは、受信者に承認と提供のプロセス中のステップを通知するのに使用されます。
Service Catalog で使用されるテンプレートは、[全般(General)] リンクの下にあります。 Demand Center で使用されるテンプレートは、[契約電子メールテンプレート(Agreement Email Templates)] の下にあります。 発生したイベントへの応答として自動的にテンプレートを送信するように、Administration を設定できます。 たとえば、あるサービスでマネージャからの承認が必要であるときに、システムからこのマネージャに、サービス要求の承認が必要であることを通知する電子メールを送信できます。 付属のテンプレートを変更することも、組織に適したテンプレートを追加することもできます。
電子メール テンプレートの情報を表示するには、次の方法のいずれかを使用します。
テンプレート名をクリックすると、テンプレートのスタイル設定オプションと内容が表示されます。 次に示すのはサンプルの Service Catalog テンプレートです。
電子メール テンプレートを設定するには、次の情報を入力します。
フィールド |
説明 |
---|---|
[名前(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)] タブを使用して、次のリストを設定します。
リスト名 |
説明 |
---|---|
コスト ドライバ |
コスト ドライバは、Service Designer でサービスのコスト詳細を設定するときに使用できます。 |
目的 |
目標リストは、Service Designer で目標を作成するときにドロップダウン リストで使用可能な目標基準の設定に使用されます。 |
測定単位(Unit of Measure) |
測定単位は、Service Designer で目標を設定するときに基準と組み合わせて使用されます。 |
[言語(Language)] |
言語リストは、ユーザ プロファイルや個人情報内の [表示言語(Preferred 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)] タブに表示されるオプションは次のとおりです。
ページ |
説明 |
---|---|
さまざまなモジュールの、サイト全体の設定を指定します。 |
|
個人検索の実行時に表示される情報のタイプを設定します。 |
|
同じ実装の各サイト上で修正可能な定義データを指定します。 |
|
デバッグ情報をユーザ インターフェイス内に表示するかどうかを指定します。 |
|
すべての新規ユーザーが更新された言語および対応する通貨を使用するようにします。 |
|
パスワード設定のポリシーを定義します。 |
|
適用する組織を定義および指定します。 |
|
アプリケーションに登録されているデータ ソースが表示されます。 |
カスタマイゼーションを使用すれば、組織の業務慣習に合わせてオプションを設定できます。 カスタマイゼーション設定は、影響を受けるモジュールや各設定によって付与される機能に応じて、いくつかのグループに分かれています。
カスタマイゼーションに使用できる値は次のとおりです。
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)] の設定をオンにする必要があります。
オーダーの失敗 E メール テンプレート |
オーダー送信プロセスが予期せず異常終了したときに送信される電子メール。 このエントリが効力を持つのは、[非同期でのタスクの送信、承認、および確認(Submit, Approve and Review Tasks Asynchronously)] の設定がオンの場合のみです。 |
承認の失敗 E メール テンプレート |
ユーザが実行した承認または確認のタスクが予期せず異常終了した場合に送信される電子メール。 このエントリが効力を持つのは、[非同期でのタスクの送信、承認、および確認(Submit, Approve and Review Tasks Asynchronously)] の設定がオンの場合のみです。 |
この設定は、本番環境においてほとんど変更されることのないアプリケーション ファイルをブラウザ キャッシュに格納できるようにします。 この機能を使用すると、キャッシュ済みのオブジェクトが利用されるため、遠隔地にいるユーザのページ読み込み時間が大幅に改善される可能性があります。リフレッシュが要求されるのは、バージョンの変更が検出されたときのみです。
ブラウザ キャッシュが有効な場合は、最後にアクセスされたバージョンを記録するための Cookie がブラウザ クライアント内に作成されます。次のタイプのオブジェクトについては、キャッシュされたバージョンをアプリケーションで利用できます。
アプリケーション変更イベントが発生した場合(たとえば、変更されたイメージを持つサービスを Catalog Deployer を使用して展開するなど)、管理者はバージョン番号を増加させることで、ユーザにブラウザ キャッシュの削除を要求することができます。
ユーザのブラウザ Cookie に記録されているバージョンが、[管理(Administration)] 設定のものと異なる場合は、ユーザにブラウザ キャッシュの削除を要求する通知が表示されます。 ブラウザ キャッシュが削除されたら、[再ログイン(Login Again)](シングル サインオンが有効な場合は [続行(Continue)])をクリックしてアプリケーションにアクセスできます。
アプリケーションのインストール時に、JMS ユーザ名とパスワードの値が初めて収集されます。 それ以降にアプリケーション サーバ側でクレデンシャルが変更された(企業のパスワード ポリシーやその他の要件で必要とされたため)場合は、更新された値をここに入力して、Prime Service Catalog アプリケーションが JMS キューへのアクセスを継続できるようにする必要があります。
VSOC の設定は VSOC ソリューションに使用されます。シスコの指示がない限り、変更しないでください。
AMQP ユーザ名とパスワードを他の AMQP 設定と一緒に使用して、RabbitMQ サーバとの接続を確立することができます。 AMQP 公開キーは重要なフィールドを保護するために使用されます。この保護されたフィールドは対応する秘密キーを使用して外部システムで復号化されます。 AMQP セキュア文字列形式はデータの暗号化形式です。 デフォルトのセキュア文字列形式はバイトです。 外部システムにサービス要求を発行するための AMQP タスクの設定方法については、『Cisco Prime Service Catalog 11.0 Designer Guide』を参照してください。
(注) |
一度に接続可能な AMQP は 1 つだけです。 |
共通設定は、複数のモジュールの振る舞いに影響を及ぼします。
カスタムヘッダーフッターの有効化(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 によってサービスが展開されるときに、そのサービスで参照される標準の定義(一般的には、データ取得ルールの形を取ります)が自動的に展開され、その標準に対応するエントリ(データ)も展開されます。 [標準テーブルのエントリ(データ)の展開(Deploy Entries (data) in Standards Tables)] 設定を使用すると、この動作をオーバーライドすることができます。 [いいえ(No)] に設定されている場合は、Catalog Deployer によって標準データがターゲット環境に展開されることはありません。 ターゲット環境へのデータ読み込みには別の方法(Lifecycle Center を使用して手作業で入力するか、標準データをインポートする)が使用されると想定されます。
詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。
My Services の設定は、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 は、サービス フォームの右側に表示されます。 ここには、フォーム内のディクショナリが表示されます。 ディクショナリのチェックが行われるのは、そのディクショナリ内のすべての必須フィールドに値が入力されたときです。 必須フィールドのステータス チェックは、グリッド ディクショナリには適用されません。
サービス フォームの表示後にディクショナリがルールまたは ISF コードによって非表示にされると混乱を招くおそれがあります。そのディクショナリは引き続き Form Monitor に表示されているためです。
[承認(Authorizations)] ポートレットでは、現在のユーザに割り当てられたすべての承認をすばやく表示してアクセスできます。 承認を表示可能なユーザの場合は、このポートレットが [マイサービス(My Services)] 画面の左側に表示されます。
[承認(Authorizations)] ポートレットは、最新の 5 つの承認のクイック ビューと現在のユーザに割り当てられたすべての承認を表示する手段を提供します。 承認にアクセスする方法としては他にも、[共通タスク(Common Tasks)] > [承認(Authorizations)] リンクと My Services モジュールのナビゲーション バーの [承認(Authorizations)] タブがあります。
[サービス項目(Service Items)] ポートレットでは、現在のユーザに割り当てられたサービス項目が表示され、任意のサービス項目にすばやくアクセスできます。 このポートレットを使用できるのは、Lifecycle Center のライセンスを取得済みのサイトのみです。
[サービス項目(Service Items)] ポートレットには、プロビジョニング済みサービス項目のうち最新の 5 件が表示され、現在のユーザに割り当てられているすべてのサービス項目を表示することもできます。 サービス項目にアクセスする方法としては他にも、My Services モジュールのナビゲーション バーの [サービス項目(Service Items)] タブがあります。
[要求(Requisitions)] ポートレットには、送信済みで進行中の要求のうち最新の 5 件が表示され、ここから要求にアクセスできます。 有効にした場合は、このポートレットが [マイサービス(My Services)] 画面の左側に表示されます。
要求にアクセスする方法としては他にも、My Services モジュールのナビゲーション バーの [要求(Requisitions)] タブがあります。
[共通タスク(Common Tasks)] ポートレットには、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 モジュールの外観と動作に影響を及ぼします。
設定 |
説明 |
||
---|---|---|---|
タスクリンクを表示(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)] がクリックされたときや、ページが再読み込みされたときです。 タスク リストのリフレッシュ頻度を下げると、アプリケーションへの負荷が低下するため、全体的なアプリケーション パフォーマンスの向上に役立ちます。
デフォルトはオフです。 |
[メッセージを圧縮(Compress Messages)] 設定は、Service Link のメッセージ(内部 nsXML メッセージと外部メッセージの両方)をリポジトリ内に保持するときに圧縮するかどうかを制御します。 内部 nsXML メッセージはかなり大きくなることがあるため、圧縮が推奨されます。 Service Link のメッセージ保存に必要な領域の量を縮小するその他の手段としては、メッセージ コンテンツを最小化するようエージェントを設定する方法や、完了したタスクのメッセージを定期的に消去する方法があります。 これらのオプションの詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。
設定 |
説明 |
---|---|
メッセージの圧縮(Compress Messages) |
このフラグがオンのときは、データベース内のメッセージが圧縮されます。 メッセージに使用される領域は小さくなりますが、人間には判読が難しくなります。 デフォルトはオンです。 |
次の認証設定によって、HTTP/WS アダプタ、Web Service Listener アダプタ、Service Item Listener アダプタ経由で受信した Service Link HTTP 受信要求の認証を制御します。
設定 |
説明 |
---|---|
HTTP 受信要求の認証(Inbound HTTP Request Authentication) |
有効にした場合、Service Link の受信要求すべてに認証が必要です。 デフォルトはオンです。 |
Prime Service Catalog では、RabbitMQ サーバを使用して AMQP を実装し、システム間のメッセージのルーティングを実行します。
以下の手順を使用して、RabbitMQ サーバに接続します。 接続を確立したら、Service Designer で他のアプリケーションやシステムにサービス要求を発行するように AMQP タスクを設定できます。 サービス要求を使用するシステムの例として、要求を受け取り、履行ワークフローを実行する Cisco Process Orchestrator を挙げることができます。
他のアプリケーションやシステムにサービス要求を発行する AMQP タスクの設定方法の詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。
また、この設定は、要求者に RabbitMQ の詳細を返すために、Overview API によっても使用されます。
ステップ 1 | [管理(Administration)] > [設定(Settings)] > [AMQP] オプションを選択し、以下の表に示すように AMQP の詳細を入力します。 | ||
ステップ 2 |
設定を保存し、[AMQP接続のテスト(Test AMQP Connection)] をクリックして検証します。
|
フィールド |
説明 |
||
---|---|---|---|
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 です。
|
||
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 人以上のユーザに通知する電子メール テンプレートを選択します。 システムは、事前、事後、またはメインのタスクのいずれかの電子メール通知を生成します。 |
Prime Service Catalog には、RabbitMQ サーバで管理する代わりに、RabbitMQ サーバ上の AMQP タスク キューへのアクセスを許可する管理ユーティリティが組み込まれています。 このコンソールには、[管理(Administration)] > [ユーティリティ(Utilities)] > [AMQPトピック(AMQP Topics)] からアクセスできます。 使用可能なすべてのタスクを表示し、不要なタスクを削除できます。 次の条件のいずれかに基づいて使用可能なタスクを絞り込むことができます。
[個人ポップアップ(Person Popup)] では、ユーザが個人検索を実行したときに表示される [個人ポップアップ(Person Popup)] ウィンドウに、どのデータを表示するかを設定できます。 個人検索は次の場合に実行できます。
見出しをどのように表示するか、および各フィールドにどの情報を表示するかを指定できます。 デフォルトでは、[名前(Name)] にはその個人の姓名を定義する文字列が表示されます。 個人に関する情報フィールドは、最大 4 つ定義できます。
[名前(Name)] 以外のフィールドは表示から除外できます。除外するには、カラム見出しおよび対応する個人データを空白にします。
上記のとおりに [個人ポップアップ(Person Popup)] で定義すると、個人検索ポップアップは次のように表示されます。
Entity Homes 機能は、会社の変更管理ポリシーを施行するための手段を提供します。 マルチサイト実装(開発、テスト、および本番)の場合は、特定のエンティティ タイプを修正できる場所を切り分けて、そのエンティティのための記録システムを作成することもできます。 これは、コンテンツ変更を管理するための一般的なアプローチの 1 つです。 たとえば、サービス定義の変更は開発サイト上のみで許可し、Catalog Deployer および関連ツールを使用して変更を本番に昇格させます。 この場合は、サービス定義の記録システム、つまり「ホーム」は開発となります。
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)の参考にもなります。
[デバッグ(Debug)] 設定をオンにすると、標準画面に追加情報が表示されます。 この設定は一般的に、開発環境や QA のインストールで、または一時的に本番インスタンスで作業するときに、それまでに発見された問題の詳細情報を収集する場合にのみ使用します。
設定 |
説明 |
---|---|
デバッグ(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 |
を選択します。 |
ステップ 2 | 次のフィールドで適宜選択します。 |
ステップ 3 | [更新(Update)] をクリックします。 |
悪意ある試みを防ぐ強力なパスワードをアプリケーションに設定する必要があります。 強力なパスワードは、さまざまな脅威や脆弱性からアプリケーションとデータを保護します。 アプリケーションにパスワード ポリシーを適用し、ユーザが強力なパスワードを使用し、頻繁に変更することを推奨します。
ユーザ管理および認証のために、LDAP またはローカル データベースのいずれかとアプリケーションを統合します。 LDAP ユーザ パスワードは外部システムの一部(つまり、Prime Service Catalog の外部)になり、別個に管理および制御されます。 したがって、LDAP ユーザがシングル サインオンや外部ユーザ認証でログインするときには、これらのパスワード ポリシーは適用されません。
ユーザの管理にローカル アプリケーション認証を使用している場合、Prime Service Catalog 管理モジュールでパスワード ポリシーを設定して、エンド ユーザがアプリケーションにより安全にアクセスできるようにする必要があります。 パスワードの変更時にアプリケーションによってパスワード ポリシーが適用され、ポリシー違反がある場合はエラー メッセージが表示されます。
パスワード ポリシーはデフォルトで有効です。 要件に応じてポリシーを変更または無効化できます。 パスワード ポリシーに加えた変更は、次回のログイン検証時にユーザに適用されます。
ユーザが表 1に記載されているパスワード ポリシーに違反すると、ユーザ アカウントがロックされ、ユーザはパスワードをリセットするためシステム管理者に問い合わせる必要があります。 パスワードのリセットの詳細については、人員の設定を参照してください。
パスワード ポリシーを設定または更新するには、次の手順を実行します。
ステップ 1 |
を選択します。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
ステップ 2 |
表 1ごとにポリシーを更新します。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
ステップ 3 |
[送信(Submit)] をクリックします。
|
Catalog@2014 というパスワードについて検証します。 表 1の表に、表 2に記載されている設定に基づいてパスワード評価ポリシーを計算する方法を示します。
行番号 |
最初の文字位置と最後の文字位置 |
文字 |
文字タイプ別のスコア |
合計得点 |
---|---|---|---|---|
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 |
[ログおよびプロパティ(Logs and Properties)] ページで、ファイル タイプを左上のドロップダウン メニューから選択します。 選択できるファイル タイプは 4 つあります。 |
||
ステップ 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)] をクリックします。 |
を選択して [消去ユーティリティ(Purge Utilities)] を表示します。
(注) |
[消去ユーティリティ(Purge Utilities)] を表示して使用するには、[サポートユーティリティを使用する(Use Support Utilities)] と [消去ユーティリティにアクセスする(Access Purge Utilities)] の両方の機能がユーザに対して有効になっている必要があります(Administration の機能を参照)。 |
3 種類の消去ユーティリティを以下に示します。
要求消去ユーティリティによって、タスクと Service Link メッセージを含め、消去フィルタ条件を満たす要求とそれらの要求に関連付けられたすべてのトランザクション データが削除されます。 RequestCenter データベースの LogPurge テーブルには実際の要求消去の結果も追加されます。
データベースの規模が大きい場合、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 ページを表示するには、[管理(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 |
を選択します。 |
ステップ 2 | 要求 ID をクリックするか、[検索(Search)] タブを使用して要求を検索します。 |
ステップ 3 | [メッセージ(Message)] ウィンドウでメールを確認します。 |
ステップ 4 | [Resend(再送信)] をクリックします。 |
このユーティリティを使用して、履歴要求を一時的に履歴データ テーブルに移行できます。 オフピーク期間の手動移行プロセスによって、システムのオーバーヘッドが減少します。
newscale.properties ファイルで設定されている値が、締切日、バッチ サイズ、および最大要求数の各フィールドに表示されます。 設定をさらに編集してから、[開始(Start)] をクリックしてスケジューラを有効にすることができます。
処理の速度と時間は、要求の平均サイズによって異なります。 本番環境で移行プロセスを実行する前に、データベース管理者と協力して試験実行を行い、初回の実行にかかる時間を見積もってください。 詳細については、消去と分割によるパフォーマンスの最適化を参照してください。
移行プロセスを開始するには、次の手順を実行します。
ステップ 1 |
を選択します。 |
ステップ 2 | カレンダーを使用して締切日を選択します。 |
ステップ 3 | バッチ サイズと処理できる最大要求数を入力することもできます。 |
ステップ 4 |
[開始(Start)] をクリックして移行プロセスを開始します。 [管理(Administration)] > [設定(Settings)] タブの [履歴要求スケジューラの有効化(Enable Historical Requisitions Scheduler)] の設定がオフになっていることを確認してください。 履歴移行を処理するには、履歴スケジューラを有効にする方法と、プロセス実行ユーティリティを使用する方法のいずれかを選択できます。 |
ステップ 1 | を選択します。 |
ステップ 2 | [停止(Stop)] をクリックして、スケジューラまたはユーティリティを使用して有効にした移行プロセスを終了します。 |
複数のユーザがアクティブ フォームでサービスを作成する場合、各ユーザが実行した変更内容を把握することは困難です。 Prime Service Catalog では、[サービス設計の変更履歴(Service Design Change History)] オプションを使用して、サービス設計でのそれらの変更を追跡できます。 これによって、Service Designer でユーザが変更の詳細にアクセスできるようになります。 サービス設計の変更履歴を追跡する方法の詳細については、『Cisco Prime Service 11.0 Catalog Designer Guide』を参照してください。
(注) |
Oracle データベースを使用する Prime Service Catalog のインストールでは、このタブにアクセスできません。 これは、Oracle が変更データ キャプチャ機能のサポートを停止したためです。 |
はじめる前に
Prime Service Catalog をインストールした後で、以下のスクリプトを実行します。
これらのスクリプトは、インストール ディレクトリ /schema の下のユーティリティ フォルダで使用できます。
サービス設計の変更履歴を有効または無効にするには、次の手順を実行します。
ステップ 1 |
を選択します。 |
ステップ 2 | サービス設計の変更履歴を有効または無効にする特権を持つユーザのデータベース資格情報のユーザ名とパスワードを入力します。 |
ステップ 3 | 変更履歴のキャプチャを開始するには [有効化(Enable)] をクリックし、変更履歴のキャプチャを停止するには [無効化(Disable)] をクリックします。 |
(注) |
サービス設計の変更履歴を無効にすると、Prime Service Catalog はアーカイブされたデータをデータベースから削除します。 |
SQL クライアントから変更履歴を手動で有効または無効にできます。 SQL Server の変更履歴を手動で有効または無効にする方法の詳細については、MSDN ライブラリを参照してください。
目次
この章は次のトピックで構成されています。
会社のルールやビジネス プラクティスに合わせて Administration モジュールのさまざまな振る舞いをセットアップすることができます。
Administration モジュールから次のようなタスクを実行できます。
ディレクトリとは、ユーザ データのリポジトリのことです。 Administration では、エンタープライズ ディレクトリなどのユーザ データのソースにリンクしてそのソースからのデータを利用するようにシステムを設定できます。 具体的には、ユーザ プロファイル情報をディレクトリ サーバ データベースと同期させることができます。
ディレクトリ統合の詳細(統合に必要な情報を整理するためのワークシート、詳細なマッピング情報、特別な考慮事項など)については、『Cisco Prime Service Catalog Integration Guide』を参照してください。
Administration モジュールの [承認(Authorizations)] タブで、承認と確認の有効化および無効化と、サイト全体の承認のセットアップができます。 このようなサイト全体の承認は、個々の組織やサービスまたはサービス グループに対して確立済みの承認に加えて、またはその代わりとして使用できます。
承認は、割り当てられた承認者に対してサービス要求の拒否または承認を求めるタスクです。 確認は、実行者に対して提供プロセスのステップの確認を求めるタスクです。
Service Catalog では、複数のタイプの承認と確認をサポートしています。
ファイナンシャル承認 |
要求されたサービスまたは項目が予算内であるかどうかを判断する承認。 この承認は、組織単位レベルでは上書きできません。 |
部門承認 |
事業単位マネージャによる購買承認のための承認。 |
部門確認 |
部門で要求されたサービスまたは項目が適切であるかどうかの確認。 |
サービス グループの承認 |
サービス チーム マネージャによる購買承認のための承認。 通常、サービス チーム マネージャは、自分のサービス チームに所属する人を承認します。 |
サービス グループの確認 |
サービス グループで要求されたサービスまたは項目が適切であるかどうかの確認。 |
承認プロセスの設定は、次の 3 つの手順で構成されます。
Administration モジュールの [承認(Authorizations)] タブで、1 つのサイトに対して最大 5 つの承認タイプを有効にできます。
承認タイプのステータスを変更するには、変更する承認タイプの [アクション(Action)] 列で [編集(Edit)] をクリックし、[ステータス(Status)] ドロップダウン メニューから [有効化(Enable)] または [無効化(Disable)] を選択します。 実行順序を変更するには、[アクション(Action)] 列で上矢印または下矢印をクリックして正しい順序にします。
承認または確認のタイプが有効になっている場合は、このタイプに対して詳細を指定できます。 承認の詳細は、次のように定義できます。
Departmental Authorizations/Reviews の場合、次の選択肢があります。
Service Group Authorizations/Reviews の場合、次の選択肢があります。
[サイトの承認構造のみを使用(Use site authorization structure only)] または [サービス グループの承認構造を使用(Use service group authorization structure only)] オプションを選択した場合、それ以上の手順は必要ありません。 それ以外の場合は、設定する承認タイプを選択できます。
(注) |
すべての承認タスクと確認タスクは、提供プロセスが開始する前に完了する必要があります。 |
Administration モジュールの [承認(Authorizations)] タブで、編集する承認または確認の横にある [アクション(Actions)] カラムの [編集(Edit)] をクリックします。 選択する承認タイプに基づいて、[承認 – 逐次的プロセス(Authorizations – Sequential Process)] または [確認 – 同時プロセス(Reviews – Concurrent Process)] サブタブが表示されます。
次の表に、[詳細(Details)] 画面のフィールドを示します(これらのサブタブの [追加(Add)] をクリックした後、またはサブタブの [名前(Name)] フィールドの左にあるチェックボックスをクリックして定義済みの承認/確認ロールを選択した後に表示されます)。 [更新(Update)] をクリックして変更を保存します。 アスタリスク(*)の付いたフィールドは必須フィールドです。
フィールド |
説明 |
---|---|
名前(Name)* |
承認者または確認者によって実行されている新しい役割の名前。 |
期間(Duration)* |
タスクの承認または確認に割り当てられる時間(時間単位)。 |
件名(Subject)* |
この役割が実行する承認タスクまたは確認タスクの名前。 この値は、Service Manager で承認者または確認者に対して [タスクリスト(Task List)] に表示されます。 タスクのタイトルには名前空間変数を使用できます。 ハッシュ マーク(#)で囲まれた文字列は、名前空間変数であることを示します。 この変数は、オーダー中のサービス名で置き換えられます。 詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。 |
実行(Effort)* |
確認または承認の実行所要時間。 通常、[時間(Duration)] よりも小さい値になります。 |
ワークフロータイプ(Workflow Type) |
承認者がシステム内のユーザである場合は、[internal] を選択します。または、使用可能な外部ワークフローを選択して、Service Link タスク経由で承認を実行します。 |
Assign |
ドロップダウン メニューから、次のいずれかを選択します。 |
割り当て先(Assign to) |
をクリックして、[割り当て(Assign)] フィールドの選択内容に対応する値を選択します。 [式から(From an expression)] を選択した場合は、式を入力します。 式の構文については、『Cisco Prime Service Catalog Designer Guide』を参照してください。 |
エスカレーション階層(Escalation Tiers) |
次のいずれかをクリックします。 |
条件 |
承認するために満たす必要がある条件を含む式。 True または False を使用して、タスクが発生するかどうかを示します。 式を入力しない場合は、デフォルト値が True になり、承認が常に実行されます。 使用している式が動作することを検証するには、[確認(Validate)] をクリックします。 検証では構文チェックのみが実行され、参照データが実際に要求に存在するかどうかはチェックされません。 |
次の場合に条件を評価(Evaluate condition when) |
次のいずれかを選択します。
|
承認/確認が進むときに式を再評価(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) |
エスカレーションとは、指定された期間内に実行されなかったアクティビティにフラグを立て、解決のために適切な実行者、スーパーバイザ、または顧客に送信するプロセスのことです。 受信者は、遅延タスクの通知を電子メール形式で受け取ります。
エスカレーション プロセスをセットアップする場合は、次の点に注意してください。
実際には、エスカレーションは、ワークフロー マネージャである Business Engine の一部である Escalation Manager によって送信されます。 デフォルトでは、通常の勤務時間中に、関連するエスカレーションが指定された遅延タスクが、Escalation Manager により 1 時間に 1 回(正時)チェックされます。 したがって、上記で示しているように、承認が指定時間遅れた後で電子メール通知が送信されるというのは必ずしも正確でありません。 通知が実際に送信されるのは、エスカレーション期間が期限切れとなった後で Escalation Manager による遅延タスクのチェックが次に行われたときです。 たとえば、承認が午後 12:30 に予定されており、エスカレーション通知をその 1 時間後(午後 1:30)に送信するよう設定されている場合、通知が実際に送信されるのは、Escalation Manager の実行が次に行われる午後 2 時となります。
管理者は、Escalation Manager の設定を変更できます。 詳細は、Prime Service Catalog の保守を参照してください。
Service Catalog には、事前設定の電子メール テンプレートのセットが含まれています。 発生したイベントへの応答として自動的にテンプレートを送信するように、サービスの提供計画をセットアップできます。 Administration モジュールでは、電子メール通知に使用されるテンプレートを新規に作成したり、提供されたテンプレートを修正したりすることができます。 この電子メールは、受信者に承認と提供のプロセス中のステップを通知するのに使用されます。
Service Catalog で使用されるテンプレートは、[全般(General)] リンクの下にあります。 Demand Center で使用されるテンプレートは、[契約電子メールテンプレート(Agreement Email Templates)] の下にあります。 発生したイベントへの応答として自動的にテンプレートを送信するように、Administration を設定できます。 たとえば、あるサービスでマネージャからの承認が必要であるときに、システムからこのマネージャに、サービス要求の承認が必要であることを通知する電子メールを送信できます。 付属のテンプレートを変更することも、組織に適したテンプレートを追加することもできます。
電子メール テンプレートの情報を表示するには、次の方法のいずれかを使用します。
テンプレート名をクリックすると、テンプレートのスタイル設定オプションと内容が表示されます。 次に示すのはサンプルの Service Catalog テンプレートです。
電子メール テンプレートを設定するには、次の情報を入力します。
フィールド |
説明 |
---|---|
[名前(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)] タブを使用して、次のリストを設定します。
リスト名 |
説明 |
---|---|
コスト ドライバ |
コスト ドライバは、Service Designer でサービスのコスト詳細を設定するときに使用できます。 |
目的 |
目標リストは、Service Designer で目標を作成するときにドロップダウン リストで使用可能な目標基準の設定に使用されます。 |
測定単位(Unit of Measure) |
測定単位は、Service Designer で目標を設定するときに基準と組み合わせて使用されます。 |
[言語(Language)] |
言語リストは、ユーザ プロファイルや個人情報内の [表示言語(Preferred 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)] タブに表示されるオプションは次のとおりです。
カスタマイゼーションを使用すれば、組織の業務慣習に合わせてオプションを設定できます。 カスタマイゼーション設定は、影響を受けるモジュールや各設定によって付与される機能に応じて、いくつかのグループに分かれています。
カスタマイゼーションに使用できる値は次のとおりです。
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)] の設定をオンにする必要があります。
オーダーの失敗 E メール テンプレート |
オーダー送信プロセスが予期せず異常終了したときに送信される電子メール。 このエントリが効力を持つのは、[非同期でのタスクの送信、承認、および確認(Submit, Approve and Review Tasks Asynchronously)] の設定がオンの場合のみです。 |
承認の失敗 E メール テンプレート |
ユーザが実行した承認または確認のタスクが予期せず異常終了した場合に送信される電子メール。 このエントリが効力を持つのは、[非同期でのタスクの送信、承認、および確認(Submit, Approve and Review Tasks Asynchronously)] の設定がオンの場合のみです。 |
この設定は、本番環境においてほとんど変更されることのないアプリケーション ファイルをブラウザ キャッシュに格納できるようにします。 この機能を使用すると、キャッシュ済みのオブジェクトが利用されるため、遠隔地にいるユーザのページ読み込み時間が大幅に改善される可能性があります。リフレッシュが要求されるのは、バージョンの変更が検出されたときのみです。
ブラウザ キャッシュが有効な場合は、最後にアクセスされたバージョンを記録するための Cookie がブラウザ クライアント内に作成されます。次のタイプのオブジェクトについては、キャッシュされたバージョンをアプリケーションで利用できます。
アプリケーション変更イベントが発生した場合(たとえば、変更されたイメージを持つサービスを Catalog Deployer を使用して展開するなど)、管理者はバージョン番号を増加させることで、ユーザにブラウザ キャッシュの削除を要求することができます。
ユーザのブラウザ Cookie に記録されているバージョンが、[管理(Administration)] 設定のものと異なる場合は、ユーザにブラウザ キャッシュの削除を要求する通知が表示されます。 ブラウザ キャッシュが削除されたら、[再ログイン(Login Again)](シングル サインオンが有効な場合は [続行(Continue)])をクリックしてアプリケーションにアクセスできます。
アプリケーションのインストール時に、JMS ユーザ名とパスワードの値が初めて収集されます。 それ以降にアプリケーション サーバ側でクレデンシャルが変更された(企業のパスワード ポリシーやその他の要件で必要とされたため)場合は、更新された値をここに入力して、Prime Service Catalog アプリケーションが JMS キューへのアクセスを継続できるようにする必要があります。
AMQP ユーザ名とパスワードを他の AMQP 設定と一緒に使用して、RabbitMQ サーバとの接続を確立することができます。 AMQP 公開キーは重要なフィールドを保護するために使用されます。この保護されたフィールドは対応する秘密キーを使用して外部システムで復号化されます。 AMQP セキュア文字列形式はデータの暗号化形式です。 デフォルトのセキュア文字列形式はバイトです。 外部システムにサービス要求を発行するための AMQP タスクの設定方法については、『Cisco Prime Service Catalog 11.0 Designer Guide』を参照してください。
(注) |
一度に接続可能な AMQP は 1 つだけです。 |
共通設定は、複数のモジュールの振る舞いに影響を及ぼします。
カスタムヘッダーフッターの有効化(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 によってサービスが展開されるときに、そのサービスで参照される標準の定義(一般的には、データ取得ルールの形を取ります)が自動的に展開され、その標準に対応するエントリ(データ)も展開されます。 [標準テーブルのエントリ(データ)の展開(Deploy Entries (data) in Standards Tables)] 設定を使用すると、この動作をオーバーライドすることができます。 [いいえ(No)] に設定されている場合は、Catalog Deployer によって標準データがターゲット環境に展開されることはありません。 ターゲット環境へのデータ読み込みには別の方法(Lifecycle Center を使用して手作業で入力するか、標準データをインポートする)が使用されると想定されます。
詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。
My Services の設定は、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 は、サービス フォームの右側に表示されます。 ここには、フォーム内のディクショナリが表示されます。 ディクショナリのチェックが行われるのは、そのディクショナリ内のすべての必須フィールドに値が入力されたときです。 必須フィールドのステータス チェックは、グリッド ディクショナリには適用されません。
サービス フォームの表示後にディクショナリがルールまたは ISF コードによって非表示にされると混乱を招くおそれがあります。そのディクショナリは引き続き Form Monitor に表示されているためです。
[承認(Authorizations)] ポートレットでは、現在のユーザに割り当てられたすべての承認をすばやく表示してアクセスできます。 承認を表示可能なユーザの場合は、このポートレットが [マイサービス(My Services)] 画面の左側に表示されます。
[承認(Authorizations)] ポートレットは、最新の 5 つの承認のクイック ビューと現在のユーザに割り当てられたすべての承認を表示する手段を提供します。 承認にアクセスする方法としては他にも、[共通タスク(Common Tasks)] > [承認(Authorizations)] リンクと My Services モジュールのナビゲーション バーの [承認(Authorizations)] タブがあります。
[サービス項目(Service Items)] ポートレットでは、現在のユーザに割り当てられたサービス項目が表示され、任意のサービス項目にすばやくアクセスできます。 このポートレットを使用できるのは、Lifecycle Center のライセンスを取得済みのサイトのみです。
[サービス項目(Service Items)] ポートレットには、プロビジョニング済みサービス項目のうち最新の 5 件が表示され、現在のユーザに割り当てられているすべてのサービス項目を表示することもできます。 サービス項目にアクセスする方法としては他にも、My Services モジュールのナビゲーション バーの [サービス項目(Service Items)] タブがあります。
[要求(Requisitions)] ポートレットには、送信済みで進行中の要求のうち最新の 5 件が表示され、ここから要求にアクセスできます。 有効にした場合は、このポートレットが [マイサービス(My Services)] 画面の左側に表示されます。
要求にアクセスする方法としては他にも、My Services モジュールのナビゲーション バーの [要求(Requisitions)] タブがあります。
[共通タスク(Common Tasks)] ポートレットには、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 モジュールの外観と動作に影響を及ぼします。
設定 |
説明 |
||
---|---|---|---|
タスクリンクを表示(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)] がクリックされたときや、ページが再読み込みされたときです。 タスク リストのリフレッシュ頻度を下げると、アプリケーションへの負荷が低下するため、全体的なアプリケーション パフォーマンスの向上に役立ちます。
デフォルトはオフです。 |
[メッセージを圧縮(Compress Messages)] 設定は、Service Link のメッセージ(内部 nsXML メッセージと外部メッセージの両方)をリポジトリ内に保持するときに圧縮するかどうかを制御します。 内部 nsXML メッセージはかなり大きくなることがあるため、圧縮が推奨されます。 Service Link のメッセージ保存に必要な領域の量を縮小するその他の手段としては、メッセージ コンテンツを最小化するようエージェントを設定する方法や、完了したタスクのメッセージを定期的に消去する方法があります。 これらのオプションの詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。
設定 |
説明 |
---|---|
メッセージの圧縮(Compress Messages) |
このフラグがオンのときは、データベース内のメッセージが圧縮されます。 メッセージに使用される領域は小さくなりますが、人間には判読が難しくなります。 デフォルトはオンです。 |
次の認証設定によって、HTTP/WS アダプタ、Web Service Listener アダプタ、Service Item Listener アダプタ経由で受信した Service Link HTTP 受信要求の認証を制御します。
Prime Service Catalog では、RabbitMQ サーバを使用して AMQP を実装し、システム間のメッセージのルーティングを実行します。
以下の手順を使用して、RabbitMQ サーバに接続します。 接続を確立したら、Service Designer で他のアプリケーションやシステムにサービス要求を発行するように AMQP タスクを設定できます。 サービス要求を使用するシステムの例として、要求を受け取り、履行ワークフローを実行する Cisco Process Orchestrator を挙げることができます。
他のアプリケーションやシステムにサービス要求を発行する AMQP タスクの設定方法の詳細については、『Cisco Prime Service Catalog Designer Guide』を参照してください。
また、この設定は、要求者に RabbitMQ の詳細を返すために、Overview API によっても使用されます。
ステップ 1 | [管理(Administration)] > [設定(Settings)] > [AMQP] オプションを選択し、以下の表に示すように AMQP の詳細を入力します。 | ||
ステップ 2 |
設定を保存し、[AMQP接続のテスト(Test AMQP Connection)] をクリックして検証します。
|
フィールド |
説明 |
||
---|---|---|---|
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 です。
|
||
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 人以上のユーザに通知する電子メール テンプレートを選択します。 システムは、事前、事後、またはメインのタスクのいずれかの電子メール通知を生成します。 |
[個人ポップアップ(Person Popup)] では、ユーザが個人検索を実行したときに表示される [個人ポップアップ(Person Popup)] ウィンドウに、どのデータを表示するかを設定できます。 個人検索は次の場合に実行できます。
見出しをどのように表示するか、および各フィールドにどの情報を表示するかを指定できます。 デフォルトでは、[名前(Name)] にはその個人の姓名を定義する文字列が表示されます。 個人に関する情報フィールドは、最大 4 つ定義できます。
[名前(Name)] 以外のフィールドは表示から除外できます。除外するには、カラム見出しおよび対応する個人データを空白にします。
上記のとおりに [個人ポップアップ(Person Popup)] で定義すると、個人検索ポップアップは次のように表示されます。
Entity Homes 機能は、会社の変更管理ポリシーを施行するための手段を提供します。 マルチサイト実装(開発、テスト、および本番)の場合は、特定のエンティティ タイプを修正できる場所を切り分けて、そのエンティティのための記録システムを作成することもできます。 これは、コンテンツ変更を管理するための一般的なアプローチの 1 つです。 たとえば、サービス定義の変更は開発サイト上のみで許可し、Catalog Deployer および関連ツールを使用して変更を本番に昇格させます。 この場合は、サービス定義の記録システム、つまり「ホーム」は開発となります。
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)の参考にもなります。
[デバッグ(Debug)] 設定をオンにすると、標準画面に追加情報が表示されます。 この設定は一般的に、開発環境や QA のインストールで、または一時的に本番インスタンスで作業するときに、それまでに発見された問題の詳細情報を収集する場合にのみ使用します。
設定 |
説明 |
---|---|
デバッグ(Debug) |
オンにすると、基本的なデバッグ情報がユーザに対して表示されます(現在のページの URL とパラメータや、エラーの場合のスタック トレースなど)。 |
ディレクトリマップテスト(Directory Map Testing) |
ディレクトリ統合で使用されるマッピングのテストができるようになります。 詳細については、『Cisco Prime Service Catalog Integration Guide』を参照してください。 |
ローカライズ中に Localization モジュールに新しい言語を追加した場合は、既存および新規のユーザすべてに対して言語の更新を行う必要があります。
[アプリケーションのロケール(Application Locale)] の設定は、新規ユーザを作成する際の設定に使用されます。 設定して保存した後は、作成されるユーザにこのデフォルト設定が適用されます。 ただし、これらの設定はユーザの作成時に上書きできます。
アプリケーションのローカライズの詳細については、『Cisco Prime Service Catalog Designer Guide』の「Localizing Service Catalog Strings」の章を参照してください。
新しい言語および対応する通貨をすべてのユーザに対して有効化するには、次の手順を実行します。
ステップ 1 |
を選択します。 |
ステップ 2 | 次のフィールドで適宜選択します。 |
ステップ 3 | [更新(Update)] をクリックします。 |
悪意ある試みを防ぐ強力なパスワードをアプリケーションに設定する必要があります。 強力なパスワードは、さまざまな脅威や脆弱性からアプリケーションとデータを保護します。 アプリケーションにパスワード ポリシーを適用し、ユーザが強力なパスワードを使用し、頻繁に変更することを推奨します。
ユーザ管理および認証のために、LDAP またはローカル データベースのいずれかとアプリケーションを統合します。 LDAP ユーザ パスワードは外部システムの一部(つまり、Prime Service Catalog の外部)になり、別個に管理および制御されます。 したがって、LDAP ユーザがシングル サインオンや外部ユーザ認証でログインするときには、これらのパスワード ポリシーは適用されません。
ユーザの管理にローカル アプリケーション認証を使用している場合、Prime Service Catalog 管理モジュールでパスワード ポリシーを設定して、エンド ユーザがアプリケーションにより安全にアクセスできるようにする必要があります。 パスワードの変更時にアプリケーションによってパスワード ポリシーが適用され、ポリシー違反がある場合はエラー メッセージが表示されます。
パスワード ポリシーはデフォルトで有効です。 要件に応じてポリシーを変更または無効化できます。 パスワード ポリシーに加えた変更は、次回のログイン検証時にユーザに適用されます。
ユーザが表 1に記載されているパスワード ポリシーに違反すると、ユーザ アカウントがロックされ、ユーザはパスワードをリセットするためシステム管理者に問い合わせる必要があります。 パスワードのリセットの詳細については、人員の設定を参照してください。
パスワード ポリシーを設定または更新するには、次の手順を実行します。
ステップ 1 |
を選択します。 |
|||||||||||||||||||
ステップ 2 |
表 1ごとにポリシーを更新します。 |
|||||||||||||||||||
ステップ 3 |
[送信(Submit)] をクリックします。
|
Catalog@2014 というパスワードについて検証します。 表 1の表に、表 2に記載されている設定に基づいてパスワード評価ポリシーを計算する方法を示します。
行番号 |
最初の文字位置と最後の文字位置 |
文字 |
文字タイプ別のスコア |
合計得点 |
---|---|---|---|---|
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 ファイルの場所は、次の展開済みディレクトリです。
support.properties ファイルをテキスト エディタで開きます。 Linux 環境の support.properties ファイルの例を次に示します。
|
||||
ステップ 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 つあります。 |
||
ステップ 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)] をクリックします。 |
を選択して [消去ユーティリティ(Purge Utilities)] を表示します。
(注) |
[消去ユーティリティ(Purge Utilities)] を表示して使用するには、[サポートユーティリティを使用する(Use Support Utilities)] と [消去ユーティリティにアクセスする(Access Purge Utilities)] の両方の機能がユーザに対して有効になっている必要があります(Administration の機能を参照)。 |
3 種類の消去ユーティリティを以下に示します。
要求消去ユーティリティによって、タスクと Service Link メッセージを含め、消去フィルタ条件を満たす要求とそれらの要求に関連付けられたすべてのトランザクション データが削除されます。 RequestCenter データベースの LogPurge テーブルには実際の要求消去の結果も追加されます。
データベースの規模が大きい場合、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 ページを表示するには、[管理(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」として示されています。
このユーティリティを使用して、履歴要求を一時的に履歴データ テーブルに移行できます。 オフピーク期間の手動移行プロセスによって、システムのオーバーヘッドが減少します。
newscale.properties ファイルで設定されている値が、締切日、バッチ サイズ、および最大要求数の各フィールドに表示されます。 設定をさらに編集してから、[開始(Start)] をクリックしてスケジューラを有効にすることができます。
処理の速度と時間は、要求の平均サイズによって異なります。 本番環境で移行プロセスを実行する前に、データベース管理者と協力して試験実行を行い、初回の実行にかかる時間を見積もってください。 詳細については、消去と分割によるパフォーマンスの最適化を参照してください。
移行プロセスを開始するには、次の手順を実行します。
ステップ 1 |
を選択します。 |
ステップ 2 | カレンダーを使用して締切日を選択します。 |
ステップ 3 | バッチ サイズと処理できる最大要求数を入力することもできます。 |
ステップ 4 |
[開始(Start)] をクリックして移行プロセスを開始します。 [管理(Administration)] > [設定(Settings)] タブの [履歴要求スケジューラの有効化(Enable Historical Requisitions Scheduler)] の設定がオフになっていることを確認してください。 履歴移行を処理するには、履歴スケジューラを有効にする方法と、プロセス実行ユーティリティを使用する方法のいずれかを選択できます。 |
複数のユーザがアクティブ フォームでサービスを作成する場合、各ユーザが実行した変更内容を把握することは困難です。 Prime Service Catalog では、[サービス設計の変更履歴(Service Design Change History)] オプションを使用して、サービス設計でのそれらの変更を追跡できます。 これによって、Service Designer でユーザが変更の詳細にアクセスできるようになります。 サービス設計の変更履歴を追跡する方法の詳細については、『Cisco Prime Service 11.0 Catalog Designer Guide』を参照してください。
(注) |
Oracle データベースを使用する Prime Service Catalog のインストールでは、このタブにアクセスできません。 これは、Oracle が変更データ キャプチャ機能のサポートを停止したためです。 |
はじめる前に
Prime Service Catalog をインストールした後で、以下のスクリプトを実行します。
これらのスクリプトは、インストール ディレクトリ /schema の下のユーティリティ フォルダで使用できます。
サービス設計の変更履歴を有効または無効にするには、次の手順を実行します。
ステップ 1 |
を選択します。 |
ステップ 2 | サービス設計の変更履歴を有効または無効にする特権を持つユーザのデータベース資格情報のユーザ名とパスワードを入力します。 |
ステップ 3 | 変更履歴のキャプチャを開始するには [有効化(Enable)] をクリックし、変更履歴のキャプチャを停止するには [無効化(Disable)] をクリックします。 |
(注) |
サービス設計の変更履歴を無効にすると、Prime Service Catalog はアーカイブされたデータをデータベースから削除します。 |
SQL クライアントから変更履歴を手動で有効または無効にできます。 SQL Server の変更履歴を手動で有効または無効にする方法の詳細については、MSDN ライブラリを参照してください。