この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
• 「概要」
• 「リスト」
• 「サイトの設定」
Administration モジュールでは、さまざまな動作を、自社のルールやビジネス慣習に適合するように設定できます。
Administration モジュールを使用してできることは次のとおりです。
• エンタープライズ ディレクトリなどのユーザ データのソースにリンクして、そのソースからのデータを利用します。
• 承認および提供のプロセスで使用される電子メール通知テンプレートを定義します。
• サイト全体の設定をカスタマイズします。たとえば、特定の組織単位または組織単位のグループで使用されるカスタム スタイル シートを確立します。
• システム ログとプロパティのファイルをトラブルシューティングのために表示およびコピーします。
Administration の [Home] ページでは、ナビゲーション バーのタブまたはコンテンツ ペイン内のリンクを使用して、このモジュールのあらゆる部分にナビゲートできます。
ディレクトリとは、ユーザ データのリポジトリのことです。Administration では、エンタープライズ ディレクトリなどのユーザ データのソースにリンクしてそのソースからのデータを利用するようにシステムを設定できます。具体的には、ユーザ プロファイル情報をディレクトリ サーバ データベースと同期させることができます。
ディレクトリ統合の詳細(統合に必要な情報を整理するためのワークシート、詳細なマッピング情報、特別な考慮事項など)については、『 Cisco Service Portal Integration Guide 』を参照してください。
Administration モジュールの [Authorizations] オプションを使用すると、承認と確認をイネーブルまたはディセーブルにしたり、管理者がサイト全体の承認を設定したりすることができます。このようなサイト全体の承認は、個々の組織やサービスまたはサービス グループに対して確立済みの承認に加えて、またはその代わりとして使用できます。
詳細については、「承認構造の設定」を参照してください。
Service Portal には、事前設定済みの電子メール テンプレートのセットが含まれています。発生したイベントへの応答として自動的にテンプレートを送信するように、サービスの提供計画を設定できます。Administration モジュールでは、電子メール通知に使用されるテンプレートを新規に作成したり、提供されたテンプレートを修正したりすることができます。この電子メールは、受信者に承認と提供のプロセス中のステップを通知するのに使用されます。
Request Center で使用されるテンプレートは、[General] リンクの下にあります。Demand Center で使用されるテンプレートは、[Agreement Email Templates] の下にあります。発生したイベントへの応答として自動的にテンプレートを送信するように、Administration を設定できます。たとえば、あるサービスでマネージャからの承認が必要であるときに、システムからこのマネージャに、サービス要求の承認が必要であることを通知する電子メールを送信できます。付属のテンプレートを変更することも、自組織に適したテンプレートを追加することもできます。
電子メール テンプレートの情報を表示するには、次の方法のいずれかを使用します。
• [Home] ページの [Manage Email Templates] をクリックします。[Email Templates] ナビゲーション ペインで、開いて表示する テンプレートの名前 をクリックします。
• ナビゲーション バーの [Notifications] をクリックします。[Email Templates] ナビゲーション ペインで、開いて表示する テンプレートの名前 をクリックします。
テンプレート名 をクリックすると、テンプレートのスタイル設定オプションと内容が表示されます。サンプルの Request Center テンプレートを次に示します。
電子メール テンプレートを設定するには、次の情報を入力します。
クリックすると、テンプレートは HTML 対応の電子メール システムでの表示と同様に表示されます。選択されているときは、電子メール テンプレートの書式を設定するための HTML エディタ ツールが表示されます。 |
|
自分で作成した電子メール テンプレートのうち、使用されていないものは削除できます。事前設定されたテンプレートは削除できません。
Service Portal によって送信される電子メール通知の形式は、MIME マルチ パート メッセージであり、テキスト パートと HTML パートの両方が含まれます。ほとんどの電子メール クライアントでは、テキスト パートは無視されて HTML パートが表示されます。
HTML エディタの使用手順については、『 Cisco Service Portal Designer Guide 』を参照してください。
動的データ コンテンツを使用して電子メールの書式を設定する方法の詳細については、『 Cisco Service Portal Designer Guide 』を参照してください。
通知の受信者は、電子メール送信のトリガーとなったイベントによって決まります。たとえば、顧客(#Requisition.Customer.Email#)は一般に、要求のステータスが大きく変化したことについて通知を受け取ります。
イベントが承認または確認である場合は、承認者の代理者(#Requisition.Alternate.Email#)も受信者リストに含めるのが賢明である可能性があります。現時点で代理者が 1 人も指名されていない場合は、名前空間の値はブランクとなりますが、通知の外観には影響しません。
電子メール通知を使用するモデルとして、Request Center の方が Demand Center よりも堅牢です。Request Center の場合は、個々のサービスごとに別の通知セットを設定できます。Demand Center の場合、この設定はサイト全体のものです。つまり、イベントが属する契約とは無関係に、同じ通知のセットがすべてのイベントに使用されます。電子メール テンプレートとイベントを関連付けるには、次の手順を実行します。
ステップ 1 [Demand Center] サブタブをクリックして Demand Center のテンプレートを表示します。
ステップ 2 テンプレートのリストの下にある [Go to Agreement Notification Events] ボタンをクリックします。
ステップ 3 次に示すように、契約通知イベントのリストが表示されます。各イベントに添付する電子メール テンプレートを指定できます。
Administration では、サイト内のさまざまな場所や関連レポートで使用される標準の値リストに修正を加えたり、使用可能な言語を指定したりすることができます。
|
|
コスト ドライバを使用できるのは、サービスのコスト詳細を Service Designer で設定するときや、サービス オファリングの価格を Portfolio Designer で設定するときです。 サービス オファリングにおけるコスト ドライバは、オファリングの価格またはコストの属性またはドライバのうち、最も関連性が高く意味のあるものを、顧客の計画/消費管理に便利な単位で表したものです。 ユーザ定義のコスト ドライバに空白を含めることはできません。これは、Portfolio Designer の計算式で使用できるようにするためです。 |
|
[Objectives] リストは、Objective Manager でサービス オファリングの目標を作成するときにドロップダウン リストとして使用できる、目標メトリックの設定に使用されます。 |
|
単位は、メトリックとともに、Objective Manager でサービス オファリングの目標を設定するのに使用されます。 |
|
[Business Goals and Initiatives] リストは、サービス オファリングで使用される 4 種類のレポート分類(ビジネス カテゴリ、内部、ビジネス プロセス、ビジネス イニシアチブ)を設定するのに使用されます。 |
|
[Language] リストは、ユーザのプロファイルや個人情報にある [Preferred Language] ドロップダウン リストで選択できる言語のリストを管理するのに使用されます。詳細については、「Language」を参照してください。 |
|
属性を使用すると、ビジネス イニシアチブやプロセスをどの程度サポートするかを基準としてサービス オファリングを表すことができます。 |
ポートフォリオ設計者は、Portfolio Designer を使用してビジネス イニシアチブを 1 つ以上のサービス オファリングに関連付けます。これは、IT 作業を、ビジネスにとって最も重要なものにリンクさせる手段となります。ここで定義されるビジネス イニシアチブとサービス オファリングとの関連付けは、My Services Executive の [Portfolio Optimization] タブのポップアップ ウィンドウで行います。
My Services モジュールは、複数の言語で利用できます。[Language] リストは、ユーザの個人プロファイルの [Preferred Language] ドロップダウン リストで選択できる言語のリストを管理するのに使用されます(「Preferred Language」を参照)。デフォルトでは、[Preferred Language] ドロップダウン リストで使用できるのは英語(米国)のみです。他の言語を使用できるようにするには、[Language] リストにその言語を追加します。[Add] をクリックし、言語をドロップダウン リストから選択してから [Update] をクリックします。その他の設定手順は必要ありません。
作成できる属性の数に制限はありません。(事前設定済みの属性はありません)。後で、サービス オファリングに関連付けることができます。属性を作成すると、ビジネス イニシアチブやプロセスをどの程度サポートするかを基準としてオファリングを表すことができます。オファリングの属性は、Portfolio Designer で属性をサービス オファリングに関連付けるときにドロップダウン リストに表示されます。詳細については、Portfolio Designer のオンライン ヘルプを参照してください。
Administration では、さまざまな動作を、自組織のポリシーや業務慣習に適合するようにカスタマイズできます。これらのオプションを設定するには、[Settings] タブをクリックします。[Settings] タブに表示されるオプションは次のとおりです。
|
|
[Customizations] では、組織の業務慣習に合わせてオプションを設定できます。
[Customizations] の設定は、影響を受けるモジュールや各設定によって付与される機能に応じて、いくつかのグループに分かれています。
セッション タイムアウトを設定します。デフォルトは 20 分です。2 時間(240 分)以下の任意の長さに設定できます。 |
|
どのファイル タイプが添付でき、どれができないかを定義します。これはファイル拡張子をカンマで区切ったリストとして定義します(例:.exe, .bmp, or .zip)。 |
|
Request Center は、サービス要求を処理するために、トランザクショナル データベース内に一連のレコードを作成する必要があります。これらのレコードは、そのサービスのワークフローを構成する承認および提供のタスクに対応しています。複雑な提供計画の場合は、これらのタスクを作成して、割り当てられた参加者、それぞれの作業カレンダー、および指定のタスク期間に基づいてすべてのタスクのスケジュール上の開始日および終了日を計算するには、かなりの時間がかかることがあり、その間ユーザ(要求者または最終承認)は、自分のサービス要求送信の処理が完了したことの確認を待つ必要があります。
この待ち時間をなくすために、Service Portal では非同期タスク インスタンス化を実装するオプションが用意されています。つまり、要求が送信されたとき(または、要求に承認または確認がある場合に最終承認が完了したとき)に、Service Portal はサービス要求の更新(または作成)のみを行うため、ユーザは次に進めるようになります。残りの処理(タスクの作成と期限の計算)は、バックグラウンドで非同期に実行されます。
この結果、ユーザ インターフェイスには、待ち時間がなくなるという大きな変更が加えられ、他にもいくつかの小さな変更があります。具体的には、要求のステータスがすぐには更新されないという点です。ユーザが画面表示をリフレッシュしなければ、更新された詳細情報が表示されないことがあります。
万一、Service Portal による全タスクの作成中にエラーが発生した場合は、通知の電子メールを関係者に送信できます。2 つの電子メール テンプレートを指定できます。1 つは要求の送信に失敗したときに使用され、もう 1 つは最終承認を正常に処理できなかったときに使用されます。テンプレートを設計するには、Administration モジュールの [Notifications] オプションを使用します。テンプレートと各イベントとの関連付けは、Administration の [Customizations] の設定で行います。失敗した要求の表示と再試行のための送信は、[Administration Debugging] ページで行います。詳細については、「非同期送信メッセージのモニタリング」を参照してください。
非同期タスク インスタンス化は、デフォルトではオフになっています。この動作をアクティブにするには、Administration の [Settings] の [Common] セクションにある [Submit, Approve and Review Asynchronously] 設定をオンにする必要があります。
この設定をイネーブルにすると、実稼動環境においてほとんど変化しないアプリケーション ファイルをブラウザのキャッシュに格納できます。この機能を使用すると、キャッシュ済みのオブジェクトが利用されるため、遠隔地にいるユーザのページ読み込み時間が大幅に改善される可能性があります。リフレッシュが要求されるのは、バージョンの変化が検出されたときのみです。
ブラウザ キャッシュがイネーブルのときは、最後にアクセスされたバージョンを記録するための Cookie がブラウザ クライアント内に作成されます。次のタイプのオブジェクトについては、キャッシュされたバージョンをアプリケーションで利用できます。
• CF 画像サーブレット(presentation-attachment.cfm)(Request Center でカテゴリやサービスに関連付けられた画像を表示するのに使用)
• ISF ライブラリ(RequestCenter.war の下に展開される *.js および *.cfm。streamJS.jsStream によって条件付きルールのために実行時に生成される JavaScript やユーザ定義の JavaScript は含まれません)
アプリケーション変更イベントが発生したとき(たとえば、Catalog Deployer を介して修正済みの画像を展開する場合)に、ユーザに各自のブラウザ キャッシュを削除するよう要求するには、管理者がバージョン番号をインクリメントします。
ユーザのブラウザ Cookie に記録されているバージョンが、Administration の [Settings] のものとは異なる場合は、ユーザにブラウザ キャッシュの削除を要求する通知が表示されます。ブラウザ キャッシュが削除されると、[Login Again] ボタン(シングル サインオンがイネーブルのときは [Continue] ボタン)をクリックしてアプリケーションにアクセスできるようになります。
Common Settings は、さまざまなモジュールの動作に影響を及ぼします。
カスタム スタイル シートやヘッダーとフッターをオンにすることは、Web ページの外観カスタマイズの最初のステップに過ぎません。管理者は、使用するスタイルを設計して、該当するファイルを適切なサーバにアップロードする必要があります。また、Administration の [Custom Styles] オプションを使用してスタイルをサイトに、またはサイト内の特定の組織に関連付ける必要があります。
ディレクトリ統合をオンにすることは、Service Portal とエンタープライズ LDAP ディレクトリとの統合の最初のステップに過ぎません。統合によって、ディレクトリに格納されている個人および組織のデータが Service Portal で使用できるようになるほか、そのディレクトリを使用した外部認証やシングル サインオンも可能になります。ディレクトリ統合を一時的にオフにするには、この設定を「オフ」にします。
ディレクトリ統合の設定では、外部認証またはシングル サインオンを、トラブルシューティングやテストなどの理由のためにオーバーライドすることもできます。管理目的でこのようにオーバーライドすることができるのは、一般的に、Site Administrator 特権を持つユーザに限定されます。
ディレクトリ統合の詳細については、『 Cisco Service Portal Integration Guide 』を参照してください。
パスワードおよびログインに関するデフォルトの設定が効力を持つときは、[Login] ウィンドウは次のようになります。
つまり、[Remember Password] プロンプトは表示されますが、[Sign Me Up] と [Forgot Password] のプロンプトは表示されません。これらの設定は、シングル サインオン(ディレクトリ統合経由で設定)を使用してログイン画面をバイパスする環境では意味を持ちません。
Catalog Deployer によってサービスが展開されるときに、そのサービスで参照される標準の定義(一般的には、データ取得ルールの形を取ります)が自動的に展開され、その標準に対応するエントリ(データ)も展開されます。[Deploy Entries (data) in Standards Tables] 設定を使用すると、この動作をオーバーライドすることができます。「No」に設定されている場合は、Catalog Deployer によって標準データがターゲット環境に展開されることはありません。ターゲット環境へのデータ読み込みには別の方法(Lifecycle Center を使用して手作業で入力するか、標準データをインポートする)が使用されると想定されます。
My Services の設定は、Request Center の My Services モジュールの動作と外観を制御します。
Form Monitor は、サービス フォームの右に表示されます。ここには、フォーム内のディクショナリが表示されます。
ディクショナリのチェックが行われるのは、そのディクショナリ内のすべての必須フィールドに値が入力されたときです。
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 のポートレット(Authorizations、Service Items、Requisitions、および Common Tasks)は事前設定済みです。すべて、またはいくつかだけを My Services ホームページの左側に表示することも、すべて非表示にすることもできます。My Services のポートレットをすべて非表示にした場合は、ページのコンテンツ部分(サービス カタログ)が拡張してページの幅いっぱいに表示されます。
My Services のポートレットのコンテンツと外観は、上記のとおりに事前設定されています。ポートレットの使用や外観をさらにカスタマイズするには、Cisco Portal Manager を使用します。方法については、『 Cisco Service Portal Designer Guide 』を参照してください。
Service Manager の設定は、Request Center の Service Manager モジュールの外観と動作に影響を及ぼします。
Demand Center の設定は、Demand Center の動作と外観を制御します。
[Compress Messages] 設定は、Service Link のメッセージ(内部 nsXML メッセージと外部メッセージの両方)をリポジトリ内に保持するときに圧縮するかどうかを制御します。内部 nsXML メッセージはかなり大きくなることがあるため、圧縮が推奨されます。Service Link のメッセージ保存に必要な領域の量を縮小するその他の手段としては、メッセージ コンテンツを最小化するようエージェントを設定する方法や、完了したタスクのメッセージを定期的に消去する方法があります。これらのオプションの詳細については、『 Cisco Service Portal Designer Guide 』を参照してください。
このフラグがオンのときは、データベース内のメッセージが圧縮されます。メッセージに使用される領域は小さくなりますが、人間には判読が難しくなります。 |
[Enable Web services] 設定は、要求、タスク、またはサービス オファリングの操作のための Web サービスを受け入れるかどうかを制御します。この設定は、Service Link http/web サービス アダプタには適用されません。
アプリケーション内の顧客向けモジュールの外観をカスタマイズするには、カスケーディング スタイル シート(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] ページを使用してスタイルを定義し、そのスタイルを適用する組織を指定します。
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] ウィンドウに、どのデータを表示するかを設定できます。個人検索は、次の場合に Request Center で実行できます。
• 個人ベースのディクショナリまたは個人タイプ フィールドをサービス フォームで使用するとき
見出しをどのように表示するか、および各フィールドにどの情報を表示するかを指定できます。デフォルトでは、[Name] にはその個人の姓名を定義する文字列が表示されます。個人に関する情報フィールドは、最大 4 つ定義できます。
[Name] 以外のフィールドは表示から除外できます。除外するには、カラム見出しおよび対応する個人データを空白にします。
上記のとおりに [Person Popup] で定義すると、個人検索ポップアップは次のように表示されます。
Entity Homes 機能は、会社の変更管理ポリシーを施行するための手段となります。マルチサイト実装(開発、テスト、および実稼動)の場合は、特定のエンティティ タイプを修正できる場所を切り分けて、そのエンティティのための記録システムを作成することもできます。これは、コンテンツ変更を管理するための一般的なアプローチの 1 つです。たとえば、サービス定義の変更は開発サイト上のみで許可し、Catalog Deployer および関連ツールを使用して変更を実稼動に昇格させます。この場合は、サービス定義の記録システム、つまり「ホーム」は 開発 となります。
Entity Homes の設定は実質的に、「None」以外のサイト保護レベルがサイトに割り当てられるまでは単に文書化を行うだけです。
|
|
サイト保護レベルによって、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 コンフィギュレーション ガイド 』を参照してください。
|
|
オンにすると、基本的なデバッグ情報がユーザに対して表示されます(現在のページの URL とパラメータや、エラーの場合のスタック トレースなど)。 |
|
ディレクトリ統合で使用されるマッピングのテストができるようになります。詳細については、『 Cisco Service Portal Integration Guide 』を参照してください。 |
メッセージ モニタが使用されるのは、[Submit, Approve and Review Tasks Asynchronously] 設定がオンの場合のみです。万一 Service Portal での要求送信やタスク承認要求の非同期処理においてエラーが発生したときは、失敗を示すメッセージが内部的メッセージ モニタ セクションに表示されます。
表示されたエラー メッセージに基づいて根底にある問題を修正してから、失敗を示すメッセージの処理を再開するには、[Retry] をクリックします。
この設定を使用すると、Catalog Deployer の同時ユーザ数をゼロにリセットできます。Catalog Deployer の同時ユーザの最大許容数は 2 です。Catalog Deployer の同時ユーザ数が 2 を超える場合は、この状況を表す次のようなメッセージが表示されます。
このメッセージは、これらの Catalog Deployer ユーザの一方または両方がすべての展開操作を完了しているにもかかわらず表示されることがあります。つまり、このメッセージは Catalog Deployer の同時使用の終了後に誤って表示されることがあります。Catalog Deployer の使用中に上記のエラー メッセージが表示され、それが誤りであることがわかっている場合は、Site Administration の権限を持つユーザが、次に示すユーティリティを使用してユーザ カウンタをリセットできます。
データ ソースは、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] タブ ページで、ファイル タイプを左上のドロップダウン メニューから選択します。
• 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] をクリックします。
マウスを 2 つのカラムの間に移動して、カラム サイズ変更カーソル( )が表示された状態にします。クリックして目的の位置までドラッグします。
カラムをマウスで目的の位置までドラッグします。次の例では、ユーザは [Server Time] カラムを左に移動しています。
カラムをクリックすると、昇順にソートされます( )。同じカラムをもう一度クリックすると、降順にソートされます( )。または、マウスをカラムの 1 つに移動してカラム ソート ボタン( )が表示された状態にします。カラム ソート ボタンをクリックしてから、[Sort Ascending] または [Sort Descending] を選択します。
マウスをカラムの 1 つに移動して、カラム ソート ボタン( )が表示された状態にします。カラム ソート ボタンをクリックし、[Columns] を選択してから、表示するカラムをチェックマークを使用して選択します。