Cisco Service Portal コンフィギュレーション ガイド リリース 9.3.2
サイト管理
サイト管理
発行日;2012/08/10 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 6MB) | フィードバック

目次

サイト管理

概要

Administration ホーム

ディレクトリ統合

サイト全体の承認

承認構造の設定

承認のイネーブル化

承認の詳細の指定

エスカレーション

電子メール テンプレート

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

テンプレートの設定

名前空間の使用

Demand Center のテンプレート

リスト

Business Goals and Initiatives

Language

Offering Attributes

サイトの設定

Customizations

非同期送信/最終承認

[Browser Cache] 設定

共通設定

スタイル関連の設定

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

ログイン関連の設定

Catalog Deployer 関連の設定

My Services の設定

Form Monitor

Authorizations ポートレット

Service Items ポートレット

Requisitions ポートレット

Common Tasks ポートレット

My Services のポートレット

Service Manager の設定

Demand Center の設定

Service Link の設定

Web サービスの設定

Custom Styles

カスタム スタイルの定義

カスタム スタイル シートおよびヘッダー/フッターのイネーブル化

Person Popup

Entity Homes

デバッグの設定

共通設定

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

Catalog Deployer ユーザ カウンタ リセット

Data Source Registry

サポート ユーティリティ

ログおよび宛先フォルダの設定

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

パネル表示の調整

概要

Administration モジュールでは、さまざまな動作を、自社のルールやビジネス慣習に適合するように設定できます。

Administration モジュールを使用してできることは次のとおりです。

エンタープライズ ディレクトリなどのユーザ データのソースにリンクして、そのソースからのデータを利用します。

承認および確認のポリシーとワークフローを定義します。

承認および提供のプロセスで使用される電子メール通知テンプレートを定義します。

標準の値リストを修正し、使用可能な言語を指定します。

サイト全体の設定をカスタマイズします。たとえば、特定の組織単位または組織単位のグループで使用されるカスタム スタイル シートを確立します。

システム ログとプロパティのファイルをトラブルシューティングのために表示およびコピーします。

Administration ホーム

Administration の [Home] ページでは、ナビゲーション バーのタブまたはコンテンツ ペイン内のリンクを使用して、このモジュールのあらゆる部分にナビゲートできます。

 

ディレクトリ統合

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

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

サイト全体の承認

Administration モジュールの [Authorizations] タブを使用すると、承認と確認をイネーブルまたはディセーブルにしたり、管理者がサイト全体の承認を設定したりすることができます。このようなサイト全体の承認は、個々の組織やサービスまたはサービス グループに対して確立済みの承認に加えて、またはその代わりとして使用できます。

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

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

財務承認

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

部門承認

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

部門確認

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

サービス グループの承認

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

サービス グループの確認

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

承認構造の設定

承認プロセスの設定は、次の 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] ボタンをクリックして、変更を保存します。

Name*

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

Duration*

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

Subject*

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

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

Escalation Tiers

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

[Use all]:このプロセスに対して設定されているすべてのエスカレーションが使用されます。

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

Condition

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

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

Evaluate condition when

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

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 cancelled

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 の設定を変更できます。これを行うための手順については、「システム管理」を参照してください。

電子メール テンプレート

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

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

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

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

[Home] ページの [Manage Email Templates] をクリックします。[Email Templates] ナビゲーション ペインで、開いて表示する テンプレートの名前 をクリックします。

ナビゲーション バーの [Notifications] をクリックします。[Email Templates] ナビゲーション ペインで、開いて表示する テンプレートの名前 をクリックします。

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

 

テンプレートの設定

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

Name

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

Subject

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

From

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

To

受信者の有効な電子メール アドレス。複数の受信者はセミコロンで区切ります。一般的には名前空間が使用されます。

Type

Request Center または Demand Center。

Language

表示言語。

HTML Part

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

Text Part

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

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

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

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

名前空間の使用

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

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

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

Demand Center のテンプレート

Request Center の場合の電子メール通知使用のモデルは、Demand Center の場合よりも堅牢です。Request Center の場合は、個々のサービスごとに別の通知セットを設定できます。Demand Center の場合、この設定はサイト全体のものです。つまり、イベントが属する契約とは無関係に、同じ通知のセットがすべてのイベントに使用されます。電子メール テンプレートとイベントを関連付けるには、次の手順を実行します。


ステップ 1 [Demand Center] サブタブをクリックして Demand Center のテンプレートを表示します。

 

ステップ 2 テンプレートのリストの下にある [Go to Agreement Notification Events] ボタンをクリックします。

ステップ 3 次に示すように、契約通知イベントのリストが表示されます。各イベントに添付する電子メール テンプレートを指定できます。

 


 

リスト

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

[Lists] タブを使用して、次のリストを設定します。

リスト名
説明

Cost Drivers

コスト ドライバを使用できるのは、サービスのコスト詳細を Service Designer で設定するときや、サービス オファリングの価格を Portfolio Designer で設定するときです。

サービス オファリングにおけるコスト ドライバは、オファリングの価格またはコストの属性またはドライバのうち、最も関連性が高く意味のあるものを、顧客の計画/消費管理に便利な単位で表したものです。

ユーザ定義コスト ドライバは Portfolio Designer 計算式で使用されるため、スペースを含めないようにする必要があります。

Objectives

[Objectives] リストは、Objective Manager でサービス オファリングの目標を作成するときにドロップダウン リストとして使用できる、目標メトリックの設定に使用されます。

Unit of Measure

単位は、メトリックとともに、Objective Manager でサービス オファリングの目標を設定するのに使用されます。

Business Goals and Initiatives

[Business Goals and Initiatives] リストは、サービス オファリングで使用される 4 種類のレポート分類(ビジネス カテゴリ、内部、ビジネス プロセス、ビジネス イニシアチブ)を設定するのに使用されます。

Language

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

Offering Attributes

属性を使用すると、ビジネス イニシアチブやプロセスをどの程度サポートするかを基準としてサービス オファリングを表すことができます。

Business Goals and Initiatives

ポートフォリオ設計者は、Portfolio Designer を使用してビジネス イニシアチブを 1 つ以上のサービス オファリングに関連付けます。これは、IT 作業を、ビジネスにとって最も重要なものにリンクさせる手段となります。ここで定義されるビジネス イニシアチブとサービス オファリングとの関連付けは、My Services Executive の [Portfolio Optimization] タブのポップアップ ウィンドウで行います。

 

 

Name

イニシアチブの説明的な名前。この名前は、Portfolio Designer でビジネス イニシアチブとサービス オファリングとを関連付けるときに、ビジネス イニシアチブのポップアップ リストに表示されます。

Description

ビジネス イニシアチブのより詳細な説明。

Status

ステータスを設定するには、ページの最下部にある [Deactivate] または [Reactivate] をクリックします。[Active] のビジネス イニシアチブは、サービス オファリングを作成または編集するときに Portfolio Designer の [Attributes] ページで選択できます。[Inactive] のビジネス イニシアチブは、選択対象にはなりません。ビジネス イニシアチブの削除はできません。アクティブ化と非アクティブ化のみが可能です。

Start Date

ビジネス イニシアチブの開始日。

End Date

ビジネス イニシアチブの終了日。この情報は、ユーザが My Services Executive の [Portfolio Optimization] タブでビジネス イニシアチブ名をクリックしたときに、ビジネス イニシアチブ詳細ポップアップ ウィンドウに表示されます。

Revenue Impact

年間通算収益への影響をドル単位で表した数値。

Priority

ビジネス イニシアチブの優先度。

Language

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

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

英語(米国)

ドイツ語

フランス語

スペイン語

オランダ語

中国語(簡体字)

中国語(繁体字)

ポルトガル語(ブラジル)

日本語

韓国語

その他のすべてのモジュールでサポートされている言語は英語(米国)のみです。

Offering Attributes

作成できる属性の数に制限はありません。(事前設定済みの属性はありません)。後で、サービス オファリングに関連付けることができます。属性を作成すると、ビジネス イニシアチブやプロセスをどの程度サポートするかを基準としてオファリングを表すことができます。オファリングの属性は、Portfolio Designer で属性をサービス オファリングに関連付けるときにドロップダウン リストに表示されます。詳細については、Portfolio Designer のオンライン ヘルプを参照してください。

サイトの設定

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

ページ
説明

Customizations

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

Person Popup

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

Entity Homes

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

Debugging

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

Custom Styles

カスタム スタイルを定義し、そのスタイルを適用する組織を指定します。

Data Source Registry

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

Customizations

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

 

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

KpiSourceOfData

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

SessionTimeOut

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

Fiscal Year End

Demand Center で使用される計算に関連する会計年度カレンダーの会計年度終了日を設定します。

Attachment Maximum Size

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

Attachment File Type Restrictions

どのファイル タイプが添付でき、どれができないかを定義します。これはファイル拡張子をカンマで区切ったリストとして定義します(例:.exe, .bmp, or .zip)。

Order Confirmation Email Template

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

非同期送信/最終承認

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

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

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

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

非同期タスク インスタンス化は、デフォルトではオフになっています。この動作をアクティブにするには、[Administration] > [Settings] > [Customizations] の [Common] セクションにある [Submit, Approve and Review Asynchronously] 設定をオンにする必要があります。

Order Failure Email Template

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

Approval Failure Email Template

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

[Browser Cache] 設定

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

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

画像(*.gif、*.jpg、*.png、*.bmp)

CF 画像サーブレット(presentation-attachment.cfm)(Request Center でカテゴリやサービスに関連付けられた画像を表示するのに使用)

スタイル シート(*.css)

ISF ライブラリ(RequestCenter.war の下に展開される *.js および *.cfm。streamJS.jsStream によって条件付きルールのために実行時に生成される JavaScript やユーザ定義の JavaScript は含まれません)

HTML(*.html、*.htm)ページ

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

ユーザのブラウザ Cookie に記録されているバージョンが、Administration の [Settings] のものとは異なる場合は、ユーザにブラウザ キャッシュの削除を要求する通知が表示されます。ブラウザ キャッシュが削除されると、[Login Again] ボタン(シングル サインオンがイネーブルのときは [Continue] ボタン)をクリックしてアプリケーションにアクセスできるようになります。

共通設定

Common Settings は、さまざまなモジュールの動作に影響を及ぼします。

Enable Custom Header Footer

カスタムのヘッダーとフッターをイネーブルにします。

デフォルトはオフです。

Enable Custom Style Sheets

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

デフォルトはオフです。

Directory Integration

外部のデータソースでユーザを検索して、そのユーザをサイトにインポートする Directories 機能をイネーブルにします。

デフォルトはオフです。

Restrict Site Administrator URL

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

デフォルトはオフです。

Remember Password

ログイン ページの「ユーザ名を保存する」機能をイネーブルまたはディセーブルにします。

デフォルトはオンです。

Show "Sign Me Up"

ログイン ページの [Sign Me Up] リンクを表示または非表示にします。

デフォルトはオフです。

Show "Forgot Password"

ログイン ページの [Forgot Password] リンクを表示または非表示にします。

デフォルトはオフです。

Use Image Path Replacement

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

デフォルトはオフです。

Use Strong Encryption

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

デフォルトはオフです。

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

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

デフォルトはオフです。

スタイル関連の設定

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

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

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

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

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

ログイン関連の設定

パスワードおよびログインに関するデフォルトの設定が効力を持つときは、[Login] ウィンドウは次のようになります。

 

つまり、[Remember Password] プロンプトは表示されますが、[Sign Me Up] と [Forgot Password] のプロンプトは表示されません。これらの設定は、ログイン画面をバイパスするためのシングル サインオン(Directory Integration を使用して設定)を使用するインストールとは関係ありません。

Catalog Deployer 関連の設定

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

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

My Services の設定

My Services の設定は、Request Center の 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

代理オーダー機能へのアクセス権を全ユーザに付与します。この設定が用意されているのは、以前のバージョンの Service Portal との下位互換性のためです。これは使用しないでください。代理オーダー権限の付与は、代わりにロール経由で行ってください。

デフォルトはオフです。

Show All Users For Order On Behalf

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

デフォルトはオフです。

Open Authorization Task in a popup

イネーブルのときは、My Services の承認タスクが別のポップアップ ウィンドウに表示されます。

デフォルトはオフです。

Form Monitor

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 のポートレット(Authorizations、Service Items、Requisitions、および Common Tasks)は事前設定済みです。すべて、またはいくつかだけを My Services ホームページの左側に表示することも、すべて非表示にすることもできます。My Services のポートレットをすべて非表示にした場合は、ページのコンテンツ部分(サービス カタログ)が拡張してページの幅いっぱいに表示されます。

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

Service Manager の設定

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

Show Task Link

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

デフォルトはオンです。

Related Tasks Default To Wait

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

デフォルトはオフです。

Enable Ad-Hoc Task Email

イネーブルのときは、新規作成された Ad-Hoc タスクの実行者宛てに、Ad-Hoc タスク開始を通知する電子メールが Request Center によって自動的に送信されます。

デフォルトはオンです。

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] ボタンがクリックされたときや、ページが再読み込みされたときです。タスク リストのリフレッシュ頻度を下げると、アプリケーションへの負荷が低下するため、全体的なアプリケーション パフォーマンスの向上に役立ちます。

デフォルトはオフです。

Demand Center の設定

Demand Center の設定は、Demand Center の動作と外観を制御します。

Enable Service Offering Catalog

Portfolio Center のためのサービス オファリング カタログを Service Designer の Categories コンポーネントで作成できるようになります。

デフォルトはオフです。

Enable Agreement Management

契約管理機能を My Services Executive モジュールおよび Relationship Manager モジュールで使用できるようになります。

デフォルトはオフです。

Enable Ordering Permission

このプロパティをイネーブルにすると、Request Center で組み込みサービスに対するオーダー権限を設定できるようになります。

デフォルトはオフです。

Service Link の設定

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

Compress Messages

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

デフォルトはオンです。

Web サービスの設定

[Enable Web services] 設定は、要求、タスク、またはサービス オファリングの操作のための Web サービスを受け入れるかどうかを制御します。この設定は、Service Link http/web サービス アダプタには適用されません。

Enable Web services

このプロパティをイネーブルにすると、Web サービスにアクセスできるようになります。

デフォルトはオフです。

Custom Styles

アプリケーション内の顧客向けモジュールの外観をカスタマイズするには、カスケーディング スタイル シート(css)とカスタム ヘッダーおよびフッターを使用します。カスケーディング スタイル シートを利用すると、Web ページそのものを編集する代わりに、ページの表示に使用されるスタイルの定義を変更することによって外観をカスタマイズできます。

カスタマイズできるページは次のとおりです。

Request Center の My Services モジュールや Service Manager モジュールに表示されるページ(たとえば、Request Center Service Designer で指定された定義に基づいて動的に生成されるサービス フォーム)

Demand Center のモジュール(Relationship Manager、My Services Executive、および Service Level Manager)に表示されるページ

Reporting および Advanced Reporting のページ

Portal Manager を使用して定義されるモジュール

ログイン ページ

サービス設計者や管理者が Service Portal の設定および管理に使用するモジュールの外観は、カスタマイズできません。これに該当するモジュールは、Service Designer、Organization Designer、Portfolio Designer、Administration、Catalog Deployer、Service Item Manager、および Service Link です。

設計者のための詳細については、「カスタム スタイル シート」を参照してください。

カスタム スタイルの定義

[Custom Styles] ページを使用してスタイルを定義し、そのスタイルを適用する組織を指定します。

 

次のとおりにプロパティを入力します。

Name

スタイル名には、スタイルの適用先であるインストール名または組織を反映してください。

Make this Style the default for the entire site

スタイルの 1 つをデフォルトとして指定できます。デフォルトが指定されている場合は、ユーザのホーム組織(OU)にスタイルが割り当てられていないときにそのデフォルトが使用されます。デフォルトが指定されていない場合は、システム定義のスタイル シートが使用されます。

Apply this Style to all sub OUs

組織で階層構造が使用されている場合は、同じ親のすべての子 OU にスタイルを継承するかどうかを指定できます。

Style Directory

RequestCenter.war\custom の下にある任意のディレクトリからスタイル ディレクトリを選択できます。スタイルを作成するには、ディレクトリが存在している必要があります。デフォルトである 1 という名前のディレクトリは、すでに存在しています。

スタイル定義や、スタイル適用先の事業単位の編集は、いつでもできます。

カスタム スタイル シートおよびヘッダー/フッターのイネーブル化

Administration モジュールを選択して [Settings] タブに移動します。[Customizations] ページが表示されます。次に示すように、[Common] の設定の中に [Enable Custom Header Footer] や [Enable Custom Style Sheets] などのパラメータがあります。

 

カスタム スタイル シートをイネーブルにするには、対応するパラメータ設定を [Off] から [On] に変更します。変更を保存するには、ページを更新します。custom.css ファイル(アプリケーション サーバ上にあります)で指定されているカスタム スタイルが効力を持ちます。

同様に、カスタムのヘッダーやフッターをイネーブルにするには、[Enable Custom Header Footer] パラメータの設定を [On] に変更します。

これらのパラメータをオンにした状態でセッションを開始した後は、セッションを終了しなくてもスタイルの変更が反映されます。スタイルの定義が変更されてファイルがアプリケーション サーバ上の指定のディレクトリに配置されると、それ以降は、ページをリフレッシュしたときに新しいスタイル定義が使用されます。

Person Popup

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

他の個人の代理でオーダーするとき

個人ベースのディクショナリまたは個人タイプ フィールドをサービス フォームで使用するとき

ユーザが一時的な代理承認者を選択するとき

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

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

 

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

 

Entity Homes

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

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

設定
説明

None

このサイト上でイネーブルになる保護はありません。

Create only

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

Create, Modify

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

Create, Modify, Delete

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

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

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

デバッグの設定

共通設定

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

[Debug] 設定をオンにすると、標準画面に追加情報が表示されます。この設定は一般的に、開発環境や QA のインストールで、または一時的に実稼働インスタンスで作業するときに、それまでに発見された問題の詳細情報を収集する場合にのみ使用します。詳細については、『 Cisco Service Portal コンフィギュレーション ガイド 』を参照してください。

設定
説明

Debug

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

DebugCfx

オンにすると、ColdFusion のデバッグ情報が表示されます。

Directory Map Testing

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

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

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

 

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

Catalog Deployer ユーザ カウンタ リセット

この設定を使用すると、Catalog Deployer の同時ユーザ数をゼロにリセットできます。Catalog Deployer の同時ユーザの最大許容数は 2 です。Catalog Deployer の同時ユーザ数が 2 を超える場合は、この状況を表す次のようなメッセージが表示されます。

 

このメッセージは、これらの Catalog Deployer ユーザの一方または両方がすべての展開操作を完了しているにもかかわらず表示されることがあります。つまり、このメッセージは Catalog Deployer の同時使用の終了後に誤って表示されることがあります。Catalog Deployer の使用中に上記のエラー メッセージが表示され、それが誤りであることがわかっている場合は、Site Administration の権限を持つユーザが、次に示すユーティリティを使用してユーザ カウンタをリセットできます。

 

Data Source Registry

データ ソースは、Service Portal が情報にアクセスするリレーショナル データベースを定義します。デフォルトでは、Service Portal インスタンスには 2 つのデータ ソースがあります。1 つはトランザクショナル データへのアクセス用、もう 1 つはデータ マートおよびレポーティングのオプションへのアクセス用です。

 

さらに、管理者は外部ディクショナリ、SQL オプション リスト、アクティブ フォーム データ取得ルールなどのコンポーネントをサポートするための追加データ ソースを作成できます。

[Data Source registry] には、使用可能なすべてのデータ ソースが一覧表示されます。データソースを作成するには、『 Cisco Service Portal Installation Guide 』を参照してください。

サポート ユーティリティ

Administration では、システム ログやプロパティのファイルを、トラブルシューティングのために表示およびダウンロードできます。

ファイルにアクセスするには、次のいずれかの方法を使用します。

[Home] ページの [Use Support Utilities] をクリックします。

ナビゲーション バーの [Utilities] をクリックします。

[Logs and Properties] タブ ページが次のように表示されます。

 


) サポート ユーティリティを使用するには、[Use Support Utilities] と [Access Logs and Property Files] の両方の機能がユーザに対してイネーブルになっている必要があります(「Administration の機能」を参照)。


ログおよび宛先フォルダの設定

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

宛先とログのフォルダを指定する手順は次のとおりです。


ステップ 1 新しい宛先フォルダを 1 つ(またはファイル タイプごとに 1 つずつ)作成します。このフォルダは任意の場所に配置できます。

ステップ 2 宛先フォルダの場所と最大サイズの指定は、support.properties ファイルで行います。support.properties ファイルは 2 つあります。1 つは Request Center 用、もう 1 つは Service Link 用です。

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

Request Center:RequestCenter.ear\config\

Service Link:ISEE.war\WEB-INF\classes\


) 上記のパスは、Windows 環境の場合のものです。


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

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


) Request Center の support.properties ファイルの場合は、Request Center のエントリのみが使用され、Service Link のエントリは無視されます。Service Link の support.properties ファイルの場合は、Service Link のエントリのみが使用され、Request Center のエントリは無視されます。


 

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

上記の例では、

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

ステップ 4 WebSphere または 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 Portal サーバを再起動します。


 

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

ファイルを表示してダウンロードする手順は次のとおりです。


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

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

Request Center - Log Files

Service Link - Log Files

Request Center - Property Files

Service Link - Property Files

ステップ 2 上部のパネルでファイルの 1 つをクリックして選択します。必要に応じて、[Refresh] をクリックして最新のファイルを表示します。

ステップ 3 ファイルを表示するには、最後の何行を表示するかを上部パネルの下部にあるドロップダウン メニューで選択してから、[View] をクリックします。

ステップ 4 ファイルがポップアップ ウィンドウに表示されます。サンプルのログ ファイルを次に示します。

 

ステップ 5 [Close] をクリックして、ウィンドウを閉じます。

ステップ 6 選択したファイル(複数のファイルを選択するには Ctrl キーを押した状態でクリックします)を特定の場所にダウンロードするには、[Compress] をクリックします。

ステップ 7 下部のパネルの [Refresh] をクリックすると、圧縮済みのファイルが下部のパネルに表示されます。ファイルは Zip 形式で圧縮され、タイム スタンプが名前に追加されます。複数のファイルを選択した場合は、Zip ファイルが 1 つだけ作成され(名前はファイル タイプとタイム スタンプのみから生成されます)、選択したファイルすべてがこの中に格納されます。


) 同じファイルが再び圧縮された場合は、異なるタイム スタンプの新しいファイルが作成され、以前の圧縮ファイルは上書きされません。


ステップ 8 下部のパネルで、ファイルの 1 つの [Download] アイコン( )をクリックします。

ステップ 9 [File Download] ダイアログが表示されます。[Save] をクリックします。

ステップ 10 場所を選択してファイルを保存するための [Save As] ダイアログが表示されます。

ステップ 11 希望する場所まで移動してから [Save] をクリックします。

ステップ 12 ファイルを保存した後で、下部のパネルで圧縮済みファイルを選択して削除するには(複数のファイルを選択するには Ctrl キーを押した状態でクリックします)、[Delete] をクリックします。


 

パネル表示の調整

次の図に示すように、[Logs and Properties] タブの上下のパネルで、カラムのサイズ変更、移動、ソート、非表示ができます。

カラムのサイズ変更

マウスを 2 つのカラムの間に移動して、カラム サイズ変更カーソル( )が表示された状態にします。クリックして目的の位置までドラッグします。

 

カラムの移動

カラムをマウスで目的の位置までドラッグします。次の例では、ユーザは [Server Time] カラムを左に移動しています。

 

カラムのソート

カラムをクリックすると、昇順にソートされます( )。同じカラムをもう一度クリックすると、降順にソートされます( )。または、マウスをカラムの 1 つに移動してカラム ソート ボタン( )が表示された状態にします。カラム ソート ボタンをクリックしてから、[Sort Ascending] または [Sort Descending] を選択します。

 

カラムの表示と非表示

マウスをカラムの 1 つに移動して、カラム ソート ボタン( )が表示された状態にします。カラム ソート ボタンをクリックし、[Columns] を選択してから、表示するカラムをチェックマークを使用して選択します。