Cisco Prime Service Catalog 11.0 設計者ガイド
サービス用のフォームの設定
サービス用のフォームの設定

目次

サービス用のフォームの設定

この章は次のトピックで構成されています。

サービス用のフォームの設定

はじめに

サービス フォームは、エンドユーザによってサービス要求の定義に使用されます。 Service Designer モジュールを使用して、サービス フォームを設定し、サービスのオーダー時に特定の選択肢を表示するためのデータ取得ルールを作成できます。 サービス フォームの設計には次のコンポーネントを使用します。

ディクショナリを使用したサービス フォーム フィールドの設定

サービス フォームの基本的な構成要素は、個々のデータ エレメント(フィールド)のグループであるディクショナリであり、これらを使用してユーザやサービス実行者はサービス要求を実施するのに必要なデータの入力や表示を行うことができます。 ディクショナリには、これらの要求で必要になる可能性があるすべてのフィールドを組み込む必要があります。

(ディクショナリとフォーム コンポーネントを再利用される場合に備えて設計する)この原則は、サービスが、カスタマーにサービス(または項目)を提供するための最初の要求だけでなく、サービス項目のライフ サイクル全体にわたって有効である可能性があるため、サービス項目ベースのディクショナリにとって特に重要です。 サービス要求に組み込むことができるタスク(サービス項目の作成と変更やサービス項目の現在のオーナーからの除外)をサポートするディクショナリを設計することができます。

Prime Service Catalog におけるディクショナリのタイプ

ディクショナリには内部と外部の 2 つの主なカテゴリがあり、ディクショナリ内のデータを保存する方法を示しています。

内部自由形式ディクショナリ

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

内部個人ベースのディクショナリ

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

個人ベースのディクショナリを使用するケース

カスタマーまたは発信者として要求を参照するだけの場合は、個人ベースのディクショナリを作成する必要はありません。 代わりに、Prime Service Catalog の予約済みディクショナリの一部である Customer_Information ディクショナリと Initiator_Information ディクショナリを使用します。要求者が要求の実施に関与したり参照として必要となる可能性がある他の人を頻繁に指定する必要がある場合は、個人ベースのディクショナリを作成する必要があります。

個人ベースのディクショナリの使用例

個人ベースのディクショナリが頻繁に使用される事例として、ディレクトリの統合から使用可能な監視構造から承認者が推測できない場合に、発信者が要求の承認者を 1 人以上指定する必要がある場合が挙げられます。 このシナリオでは、使用可能な従業員のドロップ ダウン リストから検索することで、要求者は承認者を選択します。また、承認者の連絡先情報は、簡単な参照用にサービス フォーム データに組み込まれます。

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

個人ベースのディクショナリをサービス フォームで使用する場合は、[人物検索(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 モジュールで定義されたサービス項目に基づく構造(フィールド)を持つディクショナリのことです。 このディクショナリには、サービス要求中に収集されたそのサービス項目に関するデータも格納されます。 サービス項目に設定できるデータのタイプを表示するには、サービスのサービス項目の定義の項を参照してください。

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

サービス項目ベースのディクショナリの追加

この手順を使用して、サービス項目の作成中に定義された属性に基づくサービス項目ベースのディクショナリを作成します。

はじめる前に

ディクショナリが定義されるベースとなるサービス項目を設定します。


    ステップ 1   [Service Designer] > [ディクショナリ(Dictionaries)] の順に選択します。
    ステップ 2   > [新しいディクショナリ(New Dictionary)] を選択し、[新しいディクショナリ(New Dictionary)] ページを表示します。
    ステップ 3   [新しい内部ディクショナリを追加する(Add New Internal Dictionary)] セクションの [サービス項目(Service Item)] フィールドに、対象のサービス項目の名前の 1 つ以上の文字を入力するか、または、「*」を入力してすべてのサービス項目を検索します。 対象のサービス項目をクリックします。

    [カテゴリ(Category)]、[サービス項目グループ(Service Item Group)] および [サービス項目タイプ(Service Item Type)] フィールドの値は、選択したグループおよびサービス項目タイプに設定されます。 前のリリースと同様に、[サービス項目ファミリ(Service Item Family)] は Service Catalog では使用されず、任意の値を指定できます。 この値は Service Catalog のデータ マートでのクエリとグループ化に使用できます。 サービス項目ベースのディクショナリに含めることができる他のフィールドは次のとおりです。

    • サービス項目自体で定義された属性に対応するフィールド。 詳細については、「サービス項目フィールド」を参照してください。
    • ディクショナリと組み合わせて使用できるサービス項目サブスクリプション(履歴)および提供履歴に関するフィールド。 これらのフィールドは、サービス項目の現在の使用状況とサブスクリプション履歴に関する追加情報を提供します。 詳細については、「サービス項目サブスクリプションと履歴フィールド」を参照してください。
    • ユーザによって定義されたフィールド。 詳細については、「ユーザ定義によるフィールド」を参照してください。
    ステップ 4   [ディクショナリを保存(Save Dictionary)] をクリックします。
    (注)      ディクショナリを作成した後に、対応するサービス項目に新しい属性を追加するには、手動で新しいフィールドを追加する必要があります。 これは、Service Catalog がその属性に対応する新しいフィールドをディクショナリに自動的に追加しないためです。 属性名(表示名でなくデータ名)と同じ名前をフィールドに使用していると、Service Catalog は、サービス項目内の属性と、ディクショナリ内のフィールドを適正に同期化します。 同様に、SIBD を作成し、対応するサービス項目から属性を削除した場合は、削除された属性に対応するディクショナリ フィールドを手動で削除する必要があります。 削除を行わないと、サービス項目に対応するデータのないフィールドがフォームに含まれることになります。

    サービス項目フィールド

    ユーザによって定義されたサービス項目で指定される属性は、デフォルトで、その項目に基づいたディクショナリに含まれます。 ディクショナリに追加フィールドを追加するには、ディクショナリ属性の下の属性名の左側にあるチェック ボックスをオンにします。 [名前(Name )] フィールドを除く他のフィールドはオプションです。 [名前(Name)] フィールドには「サービス項目 ID」として予約済みのデータ型があります。 すべてのデータ型は、サービス項目の定義から継承されます。 パスワード、受取人氏名、口座番号などの機密データを暗号化するには、[暗号化(Encrypt)] チェック ボックスを選択します。


    (注)  


    暗号化された文字列が文字数制限を超えないように、暗号化するサービス項目ディクショナリに [文字列(最大)(String (max))] フィールド タイプを使用します。

    [文字列(最大)(String (max))] の制限は、システム管理者によって cnfparam テーブルで 6000 に設定できます。 ただし、サービス項目ディクショナリで設定する場合は、新しい文字列の制限値によってパフォーマンスの問題が発生しないことを確認します。 機密データの暗号化の詳細については、ディクショナリ属性の表を参照してください。

    サービス項目サブスクリプションと履歴フィールド

    [ディクショナリ(Dictionary)] ページに表示される次の一連のフィールドは、サービス項目サブスクリプションと履歴用に保持されるデータに対応します。 サービス項目に対するサービス項目の作成または更新タスクが実行されると、要求のサブスクリプションと履歴データがサービス項目の履歴に記録されます。 このオプションは、エンド ユーザの場合は、[マイスタッフ( My Stuff)] ページで使用でき、管理者の場合は、各項目の [Service Item Manager] > [サービス項目の管理(Manage Service Items)] > [履歴(History)] タブで使用できます。

    サービス項目のサブスクリプション フィールドを次のテーブルにまとめています。 事前に設定されているサブスクリプション フィールドの場合は、フィールド名の左にあるチェック ボックスを選択して、含めるフィールドを選択します。 次に示すフィールドは、ディクショナリに組み込まなくても、適切な値が入力された状態で、サービス項目の履歴とサブスクリプションのデータに自動的に組み込まれます。 これらをディクショナリに組み込むのは、Service Catalog がこれらのフィールドに値を提供するために使用するデフォルトの動作を補足または上書きするためです。

    表 1 サービス項目フィールド

    フィールド名

    説明

    CustomerID

    要求/サービス項目用のカスタマーの ID。

    RequisitionID

    サービス項目サブスクリプションを作成したサービス要求を含む要求(ショッピング カート)の ID。

    RequisitionEntryID

    サービス項目サブスクリプションを作成したサービス要求の ID。

    OrganizationalUnitID

    サービス項目が割り当てられているカスタマーのホーム OU。

    AssignedDate

    サービス項目がカスタマーに割り当てられた日時。つまり、「サービス項目 - 作成」タスクが実行された日時。

    SubmittedDate

    「サービス項目の作成」タスクが含まれる要求が送信された日時。

    ErrorCode

    未使用。

    ErrorDescription

    サービス項目の作成または割り当てを行おうとして失敗した場合に受け取る、エラー コードのテキスト形式の説明。

    アカウント ID(Account ID)

    デフォルトでは、サービス項目が割り当てられているカスタマーのホーム OU のテナント アカウント。


    (注)  


    CustomerID および OrganizationalUnitID がサービス項目ベースのディクショナリに組み込まれていない場合、Service Catalog はそのデフォルト ロジックを使用して、各フィールドに値を指定します。 フィールドがディクショナリに組み込まれていると、サービス項目のタスクが実行される時に、フォーム フィールドの値が使用されます。
    • ディクショナリに CustomerID または OrganizationalUnitID が含まれている場合、サービス設計者は、フィールドに値を指定するためのルールやその他のメカニズムを記述する責任があります。

    Service Catalog のデフォルトの動作を上書きするためのシナリオとして、次のものがあります。

    • オーナーなしでサービス項目(SI)を作成します。 つまり、そのサービス項目へのサブスクリプションは誰にもありません。 たとえば、新しいラップトップが届き、まだ誰にも割り当てられていない状態などが該当します。 これは、[サービス項目の管理(Manage Service Items)] タブでサービス項目を手動で作成するか、外部ソースからサービス項目をインポートする代替手段となります。 このシナリオでは、CustomerID と OrganizationalUnitID の両方がサービス フォームに含まれています(オーダー段階ではルールによって非表示になっている可能性があります)が、値は指定されていません。 CustomerID と OrganizationalUnitID の両方が参照されるたびに AccountID を追加します。
    • 要求の発信者が、サービス項目のカスタマーを(個人ベースのディクショナリから)明示的に選択することができます。 カスタマーの情報を SIBD に含まれている [CustomerID] フィールドと [OrganizationalUnitID] フィールドにコピーして、デフォルトのカスタマー(発信者)を上書きします。 CustomerID と OrganizationalUnitID の両方が参照されるたびに AccountID を追加します。 このシナリオは、XREF セクションで詳しく説明します。
    • 指定されたオーナー(CustomerID に対応する人物)はないが、所有する OU はありで SI を作成します。 たとえば、プロジェクト チームがサーバを必要としているが、サーバは個人ではなくチームの責任である場合などです。 このシナリオは前述のシナリオと似ていますが、ディクショナリに含まれる必要があるのは CustomerID のみです。CustomerID の内容は、オーダー段階でルールによってブランクになります。 OrganizationalUnitID は、発信者やカスタマーの OU ID にでき、または人物検索機能によって OU/カスタマーを選択できます。
    • 誰かからサービス項目を割り当て解除します。 たとえば、従業員が会社またはプロジェクトを去るときにその従業員の備品を一時的に割り当て解除する場合などです。
    • データ取得ルールを実行して、SI が作成されたときの情報(どの要求 ID と要求エントリ ID が前のオーダーに含まれていたか、など)を表示します。

    エラーの説明フィールドには、サービス項目タスクに失敗した場合のフィードバックが記述されます。 これは、データ入力を検証するために必要になることが考えられる条件付きルールのヒントを提供することで、デバッグの際に役立ちます。

    サービス項目の作成に失敗する理由は、サービス項目の作成で、項目名をブランクにしたままであるか、既存のサービス項目と名前とタイプが同じものを作成しようとした、などが考えられます。 こうしたタスクが失敗すると、サービス項目は作成されず、要求に対して加えられた変更はすべてロールバックされます。 同様に、参照される項目が存在しない場合、サービス項目の更新または削除のタスクが失敗する可能性があります。

    ユーザによって定義されたフィールド

    サービス項目の設計者は、任意のサービス項目ベースのディクショナリにフィールドを追加できます。 こうしたフィールドは、サービス項目自体に該当しない場合がありますが、サービス項目に関連するサービス要求の重要な部分です。 たとえば、カスタマーがこの項目を要求した理由についてのコメントや、項目の使用状況に関連付けられた初期月次コストまたは定期月次コストなどを含むことができます。 フィールド名が、使用可能なサービス項目履歴またはサービス項目サブスクリプションのフィールド名と同じではいけません。これは、フィールドがこのディクショナリに含まれていなくても、適用されます。

    このようなフィールドは、フォームとフォーム用ディクショナリ データに含まれるデータとなるだけです。サービス項目の一部として記録されることはなく、サービス項目履歴およびサービス項目サブスクリプションのクエリからは表示できません。 ただし、ディクショナリ フィールドと同様に、完了した要求では表示が可能で、ディクショナリまたはディクショナリを含むサービスが、レポート可能になっている場合は、Advanced Reporting モジュールからレポートが可能です。

    外部ディクショナリ

    外部ディクショナリは、[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 のウィザード)を通して作成されるディクショナリが、自動的にこのグループに配置されます。 一度作成されると、統合ディクショナリはどのディクショナリ グループにも移動できます。 設計者は、このグループに手動でディクショナリを配置することはできません。

    ディクショナリ グループの作成

    ディクショナリ グループは、潜在的な多くのディクショナリを整理するのに役立つフォルダです。 すべてのディクショナリは、ディクショナリ グループに配置する必要があります。 システムで孤立ディクショナリは許可されません。 ディクショナリ グループにはサービス グループとは異なり、それらに関連付けられている動作はありません。


      ステップ 1   [Service Designer] > [ディクショナリ(Dictionaries)] の順に選択します。
      ステップ 2   [新規(New)] > [新しいディクショナリグループ(New Dictionary Group)] の順に選択します。 [新しいディクショナリグループ(New Dictionary Group)] ウィンドウが開きます。
      ステップ 3   必要な情報を指定されたフィールドに入力し、[このディクショナリグループを追加(Add This Dictionary Group)] をクリックします。 ディクショナリ グループがツリー メニューに追加されます。

      ディクショナリの作成

      はじめる前に

      • ディクショナリのタイプを決定します。 Prime Service Catalog で利用可能なディクショナリのタイプを理解します。 Prime Service Catalog におけるディクショナリのタイプを参照してください。
      • 外部ディクショナリを作成するには、システム ディクショナリとして使用できるように、アプリケーション サーバに応じて外部データベースのデータ ソース名を定義します。 これはシステムの外で完全に行われます。

        ステップ 1   [Service Designer] > [ディクショナリ(Dictionaries)] の順に選択します。
        ステップ 2   左側の事前に定義されたディクショナリを選択するか、または [新規(New)] > [新しいディクショナリ(New Dictionary)] の順に選択して新しいディクショナリを作成します。
        ステップ 3   ディクショナリのタイプを指定します。
        1. 内部自由形式のディクショナリを設定するには、[データソース(Data Source)] 列の下の [新しい内部ディクショナリを追加する(Add New Internal Dictionary)] セクションの [自由形式(Free Form)] リンクをクリックします。
        2. 内部個人ベースのディクショナリを設定するには、[データソース(Data Source)] 列の下の [新しい内部ディクショナリを追加する(Add New Internal Dictionary)] セクションの [ベースとするテンプレート(Template Based)] ドロップダウンリストから [個人ベース(Person Based)] を選択します。
        3. サービス項目ベースのディクショナリを設定するには、[新しい内部ディクショナリを追加する(Add New Internal Dictionary)] セクションの [サービス項目(Service Item)] フィールドで、サービス項目を名前で検索し、表示されるポップアップ ウィンドウからサービス項目をクリックします。
        4. 外部ディクショナリを設定するには、[外部ディクショナリを追加する(Add an External Dictionary)] セクションで、作成されるディクショナリの基となるデータ ソースの名前をクリックします。 [新しい外部ディクショナリ(New External Dictionary)] ウィンドウが表示されます。 データ ソース用のログインとパスワードはアプリケーション サーバですでに設定されています。
        ステップ 4   内部ディクショナリを設定するためのフィールドの表を使用して、ディクショナリにデータ要素を追加します。
        ステップ 5   ディクショナリ属性の表を使用して、ディクショナリ属性を追加します。 複数の属性を追加するには、[フィールドの追加(Add Field)] をクリックします。
        ステップ 6   [ディクショナリを保存(Save Dictionary)] をクリックします。

        システムからディクショナリを削除するには、[Service Designer] > [ディクショナリ(Dictionaries)] の順に選択し、削除する特定のディクショナリを選択し、[ディクショナリを削除(Delete Dictionary)] をクリックします。


        (注)  


        条件付きルールまたはデータ取得ルールと関連付けがある場合は、ディクショナリまたはディクショナリ フィールドの削除が回避されます。
        表 2 内部ディクショナリを設定するためのフィールド

        フィールド

        説明

        ディクショナリ名(Dictionary Name)

        このフィールドにディクショナリの名前を入力します。 使用可能な文字は、英数字、アンダースコア、およびアポストロフィです。 スペースは使用できません。

        グループ名(Group Name)

        ディクショナリ グループにこのディクショナリを配置する場合には、[更新(Update)] ボタンをクリックします。 ディクショナリとディクショナリ グループとの関連付けに関するシステム動作はありません。

        デフォルトキャプション(Default Caption)

        サービス フォームのセクション タイトルに表示するテキストをこのフィールドに入力します。

        連絡先担当者

        これは、組織のサイト基準およびベスト プラクティスにおいて、ディクショナリへの考えられる変更やディクショナリの使用に関する相談窓口となる個人です。

        サービス項目ファミリ(Service Item Family)

        これはオプションのテキスト入力フィールドで、レポートの目的で論理エンティティを作成するために複数のディクショナリをグループ化できます。 たとえば、3 つの独立したディクショナリを一つにまとめることで、デスクトップ構成のための完全なセットを構成することができます。

        (注)      このフィールドは外部ディクショナリには適用されません。

        レポート可能(Reportable)

        ディクショナリがレポート可能な場合には、ディクショナリ定義を変更する機能が一時的に無効になります。 レポート可能なディクショナリ内のフィールドのデータ型は、数値/通貨型、日付/日時型、文字型の間で切り替えることはできません。 ディクショナリに他の変更を行いたい場合には、[レポート可能(Reportable)] 設定を [いいえ(No)] に切り替えて、ディクショナリを保存し、変更を行ってから設定を元の値に戻します。 Advanced Reporting Ad-Hoc レポート機能および Report Designer 機能の使用に対抗して、レポートすることができるものにディクショナリを追加するには、[レポート可能(Reportable)] フィールドを [はい(Yes)] に設定します。

        ディクショナリをレポート可能と指定すると、アドホック レポートまたは Report Designer でクエリの件名としてそのディクショナリが表示されます。

        (注)      ディクショナリをレポート可能にするかどうかを決定する際に考慮すべき多くの影響があります。 ディクショナリをレポート可能にするかどうかを決定するためのガイダンスについては、『Cisco Prime Service Catalog Reporting Guide』を参照してください。外部ディクショナリをレポート可能とマークする場合は、すべてのデータ型がサポートされるわけではないことに注意してください。

        説明(Description)

        このディクショナリがどのように使用されるかの説明を入力します。 これは、このディクショナリを使用する可能性がある他のサービス設計者にとって非常に有用な情報です。

        リビジョンの注記(Revision Notes)

        セットアップ時はこのフィールドを無視してください。後で、このディクショナリに変更を加える場合に使用します。 リビジョンに関する注釈を入力し、[ディクショナリを保存(Save Dictionary)] をクリックできます。

        DBAの注記(DBA Notes)

        このフィールドはオプションで、このディクショナリの使用に関するデータベース固有の情報を入力します。 このテキスト領域は、Request Center DBA 以外の DBA によって維持されている可能性がある外部テーブルと接続するため、外部ディクショナリに最も関連しています。

        ディクショナリが表す(Dictionary Represents)

        このフィールドは外部ディクショナリの設定のみに適用されます。 テーブル内のデータ(読み取り/書き込み)またはクエリの結果(読み取り専用)を選択するオプション ボタンをクリックします。 テーブル内のデータ(読み取り/書き込み)をクリックした場合は、次の手順に従います。

        1. [テーブル名(Table Name)] ドロップダウン メニューからテーブル名を選択します。
        2. [要求エントリID列(Requisition Entry ID Column)] ドロップダウン メニューから、要求番号のストレージ用に予約されているデータ テーブルの列を選択します。
        3. [プライマリキーの列(Primary Key Column)] ドロップダウン メニューから、プライマリ検索キーを選択します。

        クエリの結果(読み取り専用)をクリックした場合は、次の手順に従います。

        1. [SQLステートメント(SQL statement)] フィールドに SQL ステートメントを入力します。
        2. [SQLステートメントのテスト] をクリックし、ステートメントを確認します。
        表 3 ディクショナリ属性

        フィールド

        説明

        名前(Name)

        フィールドの名前は、英数字およびアンダースコアを使用でき、文字で始める必要があります。 スペースや他の特殊文字は使用できません。 JavaScript の予約語(「this」など)は、フィールド名に使用できません。

        タイプ(Type)

        データ型は、ディクショナリがフォームに含まれている場合に選択できる HTML 表現に影響します。 それは、次に、ルールと ISF 関数をフィールドに適用する方法に影響するとともに、ディクショナリまたはディクショナリを含むサービスをレポート可能にするかなど、データ マート内のフィールドの使用方法に影響します。 フィールドのデータ型を選択します。 データ型とその動作の説明については、フィールド タイプの表を参照してください。

        最大、10進数(Maximum, Decimals)

        ユーザがこのフィールドに入力できる文字列の最大長を入力します。 数値フィールドの場合は、小数点の右側の小数位の数を入力します。 整数の場合は 0 を入力します。 サービス項目ベースのディクショナリ(SIBD)の場合は、[暗号化(Encrypt)] が属性に対し有効になっている場合、ユーザがこのフィールドに入力できる文字列の最大長は 2 で割られます。 これは、SIBD 属性がフォーム データをサービス項目テーブルに挿入し、暗号化中に余計な文字が属性に挿入されるためです。

        複数値(Multivalue)

        タスクの実行を制御するための式に INCLUDES 演算子を使用するときは、[複数値(Multivalue)] のチェック ボックスをオンにします。 INCLUDES 演算子は、複数値データ型の値を他の式と比較します。 複数値フィールドは、次の要素にマップします:複数選択、チェックボックス、およびオプション ボタン。

        (注)      DefMultivalue および TxMultivalue レコードは複数値フィールドに対して作成されます。

        グリッドで表示(Show in Grid)

        ディクショナリが [グリッドとして表示(Display as Grid)] に設定されたときに、ディクショナリ内で [グリッドで表示(Show in Grid)] および [使用(Use)] に設定されたフィールドが、サービス フォーム上でグリッド内の列として表示されます。 グリッドは、複数値セルの機能を持たないため、[グリッドで表示(Show in Grid)] と [複数値(Multivalue)] は互いに排他的です。 デフォルトでは、グリッドは 20 以上の列を持てません。newscale.properties ファイルの「dictionary.attributes.maximum.showingrid.count」プロパティにより定義されます。

        (注)      外部ディクショナリ内のフィールドは、グリッドで使用できません。したがって、[グリッドで表示(Show in Grid)] 列を持ちません。 また、予約済みディクショナリ(Customer_Information と Initiator_Information)は本質的に 1 セットのデータのみ表現するため、これらのディクショナリ内のフィールドはグリッドで使用できません。 グリッドの詳細については、複数のデータ インスタンスを含むフィールド向けのグリッド ディクショナリの設計を参照してください。

        暗号化

        パスワード、受取人氏名、口座番号などの機密データを暗号化するには、このチェックボックスを選択します。 機密情報は、保存時、確認時、アクセス時、記録時、または外部システムへの送信時に公開される場合があり、また、設定時に暗号化するときに自動的にマスクされます。 暗号化は、次の場所に適用されます。

        • サービスのフォーム データ
        • [Service Item Manager] > [サービス項目の管理(Manage Service Items)]
        • [Service Catalog] > [マイスタッフ(My Stuff)]
        • [管理(Administration)] > [ユーティリティ(Utilities)] > [フォームデータビューア(Form Data Viewer)]
        • [Service Link] > [トランザクションの表示(View Transactions)] > [メッセージタイプのリンク(Message Type link)] > [nsXMLメッセージ/外部メッセージ(nsXML Message / External Message)]
        • [My Services] > [サービス項目(Service Items)]
        • サーバ ログ
        • SI データを読み取る nsAPI
        • HTML ソース
        (注)      ディクショナリに対し最大 3 つのセキュアな文字列を設定できます。 この制限は、暗号化中は合成値に元のフィールド値よりも余計な文字が含まれ、パフォーマンスに影響を与える可能性があるためです。 したがって、ディクショナリの最大長を設定する場合は、暗号化された値が指定したディクショナリの長さを超えないように、適切なバッファ長を提供します。 セキュアな文字列は、テキスト フィールド タイプのみに適用されます。
        表 4 フィールド タイプ

        タイプ

        説明とアクティブ フォームの意味

        テキスト(Text)

        デフォルトのデータ型であり、英数字データをサポートします。単一行または複数行テキストとして表されるフィールドで使用する必要があります。

        番号(Number)

        整数と自然数を含む、すべての数値のデータ型。アプリケーションは長さだけでなく 10 進精度を確認するため、[10進数(Decimals)] 列内に精度を指定することが重要です。

        アカウント(Account)

        ドキュメント専用。データは、英数字として扱われます。

        日付(Date)

        データベース固有の日時型と互換性のあるデータ。ただし、表示は日付に制限され、データ入力用にカレンダー ウィジェットが提供されます。

        ブール値

        取り得る値が、「はい(Yes)」と「いいえ(No)」で表される「true」と「false」であるデータ オブジェクト。

        電話

        ドキュメント専用。データは、英数字として扱われます。

        SSN(社会保障番号)

        ドキュメント専用。データは、英数字として扱われます。

        資金

        データに有効な数のみ含まれるか検証されます。通貨記号とカンマは入力できません。数字のみ入力でき、小数点以下 3 桁まで入力できます。

        Person

        データは個人プロファイル内の個人 ID に対して検証されます。検証にはサービス フォームに自動的にレンダリングされる [検索(Search)] ボタンを通して、[個人検索(Person Search)] ダイアログボックスを使用します。 Person データ型は、基本的には下位互換性のために提供されています。この機能が必要な場合には、個人ベースのディクショナリを作成する必要があります。

        URL

        英数字で保存されるデータ。保存された値は、テキストと値の HTML 表現の両方で示され、指定された URL へのリンクを提供します。

        日付および時刻(Date and Time)

        日付および時刻として保存されるデータ。データ入力用に提供されるカレンダー ウィジェットには、時間選択ウィジェットが含まれます。

        サービス要求中にディクショナリを編集する権限の定義

        ディクショナリがフォームで使用される場合、ディクショナリへのアクセスを制御する方法を指定できます。 この手順を使用して、要求ライフ サイクルでディクショナリを表示または編集できるユーザを制御するために、システム モーメントごとに権限を定義できます。 通常、発信者が要求の詳細を提供する必要があるディクショナリのみが編集可能です。 承認者、確認者、またはタスク実行者によってのみ使用されるディクショナリには、アクセス権が割り当てられていません。 サービスに設定されている承認と確認に基づいて、要求には承認段階が存在しないか、または任意の数の承認段階が存在します。

        ディクショナリへの表示機能の影響

        特定の時点でディクショナリを表示可能ではあるが編集不可に指定すると、ディクショナリ内のすべてのフィールドが HTML ラベル(読み取り専用テキスト)としてレンダリングされます。

        • 複数の選択肢を持つフィールド(チェックボックス、複数選択ドロップダウンリスト)のテキストでは、これらのフィールドに対してすでに選択されているオプションが、カンマ区切りの値リストで示されます。
        • [ユーザ(Person)] フィールドのラベルには、以前選択された個人の名前が表示されます。 付随する [検索(Search)] ボタンは無効になっています。 2 番目(非表示)のオブジェクトには、選択した個人の一意の識別子が含まれます。
        • URL は、ハイパーリンクされた HTML ラベルとしてレンダリングされます。

        編集不可のディクショナリ内のフィールドには HTML DOM オブジェクト(つまり、<input> タグ)が存在しないため、適用できるルールまたは ISF 関数はサブセットに制限されます。 これらの制限は、以降の条件付きルールと ISF 関数の詳細な説明に記載されています。

        アクセス レベルは、ディクショナリ レベルで適用されます。 特定の時点で、そのすべてのフィールドを含めてディクショナリ全体が非表示か、または表示されるが、その表示可能なフィールドがすべて定型文としてレンダリングされるか、または表示されるが、そのフィールドはユーザによって編集可能かルールによって操作可能な HTML 入力オブジェクトのセットとしてレンダリングされます。


        (注)  


        すべてのアクセス制御の割り当ては、提供計画の一部として実行されるすべてのタスクに関係しています。 異なるタスクの異なるユーザに対してディクショナリに異なる権限を割り当てる必要がある場合は、条件付きルールによってこの権限を割り当てる必要があります。 アクセス制御設定は、常に、特定のユーザまたはグループに対して特定のディクショナリに必要となるすべての権限を付与する必要があります。 条件付きルールは、アクセス特権を削除できますが、アクセス特権が [アクセス制御( Access Control)] タブを使って元から指定していない場合は、それらを付与することはできません。

        権限を割り当てるための [アクセス制御(Access Control)] タブの使用

        [アクセス制御(Access Control)] タブを使って権限を割り当てると、アクティブ フォーム ルールを指定する設計者および ISF のプログラマに重要な影響を与えます。

        • 表示 ディクショナリの場合アクセス 制御 を介してディクショナリを非表示にするということは、その時点およびディクショナリが非表示にされた参加者のサービス フォームには、ディクショナリで定義されたオブジェクトが提示されないことを意味しています。 したがって、ルールまたは ISF を使用してディクショナリやフィールドの内容、または可視性を操作することはできません。

        ユーザに非表示のディクショナリでフィールドの値を操作する必要がある場合は、これらのディクショナリで機能するフォーム ルールをサーバ側で実行するように設定できます。 詳細については、サービス項目ベースのディクショナリのフォーム動作の定義を参照してください。 たとえば、ユーザに値を知られることなく、一連のフィールドにデフォルトの値を投入できます。

        • 表示 専用 ディクショナリの場合は、フィールドを編集できません。 ただし、ルールまたは ISF を使用して、アクセス制御によって表示専用に設定されたディクショナリ内のフィールドの現在値を取得すること、ビューでフィールドを一時的に非表示にすること、またはフレームワークによって提供された他の機能を適用できます。
        • 編集可能な ディクショナリ の場合は、全機能を使用して、ディクショナリまたはディクショナリ内のフィールドの外観と動作を操作できます。

        ディクショナリのアクセス制御を「なし」(つまり、[表示(View)] と [編集(Edit)] のいずれもオフ)に設定すると、ディクショナリはブラウザに送信されません。 ただし、ルールがサーバで実行されることを条件として、引き続きフォーム ルールを設定して、ディクショナリにデータを格納できます(サービス項目ベースのディクショナリのフォーム動作の定義を参照)。 これは、引き続きブラウザ セッションの結果を収集およびデータベースに格納するとともに、ブラウザにレンダリングされるサービス フォームを可能な限り小さく維持するための強力な手法です。

        アクセス制御設定の管理上のオーバーライド

        「サービス ディクショナリの管理」機能が付与されているユーザによってサービス フォームが実行されると、Service Designer を使って割り当てられたアクセス制御は無視されます (この機能は「サイト管理者」および「分散サービス設計者」のロールに含まれています)。このようなユーザに対して、すべてのディクショナリは指定されたアクセス制御に関係なく、すべての時点に編集できます。


        ヒント


        この機能はフォームの外観の構築とテストを容易にするために提供されており、慎重に割り当てる必要があります。


        はじめる前に

        編集できないディクショナリのフィールドの動作を理解するには、「ディクショナリに対する表示機能の影響」を参照してください。

          ステップ 1   [Service Designer] > [アクティブフォームコンポーネント(Active Form Components)] の順に選択します。 アクティブ フォーム コンポーネント ツリーからフォームをクリックします。
          ステップ 2   設定するフォームを選択し、[アクセス制御(Access Control)] タブをクリックします。
          ステップ 3   システム モーメントをクリックし、設定するディクショナリをクリックします。
          ステップ 4   その時点の各参加者に対する [表示(View)] および/または [編集(Edit)] をクリックします。
          (注)      [表示(View)] または [編集(Edit)] をオンにしないと、指定したシステム モーメント中にそのディクショナリの参加者に効率的に権限を付与できません。 これは、参加者が指定したシステム モーメント中にディクショナリ フィールドをまったく表示できないことを意味します。
          ステップ 5   [参加者の追加(Add Participant)] ドロップダウンリストから参加者のタイプを選択します。 参加者のタイプと関連付けられている機能に関する詳細については、参加者のタイプの表を参照してください。
          ステップ 6   選択したシステム モーメント中のすべてのディクショナリに対する権限の設定を続行します。 残りのシステム モーメントおよびディクショナリに進みます。
          ステップ 7   [フォームの保存(Save Form)] をクリックします。

          必要なくなった場合は、アクティブ フォーム コンポーネントからディクショナリを簡単に削除でき、または、システムからディクショナリを削除することで、ディクショナリが使用されていたフォーム コンポーネントからも削除されます。

          表 5 参加者のタイプ

          参加者の種類

          説明

          カスタマー

          サービス オーダー フォームを記入し、送信するユーザ。機密情報を含むディクショナリを除いて、通常、サービス提供時点でディクショナリの表示アクセス権が付与されています。

          サービス チーム(Service Team)

          このサービスが存在するサービス グループを「所有」するサービス チーム OU のメンバーである、サービス実行者およびサービス マネージャ 「サービス チーム」の参加者は、サービスが存在するサービス グループを所有するサービス チームを意味しています。 このフォームを複数のサービスに含める場合、サービスが存在するグループによって、各サービスのサービス チームの参加者が異なります。 そのため、フォームに「参加者を追加」して、現時点でディクショナリ データにアクセスする必要があるサービス チームを明示的に示すことを推奨します。 複雑な提供計画のサービスの場合、計画の各タスクを異なるサービス チームが実行する必要がある場合があります。 この場合も、参加者を追加する必要があります。

          組織

          サービス要求の確認や承認を行うメンバーなど、カスタマーのホーム OU のメンバー。

          財務チーム(Financials Team)

          サイト全体の財務承認のため、財務チームとして [管理(Administration)] で設定された OU(存在する場合)を指します。

          アドホックタスクの実行者(Ad-Hoc Task Performers)

          アドホック タスクを受信する実行者またはキュー メンバー


          (注)  


          Customer-Initiator フォームは、実質的にすべてのサービスで使用される可能性があるため、新たな懸念事項になります。 したがって、特に Customer ディクショナリと Initiator ディクショナリに表示権限のみを設定する必要がある場合、[追加の参加者( Additional Participants)] オプションを通して「任意のユーザにアクセスを追加」するのが最も効率的なことがあります。

          特定のサービスへのアクセス制御設定の追加

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

          サービス設計における標準の定義

          標準は、アクティブ フォーム コンポーネントの設計、特に、サービスのオーダー時にカスタマーが特定の応答または選択にドリル ダウンできるようにするデータ取得ルールにおいて役立ちます。 標準によって、サービス フォームへのユーザ エントリを検証するために使用できる参照データが提供されたり、そのフォーム上のフィールドに対するデフォルト値が提供されます。Prime Service Catalog で Service Item Manager を使用して、新しい標準を作成したり、ファイルから既存の標準データまたは定義をインポートできます。

          標準テーブルは、外部のデータソースで保持されるリレーショナル データベース テーブルと同じ機能を実行します。つまり、(ドロップダウンリストでの)表示または(ユーザから提供されたデータの)検証のために、行を取得できます。 標準テーブルと外部テーブルの相違点は次のとおりです。

          • 標準テーブルの保持は、Service Item Manager 内で完全に可能です。テーブルを作成したり、その構造を変更したり、内容を維持したりするために DBA を介入させる必要はありません。 標準レコードの作成、削除、または変更を行うためのユーザ インターフェイスを提供するだけでなく、XML ファイルから標準テーブルにデータをインポートして、そのテーブルの構造を作成または変更できます。
          • 標準テーブルは、データソースとして標準を選択することにより、テーブル ベースのデータ取得ルールで直接使用できます。 SQL クエリーのデータ取得ルール、または SQL ベースのオプション リストの構成でも使用できます。

          (注)  


          デフォルトでは、Catalog Deployer は、サービスが指定した標準を使用するデータ取得を導入するときに任意の標準エントリを展開します。 管理設定を [標準エントリを配置(Deploy standards entries)] に変更することにより、この動作を上書きすることができます。 これは、たとえば、実稼働環境での管理者が、すべての標準を実稼働環境またはテスト環境で定義するよりも、標準を保持する責務がある場合に適しています。

          ユーザに割り当てられたロールに基づいて、サービス項目標準を表示または編集する権限を定義できます。 追加できる権限の詳細については、『Cisco Prime Service Catalog Administration and Operations Guide』の「Service Item Manager module in Assigning Permissions」の項を参照してください。

          標準を定義するには、次の手順を実行します。

          1. 標準テーブルの機能要件を指定します。 各テーブルに含まれる必要のあるデータは何か。 また、Service Catalog 内でどのように使用されるか。
          2. 標準を定義するには Service Item Manager を使用します。 「標準の設定」を参照してください。
          3. Service Catalog のセットアップに関連したデータを標準テーブルに入力します。 「標準テーブルへのデータの追加」を参照してください。
          4. 標準テーブルにアクセスするデータ取得ルールを書き込みます。

          標準グループの作成

          手順


            ステップ 1   [Service Item Manager] > [サービス項目の設計(Design Service Items)] > [標準の設計(Design Standards)] の順に選択します。
            ステップ 2   左側のペインの標準テーブルでプラス記号(+)をクリックし、[新しい標準グループ(New Standard Group)] を選択します。
            ステップ 3   グループ名と説明を指定し、[追加(Add)] をクリックします。

            標準を編集するためのロール ベースの権限の追加


              ステップ 1   [Service Item Manager] > [サービス項目の設計(Design Service Items)] > [権限(Permissions)] の順に選択します。
              ステップ 2   [権限のサマリー(Permission Summary)] ウィンドウに、選択されたサービス項目に割り当てられた権限が一覧表示されます。
              ステップ 3   [役割(Role)] フィールドで虫めがねアイコンをクリックし、ロールを選択します。
              ステップ 4   [権限(Permissions To)] ドロップダウンリストから権限を選択し、[追加(Add)] をクリックします。

              標準の設定

              この手順を使用して、新しい標準定義を作成し、定義したものを編集できます。


                ステップ 1   [Service Item Manager] > [サービス項目の設計(Design Service Items)] > [標準の設計(Design Standards)] の順に選択します。
                ステップ 2   左側のペインの標準テーブルでプラス記号(+)をクリックし、[新しい標準(New Standard)] を選択します。
                ステップ 3   属性の定義を追加し、[追加(Add)] をクリックします。 属性で、標準について保持されるフィールド(データ)が指定されます。 「標準に対する属性」を参照してください。
                ステップ 4   既存の標準定義を更新するには、標準テーブルの作成中に定義した属性を変更し、[保存(Save)] をクリックします。
                ステップ 5   テーブルに定義を追加するには、[列定義に追加(Add in the Column Definitions)] ペインをクリックします。
                • [表示名(Display Name)]:[マイアイテム(My Items)] ポートレットを含む、すべての Service Catalog ページで属性ラベルとして表示される属性の名前。
                • [名前(Name)]:属性の内部名。基礎となっているデータベースのキーワードや予約語(INTEGER、ORDER、VARCHAR など)は使用できません。 名前は 27 文字までに制限されています。
                • [属性タイプ(Attribute Type)]:属性データを保存するためのデータ型。

                最後に保存してから追加または更新されたすべての属性に、属性の表示名の左上に赤の三角形が付きます。


                標準を定義した場合は、Service Item Manager の [データのインポート(Import Data)] タブを使用して、それらを Prime Service Catalog にインポートすることもできます。 外部システムから標準をインポートする方法の詳細については、「標準のインポート」を参照してください。

                表 6 標準に対する属性

                フィールド

                説明

                表示名(Display Name)

                名前のユーザ フレンドリーなバージョン。これにはスペースを含めることができます。

                名前(Name)

                システムが標準とそのデータの参照に使用する標準の名前。 これは、Service Catalog のトランザクション データベースで動的に作成され、保持されているテーブルに対応します。 標準名で使用できるのは、英数字と下線(_)で、スペースは使用できません。 名前の先頭は英数字である必要があります。 Service Item Manager は、標準名と同じ名前で、プレフィックスが「St」のデータベース テーブルを作成します。

                標準グループ(Standard Group)

                標準テーブルを関連付けるグループを選択します。

                説明(Description)

                作成するテーブルについての説明

                標準テーブルへのデータの追加

                Service Catalog は、データを標準テーブルに追加するための次の方法をサポートしています。

                • 標準データをインタラクティブに編集するには、Service Item Manager の [標準の管理(Manage Standards)] タブを使用します。 このタブには、標準に指定されたすべての属性を含むグリッドが示されます。
                • ファイルまたはサービス リンクから標準データまたは定義をインポートするには、Service Item Manager の [データのインポート(Import Data)] タブを使用します。 ファイルまたはサービス リンクからの標準のインポートの詳細については、「標準のインポート」を参照してください。 Prime Service Catalog にインポートできるファイルの形式については、「サービス項目および標準に関するインポート ファイルの形式」を参照してください。
                標準のインポート

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

                ファイルからの標準のインポート

                [Service Item Manager] > [ファイルからインポート(Import from File)] オプションを使用して、外部ソースから標準のデータと定義をインポートできます。 インポートするファイルは、ANSI エンコーディング ASCII または UTF-8 を使用する必要があります。 Unicode エンコーディングはサポートされていません。 [データ(Data)] または [定義(Definition)] オプションを選択して、ファイルのその部分のみをインポートしたり、両方を選択することもできます。 両方をインポートする選択をした場合で、XML ファイルに定義セクションしか含まれていない場合は、システムは定義のみをインポートします。

                標準データのインポートでは、既存のすべてのデータは常にインポートされたデータで上書きされます。


                (注)  


                標準データをインポートするオプションは、標準を参照するデータ取得ルールが含まれるサービスの配置での Catalog Deployer のアクションを補足するか、置換します。 デフォルトでは、Catalog Deployer によって、ソース環境で事前に定義された標準定義とすべてのデータの両方がターゲット環境に配置されます。 標準データが環境間で変化しない場合、この動作が推奨されます。 その他の場合は、[標準テーブルへのエントリ(データ)の展開(Deploy Entries (data) in Standards Tables)] に対する管理設定をオフにすることで、このデフォルトの動作を変更できます。

                標準定義をインポートする場合は、同じ競合の解決オプションを使用できます。それらのオプションを下記にまとめます。

                表 7 標準定義の競合解決

                定義

                競合解決

                説明

                定義

                上書き

                インポートされる標準のすべての属性値と一致する属性値が標準レコードが存在する場合、この標準が更新されて、インポートされるレコードで指定された属性に対して「のみ」標準の値が含まれるようにします。

                これは、インポートされる標準レコードに、一部の属性に対してのみ指定された値が含まれているにもかかわらず、データベース内の既存の標準には追加の属性に対して指定された値が含まれていると、これらの値がヌルに設定されることを意味します。

                マージ

                下記の Insert と同じです。

                Insert

                属性値がインポートされる標準のすべての属性値と一致する標準が存在する場合、この標準は作成されません。

                アクティブ フォーム コンポーネントを使用したサービス フォームの外観と動作の設定

                フォームは、サービスを実装するための構成要素です。 オーダー可能な各サービスは、1 つ以上のフォームで構成されます。 各フォームは、ユーザがサービス カタログのサービスをオーダーするとき、サービスの要求を承認または確認するとき、および受信者へのサービスの提供に必要な手順を完了するときに、ユーザに提示される Web ページの外観と動作を指定します。 その Web ページは、「サービス フォーム」と呼ばれます。

                フォーム ルールにより、サービス設計者は、コードを記述することなく、サービス フォームを Rich Internet Application(RIA)にすることができます。 (RIA は、ユーザが入力画面の最後で [送信(Submit)] ボタンをクリックする必要なく、アプリケーションがユーザが入力した内容や画面に表示される内容に瞬時に応答することを意味します。)ルールを使用することで、設計者はサービス フォームの外観と動作をユーザが開始したイベントに応答してどのように変更するべきかを指定できます。

                条件付きルールの共通の使用方法には、次のものが含まれます。

                • オプション ボタン(たとえば、[はい(Yes)]/[いいえ(No)] の選択)に基づいて、フィールドを有効/無効または表示/非表示にする
                • 別のフィールドの値に基づいて、または特定タスクの実行中や提供(実施)サイクル中は、フィールドを必須としてマークする
                • ディクショナリ全体を表示/非表示にすることで、サービスの提供期間内の各種タスクに対して、ユーザ エクスペリエンスをカスタマイズする
                • フィールドにフォーカスを設定して、ユーザの注意を促す
                • データが正しいことを検証する

                動的データ取得ルールは、サービス フォームとリレーショナル データベースに格納されている情報間でオンラインのリアルタイム インターフェイスを提供します。 これらのルールにより、このようなデータをディクショナリ フィールドに表示すること、またはサービス要求元または実施者が入力した項目が正しいことを判断するために問い合わせることができます。 データ取得ルールの共通の使用方法には、次のものが含まれます。

                • Configuration Management Database(CMDB)、ERP、HR システムなど、他のアプリケーションで維持されている情報を、フォーム データに事前に入力する
                • 動的なドリル ダウンを提供して、以前入力した項目、または別のリストから選択した項目に基づき、ドロップダウンリストに表示される項目が動的に変化するようにする

                アクティブ フォーム グループの作成

                すべてのアクティブ フォーム コンポーネントは、フォーム グループに配置する必要があります。


                  ステップ 1   [Service Designer] > [アクティブフォームコンポーネント(Active Form Component)] の順に選択します。
                  ステップ 2   [新規(New)] > [フォームグループ(Form Group)] の順に選択します。
                  ステップ 3   新しいフォーム グループの名前、および必要に応じて簡単な説明を入力し、[保存(Save)] をクリックします。

                  新しいフォーム グループは、ページが更新されるまではツリーの最上位に表示され、更新後はアルファベット順の場所に移動されます。


                  サービス フォームを設計するためのグループ レベル権限の割り当て

                  [権限(Permissions)] タブを使用してフォーム グループへのオブジェクト レベルの権限を割り当てます。 これらのオブジェクト レベルの権限は、人、組織単位、グループ、役職、およびロールが実行できるアクションのタイプです。 次のタイプの権限を付与できます。

                  • DesignForms:ユーザはこのフォーム グループのフォームを設計し、グループ データを変更できます。 通常、これらの権限はこのフォーム グループのフォームを設計および設定する個人に予約されます。
                  • フォームの表示:ユーザはフォーム グループとフォーム定義を表示できますが、変更はできません。

                  (注)  


                  新しいフォーム グループは、「だれにでも」フォームの設計を許可するように設定してはいけません。 手動で「任意のユーザにアクセス権を付与する」機能は、フォーム グループが正常に定義され確立された後に使用することを目的とした時間節約のオプションです。

                  Service Catalog の以前のバージョンの場合は、各サービス グループに対し、対応するフォーム グループが作成されます。 フォーム グループの名前の前に「UPGD: Form」が付き、その後にサービス グループ名が続きます。

                  アクティブ フォームの作成

                  アクティブ フォーム コンポーネントはサービス フォームの構成要素であり、アクティブ フォーム ルールを伴うディクショナリはフォーム コンポーネントの構成要素です。サービス フォームの外観と動作は、ディクショナリおよびそのコンポーネント フィールドがサービス定義に使用されるアクティブ フォーム コンポーネントの一部としてどのように設定されているかによって決まります。


                    ステップ 1   [Service Designer] > [アクティブフォームコンポーネント(Active Form Component)] の順に選択します。
                    ステップ 2   [新規(New)] > [アクティブフォームコンポーネント(Active Form Component)] の順に選択します。
                    ステップ 3   新しいフォームの名前と簡単な説明を入力します。
                    ステップ 4   フォーム グループ フィールドをクリックし、フォームに関連付けるグループを 1 つ選択します。
                    ステップ 5   [フォームの保存(Save Form)] をクリックします。

                    フォームを保存後、ディクショナリをフォームに追加したり、フォーム属性を変更および設定できます。 ディクショナリの追加方法やフォーム属性の変更方法の詳細については、「アクティブ フォームの設定」を参照してください。 

                    アクティブ フォームの設定


                    (注)  


                    再利用可能なフォーム コンポーネントは、複数のサービス間で使用するために一度だけ設定する必要があります。 フォーム コンポーネントを変更すると、変更はアクティブ フォーム コンポーネントを使用するすべてのサービスに適用されます。

                    次の属性は、アクティブ フォームに設定できます。

                    • フォーム コンテンツ:フォームに含まれるディクショナリ、およびディクショナリとそのディクショナリを構成するフィールドの順序が表示されます。 詳細については、フォームへのディクショナリの追加を参照してください。
                    • 表示プロパティ:ユーザがサービス フォームで作業するときに、各ディクショナリを構成する個々の属性を Web ページにレンダリングする方法。 詳細については、フォームの外観の定義を参照してください。
                    • アクセス制御:要求ライフ サイクル内の各時点で、サービス フォームを構成する特定のディクショナリを表示または編集できるユーザまたはユーザのグループ。 詳細については、サービス要求中にディクショナリを編集する権限の定義を参照してください。
                    • アクティブ フォーム ルール:サービス フォームに表示されるディクショナリや個々の属性の外観または動作を条件に従って変更するためのルール、またはリレーショナル データ ソースからデータを動的に取得するためのルール。 詳細については、フォーム ルールを使用した動的なフォーム動作の設定を参照してください。
                    • アクティブ フォームの動作:条件付きルールの実行をトリガーするイベント、または JavaScript を ISF と組み合わせて使用して記述されたスクリプト。 詳細については、サービス フォームへのフォーム ルールの追加を参照してください。

                    フォームへのディクショナリの追加

                    フォームを設定する最初の手順は、そのフォームで使用されるディクショナリ、それらのディクショナリの順序と向き、各ディクショナリが表示されるフィールドを指定することです。 ディクショナリを追加するには、[フォームコンテンツ(Form Content )] タブを使用します。


                    (注)  


                    フォームに含まれるディクショナリをこのタブで確認すると、ディクショナリ名の前にディクショナリ グループ名が付いています。 ディクショナリ名の左のプラス記号(+)をクリックして、そのディクショナリ内のフィールドを表示します。 ディクショナリまたはフィールドの表示順序を変更するには、移動させるコンポーネントを選択して、そのコンポーネントが目的のシーケンスになるまで、ページの右にある上矢印キーまたは下矢印キーをクリックします。

                    はじめる前に

                    以下は、サービス フォームにディクショナリを追加する前の設計上の考慮事項です。

                    • フォームごとに追加するディクショナリの数と、どのディクショナリを追加するかを選択します。 単一のフォームが同じサービス向けである場合にのみ、そのフォームに複数のディクショナリを関連付けます。 たとえば、サービスのグループに 3 人の承認者で構成される承認のチェーンがあり、カスタマーによって選択され、要求時に提供されたデータに基づいて動的に決定される場合、「承認」フォームには 3 つのディクショナリ、FirstApprover、SecondApprover および ThirdApprover を含める必要があります。
                    • そのフォーム内で定義されたルールでディクショナリや属性を参照するためには、フォームにディクショナリを含める必要はありません。 さらに、フォームは、まったくディクショナリを含まなくてもかまいません。 この場合、フォームは、ルールのリポジトリです。 フォームは、他のフォームを含むサービスに含まれる必要があります。また、フォームは、ルールを参照するディクショナリを含む必要があります。
                    • 複数のフォームのうちの 1 つだけがサービスに含まれる場合には、同じディクショナリを複数のフォームで使用できます。 ただし、フォームの外観または動作に関連するすべてのアクティブなコンポーネントは、各フォームで定義する必要があります。そのため、これは理想的なアーキテクチャではありません。
                    • サービス バンドルの場合:
                      • 子サービスのフォーム レベル イベント(フォームがロードまたは送信されている場合)にアタッチされているルールまたは JavaScript は、無視されます。 これらのルールを指定するフォーム コンポーネントは、親サービスに含まれる必要があります。
                      • ディクショナリが複数の子サービスで発生した場合、サービス バンドルには一度だけ表示されます。 ディクショナリの設定は、そのディクショナリが含まれているアクティブ フォーム コンポーネントを含んでいる最初の子サービスで指定されている設定と一致します。 ディクショナリの設定がサービスによって異なる場合(たとえば、サービス固有のルールを適用によって)、その差異は無視されます。

                      ステップ 1   [Service Designer] > [アクティブフォームコンポーネント(Active Form Component)] の順に選択します。
                      ステップ 2   アクティブ フォーム コンポーネントのツリーでフォームをクリックします。 [フォームコンテンツ(FormContent)] を選択し、[ディクショナリの追加(Add Dictionaries)] をクリックします。
                      ステップ 3   [ディクショナリの追加(Add Dictionaries)] ダイアログボックスで、次を実行します。
                      1. [名前(Name)] 列で、使用可能なディクショナリを検索し、使用するものを選択します。
                      2. [グリッドとして表示(Display as Grid)] 列で、グリッドとして表示するディクショナリをチェックします。 [グリッドで表示(Show in Grid)] に設定されたディクショナリのフィールドは、グリッドで列として表示されます。 [グリッドとして表示(Display as Grid)] をオンにしてディクショナリを追加するときに、[グリッドで表示(Show in Grid)] および [使用(Use)] に設定されたフィールドのみが列に表示されます。 [使用(Use)] に設定されているフィールドで、[グリッドで表示(Show in Grid)] に設定されていないフィールドは表示されません。
                      3. [追加(Add)] をクリックします。

                        ディクショナリがフォームに追加され、[フォームコンテンツ(Form Content)] ページに戻ります。

                        グリッドとして追加したすべてのディクショナリに関して、[コンテンツ(Content)] タブの [グリッドとして表示(Display as Grid)] チェック ボックスがオンの状態で表示されます。 [コンテンツ(Content)] タブ上で、このチェック ボックスは常に選択不可となっており、変更できません。その目的は、フォーム上でどのディクショナリがグリッド フォーマットか示すことです。 ディクショナリを誤ってグリッドとして追加した場合、またはグリッド ディクショナリをフォームに追加するときに [グリッドとして表示(Display as Grid)] をオンにするのを忘れた場合には、そのディクショナリを削除し、[ディクショナリ(Dictionary)] ダイアログボックスで [グリッドとして表示(Display as Grid)] をオンまたはオフにしてもう一度追加できます。

                      ステップ 4   アクティブ フォーム コンポーネントがバンドルされたサービスで使用される場合は、このディクショナリを表示するためのオプションをオンにします。 [バンドルで表示(Show in Bundle)] は、このフォームのサービスがバンドルの一部である場合にアタッチされている場合はディクショナリ フィールドが表示されることを示します。
                      ステップ 5   [フォームの保存(Save Form)] をクリックします。

                      このフォームで使用されるサービスは、アクティブ フォーム コンポーネントがサービスによって使用されたときに自動的に読み込まれる読み取り専用テーブルです。 詳細については、サービス項目ベースのディクショナリのフォーム動作の定義を参照してください。


                      ディクショナリをアクティブ フォーム コンポーネントに追加した後に、フォーム フィールドとフォームの動作を設定できます。

                      フォームが複数のディクショナリを使用する場合は、ディクショナリ名の左にあるチェック ボックスをオンにして、ページの右側にある上矢印キーまたは下矢印キーを使用して、フォームに表示するディクショナリの順序を変更できます。


                      (注)  


                      [フォームコンテンツ(Form Content)] タブのディクショナリ名は、Service Designer のディクショナリ コンポーネントへのリンクです。 ディクショナリに別のフィールドを追加する必要がある場合、ここから単にディクショナリ名の上で Ctrl キーを押しながらクリックすることで、直接ディクショナリに移動できます。

                      フォームの外観の定義

                      各アクティブ フォーム コンポーネントの外観は、[表示プロパティ(Display Properties)] タブで設定します。 このタブで、各ディクショナリとその中のフィールドのプロパティを設定します。 ディクショナリ フィールドのデータ型は、ディクショナリの定義時に割り当てられます。同時にフィールドのストレージ要件も定義されます。 ディクショナリで定義できるフィールドの詳細については、ディクショナリの作成を参照してください。


                        ステップ 1   [Service Designer] > [アクティブフォームコンポーネント(Active Form Component)] の順に選択します。
                        ステップ 2   設定するフォームを選択し、フォームにすでに追加されているディクショナリがあると想定して、[表示プロパティ(Display Properties)] タブをクリックします。
                        ステップ 3   [このフォームで使用するディクショナリ(Dictionaries Used in This Form)] セクションから、フィールドを編集するディクショナリを展開します。
                        ステップ 4   ディクショナリの名前をクリックし、右側にプロパティを表示します。
                        ステップ 5   ディクショナリのキャプションを入力し、[キャプションの変更(Change Caption)] をクリックするか、またはデフォルトのキャプションに設定します。 ディクショナリが [グリッドとして表示(Display as Grid)] に設定されている場合は、[グリッドのオプション(Grid Options)] セクションにグリッド設定を入力します。
                        ステップ 6   ディクショナリ フィールドをクリックし、要件を設定します。 詳細については、HTML 表現のフィールドを参照してください。
                        ステップ 7   [保存(Save)] をクリックします。
                        ステップ 8   設定されているすべてのディクショナリに対してステップ 1 ~ 7 を繰り返します。


                        (注)  


                        ディクショナリおよびフィールドがフォーム コンポーネントに表示される順序を変更するには、[フォームコンテンツ(Form Content)] タブを使用します。
                        表 8 HTML 表現のフィールド

                        フィールド

                        説明

                        入力タイプ

                        グリッド ディクショナリの場合は、「選択(複数)」、「オプション ボタン」、および「チェックボックス」は [入力タイプ(Input Types)] のドロップダウンリストで使用できません。これらの制御はグリッドでレンダリングできないためです。

                        (注)      選択した入力タイプによって、ページが使用可能な設定オプションを動的に変更します。 たとえば、テキスト フィールド内に入力できる文字の最大数または最小数は選択できますが、パスワード フィールドについては選択できません。

                        入力タイプがエンド ユーザの選択肢(たとえば、オプション ボタン、チェックボックス、選択)に関係する場合、選択肢をフォームに左右に並べて表示するか上下に並べて表示するかを選択でき、[オプションリストとオプションの事前選択(Options List and Options Preselection)] サブ タブを使用して選択肢を設定できます。 詳細については、HTML フィールド表現の入力タイプの表を参照してください。

                        ラベル(Label)

                        ラベルを編集します。 たとえば、「Select_Person」を「Select Person」と読み取るように変更します。

                        ヘルプ テキスト

                        フォームを完了する方法について、エンド ユーザに指示を与えます。 たとえば、「スペースやダッシュを含まずに9桁のSSNを入力してください(Please enter your 9-digit SSN without any spaces or dashes)」などです。

                        デフォルト値(Default Value)

                        このフィールドを事前に入力するために名前空間を使用する場合は、ここに値を入力します。

                        一意の値の生成(Generate Unique Value)

                        [一意の値の生成(Generate unique value)] チェック ボックスをオンにすることで、入力タイプが「テキスト」、「非表示」、または「読み取り専用」の任意のディクショナリ フィールドに対する値として一意の ID を生成できます。 新しいサービスが要求されると、汎用一意識別子(UUID)が生成され、フォーム ロード時に、[一意の値の生成(Generate unique value)] がオンになっているすべてのフィールドのフィールド値として設定されます。 この手順の後、条件付きルールとデータ取得ルールが実行されます。したがって、このフィールドの値を設定する条件付きルールまたはデータ取得ルールがある場合、そのルールを実行することにより、この UUID 値を上書きできます。

                        範囲の検証(Validate Range)

                        システムにユーザの入力を検証させる場合は、このチェック ボックスをオンまたはオフにします。 すべてのフィールド タイプが検証をサポートしているわけではありません。

                        必須

                        オーダーを送信する前にフィールドへの入力をエンド ユーザに要求する場合は、[必須(Mandatory)] チェック ボックスをオンにします。

                        ボタンの追加(Add a Button)

                        フォームにボタンを追加する場合は、[ボタンの追加(Add a Button)] を選択します。 ユーザがボタンをクリックしたときに他のサイトに移動させるには、完全修飾 URL(http:// を含む)を入力します。

                        グリッドでボタンを設定することはできないので、この制御はグリッド ディクショナリには表示されません。

                        サーバ側で編集可能(Editable on server-side)

                        フィールドをサーバでのみ編集できるように設定するには、[サーバ側でのみ編集可能(Editable on server-side only)] チェック ボックスをオンにします。 機密情報や、デフォルトで設定された値または自動取得メカニズムによる値を含むディクショナリ フィールドでは、このチェック ボックスをオンにする必要があります。

                        これは、ハッカーがブラウザでデータを傍受したり変更したりできないようにするセキュリティ機能です。

                        高度なフォーマット設定(Advanced Formatting)

                        追加または代替の HTML フォーマット設定は、[高度なフォーマット設定(Advanced Formatting)] ボタンを使用して特定のフィールドに適用できます。グリッドで高度なフォーマット設定を設定することはできないので、この制御はグリッド ディクショナリには表示されません。

                        表 9 HTML フィールド表現の入力タイプ

                        入力タイプ

                        説明とアクティブ フォームの意味

                        テキスト

                        HMTL の「テキスト ボックス」としてレンダリングされます。

                        textarea

                        複数行のテキスト領域としてレンダリングされます。

                        password

                        パスワード フィールドとしてレンダリングされます。値は、アスタリスクで表示またはエコーされます。

                        hidden

                        HTML テキスト ボックスとしてレンダリングされますが、表示タイプは「非表示」です。

                        オプション(radio)

                        HTML オプション リストとしてレンダリングされます。このフィールドには、複数のオプションがあります。フィールド値は、現在選択されているオプションです。 [グリッドで表示(Show in Grid)] に設定されているフィールドには使用できません。

                        選択(単一)(select (single))

                        ユーザが単一の値を選択できる HTML ドロップダウン ボックスとしてレンダリングされます。

                        チェックボックス(check box)

                        Service Designer での設計に従って、可能なすべてのオプションに対する HTML チェック ボックスのセットとしてレンダリングされます。 [グリッドで表示(Show in Grid)] に設定されているフィールドには使用できません。

                        選択(複数)(select (multiple))

                        ユーザが複数の値を選択できる HTML ドロップダウン ボックスとしてレンダリングされます。 [グリッドで表示(Show in Grid)] に設定されているフィールドには使用できません。

                        SSN(社会保障番号)

                        単一行のテキスト ボックスとしてレンダリングされます。「SSN」は、ドキュメントのみ提供します。

                        Person

                        このフィールドは、2 つのオブジェクトとしてレンダリングされます。ドロップダウンリストには、複数の個人が表示され、1 人を選択できます。2 番目(非表示)のオブジェクトには、選択された個人の一意の識別子が含まれます。 この HTML 表現は、個人ベースのディクショナリ内の [人を選択します(Select_Person)] フィールドに自動的に適用されます。 また、自由形式のディクショナリ内の「Person」データ型のフィールドにも適用できます。ただし、後者の使用方法は、主に下位互換性のために提供されており、推奨しません。

                        URL

                        値を保存した後、URL へのアクセス用に生成されるリンク付きで、単一行のテキスト ボックスとしてレンダリングされます。

                        読み取り専用(read-only)

                        テキストとしてレンダリングされます。ユーザは値を入力できません。 サービス設計者は、このようなフィールドに値を提供する(一般には、フォーム ルールまたはデフォルト値表示プロパティから)責任があります。

                        複数のデータ インスタンスを含むフィールド向けのグリッド ディクショナリの設計

                        グリッドは、1 つのフォームで同じフィールドを持つ複数のデータ インスタンスを入力する必要があるフォームを設計する場合に有効です。 同じフィールドを持つ複数のセクションを作成するのではなく、複数のフィールドを持つ 1 つのグリッドを作成できます。 グリッドを使用すれば、ディクショナリを複数作って同じフィールドを複数保持する代わりに、ディクショナリを 1 つ作成および設定するだけで済みます。

                        グリッドの設定中に、フィールド ラベルがフィールドの上部に表示されるように、ディクショナリが 90 度回転します。 グリッド セルは、データベース内に個別のフィールドとして保存されるにもかかわらず、ブラウザでのレンダリング時には完全に個別のフィールドではありません。

                        グリッド ディクショナリと非グリッド ディクショナリの違い

                        • オプション ボタン、チェック ボックス、および選択(複数)の入力タイプは、使用できません。
                        • フィールド ラベルが列ヘッダーとして表示されます。 グリッド内のフィールド ラベルには、高度なフォーマットを設定できません。
                        • ボタンを使用できません。
                        • いくつかの ISF ディクショナリ レベル関数およびフィールド レベル関数は使用できません(フォーム ルールを使用した動的なフォーム動作の設定を参照)。
                        • グリッド フィールドは、データ取得ルールの作成時に、「トリガー フィールド」として選択できません。
                        • グリッド ディクショナリとそのフィールドは、条件付きルールの「トリガー条件」として選択できません。「アクション」ターゲットとしてのみ使用可能です。
                        • 条件付きルール アクションのサブセットがサポートされます。また、これは、個別のセルとしてではなく、全体として列に適用されます。
                        • Requisition API(RAPI)は、グリッド ディクショナリを含むサービスの送信に使用できません。
                        • Business Engine 名前空間および Service Link エージェント パラメータに対するグリッド ディクショナリ フィールドの使用はサポートされません。
                        • グリッド上では、サーバ側条件付きルールはサポートされません。

                        グリッド ディクショナリを設計するには、次の手順を実行します。


                          ステップ 1   [Service Designer] > [アクティブフォームコンポーネント(Active Form Component)] > [フォームコンテンツ(Form Content)] > [コンテンツ(Content)] タブで、ディクショナリの定義で [グリッドで表示(Show in Grid)] チェック ボックスをオンにすることで、グリッドに表示させるフィールドを選択します。
                            • 新しい個人ベースのディクショナリの場合は、[人を選択します(Select_Person)]、[ログインID(Login_ID)]、[個人識別(Personal_Identification)]、[Eメールアドレス(Email_Address)]、および [ホーム組織単位(Home_Organizational_Unit)] フィールドで [グリッドで表示(Show in Grid)] がデフォルトでオンになっています。
                          (注)      グリッドは、複数値セルの機能を持たないため、[グリッドで表示(Show in Grid)] と [複数値(Multivalue)] は互いに排他的です。
                            • 外部ディクショナリ内のフィールドは、グリッドで使用できません。したがって、[グリッドで表示(Show in Grid)] 列を持ちません。
                            • 予約済みディクショナリ(Customer_Information と Initiator_Information)は本質的に 1 セットのデータのみ表現するため、これらのディクショナリ内のフィールドはグリッドで使用できません。
                          ステップ 2   グリッドとして表示するショナに対し、[グリッドとして表示(Display as Grid )] チェック ボックスを選択します(予約済みディクショナリを除く)。 このオプションがオンになっていると、[グリッドで表示(Show in Grid)] および [使用(Use)] 列に設定されたフィールドのみが列に表示されます。
                          (注)     

                          [グリッドとして表示(Display as Grid)] チェック ボックスは、グリッドとして追加したディクショナリに対してオンの状態で表示され、[フォームコンテンツ(Form Content)] タブで変更することはできません。 グリッド ディクショナリをフォームに追加するときに [グリッドとして表示(Display as Grid)] をオンにするのを忘れた場合には、そのディクショナリを削除し、[ディクショナリ(Dictionary)] ポップアップ ウィンドウで [グリッドとして表示(Display as Grid)] をオンまたはオフにしてもう一度追加できます。

                          ステップ 3   グリッド オプションと表示プロパティを設定します。

                          フォーム ルールを使用した動的なフォーム動作の設定

                          アクティブ フォーム ルールは、[アクティブフォームコンポーネント(Active Form Components)] ページの [アクティブフォームルール(Active Form Rules)] タブで定義されます。 アプリケーションは、次の 2 種類のアクティブ フォーム ルールをサポートしています。

                          • 動的データ取得ルールは、リレーショナル データベースに格納されたデータを取得し、返された値を現在のフォームのフィールドに表示するか、取得した結果に対してフォームのデータを検証します。 方法の理解
                          • 条件付きルールは、一連のアクションを実行するために満たす必要がある条件のセットを指定します。 「条件付き」と呼ばれますが、これらのルールは実際には指定したトリガー イベントが発生するたびに適用されます。

                          大部分のルール定義は「宣言的」に行われます。つまり、ルール ウィザードが一連の手順をガイドすることにより、ルールの定義を支援します。 ほとんどの場合、一連の質問に答えるだけで、コードを記述する必要はありません。 フォームを含むサービスをオーダーすると、ルールが取得され、Web ページのコンテキストで動作するコードが自動的に生成されます。

                          条件付きルールの作成

                          条件付きルールを使用することにより、設計者は、サービス フォームの動作と外観を変更できます。 これらは [アクティブフォームコンポーネント(Active Form Components)] ページの [アクティブフォームルール(Active Form Rules)] タブで定義します。 ルールを作成した後で、これらのルールは実行するこれらのルールのトリガー イベントにアタッチする必要があります。

                          条件付きルールには、次のコンポーネントがあります。

                          • ルール名と説明
                          • ルールによって指定されたアクションを実行すべき条件(無条件を含む)
                          • すべての条件が true の場合に実行されるアクション

                          条件付きルールは、「エンドユーザとの会話」中(つまり、ブラウザ セッション中)、および「会話」の前後(つまり、サーバ側)の両方でロジックを適用する強力なメカニズムです。

                          この手順を使用して、ルールを作成し、ルールを実行するトリガー イベントをアタッチします。

                          はじめる前に


                            ステップ 1   [Service Designer] > [アクティブフォームコンポーネント(Active Form Component)] の順に選択します。
                            ステップ 2   ルールを適用する必要があるアクティブ フォーム コンポーネントを選択し、[アクティブフォームルール(Active Form Rules)] をクリックします。
                            ステップ 3   [新しいルール(New Rule)] > [新しい条件付きルール(New Conditional Rule)] の順に選択します。
                            ステップ 4   [条件付きルール(Conditional Rule)] ウィザードの最初のページ(ステップ 1)で、1 つ以上の条件句を指定することにより、条件を設定します。 各コンポーネント条件は、true または false で評価されます。 複数の条件句は、標準の関係ルールを使用して、組み合わせることができます。 また、条件付きルールを無条件にすることもできます。
                            1. ルール名を入力します。 この名前は、フォーム コンポーネントで一意である必要があります。
                            2. [条件を追加(Add Condition)] をクリックし、条件のタイプを選択します。 選択に応じて、若干異なる [条件ビルダー(Condition Builder)] ダイアログボックスが表示されます。 ディクショナリまたはディクショナリ フィールドを選択すると、フォーム コンポーネントで使用されるディクショナリが最初にリストされ、その次にシステムで使用可能なすべてのディクショナリがリストされます。 詳細については、表 2の表と条件作成のベスト プラクティス/​ガイドラインを参照してください。
                            3. 各条件を定義したら、[OK] をクリックして変更を保存します。

                              必要に応じて、ステートメントの作成を続行する場合は、[条件を追加(Add Condition)] をクリックします。 複数の条件を 1 つのルールに組み合わせる場合は、ブール演算子(または句)を使用してそれらを統合する必要があります。 また、(ボックスをピンクにする)各条件の最初と最後にあるカッコ () をクリックして、条件下で全文の条件ボックスでステートメントを明確に定義できます。

                              (注)      「等しい(is equal to)」演算子が個人タイプとペアになっている場合、値は個人の名前ではなく個人の ID に対応する番号である必要があります。 「is equal to <blank>」を使用して数値およびお金のフィールド タイプにゼロまたはヌル値があるかチェックしないでください。 代わりに「is equal to 0」を使用します。
                            4. すべての条件が追加されたら、[次へ(Next)] をクリックします。
                            ステップ 5   [条件付きルール(Conditional Rule)] ウィザードの 2 ページ目(ステップ 2)で、指定した条件が満たされたときに実行するアクションを追加します。
                            1. [アクションを追加(Add Action)] をクリックし、アクションのタイプを選択します。 アクションの詳細については、表 2の表を参照してください。

                              [条件付きルール(Conditional Rule)] ウィザードの最初のページで設定した条件が満たされないと、アクションは実行されません。 代替アクションを設定するには、別の条件付きルールを作成する必要があります。 日付を表示する任意のフィールドの値を設定する場合、形式は mm/dd/yyyy にする必要があります。 たとえば、10/31/2010 などです。

                            2. アクションを定義した後、[OK] をクリックして変更を保存し、[次へ(Next)] をクリックして次のページに進みます。
                            ステップ 6   [条件付きルール(Conditional Rule)] ウィザードの最後のページ(ステップ 3/3)で、作成した条件付きルールを確認して保存します。 編集が必要な場合は、[前へ(Previous)] をクリックしてウィザードを戻るか、または [保存(Save)] をクリックしてルールを後で編集します。
                            1. このページの [自動関連付け(Automatic Associations)] の部分で、1 つ以上のトリガー イベントにルールをアタッチします。
                                • [フォームのロード前(サーバ側)(Before the form is loaded (server-side))]:このサーバ側ルールは、ブラウザに送信する前にサーバ側で実行されます。
                                • [フォームのロード時(ブラウザ側)(When the form is loaded (browser-side))]:このルールは、このアクティブ フォーム コンポーネントを含む任意のサービスのサービス フォームが最初にブラウザに表示(ロード)されたときに実行されます。
                                • [ルールの条件内で参照されている任意のフィールドの値が変更されたとき(When the value of any field referred to in the rule’s conditions is changed)]:この場合、ルールは、フィールドの HTML 表現に応じて、「フィールドの変更時(When the field is changed)」イベントまたは「フィールドのクリック時(When the field is clicked)」イベントにアタッチされます。
                                • [フォームの送信後(サーバ側)(After the form is submitted (server-side))]:このサーバ側ルールは、ブラウザ上でフォームが送信された後、および処理のためにサーバに送信された後で、サーバ上で実行されます。
                              (注)      フォーム ルールが使用されているときは、常に「フォームの送信後(サーバ側)(After the form is submitted (server-side))」トリガー イベントを使用して、権限付与またはアクセス権限に基づいて厳密に制御する必要があるフォーム フィールドの値を設定します。 値の設定アクションのこのサーバ側での実行によって、悪意のある試行によってサーバに送信される可能性がある未承認データが上書きされます。

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

                            条件付きルールの例

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

                            表 10 条件付きルールの例

                            条件

                            操作

                            データベース ディクショナリ内の [DatabaseType] フィールドの現在値が「その他(Other)」に等しいか。

                            その場合には、同じディクショナリ内の [説明(Description)] フィールドを表示し、ユーザに対して追加情報を入力するように要求します。

                            誰かの代わりにこのサービスをオーダーしているか。

                            その場合、その人(サービスの実際のカスタマー)に関する追加情報を表示します。

                            タスク実行者である現在のユーザは、「金銭のオーダー」タスクに対して作業しているか。

                            その場合には、MemoryDetails ディクショナリを表示し、必要なすべてのフィールドのエントリを作成します。


                            (注)  


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

                            表 11 条件の追加リストにおける条件

                            パラメータ

                            説明/使用方法

                            ディクショナリフィールド(Dictionary Field)

                            サービス フォーム上のディクショナリ内のフィールドの現在値を、リテラル フィールド、別のディクショナリ フィールドの値、または空値つまりヌルと比較します。 使用可能な演算子の詳細については、下記の「演算子」の項を参照してください。

                            ディクショナリ

                            現時点でサービス フォーム内に指定されたディクショナリの使用方法を決定します。 ディクショナリは、表示可能、編集可能、または非表示にできます(以前は、条件付きルールまたは ISF で非表示に設定されていました)。

                            ユーザ名(User Name)

                            現在のユーザに割り当てられたログイン名と指定された値を比較します。

                            ユーザ ロール

                            現在のユーザに、指定されたロールが割り当てられているか、割り当てられていないかを確認します。

                            時点(Moment)

                            要求が、要求ライフ サイクルの特定の時点のものか確認します。 要求は、サービス要求オーダーとも呼ばれます。 要求ライフサイクルの状態およびその値には、要求ライフサイクルの状態を表す値がリストされています。

                            タスク名(Task Name)

                            Service Manager 内の現在のタスク名を、指定されたタスク名と比較します。 タスク名は、すべての承認時点とサービス提供時点に対して設定されます。 タスク名は、タスクが関係しない時点(「オーダー」と「サービス完了」)に対しては空白です。また、現在の要求ステータスに関係なく、サービス フォームが Service Catalog に表示された時点では空白です。

                            コンテキスト

                            サービス フォームが現在表示されているモジュール。 有効な値は次のとおりです。

                            • サービス カタログ(Service Catalog)
                            • Service Manager
                            • My Services

                            サービス名(Service Name)

                            サービスの名前。

                            未送信の要求はありますか(Does unsubmitted requisition exist)

                            サービス要求が保存された後、true を返すブール値。 オーダー時点でサービスが初期的に要求されたときのみ、false を返します。 要求は、「追加」または「送信」された場合に存在します。

                            代理によるオーダーですか(Is Order on Behalf)

                            他のユーザの代わりにサービスがオーダーされた場合は true を返し、要求者が自分のためにサービスをオーダーする場合は false を返すブール値。

                            カスタマーロール(Customer Role)

                            サービスのカスタマーに、指定されたロールが割り当てられているか、割り当てられていないかを確認します。

                            表 12 要求ライフサイクルの状態およびその値

                            サービス要求のライフサイクル ステータス

                            パラメータ値

                            オーダー

                            ordering

                            部門による承認

                            ouauthorizations

                            部門による確認

                            oureviews

                            サービス チームによる承認

                            stauthorizations

                            サービス チームによる確認

                            streviews

                            財務承認

                            financialauthorizations

                            サービス提供

                            servicedelivery

                            条件作成のベスト プラクティス/ガイドライン

                            [コンテキスト(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 つのルールを定義します。

                            表 13 条件とアクション

                            条件

                            アクション

                            ルール 1:DatabaseType_OtherDatabase.DatabaseType が [その他(Other)] と等しい

                            同じディクショナリ内の [説明(Description)] フィールドを表示します。 [説明(Description)] フィールドを必須にします。

                            ルール 2:DatabaseType_DefinedDatabase.DatabaseType が [その他(Other)] と等しくない

                            [説明(Description)] フィールドを非表示にします。 [説明(Description)] フィールドを任意にします。 [説明(Description)] フィールドの値に空白を設定します。

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

                            表 14 条件付きルール アクション

                            操作

                            アクションの説明

                            注記

                            グリッドの使用

                            表示/非表示(Show/Hide)

                            指定されたフィールド、グリッド列、または指定されたディクショナリ内のすべてのフィールドを表示/非表示にします。 要素は、Service Designer に定義されている表現形式に従って表示されます。

                            条件付きルールは、フォーム上の別のフィールドの現在値または指定された他の条件に基づいて、フィールドやディクショナリの表示と非表示を切り替えるために、頻繁に使用されます。 ディクショナリ内のすべてのフィールドではなく、大部分のフィールドを非表示にする必要がある場合には、ディクショナリを非表示にした後、必要なフィールドだけを表示します。 フィールドがルールによって非表示になっていても、その値は、引き続き他の条件付きルールでアクセスできます。

                            列全体に適用

                            値の設定(Set Value)

                            ターゲット フィールドの値を、指定されたソース フィールド、リテラル、ヌル/空白、または式の結果に等しい値に設定します。 フィールド値を設定するときには、フィールドのデータ型と HTML 表現を考慮する必要があります。

                            値にリテラルまたは式の結果が設定されている場合、そのリテラルまたは式には、現在のサービスで使用される任意の数の数字フィールドまたはテキスト フィールドを含めることができます。 (日付算術演算はサポートされません)。フィールドは、Lightweight 名前空間構文を使用する式(#DictionaryName.FieldName #)で表現されます。 式が無効(たとえば、ゼロ除算を含む)な場合、その式は処理対象から除外されます。値は更新されません。また、同じイベントに対して残りのアクションまたはルールが存在する場合、それらが引き続き実行されます。 ユーザには、エラー メッセージが表示されません。

                            フィールドの [サーバ側でのみ編集可能(Editable only on server-side)] 設定は、値の設定の動作にも影響を及ぼします。 [サーバ側でのみ編集可能(Editable only on server-side)] とマーク付けされたフィールドは、ブラウザ セッション中に値を傍受しようとしても、できないように保護されます。 自動取得に対応している個人ベースのディクショナリとサービス項目ベースのディクショナリの場合、[サーバ側でのみ編集可能(Editable only on server-side)] 設定が有効な場合には、データベースから取得される属性値が、ブラウザから送信される値よりも常に優先されます。 その理由から、このようなフィールドに適用するすべての値の設定アクションは、送信後イベントに関連付けられたルール内に存在する必要があります。言いかえれば、[値の設定(Set Value)] を使用してフィールドを編集できますが、それはサーバ側イベントに限定されます。

                            現在使用不可、代わりに ISF を使用

                            価格の設定(Set Price)

                            サービス価格、またはバンドル内の指定された子サービスの価格を、指定されたソース フィールド、リテラル、または式の結果と同じ値に設定します。

                            [価格の設定(Set Price)] アクションは、サービスの動的な価格設定をサポートします。 価格には、[価格の設定(Set Price)] アクションの場合と同じルールを使用して、定数、別のフィールドの値、または式の計算結果を設定できます。 [価格の設定(Set Price)] アクションは、任意のイベントによってトリガーされるルールに含めることができますが、新しい価格は、サービス フォームが送信されたときにのみ実際に効力を持ちます。トランザクションがキャンセルされると、新しい価格は記録されません。 新しい価格は、フォームが送信されたときにのみ実際に効力を持つため、価格の設定を含むルールの実行のために選択する必要のある最も適切なイベントは、送信後イベントです。 [価格の設定(Set Price)] アクションは、要求のシステム履歴に記録されます。

                            未サポート

                            必須にする(Make Mandatory)

                            指定されたフィールドを必須にします。 フィールドを必須にすることは、Service Designer を使用してフィールドを必須に指定するのと同じ効果があります。

                            • 必須であることを表す記号が、フィールド ラベルの左に表示されます。
                            • フォームを正しく送信するためには、ユーザが値を入力する必要があります。
                            • 管理設定にフォーム モニタが含まれる場合には、値が指定されるまで、モニタはディクショナリを不完全なものとして表示します。

                            フィールド(またはディクショナリ)を非表示に設定している場合、必須に設定されたフィールドがディクショナリ内に存在しないことを確認する必要があります。必須フィールドが存在する場合には、ユーザがフォームを送信しようとすると、エラー メッセージが表示されます。 ルール(または ISF)を使用して、フィールドの必須と任意を切り替える場合、フィールドの HTML 表現を使用してフィールドを任意に設定する必要があります。 HTML 表現ですでに必須としてマークされているフィールドを、条件付きルールを使用して上書きすると、予期しない動作が発生する場合があります。

                            必須フィールドが読み取り/書き込みモードの間で切り替えられる場合は、読み取り専用に設定されるときにそのフィールドを任意に設定するか、または無効にすることにより、ユーザの混乱を防止する必要があります。

                            未サポート

                            任意にする(Make Optional)

                            指定されたフィールドを任意にします。

                            未サポート

                            読み取り専用にする(Make Read-Only)

                            指定されたフィールド、グリッド列、または指定されたディクショナリ内のすべてのフィールドを読み取り専用にします。ユーザは、このフィールドまたは列を変更できませんが、ルールまたは ISF を使用して値を変更できます。

                            グリッドの場合、「読み取り専用にする」と「無効」の間に違いはありません。

                            列全体に適用

                            書き込み可能にする(Make Writable)

                            指定されたフィールド、グリッド列、または指定されたディクショナリ内のすべてのフィールドを書き込み可能にします。

                            このアクションは、「有効」と同じです。

                            列全体に適用

                            有効(Enable)

                            指定されたフィールド、グリッド列、または指定されたディクショナリ内のすべてのフィールドを書き込み可能にします。

                            このアクションは、「書き込み可能にする」と同じです。

                            列全体に適用

                            無効(Disable)

                            指定されたフィールド、グリッド列、または指定されたディクショナリ内のすべてのフィールドを無効にします。 フィールドまたは列を無効にすると、読み取り専用にするアクションと同様に読み取り専用になります。しかし、読み取り専用にするとは異なり、フィールドまたは列がグレー表示になり、条件付きルールまたは ISF からフィールドに適用されるすべての変更が無視されます。

                            グリッドの場合、「無効」と「読み取り専用にする」の間に違いはありません。

                            列全体に適用

                            フォーカスを設定(Set Focus)

                            カーソルを、指定されたフィールドに移動します。 これは、一般に、アラート後、またはフォームの送信が停止した後に、問題のあるフィールドにユーザの注意を向けさせるために使用されます。

                            [フォーカスを設定(Set Focus)] は、グリッド ディクショナリ直後のフラットなディクショナリでは機能しません。 フラットなディクショナリにフォーカスを設定するには、次のパターンに従います。

                            • グリッド ディクショナリに入力します。
                            • フラット ディクショナリの任意のフィールドをクリックします。
                            • 最初のクリックではフォーカスは設定されません。
                            • フラット ディクショナリのそのフィールドでフォーカスを設定するにはもう一度クリックする必要があります。

                            現在使用不可、代わりに ISF を使用

                            アラート(Alert)

                            指定されたメッセージのアラート ボックスを表示します。リテラル メッセージのみ使用できます。名前空間はサポートされていません。 このアクションは、一般にサーバ側のイベントには適用できません。

                            サーバ側では、送信後イベント内で [送信の停止(Stop Submission)] アクションと組み合わせる場合のみ、アラートの使用が有効になります。

                            該当なし

                            送信の停止(Stop Submission)

                            フォームの送信と更新を許可しません。 トリガー イベントでフォームが送信されるような条件でのみ使用する必要があります。

                            ブラウザ側でアクションが実行される場合、そのアクションの順序に関係なく、ルール内の他のアクションの実行は停止されません。 サーバ側でアクションが実行される場合、それ以降のすべてのアクションとルールは無視され、エンド ユーザにエラー メッセージが表示されます。 オプションとして、送信の停止アクションの前にアラート アクションを定義することにより、適切なエラー メッセージを表示することもできます。 アラート メッセージが定義されていない場合、要求を送信できないことを示すために、汎用的なエラー メッセージが表示されます。

                            該当なし

                            グリッド ディクショナリの条件付きルールと ISF

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

                            グリッドに適用される条件付きルール

                            グリッド ディクショナリとそのフィールドは、ルールのトリガー条件としては選択できません。条件付きルール アクションのターゲットとしてのみ選択できます。 非グリッド ディクショナリ内の個々のフィールドに適用される、以下の条件付きルール アクションは、グリッド内の列全体に適用されます。 その他のすべての条件付きルール アクションは、グリッドの列またはセルではサポートされません。

                            • フィールドの表示(Show Fields)
                            • フィールドの非表示(Hide Fields)
                            • 読み取り専用にする(Make Read-Only)
                            • 書き込み可能にする(Make Writeable)
                            • 有効(Enable)
                            • 無効(Disable)

                            グリッドの場合、[読み取り専用にする(Make Read-Only)] アクションと [無効(Disable)] アクションの間には、目立った差はありません(非グリッド フィールドでは、ユーザ インターフェイスの効果に多少の違いがみられます)。 同じことが、[書き込み可能にする(Make Writable)] アクションと [有効(Enable)] アクションにも当てはまります。

                            グリッド内の ISF

                            JavaScript 関数は、グリッド ディクショナリ内のフィールド レベル イベントに割り当てることはできません。 次の表に示すように、既存の ISF フレームワークは、グリッド ディクショナリおよびフィールドをサポートするように拡張されています。

                            表 15 ディクショナリ レベル関数

                            機能

                            グリッド内の用途

                            serviceForm.dictionaryName.setVisible (Boolean)

                            グリッドを表示、非表示にします。 Service Designer を通して非表示にされるディクショナリには効果がありません。

                            serviceForm.dictionaryName.isVisible()

                            グリッドが表示される場合には true を返し、表示されない場合は false を返します。

                            serviceForm.dictionaryName.getCaption(Boolean stripTags)

                            グリッドのタイトル テキストを取得します。オプションで、すべての HTML を外します。

                            serviceForm.dictionaryName.setCaption(String newCaption)

                            グリッドのタイトル テキストを設定します。

                            serviceForm.dictionaryName.setReadOnly (Boolean)

                            ディクショナリ内のすべてのカラムを読み取り専用または読み取り/書き込みに設定します。Service Designer でそのカラムがすでに読み取り専用に設定されている場合には、効果がありません。

                            serviceForm.dictionaryName.isReadOnly()

                            ディクショナリが読み取り専用の場合には true を返します。

                            serviceForm.dictionaryName.getGridSize()

                            グリッド内の行数を返します。

                            表 16 フィールド レベル(グリッドのカラム レベル)関数

                            機能

                            グリッド内の用途

                            serviceForm.dictionaryName.fieldName setReadOnly (Boolean)

                            カラムを読み取り専用または読み取り/書き込みに設定します。

                            serviceForm.dictionaryName.fieldName.isReadOnly()

                            カラムが読み取り専用の場合には true を返し、その他の場合には false を返します。

                            serviceForm.dictionaryName.fieldName.setVisible(Boolean)

                            カラムを非表示または表示可能(表示される)にします。 カラムが、Service Designer の設定を通して非表示になっている場合には、表示可能にできません。

                            serviceForm.dictionaryName.fieldName.isVisible()

                            カラムが表示可能な場合には true を返し、その他の場合には false を返します。

                            serviceForm.dictionaryName.fieldName getInstructionalText(stripTags)

                            カラムの指示テキストを返します。オプションで、Boolean stripTags 引数に基づいて、テキストからすべての HTML を削除します。

                            serviceForm.dictionaryName.fieldName.setInstructionalText(text)

                            カラムの指示テキストを設定します。

                            serviceForm.dictionaryName.fieldName.getPrompt(stripTags)

                            列ヘッダーを返します。オプションで、Boolean stripTags 引数に基づいて、プロンプトからすべての HTML を削除します。

                            serviceForm.dictionaryName.fieldName.setPrompt(prompt)

                            列ヘッダーを設定します。

                            動的データ取得ルールの作成

                            動的データ取得ルールは、リレーショナル データベースに格納されたデータを取得し、返された値を現在のフォームのフィールドに表示するか、それらの値に対してフォームのデータを検証します。 この取得はソース データベースに対して SQL クエリーを実行することによって行われ、指定した列の値がサービス フォームに返されます。


                            (注)  


                            サービスが Web サービスを通じてオーダーされた場合は、サーバ側のルールだけが実行されます。 データ取得ルールによってデータが読み込まれるオプションがある選択されたフィールドがある場合、Web サービス要求で渡された値が検証のためのオプションのリストを確実に持てるように、ルールは送信後にトリガーされる必要があります。
                            データ取得ルール作成の前提条件
                            • データソースの定義:Service Catalog がデータベースにアクセスするには、対応するデータソースを定義する必要があります。 データソースはデータベースを識別し、有効なユーザ名とパスワードを含む、データベースに接続するための情報を提供します。 アプリケーションには、REQUESTCENTERDS という名前の事前設定されたデータソースが 1 つ付随しており、これにより Service Catalog データにアクセスできます。 システム管理者とともにデータベース管理者は、会社固有のデータを含む追加のデータソースを定義し、Service Catalog がインストールされているアプリケーション サーバに定義を公開する必要があります。 データソースの設定とインストールの詳細な手順は、『Cisco Prime Service Catalog Installation and Upgrade Guide』に記載されています。 標準とサービス項目をデータ取得ルールのデータのソースとして使用できます。 しかし、その用途は、クエリのタイプが「データベース テーブル」のルールに制限されます。SQL を使用するルールでは使用できません。

                            データベース テーブル検索を定義する場合は、データソースのリストに標準(とサービス項目)だけでなく、トランザクション データベースおよびデータ マート データベースを含めます。 [標準(Standards)] を選択すると、クエリのテーブル名として選択できる使用可能な標準テーブルが表示されます。 データ取得ルールを構成する他のすべての側面は、この項で前に説明した内容と同じです。

                            • ソース デー識別:取得する必要のあるデータと、データが保存されるテーブルの構造を理解する必要があります。 この情報は、ソース システムに精通した IT 専門家が提供します。
                              • 取得する必要があるデータがすべて単一のテーブルにある場合、テーブルの名前と取得する列を単に指定できます。 Service Catalog は、テーブルのすべての列を取得する SQL クエリーを自動的に作成します。
                              • 複数のテーブルからデータを取得する必要がある場合、またはサービス フォーム上で使用するために値を操作(値の連結や計算の実行など)する必要がある場合は、SQL クエリーを自分で記述し、テストする必要があります。 この作業には、ソース システムの知識を持ち、SQL の開発ツールを使用できる、データベースまたは IT 専門家が必要不可欠です。 クエリのテストが終わったら、ここに概要を示す細かい変更を行い、[自分のSQLクエリーを入力する(Enter Your Own SQL Query)] クエリ タイプを使用して [動的データ取得ルール(Dynamic Data Retrieval Rule)] ウィザードにカット アンド ペーストできます。

                            動的データ収集ルールを定義するには、次の手順を使用します。

                            はじめる前に


                              ステップ 1   [Service Designer] > [アクティブフォームコンポーネント(Active Form Components)] の順に選択し、ルールを適用するアクティブ フォーム コンポーネントを選択します。
                              ステップ 2   [アクティブフォームルール(Active Form Rules)] タブをクリックし、[新しいルール(New Rule)] > [新しいデータ取得ルール(New Data Retrieval Rule)] の順に選択します。
                              ステップ 3   [データ取得ルール(Data Retrieval Rule)] ウィザードの最初のページで、ルールの一意の名前と説明を入力し、[ルールタイプ(Rule Type)] と [クエリーのタイプ(Query Type)] を指定します。
                              1. ルール タイプを指定します。
                                  • [配布ルール(Distributing Rule)]:クエリの結果をフォームに返すことが主な目的の場合は、このオプションを選択します。たとえば、選択リスト、選択やデータ入力により別のフィールドにトリガーするフィールドのセット、またはグリッドの場合があります。 このタイプのルールは、任意の数のフォーム レベル イベントおよびフィールド レベル イベントにアタッチできます。
                                  • [検証ルール(Validating Rule)]:主な目的が、フォームに入力されたデータをクエリによって返された一連の結果と照合して検証し、セキュリティなどの特定の基準に準拠していることを確認することである場合は、このオプションを選択します。 したがって、このルールは、悪意あるユーザによるフォームの傍受およびコンテンツの操作を防ぐ目的で使用できます。
                                (注)      このルールは、送信後イベント(サーバ側)でのみ実行できます。ルールを他のイベントにアタッチすることはできません。
                                  • [送信後イベントで実行される暗黙的検証を伴う配布ルール(Distributing Rule with implicit validation performed on the post-Submit event)]:このオプションは、新しいルールの作成時にデフォルトでオンになっています。 フォームにクエリの結果を返すことが主な目的である場合はこのオプションを選択しますが、さらに送信後イベントでフォーム データを検証する必要があります。 このルールは、任意の数のフォーム レベル イベントおよびフィールド レベル イベントにアタッチできます。また、このルールと「同等の検証」が、送信後イベントに自動的にアタッチされます。 たとえば、ドロップダウン コントロールに値としてサーバ プロビジョニング ロケーションのリストを入力するときに、ロケーションがフォーム ユーザのロールによって制限されている場合には、[暗黙的検証を伴う配布(Distributing with implicit validation)] オプションを使用すると、ルールによって「Seattle」がロールの有効な選択肢から除外されている場合は、悪意のあるユーザが「Seattle」を指定できなくなります。
                              2. クエリ タイプを指定します。
                                • [データベーステーブルルックアップ(Database Table Lookup)]:[データベーステーブルルックアップ(Database Table Lookup)] は、単純または簡単なオプションです。 対象となるデータがすべて 1 つのテーブル(またはデータベース管理者が作成したデータベース ビュー)内に存在する場合、このタイプを使用します。 画面のセット全体を通して、ウィザードのガイドに従ってダイアログボックスに入力することにより、クエリを定義できます。 データ ソースと、データが属するテーブルを指定します。 データソースを指定すると、[テーブル名(Table Name)] ドロップダウンリストに、そのデータ ソースにアクセス可能なすべてのテーブルが表示されます。
                                  • [REQUESTCENTERDS]:Service Catalog データベースにテーブルが含まれます。

                                  • [DATAMARTDS]:データ マート データベースにテーブルが含まれます。

                                  • [標準(Standards)]:Service Item Manager の [標準の設計(Design Standards)] タブを使用して作成したテーブル、または Service Item Manager の [データのインポート(Import Data)] タブを使用してインポートしたテーブルが含まれます。

                                  • [サービス項目(Service Items)]:仮想マシンのサービス項目、ServiceItemHistory および ServiceItemSubscription テーブル、および [サービス項目(Service Item)] で定義されたサービス項目が含まれます。

                                • [自分のSQLクエリーを入力する(Enter Your Own SQL Query)]:より複雑なクエリの場合はこのクエリ タイプを使用します。 このクエリ タイプを選択する場合は、情報の取得元のデータ ソースを指定して、実行する完全な SQL SELECT ステートメントを書き込む必要があります。 フォーム上でフィールドの値を参照するには、クエリに、そのフィールドを参照する Lightweight 名前空間を含める必要があります。

                              For example: select distinct CMN_NAME from ASSET_TRACKING where MODEL = #ST_HARDWAREKIT.ComputerName#
                              (注)     
                              • 実行時にパーサーにより、名前空間に返される値の前後に、自動的に一重引用符が挿入されます。 これは「datetime」を除くすべてのデータ型についても当てはまります。datetime データ型の値は、RDBMS によって要求される日時形式と正確に一致させる必要があります。 各 RDBMS は、日時形式の設定が異なっている可能性があります。

                              • [データベーステーブルルックアップ(Database Table Lookup)] を選択した場合、生成された SQL クエリーは、[SQLクエリー(SQL Query)] フィールドのウィザードの最後に表示されます(フィールド名は保存時に生成された SQL クエリーに変わります)。 これは、2 番目のタイプを介して、独自の SQL クエリーを作成できる開始ポイントとなります。(つまり、生成された SQL クエリーをコピーし、次にウィザードのステップ 1 に戻り、[自分のSQLクエリーを入力する(Enter Your Own SQL Query)] を選択して、生成された SQL クエリーを [SQLステートメント(SQL Statement)] フィールドに貼り付けることができます)。

                              • REST Web サービス:REST Web サービスの動的データ取得ルールを使用して、サービス フォーム上のデータを外部システムから取得することができます。 クエリ タイプを [REST Webサービス(REST Web service)] に選択する場合は、次の項目を指定する必要があります。
                                • REST URL:GET および POST 操作を使用して情報へのアクセスを開始する Web リソースの URL を指定します。

                                • REST メソッド:Web リソースへのアクセスには GET または POST メソッドを使用します。 POST メソッドを使用する場合は、正しくフォーマットされた xml レイアウト形式の詳細情報またはペイロードを指定します。

                                • ユーザ名とパスワード:要求を行う際に Web リソースにアクセスするための基本認証。

                                • 認証タイプ:基本のユーザ名およびパスワード ベースの認証メカニズムに加えて、セッション ベースまたはヘッダー ベースの認証を使用して、Web リソースにアクセスできます。 セッション ベースの名前およびパスワードの認証には、認証された HTTP 要求の追加の認証トークン パラメータが含まれます。

                              ステップ 4   [Next] をクリックします。

                              ルール タイプに [配布ルール(Distributing Rule)] または [送信後イベントで実行される暗黙的検証を伴う配布ルール(Distributing Rule with implicit validation performed on the post-Submit event)] を指定した場合、1 つ以上のトリガー イベントを選択する必要があります。

                              (注)     

                              権限付与またはアクセス権限に基づいて厳密に制御する必要があるフォーム フィールドに対しては、ルール タイプは常に [暗黙的検証を伴う配布ルール(Distributing Rule with implicit validation)] を使用します。 暗黙的検証によって、悪意のある試行によってフィールド値が操作されたり、未承認データがサーバに渡されることを防ぎます。 暗黙的検証を 10 進数の数値フィールドに適用する場合は、クエリによって返される 10 進数の数がユーザ入力と一致するようなクエリを構築する必要があります。 そうしないと、小数点以下の桁数が異なるだけの理由で検証が失敗する可能性があります。

                              ステップ 5   [トリガーイベント(Triggering Event(s))] を選択し、[次へ(Next)] をクリックします。 ルールは、次のイベントのチェック ボックスをオンにすることで実行(トリガー)できます。 [トリガーイベントの選択(Select Triggering Events)] ページのフィールドの表を参照してください。
                              (注)      グリッド フィールドは、データ取得ルールの作成時に、「トリガー フィールド」として選択できません。
                              ステップ 6   検索条件(Where 句)を定義し、[次へ(Next)] をクリックします。
                                • 配布ルールまたは「送信後イベントで実行される暗黙的検証を伴う配布ルール」の場合:取得タイプが [データベーステーブルルックアップ(Database Table Lookup)] のルールには通常、指定したテーブルから取得する行(複数可)を指定する条件の一部として「Where」句が関連付けられている必要があります。 [Where句の追加(Add Where Clause)] をクリックして、任意の数の条件を入力できます。 入力するごとに、[OK] をクリックします。 ここで指定した条件は、ページの最上部に表示されます。 複数の条件を使用する場合は、すべての条件が返される行に対して true である必要があります(つまり、条件はブール演算子 AND を使用して一つにグループ化されます)。
                                • 検索条件を指定しない場合、指定したテーブル内のすべての行が返されます。 これは、一般に、ドロップダウンリスト(単一選択または複数選択)に値を入れるときに発生します。 このようなルールをフォームのロード イベントにアタッチするよりも、フィールドの表示プロパティの一部として、単にテーブル ベースのオプション リストを定義する方が簡単かつ効率的です。
                              (注)      グリッド ディクショナリは、検索条件の作成には使用できません。
                              ステップ 7   ソート条件を定義し、[次へ(Next)] をクリックします。

                              ルールが複数の行に返されるようにする場合は、返される行をソートできます。 たとえば、ドロップダウンリストにデータを投入するために使用されるデータを取得するルールを使用する場合、その結果は通常ソートされる必要があるので、適切な順番になっています。 任意の数のソート フィールド(テーブルの列名)と、それぞれのフィールドに指定するソートの方向(昇順または降順)を指定できます。 新しいソート フィールドを追加するには、[ソートの追加(Add Sort)] をクリックします。 入力したら、[OK] をクリックすると、ページの最上部に表示される [ソート条件(Sort Conditions)] に新しいフィールドが追加されます。

                              ステップ 8   フォームで検索結果を使用します。

                              配布ルールまたは「送信後イベントで実行される暗黙的検証を伴う配布ルール」では、配布ターゲットを少なくとも 1 つ定義する必要があります。 「配布」は、テーブル ベースの検索と SQL クエリーの両方から返される値をフォームでどのように使用するかを定義します。 配布では、クエリ内で返された列値が、サービスのフィールドにマッピングされます。 各ルールには、1 つ以上の配布を含めることができます。

                              REST Web サービスの場合、サービスは XML または JSON の応答を返すので、値がディクショナリ フィールドにマッピングされる JSON パスまたは XPATH を指定します。

                              たとえば、ドロップダウン リストの値の設定に使用するルールには、1 つの配布のみ使用します(列を、単一選択または複数選択要素の HTML 表現を持つディクショナリにマッピング)。 また、ルールで、それぞれ 1 つの列を 1 つのディクショナリ フィールドにマッピングする複数の配布を使用する場合があります。 ターゲット ディクショナリ フィールドは、フォーム上で書き込み可能である必要はありません。読み取り専用または非表示にすることができます。 [配布の追加(Add Distribution)] をクリックして、任意の数の配布を入力できます。 入力するごとに、[OK] をクリックします。

                              ルールは、結果をグリッド ディクショナリと非グリッド ディクショナリの組み合わせに配布すること、また 2 つの異なるグリッド ディクショナリに配布することはできません。 1 つのグリッド ディクショナリ フィールドを配布ターゲットとして選択すると、すべての追加ターゲットは、同じディクショナリ内のフィールドに限定されます。

                              配布のターゲットは、現在のフォーム コンポーネントに含まれていないディクショナリ上のフィールドにできます。 参照されるディクショナリが別のフォーム コンポーネントに含まれること、次にそれが現在のフォーム コンポーネントを持つサービス内に含まれることを保証するのは、サービス設計者の責任です。

                              ステップ 9   [Next] をクリックします。
                              ステップ 10   フィールド値を検証し、[次へ(Next)] をクリックします。

                              ルール タイプを [検証ルール(Validating Rule)] に指定する場合、検証する 1 つ以上のフィールドを選択する必要があります。

                              この手順を使用して、クエリによって返される列、つまりクエリ結果に対して検証されるフィールドを選択します。 ここで指定する各フィールドの値は、フォームの送信後に対応するクエリ結果と照合して検証されます。フィールドの値が結果のいずれとも一致しない場合、送信は失敗し、エンド ユーザは、その旨のメッセージを受信します。 [検証の追加(Add Validation)] をクリックして、任意の数の検証を入力できます。 入力するごとに、[OK] をクリックします。

                              ルールは、グリッド ディクショナリと非グリッド ディクショナリの組み合わせに対して検証すること、また 2 つの異なるグリッド ディクショナリに対して検証することはできません。 1 つのグリッド ディクショナリ フィールドを検証として選択すると、すべての追加検証は、同じディクショナリ内のフィールドに限定されます。

                              検証フィールドは、現在のフォーム コンポーネントに含まれていないディクショナリ上のフィールドにすることができます。 参照されるディクショナリが別のフォーム コンポーネントに含まれること、次にそれが現在のフォーム コンポーネントを持つサービス内に含まれることを保証するのは、サービス設計者の責任です。

                              ステップ 11   確認と保存

                              ウィザードの最後のページに、ルール定義が表示されます。 [保存(Save)] をクリックするとルールが保存され、[キャンセル(Cancel)] をクリックするとルール(またはウィザードのこのセクションで行った変更)が廃棄され、または [前へ(Previous)] をクリックするとウィザードの前のページに戻ります。 また、[アクティブフォームルール(Active Form Rules)] ページでルールを選択することによっても、ルール定義が表示されます。


                              [トリガーイベントの選択(Select Triggering Events)] ページのフィールド
                              表 17 [トリガーイベントの選択(Select Triggering Events)] ページのフィールド

                              フィールド

                              説明

                              フォームのロード(Form Load)

                              My Services または Service Manager にサービス フォームが初期表示される場合。

                              フォームのロード前(サーバ側)(Before the form is loaded (server-side))

                              このサーバ側ルールは、ブラウザに送信する前にサーバ側で実行されます。

                              フォームの送信後(サーバ側)(After the form is submitted (server-side))

                              配布ルールの選択肢でのみ使用可能。このサーバ側ルールは、フォームがブラウザに送信され、処理のためにサーバに送信された後に実行されます。

                              ディクショナリフィールドアクション(Dictionary Field Action)

                              フォームでのユーザの作業に伴って発生するイベントに対応して、データを入力するとともに、フィールド間を移動します。

                              ディクショナリ名(Dictionary Name)、ディクショナリフィールド名(Dictionary Field Name)、およびイベント(Event)

                              イベントを「ディクショナリ フィールド アクション」として指定する場合、ドロップダウン メニューから [ディクショナリ名(Dictionary Name)]、[ディクショナリフィールド名(Dictionary Field Name)]、および [イベント(Event)] を選択することにより、そのアクションを定義する必要があります。 「トリガー」イベントは、Web ページ設計者が精通しているイベントに類似していますが、まったく同じではありません。 使用可能なイベントのリストは、フィールドに割り当てられた入力タイプに応じて変わる場合あります。 たとえば、オプション ボタンには「項目のクリック時」イベントがあり、これはテキスト フィールドには適用できません。

                              データ取得ルールのタイプを選択する前のパフォーマンスに関する考慮事項

                              サーバ上でのクエリの実行はブラウザによって呼び出されるクエリよりも速いですが、ロード前イベントではなくロード中イベントでデータ取得ルールを実行することを推奨します。 ロード中イベントよりもロード前イベントを実行する場合は、次のことを考慮してください。

                              • サーバ側で何かを実行する場合(ロード前イベント)はアプリケーション サーバのサイクルが使用されますが、 ユーザのブラウザ セッションに制限されます。
                              • 多数のレコードを返すルールの実行は、サーバ側のイベント中に実行された場合は全体的なソリューション パフォーマンスに影響します。 アプリケーション サーバで実行するそのようなルールは、すべてのユーザに対するソリューションの全体的なパフォーマンスに影響を与える可能性があります。 したがって、多すぎる結果を返すことを避けるために、クエリをできるだけ改良します。 これは、最高のエンドユーザ エクスペリエンスとパフォーマンスにつながります。
                              • もう 1 つの要因として、フォームのエンドユーザが認識するパフォーマンスがあります。 数十個または数百個のフィールドを持つ複雑なサービス フォームをブラウザ ウィンドウに完全にロードするには、多少の時間がかかります。 そのフォームにロード中イベントでドロップダウンを入力するデータ取得ルールも含まれている場合、一般にフォームが最初に描写され、それに続いてドロップダウンに値が入力されます。 ドロップダウンの描写と値の入力の間、フォーム上に「空」に見えるドロップダウン コントロールが表示される場合があります。 この効果は、ドロップダウンに入力するルールをロード前イベントに関連付けることによって軽減できます。 しかし、データ取得ルールをロード前イベントに移動することは、ルールの実行が終了するまで、フォームがロードされないことを意味しています。したがって、ユーザは、フォームがブラウザにロードされるのを見ることはありません。 そのため、フォームを完全にロードするパフォーマンス全体は向上する場合がありますが、ユーザは、[オーダー(Order)] ボタンをクリックした際のアプリケーションの応答が遅いと感じる可能性があります。

                              一連のルールをロード中イベントに結び付けることで応答を比較し、続いてルールをロード前イベントに結び付けるように変更することができます。 アプリケーションがロード中にこの比較を行うと、効果がよりはっきりと表示されるため、最も適切なアプローチを選択できます。

                              アクティブ フォーム ルールの変更

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

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

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

                              サービス フォームへのフォーム ルールの追加

                              [アクティブフォームの動作(Active Form Behavior)] タブを使用して、設計者はサービス フォームのライフ サイクル内で発生するイベントに JavaScript 関数と条件付きルールをアタッチすることができます。 このタブで、条件付きルールの順序を変更できます。 JavaScript は常に最後に実行されます。


                                ステップ 1   [Service Designer] > [アクティブフォームコンポーネント(Active Form Component)] の順に選択します。
                                ステップ 2   [アクティブフォームの動作(Active Form Behavior)] タブをクリックします。 [フォームまたはフィールド(Form or Field)] 列の最初の行 [アクティブフォームコンポーネント(Active Form Component)] がデフォルトで選択されています。 [トリガーイベント(Triggering Event)] 列に、すべてのフォーム レベル イベントが一覧表示されます。
                                ステップ 3   [トリガーイベント(Triggering Event)] 列で、使用可能なリストから JavaScript または条件付きルールをアタッチするフォーム レベル トリガー イベントを選択します。
                                (注)      サーバ側のフォーム レベル トリガー ルールを選択することを推奨します。これらは、セキュアで傍受攻撃の影響を受けにくいためです。
                                • [フォームのロード前(サーバ側)(Before the form is loaded (server-side))]:このサーバ側ルールは、ブラウザに送信する前にサーバ側で実行されます。 詳細については、外部システムでのサービス項目の管理を参照してください。
                                • [フォームの送信後(サーバ側)(After the form is submitted (server-side))]:このサーバ側ルールは、ブラウザ上でフォームが送信された後、および処理のためにサーバに送信された後で、サーバ上で実行されます。 詳細については、外部システムでのサービス項目の管理を参照してください。
                                • [フォームの送信時(ブラウザ側)(When the form is submitted (browser-side))]:コードまたはルールは、[送信(Submit)] ボタンまたは [更新(Update)] ボタンをクリックした後、およびフォームの [表示(Display)] で指定された検証(数値データや必須データの確認など)の後で、フォームがサーバに送信される前に実行されます。
                                • [フォームのロード時(ブラウザ側)(When the form is loaded (browser-side))]:コードまたはルールは、サービス フォームが最初に Service Catalog、Service Manager、または My Services に表示されたときに実行されます。
                                • [フォームのアンロード時(ブラウザ側)(When the form is unloaded (browser-side))]:コードまたはルールは、サービス フォームがクローズされたときに実行されます。
                                (注)      JavaScript 関数は、サーバ側トリガーにアタッチすることはできません。
                                ステップ 4   [JavaScriptの追加(Add JavaScript)] または [ルールの追加(Add Rules)] をクリックします。 ダイアログボックスに、以前に定義されたすべてのスクリプトまたはルールが一覧表示されます。
                                ステップ 5   以前に定義された関数または条件付きルールの横にあるチェックボックスをオンにして選択し、[追加(Add)] をクリックします。 必要に応じて検索ボックスを使用できます。

                                [動作(Behavior)] 列で、関数は [JavaScripts] セクションの下に表示され、ルールは [ルール(Rules)] セクションの下に表示されます。 ルールが実行される順序を確認し、必要に応じて順序を変更します。

                                (注)      単一フォーム内の同じイベントに複数の JavaScript 関数をアタッチできますが、関数を指定(および実行)する順序を定義できないため、これは最も回避すべき方法です。 したがって、特定の順序で関数を実行する必要がある場合には、目的とする順序ですべての関数を含む JavaScript 関数を作成します。
                                ステップ 6   必要に応じて、[動作(Behavior)] 列で JavaScript 関数をクリックし、次に [引数の編集(Edit Arguments)] をクリックすることにより、JavaScript 関数の引数を編集できます。

                                サービス フォーム フィールドへのフォーム ルールの追加

                                  ステップ 1   [Service Designer] > [アクティブフォームコンポーネント(Active Form Component)] の順に選択します。
                                  ステップ 2   [アクティブフォームの動作(Active Form Behavior)] タブをクリックします。
                                  ステップ 3   [フォームまたはフィールド(Form or Field)] 列でフィールドをクリックします。 [トリガーイベント(Triggering Event)] 列に、すべてのフィールド レベル イベントが一覧表示されます。
                                  ステップ 4   [トリガーイベント(Triggering Event)] 列で、使用可能なリストから JavaScript または条件付きルールをアタッチするフィールド レベル トリガー イベントを選択します。
                                  • [項目の変更時(When the item is changed)]:ユーザは指定されたフォーム フィールドに情報を入力します。
                                  • [項目のフォーカスの喪失時(When the item loses focus)]:ユーザは、別のフィールドに切り替えるか、または別のフィールドでマウスをクリックすることで、指定されたフォーム フィールドを終了します。
                                  • [項目のクリック時(When the item is clicked)]:ユーザは、チェック ボックス、オプション ボタン、またはドロップダウンリストの項目をクリックします。
                                  • [項目のフォーカス時(When the item is focused on)]:ユーザは、指定されたフィールドでクリックします。
                                  • [項目からマウスを移動時(When the mouse is moved off the item)]:ユーザは、指定されたフィールドからマウスを移動します。
                                  • [項目にマウスを移動時(When the mouse is moved on the item)]:ユーザは、指定されたフィールドにマウスを移動します。
                                  ステップ 5   [JavaScriptの追加(Add JavaScript)] または [ルールの追加(Add Rules)] をクリックします。
                                  ステップ 6   以前に定義された関数または条件付きルールの横にあるチェック ボックスをオンにして選択し、[追加(Add)] をクリックします。 必要に応じて検索ボックスを使用できます。

                                  [動作(Behavior)] 列で、関数は [JavaScripts] セクションの下に表示され、ルールは [ルール(Rules)] セクションの下に表示されます。

                                  ステップ 7   ルールが実行される順序を確認し、必要に応じて順序を変更します。 必要に応じて、[動作(Behavior)] 列で JavaScript 関数をクリックし、次に [引数の編集(Edit Arguments)] をクリックすることにより、JavaScript 関数の引数を編集できます。


                                  (注)  


                                  単一フォーム内の同じイベントに複数の JavaScript 関数をアタッチできますが、関数を指定(および実行)する順序を定義できないため、これは最も回避すべき方法です。 したがって、特定の順序で関数を実行する必要がある場合には、目的とする順序ですべての関数を含む JavaScript 関数を作成します。

                                  サービス項目ベースのディクショナリのフォーム動作の定義

                                  サービス項目ベースのディクショナリ(SIBD)のフォーム ルールおよび他のフォームの動作は、自由形式のディクショナリとほぼ同様に機能します。 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   [ルール(Rule)] ウィザードの 2 ページ目が表示されます。 データソースとして [サービス項目(Service Items)] を選択できます。

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

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

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

                                    図 3. New Rule

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

                                    ウィザードとしてのサービス フォームの表示

                                    Service Catalog モジュールでは、ウィザード形式でディクショナリを含むサービス フォームの表示をカスタマイズできます。 ウィザードでは、前後へのナビゲーション コントロールが備わった複数のページにフォーム フィールドが表示されます。 デフォルトでは、サービスに対するすべてのディクショナリが単一ページに一覧表示されます。 個々のサービスに対しウィザードを設定でき、これによって、特にサービス フォームに多くのディクショナリが含まれている場合に、ディクショナリを整理した状態で表示することができます。

                                    ウィザードは、サービス内のアクティブ フォーム コンポーネントまたはディクショナリに基づいてステップとしてレンダリングされます。 サービス用に設定されたウィザードには、すべてのウィザード ステップが表示されているカルーセルがあり、ユーザは連続したステップを追うのではなく、任意のステップに直接移動することができます。 ナビゲーション コントロールおよび価格情報は、サービスフォームに存在するアクション ボタンとともにページの下部に表示されます。


                                      ステップ 1   [Service Designer] > [サービス(Services)] > [全般(General)] の順に選択します。
                                      ステップ 2   [ページネーションビューモード(Pagination View Mode)] フィールドの場合は、表 1にリストされているページネーション ビュー オプションから 1 つを選択します。
                                      表 18 ページネーション ビュー オプション

                                      オプション

                                      説明

                                      クラシック表示(Classic View)

                                      これはデフォルト設定です。つまり、ページネーションはサービス フォームに適用されず、サービスのすべてのディクショナリに含まれません。

                                      ディクショナリのページネーション(Dictionary Pagination)

                                      サービス フォームに存在するディクショナリごとに 1 つのウィザード ステップを表示します。

                                      フォームのページネーション(Form Pagination)

                                      サービス フォームに存在するアクティブ フォーム コンポーネントごとに 1 つのウィザード ステップを表示します。

                                      カスタムページネーション(Custom Pagination)

                                      関連付けられている選択したディクショナリを含む一連のサービス ページを表示するようにサービス フォームをカスタマイズできます。 選択したディクショナリを含む 1 つのサービス ページは、一連のウィザード ステップとして表示されます。

                                      ステップ 3   下へスクロールして、[保存(Save)] をクリックします。

                                      カスタム ページネーションを使用したサービス フォームのカスタマイズ

                                      [カスタムページネーション(Custom Pagination)] オプションを使用してサービス フォームをカスタマイズするには、次の追加手順を実行します。


                                        ステップ 1   [ページネーションビューモード(Pagination View Mode)] の横にあるアイコン をクリックします(このアイコンは、[カスタムページネーション(Custom Pagination)] オプションを選択した場合にのみ使用できます)。
                                        ステップ 2   ポップアップ ダイアログボックスで、[ページ名(Page Name)] フィールドにページの名前を入力します。
                                        ステップ 3   [使用可能なディクショナリ(Available Dictionaries)] ボックスから必要なディクショナリを選択し、矢印をクリックして [選択したディクショナリ(Selected Dictionaries)] ボックスに移動させます。
                                        ステップ 4   必要に応じて、[新しいページの追加(Add New Page)] および [選択項目の削除(Remove Selected)] を使用して、ページを追加するか選択したページを削除します。
                                        ステップ 5   [ページを保存(Save Page)] をクリックし、ダイアログボックスを閉じます。

                                        下の図は、Service Catalog モジュールでディクショナリのページネーションをカスタマイズしたカスタマイズ サービス フォームの例です。

                                        図 4. カスタム ページネーションによるサービス フォームの例




                                        インタラクティブ サービス フォーム(ISF)API の概要

                                        ISF は、JavaScript プログラミングをサービス フォームに追加するためのインターフェイスと技法のセットです。 JavaScript プログラミングは、サービス データが表示されている場合、つまりサービスが My Services、または Service Manager の [タスクの詳細(Task Details)] タブでオーダーされている場合のみ実行できます。

                                        ISF と JavaScript を使用するタイミング

                                        ISF を含む JavaScript プログラミングは、アクティブ フォーム ルールで提供される機能を補完することを目的としています。 アクティブ フォーム ルールでは、サービス フォームの対話性を強化するために関連付けられる最も一般的な動作(フィールドやディクショナリを動的に表示および非表示にする、コンテキストまたは以前入力したデータに基づいてフィールド値を設定する、フィールドを読み取り専用または編集可能、必須または任意に設定する)を提供できます。 したがって、サーバ側イベント(ロード前と送信後)は JavaScript を実行できません。

                                        ISF と JavaScript を記述するには、技術(プログラミング)的な専門知識が必要なだけでなく、さらにコードのデバッグ、アプリケーション サーバへのアクセス、ソース コード コントロールの維持のためのツールを使用する必要があります。 そのため、ISF コードの開発と維持には、同等のアクティブ フォーム ルールと比較して、より多くの費用がかかります。 このテクノロジーは、主に、目的の機能が宣言型ルールを介して実装できない場合に使用する必要があります。 以降の項で、いくつかの例を紹介します。 これらの使用例は、一般に次の領域に該当します。

                                        • ディクショナリ キャプション、フィールド ラベル、指示(ヘルプ)テキスト、およびグリッド ディクショナリ内のセルなど、ルールでアクセスできないサービス フォーム上のオブジェクトの操作。
                                        • たとえば、サービスがオーダーされた日付に基づくスケジュールされた開始日の計算、または選択したコンポーネントに基づくサービス価格の計算など、日付や数字の算術演算の実行。
                                        • 暗号化や暗号解読など、市販、フリーウェアとして配布、またはカスタム開発された特殊な関数用の JavaScript ライブラリへのアクセス、または Web サービスやサーバ側(AJAX)コードを介した別のアプリケーションへのアクセス。

                                        ISF コンポーネントによっては、アクティブ フォーム ルールを介して使用できる機能が重複するものがあります。 フォーム ルールを使用してアプリケーションの要件を完全に満たすことができる場合は、通常、それがコーディングを行う最も効果的な方法です。 ただし、多数の複雑なルールのメンテナンスを容易にするため、次のシナリオで ISF を使用して同等の機能を実装することができます。

                                        • ルールは if/then/else ロジックを完全にはサポートしていないため(「if」部分のみサポート)、「else」句のある「if」条件ごとに 2 つのルールが必要になります。 「if ステートメント」をネストする必要がある場合など、条件がより複雑になると、すべてのケースをカバーするために必要なルールの数は著しく増加します。 これらすべてのルールを記述して追跡するよりも、ネストされた if ステートメントを含む ISF 関数を 1 つ記述する方が、長期的には負担の軽減につながります。
                                        • ルールは特定の 1 つのアクティブ フォーム コンポーネント(AFC)にバインドされますが、JavaScript 関数または ISF は任意の AFC から呼び出すことができます。 ISF は、同じディクショナリが 2 つの異なる AFC で使用される場合、または同じコード部分を 2 つのフィールドに適用する必要がある場合など、多数の AFC から呼び出す必要がある複雑なコード部分に使用できます。
                                        • たとえば、フィールド ラベルやヘルプ テキストの変更など、ルールで実行可能ないくつかのアクションと共に ISF を実行する必要がある場合は、その全体を ISF でコーディングすることを検討します。 これは、ISF とルールの順序で発生する問題のためです。ルールは明示的に順序を指定できますが、ISF は同じイベントに対するすべてのルールに従う必要があります。

                                        同じイベントに対する場合であっても、同じフォーム内で ISF と宣言型ルールを自由に組み合わせることができます。 ルールで使用可能なアクションを ISF で置換または補完する際には、最も重要な制限事項として、JavaScript は、同じイベントにアタッチされたルールの後に実行する必要があるという点に注意する必要があります。

                                        ISF コンポーネント

                                        ISF には、グローバル ID だけでなく、パブリック関数のセットも含まれています。

                                        グローバル ID

                                        次の表に、ISF グローバル変数とそれらの取り得る値の概要を示し、詳細については、以下の段落で説明します。 条件付きルールに、これらの ID と同等の条件がある場合、その同等の条件が示されます。 詳細については、前述のアクティブ フォーム コンポーネントの項を参照してください。

                                        表 19 ISF グローバル ID

                                        グローバル変数

                                        説明

                                        コンテキスト

                                        サービス フォームが現在表示されているモジュール。 「コンテキスト」の条件と同等。

                                        EditRequisitionBeforeOrdering

                                        オーダーの時点で、既存の(以前保存された)要求エントリが編集されている際は true を返し、その他の条件では false を返すブール値。 RequisitionId は要求が保存される際に割り当てられるため、この条件を見つける代替方法は、(ReqID==0) を評価することです。 「未送信の要求はありますか(Does unsubmitted requisition exist?)」の条件と同等です。

                                        時点

                                        要求ライフ サイクル内の現在の時点。 「時点」の条件と同等です。

                                        ReqCustomerID

                                        サービスのカスタマーの一意の ID。 これは、要求を作成しているユーザとは異なる場合があります。 ReqCustomerID 値は、すべての時点で使用できます。 これは、Service Catalog 内の個人の一意の ID に対する参照です。

                                        ReqEntryID

                                        要求エントリ(別名、サービス要求)ID。 要求が保存されるまで、ReqEntryID はゼロ(0)です。

                                        ReqID

                                        要求 ID(別名ショッピング カート)。 要求が保存されるまで、要求 ID はゼロ(0)です。

                                        ReqInitiatorID

                                        サービス要求を開始した個人の一意の ID。 ReqInitiatorID 値は、すべての時点で使用できます。 これは、Service Catalog 内の個人の一意の ID に対する参照です。

                                        ServiceID

                                        サービスの一意の ID。下位互換性のために含まれています。サイト間でエンティティ ID を維持しない、Catalog Deployer を介して展開されたサービスには使用しないでください。

                                        ServiceName

                                        サービスの名前。 「サービス名」の条件と同等。

                                        TaskID

                                        Service Manager で表示されているタスクの ID。 TaskID は、すべての承認時点とサービス提供時点に対して設定されます。 アクティブなタスクがない時点(通常、承認またはサービス提供が開始される前)では、TaskID 値はゼロ(0)です。

                                        TaskName

                                        すべての名前空間参照が適切に評価されている、Service Manager に表示されているタスクの名前。 「タスク名」の条件と同等です。

                                        UserID

                                        要求を作成している個人、またはコンテキストが Service Manager の場合に要求で作業している個人。

                                        個人参照

                                        すべてのユーザは、Organization Designer に登録されている必要があります。 アプリケーションは、Organization Designer 内のユーザのレコードに一意の ID を割り当てることにより、これらのユーザを識別します。 アプリケーションは、現在の要求の発信者(ReqInitiatorID)、現在の要求のカスタマー(ReqCustomerID)、および現在要求で作業しているユーザ(UserID)を追跡します。

                                        オーダー時点では、ReqInitiatorID は常に UserID と同じです。 サービス提供、および承認/確認の時点では、タスク実行者または確認者が UserID によって識別されます。 Order On Behalf(OOB)機能が使用された場合、ReqCustomerID は ReqInitiatorID とは異なります。それ以外の場合は同じです。

                                        JavaScript 関数

                                        JavaScript 関数は、ISF フレームワークに組み込まれます。 ISF はオブジェクト指向のフレームワークです。 ISF JavaScript 関数は、実際には基本オブジェクト serviceForm に基づくメソッドです。 たとえば、ディクショナリを非表示にする場合は、次を呼び出します。

                                        serviceForm.DictionaryName.setVisible(false). 
                                        

                                        フィールドを非表示にする場合は、次を呼び出します。

                                        serviceForm.DictionaryName.FieldName.setVisible(false).
                                        

                                        ヒント


                                        以下の各項では、太字フォントおよびイタリック体フォントは、プログラマが項目の名前を置き換える必要があることを意味しています。



                                        (注)  


                                        JavaScript 関数は、グリッド ディクショナリおよびそのフィールドのイベントに割り当てることはできません。
                                        ディクショナリ権限と ISF ディクショナリ レベル関数

                                        (指定された時点または参加者のセットの)Service Designer を介して読み取り専用に指定されたディクショナリの外観(および HTML 表現)は、ISF の dictionaryName.setReadOnly() 関数を介して読み取り専用に設定されたディクショナリの外観(および HTML 表現)とは異なります。

                                        • Service Designer を介してディクショナリが [編集のみ(Edit only)] に設定されている場合、ディクショナリを構成するフィールドに HTML 入力タグは生成されません。これらは、サービス フォームにテキストとしてレンダリングされます。
                                        • ディクショナリのアクセス制御に編集機能が含まれており、ISF または条件付きルールを通して読み取り専用に設定されている場合は、ディクショナリ フィールドが入力オブジェクトとして表示されます。ただし、それらは入力可能ではありません。

                                        ディクショナリが設計時に読み取り専用に設定されている場合(つまり、Service Designer のアクティブ フォーム コンポーネントの [アクセス制御(Access Control)] タブで指定されている現在の参加者および時点に対する編集権限を持たない場合)、ISF またはルールによって書き込み可能にすることはできません。 これは、読み取り専用のディクショナリがレンダリングされた場合、結果の HTML に <span ../> タグ付きのテキストが含まれており、HTML の <input ..> タグは存在しないためです。

                                        ディクショナリ権限と管理ユーザ

                                        「サービス ディクショナリの管理」機能が付与されているユーザでは、ディクショナリ権限は無視されます。 (この機能は「サイト管理」組織に所属するユーザに自動的に付与され、ユーザ定義のルールおよび Service Catalog 定義のロールも含まれる場合があります)。ディクショナリは、編集可能であるかのように表示されます。 「サービス ディクショナリの管理」機能によって、指定したディクショナリ権限が上書きされるため、管理ユーザとしてログインしている場合は ISF をテストしないように注意する必要があります。

                                        ディクショナリの存在の確認

                                        次の ISF 式

                                        serviceForm.dictionaryName
                                         

                                        は、ブール値を返す関数ではありません。 dictionaryName は、serviceForm オブジェクトの属性です。 dictionaryName 属性は、ISF が実行されたサービス内にディクショナリが存在する場合は true 値を持ち、ディクショナリが存在しない場合は未定義になります。 したがって、1 つ以上のディクショナリが存在することを確認し、現在のサービスにディクショナリが存在する場合のみアクションを実行する堅牢なコードは、次のようにコーディングします。

                                        AIT_Server_onLoad() { if (serviceForm.RC_CUSTCODES != undefined)     {RC_CUSTCODES_onLoad();)
                                          if (serviceForm.RC_PERFORMWORK != undefined)     {RC_PERFORMWORK_onLoad();)
                                        }
                                        フィールド レベル関数

                                        次の表に、フィールドに適用可能な関数の概要を示し、詳細については、以下の段落で説明します。

                                        表 20 フィールド レベル関数

                                        機能

                                        使用方法

                                        グリッドの使用

                                        serviceForm.dictionaryName.fieldName

                                        フォーム内にフィールドが存在する場合にフィールド オブジェクトを返します。それ以外の場合は、未定義になります。

                                        [いいえ(No)]

                                        serviceForm.dictionaryName.fieldName.getValue()

                                        フィールドの現在の値を返します。

                                        [いいえ(No)]

                                        serviceForm.dictionaryName.fieldName.setValue(inputValues)

                                        フィールドの値を設定します。

                                        [いいえ(No)]

                                        serviceForm.dictionaryName.fieldName.getCellValue (RowIndex)

                                        指定された RowIndex のグリッド カラムのセル値を返します。

                                        [はい(Yes)]

                                        serviceForm.dictionaryName.fieldName.setCellValue (RowIndex, inputValue)

                                        指定された RowIndex のグリッド カラムのセル値を設定します。 inputValue は、配列ではなく単一の値を取ります。

                                        [はい(Yes)]

                                        serviceForm.dictionaryName.fieldName.setValue(inputValues, defaultValue)

                                        フィールドの値を設定します。 inputValues は配列の必要があり、inputValues の最初の値は、任意の単一オプション フィールドに割り当てられます。

                                        defaultValue は、入力タイプがテキストまたはテキスト エリアのフィールドにのみ適用可能です。 その他のフィールド タイプの場合、defaultValue は無視されます。

                                        [いいえ(No)]

                                        serviceForm.dictionaryName.FieldName.setSelection(inputValues)

                                        HTML 表現の選択(単数)、選択(複数)、チェック ボックス、またはオプション ボタンのフィールドの値を設定します。

                                        [いいえ(No)]

                                        serviceForm.dictionaryName.FieldName.setMandatory(Boolean)

                                        フィールドを必須または任意にします。 フィールドが、Service Designer の設定を通して必須になっている場合には、必須以外にはできません。 フィールドを必須にすると、自動的に検証が割り当てられます。このフィールドを空白にしてフォームを送信すると、「必須:送信前にこのフィールドに入力してください(Required: Please fill out this field before submitting)」というエラー メッセージが表示されます。

                                        [いいえ(No)]

                                        serviceForm.dictionaryName.fieldName .isMandatory()

                                        フィールドが必須としてマークされているか確認します。 ISF の setMandatory() 関数、条件付きルール、または Service Designer の表示設定のいずれかでフィールドが必須になっている場合は、true を返します。

                                        [いいえ(No)]

                                        serviceForm.dictionaryName.fieldName .setReadOnly(Boolean)

                                        フィールドまたはグリッド カラムを読み取り専用または読み取り/書き込みに設定します。

                                        [はい(Yes)]

                                        serviceForm.dictionaryName.fieldName .isReadOnly()

                                        フィールドまたはグリッド カラムが読み取り専用の場合には true を返し、その他の場合には false を返します。

                                        [はい(Yes)]

                                        serviceForm.dictionaryName.fieldName .setVisible(Boolean)

                                        フィールドまたはグリッド カラムを非表示または表示可能(表示対象)にします。 カラムが、Service Designer の設定で非表示になっている場合には、表示可能にできません。

                                        [はい(Yes)]

                                        serviceForm.dictionaryName.FieldName.isVisible()

                                        フィールドまたはグリッド カラムが表示可能な場合には true を返し、その他の場合には false を返します。

                                        [はい(Yes)]

                                        serviceForm.dictionaryName.FieldName.setFocus(Boolean)

                                        フィールドにフォーカスを設定します。オプション ボタンとチェック ボックスを除く、すべての入力タイプに適用できます。 True の場合はフィールドにフォーカスが設定され、False の場合はフィールドが不鮮明になります。 この関数は、Service Designer を通して読み取り専用に設定されたディクショナリ内のフィールド、または非表示のフィールドには適用されません。呼び出しは無視され、エラーは表示されません。

                                        [いいえ(No)]

                                        serviceForm.dictionaryName.FieldName.setFocusViaValidation(Boolean)

                                        フィールドにフォーカスを設定します。オプション ボタンおよびチェック ボックスにのみ適用可能です。

                                        [いいえ(No)]

                                        serviceForm.dictionaryName.FieldName.getInstructionalText(stripTags)

                                        フィールドまたはグリッド カラムの指示テキストを返します。オプションで、Boolean stripTags 引数に基づいて、テキストからすべての HTML を削除します。

                                        [はい(Yes)]

                                        serviceForm.dictionaryName.FieldName.setInstructionalText(text)

                                        フィールドまたはグリッド カラムの指示テキストを設定します。

                                        [はい(Yes)]

                                        serviceForm.dictionaryName.FieldName.getPrompt(stripTags)

                                        フィールドまたはグリッド列ヘッダーのプロンプトを返します。オプションで、Boolean stripTags 引数に基づいて、プロンプトからすべての HTML を削除します。

                                        [はい(Yes)]

                                        serviceForm.dictionaryName.FieldName.setPrompt(prompt)

                                        フィールドまたはグリッド列ヘッダーのプロンプトを設定します。

                                        [はい(Yes)]

                                        フィールドの存在の確認

                                        次の ISF 式

                                        serviceForm.dictionaryName.fieldName
                                        

                                        ではブール値を返しません。 fieldName は、serviceForm.dictionaryName オブジェクトの属性です。 fieldName 属性は、フィールドが現在のサービスに存在していない場合は未定義となります。 (フィールドは非表示の場合がありますが、引き続き存在していると見なされます)。したがって、1 つ以上のディクショナリが存在することを確認し、現在のサービスにディクショナリが存在する場合のみアクションを実行する堅牢なコードは、次のようにコーディングします。

                                        RC_REQUESTEDBY_onLoad() {  if (serviceForm.RC_REQUESTEDBY.FirstName != undefined)     {serviceForm.RC_REQUESTEDBY.FirstName.setReadOnly();)
                                          if (serviceForm.RC_REQUESTEDBY.LastName != undefined)    {serviceForm.RC_REQUESTEDBY.LastName.setReadOnly();)
                                        }
                                        

                                        コードで以前にディクショナリの「存在」が確認されている場合は、必ずしもフィールドの存在をチェックする必要はありません。

                                        commonOnLoad() {
                                          if (serviceForm.RC_REQUESTEDBY != undefined) {
                                            RC_REQUESTEDBY_onLoad();
                                          }
                                          ...
                                        }
                                        RC_REQUESTEDBY_onLoad() {  serviceForm.RC_REQUESTEDBY.FirstName.setReadOnly();
                                          serviceForm.RC_REQUESTEDBY.LastName.setReadOnly();
                                        }
                                        フィールドの値の取得

                                        getValue() メソッド(serviceForm.dictionaryName.fieldName.getValue())は、常に配列を返します。 項目が 1 つしかない場合は、1 項目の配列です。 .getValue()[0] を使用して最初の要素にアクセスします。 ディクショナリに編集アクセス権が定義されている場合、現在の時点でフィールドが読み取り専用、読み取り/書き込み、または非表示にされているかどうかに関係なく、getValue() メソッドはすべてのフィールドに作用します。

                                        • チェック ボックスや選択(複数)などの入力タイプでは、値に Tab 文字が含まれていると getValue() が正しく処理されません(たとえば、Tab 文字を使用してリスト内の値が区切られている外部ソースからデータのインポートを試行する場合)。 値に含まれる Tab 文字は、\t で表現されます。
                                        • 複雑な制御(オプション、チェック ボックス、複数選択、単一選択/ドロップダウン)の場合、返される値は「選択した値」のセットになります。つまり、強調表示されている値のみが返され、表示にはラベルまたはテキストではなくしばしば「値(Value)」プロパティが使用されます。

                                        セキュリティ上の理由で、このメソッドは入力タイプがパスワードのフィールドでは機能しません。 空白の文字列が返され、エラーは表示されません。

                                        フィールドを読み取り専用に設定

                                        setReadOnly() メソッド(serviceForm.dictionaryName.fieldName.setReadOnly())は、フィールドを読み取り専用と読み取り/書き込みの間で切り替えます。

                                        • 入力タイプがユーザ、日付、または日時のフィールドにはボタンが関連付けられており、ユーザは、そのボタンをクリックしてフィールドの値を選択できます。 これらのフィールドを読み取り専用に設定すると、フィールドの横の [選択(Select)] ボタンが無効になり、クリックできなくなります。 説明情報(個人の名前、日付、または日時)を含むテキスト フィールドは、常に読み取り専用です。
                                        • Service Designer で特定の時点に対してディクショナリが読み取り専用にマークされている場合、フィールドは定型文としてサービス フォームに表示されます。HTML 入力オブジェクトは生成されません。 このようなディクショナリ(またはディクショナリ内のフィールド)は、ISF を通して読み取り/書き込みに設定できません。 ISF setReadOnly() を使用してディクショナリまたはディクショナリ内のフィールドを書き込み可能にしようとすると、失敗しますがメッセージは表示されません。 同様に、ISF を介してフィールドまたはディクショナリを読み取り専用にしようとしても効果がなく、エラーは生成されません。
                                        • ISF を通してディクショナリまたはフィールドを読み取り専用に設定すると、引き続き HTML 入力ボックスは表示されますが、フィールドの内容は編集不可であり、フィールドは Tab シーケンスから除外されます。
                                        フィールドを表示可能に設定

                                        setVisible() メソッド(serviceForm.dictionaryName.fieldName.setVisible())は、サービス フォームでフィールドを非表示と表示可能の間で切り替えます。

                                        • Service Designer で特定の時点に対してディクショナリが非表示としてマークされている場合、そのディクショナリ内のフィールドは、ISF を介して表示可能にできません。
                                        • ISF を介してディクショナリが非表示になっている場合にディクショナリ内のフィールドを表示可能にしようとすると、失敗しますがメッセージは表示されません。
                                        フィールドの値の設定

                                        フィールドの値の設定には、次の 2 つのメソッドを使用できます。

                                        • serviceForm.dictionaryName.fieldName .setValue())
                                        • serviceForm.dictionaryName.fieldName.setSelection())

                                        3 番目のメソッドは setValue() メソッドと同等ですが、グリッド内のセルに対するものです。

                                        • serviceForm.dictionaryName.fieldName.setCellValue())

                                        詳細については、フォーム ルールを使用した動的なフォーム動作の設定を参照してください。

                                        setValue() メソッドは、指定したフィールドの値に指定した inputValues を設定します。 inputValues は配列の必要があり、inputValues の最初の値は、任意の単一オプション フィールドに割り当てられます。

                                        • セキュリティ上の理由で、このメソッドは入力タイプがパスワードのフィールドでは機能しません。
                                        • 入力タイプが選択(単一)、選択(複数)、チェック ボックス、およびオプション ボタンの inputValues には表示値が設定され、この関数は同じ値を選択します。 チェック ボックス タイプのフィールドは、inputValues の配列を取ることができます。 フィールド内にない無効な表示値が渡されると、関数は選択を行わずに戻ります。 サービス フォームの保存時には、選択が維持されます。
                                        • inputValues に対する検証は行われません。 [ユーザ(Person)]、[SSN]、[URL]、または [日付(Date)] のようなフィールド タイプの場合であっても、サービス フォームの送信時に、この関数を通して設定された誤った値が保持される可能性があります。
                                        • [ユーザ(Person)] タイプのフィールドに関しては、次の特殊なフィールド レベル関数の項を参照してください。

                                        setSelection() メソッドは、複数オプションのフィールド(選択(単一)、選択(複数)、チェック ボックス、およびオプション ボタン)に使用する必要があります。 引数は、フィールドのさまざまな要素の値に一致します。 ラジオ フィールドまたはチェック ボックスの場合は、この関数を使用して、選択に 1 つの制御を設定すること、または制御を設定しないことができます。 たとえば、.setSelection([‘’]) は、すべてのオプション ボタンをクリアして「初期状態」に戻します。

                                        複数選択または単一選択の入力項目の場合、setSelection は、要求された項目を選択した状態にマークします。 リスト内で検出されなかった項目は無視されます。

                                        この関数は、入力タイプがパスワード、テキスト、またはテキスト エリアのフィールド、または読み取り専用ディクショナリ内のフィールドに使用しても効果がありません。

                                        特殊なフィールド レベル関数

                                        フィールド レベル関数によっては、特定タイプのフィールドだけに適用できる関数があります。 次の表は、これをまとめたものです。

                                        表 21 特殊なフィールド レベル関数

                                        機能

                                        使用方法

                                        serviceForm.dictionaryName.fieldName_disp .getValue()

                                        個人タイプのフィールドにのみ適用されます。 fieldName.getValue(inputValues) は、指定されたフィールドの PersonID を取得します。 [ユーザ(Person)] フィールドの表示値(通常は個人の名前)には、フィールド名にサフィックスとして「_disp」を付加(…fieldName_disp.getValue())することによってアクセスできます。

                                        serviceForm.dictionaryName.fieldName_disp .setValue(inputValues)

                                        個人タイプのフィールドにのみ適用されます。 fieldName.setValue(inputValues) は、指定されたフィールドの PersonID を設定します。 fieldName_disp.setValue(inputValues) を使用して、テキスト ボックスに表示される値を設定します。

                                        serviceForm.dictionaryName.fieldName_saved .getValue()

                                        単一選択フィールドおよび複数選択フィールドの場合、通常の fieldName.getValue() は常に現在選択されている値を返します。 [選択(Select)] タイプのフィールドに保存された値は、実際のフィールド名に「_saved」を付加することによってアクセスできます。

                                        fieldName_saved .getValue()

                                        この関数は、[選択(Select)] リストで以前の時点に保存された値を判断する際に役立ちます。

                                        この関数は、以前の同一時点に保存された値も返します。

                                        fieldName_saved .setValue() はエラーを発生せずに実行されますが、機能しない状態であり、フィールドの保存された値を変更しません。

                                        (注)      この関数は、グリッド ディクショナリでは使用できません。
                                        個人ベースのフィールド

                                        個人データ型と HTML 表現は、Organization Designer に保存された個人のプロファイル データの表示および検証用に設計されています。 次に示すように、このフィールドは、サービス フォーム上に、「Select」というラベル付きで、関連付けられたコントロールを持つ単一行のテキスト ボックスとして表示されます。

                                        図 5. オプションの選択 

                                        [選択(Select)] ボタンをクリックすると表示されるポップアップ ウィンドウを使用して、Service Community 内のユーザを検索し、目的の個人を選択できます。 サービス フォームに、個人の名前と電子メール アドレス([サイト管理(Site Administration)] で設定したフィールド)が表示されます。

                                        ISF 関数を個人タイプのフィールドに適用すると、次のように動作します。

                                        • personFieldName .getValue() は、Service Catalog の個人レコードに対する一意の ID である個人の ID を返します。 カスタマイズされた適切なサーバ側コードでその ID を使用することにより、サービス フォームの他のフィールドで、追加の個人のプロファイル情報を検索して表示できます。
                                        • personFieldName_disp .getValue() は、サービス フォームに現在表示されている個人の名前を返します。
                                        • セレクト コントロールを使用すると、[PersonField] フィールドと [PersonField_disp] フィールドが自動的に更新され、同期を維持できます。
                                        • personFieldName .setValue() を使用して、PersonID の値を設定できます。 この関数と personFieldName_disp .setValue() を組み合わせて使用することにより、現在の ID に対して常に正しい名前を表示できます。

                                        PersonField.setValue () 関数は有効な個人 ID を想定していますが、クライアントによる検証は行われません。そのため、無効な ID を割り当てても、送信/更新アクションが失敗することはありません。 [PersonField] の表示値には、fieldName にサフィックスとして「_disp」を付加することによってアクセスできます。

                                        fieldName_disp .setValue(inputValues).

                                        • サービス フォームを送信すると、この関数を使用して設定された個人 ID 値は保持され、表示値は無視されます。
                                        • [ユーザ(Person)] の名前を変更しても、サービス フォームは [ユーザ(Person)] の表示値と同期しません。つまり、この関数を使用して設定された値が引き続き表示されます。
                                        複数の値/選択が許可されるフィールド

                                        複数選択のフィールドおよびチェック ボックスに対する HTML 表示では、同じフィールドで複数の値を選択できます。 次の例に示すように、選択した値は、カンマ区切りのリストで表示されます。

                                        alert (serviceForm.EUIT_RemoteAccessDetails.AccessType.getValue([0]));
                                        


                                        JavaScript split() メソッドを使用すると、フィールド値を解析して各要素を区別できます。

                                        ISF コードをサービス フォームに統合

                                        ISF およびサービス フォームは、類似しているが同一ではないイベント モデルをドキュメント オブジェクト モデル(DOM)イベント モデルに実装します。 つまり、カスタマイズした JavaScript 関数を呼び出して、サービス フォームの処理中に発生するイベントを処理できます。

                                        通常、JavaScript 関数は、HTML フォームが表示され、ユーザがフォームの入力フィールドにデータを入力すると発生する処理イベントに対するイベント ハンドラとして呼び出されます。 サービス フォームは、以前リポジトリに保管したディクショナリおよびフォームの定義に基づいて動的に生成されるため、プログラマが単純に ISF コードを HTML ファイルに入力することはできません。 Service Designer によって提供されたユーザ インターフェイスに従って関数を記述し、それらの関数を適切なイベントにアタッチする必要があります。 したがって、イベント ハンドラとしてアクセスされるすべての JavaScript 関数も、リポジトリ内に定義する必要があります。 このような関数は、Service Designer の [スクリプト(Scripts)] オプションを通して定義され、フォームの [アクティブな動作(Active Behavior)] タブを通して該当するイベントに関連付けられます。

                                        次に、イベント ハンドラとして記述された JavaScript 関数は、他の JavaScript 関数を呼び出すことができます。 これらの関数は(パブリック スコープを持つ必要がある場合)、Service Designer 内でスクリプトとして定義することはできません。 代わりに、それらの関数は、1 つ以上の関数を含むテキスト ファイルとして JavaScript ライブラリ内に記述し、アプリケーション サーバからアクセス可能なファイル システム内に配置する必要があります。 次に、Service Designer インターフェイスを使用して、その関数を必要とするフォーム内に、これらのライブラリを組み込みます。

                                        グローバル フォームの設定

                                        すべてのフォームで使用される JavaScript の動作を管理するには、グローバル フォームの設定を使用します。 これらの設定は標準のフォーム イベントによって構成されています。

                                        • フォームの送信時(ブラウザ側)
                                        • フォームのロード時(ブラウザ側)
                                        • フォームのアンロード時(ブラウザ側)

                                        (注)  


                                        サーバ側トリガー イベントの [フォームの送信後(サーバ側)(After the form is submitted (server-side))] と [フォームのロード前(サーバ側)(Before the form is loaded (server-side))] は、フォーム ルールに対してのみ提供されます。

                                        JavaScripts の追加

                                        • [全般(General)] タブでは、JavaScript 関数を作成し、維持できます。
                                        • [ライブラリ(Libraries)] タブでは、JavaScript ライブラリを現在の関数、および拡張により、関数がアタッチされるフォームに組み込むことができます。
                                        • [アクティブフォームコンポーネント(Active Form Components)] タブには、現在の関数がアタッチされるフォームが表示されます。

                                        新しい JavaScript 関数を作成するには、次の手順を実行します。


                                          ステップ 1   [Service Designer] > [スクリプト(Scripts)] の順に選択します。
                                          ステップ 2   [新規(New)] > [新規関数(New Function)] の順に選択します。 関数を作成後、メンテナンスのために左側のツリー構造からそれを選択します。
                                          • [名前(Name)]:関数の名前。 Service Designer 内でこの名前が使用されますが、JavaScript 関数を参照するには、生成されたコード内で関数を識別する JavaScript 識別子を使用するのが良い方法です。 JavaScript 識別子としての名前は、大文字と小文字を区別する単一の単語であり、文字と数字で構成され、文字で始まります。 関数の命名のガイドラインについては、最適なサービス フォームの設計に関するガイドラインで命名規則を参照してください。
                                          • [説明(Description)]:任意ですが、関数の説明を記述するように強く推奨されています。
                                          • [このスクリプトをすべてのフォームの次のイベントに追加する(Add this script to the following events on all forms)]:これらのチェック ボックスは、オンにされたイベントに対するイベント ハンドラとして関数を指定するために使用します。 この「グローバルな」アタッチによって、[アクティブフォームの動作(Active Form Behavior)] タブを介したイベントへの関数の「ローカルな」アタッチが置き換えられます。 グローバルなアタッチは、ISF コーディングとベスト プラクティスで説明するように、ほとんどのプロジェクトで推奨されていません。
                                          • [JavaScript関数(JavaScript Function)]:ISF コードをインクルードする関数の実際のコード。 関数シグニチャは「function」キーワードを含むことはできませんが(これは、生成されたサービス フォームに関数が取り込まれるときに自動的に追加されます)、それ以外は、関数の内容は標準的な JavaScript ルールに従います。 次に例を示します。

                                          JavaScript 関数内にこのコード ブロックを記述

                                          フォーム内にこのコードを生成

                                          CER_Name_onChange() {
                                          }
                                          function CER_Name_onChange() {
                                          }
                                          ステップ 3   [新規JavaScriptを追加(Add new JavaScript)] をクリックします。

                                          JavaScript 関数への引数の追加

                                          JavaScript 関数に引数を追加できます(関数が呼び出されるたびに)。 スクリプトで作成された関数の引数は、サービス レベルでサービス設計者によって上書きできます。


                                            ステップ 1   [Service Designer] > [スクリプト(Scripts)] の順に選択します。
                                            ステップ 2   関数を選択し、[全般(General)] > [関数の引数(Function Arguments)] の順に選択します。
                                            1. [引数名(Argument Name)] フィールドで、引数の名前を入力します(JavaScript 識別子の命名規則に従ってください)。
                                            2. [デフォルト値(Default Value)] フィールドに、デフォルト値を入力します。
                                            ステップ 3   [追加(Add )] をクリックして、新しい関数の引数を追加します。
                                            ステップ 4   (任意)[情報(Information)] アイコン ボタン をクリックして、説明を入力します。 説明を入力できる [パラメータの説明(Parameter Description)] ポップアップ ウィンドウが表示されるので、[説明の設定(Set Description)] をクリックします。
                                            ステップ 5   左下の、 [保存(Save)] をクリックします。

                                            引数の定義では、次のガイドラインに従います。

                                            • JavaScript の引数ごとに未使用のデフォルト値(つまり、上書きされないデフォルト値)を設定します。
                                              • たとえば、MyUniqueFunction(arg1, arg2) { .. }:この 2 つの引数のデフォルト値は、arg1 = ‘unused value 1’、arg2 = ‘unused value 2’ とする必要があります。

                                            ヒント


                                            各引数にデフォルト値を入力する必要があります。 それ以外の場合、エラーが発生します。



                                            ヒント


                                            デフォルト値として文字列を使用する場合には、一重引用符で囲む必要があります。 二重引用符は使用しないでください。また、間に値が存在しない 2 つの一重引用符を使用しないでください。


                                            • JavaScript には型がないため、引数を特定のデータ型としてマークする方法はありません。
                                              • 引数の意図が文字列値の場合、デフォルトのダミー値(使用されることがない値)を一重引用符で囲むことができます。 たとえば ‘AAABBBCCCDDD’ と入力します。
                                              • 引数の意図が数値の場合、デフォルトのダミー値(使用されることがない値)を負の値にすることができます。 たとえば –999999999 と入力します。
                                            • JavaScript 関数をアクティブ フォーム コンポーネントに追加した後、関数の引数を編集します。

                                            JavaScript 関数へのライブラリの関連付け

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

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

                                            ライブラリ使用の前提条件

                                            ライブラリのアプローチには次の前提条件があります。

                                            • JavaScript ライブラリは、アプリケーション サーバの Web 展開ディレクトリ(RequestCenter.war)上に存在する必要があります。 慣例で、ライブラリは「isfcode」という名前のディレクトリに配置します。
                                            • したがって、プログラマは、アプリケーション サーバのファイル システムに対するアクセス権を持つ必要があります。 これにより、サーバ上に追加のログインが作成される場合や、追加のクライアント ソフトウェア(たとえば、リモート デスクトップ サービス)が提供される場合があります。
                                            • ISF コードが存在するディレクトリには、ISF プログラマに対して読み取り/書き込み権限を設定する必要があります。

                                            ISF スクリプトを格納する場所は、設計コストに影響を与えるため、詳細な設計を行う前に決定する必要があります。 すべての ISF をリポジトリに埋め込むよりも、ライブラリ アプローチを使用する方が、はるかに効率的です。

                                            関数が、ライブラリに存在する関数を追加で呼び出す場合、[JavaScripts] オプションの [ライブラリ(Libraries)] タブを使用して、ライブラリを指定します。

                                            新しいライブラリを追加するには、次の手順を実行します。


                                              ステップ 1   [Service Designer] > [スクリプト(Scripts)] の順に選択します。
                                              ステップ 2   関数を選択し、[ライブラリ(Libraries)] > [ライブラリの追加(Add Libraries)] の順に選択します。
                                              ステップ 3   [ライブラリの追加(Add Libraries)] ウィンドウで、追加するライブラリに対応するチェック ボックスを選択し、[追加(Add)] をクリックして選択した項目を JavaScript 関数に組み込みます。

                                              関数に組み込まれたすべてのライブラリが、[ライブラリ(Libraries)] ページに表示されます。


                                              対応するチェック ボックスをオンにし、[削除(Remove)] をクリックすることにより、1 つ以上のライブラリを削除できます。

                                              JavaScript を使用したフォームの確認

                                              [アクティブフォームコンポーネント(Active Form Components)] タブには、現在の JavaScript がアタッチされているフォームがリストされます。

                                              Javascript に使用されるフォームを確認するには、次の手順を実行します。


                                                ステップ 1   [Service Designer] > [スクリプト(Scripts)] の順に選択します。
                                                ステップ 2   関数を選択し、[アクティブフォームコンポーネント(Active Form Components)] を選択します。
                                                ステップ 3   フォーム名をクリックして、フォーム定義を確認します。

                                                クロスリファレンスには、関数の「ローカルな」アタッチのみ反映されます。 JavaScript 関数の [全般(General)] タブで [このスクリプトをすべてのフォームの次のイベントに追加する(Add this script to the following events on all forms)] チェック ボックスをオンにすることで、サービスに「グローバル」にアタッチされた JavaScript は含まれません。


                                                JavaScript ライブラリの作成

                                                Service Catalog の外部で作成した(または作成する予定の)ライブラリを関連付けるには、この手順を使用します。

                                                手順


                                                  ステップ 1   [Service Designer] > [スクリプト(Scripts)] の順に選択します。
                                                  ステップ 2   [新規(New)] > [新しいライブラリ(New Library)] の順に選択し、リポジトリでライブラリに対するエントリを作成します。
                                                  • [名前(Name)]:説明フィールドなので、ライブラリに任意の名前を指定できます。 この名前は、Service Designer 内でライブラリの参照に使用されます。
                                                  • [URLからインポート(Import from URL)]:ライブラリの位置。 ライブラリは、Web 展開ディレクトリ内に配置する必要があります(/RequestCenter/ と指定)。 慣例として、ISF ライブラリは、ルート ディレクトリ /RequestCenter の直下にある isfcode ディレクトリに配置されます。
                                                  • [このライブラリをすべての関数に組み込む(Include this library in all functions)]:このチェック ボックスでは、実際にはすべての「関数」ではなく、すべてのサービス フォーム内のライブラリがインクルードされるため、この命名も若干適切ではありません。 このチェック ボックスをオンにすると、サービス フォーム内のライブラリが(参照により)インクルードされ、ライブラリ内に定義されたすべての関数を呼び出せるようになります。 (ライブラリの <script> タグがサービス フォーム内に生成されます。)この詳細と他のオプションについては、ISF コーディングとベスト プラクティスを参照してください。
                                                  ステップ 3   [新しいライブラリの追加(Add new Library)] をクリックすることにより、ライブラリをリポジトリに追加します。

                                                  JavaScript への関数の引数の追加

                                                  JavaScript 関数をフォームに追加するには、次の手順を実行します。


                                                    ステップ 1   [Service Designer] > [アクティブフォームコンポーネント(Active Form Component)] の順に選択します。
                                                    ステップ 2   [アクティブフォームの動作(Active Form Behavior)] タブをクリックします。
                                                    ステップ 3   [フォームまたはフィールド(Form or Field)] 列で、最初の行である [このアクティブフォームコンポーネント(This Active Form Component)] を選択します。 [トリガーイベント(Triggering Event)] 列に、すべてのフォーム レベル イベントが一覧表示されます。
                                                    ステップ 4   JavaScript 関数をアタッチするフォーム レベル トリガー イベントを選択します。

                                                    JavaScript 関数に対して使用できるフォーム レベル トリガー イベントには、次のものがあります。

                                                    表 22 フォーム レベル トリガー イベント

                                                    フォーム レベル トリガー イベント

                                                    説明

                                                    フォームの送信時(ブラウザ側)

                                                    コードは、[送信(Submit)] ボタンまたは [更新(Update)] ボタンをクリックした、およびフォームの [表示(Display)] で指定された任意の検証(数値データや必須データの確認など)ので実行されます。 これらのアクションは、フォームがサーバに送信されるに実行されます。 これにより、通常、データがサーバに送信される前に追加の検証、フォーマット設定、または任意の処理を実行するためのウィンドウが表示されます。 onSubmit 関数は、送信を実行できる場合には true ブーとして返し、停止する場合には false を返す必要があります。 これは、HTML イベントの form ... onSubmit に対応しています。

                                                    フォームのロード時(ブラウザ側)

                                                    ディクショナリ内のフィールドに値を入力するコード、またはブラウザでフォームがレンダリングされる前に何らかのフォーム メッセージングを実行するコードを追加する際に、ここが最適な場所となります。 これは、HTML イベントの body ... onLoad に対応しています。

                                                    フォームのアンロード時(ブラウザ側)

                                                    このイベントは、フォームを閉じるときに呼び出されます。 このイベントは、ウィンドウを閉じると失われるデータをユーザに通知するために使用できます。 これは、HTML イベントの body ... onUnload に対応しています。

                                                    (注)      サーバ側トリガー イベントの [フォームの送信後(サーバ側)(After the form is submitted (server-side))] と [フォームのロード前(サーバ側)(Before the form is loaded (server-side))] は、フォーム ルールに対してのみ提供されます。
                                                    ステップ 5   [JavaScriptの追加(Add JavaScript)] をクリックします。

                                                    [関数の追加(Add Functions)] ダイアログボックスが表示され、[スクリプト(Scripts)] オプションで事前定義された JavaScript 関数が一覧表示されます。

                                                    ステップ 6   チェック ボックスをオンにすることで JavaScript 関数を選択し、[追加(Add)] をクリックします。 必要に応じて [検索(Search)] ボックスを使用して、JavaScript 関数を検索できます。

                                                    [JavaScripts] セクションの [動作(Behavior)] 列に関数が表示されます。


                                                    (注)  


                                                    単一フォーム内の同じイベントに複数の JavaScript 関数をアタッチできますが、関数を指定(および実行)する順序を定義できないため、これは最も回避すべき方法です。 したがって、特定の順序で関数を実行する必要がある場合には、目的とする順序ですべての関数を含む JavaScript 関数を作成します。

                                                    フィールド レベル イベントへの JavaScript 関数の追加

                                                    フィールド レベル イベントに JavaScript 関数を追加するには、次の手順を実行します。


                                                      ステップ 1   Service Designer のアクティブ フォーム コンポーネント内のフォームを編集します。
                                                      ステップ 2   [アクティブフォームの動作(Active Form Behavior)] タブをクリックします。
                                                      ステップ 3   [フォームおよびフィールド(Form and Field)] 列で、ディクショナリ ノードを展開し、関数をアタッチするフィールドを選択します。
                                                      ステップ 4   [トリガーイベント(Triggering Event)] 列で、関数を実行するタイミングに対応するフィールド レベル トリガー イベントを選択します。
                                                      図 6. トリガー イベント

                                                      表 23 次のフィールド レベル トリガー イベントを使用できます。

                                                      トリガー イベントの説明

                                                      HTML イベント名

                                                      項目のクリック時

                                                      onClick

                                                      項目の変更時

                                                      onChange

                                                      項目のフォーカス時

                                                      onFocus

                                                      項目のフォーカスの喪失時

                                                      onBlur

                                                      項目にマウスを移動時

                                                      onMouseOut

                                                      項目からマウスを移動時

                                                      onMouseOver

                                                      onChange イベントは、テキスト/単一選択フィールドへの変更の検出に最も適しています。 同一人物が [人を選択します(Select Person)] ポップアップ ウィンドウから選択された場合、または同じ日付が [予定表(Calendar)] ポップアップから選択された場合であっても、[ユーザ(Person)]、[日付(Date)]、または [日時(DateTime)] フィールドに対する onChange イベントは常にトリガーされます。 同様に、[テキスト(Text)] フィールドに入力すると、フィールド内の値を実際に変更したかどうかに関係なく onChange イベントがトリガーされます。

                                                      • 現在のフィールドの値に基づいて、フィールドに入力します(たとえば、ユーザが入力した別のフィールドの値に基づいてサービスにフラグを設定)。

                                                      • ドロップダウンから [その他(Other)] を選択すると、フォーム上にさらにテキスト ボックスを表示する必要があります。

                                                      onClick イベントは、オプション ボタン/チェック ボックスの制御で最もよく機能します。 onClick イベントは、[ユーザ(Person)]、[日付(Date)]、および [日時(DateTime)] フィールドに対してはトリガーされません。その理由は、これらのフィールド タイプに対するテキスト ボックスは常に読み取り専用であり、ポップアップ ウィンドウを通してのみ選択可能なためです。

                                                      ステップ 5   [JavaScriptの追加(Add JavaScript)] をクリックします。

                                                      [関数の追加(Add Functions)] ダイアログボックスが表示され、[スクリプト(Scripts)] オプションで事前定義された JavaScript 関数が一覧表示されます。

                                                      ステップ 6   チェック ボックスをオンにすることで JavaScript 関数を選択し、[追加(Add)] をクリックします。 必要に応じて [検索(Search)] ボックスを使用して、JavaScript 関数を検索できます。
                                                      図 7. JavaScript 関数

                                                      次に示すように、[JavaScripts] セクションの [動作(Behavior)] 列に関数が表示されます。

                                                      図 8. JavaScript 関数の機能

                                                      (注)      単一フォーム内の同じイベントに複数の JavaScript 関数をアタッチできますが、関数を指定(および実行)する順序を定義できないため、これは最も回避すべき方法です。 したがって、特定の順序で関数を実行する必要がある場合には、目的とする順序ですべての関数を含む JavaScript 関数を作成します。
                                                      ステップ 7   必要に応じて、[動作(Behavior)] 列で JavaScript 関数をクリックし、次に [引数の編集(Edit Arguments)] をクリックすることにより、関数の引数を編集できます。 (詳細については、JavaScript 関数への引数の追加を参照してください。)

                                                      JavaScript の使用

                                                      ここでは、JavaScript 関数の使用について説明します。

                                                      関連付けられたコントロール(ボタンとリンク)

                                                      ディクショナリ フィールドには、そのフィールドの [表示プロパティ(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 エントリからコピーして貼り付けたものです。

                                                      ISF コーディングとベスト プラクティス

                                                      ISF を使用すると、サービス カタログ プロジェクトの複雑性が増します。 この項では、この環境での開発に役立つ方法論的および技術上のヒントの概要を説明します。

                                                      • JavaScript および ISF を効率的に開発、検証、およびデバッグするには、追加のツールをクライアントのワークステーションにインストールするか、または以前インストールしたソフトウェアを再設定します。
                                                      • JavaScript ではエラーは通知されません。 したがって、より有益なエラー メッセージとデバッグ機能を得るには JavaScript DebuggerJavaScript をインストールします。Microsoft Script Debugger は、Microsoft から無料でダウンロードできます(インターネット検索で検索してください)。 Visual Studio など、いくつかの Web 開発環境には使用可能なデバッガも含まれています。

                                                      デバッガを使用するには、[ツール] > [インターネット オプション] > [詳細設定] オプションでスクリプトのデバッグを有効にするように Internet Explorer を再設定する必要があります。

                                                      • JavaScript プログラムには構文の強調表示を提供するテキスト エディタを使用します。 このようなエディタの中には、フリーウェアまたはトライアル バージョンとして提供されているものもあります。 いくつかの Java 統合開発環境(IDE)は、JavaScript ファイルの編集もサポートしています。
                                                      • ISF 開発者に、JavaScript ライブラリが存在するアプリケーション サーバ上のディレクトリ(一般には、RequestCenter.war Web アーカイブ下の isfcode ディレクトリ)への読み取り/書き込みアクセス権を提供します。 また、ワークステーションとアプリケーション サーバ間でファイルを転送するソフトウェアも必要です。
                                                      • ライブラリ ファイルは、アプリケーション サーバからサービスを受けます。 したがって、ライブラリの改訂版をロードできるように、ページ キャッシングを無効にする必要があります。

                                                      アーキテクチャ/ISF スクリプトの保存

                                                      Service Designer では、JavaScript 関数をスクリプト(リポジトリ内)またはライブラリ(ファイル システム上の外部ファイルとして)に保存できます。

                                                      ライブラリを使用する利点

                                                      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 関数によって使用される量は、他のコンポーネントで使用される量と比較して少量であるため、特に実際の利点はありません。

                                                      推奨される命名基準とコーディング基準

                                                      組織が JavaScript のコーディング基準を開発している場合、命名基準とフォーマット設定基準を使用する必要があります。 一般に、ISF のサポートのために記述されるスクリプトはあまり長くも複雑でもありませんが、命名基準およびフォーマット設定基準を適用すると、プログラマが他人のコードを読みやすくなり、理解しやすくなります。

                                                      JavaScript では、大文字と小文字が区別されるため、命名基準では、オブジェクト名での大文字と小文字の使用方法を指定する必要があります。

                                                      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 文字以内にしてください。

                                                      ISF 固有のベスト プラクティス

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

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

                                                      Javascript の作成

                                                      サービス フォームは、Service Designer にインタラクティブに入力する指定に従って自動的に生成されます。 ただし、特定のページ(複数ページ含む)でライブラリを含めるための HTML タグや、JavaScript の一部をページに埋め込む特定のイベントに割り当てるための HTML タグは手動で作成します。 スクリプトを使用して、サービス フォームを含む生成された HTML ページにライブラリをインクルードする方法を指定します。また、[アクティブフォームの動作(Active Form Behavior)] タブを使用して、どのスクリプトが特定のイベントに対するイベント ハンドラであるかをアプリケーションに指示します。 Service Catalog の外部で作業して、ライブラリ内のコードを維持する必要があります。

                                                      ライブラリの作成

                                                      [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)] チェック ボックスを介したライブラリのロード

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

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


                                                      (注)  


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

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

                                                      カスタム JavaScript 関数の書き込み

                                                      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』の指示に従ってブラウザ キャッシュ バージョンを追加します。

                                                      最適なサービス フォームの設計に関するガイドライン

                                                      Service Catalog を使用すると、サービス フォームをすばやく簡単に作成できます。 以下は、最適なサービス フォームを設計するため一般的なガイドラインと原則です。

                                                      • JavaScript コードディクショナリ固有あるあります。 コードの各機能がスタンドアロンであり、他の機能またはディクショナリに依存していないことを確認します。 これにより、新しいディクショナリが追加されたり既存のディクショナリが削除されてもコードの機能が保証されます。 たとえば、特定のサービスで使用されている 2 つのディクショナリに、onLoad イベントで実行する必要のあるコードが存在すると仮定します。 一体となった大きな関数を 1 つ記述するよりも、次のように、ディクショナリに固有の関数を 2 つ記述して、それらをライブラリに配置し、スクリプトとして定義され、onLoad イベントとしてフォームにアタッチされたラッパー関数からそれらを呼び出します。
                                                      Common_Service_onLoad () { IT_Dictionary1_onLoad(); IT_Dictionary2_onLoad();}
                                                      
                                                      • サービス依存しないコード作成します。 1 つのサービスでコードをテストするだけで、そのコードを使用するすべてのサービスが検証されます。 前の例のコードは、サービスに依存しません。 Common_Service_onLoad() 関数は、一方または両方のディクショナリが欠落しているサービスで実行すると失敗します。 しかし、これは簡単に修正できます。
                                                      Common_Service_onLoad () { if (serviceForm.ITDictionary1 !- undefined) {    IT_Dictionary1_onLoad();  }  if (serviceForm.ITDictionary2 !- undefined) {  IT_Dictionary2_onLoad();}
                                                      

                                                      上記のコードで、ディクショナリに固有のコードを適用する前に、サービスにディクショナリが存在するかテストしているように、フィールドに固有のコードを適用する前に、特定のフィールドが存在するかテストする必要がある場合があります。 ベスト プラクティスは、ディクショナリを 1 つのアクティブ フォーム コンポーネントだけで使用することです。しかし、サービスに固有のルールは、ディクショナリの外観に影響を与える可能性があります。 たとえば、サービスを要求する個人に対する上司情報の表示は、上司の承認が必要なサービスに対してのみ必要です。 したがって、上司に関連するフィールドを操作するコードを、次のようなコード ブロックに含める必要があります。

                                                      FirstApprover_onLoad () {  if (serviceForm.FirstApprover.SupervisorName !- undefined) {//    code goes here;  }}
                                                      

                                                      フィールドはフォーム内で使用できますが、前に実行されたルールまたは ISF コードによっては、非表示になる場合があります。 このような場合には、次のようなコードがより適切であり、またより堅牢です。

                                                      if (serviceForm.FirstApprover.SupervisorName !- undefined) { if (serviceForm.FirstApprover.SupervisorName.isVisible()) {// code goes here; }

                                                      • ブラウザ セッションより少なデータします。フォームをロードするときにフォームのパフォーマンスを向上させるには、より少ないデータをブラウザ セッションに送信する必要があります。 以前のリリースの Service Catalog では、操作が必要なディクショナリ フィールドは、ブラウザに送信して操作する必要がありました。 サーバ側のイベントを使用して、より少ないデータがブラウザに送信されるように、また、サーバ側の実行の制御下でセンシティブ データを保持し、その結果傍受されないように、ディクショナリ内のデータを操作できます。 サーバ側データ取得ルールを参照してください。 より少ないデータを送信ために、次を行うことができます。
                                                        • 少なくともオーダー時以外にブラウザ セッションにロードする必要がないグループ フィールドは、1 つ以上の「非ロード」ディクショナリにグループ化する必要があります。 「非ロード」ディクショナリの一般的な例としては、パラメータをオーケストレーション エージェントに提供するディクショナリがあります。 オーケストレータは通常、ユーザがフォームで確認できるデータより多くのデータを必要とします。 このデータは通常、ユーザが誰か、ユーザのロールは何か、ユーザの OU メンバーシップは何かなどを判断する条件付きルールまたはデータ取得ルールを通して取得されます。これらはすべて、フォームがブラウザにロードされる前(ロード前イベント中)、またはユーザが [送信(Submit)] ボタンをクリックした際(送信後イベント中)のいずれかが、抽出する最適なタイミングとなります。

                                                      送信後イベントが発生するまで設定されている値を確認できないため、「非ロード」のディクショナリで動作するルールの効果を確認するには、通常よりも多くのテストを必要とします。 したがって、「非ロード」のディクショナリの使用には通常、フォームで定義されたすべてのディクショナリを確認できるサービス ディクショナリの管理権限を持つユーザとして、後続の時点(たとえば、サービス グループの承認またはサービスの提供)でフォームを確認することが含まれます。

                                                      • ロー中イベントではなローイベン使用します。 一般に、条件付きルールとデータ取得ルールは、ブラウザに存在するオブジェクトに対してアクションを実行します。 したがって、ロード前イベントに関連付けられている条件付きルール「フィールドの非表示」の場合、実際には非表示にされるフィールドはありません。これは、ロード前イベント中は非表示にするフィールドがまだ存在しないためです。 前に「非ロード」のディクショナリで説明したように、この一般的なルールには、注目すべき例外があります。

                                                      値の設定条件付きルールのアクション、またはデータ取得ルールのいずれかを通して、ブラウザにロードされていないフィールドの値を操作できます。

                                                      条件付きルールとデータ取得ルールの機能は非常に柔軟であり、複数のターゲットに複数のルールのアクションを組み合わせること、また任意の 1 つのルールを複数のイベントに関連付けることができます。 ターゲットにアクセスできないアクション(たとえば、実際にはサービス フォームに存在しないフィールドでの値の設定アクション)は、「メッセージを出力せずに失敗」するか、または効力がないと考えられます。 一連のアクション(たとえば、いくつかのフィールドの非表示化、他のフィールドの必須化、アラート メッセージのポップアップ、さらに値の設定の実行)を実行する条件付きルールがある場合、ブラウザで、そのほとんどのアクションの実行を確認できます。 ただし、ターゲット フィールドが現在非表示になっているか、またはブラウザ内に存在しないために、値の設定アクションの実行がブラウザに表示されない可能性があります。 条件付きルールのフレームワークでは、そのようなルールも作成できますが、実行できないアクションは、単に無視されます。

                                                      これらの動作については、ルールを構築する際に、条件付きルールとデータ取得ルールのウィザードで詳しく説明されます。 各ステップに組み込まれているヘルプ テキストには、サーバ側イベントで特定のアクションを使用する際に生じる制限が説明されています。

                                                      • サーバ側イベントでは、データベースに直接データを書き込むことができます(具体的には、要求エントリごとにデータベースに格納される WDDX データ)。 特に、送信後イベントは、ブラウザでのアクションによって収集または取得したデータをデータベースに書き込みます。

                                                      ロード前イベントと送信後イベントの重要な違いは、ロード前イベントがデータベースに書き込むことができるのは、要求データがすでにデータベースに存在する場合に限られるという点です。 言いかえれば、ユーザがまだ [発注(Order)] ボタンまたは [追加と確認(Add & Review)] ボタンをクリックしていない場合、要求に対するデータがデータベースに存在しないため、ロード前ルールで操作される対象はありません。 ロード前イベントでは表示可能な値を変更できますが、その値をデータベースに保持しません。 送信後イベントは値を保持します。

                                                      • サーバ側のイベントによって、サーバによってこれから保護されるサービス フォームの一部であるデータの操作に対し大きな柔軟性が提供されます。 これは、「非ロード」のディクショナリがデータベースに格納されることで、サーバ側ルールによってアクセス可能になったためです。 ブラウザ側ルールはフォーム上で JavaScript として生成されますが、これらのルールと同等のサーバ側ルールは Java コードとして生成されます。つまり、2 つの異なる表現でルールを生成できるということです。 ISF フレームワーク(インタラクティブ サービス フォーム(ISF)API の概要で説明)を使用すると、フォーム データと外観に対してより複雑な操作を行う JavaScript を記述できます。 この JavaScript は、ブラウザでのみ実行できます。 したがって、作成した ISF 関数は、サーバ側イベントに関連付けることはできません。
                                                      • この [サーバ側でのみ編集可能(Editable on server-side only)] オプションは、入力タイプが読み取り専用または非表示に定義された任意のフィールドの [HTML表現(HTML Representation)] タブで使用可能で、競合することがある要件を満たすために役立ちます。まず、要求側ユーザに役立つデータを表示したり、ビジネス ロジックを適用する「非表示変数」をフォームで使用します。次に、データをユーザによる介入(悪意のあるアクティビティなど)から完全に保護します。

                                                      このフラグは、一般に次の 2 つの場合に使用します。

                                                        • ディクショナリ モジュール内に作成可能な個人ベースのディクショナリである「テンプレート ディクショナリ」
                                                        • ディクショナリ モジュール内に構造が自動的に作成されるサービス項目ベースのディクショナリ

                                                      この 2 つのディクショナリは、「自動入力」動作を実行する点で類似しています。 個人ベースのディクショナリでは、フォーム ユーザが個人を選択([人を選択します(Select Person)] コントロールを使用)します。選択された個人の詳細は、フォームに自動的に表示されます。 サービス項目ベースのディクショナリでは、フォーム ユーザは、所有する、またはアクセス権を持つ特定のサービス項目を選択できます。そのサービス項目インスタンスの属性値は、自動的に表示されます。

                                                      これは、読み取り専用のフィールド(つまり、[HTML表現(HTML Representation)] タブで入力タイプが「読み取り専用」として設定されたフィールド)として自動的に入力される大部分の属性(またはすべての属性)を定義する一般的なサービス設計技法です。 たとえば、ユーザ ベースに同じ名前の複数の人物を格納するための十分なスペースがある場合は、これらの人物の電子メール アドレスなどの属性を使用してフォーム ユーザを区別し、目的の個人を正しく選択できます。 ここでは、フォーム ユーザが、選択したユーザの電子メール アドレスを更新することは想定していません。 一方、フォーム ユーザはこの人物を良く知っており、その人物がディレクトリ統合を通して取得した卓上電話番号ではなく、携帯電話だけを使用していることを知っているかもしれません。 この場合は、[勤務先電話(Work Phone)] フィールドを読み取り専用ではなく、編集可能にして、少なくとも要求を処理するサービス提供担当者が、選択した個人に到達するために最も信頼できる方法を確保します。

                                                      [サーバ側でのみ編集可能(Editable on server-side only)] チェック ボックスを使用すると、入力タイプに読み取り専用または非表示としてマークを付けたフィールドがサーバによって完全に制御され、ブラウザ セッションでこれらの値を操作しても、Service Catalog データベースに存在するデータが優先され、操作が破棄されます。 実際、データベース内に存在するデータを上書きする唯一のメカニズムは、サーバ側イベント中に実行するルール(条件付きルールまたはデータ取得ルールのいずれか)であり、この場合はルールが実際にデータベース値を更新します。 (個人ベースのディクショナリの場合、DirPerson 内の個人レコードは更新されませんが、データベースに格納されている、要求エントリに対する WDDX データは更新されます)。

                                                      言いかえれば、サービス設計者は、サーバ側イベント中に実行されたルールを通してのみ、[サーバ側でのみ編集可能(Editable on server-side only)] としてマーク付けされているフィールドの値を操作できます。 サービス設計者は、これら「保護された」フィールドを使用するには、[サーバ側でのみ編集可能(Editable on server-side only)] フラグのチェックをオンにするだけでよいと考える可能性があるため、これは考慮すべき重要な要因です。 データベースから返される値を操作する理由がない場合は、チェックをオンにするだけで十分です。 しかし、フォーム ユーザが行った選択に応じてこれらの値を設定するようにビジネス ロジックで要求されている場合、条件付きルール(値の設定アクションの場合)またはデータ取得ルール(クエリからのデータ提供の場合)をサーバ側イベントに必ず関連付ける必要があります。

                                                      • 名前付け規則:表記上はまったく問題ありませんが、ディクショナリ、フォーム、およびフィールドには同じ名前を付けないでください。 同じ名前を付けると、非常にわかりにくくなる場合があります。 ディクショナリはプレフィックス表記法を使用して、その使用方法と、場合によっては格納されているディクショナリ グループを示すのが理想的です。 たとえば、「Reason」ディクショナリには、かなり汎用的な響きがあり、多くのフォームで使用されているように思われます。 したがって、「Common」などの名前が付けられたディクショナリ グループに配置して、ディクショナリ名にこのディクショナリ グループを示すコードのプレフィックスを付ける(たとえば、CMN_Reason)と理解しやすくなります。 ディクショナリ グループは、サービス固有のディクショナリが使用されているサービス グループ、または場合によっては、ディクショナリおよびサービスを開発している会社の部門や部署を反映している場合があります。

                                                      また、容易に理解できるフォームの表記も必要です。 これは、同じディクショナリまたはディクショナリのグループを使用している複数のフォームを区別する必要がある場合に特に重要です。

                                                      • フォーム/ディクショナリ関係:1 つのフォームにはディクショナリが 1 つ必要です。 次のような場合には、複数のディクショナリを同じフォームに含める必要があります。
                                                        • これらのディクショナリがすべて同じサービスで必要とされる場合。
                                                        • ディクショナリが表示される順序がすべてのサービスで同じ場合。
                                                        • このフォームのディクショナリ間で、これ以上表示するディクショナリがない場合。 サービス フォームでは、1 つのフォーム コンポーネント内のすべてのディクショナリが、そのコンポーネントで指定された順序で表示されます。そして、そのサービスに含まれている次のフォーム コンポーネントのディクショナリが、指定された順序で表示されます。以下同様です。

                                                      次に、例を示します。

                                                      • 施設部門に対して開発されたサービスのグループは、カスタマーの役職や部門に基づき、最大 3 人の承認者によって構成されている承認のチェーンがあると想定します。 この場合、Facilities_Approval フォームは、FirstApprover、SecondApprover、および ThirdApprover の 3 つのディクショナリを含む必要があり、また 3 つの承認うち、実際に収集が必要な承認の数を判断するルールを含む必要があります。
                                                      • 施設部門に対して開発された大部分のサービスでは、最大 3 つの標準的な承認を必要としますが、さらに高価なサービスには VP レベルの追加の承認者を必要とするものと想定します。 次の 2 つの対処法があります。

                                                      1 つのフォーム(One Form)

                                                      FirstApprover、SecondApprover、および ThirdApprover に加えて、VP Approver ディクショナリが含まれるように Facilities_Approval フォームを修正し、その 1 つのサービスに対してのみ、VPApprover ディクショナリを表示および処理する追加のルールまたはルール群を記述します。

                                                      複数のフォーム(Multiple Forms)

                                                      VPApprover ディクショナリを含む別のフォーム Facilities_VP_Approval を作成し、FirstApprover ディクショナリ、SecondApprover ディクショナリ、および ThirdApprover ディクショナリの処理に必要な HTML、アクセス コントロール、およびルールを複製します。

                                                      ほとんどの場合、最初のソリューション(わずかに複雑なフォーム)を優先する必要があります。 複数のフォームで、3 つのディクショナリおよびそれらに関連付けられたルールを設定する作業を重複して行う必要はありません。 これらのディクショナリまたはそれらのルールを変更する必要がある場合、それらを変更する場所は 1 箇所のみです。 2 番目のソリューション(部分的に冗長な 2 つのフォーム)は、ディクショナリを追加することにより、他方のディクショナリの表示または処理方法も変更される場合のみ使用を考慮する必要があります。

                                                      • 同じィクショナリ対してるレンダリング:フォームが使用されるサービスに基づいて、フォームの動作と外観が大幅に変わる必要があるとしたらどうでしょうか。 さまざまなシナリオを選択できます。 次に記載された条件に基づいて優先されるシナリオを決定できるのは、サービス設計者に限られます。 たとえば、実質的にすべてのサービスに、「Reason」ディクショナリが含まれている必要があります。 しかし、フィールド ラベルは、「Reason」、「Justification」、または「Explanation」の場合があります。 さらに、フィールドに関連付けられたヘルプ テキストは、サービスまたはサービスのグループごとに大幅に異なる必要があります。 この場合、ディクショナリは単純で容易に設定できるため、判断は容易です。ディクショナリのレンダリングごとに別々のフォームを作成し、対応するサービスに適切なフォームを含めます。

                                                      しかし、サービスごとにカスタマイズの必要な単一または複数のフィールドが、潜在的に複雑なルールを持つ大きなディクショナリの一部の場合はどのようになるでしょうか。 ここでも、上述と同じ 2 つのオプション(1 つのフォームまたは複数のフォーム)を選択できます。 それでも、次の対応を試してください。

                                                      1 つのフォーム(One Form)

                                                      フォームを 1 つ作成し、ISF 関数を使用してその外観をカスタマイズします。

                                                      複数のフォーム(Multiple Forms)

                                                      ディクショナリのレンダリングごとに異なるフォームを作成します。

                                                      [1つのフォーム(One-Form)] オプションは、条件付きルールを使用してディクショナリの外観をカスタマイズできないという事実によって複雑になっています。条件付きルールは、フィールドの外観と動作のみを変更し、フィールドのラベルやヘルプ テキストの内容は変更しません。 [複数のフォーム(Multiple-Forms)] オプションには、前記と同様の欠点があります。事前にフォームの作成作業を行う必要があり、またルールを維持するメンテナンス作業を複数の場所で行う必要があります。

                                                      次の 2 つの追加のオプションを選択できます。

                                                        • 要件を変更します。 サービスの要求時に情報を提供する方法に関し、ユーザに提供される情報が減少する可能性があるため、このオプションは推奨されていません。
                                                        • 問題があるフィールドを、複数のフォームで使用される個別のディクショナリに移動し、ディクショナリの残りの部分に対してはフォームを 1 つに維持します。 これは、そのフィールドが他のフィールドの間に表示されるのではなく、他のすべてのフィールドの前または後に表示できる場合にのみ可能です。
                                                      • ディクショナリ、フォーム、ルールおよびサービス:フォームは通常、ディクショナリのセットおよびルールのセットから構成されます。
                                                        • ルールは、同じフォーム内のディクショナリ(およびそれらのフィールド)だけでなく、他のフォーム内のディクショナリにも影響を与える可能性があります。
                                                        • 特定のサービスのコンテキストでルールを徹底的にテストし、参照されるすべてのディクショナリがそのサービスに含まれるフォーム内に存在することを確認することが非常に重要です。 ベスト プラクティス レポートには「サービス内のディクショナリ」レポートが含まれます。これを使用すると、このテストの実行、および提案された変更がディクショナリまたはルールに与える潜在的な効果を調べるための影響分析が容易になります。

                                                      また、特定のサービスに適用されるルールのみが含まれるように Form 2 を構成する場合にも最適です。 多くのサービスは、Form 1 のみを含むことができますが、追加の要件付きサービスのみ Form 2 を含みます。 これにより、Form 2 のルールに必要な条件が大幅に簡素化(場合によっては不要化)され、適切なサービスに対してのみ実行されることが保証されます。

                                                      また、サービス名(変更される可能性のあるテキスト要素)をテストする条件付きルールを記述する必要もなくなります。 影響を受けるサービス内に、影響を受けるディクショナリ持つフォームに続いて、順番にルール専用フォームを含めることのみ必要となります。 ルールは、フォームがサービスに含まれる順序に従って、次にルールがフォーム内に配置される順序に従って実行されます。

                                                      • 疎結されルールおよびディクショナリと 合されたールよびィクショナリルールとそのルールが影響を与え、参照するディクショナリが同じ AFC 内にある場合、そのルールとディクショナリは「密結合」されているといいます。 別のフォーム内のディクショナリの外観に影響を与えるルールを使用した上記の例では、ルールとディクショナリは「疎結合」されています。 一般に、両方のフォームが同じサービスに含まれる場合、ルールは、任意のフォーム内のディクショナリに影響を与えることができます。 ただし、疎結合されたルールとディクショナリには、1 つ重要な制限事項があります。つまり、1 つのフォーム内で定義されたルールは、別のフォーム内のディクショナリのフィールドにアタッチされたフィールド レベル イベントによってトリガーすることができません。 したがって、疎結合されたルールは、通常、フォームがロードまたは送信されたときに、フォーム レベル イベントによってトリガーする必要があります。
                                                      • ルール、ISF および要求ライフ サイクル:要求が送信されると、ディクショナリのすべての定義、HTML 表現、アクセス制御、およびそのサービスのタスク計画が、要求データとともに保存(圧縮形式)されます。 これにより、処理中の要求のサービス フォームの動作または外観に影響を与えるフォームの定義を後から変更することなく、承認時点と提供時点を通して要求を処理できます。

                                                      ディクショナリを変更すると、そのディクショナリを使用するすべてのフォームが自動的に変更を継承します。また、それらのフォームを使用するすべてのサービスも変更を継承します。 保存されているが送信されていない、変更されたサービスに対するすべての要求は、古い要求としてマーク付けされます。 要求をキャンセルするかサービスを削除し、それを読み込み、サービス フォームにデータを入力する必要があります。 送信された要求は、ディクショナリまたはアクティブ フォーム コンポーネントへの変更によって影響されません。

                                                      ただし、ルールと ISF 関数(スクリプトまたは外部のライブラリにある)は、サービス フォームが My Services または Service Manager に表示されると、常に動的にロードされます。 したがって、現在のバージョンのルール/コードが、すでにフォーム上に存在しないフィールドを参照しないこと、または逆に、もう使用されていない前バージョンのフォーム上のフィールドは、関連する関数を持つことができることを確認する必要があります。 前に説明したように、この柔軟性は、ISF を介してディクショナリまたはフィールドを操作する前に、ディクショナリまたはフィールドが存在することを常に確認することによって容易に実現できます。 必要に応じて、異なるバージョンのライブラリを新しいバージョンのフォームにアタッチできます。これにより、たとえば、関数の名前を変更することなく、改訂された要件に準拠してその内容を更新できます。

                                                      • ディクショナリまたはアクティブ フォーム コンポーネント変更:ディクショナリ内のフィールドの定義を変更すると、すべてのアクティブ フォーム コンポーネントがその変更を反映します。 同様に、アクティブ フォーム コンポーネント定義の任意の側面を変更すると、その変更はそのフォームを使用するすべてのサービス定義に反映されます。 条件付きルールに関連付けられたディクショナリやディクショナリ フィールド、またはデータ取得ルールをトリガーするディクショナリやディクショナリ フィールドを削除/変更することはできません。まず、関連付けを削除する必要があります。 この検査は、JavaScript 関数に対しては実行されません。 フォームを変更するたびに、そのフォームを組み込むすべてのサービス定義のバージョン番号が、アプリケーションによって自動的に更新されます。 フォームが多数のサービス内で使用されている場合、このような変更の保存にわずかな遅延が生じる場合があります。 また、Requisition API(RAPI)SubmitRequest 操作では、指定するサービスのバージョン番号が必要となるため、サービスをオーダーするために実装されたすべての RAPI プログラムに影響を与える場合があります。
                                                      • SQL エントリ データ取得ルールのコーディングSQL に詳しくない場合は、SQL エントリ データ取得ルールのコーディングが若干難しいかもしれません。 SQL に詳しくなる「秘訣」は、データベース テーブル ルックアップとしてより単純なバージョンのルールの設定から始めることです。 ルールを保存した後、生成した SQL がルールの概要に表示されます。 SQL ステートメントをコピーして SQL 入力データ取得ルールに貼り付け、必要に応じて修正できます。
                                                      • カスタマーおよび発信者の Lightweight 名前空間の使用:#Customer# および #Initiator# の Lightweight 名前空間は、Customer-Initiator フォーム コンポーネントで使用される Customer_Information ディクショナリおよび Initiator_Information ディクショナリのフィールドに、デフォルト値として自動的に提供されます。 ただし、これらの名前空間は、すべてのフォーム コンポーネントでデフォルト値として使用できます。

                                                      カスタマー ロケーションに関する情報を保持するディクショナリの設計には、この技法を使用できます。 カスタマー ロケーションに関するフィールドは、Customer_Information ディクショナリに含めることができます。 ただし、このようなフィールドを必要とするサービスは、サービスをカスタマーの物理的な場所に提供する必要がある場合などに限定されており、非常に少数です。 より柔軟な設計では、カスタマー ロケーションに対して個別のディクショナリ(およびフォーム コンポーネント)を設定し、このフォーム コンポーネントをカスタマー ロケーションに関係するサービスにのみ含めます。

                                                      複数の名前空間をデフォルト値として指定できます。 たとえば、#Customer.FirstName# #Customer.LastName# という式は、カスタマーの姓と名前を 1 つのスペースで区切って連結します。 この式は、個人ベースのディクショナリの最初のフィールドの外観を複製します。


                                                      (注)  


                                                      Lightweight 名前空間のグリッド ディクショナリ フィールドの使用は、現在サポートされていません。

                                                      サーバ側データ取得ルール

                                                      データ取得ルールのトリガー イベントはサーバ側またはブラウザ側の場合があります。 サーバ側を実行するフォーム レベルのイベントは 2 つあります。ロード前イベントと送信後イベントです。 サーバ上でのルールの実行にこれらのイベントを使用できます。 このようなルールは、一般に「サーバ側ルール」と呼ばれています。 ブラウザにロードされたサービス フォームに対して作用するクライアント側ルールとは異なり、サーバ側ルールは、サービス フォーム内の任意のディクショナリに対して作用します。 これには、ブラウザに送信されることのない(ユーザに表示権限も編集権限もない)ディクショナリが含まれます。

                                                      上記で説明した強力な動作は、1 つ以上のデータ取得ルールをロード前イベントにアタッチする場合、すべてのシステム時点で、これらのルールがすべてのディクショナリに対して効力を持つことを意味しています。 したがって、ディクショナリが読み取り専用になるときに、オーダー時点でデータを事前入力し、それ以降のサーバ側イベントでは無視されることを意図するフォーム ルールを作成する場合、サーバ側イベントに関連付けないでください。 フォームは、ロード前データの取得が完了した後でのみレンダリングされます。

                                                      これにより、ブラウザ上でのサービス フォームの初期レンダリングとクライアント側イベントの完了間の時間を短縮できるため、しばしばユーザ エクスペリエンスが向上します。 ただし、フォームのサイズと複雑性によっては、ロード前のデータ取得を最小化すると、フォーム ロードに関するエンド ユーザの認識が改善される場合があります。

                                                      フォーム ロード時にトリガーされるクライアント側ルールとは異なり、プリロード時にトリガーされるフォーム ルールは、検証エラーが発生した後にフォームが更新されるときに再実行されません。

                                                      Service Link を使用したサービス項目と標準のインポート

                                                      サービス項目または標準のインポートには Service Link エージェントを使用できます。 これで標準サービス要求にインポート ステップをタスクとして組み込むことができます。 このエージェントは、サービス項目および標準のインポート ファイルの形式に記載するようにフォーマットされたファイルをインポートし、ファイルからインポート ユーティリティで使用できるオプションと同じインポート オプションをサポートします。 メッセージは Service Link に「SIM インポート」メッセージ タイプとして記録されます。

                                                      Service Link の使用法の詳細については、『Cisco Prime Service Catalog Adapter Integration Guide』を参照してください。

                                                      Service Link エージェントをサービス項目または標準をインポートするように設定するには、次の手順を実行します。

                                                      1. Service Link で新しいエージェントを定義し、コンテキスト タイプに「サービス項目」タスクを指定します。 少なくとも、標準とサービス項目向けに別個のエージェントが必要です。
                                                      2. アウトバンド アダプタとして「Dummy」アダプタを指定し、インバンド アダプタとして「File」アダプタを指定します。 変換は不要です。
                                                      3. アウトバンド アダプタ プロパティとそのパラメータの設定を行うページをスキップします。
                                                      4. インバウンド アダプタ プロパティの場合、インポート ファイルの処理に使用するディレクトリ名を指定します。 ファイルは指定された「Input」ディレクトリに書き込まれる必要があります。
                                                      5. インバウンド パラメータの場合、4 つのパラメータを作成し、次の表で示すように、[ディクショナリ(Dictionary)] フィールドに適切な値を入力します (パラメータ値は大文字と小文字が区別されます)。
                                                      表 24 インバウンド パラメータとディクショナリ値の表

                                                      パラメータ名

                                                      有効な値

                                                      説明

                                                      ドメイン

                                                      SERVICE ITEM

                                                      STANDARD

                                                      インポート ファイルはサービス項目のデータまたは定義を含むことができます。

                                                      ImportDefinition

                                                      TRUE

                                                      FALSE

                                                      インポート ファイルの定義部分(ある場合)を処理する必要がある場合には True で、その他の場合は False です。

                                                      ImportData

                                                      TRUE

                                                      FALSE

                                                      インポート ファイルのデータ部分(ある場合)を処理する必要がある場合には True で、その他の場合は False です。

                                                      ConflictResolution

                                                      INSERT(挿入)

                                                      OVERWRITE

                                                      MERGE

                                                      入力ファイル内の新しいデータまたは定義を、現在 Service Catalog にあるデータまたは定義で調整する際のインポート プロセスの動作。

                                                      サービス項目および標準のインポート ファイルの形式

                                                      各インポート ファイルは、業界標準の CIM(共通情報モデル)互換フォーマット、バージョン 2.3.1 の XML ファイルです。 CIM はオブジェクト指向モデルに基づいており、統一モデリング言語(UML)から採用された技術を使用します。 Service Catalog で使用されるファイル形式を記述する文書型定義(DTD)は、アプリケーション サーバの RequestCenter.war\DTD にあります。

                                                      Service Catalog は、CIM で使用可能なエンティティのサブセットのみを認識します。 認識されないエンティティは、Service Catalog で無視されます。 Service Catalog の CIM の実装において:

                                                      • 各サービス項目または標準はクラスです。
                                                      • サービス項目に関する詳細(説明、表示名、割り当てられているグループ(分類))は、サービス項目の修飾子です。
                                                      • サービス項目に指定された属性は、サービス項目クラスのプロパティです。
                                                      • 各属性(プロパティ)には修飾子が付いています。 これらの修飾子は、個々の属性の詳細な設定(説明、キャプション、My Services から参照できるかどうか、属性がサービス項目定義で発生する順序)から構成されます。
                                                      • 各サービス項目には、多くのインスタンスが含まれていることがあります。 これらはそれぞれ 1 つのサービス項目インスタンスに対応します。
                                                      • サービス項目の各インスタンスには、サービス項目の属性ごとに 1 つのプロパティがあります。 インポート時に、サービス項目のサブスクリプション情報を構成する 3 つの属性(要求エントリ ID、カスタマー ログイン名、組織単位名)も含むことができます。 XML ファイル内の値は、サービス項目インスタンスの対応する属性またはサブスクリプション フィールドの値を更新します。

                                                      一般に、以前の説明がサービス項目と標準の両方に適用されます。 標準は、個々のユーザまたは組織単位自体によっては「所有」されず、したがってこれらにはサブスクリプション属性を設定できないことに注意してください。

                                                      サービス項目インポート ファイルの構文

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

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

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

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

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

                                                      表 25 サービス項目または標準のインポート ファイルを指定するための構文

                                                      SIImportSpec =

                                                      S<?xml version="1.0" encoding="utf-8"?>

                                                      <CIM CIMVERSION="" DTDVERSION="">

                                                      <DECLARATION>

                                                      <DECLGROUP>

                                                      SIClassDefinition

                                                      SIInstanceList

                                                      </DECLGROUP>

                                                      </DECLARATION>

                                                      </CIM>

                                                      SIClassDefinition =

                                                      <<VALUE.OBJECT>

                                                      SIClass

                                                      </VALUE.OBJECT>

                                                      SIClass =

                                                      <CLASS NAME="Service Item Name">

                                                      <QUALIFIER NAME="Description" TYPE="string">

                                                      <VALUE></VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME="Classification" TYPE="string">

                                                      <VALUE>Service Item Group</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME="DisplayName" TYPE="string">

                                                      <VALUE>SI Display Name</VALUE>

                                                      </QUALIFIER>

                                                      SIAttributeList

                                                      </CLASS>

                                                      SIAttributeList =

                                                      SIAttributeDefinition [SIAttributeDefinition]

                                                      SIAttributeDefinition =

                                                      <PROPERTY NAME="Name" TYPE="string">

                                                      <QUALIFIER NAME="Description" TYPE="string">

                                                      <VALUE>Description of the attribute</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME="Caption" TYPE="string">

                                                      <VALUE>Caption for the attribute</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME="IsVisible" TYPE="sint32">

                                                      <VALUE>1 if visible, 0 if not visible</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME="DisplayOrder" TYPE="sint32">

                                                      <VALUE>Sequence of the attribute</VALUE>

                                                      </QUALIFIER>

                                                      </PROPERTY>

                                                      SIInstanceList =

                                                      SIInstance [SIInstance]

                                                      SIInstance =

                                                      <VALUE.OBJECT>

                                                      <INSTANCE CLASSNAME="ClassName">

                                                      SIPropertyList

                                                      </INSTANCE>

                                                      </VALUE.OBJECT>

                                                      SIInstanceDataList=

                                                      SIInstanceData [SIInstanceData]

                                                      SIInstanceData=

                                                      <PROPERTY NAME="AttributeName" TYPE=SIDataType>

                                                      <VALUE>Attribute value</VALUE>

                                                      </PROPERTY>

                                                      オプションのサブスクリプション プロパティ:

                                                      <PROPERTY NAME="#RequisitionEntryID#" TYPE="sint32">

                                                      <VALUE>Requisition entry ID</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME="#LoginName#" TYPE="string">

                                                      <VALUE>Customer login name</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME="#OrganizationalUnitName#" TYPE="string">

                                                      <VALUE>Organizational unit name</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME="#AccountName#" TYPE="string">

                                                      <VALUE>account name</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME="#Operation#" TYPE="string">

                                                      <VALUE></VALUE>

                                                      </PROPERTY>

                                                      SIDataType =

                                                      {“char16” | “string” | “datetime” | “real64” | “sint32” | “sint64”}

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

                                                      表 26 Service Item Manager のデータ型からのインポート ファイルのデータ型

                                                      Service Item Manager のデータ型

                                                      インポート ファイルのデータ型

                                                      STRING(32)

                                                      char16

                                                      STRING(128)

                                                      <サポート外>

                                                      STRING(512)

                                                      string

                                                      INTEGER

                                                      sint32

                                                      LONGINTEGER

                                                      sint64

                                                      DOUBLEFLOAT

                                                      real64

                                                      MONEY

                                                      real64 を使用

                                                      DATETIME

                                                      Datetime(日付値には、yyyy-mm-dd hh:mm:ss フォーマットを使用します。例:2009-04-15 12:00:00)

                                                      インポートされたファイルのサービス項目のサブスクリプション処理ルール

                                                      内部サービス項目タスクと外部サービス項目タスクによって実行される作成操作と更新操作とは異なり、ファイルのインポート メカニズムによって処理される作成操作と更新操作はサービス要求の提供計画のコンテキスト外で発生します。 したがって、インポート プログラムは、インポート ファイルで提供される要求エントリ ID、カスタマー ログイン名、組織単位名の間の関係を検証しません。 これらが有効な ID または名前であるかぎり、入力が受け入れられます。

                                                      サブスクリプションの処理ルールの概要は次のとおりです。

                                                      • サービス項目インスタンスの作成時にサブスクリプション情報が提供されていない場合、その項目は未割り当てのままとなります。
                                                      • サービス項目インスタンスの作成時に [カスタマーログイン名(Customer Login Name)] プロパティのみが指定された場合、項目の組織単位のオーナーは、カスタマーのホーム組織単位に設定され、アカウントの所有権はホーム組織単位から取得したテナント アカウントが 1 つである場合はそれに設定されます。
                                                      • [カスタマーログイン名(Customer Login Name)] または [組織単位名(Organizational Unit name)]、または [アカウント名(Account name)] プロパティが指定された場合、値はサービス項目サブスクリプションを更新するために使用されます。 値がブランクの場合、対応するサブスクリプション フィールドがヌルに設定されます。 インポート ファイルにプロパティが存在しない場合、プロパティ値に変更/上書きが行われません。
                                                      • 要求エントリ ID がプロパティに提供されていると、対応する要求 ID がサービス項目に関連付けられ、My Services および Service Item Manager に表示されます。
                                                      • 一度要求エントリ ID がサービス項目に設定されると、これを変更したり、ヌルにリセットしたりすることはできません。

                                                      カスタマーと組織単位の割り当てで可能な組み合わせとその結果をサービス項目サブスクリプションの表にまとめます。

                                                      アカウント割り当ては、組織単位の割り当てと同様に機能し、置換は次の表に列挙されていません。

                                                      表 27 サービス項目サブスクリプションの表

                                                      サービス項目の作成時

                                                      XML 内のプロパティ

                                                      結果のサブスクリプション

                                                      ログイン名(Login Name)

                                                      OU 名

                                                      カスタマー

                                                      OU

                                                      なし

                                                      なし

                                                      NULL

                                                      NULL

                                                      なし

                                                      ブランクまたは無効な値

                                                      NULL

                                                      NULL

                                                      なし

                                                      有効な OU 名

                                                      NULL

                                                      提供された OU

                                                      ブランクまたは無効な値

                                                      なし

                                                      NULL

                                                      NULL

                                                      ブランクまたは無効な値

                                                      ブランクまたは無効な値

                                                      NULL

                                                      NULL

                                                      ブランクまたは無効な値

                                                      有効な OU 名

                                                      NULL

                                                      提供された OU

                                                      有効なカスタマー

                                                      なし

                                                      提供されたカスタマー

                                                      カスタマーのホーム OU

                                                      有効なカスタマー

                                                      値なし

                                                      提供されたカスタマー

                                                      NULL

                                                      有効なカスタマー

                                                      有効な OU 名

                                                      提供されたカスタマー

                                                      提供された OU

                                                      サービス項目の更新時

                                                      XML 内のプロパティ

                                                      結果のサブスクリプション

                                                      ログイン名(Login Name)

                                                      OU 名

                                                      カスタマー

                                                      OU

                                                      なし

                                                      なし

                                                      変更なし

                                                      変更なし

                                                      なし

                                                      ブランクまたは無効な値

                                                      変更なし

                                                      NULL

                                                      なし

                                                      有効な OU 名

                                                      変更なし

                                                      提供された OU

                                                      ブランクまたは無効な値

                                                      なし

                                                      NULL

                                                      変更なし

                                                      ブランクまたは無効な値

                                                      ブランクまたは無効な値

                                                      NULL

                                                      NULL

                                                      ブランクまたは無効な値

                                                      有効な OU 名

                                                      NULL

                                                      提供された OU

                                                      有効なカスタマー

                                                      なし

                                                      提供されたカスタマー

                                                      変更なし

                                                      有効なカスタマー

                                                      ブランクまたは無効な値

                                                      提供されたカスタマー

                                                      NULL

                                                      有効なカスタマー

                                                      有効な OU 名

                                                      提供されたカスタマー

                                                      提供された OU

                                                      例:サービス項目インポート ファイル

                                                      次の定義により「Desktop」サービス項目が作成されているとします。

                                                      図 11. Desktop サービス項目

                                                      このサービス項目のインポート ファイルは次の例のようになります。

                                                      表 28 サービス項目のインポート ファイルの例

                                                      XML の例

                                                      説明/使用方法

                                                      <?xml version=“1.0” encoding=“utf-8”?>

                                                      <CIM CIMVERSION=““ DTDVERSION=““>

                                                      <DECLARATION>

                                                      <DECLGROUP>

                                                      SI インポート仕様の開始。

                                                      < VALUE.OBJECT>

                                                      <CLASS NAME=“Desktop”>

                                                      <QUALIFIER NAME=“Description” TYPE=“string”>

                                                      <VALUE>Desktop Computer.</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“Classification” TYPE=“string”>

                                                      <VALUE>Hardware</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“DisplayName” TYPE=“string”>

                                                      <VALUE>Desktop Computer</VALUE>

                                                      </QUALIFIER>

                                                      SI のプロパティ:名前、説明、表示名、グループ(分類)。

                                                      <PROPERTY NAME=“Name” TYPE=“string”>

                                                      <QUALIFIER NAME=“Description” TYPE=“string”>

                                                      <VALUE>The name of the computer.</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“Caption” TYPE=“string”>

                                                      <VALUE>Name</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“IsVisible” TYPE=“sint32”>

                                                      <VALUE>1</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“DisplayOrder” TYPE=“sint32”>

                                                      <VALUE>1</VALUE>

                                                      </QUALIFIER>

                                                      </PROPERTY>

                                                      SI の Name 属性の定義。 Name 属性は、すべての SI に必要です。そのキャプションも「Name」である必要があります。

                                                      <PROPERTY NAME=“Brand” TYPE=“char16”>

                                                      <QUALIFIER NAME=“Description” TYPE=“string”>

                                                      <VALUE>Brand name of the computer.</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“Caption” TYPE=“string”>

                                                      <VALUE>Manufacturer</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“IsVisible” TYPE=“sint32”>

                                                      <VALUE>1</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“DisplayOrder” TYPE=“sint32”>

                                                      <VALUE>2</VALUE>

                                                      </QUALIFIER>

                                                      </PROPERTY>

                                                      SI の Brand 属性の定義。

                                                      <PROPERTY NAME=“Price” TYPE=“real64”>

                                                      <QUALIFIER NAME=“Description” TYPE=“string”>

                                                      <VALUE>MSRP</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“Caption” TYPE=“string”>

                                                      <VALUE>Unit Price</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“IsVisible” TYPE=“sint32”>

                                                      <VALUE>1</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“DisplayOrder” TYPE=“sint32”>

                                                      <VALUE>3</VALUE>

                                                      </QUALIFIER>

                                                      </PROPERTY>

                                                      SI の Price 属性の定義。

                                                      <PROPERTY NAME=“Memory” TYPE=“sint32”>

                                                      <QUALIFIER NAME=“Description” TYPE=“string”>

                                                      <VALUE>Amount of RAM in GB</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“Caption” TYPE=“string”>

                                                      <VALUE>Memory in GB</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“IsVisible” TYPE=“sint32”>

                                                      <VALUE>1</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“DisplayOrder” TYPE=“sint32”>

                                                      <VALUE>4</VALUE>

                                                      </QUALIFIER>

                                                      </PROPERTY>

                                                      SI の Memory 属性の定義。

                                                      < PROPERTY NAME=“ManufactureDate” TYPE=“datetime”>

                                                      <QUALIFIER NAME=“Description” TYPE=“string”>

                                                      <VALUE>Date of manufacture</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“Caption” TYPE=“string”>

                                                      <VALUE>Manufacture Date</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“IsVisible” TYPE=“sint32”>

                                                      <VALUE>1</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“DisplayOrder” TYPE=“sint32”>

                                                      <VALUE>5</VALUE>

                                                      </QUALIFIER>

                                                      </PROPERTY>

                                                      </CLASS>

                                                      </VALUE.OBJECT>

                                                      SI の ManufactureDate 属性の定義。

                                                      <VALUE.OBJECT>

                                                      <INSTANCE CLASSNAME=“Desktop”>

                                                      <PROPERTY NAME=“Name” TYPE=“string”>

                                                      <VALUE>Thinkpad T60</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME=“Brand” TYPE=“char16”>

                                                      <VALUE>LENOVO</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME=“Price” TYPE=“real64”>

                                                      <VALUE>899.99</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME=“Memory” TYPE=“sint32”>

                                                      <VALUE>3</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME=“ManufactureDate” TYPE=“datetime”>

                                                      <VALUE>2009-04-15 12:00:00</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME="#RequisitionEntryID#" TYPE="sint32">

                                                      <VALUE>10</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME="#LoginName#" TYPE="string">

                                                      <VALUE>jsmith</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME="#OrganizationalUnitName#" TYPE="string">

                                                      <VALUE>Finance</VALUE>

                                                      </PROPERTY>

                                                      </INSTANCE>

                                                      </VALUE.OBJECT>

                                                      デスクトップ SI の 1 つのインスタンス「Thinkpad T60」の場合

                                                      </DECLGROUP>

                                                      </DECLARATION>

                                                      </CIM>

                                                      SI インポート仕様の終わり。

                                                      例:標準的なインポート ファイルの例

                                                      「Projects」標準が次の定義で作成されていると仮定しています。

                                                      図 12. 標準的なインポート ファイルの例

                                                      Service Link のサービス項目タスクは、次のエージェント パラメータで定義されます(一般)。

                                                      • 送信プロパティ
                                                      • 受信プロパティ
                                                      • 送信要求パラメータ
                                                      • 受信応答パラメータ
                                                      • 内部パラメータ

                                                      この標準のインポート ファイルは次の例のようになります。

                                                      表 29 標準的なインポート ファイルの例

                                                      XML の例

                                                      説明/使用方法

                                                      <?xml version=“1.0” encoding=“utf-8”?>

                                                      <CIM CIMVERSION=““ DTDVERSION=““>

                                                      <DECLARATION>

                                                      <DECLGROUP>

                                                      標準インポート仕様の開始。

                                                      < VALUE.OBJECT>

                                                      <CLASS NAME=“Projects”>

                                                      <QUALIFIER NAME=“Description” TYPE=“string”>

                                                      <VALUE>Describe it here</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“Classification” TYPE=“string”>

                                                      <VALUE>My Standards</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“DisplayName” TYPE=“string”>

                                                      <VALUE>Projects</VALUE>

                                                      </QUALIFIER>

                                                      標準のプロパティ:名前、説明、表示名、グループ(分類)。

                                                      <PROPERTY NAME=“ProjectID” TYPE=“string”>

                                                      <QUALIFIER NAME=“Description” TYPE=“string”>

                                                      <VALUE>ID of the Project</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“Caption” TYPE=“string”>

                                                      <VALUE>Project ID</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“IsVisible” TYPE=“sint32”>

                                                      <VALUE>1</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“DisplayOrder” TYPE=“sint32”>

                                                      <VALUE>1</VALUE>

                                                      </QUALIFIER>

                                                      </PROPERTY>

                                                      標準の ProjectID 属性の定義。

                                                      <PROPERTY NAME=“ProjectName” TYPE=“string”>

                                                      <QUALIFIER NAME=“Description” TYPE=“string”>

                                                      <VALUE>Name of the project</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“Caption” TYPE=“string”>

                                                      <VALUE>Project Name</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“IsVisible” TYPE=“sint32”>

                                                      <VALUE>1</VALUE>

                                                      </QUALIFIER>

                                                      <QUALIFIER NAME=“DisplayOrder” TYPE=“sint32”>

                                                      <VALUE>2</VALUE>

                                                      </QUALIFIER>

                                                      </PROPERTY>

                                                      標準の ProjectName 属性の定義。

                                                      <VALUE.OBJECT>

                                                      <INSTANCE CLASSNAME=“Projects”>

                                                      <PROPERTY NAME=“ProjectID” TYPE=“string”>

                                                      <VALUE>001</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME=“ProjectName” TYPE=“string”>

                                                      <VALUE>Reporting System Upgrade</VALUE>

                                                      </PROPERTY>

                                                      </INSTANCE>

                                                      </VALUE.OBJECT>

                                                      Project 標準の最初のインスタンス。

                                                      < VALUE.OBJECT>

                                                      <INSTANCE CLASSNAME=“Projects”>

                                                      <PROPERTY NAME=“ProjectID” TYPE=“string”>

                                                      <VALUE>002</VALUE>

                                                      </PROPERTY>

                                                      <PROPERTY NAME=“ProjectName” TYPE=“string”>

                                                      <VALUE>Decision Support System Installation</VALUE>

                                                      </PROPERTY>

                                                      </INSTANCE>

                                                      </VALUE.OBJECT>

                                                      Project 標準の 2 番目のインスタンス。

                                                      </DECLGROUP>

                                                      </DECLARATION>

                                                      </CIM>

                                                      標準インポート仕様の終わり。

                                                      サービス項目インポート DTD

                                                      サービス項目または標準インポート ファイルに必要なフォーマットを記述している文書型定義(DTD)が RequestCenter.war\DTD にある Service Catalog アプリケーション サーバで使用できます。 DTD を次に示します。

                                                      <!ENTITY % CIMName "NAME           CDATA         #REQUIRED">
                                                      <!ENTITY % CIMType "TYPE (char16|string|sint32|sint64|datetime|real64)">
                                                      <!ENTITY % ClassName "CLASSNAME      CDATA         #REQUIRED">
                                                      <!ELEMENTCIM (DECLARATION)>
                                                      <!ATTLISTCIM
                                                      	CIMVERSION CDATA #REQUIRED
                                                      	DTDVERSION CDATA #REQUIRED
                                                      >
                                                      <!ELEMENTDECLARATION (DECLGROUP)+>
                                                      <!ELEMENTDECLGROUP (VALUE.OBJECT*)>
                                                      <!ELEMENTVALUE.OBJECT (CLASS | INSTANCE)>
                                                      <!ELEMENTCLASS (QUALIFIER*, PROPERTY*, METHOD*)>
                                                      <!ATTLISTCLASS
                                                      	%CIMName; 
                                                      >
                                                      <!ELEMENTQUALIFIER (VALUE?)>
                                                      <!ATTLISTQUALIFIER %CIMName;
                                                               %CIMType;              #REQUIRED
                                                      >
                                                      <!ELEMENTPROPERTY (QUALIFIER*, VALUE?)>
                                                      <!ATTLISTPROPERTY %CIMName;
                                                               %CIMType;              #REQUIRED
                                                      >
                                                      <!ELEMENTVALUE (#PCDATA)>
                                                      <!ELEMENTINSTANCE (QUALIFIER*, PROPERTY*)>
                                                      <!ATTLISTINSTANCE
                                                      	%ClassName; 
                                                      >
                                                      <!ELEMENTMETHOD (QUALIFIER*)>
                                                      <!ATTLISTMETHOD %CIMName;
                                                      >