Cisco Service Portal 設計者ガイド リリース 9.3.2
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月6日
章のタイトル： Lifecycle Center
Lifecycle Center
•
「概要」
概要
サービス項目とは、サービス要求に対応して提供される明白な結果です。これは物理的なハードウェア デバイス（携帯電話やサーバなど）のような物理的な結果があります。あるいは、ソフトウェア（アプリケーションやログイン ID など）、ソフトウェア ライセンス、VMware 仮想マシンのような仮想的な結果の場合もあります。サービス要求によっては、提供されるサービス項目が複数の場合があります。特に、携帯電話、ラップトップ、ネットワーク ログイン、電子メール アクセス、複数のソフトウェア アプリケーションを提供する従業員のオンボード サービスの場合、これが該当します。
Lifecycle Center は Service Portal のモジュールです。このモジュールにより、ユーザが Request Center のサービス カタログからオーダーされるサービス項目を管理することができます。
ここでは、サービス項目のライフ サイクルを管理するためのサービスの設定方法について説明します。ライフ サイクルは、サービス項目が企業の資産として利用可能になった時点から始まり、これがサービス要求を経由して Request Center のユーザにプロビジョニングされ、その項目が更新されたり変更されたりして、要求側ユーザに対して割り当てられなくなるまで継続したあと、再割り当てできるようになります。
サービス項目のライフ サイクル管理の場合
構成管理データベース（CMDB）に習熟しているシステム設計者やデータ設計者、またはその他の技術者は、「CMDB があるのになぜ Request Center 内でサービス項目管理を使う必要があるのだろう?」という疑問にかられることがあります。
CMDB は、その保持と使用が複雑であるという弱点があります。サービス提供者がサービスをエンドユーザに提供する際に、そのユーザがすでに所有している他のサービス項目のコンテキストが必要となることがあります。そのコンテキストを「CMDB から」参照するのは簡単なことではない可能性があります。つまり、コンテキストの情報を得るために複数の異なるシステムにアクセスし、それらのシステムをすべてスキャンできる知識が必要です。
Lifecycle Center 機能を使用すると、どのサービス項目がこのエンドユーザにプロビジョニングされているか、Request Center から簡単に参照できるようになります。 これを実行するメカニズムでは、CMDB（とその構成パーツ）へのアクセスや、CMDB についての知識を必要としません。Request Center から「参照する」だけです。エンドユーザ（とそのマネージャ）は、自分たちが実際に所有するサービス項目を表示させ、IT が（さまざまなアセット システムと CMDB の一方または両方に応じて）エンドユーザ（とそのマネージャ）が所有していると 考える 項目との不整合を解消します。
CMDB を長く使用している企業でも、一部の項目については、（CMDB と資産システムの どちらでも ）まったく追跡されないか、不完全な情報しか持っていないことがあります。このような項目を管理することは困難です。たとえば、ソフトウェアのライセンスは、通常 CMDB に保存する項目の種類ではありません。 同様に、携帯電話は追跡が確実に行われる可能性がありますが、既存のシステムでは、エンドユーザに後継サービスを提供するために実際に必要な業務依存のデータを記録していないことも考えられます。
サービス項目認識サービスの設計
サービス項目のライフ サイクル管理をサービス カタログに組み込むと、Request Center 本来の機能が設計サービスに活用されます。
• ビジネス要件を分析して、サービス項目のライフ サイクルの管理をサポートするために必要なサービス項目と機能を特定します。
• Service Item Manager は、サービス項目を定義したり、仮想マシンなどの事前に設定されているサービス項目定義を確認したりするために使用します。
• Service Designer は、サービス項目ベースのディクショナリを指定するために使用します。サービス項目ベースのディクショナリからは、サービス項目を作成したり保持したりするための、詳細要件を指定する必要のあるフィールドが提供されます。
• Service Designer を使用すると、1 つ以上のサービス項目ベースのディクショナリと、これらのディクショナリの使用をサポートする適切なルールが含まれるアクティブ フォーム コンポーネントを設計できます。アクティブ フォーム コンポーネントには、ユーザが、サービス項目や、サービス要求の他の詳細を入力したり確認したりするユーザ インターフェイスが用意されています。
• サービス項目の作成、更新、削除の各タスクを指定する提供 計画 （ワークフロー）を設計するには、Service Designer を使用します。
• サービス項目の作成と更新、あるいは保持が、VMWare の vCenter（仮想マシンの場合）や Amazon の Elastic Compute Cloud (EC2)（クラウド内での仮想マシンの場合）などの第三者のアプリケーションで行われる必要がある場合があります。このような場合は、Service Link を使用して、Request Center と外部システムの間の統合を設計します。
• サービスが設計されたら、Service Item Manager に戻り、このサービスとサービス項目を関連付けます。これによって、ユーザとマネージャが再設定できるサービスをすばやく確認することができるようになります。あるいは、以前プロビジョニングされたサービス項目を調整できるサービスをすばやく確認することができるようになります。
• Service Item Manager のインポート機能を使用して、外部定義のサービス項目と標準を Request Center にインポートするか、Service Link のファイル アダプタを使用して、サービス項目または標準のデータをインポートすることもできます。
Service Item Manager
Service Item Manager モジュールによって、サービス設計者はサービス項目の作成と管理ができます。サービス項目定義は、サービス項目に関連付けられている属性を指定します。たとえば、ラップトップ サービスには、モデル、型、資産 ID またはシリアル番号などがあり、ソフトウェア ライセンスには、アプリケーション、バージョン、レベル（Standard または Professional）、その他のベンダー依存情報などがあります。
ユーザによる設定が可能なサービス項目に加えて、Request Center には、事前に設定されているサービス項目の 1 つのタイプ：VMware で設定される仮想マシンが含まれます。本章には、仮想マシンを管理するためのサービスの設定方法についての詳しい手順が記載されています。『 Cisco Service Portal Integration Guide 』には、Request Center のインターフェイスを vSphere 4.1 vCenter サーバに実装する Service Link「エージェント」の設定方法についての詳しい手順が記載されています。
Service Item Manager モジュールによって、vCenter サーバとの通信管理がさらに強化され、vCenter と VMware サービスのユーザ インターフェイスをカスタマイズできるようになります。Service Item Manager で、仮想ハードウェア、仮想マシン テンプレート、設定オプションに関するデータを、一連の「Virtual Data Center Standards」へインポートできます。次に、VMware サービスは、これらの標準を参照データとして使用して、ユーザ データ項目の検証などを行うことができます。この検証では、仮想マシンのプロビジョニングまたは設定において、ユーザが有効な VMware 仮想マシン テンプレートあるいは適切な設定オプションを選択していることを確認します。
Service Designer
Service Designer は、サービス要求を定義するために使用されるモジュールです。サービス要求には、そのプレゼンテーション、承認と提供計画、ユーザとタスク実行者がオーダー フォームに指定するディクショナリ形式の必須データ、現在のコンテキストに適合するように、そのフォームの外観と動作を動的に調整できるオプションのルールが含まれます。
サービス項目タスクは、特殊な種類のワークフローで、サービスの提供計画内で使用され、要求されたサービス項目のライフ サイクル フェーズを起動します。
Organization Designer
Service Portal で使用可能なすべての機能と同様に、サービス項目と標準の設計、保持、表示を行う機能は、ロールベース アクセス コントロール（RBAC）で管理されます。事前に設定されているロールには、Service Item Manager、Service Item Designer、Service Standards Manager、Service Item Administrator があります。
Service Link
ファイル アダプタを使用することにより、サービス項目と標準は、外部システムからインポートすることができます。この機能は、Service Item Manager のインポート機能により、データをインタラクティブにインポートする方法も提供します。
さらに、VMware vCenter や Amazon EC2 などのサードパーティ製システムと通信するためのエージェントを設定することもできます。これらのエージェントは、サービスのワークフロー内で使用され、このように外部で保持されているサービス項目のプロビジョニングや設定を必要に応じて行うことができます。
サービス項目のエンドユーザのビュー
サービス項目は、サービス要求を経由してプロビジョニングされる際に個人に自動的に割り当てられます。また、サービス項目は、Service Item Manager の手動による割り当て機能により、Request Center のユーザに直接割り当てられることもできます。手動による割り当ては、ユーザが外部システムでサービス項目を割り当てられた場合に特に有効で、そのデータが Request Center に展開される必要があります。
Lifecycle Center の一部として、My Services には、[Service Items] タブと [My Items] ポートレットが用意されています。ここで、ユーザは自分にプロビジョニングされているサービス項目を確認し、この項目への変更や追加を依頼することができます。My Services Consumer ロール（すべての Request Center ユーザに割り当てられているデフォルトのロールで、このロールでサービス要求の送信ができます）には、ユーザが自分のサービス項目を表示したり検索したりできる機能は含まれていません。この機能は、My Services 360-Degree Consumer ロールによって提供されます。このロールには、「My Service Item を表示する」機能と、個々のユーザが [My Items] ポートレットの表示/非表示を制御できる個人設定が含まれます。
詳細については、「My Service Items の処理」を参照してください。
サービス項目と Service Item Manager
Service Item Manager は Service Portal のモジュールで、設計者と管理者がサービス項目のタイプとインスタンスを設計し、サポートしているデータ（または 標準 ）の作成、インポート、管理を行うことができます。ユーザがサービス項目を要求するサービス（オーダー）フォーム用の検証データと参照データが提供されます。
Service Item Manager の分類
Service Item Manager の分類は次のとおりです。
• サービス項目グループ：階層の最上位にあり、[Design Service Items] タブで管理されます。サービス項目グループの Virtual Hardware は自動的に提供されます。これは変更できません。ユーザによる設定が可能なサービス項目を自由に追加することができます。
• サービス項目タイプ：サービス項目グループの子であり、これも [Design Service Items] タブで管理されます。[Virtual Hardware] サービス項目グループには、事前に設定されているサービス項目である Virtual Machine が含まれています。これで仮想データセンター（VDC）サービスをサポートします。このサービス項目は変更できません。このグループ内、または他のサービス項目グループ内にサービス項目をさらに作成したり、管理したりできます。
• サービス項目インスタンス：サービス項目タイプのインスタンスで、[Manage Service Items] タブで管理されます。たとえば、VMware サーバ ホストに設定された仮想マシンは、Virtual Hardware グループの子であるサービス項目タイプの Virtual Machine のインスタンスです。
Service Item Manager の管理画面
Service Item Manager モジュールを選択すると、Service Item Manager の [Home] ページが表示されます。
Service Item Manager の画面には、希望のオプションに対応するタブをクリックするか、オプションの説明をクリックしてアクセスできます。
大半の Service Manager ページは、画面左のリスト パネルと、右のコンテンツ パネルから構成されます。コンテンツ パネルには、サービス項目または標準を表示するグリッドが含まれます。
|
|
|
||
|
|
|
||
|
|
|
• リスト パネルは、折りたたみ表示パネル アイコンと展開パネル アイコンをクリックすることにより、折りたたむことも展開することもできます。
• リスト パネルの幅とコンテンツ パネルの幅は、ディバイダをドラッグして変更することができます。
• グリッド内のカラム幅を変更するには、そのカラムと次のカラムの間にある線にカーソルを置きます。カーソルは、反対側を向いた 2 つの矢印が付いた二重線に変わります。新しいカーソルが表示されたら、左マウス ボタンを押したままドラッグして、カラム幅を調整します。
サービス項目の設計
[Design Service Items] タブに、使用可能なサービス項目グループと関連付けられているタイプが表示され、グループまたはタイプを作成したり、変更したりできます。
プラス（+）記号をクリックし、続いて以下のように表示される [Create (+)] メニューで [Service Item] または [Service Item Group] をそれぞれ選択すると、サービス項目またはサービス項目グループを新たに作成できます。
グループは、グループ名を指定して定義されます。説明を入力することもできます。サービス項目定義は、項目名、表示名、説明（任意）、項目を説明する一連の属性から構成されます。
• 表示名はユーザにとってわかりやすい名前のバージョンで、スペースが入っていてもかまいません。これは、[My Items] ポートレットでサービス項目ベースのディクショナリ用のキャプションの基礎として使用されます。表示名はサイト内で一意である必要があります。
• 項目名は、サービス項目とそのデータをシステムが参照する際の名前です。この名前で使用できるのは、英数字と下線（_）で、スペースは使用できません。名前の先頭は英数字である必要があります。これは、Request Center のトランザクション データベースで動的に作成され、保持されているテーブルに対応します。Service Item Manager は、項目名と同じ名前で、プレフィックスが「Si」のデータベースを作成します。項目名はサイト内で一意である必要があります。
項目の属性で、サービス項目について保持されるフィールド（データ）が指定されます。すべてのサービス項目には、項目に対して固有の ID を示す名前が必要です。次の図や、その後のテーブルに示すように、他の属性も追加できます。
ステップ 1 [Add] をクリックして、サービス項目に属性を新たに追加します。グリッドの最後に空の行が表示されます。ここにサービス項目定義を入力できます。
ステップ 2 1 つ以上の属性を削除するには、削除する属性をクリックして選択し（Ctrl キーを押しながらクリックするか、Shift キーを押しながらクリックして、複数の属性を選択できます）、続いて [Remove Selected] をクリックします。選択項目から属性を削除するには、もう一度その属性をクリックします。
ステップ 3 [Save] をクリックして変更を保存します。
|
|
|
すべての Request Center ページで属性ラベルとして表示される属性の名前。[My Items] ポートレットが含まれます。必要な場合、HTML フォーマット タグを組み込むことができます。 |
|
属性の内部名。基礎となっているデータベースのキーワードや予約語（INTEGER、ORDER、VARCHAR など）は使用できません。名前は 27 文字までに制限されています。 |
|
最後に保存してから追加または更新されたすべての属性に、属性の表示名の右上に赤の三角形が付きます。
サービス項目サブスクリプションまたはサービス項目履歴の一部として自動的に保持される属性は、サービス項目定義に追加しないでください。Customer ID、RequisitionID、およびサービス項目の用途に関するその他の面を含む属性は、「サービス項目ベースのディクショナリの定義」で説明します。
属性タイプ
属性タイプは、属性の値を保存するために使用するデータ タイプを指定します。次のデータ タイプが使用可能です。
|
|
|
既存のサービス項目定義の変更
サービス項目が作成されると、その名前を変更することはできません。表示名は自由に変更できます。
属性はサービス項目定義に自由に追加できます。修正された定義が変更されると、既存のサービス項目には、追加された属性のブランクの値が含まれます。管理者は、[Manage Service Items] オプションを使用して、新しく追加された属性に値を指定できます。
属性は、サービス項目定義から自由に削除できます。既存のサービス項目から属性に対応するデータが削除されます。
既存のサービス項目の属性の表示名は変更できますが、属性の名前は変更できません。データ タイプも変更不可です。これらのいずれかを変更するには、オリジナルの属性を削除し、新しく属性を追加する必要があります。オリジナルの属性に関連付けられているすべてのデータが失われます。
サービス項目ベースのディクショナリがすでに作成されている場合は、サービス項目定義に加えられたすべての変更は、ディクショナリに手動で適用される必要があります。ディクショナリに追加されるフィールドの名前がサービス項目内の対応する属性の名前と一致している限り、そのフィールドと属性の間の関係が保持されます。
サービス項目履歴とサービス項目サブスクリプション
Request Center は、サービス要求により、サービス項目が作成、更新、削除されるたびにそのログを記録します。これらのトランザクションの履歴は、サービス項目履歴テーブルで参照できます。また、サービス項目の現在の状況は、サービス項目サブスクリプションで参照できます。このテーブルは、[My Items] ポートレットから参照できるクエリーの基礎となります。データ取得ルールでもこのテーブルを使用できます。
サービス項目サブスクリプションには、項目に関する次の情報が含まれます。
|
|
|
サービス項目が割り当てられているユーザのホーム OU。この ID は、特定の個人に割り当てられているサービス項目だけでなく特定の OU に割り当てられているサービス項目を照会する場合にも使用することを推奨します。 |
|
|
|
|
サービス項目が割り当てられているユーザのホーム OU。この ID は、特定の個人に割り当てられているサービス項目だけでなく特定の OU に割り当てられているサービス項目を照会する場合にも使用することを推奨します。 |
|
Virtual Machine サービス項目
次のスクリーン ショットにあるように、Virtual Machine の属性には Name、DSN Name、および特定の VM が有効になるように指定する必要のあるその他の情報が含まれています。
Virtual Machine サービス項目の属性の要約については、次の表を参照してください。個々の属性のより詳しい説明と、VMware 操作での属性の使用法については、「VMware 操作の設定」を参照してください。
サービス項目の管理
サービス項目は、次の複数の方法で Request Center リポジトリに追加できます。
• ユーザが Service Item タスクを経由して新規サービス項目をプロビジョニングするサービスを要求する。
• Service Item Import ユーティリティを使用して、サービス項目定義とインスタンスの一方または両方をインポートする。
• Service Link ファイル アダプタを使用して、サービス項目定義とインスタンスの一方または両方をインポートする。
サービス項目の管理
[Manage Service Items] タブを使用すると、サービス項目管理者は次ができるようになります。
• Request Center によって現在追跡されているサービス項目について、これらがシステムに追加されているかどうかにかかわらず、確認を行います。
既存のサービス項目は、名前別にアルファベット順でリストされます。
使用可能なアクションについて、次の表にまとめます。詳細については、次の段落を参照してください。
|
|
|
サービス項目のリストを CSV（コンマ区切り値）フォーマットのテキスト ファイルにエクスポートし、このファイルを Excel スプレッドシートとして表示します。 |
|
新規サービス項目の追加
ステップ 1 [New] をクリックして、新しいサービス項目を追加します。[New Service Item] ポップアップ ウィンドウが表示されます。
ステップ 4 続いて属性を入力します。[Name] の値は必ず指定してください。[DATETIME] フィールドの値は、「DD-Mon-YYYY」形式で入力する必要があります。同時に「HH:mm」形式で時刻も入力できます（例：01-Dec-2011 13:01）。項目が保存されると、各ユーザの選択した日時形式で、日時が表示されます。
ステップ 5 入力が終了したら [Add Service Item] をクリックします。
フィルタおよび検索
[Filter and Search] オプションを使用すると、表示されるサービス項目を制限することができます。フィルタ基準には、サービス項目を構成するすべての属性と、サービス項目の割り当て先であるカスタマーと組織単位、サービス項目がその個人に割り当てられた日付、サービス項目の作成に使用した要求 ID があります。
デフォルトでは、英数字フィールドのフィルタ基準は「Contains」フィルタを使用します。たとえば、次の図の [Name] フィールドに‘386'（引用符なし）と入力すると、名前にストリング‘386'が含まれるすべてのサービス項目のインスタンスが検索されます。
ビューの保存
現在有効なフィルタと検索条件を保存するには、[Save View] をクリックします。[Manage Service Items] を一度終了してから戻ると、保存したフィルタ基準が有効になります。保存されたビューを変更するには、[Filter and Search] をクリックすると、必要に応じて基準を編集することができます。これらの変更を適用してから [Save View] をクリックすると、ビューが編集されたビューまたは（すべての基準が削除されている場合は）デフォルトのビューに置き換わります。
Export to Excel
サービス項目データをスプレッドシート形式にエクスポートするには、[Export to Excel] をクリックします。コンマ区切り値（CSV）形式のテキスト ファイルが生成されます。このファイルを Excel で開いたり、今後の使用に備えてローカル ディスクに保存したりできます。
サービス項目とサービスの関連付け
[Manage Service Items] タブの [Associated Services] サブタブを使用すると、サービス設計者がサービス項目と 1 つ以上のサービスを関連付けることができます。
サービスをサービス タイプの項目と関連付けると、My Services のユーザは、ショートカットを使用して、以前サービスに割り当てられていたサービス項目に適用可能なサービスを順序付けることができます。ユーザは、My Services のカタログでサービスを検索しなくても、[My Items] ポートレットにサービス項目を表示できます。サービス項目が選択されると、ユーザに順序付けの権限がある関連サービスがすべて表示されます。
ユーザが関連サービスをクリックすると、サービス フォームが表示されます。そのサービスが（「アクティブ フォーム コンポーネントの設定」で説明しているように）正しく設定されていると、サービス フォームにはユーザのサービス項目に関する情報が事前に入力されています。
原則的には、サービス項目のライフ サイクルに影響するすべてのサービスは、そのサービス項目のタイプに関連付けられている必要があります。これは実際には、サービス項目の作成、更新、または削除を行う Service Item タスクが含まれるすべてのサービスが、サービス項目のタイプに関連付けられている必要があるという意味です。
標準の定義
Service Item Manager には、「ユーザによって定義された標準」を指定する機能があります。この標準は、カスタム テーブル形式で提供され、アクティブ フォーム コンポーネントの設計、特にデータ取得ルールにおいて、サービスの順序付けを行う際に、カスタマーが特定の回答や選択まで「ドリルダウン」できるようにします。 実際には、標準の主な役割は（これだけではない場合もあります）、ユーザ項目の検証に使用される参照データをサービス フォームに提供すること、またはそのフォームにフィールドのデフォルト値を提供することです。
標準テーブルは、外部のデータソースで保持されるリレーショナル データベース テーブルと同じ機能を実行します。つまり、（ドロップダウン リストでの）表示または（ユーザから提供されたデータの）検証のために、行が取り出されます。データ取得ルールの影響を受けるディクショナリ フィールドが、サービス項目ベースのディクショナリにあるかどうかにかかわらず、標準テーブルと外部テーブルは、両方とも前述の方法で使用できます。
• 標準テーブルの保持は、Lifecycle Center 内で完全に可能です。テーブルを作成したり、その構造を変更したり、内容を維持したりするために DBA を介入させる必要はありません。Lifecycle Center は、標準レコードの作成、削除、または変更を行うためのユーザ インターフェイスを提供するだけでなく、XML ファイルから標準テーブルへのデータのインポート機能、あるいはこのテーブルの構造を作成したり変更したりする機能、またはこの両方の機能も提供します。
• 標準テーブルは、標準データソースで standard を選択することにより、テーブル ベースのデータ取得ルールで直接使用されます。SQL クエリーのデータ取得ルール、または SQL ベースのオプション リストの構成でも使用できます。standard のデータベース テーブルの名前は、標準プレフィックスの「St」で始まります。
• Lifecycle Center には、VMware 要求と一緒に使用する標準テーブルがいくつか事前に設定されています。これらの標準のデータは、手動で入力するか、既存の vCenter インスタンスからインポートできます。
なんらかの標準が定義されると、次の手順として、ご使用の Request Center のインストール環境に関連するデータを標準テーブルに取り込む必要があります。データが提供されると、データ取得ルールまたはオプション リストで標準データが使用できます。
標準テーブルの使用
Request Center 内で標準テーブルを使用するには、次の手順を実行します。
1. 標準テーブルの機能要件を指定します。各テーブルに含まれる必要のあるデータは何ですか?それは Request Center 内でどのように使用されますか?
2. 標準を定義するには Service Item Manager を使用します。仮想データセンター標準の場合、標準定義の確認はできますが、変更はできません。
標準テーブルの定義
[Design Standards] タブに、使用可能な標準グループと関連付けられている標準が表示され、グループまたは標準を作成したり、変更したりできます。
プラス記号（+）をクリックし、次に [Create] メニューから [New Standard Group] を選択して、標準グループを新たに作成できます。グループは、グループ名を指定して定義されます。説明を入力することもできます。
標準定義は、標準名、表示名、説明（任意）、標準を含む一連の属性から構成されます。
• 表示名はユーザにとってわかりやすい名前のバージョンで、スペースが入っていてもかまいません。
• 標準名は、標準とそのデータをシステムが参照する際の名前です。これは、Request Center のトランザクション データベースで動的に作成され、保持されているテーブルに対応します。標準名で使用できるのは、英数字と下線（_）で、スペースは使用できません。名前の先頭は英数字である必要があります。Service Item Manager は、標準名と同じ名前で、プレフィックスが「St」のデータベースを作成します。
属性で、標準について保持されるフィールド（データ）が指定されます。すべての標準に、名前が必要です。次の図や、その後のテーブルに示すように、他の属性も追加できます。
|
|
|
すべての Request Center ページで属性ラベルとして表示される属性の名前。[My Items] ポートレットが含まれます。 |
|
属性の内部名。基礎となっているデータベースのキーワードや予約語（INTEGER、ORDER、VARCHAR など）は使用できません。名前は 27 文字までに制限されています。 |
|
仮想データセンターの標準
VM サービス項目の作成とメンテナンスをサポートするために必要な参照データ（標準）を確認するには、[Design Standards] タブを使用します。これらの標準定義は、「仮想データセンター」のグループの一部として提供されます。
VMware サービスは、これらの標準を使用して、有効な VM 設定オプションのみを確実に要求できるようにします。大半の標準のデータは、このマニュアルの後半で説明する [Import Data] オプションを使用して、vCenter サーバからインポートできます。
|
|
|
|
標準の管理
Request Center は、データを標準テーブルに追加するため次の方法をサポートします。
• 標準データをインタラクティブに編集するには、Service Item Manager の [Manage Standards] タブを使用します。
• 標準データと標準定義の一方または両方をファイルからインポートし、仮想データセンター標準を vCenter インスタンスからインポートするには、Service Item Manager の [Import Data] タブを使用します。
[Manage Standards] タブは、標準に指定されたすべての属性が含まれるグリッドを提供します。新しい標準の作成、既存の標準の属性値の変更、または 1 つ以上の入力の削除ができます。
標準をインポートするための [Import Data] オプションについては、「サービス項目と標準のインポート」を参照してください。
デフォルトでは、データ取得ルールによって指定された標準を参照するサービスが配置される際に、Catalog Deployer で、標準入力が配置されます。管理設定を「標準入力を配置」に変更することにより、この動作を上書きすることができます。これは、たとえば、実稼働環境での管理者が、すべての標準を実稼働環境またはテスト環境で定義するよりも、標準を保持する責務がある場合に適しています。
サービス項目ディクショナリの設定
サービス項目が設計されると、サービス要求中に収集される、そのサービス項目に関するデータを保持するディクショナリが必要です。このディクショナリ中のフィールドで、サービス項目に保存されるデータが提供され、サービス項目の履歴とそのサブスクリプションの更新に役立てることもできます。
サービス項目ベースのディクショナリの定義
[Service Designer] に移動し、[Dictionaries] オプションを選択します。[New] > [Dictionary] の順にクリックすると、[New Dictionary] ページが表示されます。以前定義されたサービス項目でディクショナリを対象にするには、[Service Item] ラベルの右側にあるテキスト ボックスに、対象のサービス項目の名前の 1 文字以上を入力します。「*」と入力すると、すべてのサービス項目が検索されます。対象のサービス項目をクリックします。
[Dictionary] ページが表示されます。ページの先頭に通常どおり入力します。
[Category]、[Service Item Group]、[Service Item Type] には入力できません。これらのフィールドの値は、それぞれ [Service Items]、このディクショナリを基盤とするグループ、サービス項目のタイプに設定されます。前のリリースと同様に、[Service Item Family] は Request Center では使用されず、すべての値が指定できます。この値は Request Center のデータ マートでのクエリーとグループ化に使用できます。
サービス項目ベースのディクショナリには、次のタイプのフィールドが含まれます。
• ディクショナリと組み合わせて使用できるサービス項目サブスクリプション（履歴）および提供履歴に関するフィールド。これらのフィールドは、サービス項目の現在の使用状況とサブスクリプション履歴に関する追加情報を提供します。
• Virtual Machine サービス項目専用：VMware アダプタで実行される操作に関するフィールド。
ユーザによって定義されたサービス項目に基づいたディクショナリの定義は、次のようになります。
|
|
|
|
|
|
|
|
サービス項目フィールド
ユーザによって定義されたサービス項目で指定される属性は、デフォルトで、その項目に基づいたディクショナリに含まれます。フィールド名の左にあるチェックボックスを選択することにより、ディクショナリに入れるフィールドを組み込むことができます。[Name] フィールドはディクショナリに必ず組み込む必要があります。サービス項目内の他のフィールドの組み込みは任意です。すべてのデータ タイプは、サービス項目定義から継承されます。[Name] フィールドには予約データ タイプの [ServiceItemIdentifier] があり、[Show in Grid] が選択されています。
Virtual Machine サービス項目の場合、[Name] フィールド（VirtualMachineName に対応する）のみが、ディクショナリに自動的に組み込まれます（選択されます）。これにより、統合設計者は、実行される VMware 操作と、操作の必須フィールドに対してディクショナリの設計をカスタマイズすることができます。
サービス項目サブスクリプションと履歴フィールド
[Dictionary] ページに表示される次の一連のフィールドは、サービス項目サブスクリプションと履歴用に保持されるデータに対応します。事前に設定されているサブスクリプション フィールドの場合は、フィールド名の左にあるチェックボックスを選択するだけで、入れるフィールドが選択されます。
[Service Item Subscription] フィールドは、次のテーブルにまとめられています。これらのフィールドは、ディクショナリに組み込まれていなくても、適切な値が入力された状態で、サービス項目の履歴とサブスクリプション データに自動的に組み込まれます。これらをディクショナリに組み込むのは、Request Center がこれらのフィールドに値を提供するために使用するデフォルトの動作を補足または上書きするためです。
要求のサブスクリプションおよび履歴データは、サービス項目の作成または更新タスクがサービス項目に対して実行される際に記録されます。CustomerID および OrganizationalUnitID がサービス項目ベースのディクショナリに組み込まれていない場合、Request Center はそのデフォルト ロジックを使用して、各フィールドに値を指定します。フィールドがディクショナリに組み込まれていると、サービス項目のタスクが実行される時に、フォーム フィールドの値が使用されます。
|
|
|
ディクショナリに CustomerID または OrganizationalUnitID が含まれている場合、サービス設計者は、フィールドに値を指定するためのルールやその他のメカニズムを記述する責任があります。
Request Center のデフォルトの動作を上書きするためのシナリオとして、次のものがあります。
• サービス項目（SI）を所有者なしで作成します。つまり、このサービス項目へは誰も登録されていません。たとえば、新しいラップトップが届き、まだ誰にも割り当てられていない状態などが該当します。これは、[Manage Service Items] タブでサービス項目を手動で作成するか、外部ソースからサービス項目をインポートする代替手段となります。このシナリオでは、CustomerID と OrganizationalUnitID の両方がサービス フォームに含まれています（オーダー段階ではルールによって非表示になっている可能性があります）が、値は指定されていません。
• 要求の発信者が、サービス項目のカスタマーを（個人ベースのディクショナリから）明示的に選択することができます。カスタマーの情報をサービス項目ベースのディクショナリ（SIBD）に含まれている CustomerID フィールドと OrganizationalUnitID フィールドにコピーして、デフォルトのカスタマー（発信者）を上書きします。このシナリオについては、「ベスト プラクティス」で詳しく説明します。
• 所有者（CustomerID に対応している個人）を指定せず、所有している OU を指定して SI を作成します。たとえば、あるプロジェクト チームがサーバを必要としますが、そのサーバは個人ではなくチームが管理します。このシナリオは前述のシナリオと似ていますが、ディクショナリに含まれる必要があるのは CustomerID のみです。CustomerID の内容は、オーダー段階でルールによってブランクになります。OrganizationalUnitID を割り当てます。割り当てはどのようにして行われますか?発信者またはカスタマーの OU ID を継承するか、個人検索機能を使用して、OU またはカスタマーを選択します。
• いずれかのサービス項目の割り当てを解除します。たとえば、従業員の退職や、プロジェクトと機器の割り当ての一時的な解除などです。
• データ取得ルールを実行して、SI が作成されたときの情報（どの要求 ID と要求エントリ ID が前のオーダーに含まれていたか、など）を表示します。
エラーの説明フィールドには、サービス項目タスクに失敗した場合のフィードバックが記述されます。これは、開発者にとって有効なデバッグ ツールで、データ入力の検証に必要な場合がある条件付きルールについての情報を提示します。
サービス項目の作成に失敗する理由は、サービス項目の作成で、項目名をブランクにしたままであるか、既存のサービス項目と名前とタイプが同じものを作成しようとした、などが考えられます。こうしたタスクが失敗すると、サービス項目は作成されず、要求に対して加えられた変更はすべてロールバックされます。同様に、参照される項目が存在しない場合、サービス項目の更新または削除のタスクが失敗する可能性があります。
仮想マシンの操作フィールド
仮想マシンの「操作」フィールドは、vCenter サーバで実行されるアクティビティを指定します。VMware 統合で使用されるすべてのディクショナリに操作フィールドが組み込まれている必要があります。
一部の VMware 操作は、既存の仮想マシンを再設定するために使用されます。これらの操作では、ディクショナリ フィールドの ReconfigOperation と ReconfigurationType も必要です。
これらのフィールドの詳しい使用法については、「VMware 操作の設定」を参照してください。
仮想マシンに基づいたサービス項目ディクショナリで使用できる操作関連フィールドは次のとおりです。
|
|
|
|
|
ユーザによって定義されたフィールド
サービス項目の設計者は、すべてのサービス項目ベースのディクショナリにフィールドを追加できます。こうしたフィールドは、サービス項目自体に該当しない場合がありますが、サービス項目に関連するサービス要求の重要な部分です。たとえば、カスタマーがこの項目を要求した理由についてのコメントや、項目の使用状況に関連付けられた初期月次コストまたは定期月次コストなどを含むことができます。フィールド名が、使用可能なサービス項目履歴またはサービス項目サブスクリプションのフィールド名と同じではいけません。これは、フィールドがこのディクショナリに含まれていなくても、適用されます。
このようなフィールドは、フォームとフォーム用ディクショナリ データに含まれるデータとなるだけです。サービス項目の一部として記録されることはなく、サービス項目履歴およびサービス項目サブスクリプションのクエリーからは表示できません。ただし、ディクショナリ フィールドと同様に、完了した要求では表示が可能で、ディクショナリまたはディクショナリを含むサービスが、レポート可能になっている場合は、Advanced Reporting モジュールからレポートが可能です。
サービス項目ベースのディクショナリの保持
SIBD を作成し、次に対応するサービス項目に新しい属性を追加しても、Request Center はその属性に対応する新しいフィールドをディクショナリに自動的に追加 しません 。新しいフィールドは手動で追加する必要があります。属性名（Display Name でなく Data Name）と同じ名前をフィールドに使用していると、Request Center は、サービス項目内の属性と、ディクショナリ内のフィールドを適正に同期化します。
同様に、SIBD を作成し、次に対応するサービス項目から属性を 削除 しても、Request Center は削除された属性に対応する新しいディクショナリ フィールドをディクショナリに自動的に削除 しません 。削除は手動で行う必要があります。削除を行わないと、サービス項目に対応するデータのないフィールドがフォームに含まれることになります。
仮想マシン ディクショナリでのフィールドの指定
仮想マシン SIBD は、vCenter サーバでの操作用に、Service Link VMware アダプタと併用する属性を提供します。必須フィールドと任意フィールドは、「VMware 操作の設定」で説明しているように、関連する操作のタイプにより異なります。一般的に、仮想マシンとデータセンター名の各フィールドはすべての操作で必須です。
Request Center は、指定された操作に基づき、フォームでのフィールドの表示/非表示の切り替えを自動で行ったり、フィールドのデフォルト値を提供したり しません 。したがって、別の VMware 操作に使用しているディクショナリの場合、すべての必須フィールドが取り込まれるように、サービス フォームを設計する必要があります。
クローン、作成、再設定の各操作が正常に完了すると、Virtual Machine サービス項目は vCenter からサポートされるすべての属性の最新の値で更新されます。インバウンド更新は、ディクショナリに含まれるフィールドに対応しません。
仮想マシン サービス項目の所有者は、仮想マシンの作成または更新のために VMware 操作を呼び出す要求のカスタマーに自動的に設定されます。次の操作により、デフォルトのオーナーシップ割り当てを上書きできます。
• CustomerID と OrganizationalUnitID の一方または両方をサービス項目ベースのディクショナリに組み込む
アクティブ フォーム コンポーネントの設定
SIBD が定義されると、アクティブ フォーム コンポーネントに組み込むことができます。組み込みの手順は、フォーム コンポーネントにディクショナリを組み込む際の手順と同じです。[Form Content] タブで、[Add Dictionaries] をクリックし、ポップアップ検索ウィンドウからディクショナリを選択します。必要に応じて、フォーム コンポーネントでディクショナリとフィールドの一方または両方の表示順を変更することができます。
サービス項目ベースのディクショナリの表示プロパティ
SIBD には 1 個の固有のプロパティ（既存のサービス項目インスタンスに関するデータを自動的に取得し、事前入力する機能）があります。選択されたフォームでは、このオプションは次のようにサービス項目ベースのディクショナリの [Display Properties] タブに含まれます。
[Enable automatic retrieval of service item instance data] は、サービスが既存のサービス項目の更新か削除に使用される場合、通常は選択されている必要があります。この事前入力機能を利用するには、同じサービス項目ディクショナリに基づいた、2 つのフォーム コンポーネントが必要な場合があります。1 つは項目が作成されるサービスに、もう 1 つは項目を更新または削除するサービスに含まれます。
データ取得ルールでのサービス項目の使用
サービス項目は、テーブル ベースのデータ取得ルールで使用できます。
1. ルールを新たに作成し、その名前、説明、起動するイベントを指定します。
2. クエリー タイプとして [Database Table Lookup] を選択します。
3. ルール ウィザードの 2 ページ目が表示されます。Datasource として [Service Items] を選択できます。
[Table Name] のドロップダウン リストには、次の値が入ります。
• Service Item Manager で定義されたすべてのサービス項目。ユーザによって定義されたサービス項目と、すべての Service Portal インストール環境で提供される仮想マシン サービス項目の両方を含みます。
• サービス項目の履歴を追跡するために自動的に保持されるテーブルの ServiceItemHistory
• サービス項目のサブスクリプション（現在の状況）を追跡するために自動的に保持されるテーブルの ServiceItemSubscription
テーブル ベースのデータ取得ルールに対して行ったように、ルール定義の完了に進むことができます。ルール定義の詳細については、「アクティブ フォーム コンポーネント」を参照してください
システムがサービス項目に割り当てるデータベース テーブルの名前を参照することにより、SQL 入力データの取得ルールにサービス項目を使用できます。テーブルの名前は、プレフィックス「Si」から始まり、そのあとにテーブル名が続きます。スペースは削除されています。データベース テーブルの名前を探し出す（[Manage Service Items] ページに戻らずに、項目名を検索する）簡単な方法は、サービス項目を使用して、テーブル ベースのルールを定義し、保存する方法です。[Summary] ページに含まれる生成された SQL にはテーブル名が含まれます。
データ取得ルールでの標準の使用
サービス項目と同様に、テーブル ベースのデータ取得ルールと、SQL 入力のデータ取得ルールの両方で、標準を自由に使用できます。
提供計画の設定
サービス項目のライフ サイクルには、次のような多くのイベントが含まれます。
• サービス項目が作成され、これを要求した個人（または、サービス フォームでインテンド ユーザとして指定された個人）に割り当てられます
• サービス項目が、その状況と設定における変更を反映するために更新されます
• サービス項目がサービス停止となり、リポジトリから削除される必要があります
仮想マシン以外のすべてのサービス項目のタイプについて、これらのイベントがそれぞれ、サービス項目タスク（SIT）として実装されます。このようなタスクは、サービス項目に対するサービス項目ベースのディクショナリを含むサービスの提供計画に統合できます。サービス項目タスクが実行されると、サービス項目について、タスクで示すように、プロビジョニング、更新、または削除が行われ、このトランザクションの履歴が記録されます。
仮想マシンでは、VMware アダプタを使用するように設定された Service Link エージェントが、タスクのワークフロー タイプとして選択されます。このエージェントのプロパティで、実行される VMware API の操作が決まります。
外部システムで管理されるサービス項目でのライフ サイクル イベントの場合、サービス項目の詳細がサービス要求から抜けていることがあります。これは、要求されている親のサービス項目に従属しているためです。典型的な例として、複数の仮想マシンのプロビジョニングでもたらされる仮想アプリケーションの要求があります。要求側には、仮想アプリケーションの説明のみが提示され、仮想マシン用のサービス項目ベースのディクショナリは、サービス フォームの一部ではありません。この状況では、仮想マシン サービス項目の詳細を取得するサービス項目タスクを使用することができません。このような場合、インバウンドのサービス項目リスナー アダプタのあるエージェントを提供ワークフローで使用して、サービス項目の作成、更新、削除操作に対する外部システムからの着信要求を処理することができます。
内部サービス項目タスクの設定
サービス項目タスクを提供計画に統合するには、次の手順を実行します。
ステップ 1 [Service Designer] > [Services] の順に選択してサービスを編集します。[Plan] タブを選択します。
ステップ 2 [Plan] タブの [General] サブタブで、[Workflow] ドロップダウン リストから [Service Item Task] を選択します。これは常時最後のワークフロー タイプで、その後には外部タスクが続きます。
ステップ 3 [General] サブタブで残りの項目を指定します。このタスクはすぐに完了するので、[Task Duration] は名目上の値（またはゼロ）にしておいてかまいません。
ステップ 4 [Save] をクリックしてタスクを保存します。サービス項目タスクが保存されると、[WorkFlow Type] の右に省略記号（...）が表示されます。
ステップ 5 この省略記号をクリックします。サービス項目タスクについて詳細を指定するポップアップが表示されます。
ステップ 6 [Service Item] ドロップダウン リストから、タスクに適用するサービス項目を選択します。
ステップ 7 適用する操作（Create、Update、または Delete）を [Operation] ドロップダウン リストから選択します。サービス項目タスクの操作については、次のセクションで詳しく説明します。
ステップ 8 [OK] をクリックして、タスク定義を保存し、このウィンドウを終了します。
サービス項目タスクの操作
サービス項目タスクの操作では、Request Center に、サービス項目の作成、更新、または削除を指示します。サービス項目タスクは、サービスのワークフローにおいて、タスクの順序別に指定されたとおりに実行されます。
サービス項目の作成
サービス項目タスクが操作タイプ「Create」を指定して実行されると、Request Center は次の処理を行います。
• サービス項目のエントリをサービス項目ナレッジ ベースに作成します。このエントリには、データがサービス フォームから指定されているサービス項目のすべての属性が含まれます。
• サービス項目のエントリをサービス項目サブスクリプション テーブルに作成します。このテーブルには、すべてのサービス項目とその現在の状況が記録されます。
• カスタマー、現在の要求、要求が送信された日時、サービス項目が作成された日時を記録します。
• サービス項目のエントリをサービス項目履歴テーブルに作成します。このテーブルには、サービス項目を作成した要求が記録されます。
サービス項目の更新
サービス項目タスクが操作タイプ「Update」を指定して実行されると、Request Center は次の処理を行います。
• サービス項目のエントリをサービス項目ナレッジ ベースで更新します。
• サービス項目のエントリをサービス項目サブスクリプション テーブルで更新し、変更されたサービス項目の状況が反映されます。
• サービス項目のエントリをサービス項目履歴テーブルに作成します。このテーブルには、サービス項目の状況に影響するすべての操作（およびサービス項目のタスクが発生する場合での要求）が記録されます。
サービス項目の削除
サービス項目を削除すると、システムからサービス項目のすべてのトレースが、履歴とともに削除されます。この処理を本当に行ってもよろしいですか?項目を削除すると、項目へのすべての参照が消去されます。履歴も同時に消去されます。シナリオによっては、属性を「Inactive」または「Defunct」にマークしてサービス項目に組み込むか、このような項目をプロビジョニングすることを禁止する条件付きルールを記述したほうがいい場合があります。
サービス項目のサブスクリプション処理ルール
サービス項目サブスクリプション テーブル内のカスタマーと組織単位に関する情報は、要求の情報とは別個に設定に設定することができます。
• 作成操作でサブスクリプション情報が提供されていないと、要求のカスタマーとその個人のホーム組織単位に項目が割り当てられます。
• サービス項目インスタンスが作成されたときに Customer ID のみが指定されていると、項目の Organizational Unit ID がカスタマーのホーム組織単位に設定されます。
• Customer ID または Organizational Unit ID のいすれかに値が指定されていると、その値はサービス項目サブスクリプションを更新するために使用されます。値がヌルまたはゼロの場合、対応するサブスクリプション フィールドがヌルに設定されます。サービス項目ベースのディクショナリにプロパティが存在しない場合、属性値に変更/上書きが行われません。
• ディクショナリに指定された Requisition ID と Requisition Entry ID は無視され、サブスクリプション レコードの更新には使用されません。
カスタマーと組織単位の割り当てで可能な組み合わせとその結果は次のように要約されます。
|
|
|||
|
|
|
||
|
|
|
|
|
|
|
|||
|
|
|
||
|
|
|
|
|
外部サービス項目タスクの設定
Service Item Listener アダプタ ベースの外部タスクを提供計画に統合するには、次の手順を実行します。
1. Service Link に新しいエージェントを定義し、コンテキスト タイプに「Service Task」を指定します。
2. アウトバウンド アダプタとして「Dummy」アダプタを指定し、インバウンド アダプタとして「Service Item Listener」アダプタを指定します。変換は不要です。
3. アウトバウンド アダプタ プロパティおよびインバウンド アダプタ プロパティの設定と、アウトバウンド パラメータの設定を行うページをスキップします。
4. 必要に応じて、ディクショナリ フィールドを更新するインバウンド エージェント パラメータを定義します。
5. サービスの [Plan] タブを編集して、外部タスクを組み込み、上記で作成されたエージェントを [Workflow] ドロップダウン リストで選択します。
6. 外部タスクに対して行う場合と同様に（「ワークフローでの外部タスク」を参照）、必要なエージェント パラメータ マッピングを定義します。
外部サービス項目タスクの操作
ワークフローで外部サービス項目タスクがアクティブになる（つまり、状況が進行中となる）と、Service Link はサービス項目の作成、更新、または削除を行うための受信要求をリッスンします。サービス項目リポジトリに加えられた変更は、内部サービス項目タスクの変更と同様です。着信要求のチャネル ID により、Service Link はサービス項目履歴の追跡に使用されるサービス要求を特定できます。
外部タスクの代表的なものである他のタスクの更新（コメントの追加やパラメータ更新の送信など）を着信要求から実行することもできます。すべてのサービス項目操作が正常に処理されると、タスクを完了するために「完了」アクションを送信する必要があります。これで、提供計画での次のタスクを起動できます。
Service Item Listener アダプタと、インバウンド サービス項目メッセージの仕様の詳細については、『Cisco Service Portal Integration Guide』の「Service Link」の章を参照してください。
VMware 操作の設定
すべての VMware 操作は、Virtual Machine サービス項目に基づいたディクショナリの使用により設定されます。このディクショナリのフィールドは、（アクティブ フォーム ルールから「自動的」に、またはユーザ データ エントリを経由して）指定された値です。次に、指定されたディクショナリの値が、サービスの提供計画の一部として呼び出された VMware エージェントを経由して vCenter サーバに渡されます。
VMware アダプタ タスクを提供計画に統合するには、次の手順を実行します。
ステップ 1 [Service Designer] > [Services] の順に選択してサービスを編集します。[Plan] タブを選択します。
ステップ 2 [Workflow] ドロップダウン リストから適切な VMware エージェントを選択し、[General] タブで残りの項目を完了したら [Save] をクリックします。
ステップ 3 [Workflow Type] タイプの右に省略記号（...）が表示されるようになるので、これをクリックすると、[Service Link Agent Parameter Override] ダイアログが表示されます。
ステップ 4 [Outbound Parameter Mappings] セクションの Dictionary_Name_Lookup パラメータで、VMware 操作の詳細が含まれる VM ディクショナリ名を [Service Data Mapping] フィールドに入力して [Apply] をクリックします。
ステップ 5 [Save] をクリックしてエージェント パラメータ マッピングを保存します。
ステップ 6 [X] をクリックしてポップアップ ウィンドウを閉じます。
複数の VMware 操作に対して提供計画が必要である場合、個々の操作と一致するため、適切な VM ディクショナリを参照する別々のタスクを作成する必要があります。
仮想マシン ベースのディクショナリ内のフィールドは、次のように設定されます。
• VMware 操作（アクション）は、仮想マシン ディクショナリ内の「Operation」フィールドの値として指定されます。これらの操作は、標準テーブルの Vituperation にリストされたエントリに対応しており、大文字と小文字が区別されます。この値の設定は、通常、サービス設計者によって実行され、フィールドは、サービスの要求元には表示されません。
• 既存の VM を再設定する VMware 操作では、ReconfigOperation フィールドを使用する必要があります。
• 一部の再設定操作でも、ReconfigurationType フィールドを使用する必要があります。
• 通常は、すべての操作で、DatacenterName フィールドと VirtualMachineName フィールドに値を指定する必要があります。
• 後続のセクションで説明しているように、特定の操作では、他のディクショナリ フィールドの使用が必要な場合があります。
サポートされる VMware 操作の詳細は、次のセクションで説明しています。これらのセクションには、vSphere vCenter に渡される値を指定するため、各操作で使用する可能性のあるディクショナリ フィールドがリストされます。オプションのフィールドは角カッコ（[]）で囲まれています。
インスタンス管理
仮想マシンの作成
仮想マシンのクローン
事前に定義されている VM またはテンプレートに基づき、2 つの操作が仮想マシンを作成することができます。クローン ソースが電源オン状態の VM である場合に適用可能なのは「coldClone」操作のみです。クローンが起こる前にソース VM の電源はオフになり、その後オンになります。
仮想マシンの削除
「delete」操作は vSphere vCenter から仮想マシンを削除し、Request Center のサービス項目リポジトリから VM に関するすべてのサービス項目履歴とサブスクリプションのデータを削除します。
|
|
|
|
電源操作
すべての電源再投入操作では、仮想マシン名が仮想マシンの汎用一意識別子（UUID）（使用可能な場合）に置き換えられます。
|
|
|
|
スナップショット管理
取得したスナップショットには VM のメモリは含まれません（オプション [Snapshot the virtual machine's memory] は、ネイティブ クライアントでは選択されません）。
|
|
|
|
|
削除対象のスナップショットの「ツリー」の下にある連続する一連のスナップショットも VM から削除されます。たとえば、VM のスナップショットが 2 個連続でとられている場合、最初のスナップショットが削除されると、2 番めのスナップショットも削除されます。 |
|||
仮想マシンの再設定
仮想マシンの再設定には多くの操作が使用できます。これらの操作のすべてで、VMOperation の値は「 reconfigure 」です。ReconfigurationType パラメータと ReconfigOperation パラメータが別の値になっていると、別のリクエストであるはずです。
vCenter センターからのインバウンド応答
エラー メッセージ
vCenter サーバが操作を正常に完了できない場合、エラー メッセージが vCenter サーバから戻り、操作を呼び出したサービス要求に VMware エージェントから配信されます。このメッセージは仮想マシン ディクショナリ内の ErrorDescription フィールドで確認できます。
Service Link パースペクティブからは、エラー メッセージを受信しても正常な通信とみなされるため、[Service Link View Transactions] ページの [Messages] リストに表示されるステータスは「Completed」です。サービス要求は、要求側と実行側の一方または両方が、エラー メッセージを利用してワークフローを制御し、必要に応じて通知を生成することができるように設計される必要があります。ErrorDescription フィールドは、Virtual Machine サービス項目から作成する Virtual Machine ディクショナリに含まれている必要があります。ユーザがサービスをオーダーする際のフォーム ルールにより、このフィールドを非表示にすることを考慮してください。
エラー メッセージと推奨処置の一覧については、「VMware Adapter エラー メッセージ」を参照してください。
仮想マシンの詳細
Create、Clone、Reconfigure の各 VM 操作が完了すると、VM インスタンスは Service Portal のサービス項目リポジトリで作成または更新されます。VMware とのインバウンド統合をサポートするすべての属性は、属性が仮想マシン ベースのディクショナリに含まれているかどうかにかかわらず、サービス項目インスタンスに対して更新されます。
デフォルトでは、VM の所有者は、サービス要求のカスタマーに設定されます（別のユーザの代わりに要求がオーダーされると、VM の所有者がその要求の（要求元ではなく）カスタマーとなります）。この動作は、「アクティブ フォーム コンポーネント」で説明しているように、VM ベースのディクショナリを含むアクティブ フォーム コンポーネントを設定することにより上書きされます。
VM の IP アドレスとドメイン名は vCenter サーバで使用可能ですが、VMware エージェントに送信されるインバウンド応答に常に時間内にキャプチャされるとは限らないため、これらの要求の詳細はブランクのままである場合があります。
VM インスタンスは Service Item Manager でアクセスされ、保持されます。データ取得ルールでフィルタリング基準を簡単に使用できるようにするため、個々の VM インスタンスのカスタム属性もここで指定できます。
VM の Delete 操作は、サービス項目リポジトリを更新し、エンドユーザがアクセスできている VM インスタンスを削除します。
その他の考慮事項
サービス項目のデータ ソース
Service Designer では、個人の VM サービス項目のデータ ソースについて、PersonID を CustomerID として使用して、クエリーを実行することができます。次に、データ取得ルールで設定されるドロップダウン リストから、個人が VM を選択する場合、VirtualMachine テーブルへのキーとして VM 名を使用します。2 番めのクエリーから複数の行が戻ることがあります。実際に、このクエリーでは、ユーザに属さない VM が戻る場合もあります。したがって、この場合、複数の結果が戻ることを予想しておく必要があり、どの結果が必要なマシンに適合するか、（DataCenter と Host を追加の識別属性として使用するなどして）ユーザに調査を依頼する場合があります。
仮想マシンの再設定
仮想マシンを再設定するには、仮想マシンの電源をオフにしておく必要があります。再設定 API の呼び出しは、仮想マシンを再設定する要求であり、仮想マシンの電源を自動的にオンにすることはありません。仮想マシンがすでにダウンしている場合は、再設定の要求を続行することができます。再設定の要求を受信したときに仮想マシンが稼働している場合でも、再設定タスクは正常に完了できますが、再設定アクションは、マシンで実行中のプロセスを中断させる可能性があるため推奨されません。実際に、VMware Infrastructure Client から実行されるアクションは禁止されています。したがって、サービス設計者は「reconfigure」タスクの前に「power off」タスクを追加する必要があります。これで、仮想マシンを再設定する後続の要求を続行することができます。「power off」タスクを受信したときに仮想マシンがすでにダウンしている場合は、「power off」タスクが失敗しますが、この失敗による悪影響はなく、「reconfigure」タスクの進行を妨げるものではありません。
VM ディクショナリと仮想マシン テーブルの使用
ディクショナリのフィールドに VirtualMachine テーブルのクエリーを実行するデータ取得ルールからの結果を配信する目的で、仮想マシン サービス項目タイプからディクショナリをインスタンス化すると、HardDisk1 列と Memory 列を配信する際にエラーが発生します。このエラーは、ユーザがフォームを送信しようとするまで発生しません。回避策としては、これらの列をディクショナリのテキスト フィールドに配信する（Customx フィールドのいずれか 1 つと同様）か、ルールで取得される結果の配信元にする別のディクショナリを作成します。
さらに、ユーザが要求できる内容に関して、特定の数値制限の有無を確認する条件付きルールに、HardDisk1 とメモリの一方または両方の値を使用する予定の場合、数値から測定単位のストリングを除外する必要があります。
ディクショナリ テンプレート内の HardDisk1 フィールドと Memory フィールドは、VMware アダプタで「数値」である必要があるため（VirtualMachine テーブルで「ストリング」と記述されていても）、Number フィールドとして定義されます。ディクショナリ テンプレートは、現在の値を取得するデータ取得ルールではなく、エージェントによる使用向けに最適化されます。
サービス項目タスク付き VM ディクショナリの使用
仮想マシン ベースのディクショナリは、サービス項目タスクのある他のサービス項目ディクショナリと同様に使用できます。VMware アダプタ タスクとサービス項目タスクを準備することができ、この両方が、提供計画で同じ仮想マシン ディクショナリを参照します。ただし、実際にサービス項目インスタンスに値を伝送する際に、オプションのフィールドを VM 操作用にブランクにしておくことができます。たとえば、HardDisk1 が「clone」操作でブランクのままであると、VM テンプレート ディスク 1 が現状のまま複製できることを意味します。VM をある個人から別の個人に割り当て直すために、このようなディクショナリが後続のサービス項目タスクで使用される場合、更新アクションでも HardDisk1 がゼロにリセットされます。
VM 属性を不注意に更新することのないようにするため、別の用途に対応する VM ディクショナリを別個に定義しておくことが必要です。データ エントリが重複しないようにするため、ディクショナリ間で値をコピーするフォーム ルールを使用することもできます。
サービス項目のエンドユーザのビュー
My Service 項目の表示
My Service には [Service Items] タブと [My Items] ポートレットがあり、ユーザは、サービス項目に関連付けられたサービスにアクセスしたり、サービスをオーダーしたりできます。サービス項目が個人に割り当てられるのは、サービス要求からプロビジョニングされたとき、または Service Item Manager モジュールを使用して個人に直接割り当てられたときです。
[My Items] ポートレットには、ユーザに最近プロビジョニングされた 5 件のサービス項目が表示されます。[My Items] ポートレットの [More ...] リンクか、[Service Items] タブをクリックすると、サービス項目の完全なリストを表示することができます。[My Items] ポートレットを表示するには、Administration モジュールで、My Services の [View Service Items Portlet] 設定を [On] に設定する必要があります（「[My Items] ポートレットの管理設定」を参照してください）。さらに、個々のユーザがアクセスできるサービス項目は、（「Administration」で説明しているように）ユーザに付与された機能により異なります。ユーザは、[View my service items]、[View service items in my business units] または [View service items in my business units and their sub-units] が可能です。
My Service Items の処理
デフォルトでは、[Service Items] ページには、現在のユーザ（または現在のユーザのビジネス ユニットのメンバー）に割り当てられているすべてのサービス項目が表示されます。表示は次の方法で調整できます。
• 画面左側のリストに表示されているサービス項目グループを展開し、表示する特定のサービス項目タイプを選択する。
• [Filter and Search] ボタンを使用して、検索条件を指定する。
[Service Items] ページには次のサブタブがあります。
• [Related Services]（デフォルトで開いています）によって、ユーザは選択されたサービス項目の設定を変更できるすべてのサービスを要求することができます。
• [Service Item Details] には、選択されたサービス項目のすべての属性の詳細が表示されます。
• [Requested With] には、選択されたサービス項目をプロビジョニングしたのと同じサービス要求からプロビジョニングされたその他のサービス項目（ある場合）が表示されます。
Related Services
[Related Services] サブタブに表示されるサービスは、[My Services] ホーム ページでの検索によって表示されるサービスとまったく同様に機能します。サービス名をクリックしてオーダー前のサービスの概要を表示するか、[Order] ボタンをクリックしてオーダーに直接進むことができます。
Service Item Details
[Service Item Details] サブタブには、現在選択されているサービス項目に関する詳細が表示されます。
[My Items] ポートレットのユーザ設定
エンドユーザは、個人プロファイルの [Preferences] ページで [View My Service Items Portlet] オプションをオフにすることで、[My Services] ホーム ページから [My Items] ポートレットを表示するか、非表示にするかを選択することができます。このプロファイルには、[My Services] ホーム ページの先頭にある [Profile] リンクをクリックしてアクセスします。
サービス項目と標準のインポート
概要
サービス項目が定義されると、使用できるようになります。ただし、サービス項目を参照しているサービスを配置する前に、これらの項目のライフ サイクルについて考慮する必要があります。サービス項目は、Request Center に対して外部である自動システムまたは半自動システムで以前追跡されていましたか?そうである場合、このレガシー情報を Request Center にインポートすることができます。これで、Request Center がサービス項目のプロビジョニングおよびその他の更新を自動的に追跡するために使用できるようになります。
サービス項目のインポートはオプションです。これは通常、以前割り当てられたサービス項目で Request Center のナレッジ ベースを初期化するため、前述のシナリオで実行されます。サービス項目は、Request Center のデータと、外部で保持されていた可能性のあるその他のレコードを同期化するため、いつでもインポートできます。
サービス項目データのインポートに加えて、サービス項目定義自体も、対応するデータ付きまたはデータなしでインポートできます。これでサービス項目の定義が自動化されるため、手動で行う必要がなくなります。
標準も、サービス項目で使用可能な類似オプションを使用してインポートできます。標準定義または標準エントリ、あるいはこの両方をインポートできます。
Lifecycle Center には、サービス項目と標準をインポートするため、次の方法が用意されています。
• Service Item Manager の Import Data オプションにより、管理者はサービス項目または標準をファイルからオンデマンドでインポートできます。
vCenter からの仮想マシンと標準のインポート
Request Center は、vCenter がしばらく使用されている場所にある企業にインストールできます。この場合、VM はすでにプロビジョニングされています。これらの VM をライフ サイクルの残りの期間にわたって保持するために Service Portal を使用するには、VM をインポートする必要があります。
Service Item Manager では、[Import Data] タブで vSphere 接続ユーティリティを使用して、仮想マシン サービス項目のこれらのインスタンスに関するデータをインポートします。
• Service Item Manager の [Import Data] タブで、[Connection] ドロップダウン リストから vCenter インスタンスの名前を選択します。このドロップダウン リストには、Service Link モジュールで定義されている VMware アダプタ エージェントが読み込まれます。
• 画面左に仮想マシン ノードを配置し、右側のグリッドで 1 つ以上の行を強調表示することにより、インポート対象の仮想マシンを選択します。選択されたマシンをインポートするには、右上にある [Import] ボタンをクリックします。
選択されたマシンが仮想マシン サービス項目テーブルに追加されます。vCenter からインポートされた仮想マシンのインスタンスは、インポート日付を割り当て/送信日付として表示します。[Owner] はブランクとなります。組織の担当者を（手動または通常の方法である Directory Integration から）入力すると、仮想マシンを強調表示し、[Assign Owner] ボタンをクリックし、マシンの所有者を選択することができます。これで、マシンの所有者（または所有者の代わりに使用する管理者）が、このマシンの状況に影響するサービス要求を入力できるようになります。
ユーザ（またはユーザの代わりに使用する管理者）が、仮想マシンを作成するサービスをオーダーし、そのサービス要求が履行されると、ユーザの名前とプロビジョニング日付が自動的に記録され、[Manage Service Item Instances] ページに表示されます。
データストアやホストなどの他の vSphere エンティティをインポートするには、左側のペインで各ノードを選択し、前述の仮想マシンのインポートと同じ手順を実行します。選択されたインスタンスが対応する仮想データセンターの標準に追加されます。
ファイルからのサービス項目と標準のインポート
Service Item Manager で、[Import from File] サブタブを使用して、サービス項目と標準の外部ソースからデータをインポートします。サービス項目または標準の定義もインポートできます。インポートされるファイルは、ANSI エンコードを使用している必要があります。ASCII または UTF-8 のいずれも動作します。Unicode エンコードはサポートされていません。
ファイルには、定義セクションとデータ セクションの両方、または一方だけ、あるいは別の部分が含まれます。[Import] オプションによってインポートされるのは、オプションで指定されたように、フィールドのこれらの部分（定義とデータの一方または両方）のみです。
[Definition] オプションを選択した場合で、XML ファイルにデータ セクションしか含まれていない場合は、何もインポートされません。 同様に [Data] オプションを選択した場合で、XML ファイルに定義セクションしか含まれていない場合は、何もインポートされません。
[Definition] と [Data] の両方をインポートする選択をした場合で、XML ファイルに定義セクションしか含まれていない場合は、システムは定義のみをインポートします。 XML ファイルに定義セクションとデータ セクションの両方が含まれていると、この両方がインポートされます。
サービス項目データがインポートされると、サービス項目履歴テーブルにエントリが追加され、必要に応じてサービス項目サブスクリプションが作成または更新されます。
サービス項目のインポート
以下のテーブルには、サービス項目定義とデータの一方または両方をデータからインポートする際のインポート ユーティリティの動作がまとめられています。この動作は、本章の後半で説明する Service Link サービス項目タスクにも適用されます。
標準のインポート
標準データのインポートでは、既存のすべてのデータは常にインポートされたデータで上書きされます。標準データをインポートするオプションは、標準を参照するデータ取得ルールが含まれるサービスの配置での Catalog Deployer の処置を補足するか、置換します。デフォルトでは、Catalog Deployer によって、ソース環境で事前に定義された標準定義とすべてのデータの両方がターゲット環境に配置されます。標準データが環境間で変化しない場合、この動作が推奨されます。その他の場合は、[Deploy Entries (data) in Standards Tables] に対する管理者の設定をオフにすることで、この動作を変更できます。
標準定義のインポートでも、上述のように、サービス項目の定義のインポートについて、同じ競合解決オプションが使用できます。標準データに適用される競合解決は以下のようにまとめられます。
インポート ファイルのフォーマット
各インポート ファイルは、業界標準の CIM（共通情報モデル）互換フォーマット、バージョン 2.3.1 の XML ファイルです。CIM はオブジェクト指向モデルに基づいており、統一モデリング言語（UML）から採用された技術を使用します。Service Portal で使用されるファイル フォーマットを記述する文書型定義（DTD）は、アプリケーション サーバの RequestCenter.ear¥RequestCenter.war¥DTD にあります。
Service Portal は、CIM で使用可能なエンティティのサブセットのみを認識します。認識されないエンティティは、Service Portal で無視されます。Request Center の CIM 実装では、次の
• サービス項目に関する詳細（説明、表示名、割り当てられているグループ（分類））は、サービス項目の 修飾子 です。
• サービス項目に指定された属性は、サービス項目クラスの プロパティ です。
• 各属性（プロパティ）には 修飾子 が付いています。これらの修飾子は、個々の属性の詳細な設定（説明、キャプション、My Services から参照できるかどうか、属性がサービス項目定義で発生する順序）から構成されます。
• 各サービス項目には、多くの インスタンス が含まれていることがあります。これらはそれぞれ 1 つのサービス項目インスタンスに対応します。
• サービス項目の各インスタンスには、サービス項目の属性ごとに 1 つの プロパティ があります。インポート時に、サービス項目のサブスクリプション情報を構成する 3 つの属性（要求エントリ ID、カスタマー ログイン名、組織単位名）も含むことができます。XML ファイル内の値は、サービス項目インスタンスの対応する属性またはサブスクリプション フィールドの値を更新します。
一般に、以前の説明がサービス項目と標準の両方に適用されます。標準は、個々のユーザまたは組織単位自体によっては「所有」されず、したがってこれらにはサブスクリプション属性を設定できないことに注意してください。
サービス項目インポート ファイルの構文
次のテーブルは、サービス項目または標準インポート ファイルの指定に使用する構文をまとめたものです。同じ構文がサービス項目と標準の両方に適用されます。
XML ファイルはそれぞれ 1 つの SI インポート仕様から構成されます。
インポート仕様（SIImportSpec）は、SIClassDefinition と、それに続いて指定されたクラス（サービス項目または標準）に対応する 1 つ以上の SIInstances のリストから構成されます。クラス定義とインスタンスのどちらか一方または両方がファイルに含まれます。ファイルの内容は、指定されたインポート オプションと一致する必要があります。
各 SIClass 仕様は、適切な XML タグ内に組み込まれたサービス項目または標準定義と、それに続く属性ごとの定義から構成されます。
それぞれの属性定義には、名前、キャプション、属性に指定されたその他の設定オプションが指定されます。
サービス項目インスタンス（SIInstance）ごとに、インスタンスが適用されるサービス項目または標準の名前と、項目の各属性の値のリストが指定されます。属性値がブランクの場合でも、属性に値が指定されていないインポート ファイルに適切なタグが引き続き含まれる必要があります。
Service Item Manager を使用してサービス項目または標準を定義すると、データ型は指定されたデータ型と完全には一致しません。次のテーブルを使用して、Service Item Manager のデータ型をインポート ファイルで使用するデータ型にマッピングします。
|
|
|
Datetime（日付値には、yyyy-mm-dd hh:mm:ss フォーマットを使用します。例：2009-04-15 12:00:00） |
サービス項目のサブスクリプション処理ルール
内部サービス項目タスクと外部サービス項目タスクによって実行された create 操作と update 操作とは異なり、ファイルのインポート メカニズムによって処理される create 操作と update 操作はサービス要求の提供計画のコンテキスト外で発生します。したがって、インポート プログラムは、インポート ファイルで提供される Requisition Entry ID、Customer Login Name、Organizational Unit Name 間の関係を検証しません。これらが有効な ID または名前であるかぎり、入力が受け入れられます。
• サービス項目インスタンスの作成時にサブスクリプション情報が提供されていない場合、その項目は未割り当てのままとなります。
• サービス項目インスタンスが作成されたときに Customer Login Name プロパティのみが指定されていると、項目の Organizational Unit ID がカスタマーのホーム組織単位に設定されます。
• Customer Login Name プロパティと Organizational Unit Name プロパティの一方または両方が指定されていると、その値がサービス項目サブスクリプションを更新するために使用されます。値がブランクの場合、対応するサブスクリプション フィールドがヌルに設定されます。インポート ファイルにプロパティが存在しない場合、プロパティ値に変更/上書きが行われません。
• Requisition Entry ID がプロパティに提供されていると、対応する Requisition ID がサービス項目に関連付けられ、My Services および Service Item Manager に表示されます。
• 一度 Requisition Entry ID がサービス項目に設定されると、これを変更したり、ヌルにリセットしたりすることはできません。
カスタマーと組織単位の割り当てで可能な組み合わせとその結果は次のように要約されます。
|
|
|||
|
|
|
||
|
|
|
|
|
|
|
|||
|
|
|
||
|
|
|
|
|
サービス項目インポート ファイルの例
次の定義により「Desktop」サービス項目が作成されているとします。
このサービス項目のインポート ファイルは次の例のようになります。
標準的なインポート ファイルの例
「Projects」標準が次の定義で作成されていると仮定しています。
Service Link のサービス項目タスクは次のエージェント パラメータで定義されます。
Service Link を使用したサービス項目と標準のインポート
サービス項目または標準のインポートには Service Link エージェントを使用できます。これで標準サービス要求にインポート ステップをタスクとして組み込むことができます。このエージェントは、前述のフォーマットのファイルをインポートし、Import from File ユーティリティで使用できるオプションと同じインポート オプションをサポートします。メッセージは Service Link に「SIM Import」メッセージ タイプとして記録されます。
Service Link の使用に関する詳細な手順については、「Cisco Service Portal Integration Guide」を参照してください。Service Link エージェントをサービス項目または標準をインポートするように設定するには、次の手順を実行します。
1. Service Link に新しいエージェントを定義し、コンテキスト タイプに「Service Item」を指定します。少なくとも、標準とサービス項目向けに別個のエージェントが必要です。
2. アウトバンド アダプタとして「Dummy」アダプタを指定し、インバンド アダプタとして「File」アダプタを指定します。変換は不要です。
3. アウトバンド アダプタ プロパティとそのパラメータの設定を行うページをスキップします。
4. インバウンド アダプタ プロパティの場合、インポート ファイルの処理に使用するディレクトリ名を指定します。ファイルは指定された「Input」ディレクトリに書き込まれる必要があります。
5. インバウンド パラメータの場合、4 つのパラメータを作成し、次のテーブルで示すように、[Dictionary] フィールドに適切な値を入力します（パラメータ値は大文字と小文字が区別されます）。
サービス項目インポート DTD
サービス項目または標準インポート ファイルに必要なフォーマットを記述している文書型定義（DTD）が RequestCenter.ear¥RequestCenter.war¥DTD にあるアプリケーション サーバで使用できます。DTD を次に示します。
ベスト プラクティス
サービス項目とは
ディクショナリを設計する際には、これが使用される可能性のあるすべての要求について常に考慮する必要があります。ディクショナリには、これらの要求で必要な可能性があるすべてのフィールドが組み込まれている必要があります。フィールドの外観や使用法は、アクティブ フォーム コンポーネントで常にカスタマイズすることができます。
（ディクショナリとフォーム コンポーネントを再利用される場合に備えて設計する）この原則は、サービスが、カスタマーにサービス（または項目）を提供するための最初の要求だけでなく、サービス項目のライフ サイクル全体にわたって有効である可能性があるため、サービス項目ベースのディクショナリにとって特に重要です。サービス要求に組み込まれるサービス項目タスク（サービス項目の作成と変更やサービス項目の現在の所有者からの除外）をサポートするディクショナリを設計することができます。
ライフ サイクル管理によるデータ統合オプション
Service Portal で作成され、ここで追跡されるサービス項目は、すでに外部のアセット マネジメント システム（AMS）またはハイパーバイザなどのターゲット プラットフォームですでにある程度追跡されています。ラップトップとワークステーション、ならびに仮想マシンと仮想アプリケーションは、このようなサービス項目の良い例です。 このようなサービス項目に対して、Service Portal から数多くのデータ統合の代替が提供されます。選択する特定の代替は、外部システムの成熟度、そのシステムのデータの性質と品質、システムが変更される頻度、Service Portal でのトリガーの変更を含めるシステムにイベントがあるかどうか、などの多数の要因により異なります。
Service Portal のエンドユーザに表示させたいサービス項目の属性（データ要素）も要因となります。たとえば、製造元、型、ラップトップのモデル、あるいは仮想マシンの GUID などは変更されないため、Service Portal での保存や更新を行う必要はありません。ただし、そのデータをエンドユーザが簡単に表示させることができれば、オーダーする後続のサービスに関する決定を行うのに役立つことがあります。
ラップトップの例を使用し、外部アセット管理システムを備えていると仮定した場合、採用できる方法として考えられるものは次のとおりです。
1. 資産 ID を Service Portal のみに保存します 。 ラップトップ SI の唯一の属性は名前（外部システムからの資産 ID の書き込み先）です。My Services では、エンドユーザには、 その属性 のみ（つまり、エンドユーザはラップトップを所有しているということと、そのラップトップの ID）が表示されます。このラップトップがサービス要求で参照されると、次の 2 つの方法のいずれかを使用して、現在のデータ（型、モデル、製造元、ディスク領域、メモリ）を外部システムからフォーム上に引き出します。
– データ取得ルールは、資産 ID に基づき、外部データベースのクエリーを実行します
– Service Link データベースまたは Web サービス アダプタを使用して、外部システムからインバウンド メッセージにデータを取得します
2. 資産 ID と、変更されない属性を Service Portal に保存します 。 ラップトップ SI の属性が、名前（資産 ID）、型、モデル、製造元であると仮定します。 最初の資産 ID のルックアップにより、これらの属性が外部システムからフォーム上に取得され、Service Portal データベースにこれらが保存されます。 このラップトップがサービス要求で参照されると、前述の 2 つの方法のいずれかを使用して、ディスク領域とメモリの現在のデータを外部システムからサービス フォーム上に引き出します （言い換えると、ディスク領域とメモリは Service Portal に保存されることはありません）。
3. #1 または #2 と同様ですが、ビジネスの状況に依存したデータでサービス項目のデータを拡張します 。これは、実際には上記の 2 つの方法のバリエーションにすぎません。 サービスの要求と、これらの要求の達成プロセスの間に収集されたビジネス データが取り込まれ、サービス項目の属性として、Service Portal に書き込まれます。このデータが外部システムに保存されることはありません。
4. すべての属性を Service Portal の単一の「マスター情報」に保存します 。 （インポートによる）最初のロードは、Service Portal にすべてのラップトップを格納するために実行されます。 これ以降、ラップトップの影響を受けるすべての事項が、Service Portal のサービス要求から実行されます。 これで 質問は、外部システムの更新になります。この操作は、手動または Service Link エージェントで実行できます。
5. すべての属性を Service Portal に保存します。変更は Service Portal と外部システムの両方で発生する可能性があります 。 上記 #4 と同様ですが、Service Portal に反映される必要のある外部システムでイベントが発生する可能性があります。 たとえば、現在インベントリにあるラップトップの一覧を確認するため、外部システムを参照できない（つまり、誰にも割り当てられていない）場合があります。データを簡単に取得するため、Service Portal に保存されているすべてのデータが必要な可能性があります。 この場合には、インポート API または Service Item Listener Adapter を使用して、外部システムから Service Portal への更新を処理できます。
上記の方法の すべて が Service Portal で使用できます。 データ取得ルールによって、サービス設計者が簡単に設定できるフォーム データ レベルの統合が実現します。Service Link には、サービス用ワークフローに簡単に組み込まれる「プロセス API」が備わっています。 さらに Web サービス API は、上記には記述がありませんが、外部システムから Service Portal でプロセスを開始するためのもう一つの方法です。これは、Service Portal のデータを更新することが唯一の目的である要求を送信するために使用されます。
代理オーダーではなく SIBD を使用する
Service Portal の代理オーダー プロセスでは、サービス要求の発信者が、別の人（対象カスタマー）の代理でサービスをオーダーすることができます。この方法の欠点は、対象カスタマーにサービスのオーダー権限が必要であるということです。これは一部の企業のポリシーに反します。たとえば、IT 担当者または管理担当者は、他の人のサービスをオーダーできる必要がありますが、IT ロールまたは管理ロールのある人は、自分たち自身のサービスをオーダーできません。
サービス項目と項目ベースのディクショナリが存在しなくてもこの状況に対処することは可能ですが、実際には対処はほとんど実現できません。発信者は、サービスの対象である個人を（個人ベースのディクショナリを使用して）選択できましたが、その個人が「自分の」要求を追跡する方法はありませんでした。この状況には、サービス項目と、サービス項目のディクショナリを使用することで対処できます。発信者はサービスをオーダーし、（サービス項目をプロビジョニングして）、選択した個人をカスタマーに指定できます。これで、このカスタマーが自身の [Service Items] ページに表示されることになるサービス項目のフォームで要求をモニタできます。
• ディクショナリに CustomerID と OrganizationalUnitID を組み込んで、サービス項目ベースのディクショナリを作成します。ユーザ定義の [Status] フィールドを組み込むこともできます。このフィールドは、提供計画の進行とともに更新することができます。
• アクティブ フォーム コンポーネントに SIBD を組み込みます。
• 発信者がサービス項目のカスタマーを選択できるように個人ベースのディクショナリを作成します。両方のディクショナリがサービスに組み込まれている間、個人ベースのディクショナリを SIBD と同じアクティブ フォーム コンポーネントか別のフォーム コンポーネントに組み込みます。
• 選択した個人に関する情報をサービス項目ベースのディクショナリにコピーするため、以下に示す 2 つのルールを個人ベースのディクショナリを含むアクティブ フォーム コンポーネントに記述します。
これで、管理者は、さまざまなカスタマーに対応したサービスをオーダーできるようになりました。また、カスタマーは、[Service Items] ページや [My Items] ポートレットからサービス項目を確認することができます（カスタマーに My Services 360-Degree Consumer ロールまたは Professional ロールが付与されている場合）。サービス項目に、SI の所有者にオーダー権限がある関連サービスが含まれていると、[Service Items] ページから直接これらのサービスをオーダーできるようになります。
この方法の欠点は、要求が Reporting と Advanced Reporting を含む Service Portal のオンライン モジュール内では「カスタマー」で検索できないことです。Advanced Reporting では、サービス項目のカスタマー置換ディクショナリ（上記の例では SICustomer）はレポート可能である必要があります。
キャパシティ管理用サービス項目の使用
サービス項目のプロビジョニングを厳重にモニタすることが必要な場合があります。たとえば、特定のソフトウェア アプリケーションのライセンスが指定ユーザの最大数に使用を制限することがあります。あるいは、特定の事業部門あるいは特定の物理ロケーションで使用可能なサーバとサーバ キャパシティの一方または両方の数を制限することがあります。
オーダー不可のサービス項目は、このような状況で使用できます。ソフトウェア ライセンスの割り当てを追跡することを検討してください。「Software License Capacity」というサービス項目を定義することができます。
Administration
概要
サイト管理者は、Organization Designer モジュールを使用して、エンドユーザが My Services 内のサービス項目にアクセスできる方法を設定するように、Service Item Manager モジュールと Administration モジュールへのユーザのアクセスを認可します。
Service Item Manager モジュールのロール
サイト管理者は、Organization Designer モジュールで管理されるロールと機能を使用することで、Service Item Manager モジュールの機能へのアクセスを制御できます。Service Item Manager のロールにより、管理者は、すべての Service Portal ユーザに割り当てられたサービス項目を表示することができます。
Service Item Manager に関連する標準ロールおよびそれぞれの機能を次の表に示します。
|
|
|
|
|||
|
|
|
|
|
||
ユーザが、サービス項目のインスタンス（該当する場合項目をインポートする機能を含む）の作成、更新、および削除ができるようになります。 |
|||||
Service Item Manager のロールは慎重に割り当てる必要があります。標準データの管理または標準の定義を行う機能をユーザに付与することは、ユーザがすべての標準定義と標準データを編集できるようになることを意味します。サービス項目定義とデータを制御する機能にも、同様の注意があてはまります。
My Service 項目へのアクセスの設定
My Services の [Service Items] タブと [Service Items] ポートレットへのアクセスは、次の 3 つの方法で制御できます。
• すべてのユーザに対応するグローバル アクセスは、管理設定でオンにしておく必要があります。
• サービス項目を表示する機能が有効になると、適切なロールを持つユーザは、[My Items] ポートレットと [Service Items] タブを表示できるようになります。
[My Items] ポートレットの管理設定
どのユーザでも My Services モジュールの [My Items] ポートレットを表示できるようにするには、Administration モジュールの設定 [View Service Items Portlet] がオンになっている必要があります。この設定を確認または変更するには、[Administration] > [Settings] > [Customizations] の順に選択します。以下の [My Services] セクションの [View Service Items Portlet] 設定を参照してください。
この設定をオンにすると、ユーザは [My Services] ホーム ページに [My Items] ポートレットを表示することができます。オフにすると、このポートレットはページに表示されません。
[Service Items] タブと [My Items] ポートレットのロール
RBAC 機能は、個人のサービス項目情報へのアクセスを制御します。ロールは、次のアクセスが必要なユーザにはすぐに使用できます。
[My Items] ポートレットと [Service Items] タブが表示されるのは、エンドユーザに [My Services 360-Degree Consumer] ロールまたは [My Services 360-Degree Professional] ロール、あるいは [View My Service Items]、[View Service Items for My Business Units]、[View Service Items for My Business Units and their sub-units] 機能が含まれるカスタム ロールが付与されている場合だけです。
データベース管理
サービス項目に関連するすべてのデータと設定の詳細は、メタデータ リポジトリ（MDR）に保持されます。MDR は Service Portal トランザクション データベース内に一連のデータベース テーブルとして実装されます。
サービス項目
サービス項目のタイプはそれぞれ、サービス項目インスタンスを保存するトランザクション データベースに対応するテーブルを持っています。テーブルの名前は、「サービス項目」のプレフィックス「Si」付きで定義されるサービス項目の名前です。サービス項目が保存されると、その名前を変更することはできません。表示名は変更できます。ただし、そのサービス項目に基づいたデータ取得ルールは無効となります。
サービス項目の各属性は、データベース テーブルの列に対応します。
|
サービス項目に指定された属性に対応するカラムの他に、Service Portal は、サービス項目の処理と取得に使用する 3 つのカラムを追加します。
|
|
|
すべてのサービス項目で必要な Name カラム/属性は、サービス項目内で一意である必要があります。一意性を適用する（名前別の取得を促進する）インデックスが自動的に作成されます。
各カラムに指定された Service Portal のデータ型は、以下の表に示すように、データベース固有のデータ型で実装されます。
|
|
|
|
標準
サービス項目と同様に、標準はそれぞれ、サービス項目インスタンスを保存するトランザクション データベースに対応するテーブルを持っています。テーブルの名前は、「標準」のプレフィックス「St」付きで定義される標準の名前です。標準が保存されると、その名前を変更することはできません。表示名は自由に変更できます。
サービス項目、サービス履歴、サービス項目サブスクリプション
サービス項目、サービス履歴、サービス項目サブスクリプション テーブルを使用した SQL クエリーを記述する必要は、通常はありません。この情報の大半は、[My Items] ポートレットとページからユーザに提供されます。ただし、これらのテーブルからの情報を取り込むデータ取得ルールを記述することは可能です。たとえば、サービス項目をプロビジョニングするサービスをユーザが所有していても、これをユーザに要求したくない場合があります。
SQL ベースのデータ取得ルールを記述するには、テーブル構造について多少の知識が必要です。
• 上記で指定したように、サービス項目に対応するテーブルの名前はプレフィックス「Si」の付いた項目名となります。そのため、表示名が State of the Art Laptop でテーブル名が StateOfTheArtLaptop の SI には、 SiStateOfTheArtLaptop という名前のデータベースに対応するテーブルがあります。
• そのテーブルは ServiceItemSubscription にどのように関連しますか?ServiceItemTypeName で参加するのが最も簡単な方法です。そのため、 bfine-nov13-2009 という名前の State of the Art Laptop に対応するサブスクリプション情報を取得する場合は、クエリーは次のように機能します。
あるいは、次のクエリーを実行することにより、State of the Art Laptops のすべてのリストを取得できます。
• 次に、ここから ServiceItemHistory レコードにはどのようにし到達しますか?サービス項目サブスクリプションでのキーは PrimaryID で、これはサービス項目履歴の OwnerID と等しくなります。そこで、次のクエリーを実行します。
VMware Adapter エラー メッセージ
次の表は、仮想マシン ディレクトリの ErrorDescription フィールドに、VMware アダプタから戻る可能性のあるエラー メッセージを示します。この表では、エラーごとに説明と推奨処置を示しています。
次のエラーの一部は、エンドユーザに何の結果ももたらさないため、サービス設計において「良性」として処理することができます。たとえば、すでに電源がオンになっている仮想マシンでの「poweron」操作の場合、「Invalid power state specified」エラーはサービスの提供で無視できるエラーです。
フィードバック