Cisco Prime Service Catalog 11.0 設計者ガイド

自由形式ディクショナリは、サービス設計者が、ディレクトリ内のフィールド、その発生順序、それぞれに割り当てられるデータ型を自由に指定できることを意味しています。 自由形式ディクショナリのフィールドを設定するには、「内部ディクショナリを設定するためのフィールド」を参照してください。

Cisco Prime Service Catalog は、Prime Service Catalog アプリケーションにアクセスする必要があるユーザ組織内のすべてのユーザのリポジトリを管理します。 Service Catalog 内の個人情報は、Organization Designer 経由で表示できます。 通常、このリポジトリ内の個人情報には、ディレクトリの統合によってデータが取り込まれます。 ユーザが Service Catalog にログインしたときや、ユーザに代わってオーダーされたサービスがあるときは、リポジトリ内の個人情報を会社規模のディレクトリからの情報でいつでも更新できます。 サービス フォームは、一般に個人情報を参照する必要があります。 たとえば、サービス要求には常にカスタマー（サービスの受信者）と発信者または要求者（キーボードの前に座ってサービスを要求する個人）が存在します。 多くの場合、カスタマーと発信者は同一人物です。つまり、従業員が、自分自身のためにサービスを要求します。 その他の場合として、管理者または許可された他の従業員が、サービスのカスタマーとなる他の個人の代わりにサービス要求を開始します。 このタイプのディクショナリのフィールドを設定するには、内部ディクショナリを設定するためのフィールドの表を参照してください。

人物検索オプションについて

個人ベースのディクショナリをサービス フォームで使用する場合は、[人物検索（Person Search）] ダイアログボックスに検索条件を指定することで単一の人物を選択できます。 人物が選択されると、ディクショナリに使用されているフィールドには、選択された人のプロファイルの対応するフィールドに現在入力されている値が自動的に入力されます。 名前が名、姓形式で表示されます。

「Select_Person」属性により、リポジトリ内で個人を検索する機能、またはサービス フォームに対してディレクトリ統合が有効な場合には、外部ディレクトリで個人を検索する機能が提供されます。 この属性は、テキストではなく、「Person」のデータ型を持ちます。 このデータ型は、フォーム内で属性を使用する場合に、属性の外観を制御します。 たとえば、下記のサービス フォームの [名前（Name）] フィールドは、「Select_Person」属性として定義されています。 デフォルトで使用する [使用（Use）] もオンになっているため、新しい個人ベースのディクショナリでは、「Select_Person」に対し [グリッドで表示（Show in Grid）] がデフォルトでオンになっています。 [使用（Use）] をオフにできないのと同様に、Select-Person に関して [グリッドで表示（Show in Grid）] をオフにすることはできません。 [使用（Use）] チェックボックスをクリックして、サービス フォームに表示する他のディクショナリ属性を選択します。

図 1. 個人属性の選択

サービス項目ベースのディクショナリとは、Service Item Manager モジュールで定義されたサービス項目に基づく構造（フィールド）を持つディクショナリのことです。 このディクショナリには、サービス要求中に収集されたそのサービス項目に関するデータも格納されます。 サービス項目に設定できるデータのタイプを表示するには、サービスのサービス項目の定義の項を参照してください。

このディクショナリ中のフィールドで、サービス項目に保存されるデータが提供され、サービス項目の履歴とそのサブスクリプションの更新に役立てることもできます。 詳細については、「サービス項目サブスクリプションと履歴フィールド」を参照してください。

外部ディクショナリは、[Service Designer] > [ディクショナリ（Dictionaries）] 内に追加され維持されます。 安全なデータ転送方法を設定していない場合、読み取り/書き込みモードの外部ディクショナリを使用すると、システムからアクセスしているデータベースに破損が生じる可能性があります。 次のヒントを参照してください。

• システムで生成される要求エントリ ID は、外部データベース テーブルに独自の列とプライマリ キーを必要とします。 そうしないと、システムはテーブルにある他のデータを上書きする場合があります。
• サイトでは、システムが新しいエントリを書き込むためのキー列を追加して中間テーブルを作成することを推奨します。 このテーブルはその後、既存の表と連動できます。
• 外部ディクショナリを追加する前に、外部テーブルの DBA またはオーナーと協議して、システムが要求エントリ ID とプライマリ キーに正しい列を使用するようにしてください。
• システムは、外部データベース テーブルを参照する独自の外部ディクショナリを使用してユーザがそれらのテーブルに加えた変更を自動的に同期しません。 たとえば、列の名前やサイズの変更は、外部ディクショナリに適用されず、それらのディクショナリによってオーダーされたサービスは失敗します。 システムに外部ディクショナリを作成すると、外部データベース テーブルの構造を変更するたびに、Service Designer のディクショナリ コンポーネントの外部ディクショナリの定義ページを保存する必要があります。 このページの [このディクショナリを追加する（Add This Dictionary）] をクリックすると、システムがテーブル構造を同期し、外部データベースの列を示すセクションに新しい情報が表示されます。

すべての Service Catalog インスタンスには、カスタマーと発信者の各情報用のシード データとして提供されている 2 つのディクショナリが自動的に組み込まれます。 これらのディクショナリは、Service Designer のディクショナリ コンポーネントの「予約済み」ディクショナリ グループにあります。

アクティブ フォーム コンポーネントには「予約済み」フォーム グループもあり、これには Customer-Initiator フォームが含まれます。 このフォームには、Customer_Information ディクショナリと Initiator_Information ディクショナリが含まれています。

Customer_Information ディクショナリと Initiator_Information ディクショナリの機能は次のとおりです。

• すべての要求のカスタマーと発信者を自動的に記録する標準の動作を提供します。
• カスタマーと発信者に関するすべての情報は、取得ライフ サイクルを通して Business Engine 名前空間を介して使用できます。また、My Services 内の要求に関する [要求の概要（Requisition Summary）] ページの一部として表示されます。
• これらのディクショナリは、アクティブ フォーム コンポーネントに含まれており、次の理由ですべてのサービスに再使用可能です。
  • これらのフィールドは、個人のプロファイルから取得された値を反映しています。
  • サービスをオーダーする個人には、期限切れの情報を修正する機会、または現在の要求を遂行するために必要な追加情報を提供する機会はありません。
  • さらに、場合によっては、レポート上および制御上の理由で、要求が送信された時点の、それ以降の変更を反映していないカスタマー情報と発信者情報を追跡する必要があります。
• 予約済みディクショナリのディクショナリ名とグループ名は変更できません。
• 予約済みディクショナリは、予約済みフォーム、Customer-Initiator フォームに含まれます。 フォームの内容と外観は定義可能であり、その動作は、使用可能な任意のフォーム ルールまたは ISF で操作できます。

図 2. My Services 内の [要求の概要（Requisition Summary）] ページ

発信者情報ディクショナリとカスタマー情報ディクショナリのディクショナリ名とグループ名は変更できません。 ディクショナリの他の一般的なプロパティは編集できます。 予約済みディクショナリは、予約済みフォーム、Customer-Initiator フォームに含まれます。 フォームの内容と外観は定義可能であり、その動作は、使用可能な任意のフォーム ルールまたはインタラクティブ サービス フォーム（ISF）で操作できます。

予約済みディクショナリには、使用可能なすべての個人情報がリストされ、各ディクショナリに割り当てる属性を指定できます。 対応する属性名をチェックすることにより、ディクショナリに含める属性を選択します。 たとえば、サービス要求によってはカスタマーの上司の承認が必要になるため、上司情報を含めます。 属性名とデータ型は変更できません。 フィールドが常に非表示であっても、サービス内で処理する必要がある属性を確実に含めます。 属性を選択すると、個人のプロファイルから対応する値が確実に読み込まれます。 次に、設計者は、ディクショナリを含むフォームを設定して、フィールドを適宜非表示にできます。

個人プロファイルには、Service Catalog が使用しないカスタム フィールドが 10 個含まれています（名前は Custom1 ～ Custom10）。 これらのフィールドを、Customer ディクショナリまたは Initiator ディクショナリに含めることができます。 これらのフィールドのいくつかは、ディレクトリ（LDAP）統合を通してインポートされる個人属性にマップされます。 その他は、このディクショナリを含む Customer-Initiator アクティブ フォーム コンポーネントの設定時に使用可能な表示プロパティまたは条件付きルールを通して割り当てるため、または操作するために予約しておくことができます。

個人ベース ディクショナリおよび予約済みディクショナリ（Customer ディクショナリおよび Initiator ディクショナリ）では、Service Designer のディクショナリ コンポーネントを使用して、サービス フォームに表示するディクショナリ フィールド（属性）を選択できます。 単に、ディクショナリにナビゲートして、[使用（Use）] 列のチェック ボックスをオンまたはオフにすることにより、個人ベース ディクショナリを使用するフォーム、または Customer ディクショナリおよび Initiator ディクショナリの両方を自動的に含むアクティブ フォーム コンポーネントである Customer-Initiator フォームで使用する、または含めるフィールドを決定します。

カスタマーまたは発信者の姓名、およびログイン ID に加えて、個人の電子メール アドレスおよびホーム OU のフィールドを追加するのが一般的です。 Person_ID は、個人に割り当てられる一意の識別子です。 基本的なフォーム処理には、このフィールドは必要ありません。しかし、たとえば、このディクショナリ内に対応する属性を持たない個人またはその上司に関する追加情報を動的に取得するデータ取得ルールを記述する場合には有効です。 同様に、Supervisor_ID も、予約済みディクショナリ内に含めるように選択できます。 これにより、サービス設計者は、選択した要求の承認のために「コマンドのチェーン」を動的に作成できます。

同様に、ロケーション情報を特に Customer ディクショナリに含めることができます。 この情報は、たとえば、タスクのルーティング先のキューを決定するため、または実際に訪問してコンタクトを取る必要がある場合に個人のアドレスを単に示すために必要な場合があります。

統合ディクショナリ グループは、すべての Service Catalog インスタンスで自動的に作成されます。 統合ウィザード（Service Catalog と外部システム間の Web サービス統合を作成する Service Designer のウィザード）を通して作成されるディクショナリが、自動的にこのグループに配置されます。 一度作成されると、統合ディクショナリはどのディクショナリ グループにも移動できます。 設計者は、このグループに手動でディクショナリを配置することはできません。

複数のサービスで使用されるフォーム コンポーネントに付与する必要のあるアクセス制御は、場合によっては、各要求の履行に関係するサービス チームに応じて、サービスごとに変える必要があります。 ディクショナリの表示または編集を行う参加者を、サービス定義に追加できます。 これを行うには、[Service Designer] > [サービス（Services）] > [フォーム（Form）] の順に選択し、ディクショナリを選択してから、適切な参加者を追加します。 サービス レベルでは、アクセス制御設定にその他の変更を行うことはできません。

標準も、サービス項目で使用可能な類似オプションを使用してインポートできます。標準定義または標準エントリ、あるいはこの両方をインポートできます。 Service Item Manager には、サービス項目および標準をインポートするための次の方法が含まれています。

• Service Item Manager の [データのインポート（Import Data）] オプションにより、管理者はサービス項目または標準をファイルからオンデマンドでインポートできます。 「ファイルからの標準のインポート」を参照してください。
• 1 つの要求には、サービス項目または標準をインポートする Service Link タスクを含めることができます。 「Service Link を使用したサービス項目と標準のインポート」を参照してください。

既存のルールを編集するには、[アクティブフォームの動作（Active Form Behavior）] タブでルールがアタッチされているイベントを確認または修正します。

条件付きルールの例

サービス フォームで役立つ条件、およびその結果として実行されるアクションには、次のものがあります。

（注）	グリッド ディクショナリとそのフィールドは、条件付きルールの「トリガー条件」に選択できません。

[コンテキスト（Context）] 条件：たとえば、要求が、My Services 内のオーダー時点でのみ表示される場合など、コンテキストが冗長に見える場合があります。 しかし、サービス フォームは、タスク実行者による Service Manager 内でのサービス提供時点、および元々要求を送信したユーザによる My Services 内でのサービス提供時点でも表示できます。 同様に、フォームは、サービス提供時点で複数の参加者により表示できます。 誰が表示しているか、およびどこで表示しているかにより、フォームの動作と外観を変更できます。

[未送信の要求はありますか（Does Unsubmitted Requisition Exist）] 条件：要求が開始されると、オーダー時点となります。 この時点で、一般に、フォーム フィールドにデフォルト値を「事前入力」する任意のルールまたは ISF 関数が実行されます。 エンド ユーザは、データ入力を完了して、ただちに [送信（Submit）] をクリックできます。 その場合、フォーム内のすべてのデータが有効と想定して、要求はオーダー時点から、そのサービスで定義された次の時点に移行します。

特定の状況では、ユーザは、[追加と確認（Add and Review）] をクリックすることにより、要求を送信せず保存できます。 たとえば、要求に対するデータのいくつかが使用可能ではない場合、同じ要求に対してサービスを追加する必要がある場合、アタッチを追加する必要がある場合など、要求を保存しておくことができます。 未送信要求は、My Services 内で選択することで編集できます。

要求を送信する前に既存の要求エントリを編集のために開くと、[未送信の要求はありますか（Does Unsubmitted Requisition Exist）] 条件が true になります。その他の時点では、この条件は false です。 この条件は、たとえば、デフォルト値が事前入力されたルールは新しい要求に対してのみ実行され、保存されていない任意の要求に対しては実行されないようにするために使用します。 これにより、ユーザが以前設定したデータが上書きされないようにできます。

[時点=サービス提供（Moment = Service Delivery）] 条件：サービス提供時点には、多数のタスクが含まれます。 ルールを特定のタスクに対して条件に従って実行する場合、[タスク名（Task Name）] 条件を使用します。

[タスク名（Task Name）] 条件：[タスク名（Task Name）] は Service Designer で自由に変更できる説明フィールドであるため、参照する場合には注意が必要です。 この問題は、サービス設計ガイドラインを作成して、タスクの命名に厳密に適用することにより、最小限にとどめることができます。

サービス設計者が、タスク名に名前空間を含める場合があります。 たとえば、サービス名を意味する名前空間 #Name# を使用して、複数のサービス内で発生する同じタスクを区別できます。 条件付きルールで使用されるタスク名では、すべての名前空間の参照が正しく評価されます。 文字列操作（タスク名の先頭と終端のみ確認、またはタスク名にフレーズが含まれるかを確認）を使用して、名前空間に由来しないタスク名部分を比較できます。

条件内の演算子：使用できる演算子はコンテキストによって異なり、選択した条件に依存するドロップダウンリストに表示されます。 たとえば、フィールドには数字、英数字、または日付データを含めることができるため、算術演算と文字列演算の両方が許可されるだけでなく、フィールドの用途を判断する演算子も許可されます。 タスク名とサービス名はテキストであるため、文字列演算のみ該当します。 true または false のいずれかの値をとる条件の場合、または可能なオプションの数が限定されている（現在のコンテキストなど）条件の場合には、オプション ボタンを使用できます。

ディクショナリ フィールド	タスク名とサービス名	代理によるオーダーですか（Is Order on Behalf）/未送信の要求は ありますか（Does Unsubmitted Req. Exist）

ディクショナリ フィールドに適用可能な大部分の演算子は、そのフィールドの値を確認し、特定のフィールドまたはリテラル フィールドの値と比較します。 これらの演算子のうち、「大文字と小文字を区別しないと等しい（is equal to ignore case）」のみ大文字と小文字を区別しません。 他のすべての演算子では、大文字と小文字が区別されます。英数字データに作用する「次で始まる（starts with）」や「次を含む（contains）」などのルールを記述するときは、この点を考慮してください。

「サービスフォームに存在する（exists on the service form」や「読み取り専用（is read only）」など、他の演算子は、フィールドの値を参照せず、その用途を参照します。 ルールを実行する前に、ランタイム ルール フレームワークが自動的にフレーム上のフィールドの有無とその用途を確認するため、大部分の状況では、これらのルールを使用する必要はありません。

条件内の変数：条件では、任意のディクショナリ内にある任意のフィールドの値を使用できます。 現在のフォームにディクショナリが含まれない場合があるため、サービス設計者は、ルール内で参照されるすべてのディクショナリを含むフォームがサービスに含まれていることを確認する必要があります。

1 つのルール内での条件の結合：複数の条件を結合して評価することで、ルールのアクションを実行する必要があるか確認できます。 この場合、ルールにブール演算子（AND、OR）が含まれる必要があり、またカッコを使用してこれらの演算子の通常の優先順位を変更できます。

条件は、基本的に「if」句で構成します。 Rule Builder は、現在「else」句をサポートしていません。 if/then/else ロジックを適用する必要がある場合には、互いに排他的な条件を持つ 2 つのルールを定義します。

アクションを、次の表にまとめます。

グリッド ディクショナリが非グリッド ディクショナリと異なる点は、ブラウザでレンダリングされ、データベース内で生成された WDDX に格納される点です。 そのため、個々のセルを操作するには、条件付きルールと ISF 関数の組み合わせが必要です。 ここでは、グリッドで使用できる条件付きルール アクションと ISF 関数について説明します。

既存のデータ取得ルールまたは条件付きルールを変更するために、ルールを編集し、必要な変更を適用し、ルール ウィザードのすべてのページを移動する必要があります。 [保存（Save）] ボタンは、各ウィザードの最後のページでのみ使用できます。 このプロセスにより、ルールのすべての側面が内部的に整合していることが保証されます。

ディクショナリとフィールドに対する変更は、対応するディクショナリ、フィールド、または Lightweight 名前空間を使用するルールに、自動的には反映されません。 ディクショナリまたはフィールドの名前を変更する場合には、すべてのページをナビゲートして、ルールを編集する必要があります。 条件付きルールとテーブル ベースのデータ取得ルールの場合には、ディクショナリやフィールドに対する参照は、各ページに進むごとに自動的に更新されます。 SQL 入力データ取得ルールの場合には、正しい Lightweight 名前空間を使用して、SQL コードを再入力する必要があります。

フィールドまたはディクショナリを削除する場合には、ルールを編集して、削除されるオブジェクトへの参照を削除する必要があります。 以前機能していたルールが突然機能しなくなった場合には、名前が変更されたオブジェクトまたは削除されたオブジェクトが、そのままの状態でルール内から参照されていることが原因の可能性があります。

SIBD には 1 個の固有のプロパティ（既存のサービス項目インスタンスに関するデータを自動的に取得し、事前入力する機能）があります。 選択されたフォームでは、このオプションはサービス項目ベースのディクショナリの [表示プロパティ（Display Properties）] タブに含まれています。

[サービス項目インスタンスデータの自動取得を有効にする（Enable automatic retrieval of service item instance data）] は、サービスが既存のサービス項目の更新か削除に使用される場合、通常は選択されている必要があります。 この事前入力機能を利用するには、同じサービス項目ディクショナリに基づいた、2 つのフォーム コンポーネントが必要な場合があります。1 つは項目が作成されるサービスに、もう 1 つは項目を更新または削除するサービスに含まれます。

[テーブル名（Table Name）] のドロップダウンリストには、次の値が入ります。

• すべての Service Catalog のインストールで提供される Service Item Manager で定義されたサービス項目
• サービス項目の履歴を追跡するために自動的に保持されるテーブル、ServiceItemHistory
• サービス項目のサブスクリプション（現在のステータス）を追跡するために自動的に保持されるテーブル、ServiceItemSubscription

テーブル ベースのデータ取得ルールに対して行ったように、ルール定義の完了に進むことができます。 ルールの定義の詳細については、フォーム ルールを使用した動的なフォーム動作の設定を参照してください

図 3. New Rule

システムがサービス項目に割り当てるデータベース テーブルの名前を参照することにより、SQL 入力データの取得ルールにサービス項目を使用できます。 テーブルの名前は、プレフィックス「Si」から始まり、そのあとに項目名が続きます。スペースは削除されます。 データベース テーブルの名前を探し出す（[サービス項目の管理（Manage Service Items）] ページに戻らずに、項目名を検索する）簡単な方法は、サービス項目を使用して、テーブル ベースのルールを定義し、保存することです。 [概要（Summary）] ページに含まれる生成された SQL にはテーブル名が含まれます。

ディクショナリ フィールドには、そのフィールドの [表示プロパティ（Display Properties）] の [ボタンの追加（Add a Button）] セクション内の指定に従って、ボタンが関連付けられている場合があります。

図 9. HTML 表現

図 10. 救済策チケット番号

キャプション（ボタン上に表示されるテキスト）と URL を指定できます。 URL は、JavaScript 関数またはネットワーク上でアクセス可能な外部の任意の場所を指すことができます。

外部 Web ページを参照する場合、完全修飾 URL を使用します。

• URL は、ライブラリ内で使用可能な JavaScript 関数、または埋め込まれた JavaScript コードを指すことができます。 関数呼び出しにパラメータが含まれる場合、フォーム データをそのパラメータに含めることはできません。 しかし、関数は、ISF を含むことができます。
• [データの送信（Send Data）] オプションは、外部 Web ページにのみ適用できます。 これにより、現在のフォーム上のすべてのデータを含めて、応答がそのページに POST されます。

イベント ハンドラ内にコードを配置するのではなく、関連付けられたボタンを使用する短所は、コードを起動するために余分なキーストローク（ボタンのクリック）が必要になることです。 したがって、ボタンは、通常のフォーム処理の手順内、または拡張ダイアログボックスや外部サイトのブラウズで使用するのではなく、オンデマンドで実行する必要のあるイベント用に使用するのが最もよい方法です。

URL を指定するだけで、指定された Web ページが別のウィンドウに表示されます。 ただし、そのウィンドウのサイズは変更できず、スクロール バーもありません。 したがって、アプリケーションによっては、JavaScript を使用して、明示的に指定したウィンドウに Web ページを表示する方が望ましい場合があります。 次に、コード例を示します。

javascript:window.open ("http://www.coder.com", "mywindow","status=1,toolbar=1, scrollbars=1, width=500, resizable=1"); 

JavaScript は、すべて 1 行に記述する必要があります（改行なし）。 以下の出力例を参照してください（基本的なものですが、考え方がわかります）。 上記の行は、「URL with JavaScript」というラベルのボタンの URL エントリからコピーして貼り付けたものです。

JavaScript を外部の JavaScript（ライブラリ）ファイルに保存すると、次の利点があります。

• 各イベントに Script Manager 内でアタッチされた関数が存在する場合のように、ユーザが別々の画面をナビゲートする必要に迫られることがないように、多数の関数のコードを 1 つの場所に維持します。
• コードをファイル内に維持することにより、ソース コードのバージョン管理がより容易になります。
• コードをテキスト ファイル内に維持することにより、グローバル検索/置換、およびファイルに対する検索の実行がより容易になります。
• JavaScript ライブラリは、単に、アプリケーション サーバ上に存在する ASCII ファイルです。 そのため、強力なエディタを使用してファイルの内容を管理できます。
• 同じコード部分が 1 つ以上の関数から参照されるため、変更が必要な部分を 1 つにすることができ、テストも 1 回で済みます。

原則的には、すべてのクライアント コードを 1 つのライブラリに格納できます。 しかし、状況によっては、コードを複数のライブラリに分割する方が望ましい場合や、分割する必要がある場合があります。

• 1 つ以上の JavaScript ライブラリを使用して、同じサービスやサービスのグループで使用される可能性が高い ISF 関数が 1 つのライブラリ内に存在し、別のサービスのセットで使用されるものは別にグループ化されるように ISF 関数をグループ化することができます。 これにより、独立したプロジェクトで作業する可能性の高い開発者のグループは、自分の作業を分離できます。
• 複数の独立したライブラリを使用する場合、それらのライブラリは、サービス フォームにグローバルにアタッチしないでください（[スクリプト（Scripts）] オプションの [ライブラリ（Library）] ページの [このライブラリをすべての関数に組み込む（Include this library in all functions）] チェック ボックスを使用）。 代わりに、関連するライブラリ（複数可）を、フォームの「onLoad イベント」にアタッチされた関数に組み込む必要があります（[スクリプト（Scripts）] ページの [ライブラリ（Libraries）] タブを使用）。
• 同様に、関連するライブラリがアタッチされている onLoad イベントはすべてのフォームに組み込まないでください（[スクリプト（Scripts）] ページの [フォームのロード時にこのスクリプトを追加する...（ブラウザ側）（Add this script … when the form is loaded (browser-side)）] オプションを使用）。 代わりに、アクティブ フォーム コンポーネント内のフォームの [アクティブフォームの動作（Active Form Behavior）] タブを使用して、イベントに関連付ける必要があります。
• 同じサービス内で使用する可能性が高い複数の ISF 関数を 1 つのライブラリ内に配置すること、および稀にしか使用しない関数、または十分に定義された状況で使用される関数を別のライブラリに配置することには、論理的な利点があります。 この利点は、メモリの使用を削減することです（特定のサービスで必要とされない関数はロードされません）。 ただし最近は、メモリが比較的安価で、容量が十分であり、ISF 関数によって使用される量は、他のコンポーネントで使用される量と比較して少量であるため、特に実際の利点はありません。

記述する ISF は、JavaScript 関数内に置かれます。 特定のディクショナリまたはそのディクショナリ内のフィールドに関数を適用する場合、関数名は、この階層を反映する必要があります。 これで、関数の使用方法を格段に簡単に追跡できるようになります。 関数名は、次の表記法に従います。

• dictionaryName_event
• dictionaryName_fieldName_event

次に例を示します。

• RC_REQUESTEDBY_onLoad
• ST_HighProfile_onSubmit
• ST_UserLocation_FieldOffice_onChange
• SVC_Phone_PhoneType_onClick

ディクショナリ固有の関数とフィールド固有の関数に加えて、Cisco Advanced Services により、サイト全体にわたる次の関数が作成される場合があり、必要に応じて修正できます。

• rc_CommonService_onLoad
• rc_CommonService_onSubmit
• siteRC_REQUESTEDBY_onLoad
• siteRC_REQUESTEDFOR_onLoad

この命名規則により、各スクリプトがどのように使用されるかを簡単に理解でき、また新しい機能を作成する適切な場所を見つけることができます。 また、サイト固有のコードが、標準サービス ライブラリとともにインストールされた ISF コードと正しくインターフェイスを取れるようにします。

ISF JavaScript 関数は、外部の JavaScript ライブラリに配置することを推奨します。 特定の関数を見つけやすくするために、ファイル内で関数を順に並べることが重要です。

すべてのコードは、Tab 文字なしで ANSI テキスト ファイルに格納し、空白文字 2 個のインデントを使用して、読みやすく、また理解しやすくする必要があります。 各行は 76 文字以内にしてください。

ディクショナリ内のフィールド名を変更するときには、十分に注意する必要があります。 フィールドが関数内で参照されている場合、その関数は機能しなくなります。

JavaScript 内のすべての標準プロパティとメソッドは小文字で始まり、その次の単語は大文字で始まります。 たとえば、プロパティ「readOnly」やメソッド「onSubmit」は、この規則に従っています。 ISF 内で強制されているわけではありませんが、次の同様の規則も推奨されています。

[Service Designer] > [スクリプト（Scripts）] の下の [ライブラリ（Libraries）] オプションを使用して、1 つ以上の JavaScript ライブラリにカスタム ISF コードを配置できます。 ライブラリはテキスト ファイルであるため、アプリケーションの外部で、テキスト エディタでライブラリの内容を維持する必要があります。 JavaScript 対応エディタまたは開発環境が強く推奨されています。 また、サードパーティの JavaScript ライブラリも、ISF と組み合わせて使用できます。

サービス フォームからアクセス可能にするために、ライブラリは、URL/RequestCenter にマッピングされた、アプリケーション サーバ上のディレクトリ構造に存在する必要があります。 慣例では、ライブラリは、ルート直下に配置された isfcode という名前のディレクトリに配置されます。 /RequestCenter サイトの物理的な位置は、ユーザのサーバ上で Service Catalog がインストールされている方法、および使用中のアプリケーション サーバによって異なります。 ISF ライブラリが存在する必要のある物理的な位置を決めるには、システム管理者に相談してください。 また、ISF 開発者が、このディレクトリに対する読み取り/書き込みアクセス権、およびディレクトリにファイルを転送するツールを持っていることを確認する必要があります。

サービス フォームでライブラリ内の関数を使用するためには、生成されたサービス フォームにライブラリへの参照（HTML スクリプト タグとして実装）を組み込む必要があります。 この参照は、2 つの方法のいずれかで生成されます。

• [スクリプト（Scripts）] オプションの JavaScripts ノードの [ライブラリ（Libraries）] タブを使用して、ライブラリを特定の関数に関連付けます。 これで、ライブラリは、この関数を使用するすべてのフォームで使用可能になります。
• [スクリプト（Scripts）] の [ライブラリ（Library）] オプション上の [このライブラリをすべての関数に組み込む（Include this library in all functions）] チェック ボックスを使用して、すべてのサービス フォームにライブラリを組み込みます。

これは、ライブラリ参照をサービス フォームに組み込む推奨アプローチです。 onLoad イベントとして起動される関数が存在する必要があります。 これで、ライブラリは関数に組み込まれます。 1 つ以上の onLoad 関数をコーディングできます。 それぞれに、異なるライブラリ セットをアタッチできます。 この方法では、異なる開発者のチームが、そのサービス フォームで使用可能なライブラリを制御できます。

（注）	JavaScript ライブラリのロード順序はアプリケーションによって制御されません。また、アプリケーション サーバ、OS のバージョン、データベース タイプなどの既知および不明な環境変数によって影響を受けることがあります。

[ライブラリ（Library）] ページの [このライブラリをすべての関数に組み込む（Include this library in all functions）] チェック ボックスは、適切な名前ではありません。ライブラリは、フォームごとに一度しかロードできないため、[このライブラリをすべてのフォームに組み込む（Include this library in all forms）] にする必要があります。 このチェック ボックスを使用すると、ライブラリの <script> タグが、生成された HTML ページの先頭に置かれ、ページ レベルの ISF から呼び出されたときに、ライブラリとその関数が存在することが保証されます。

この方法は、複雑なプロジェクトでは推奨されません。

（注）	JavaScript ライブラリのロード順序はアプリケーションによって制御されません。また、アプリケーション サーバ、OS のバージョン、データベース タイプなどの既知および不明な環境変数によって影響を受けることがあります。

この時点で、ライブラリ（コードが含まれない可能性がある）と、すべてのサービス フォームでライブラリを使用するための仕様が存在します。 サービス フォームを実行し、ソース コードを表示し、ライブラリの名前を検索することにより、自分の作業を検証できます。 サービス フォームのソース コードを表示するには、ブラウザの [ソースの表示（View Source）] オプションは使用できません。 サービス フォームは、HTML ページ内のフレームとして表示されるため、生成されたソース コードは表示されません。 代わりに、マウス ポインタをサービス フォーム内（フィールド内ではない）に移動し、右マウス ボタン オプションを使用して「ソースを表示」します。 検索すると、ライブラリの名前が示されます。

HTML および JavaScript 環境でデバッグを行うことは難しいため、コードの書き込み時は一度に 1 つの関数を書き込み、デバッグ、およびテストすることを推奨します。もちろん、JavaScript を含むライブラリ ファイルをローカルで編集することもできますが、それをテストするときは、アプリケーション サーバの指定したディレクトリにコピーをとる必要があります。 最初にコードを開発するとき、またはアプリケーション サーバへのアクセス権が限定されている場合には、スクリプト内でコードを記述し、完了した時点でリファクタリングを行い、スクリプト下でライブラリ関数を呼び出すラッパー関数のみ残して、関数をライブラリに移動します。 頻繁に保存を行い、以前のバージョンのコードに戻す必要がある場合に備えて、バックアップ コピーを維持してください。

コードを記述したら、そのコードをフォーム内のイベントにアタッチする必要があります。 サービス フォームの HTML ページは動的に生成されるため、これを実行するためには Service Designer を使用する必要があります。 詳細については、JavaScript への関数の引数の追加 を参照してください。 ディクショナリ フィールドにフィールド レベル イベントをアタッチするには、次の項目を実行します。

• JavaScript ライブラリ内で関数を記述します。 dictionaryName_fieldName_event に従って、たとえば RC_REQUESTORLOCATION_LocationName_OnChange という名前を付けます。
• サイト固有のコードを持つ関数に、以前 JavaScript ライブラリにインクルードした関数の名前にプレフィックスを付けて、名前を付けます。 Service Catalog が提供する関数（たとえば、Service Catalog ライブラリに含まれるサービスで使用されるもの）はプレフィックス「rc」を使用するため、コードは次のようになります。

rcRC_REQUESTORLOCATION_LocationName_onChange () {
 RC_REQUESTORLOCATION_LocationName_onChange();
}

• [アクティブフォームコンポーネント（Active Form Components）] オプションの [アクティブフォームの動作（Active Form Behavior）] タブを使用して、関数を該当するフィールド レベル イベントにアタッチします。 フィールドとトリガー イベントを選択して、次に [JavaScriptの追加（Add JavaScript）] をクリックすることにより関数を追加します。 （ディクショナリが複数のフォームで使用される場合、関数は、すべてのフォーム内のディクショナリ フィールドにアタッチする必要があります。 このアプローチは推奨されません）。

ISF コードは、多数のサービスで再使用可能なアクティブ フォームにアタッチされます。 しかし、1 つのサービスをテストするだけでは十分ではありません。 たとえば、別のフォームのディクショナリ内のフィールドがサービス内にも存在することを想定するコードが考えられます。そうでない場合には、ISF コードは、JavaScript エラーで失敗します。 したがって、使用可能なフォームの異なる組み合わせに基づいて、テスト マトリクスを設定する必要があります。 特に、テストの初期フェーズでは、Service Catalog の複数のセッションを同時に実行するのが有効です。

• 表示されるオプションに [スクリプト（Scripts）]（関数コードを変更）または [アクティブフォームコンポーネント：アクティブフォームの動作（Active Form Components: Active Form Behavior）]（JavaScript アタッチを変更）を設定して Service Designer を 1 つのブラウザで起動します。
• 別のブラウザで My Services または Service Manager を実行して、その時点で定義されているルールや ISF に関してサービス フォームをテストします。
• ライブラリ内に存在するコードをテストする場合には、もちろん、ライブラリ ファイルの編集、アプリケーション サーバへの変更のアップロードのために、もう 1 つのウィンドウが必要になります。

JavaScript エラーが発生すると、JavaScript デバッガが表示されます。 （関数またはライブラリ コードを編集して）エラーを修正し、デバッガを閉じた後、現在のサービス フォームを終了して、新しい要求を開始する理由はありません。 単に、ページを更新して、現在のサービス フォームを新しい ISF コードで再ロードします。

[管理の設定（Administration Settings）] で [ブラウザキャッシュ（Browser Cache）] 設定が有効になっている場合、JavaScript ライブラリに対する変更は、ブラウザ キャッシュが削除されるまで効力を持ちません。 したがって、開発環境では、ブラウザ キャッシュを無効にするのが最善です。 JavaScript ライブラリへの変更を、ブラウザ キャッシュが有効になっている可能性がある実稼働環境に展開する場合、アプリケーション ユーザは、このブラウザ キャッシュを削除する必要があります。 アプリケーション ユーザにこの操作を促すには、『Cisco Prime Service Catalog Administration and Operations Guide』の指示に従ってブラウザ キャッシュ バージョンを追加します。

サービス項目または標準のインポート ファイルを指定する構文の表には、サービス項目または標準のインポート ファイルを指定するための構文をまとめています。 同じ構文がサービス項目と標準の両方に適用されます。 XML ファイルはそれぞれ 1 つの SI インポート仕様から構成されます。

インポート仕様（SIImportSpec）は、SIClassDefinition と、それに続いて指定されたクラス（サービス項目または標準）に対応する 1 つ以上の SIInstances のリストから構成されます。 クラス定義とインスタンスのどちらか一方または両方がファイルに含まれます。 ファイルの内容は、指定されたインポート オプションと一致する必要があります。

各 SIClass 仕様は、適切な XML タグ内に組み込まれたサービス項目または標準定義と、それに続く属性ごとの定義から構成されます。

それぞれの属性定義には、名前、キャプション、属性に指定されたその他の設定オプションが指定されます。

サービス項目インスタンス（SIInstance）ごとに、インスタンスが適用されるサービス項目または標準の名前と、項目の各属性の値のリストが指定されます。 属性値がブランクの場合でも、属性に値が指定されていないインポート ファイルに適切なタグが引き続き含まれる必要があります。

Service Item Manager を使用してサービス項目または標準を定義すると、データ型は指定されたデータ型と完全には一致しません。 Service Item Manager のデータ型からのインポート ファイルのデータ型の表を使用して、Service Item Manager のデータ型をインポート ファイルに使用されるデータ型にマップします。