この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
• 「概要」
• 「サービス フォーム パフォーマンスとセキュリティに関する考慮事項」
• 「ISF Application Programming Interface(API)」
• 「アクティブ フォーム コンポーネントの使用に関するベスト プラクティス」
• 「まとめ」
サービス フォーム とは、サービス要求を満たすために必要な情報を表示する、Request Center ユーザに提示される Web ページです。サービス フォームにより、カタログ カスタマーは、要求しているサービスに関する詳細な情報を入力できます。また、要求承認者、確認者、およびタスク実行者は、以前入力された情報を確認(修正する可能性もある)するとともに、要求を満たすために必要な詳細を追加できます。
サービス フォームは、サービス設計者によって設定される多数のコンポーネントで構成されています。これらのコンポーネントは、サービスの外観だけでなく、特定のイベントに対応する動作を定義します。イベントは、ユーザが開始(たとえば、オーダーするコンピュータの種類として「ラップトップ」を選択)するか、または要求ライフ サイクル(要求が送信されており、マネージャが承認する必要がある)の一部とすることができます。この章では、次のコンポーネントについて説明します。
• ディクショナリ :サービスを要求するために必要なデータ、およびそのサービス要求を満たすために必要なデータを保持するフィールドのグループ。
• 条件付きルール :要求の開始および実行中に発生するイベントに対応して、フォームの表示方法および動作方法を制御するルール。
• データ取得ルール :外部データソースからデータを取得できるようにするためのルールであり、サービス フォームに事前に情報を入力、ユーザのデータ入力に基づいて追加情報を取得、またはユーザのデータ入力を検証する目的で使用されます。
• フォーム :1 つ以上のディクショナリ、それらのディクショナリまたはディクショナリ内のフィールドに適用される任意のルール、および要求ライフ サイクル中にこれらのディクショナリとフィールドを Web ページに表示する方法のセット。これらの アクティブ フォーム コンポーネント は、サービス フォームを構築する構成要素となります。
• ISF ( 対話型サービス フォーム):プログラマが JavaScript 関数とライブラリを記述することにより、サービス フォームの対話性を向上させるための JavaScript API(アプリケーション プログラミング インターフェイス)。
フォーム ルールにより、サービス設計者は、コードを記述することなく、サービス フォームをリッチインターネットアプリケーション(RIA)にすることができます(RIA は、入力画面の終わりに [Submit] ボタンを押さなくても、ユーザ入力や画面の表示内容にアプリケーションが即座に応答することを意味する専門用語です)。このルールにより、設計者は、インタラクティブ ダイアログに入力し、ウィザードのセット内の手順に従うことで、ユーザが開始するイベントに対応してサービス フォームの外観や動作がどのように変化するか、宣言的に指定できます。
• オプション ボタン(たとえば、[Yes]/[No] の選択)に基づいて、フィールドを有効/無効または表示/非表示にする
• 別のフィールドの値に基づいて、または特定タスクの実行中や提供(実施)サイクル中は、フィールドを必須としてマークする
• ディクショナリ全体を表示/非表示にすることで、サービスの提供期間内の各種タスクに対して、ユーザ エクスペリエンスをカスタマイズする
データ取得ルールは、サービス フォームとリレーショナル データベースに格納されている情報間にオンラインのリアルタイム インターフェイスを提供します。これらのルールにより、このようなデータをディクショナリ フィールドに表示すること、またはサービス要求元または実施者が入力した項目が正しいことを判断するために問い合わせることができます。データ取得ルールの共通の使用方法には、次のものが含まれます。
• Configuration Management Database(CMDB)、または ERP、または HR システムなど、他のアプリケーションで維持されている情報を、フォーム データに事前に入力する
• 動的なドリル ダウンを提供して、以前入力した項目、または別のリストから選択した項目に基づき、ドロップダウン リストに表示される項目が動的に変化するようにする
設計者は、特定のタスクが開始または完了したときに、名前空間を使用してユーザに電子メールを送信します。または、名前空間を使用して、特定のタスクまたは承認を実行すべきか動的に判断します。名前空間については、「名前空間」で詳しく説明します。
アクティブ フォーム ルールには、使用または評価するフィールド値に動的にアクセスするため、名前空間に相当するものが必要です。たとえば、ユーザが前のフィールドで「Other」と入力した場合、サービスは追加のディクショナリまたはフィールドを表示する必要があります。また、サービス提供の有効な場所を表示するためのドロップダウン リストを作成する条件として、現在のカスタマー組織の使用が必要になることがあります。あるいは、カスタマーおよび発信者データに対するデフォルト値を提供する必要があります。
Lightweight 名前空間はこれらの機能を提供します。これらの機能は、ルール内では、サービス フォームにアクセス可能な情報だけ(サービスの提供計画やタスク実行者に関する詳細などではありません)を使用できるため「軽量」です。
この章は、基本的には、要求履行のためにサービス フォームの外観と動作を設計するサービス設計者を対象としています。フォームの外観と承認/確認サイクルを制御するすべての仕様、およびフォームの動作を決定する大部分のルールは、「宣言的」に定義されます。つまり、プログラミング言語でコマンドを記述する必要はなく、設計者は、単に一連のダイアログに入力するか、またはウィザードの手順に従って目的とする結果を指定できます。
アクティブ フォーム コンポーネントを定義するいくつかの側面では、プログラミングの専門知識が必要になる場合があります。特に次のようなものです。
• 設計者は SQL を記述することにより、データ取得ルール内でデータの検証や取得のために実行される複雑なクエリーを指定できます。これは、より単純なクエリーを自動的に生成する Request Center の機能を補完します。
• 条件付きルールで提供される宣言型機能を補完するために、JavaScript のコーディングが必要になる場合があります。たとえば、複雑な計算、相互依存性、または手続き型コード、またはグリッド ディクショナリでのデータの操作は、ISF を通して挿入できます。さらに、ユーザは、JavaScript 関数を実行するコントロール(ボタン)をフォームに追加できます。
この章では、アクティブ フォーム コンポーネントを使用してサービス フォームのすぐに使用可能な機能を向上させるためのガイドラインと手順について説明します。この章を読むと、要件に合わせてサービス フォームをカスタマイズする方法、およびこのカスタマイズを実行するために推奨されるいくつかの「ベスト プラクティス」を理解できます。
• 「サービス フォームのフレームワーク」の項では、アクティブ フォーム コンポーネントを使用するサービス設計の概要、およびコンポーネントを使用してサービス フォームをさらに使いやすくするためのガイドラインと、メンテナンスの時間を短縮し、コストを抑えるガイドラインについて説明します。
• 「ISF Application Programming Interface(API)」の項では、ISF での作業のために Service Designer で使用できる画面とオプションの使用方法について、詳細な手順を示します。ISF の機能には、Service Designer で使用できるすべての機能と、それらの機能をサービス フォームに統合する方法が含まれています。
• 「ISF コーディングとベスト プラクティス」の項では、ISF の一般的な開発サイクルを確認し、ISF コーディングのいくつかの手順について検討します。
• 「アクティブ フォーム コンポーネントの使用に関するベスト プラクティス」の項には、そのタイトルが示す内容が記載されています。ルールと ISF コードの例を示し、頻繁に発生する使用例において、各々の使用タイミングと使用方法を説明します。
• 「まとめ」の項では、最も低い保守コストでフォームとサービスを実装するとともに、目的とする機能を提供するための設計指針を説明します。
• 「サーバ側の関連付けられたコントロール」の項では、フォーム ベースデータとのやり取りを行うサーバ側コードを実装するためのオプションについて検討します。
• この章では、Service Designer の詳細な操作については説明しません。その説明では、読者が Service Designer に精通していること、および各画面、タブ、ダイアログボックスをナビゲートできることを想定しています。この情報は、オンライン ヘルプで提供されます。
• これは、JavaScript のガイドではありません。入門では、JavaScript 手法についていくつか触れていますが、そこでは、読者がすでに Web ページを制御する JavaScript および Dynamic HTML(DHTML)に精通していることを想定しています。
すべてのアクティブ フォーム コンポーネントは、サービス フォームのコンテキスト内で動作します。サービス フォームは、Service Designer で定義されたフォーム、ディクショナリ、フィールド仕様に基づいて動的に生成された要素が主な構成要素となっている HTML ページです。また、サービス フォームは、ISF API をサポートしています。そこにはグローバル変数、JavaScript オブジェクト モデル、および JavaScript 関数のセットが含まれており、プログラマは、それらを起動して、自分のサービス フォームを目的に合わせてカスタマイズできます。
サービス フォームは、Service Portal でサービス要求を入力および追跡するためのインタラクティブな Web ページです。サービス設計者は、Service Designer を使用してコンポーネントと動作を指定することにより、サービス フォームを設定します。サービス フォームの基本的な外観と動作は、サービス定義で使用される「アクティブ フォーム」の一部として指定されるディクショナリとフィールドによって定義され、また要求ライフ サイクルの時系列的な「ある時点」でディクショナリを表示または編集するために、識別されたユーザまたはユーザのグループに付与された権限によって定義されます。
サービス フォームのアーキテクチャと機能を理解するには、Service Designer によって提供されるアクティブ フォーム コンポーネントと宣言型設計機能を理解することが非常に重要です。したがって、サービスを構成する設計コンポーネントを確認することが有効です。
ディクショナリは、サービス フォームの構成要素です。ディクショナリは、フィールドをグループ化したものであり、ユーザはそれらの入力要素を通してサービス要求のデータを入力し、以前に入力または提供されたデータが自動的に表示されます。
ディクショナリは、Service Designer の Dictionaries コンポーネントを通して定義およびメンテナンスされます。左側から以前定義されたディクショナリを選択するか、または [New] > [New Dictionary] を選択して新しいディクショナリを作成します。ディクショナリのタイプを指定することから開始します。
ディクショナリには外部と内部の 2 つの主なカテゴリがあり、ディクショナリ内のデータを保存する方法を示しています。内部ディクショナリは、Request Center によって、その内部で管理されるデータ構造を表しています。一方、外部ディクショナリは、Request Center 要求の外部にある既存または新規のデータ テーブルを使用します。必要なデータベース管理が最小になること、および外部ディクショナリでは使用できない追加機能が含まれることから、一般には内部ディクショナリが推奨されます。
内部ディクショナリは、その定義方法によってさらに分類されます。
• [Free Form] リンクをクリックしてフリー フォーム ディクショナリを作成します。次に、ディクショナリ名、キャプション、その他の属性を指定し、目的とするフィールドの追加を開始します(「フリー フォーム ディクショナリ」を参照)。
• [Template-Based] ディクショナリ タイプの [Select] リストで下矢印をクリックし、[Person Based] を選択して個人ベースのディクショナリを作成します(「個人ベースのディクショナリ」を参照)。
• 以下に示すように、[Service Item] フィールドでサービス項目を名前で検索し、次にポップアップから項目を選択してサービス項目ベースのディクショナリを作成します(「サービス項目ディクショナリ」を参照)。
フリー フォーム ディクショナリは、以下に示すように、サービス設計者が、ディレクトリ内のフィールド、その発生順序、それぞれに割り当てられるデータ型を自由に指定できることを意味しています。
フィールド名(上図の [Name] カラム)には英数字とアンダースコアを使用できますが、先頭は文字にする必要があります。スペースや他の特殊文字は使用できません。JavaScript の予約語(「this」など)は、フィールド名に使用できません。
データ型(上図の [Type] カラム)は、ディクショナリをフォームに入れるときに選択可能な HTML 表現に影響を及ぼします。それは、次に、ルールと ISF 関数をフィールドに適用する方法に影響するとともに、ディクショナリまたはディクショナリを含むサービスをレポート可能にするかなど、データ マート内のフィールドの使用方法に影響します。
ディクショナリがフォーム上でグリッドとして設定されている場合、表示するフィールドの [Show in Grid] カラム内のチェックボックスにチェックを入れます(グリッドの詳細については、「フォームでのグリッドの使用」を参照)。
ディクショナリがレポート可能な場合には、ディクショナリ定義を変更する機能が一時的に無効になります。レポート可能なディクショナリ内のフィールドのデータ型は、数値/通貨型、日付/日時型、文字型の間で交換することはできません。ディクショナリに他の変更を行いたい場合には、[Reportable] 設定を [No] に設定し、ディクショナリを保存し、変更を行い、次にこの設定を元の値に戻します。ディクショナリをレポート可能に指定する前に、必ず『 Cisco Service Portal Reporting Guide 』でレポート可能オブジェクトの定義に関するガイドラインを読んでください。
アプリケーションは、Service Portal アプリケーションにアクセスする必要のある、ユーザ組織内のすべての要員のリポジトリを管理します。このリポジトリ内の個人情報は、Directory Integration(アプリケーションに対して、企業全体の LDAP ディレクトリからデータを取得するよう指示)を介して設定するのが一般的ですが、Organization Designer を使って手動でメンテナンスできます。
サービス フォームは、一般にこのような個人情報を参照する必要があります。たとえば、サービス要求には常にカスタマー(サービスの受信者)と発信者または要求者(キーボードの前に座ってサービスを要求する個人)が存在します。多くの場合、カスタマーと発信者は同一の個人です。つまり、従業員が、自分自身のためにサービスを要求します。その他の場合として、管理者または許可された他の従業員が、サービスのカスタマーとなる他の個人の代わりにサービス要求を開始します。
また、サービス要求には、企業従業員に関連するその他の情報も含まれる場合があります。頻繁に発生する使用例として、要求者が、要求に対して 1 人以上の承認者を指名する必要がある場合があります。このシナリオでは、ユーザは、使用可能な個人が含まれるドロップダウン リストを検索して承認者を選択します。また、参照しやすいように承認者の連絡先情報がサービス フォーム データに含まれます。
個人ベースのディクショナリには、リポジトリから特定の個人データを取得し、個人データのどの側面をサービス フォームに表示するか指定するメカニズムがあります。
この検索機能は、個人ベースのディクショナリによって提供されます。ディクショナリ名とグループは、自由に編集できます。このような個人ベースのディクショナリには、「Select_Person」属性が自動的に含まれます。
「Select_Person」属性により、リポジトリ内で個人を検索する機能、またはサービス フォームに対して Directory Integration が有効な場合には、外部ディレクトリで個人を検索する機能が提供されます。
Select_Person 属性は、テキストではなく、「Person」のデータ型を持ちます。このデータ型は、フォーム内で属性を使用する場合に、属性の外観を制御します。たとえば、下記のサービス フォームの [Name] フィールドは、「Select_Person」属性として定義されています。
デフォルトで使用する([Use])ようにチェックされているため、すべての新しい個人ベースのディクショナリで、[Select_Person] に対する [Show in Grid] がデフォルトでチェックされています。[Use] をオフにできないのと同様に、[Select-Person] に関して [Show in Grid] をオフにすることはできません。
次に示すように、サービス フォームに個人ベースのディクショナリが含まれている場合、[Select] ボタンをクリックすると [Person Search] ダイアログが表示され、ユーザは、検索条件を指定して 1 人の個人を選択できます。
個人を選択すると、検索ダイアログが閉じ、ディクショナリ内で使用されるすべてのフィールドに、選択した個人のプロファイル内の対応するフィールドの現在値が自動的に入力されます。名前は、FirstName LastName 形式で表示されます。
Service Portal インスタンスには、カスタマー情報用と発信者情報用に、2 つの個人ベース ディクショナリが自動的に含まれます。これらのディクショナリは、「予約済み」サービス グループにあります。
Customer_Information ディクショナリと Initiator_Information ディクショナリは、すべての要求に関してカスタマーと発信者を自動的に記録する標準動作を補完します。カスタマーと発信者に関するすべての情報は、取得ライフ サイクルを通して Business Engine 名前空間を介して使用できます。また、My Services と Service Manager 内の要求に関する [Requisition Summary] ページの一部として表示されます。
ただし、表示されるフィールドは設定可能ではありません。さらに、これらのフィールドは、個人のプロファイルから取得された値を反映しています。サービスをオーダーする個人には、期限切れの情報を修正する機会、または現在の要求を遂行するために必要な追加情報を提供する機会はありません。さらに、場合によっては、レポート上および制御上の理由で、要求が送信された時点の、それ以降の変更を反映していないカスタマー情報と発信者情報を追跡する必要があります。
これらの理由で、サービス設計者は、一般にカスタマー情報と発信者情報を含むディクショナリを作成し、これらのディクショナリをアクティブ フォーム コンポーネントに入れます。これは、次に、すべてのサービスに含まれるようになります。Initiator Information ディクショナリと Customer Information ディクショナリのディクショナリ名とグループ名は変更できません。ディクショナリの他の一般的なプロパティは編集できます。予約済みディクショナリは、予約済みフォーム、Customer-Initiator フォームに含まれます。フォームの内容と外観は定義可能であり、その動作は、使用可能な任意のフォーム ルールまたは ISF で操作できます。
予約済みディクショナリには、使用可能なすべての個人情報がリストされ、また設計者は、各ディクショナリに割り当てる属性を指定できます。設計者は、対応する属性の [Name] をチェックすることにより、ディクショナリに含める属性を選択する必要があります。たとえば、サービス要求によっては、カスタマーの上司の承認が必要になるため、一般には [Supervisor] 情報を含める必要があります。属性名とデータ型は変更できません。フィールドが常に非表示になる場合であっても、サービスで操作する必要のあるすべての属性を含める必要があります。属性を選択すると、個人のプロファイルから対応する値が入力されます。次に、設計者は、ディクショナリを含むフォームを設定して、フィールドを適宜非表示にできます。
個人プロファイルには、Request Center が使用しないカスタム フィールドが 10 個含まれています(名前は Custom1 から Custom10)。これらのフィールドを、Customer ディクショナリまたは Initiator ディクショナリに含めることができます。これらのフィールドのいくつかは、ディレクトリ(LDAP)統合を通してインポートされる個人属性にマップされます。その他は、このディクショナリを含む Customer-Initiator アクティブ フォーム コンポーネントの設定時に使用可能な表示プロパティまたは条件付きルールを通して割り当てるため、または操作するために残しておくことができます。
個人ベース ディクショナリ、および Customer ディクショナリと Initiator ディクショナリでは、Service Designer の Dictionaries コンポーネントを使用して、サービス フォームに表示するディクショナリ フィールド(属性)を選択できます。単に、ディクショナリにナビゲートして、[Use] カラムのチェックボックスをオンまたはオフにすることにより、個人ベース ディクショナリを使用するフォーム、または Customer ディクショナリと Initiator ディクショナリの両方を自動的に含むアクティブ フォーム コンポーネントである Customer-Initiator フォームで使用する、または含めるフィールドを決定します。
カスタマーまたは発信者の姓名、およびログイン ID に加えて、個人の電子メール アドレスおよびホーム OU のフィールドを追加するのが一般的です。Person_ID は、個人に割り当てられる一意の識別子です。基本的なフォーム処理には、このフィールドは必要ありません。しかし、たとえば、このディクショナリ内に対応する属性を持たない個人またはその上司に関する情報を動的に取得するデータ取得ルールを記述する場合には有効です。同様に、Supervisor_ID も、予約済みディクショナリ内に含めるように選択できます。これにより、サービス設計者は、選択した要求の承認のために「コマンドのチェーン」を動的に作成できます。
同様に、ロケーション情報を特に Customer ディクショナリに含めたい場合があります。この情報は、たとえば、タスクのルーティング先のキューを決定するため、または実際に訪問してコンタクトを取る必要がある場合に個人のアドレスを単に示すために必要な場合があります。
「サービス項目」は、「設定項目」のタイプの 1 つ、つまりサービス要求に対応して提供可能なハードウェア、ソフトウェア、装置の 1 つであり、そのライフ サイクルは、それに続くサービス要求によって管理できます。物理的なハードウェア デバイス(たとえば、携帯電話やサーバ)など、物理的なものにできますが、ソフトウェア(たとえば、アプリケーションやログイン ID)など、仮想的なものにすることもできます。Service Portal 内の Service Item Manager モジュールを使用して、サービス項目を定義するか、または仮想マシンなど、事前に設定されたサービス項目の定義を確認します。次に、これらのサービス項目は、サービス項目ベースのディクショナリ(SIBD)の作成に使用されます。また、サービス要求の一部として、サービス項目インスタンス情報を取得および表示するために使用されます。サービス項目および Service Item Manager の詳細については、「サービス項目と Service Item Manager」を参照してください。サービス項目をサービス設計に組み込むための詳細については、 第 3 章「Lifecycle Center」 を参照してください。
Service Item ディクショナリには、サービス項目に保存されるデータを提供するフィールドが含まれます。詳細については、「サービス項目ベースのディクショナリの定義」を参照してください。
統合ディクショナリ グループは、すべての Service Portal インスタンスで自動的に作成されます。統合ウィザード(Service Portal と外部システム間の Web サービス統合を作成する Service Designer のウィザード)を通して作成されるすべてのディクショナリが、自動的にこのグループに配置されます。一度作成されると、統合ディクショナリはどのディクショナリ グループにも移動できます。設計者は、このグループに手動でディクショナリを配置することはできません。
統合ウィザードの詳細については、「Service Designer」を参照してください。
フォームは、サービスを実装するための構成要素です。オーダー可能な各サービスは、1 つ以上のフォームで構成されます。各フォームは、ユーザがサービス カタログのサービスをオーダーするとき、サービスの要求を承認または確認するとき、および受信者へのサービスの提供に必要な手順を完了するときに、ユーザに提示される Web ページの外観と動作を指定します。その Web ページは、「サービス フォーム」と呼ばれます。
サービス設計者は、次のフォーム コンポーネントを指定します。
• Form Content :フォームに含まれるディクショナリ、およびディクショナリとそのディクショナリを構成するフィールドを表示する順序
• Display Properties :ユーザがサービス フォームで作業するときに、各ディクショナリを構成する個々の属性を Web ページにレンダリングする方法
• Access Control :要求ライフ サイクル内の各時点で、サービス フォームを構成する特定のディクショナリを表示または編集できるユーザまたはユーザのグループ
• Active Form Rules :サービス フォームに表示されるディクショナリや個々の属性の外観または動作を条件に従って変更するためのルール、またはリレーショナル データソースからデータを動的に取得するためのルール
• Active Form Behavior :条件付きルールの実行をトリガーするイベント、または JavaScript を ISF と組み合わせて使用して記述されたスクリプト
フォームを設定する最初の手順では、一般に、そのフォームで使用するディクショナリを指定し、さらにそれらのディクショナリ、およびディクショナリ内のフィールドを表示する順番と方向を指定します。
[Form Content] タブに、フォームに含まれるディクショナリが表示されます。ディクショナリ名には、プレフィックスとしてディクショナリ グループ名が付きます。ディクショナリ名の左のプラス記号(+)をクリックして、そのディクショナリ内のフィールドを表示します。ディクショナリまたはフィールドの表示順序を変更するには、移動する項目を選択して、その項目が目的のシーケンスになるまで、ページの右にある上矢印キーおよび下矢印キーをクリックします。
(注) [Form Content] タブのディクショナリ名は、Service Designer の Dictionaries コンポーネントへのリンクです。ディクショナリに別のフィールドを追加する必要がある場合、ここから単にディクショナリ名の上で Ctrl キーを押しながらクリックすることで、直接ディクショナリに移動できます。
フォーム内で定義されたルールでディクショナリやフィールドを参照するためには、フォームにディクショナリを含める必要はありません。さらに、フォームは、まったくディクショナリを含まなくてもかまいません。この場合、フォームは、ルールのリポジトリです。フォームは、他のフォームも含むサービスに含まれる必要があります。また、フォームは、ルールを適用するディクショナリを含む必要があります。
複数のフォームのうちの 1 つだけがサービスに含まれる場合には、同じディクショナリを複数のフォームで使用できます。ただし、ディクショナリの外観と動作に関連するすべてのプロパティは、各フォームで指定する必要があります。したがって、これは理想的なアーキテクチャではありません。
サービス設計者は、アクティブ フォーム コンポーネントの [Display Properties] を使用して、サービス フォーム上の各ディクショナリの外観、およびディクショナリ内の各フィールドの外観を設定します。
各ディクショナリにはキャプションが割り当てられており、これは、サービス フォーム上に表示されるときに、ディクショナリのタブ見出しとしてレンダリングされます。デフォルトのキャプションはディクショナリ名ですが、自由に変更または復元できます。ディクショナリにキャプションが割り当てられていない場合、サービス フォームにタブ見出しは表示されず、ディクショナリは、前のディクショナリの直後に表示されます。
ディクショナリが定義されると、各フィールドにデータ型が割り当てられ、フィールドのストレージ要件が定義されます。フォーム内で、各フィールドに「HTML 表現」を割り当てる必要があります。これは、このフォームを含むすべてのサービスで、フィールドをレンダリングする方法を示します。
HTML 表現には、フィールドの「入力タイプ」が含まれます。これは、サービス フォーム上のフィールドを表現する HTML 要素です。入力タイプは、フォーム ルールと ISF 関数をフィールドおよびその内容に適用する方法に直接影響を及ぼします。また、HTML 表現は、各フィールの設定に使用できる詳細なオプションを決定します。次の画面は、HTML 表現の「text」を割り当てられたフィールドに使用できるオプションを示しています。これは、HTML テキスト ボックスとしてレンダリングされます。
上記の [Employee_Code] フィールドの例に示すように、[Display Properties] タブの [Generate unique value] チェックボックスをオンにすることにより、[Input Type] が [text]、[hidden]、または [read-only] のすべてのフィールド値として、一意の ID を生成できます。これにより、たとえば、サービス項目名や属性に一意の値を作成するために生じる可能性のある要件を満足できます。
新しいサービスが要求されると、汎用一意識別子(UUID)が生成され、フォーム ロード時に、[Generate unique value] がチェックされたすべてのフィールドのフィールド値として設定されます。この手順の後、条件付きルールとデータ取得ルールが実行されます。したがって、このフィールドの値を設定する条件付きルールまたはデータ取得ルールがある場合、そのルールを実行することにより、この UUID 値を上書きできます。
UUID は、ISO 標準(XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX 形式の 36 文字の文字列)に従って生成されます。
(注) Requisition API(RAPI)を通してサービスをオーダーすると、UUID は生成されません。
機密性の高い情報を含むディクショナリ フィールド、またはデフォルトまたは自動取得メカニズム(たとえば、仮想マシン サービス項目の価格や個人のログイン ID)により設定された値を含むディクショナリ フィールドについては、[Editable on sever-side only] チェックボックスをオンにして、悪意のあるハッキングの試行による変更から保護する必要があります。このフィールドは、セキュリティ機能を示すロック アイコン 付きで表示されます。詳細については、「サービス フォーム パフォーマンスとセキュリティに関する考慮事項」を参照してください。
アプリケーションは、現時点で表示されているすべてのディクショナリ内のフィールドの幅に基づいて、サービス フォームのレイアウトを動的に決定します。非グリッド ディクショナリでは、各フィールドは水平にレイアウトされます。ラベルの後にフィールドの入力エリアが続き、次にヘルプ テキストが続きます。
フィールド内のカラム数、またはフィールド ラベルを変更すると、フォーム レイアウトが変化します。
読み取り専用の HTML 表現を持つフィールドには、ヘルプ(指示)テキストはありません。しかし、フィールドのデフォルト値自体は、このようなヘルプ テキストを提供するために使用できます。
フィールド ラベルは、自動的に太字で生成されます。[Advanced Formatting] ボタンを使用することにより、特定のフィールドに追加または代替 HTML フォーマットを適用できます。
Service Portal は、サービス フォーム上でのグリッドの使用をサポートします。任意のディクショナリ(外部ディクショナリを除く)を、フォーム上でグリッドとして表示されるように設定できます。グリッドは、(ディクショナリ定義内で)[Show in Grid] がグリッド上のカラムとしてチェックされているすべてのディクショナリ フィールドを使用して作成します。グリッドを使用すると、1 つのフォームでフィールド(行)の複数のデータ インスタンスを入力できます。新しい行を追加するには、次に示すように、[Add] ボタン( )をクリックします。[Add] ボタンをクリックすると、最後の行の末尾に新しい空の行が挿入され、強調表示されます。
次のサービス フォームの例は、グリッドと非グリッドのディクショナリ レイアウトの違いを示しています。同じフィールドを持つ 2 つのディクショナリが使用されており、最初のディクショナリはグリッドとしての表示が設定されています。
グリッドは、1 つのフォームで同じフィールドを持つ複数のデータ インスタンスを入力する必要があるフォームを設計する場合に有効です。同じフィールドを持つ複数のセクションを作成するのではなく、複数のフィールドを持つ 1 つのグリッドを作成できます。グリッドを使用すれば、ディクショナリを複数作って同じフィールドを複数保持する代わりに、ディクショナリを 1 つ作成および設定するだけで済みます。
ディクショナリを完全に 90 度回転してフィールド ラベルをフィールドの最上部に表示できる点を除いて、グリッドの設定は、多くの部分で非グリッド ディクショナリの設定と似ています。主な違いとして、グリッド セルは、データベース内に個別のフィールドとして保存されるにもかかわらず、ブラウザでのレンダリング時には真に個別のフィールドではない点があります。この違いにより、注意すべき制限がいくつか発生します。それらの制限、およびグリッドと非グリッド間のその他の違いを、次に示します。
• [Radio]、[Checkbox]、および [Select (Multiple)] の入力タイプは使用できない。
• フィールド ラベルがカラム ヘッダーとして表示される。グリッド内のフィールド ラベルには、高度なフォーマットを設定できない。
• いくつかの ISF ディクショナリ レベル関数およびフィールド レベル関数は使用できない(「グリッドを操作するための条件付きルールと ISF」を参照)。
• グリッド フィールドは、データ取得ルールの作成時に、「トリガー フィールド」として選択できない。
• グリッド ディクショナリとそのフィールドは、条件付きルールの「トリガー条件」として選択できない。「アクション」ターゲットとしてのみ使用可能。
• 条件付きルール アクションのサブセットがサポートされる。また、これは、個別のセルとしてではなく、全体としてカラムに適用される。
• Requisition API(RAPI)は、グリッド ディクショナリを含むサービスの送信に使用できない。
• Business Engine 名前空間、Service Item Task、および Service Link エージェント パラメータに対するグリッド ディクショナリ フィールドの使用はサポートされない。
サービス フォームで使用するグリッドを設計するには、次の手順を実行します。
ステップ 1 ディクショナリの定義の [Show in Grid] チェックボックスを使って、グリッド内に表示するフィールドを選択します。「グリッドに表示するディクショナリ フィールドの設定」を参照してください。
ステップ 2 ディクショナリをアクティブ フォーム コンポーネントに追加するときは、[Display as Grid] を選択します。「グリッドとして表示されるディクショナリの設定」を参照してください。
ステップ 3 グリッド オプションを設定し、プロパティを表示します。「グリッド オプション」、「グリッド フィールドの HTML 表現」、および「グリッドのプロパティ」を参照してください。
グリッドの使用例については、「例:Laptop Selection」と「例:View All Laptops」を参照してください。
ディクショナリの [Dictionary Attributes] セクションで、フォーム上のグリッドに表示するフィールドの横の [Show in Grid] カラム内のチェックボックスをオンにします。ディクショナリが [Display as Grid](「グリッドとして表示されるディクショナリの設定」を参照)に設定されたときに、ディクショナリ内で [Show in Grid] および [Use] に設定されたフィールドが、サービス フォーム上でグリッド内のカラムとして表示されます(「グリッドのプロパティ」を参照)。
デフォルトで使用する([Use])ようにチェックされているため、すべての新しい個人ベースのディクショナリで、[Select_Person]、[Login_ID]、[Personal_Identification]、[Email_Address]、[Home_Organizational_Unit] フィールドに対する [Show in Grid] がデフォルトでオンになっています。新しいサービス項目ベースのディクショナリ内の [Name] フィールドに関しても、同じことが言えます。[Select-Person] フィールドおよび [Name] フィールドに関して [Use] をオフにできないように、これらのフィールドに関して [Show in Grid] をオフにすることはできません。
ディクショナリ内で [Show in Grid] としてチェックされたフィールドの合計数は、newscale.properties ファイル内の「dictionary.attributes.maximum.showingrid.count」プロパティに設定された数を超えることはできません(デフォルト値は 20)。つまり、グリッドは、デフォルトで 20 を超えるカラムを持つことはできません。
グリッドは、複数値セルの機能を持たないため、[Show in Grid] と [Multivalue] は互いに排他的です。
外部ディクショナリ内のフィールドは、グリッドで使用できません。したがって、[Show in Grid] カラムを持ちません。
予約済みディクショナリ(Customer_Information と Initiator_Information)は本質的に 1 セットのデータのみ表現するため、これらのディクショナリ内のフィールドはグリッドで使用できません。
次に、フィールドが [Show in Grid] に設定されたディクショナリの例を示します。
次に示すように、[Content] タブからフォームにディクショナリを追加するときに表示される [Dictionary] ポップアップ ウィンドウ上の [Display as Grid] チェックボックスをオンにすることにより、任意の内部ディクショナリ(予約済みディクショナリを除く)をグリッドとして表示するように設定できます。
[Display as Grid] をオンにしてディクショナリを追加するときに、[Show in Grid] および [Use] に設定されたフィールドのみカラムに表示されます。[Use] に設定されているフィールドで、[Show in Grid] に設定されていないフィールドは表示されません。
グリッドとして追加したすべてのディクショナリに関して、[Display as Grid] チェックボックスがオンで [Content] タブに表示されます。[Content] タブ上で、このチェックボックスは常にグレーアウトされており、変更できません。その目的は、フォーム上でどのディクショナリがグリッド フォーマットか示すことです。ディクショナリを誤ってグリッドとして追加した場合、またはグリッド ディクショナリをフォームに追加するときに [Display as Grid] をオンにするのを忘れた場合には、そのディクショナリを削除し、[Dictionary] ポップアップ ウィンドウで [Display as Grid] をオンまたはオフにしてもう一度追加するだけです。
次に示すように、グリッド ディクショナリの [Display Properties] タブには、[Grid Options] セクションが追加されています。
[Allow user with Edit access control to add/delete rows] がオンの場合、ディクショナリの編集権限を持つすべてのユーザに対して、グリッドは、行を追加する( )と削除する( )の 2 つのボタン付きでフォームに表示されます。オフの場合、これらのボタンは表示されず、ディクショナリの編集権限を持つユーザは、グリッドに行を追加/削除できません。既存の値の修正のみ可能です。
[Maximum total number of rows] は、追加できる行の最大数を制御します。デフォルト数は 5 です。
(注) 最大値は、newscale.properties ファイル内に設定された「dictionary.grid.maximum.rows.count」プロパティを超えることはできません。デフォルト値は 50 です。
[Grid height, in rows] 設定は、表示可能なグリッドの高さを制御します。入力した行数がこの値を超えると、垂直スクロールバーが表示されます。デフォルト値は 5 です。実際の高さは、スクロールバーに対応して大きくなります。
グリッド ディクショナリの [Display Properties] タブでは、HTML 表現の [select (multiple)]、[radio]、および [checkbox] はグリッド内にレンダリングできないため、[Input Types] のドロップ ダウン リストでは使用されません。同様に、グリッド内では [Advanced Formatting] と [Buttons] は設定できないため、この 2 つのコントロールも表示されません。
次に、[Show in Grid] に設定されたディクショナリ フィールドの HTML 表現の例を示します。
あるサービスが、[Display as Grid](グリッド ディクショナリ)に設定されたサービス内の 1 つ以上のディクショナリで設計されている場合、サービス要求フォームは、オーダー時にディクショナリをグリッドとして表示します。その場合、[Show in Grid] としてマークされたディクショナリのフィールドは、カラムとして表示されます。次に、フォーム グリッドの例を示します。
[Display Properties] タブ内のディクショナリ キャプションが、グリッドのヘッダーとして表示されます。ディクショナリ キャプションが空白の場合、[Properties] タブがグリッドのヘッダーとして表示されます。グリッド ディクショナリ フィールドの [Display Properties] タブ内の [Label] プロパティがカラム ヘッダーとして表示されます。
[Display Properties] タブ内のグリッド ディクショナリ フィールドを [Mandatory] に設定すると、上記の [Department] フィールドに示すように、カラム ヘッダーが赤いアスタリスク( )付きで表示されます。
上記の例に示すように、テキスト フィールドの左上隅に赤い三角形が表示され、保存または送信されていない、新しく入力されたテキストであることを示します。
次に示すように、グリッド ディクショナリ フィールドの [Display Properties] タブに、カラム ヘッダーのツール チップとしてヘルプ テキストが表示されます。
グリッド内のセルにマウスを合わせると、セルの内容がツール チップに表示されます。これは、セルの内容が、セルに表示可能なものより長い場合に有効です。
Tab キーを使用してグリッドの次のフィールド、および [Add] ボタンと [Delete] ボタンに移動できます。[Add] ボタン( )をクリックすると、最後の行の末尾に新しい空の行が挿入され、強調表示されます。
サービス項目名を入力した後、グリッドの各行に対してサービス項目データの自動取得が機能します(「例:Laptop Selection」)。また、[Service Item Related Services] タブからサービスをオーダーするときに、サービス項目詳細の自動入力が機能します。サービス フォームにサービス項目ディクショナリがグリッド コントロールとして存在する場合、サービス項目詳細がグリッドの最後にコピーされます。この方法で、他の条件またはデータ取得ルールがグリッドに入力した場合、サービス項目詳細がグリッドの最後に追加されます。
グリッドの高さは、[Grid Height, in rows] 値で制御されます(「グリッド オプション」を参照)。指定された制限より多くの行がグリッドに存在する場合、垂直スクロール バーが表示されます。
グリッド ディクショナリ フィールドに対する [Display Properties] タブ内の [Columns] 値により、各グリッド カラムの幅が決まります。すべてのカラムの幅の合計がグリッドの幅を超える場合、水平スクロール バーが表示されます。また、カーソルをカラムと次のカラムの間に置くことにより、サービス フォーム上でグリッド カラム幅を一時的に調整できます。次に示すように、カーソルが、逆向きの矢印が 2 つ付いた二重線に変わります。
新しいカーソルが表示されたら、左マウス ボタンを押したままドラッグして、カラム幅を調整します。
カラムのデータ型が Person として定義されている場合、次に示すように、セルをクリックすると、セルに [Person Search] ボタンが表示されます。
ボタンをクリックすると、標準の [Person Search] ダイアログが表示されます(「個人ベースのディクショナリ」を参照)。個人ベースのディクショナリは、グリッドとして設定できます。フォーム ユーザが [Person Search] を使って選択を行うと、ディクショナリ内で使用されているその行内の他のフィールドに、選択した個人のプロファイル内の対応するフィールドの現在値が自動的に挿入されます。
グリッドでは、日付/時刻フィールドも使用できます。このようなフィールドをクリックすると、カレンダー アイコンが表示されます。
カレンダー アイコンをクリックすると、それぞれ Date または Date and Time として定義された Data Types ディクショナリを持つカラムに対して、日付または日付/時刻ダイアログが表示されます。
[Data Type] に URL が設定されている場合、セルの内容は、クリック可能なリンクとしてレンダリングされます。
URL リンクをクリックすると、デフォルトのブラウザが開き、入力された URL が表示されます。
グリッドに対するすべてのエラー メッセージは、グリッドの最上部に表示されます。各メッセージはリンクで表示されるため、フォーム ユーザは、各メッセージをクリックすることにより、エラーが発生しているセルに直接移動できます。
グリッド ディクショナリは、ブラウザ内では 1 方向にレンダリングされるものの、関連付けられた取得エントリに対するデータベース内で生成された WDDX では別方向に保存される点で、非グリッド ディクショナリとは異なります。この違いのため、すべての条件付きルール アクションがサポートされているわけではありません。また、サポートされているものは、データのカラム全体に適用されます。個々のセルを操作するには、条件付きルールと ISF 関数の組み合わせが必要です。次に、グリッドで使用できる条件付きルール アクションと ISF 関数のクイック サマリーを示します。(これらの詳細については、条件付きルールと ISF の各項で詳細に説明します。ここでは、これらの機能に精通しており、グリッドに適用する方法だけを理解したい場合のために、要約を示します)。
グリッド ディクショナリとそのフィールドは、ルールのトリガー条件としては選択できません。条件付きルール アクションのターゲットとしてのみ選択できます。非グリッド ディクショナリ内の個々のフィールドに適用される、以下の条件付きルール アクションは、グリッド内のカラム全体に適用されます。
その他のすべての条件付きルール アクションは、グリッドのカラムまたはセルではサポートされません。
グリッドの場合、Make Read-Only アクションと Disable アクションの間には、目立った差はないことに注意してください(非グリッド フィールドでは、ユーザ インターフェイスの効果に多少の違いがみられます)。同じことが、Make Writable アクションと Enable アクションにも当てはまります。
JavaScript 関数は、グリッド ディクショナリ内のフィールド レベル イベントに割り当てることはできません。
次の表に示すように、既存の ISF フレームワークは、グリッド ディクショナリおよびフィールドをサポートするように拡張されています。
|
|
グリッドを表示、非表示にします。Service Designer を通して非表示にされるディクショナリには効果がありません。 |
|
ディクショナリ内のすべてのカラムを読み取り専用または読み取り/書き込みに設定します。Service Designer でそのカラムがすでに読み取り専用に設定されている場合には、効果がありません。 |
|
|
|
serviceForm.dictionaryName.fieldName.getCellValue (RowIndex) |
|
serviceForm.dictionaryName.fieldName.setCellValue (RowIndex, Value) |
Customer-Initiator フォームは、「予約」フォーム グループ内のすべてのアプリケーション インスタンスに提供されます。このフォームは、Access Control 設定を除いて、ユーザ定義のフォームで使用可能な機能と同じ機能を使用して設定できます。カスタマーと発信者が同じ場合(つまり、他人のためではなく、個人が自分自身のためにオーダー)、Initiator_Information ディクショナリは非表示になります。Customer Information ディクショナリは、Access Control を通して指定された参加者権限で表示されます。両方のディクショナリのフィールドには、デフォルト値が提供されており、それ以降に使用可能です。
通常は Customer-Initiator フォームはすべてのサービスに含まれている必要があります。これにより、標準の My Services および Service Manager の表示に含まれないか、またはデータ マート内の対応するクエリー件名に含まれない、カスタマーおよび発信者に関するクライアント固有の詳細情報を記録し、アクセスできます。したがって、多様なサービスで必要なすべての属性を使用できるように、ディクショナリとフォームの両方に含まれる属性を標準化する必要があります。これにより、関係のないサービス内ではフォーム ルールによって非表示になる属性を含むことが必要になる場合があります。
このフォームに対する未承認の変更を防止するため、予約済みフォーム グループへのアクセスを(オブジェクトの権限を介して)制限する必要があります。デフォルトでは、「Site Administrator」ロールおよび「Catalog Designer and Administrator」ロールのメンバーは、このグループ内で「Design Forms」を許可されています。これらのロール内のメンバーシップは、厳密に制御する必要があります。
個人ベースのディクショナリが含まれたすべてのフォームでは、選択された個人のプロファイルに格納されたフィールドの対応する値に基づき、Lightweight 名前空間を使用してフォーム フィールドに値を提供します。これには、Customer-Initiator フォームとユーザ定義のすべてのフォームの両方が含まれます。大部分の Lightweight 名前空間の形式は、#Customer. FieldName #、または #Initiator. FieldName # です。ただし、#Customer.DetailedLocation.Office# など、ロケーション(アドレス)のコンポーネントのように、さらに複雑なものもあります。全リストについては、「Lightweight 名前空間」を参照してください。
(注) Lightweight 名前空間のグリッド ディクショナリ フィールドの使用は、現在サポートされていません。
名前空間は、フィールドのデフォルト値として自動的に入力されます。必要に応じ、初期割り当てを置換できます。ただし、元のデフォルト値を自動的に復元する方法はありません。該当する名前空間を入力する必要があります。Lightweight 名前空間は、「名前空間」に記載され、説明されています。
カスタマー データまたは発信者データを参照する Lightweight 名前空間は、予約済みディクショナリ以外のディクショナリ内のフィールドに対するデフォルト値としても使用できます。この場合、ディクショナリ フィールドから該当する個人属性へのマッピングは、当然ながらサービス設計者が行います。この機能では、個人ベースのデータとその他のデータの両方が格納されたディクショナリを定義できます。
アクセス コントロール機能により、要求ライフ サイクルを構成する全期間中に、フォームのディクショナリを表示または編集できるユーザが決まります。「System Moment」は、要求が行われた要求ライフ サイクルの段階を追跡します。
すべての要求は、オーダーの時点から開始します。要求は、送信されるまでオーダーの段階に留まります。オーダー時点の参加者は、カスタマー/発信者のみです。通常、発信者が要求の詳細を提供する必要があるディクショナリのみが編集可能です。承認者、確認者、またはタスク実行者によってのみ使用されるディクショナリには、アクセス権が割り当てられていません。
サービスに設定されている承認と確認に基づいて、要求には承認段階が存在しないか、または任意の数の承認段階が存在します。参加者と各参加者に付与されるアクセス コントロールは、承認の種類と必要なアクションの性質によって異なります。一般に、これらの時点では、1 つ以上のディクショナリが編集可能です。ここでは、以前入力されたデータを承認者または確認者が調整したり、要求が承認または拒否された理由などの新しい情報を入力したりできます。
提供計画における一般的な参加者が一覧表示され、目的の権限をオン(またはオフ)することにより、適切なアクセス コントロールを割り当てることができます。
「Service Team」の参加者は、サービスが存在するサービス グループを所有するサービス チームを意味しています。このフォームを複数のサービスに含める場合、サービスが存在するグループによって、各サービスのサービス チームの参加者が異なります。そのため、フォームに「参加者を追加」して、現時点でディクショナリ データにアクセスする必要があるサービス チームを明示的に示すことを推奨します。複雑な提供計画のサービスの場合、計画の各タスクを異なるサービス チームが実行する必要がある場合があります。この場合も、参加者を追加する必要があります。
Customer-Initiator フォームは、実質的にすべてのサービスで使用される可能性があるため、新たな懸念事項になります。したがって、特に Customer ディクショナリと Initiator ディクショナリに表示権限のみを設定する必要がある場合、[Additional Participants] ボタンを通して「すべてのユーザにアクセスを追加」するのが最も効率的なことがあります。
特定の時点でディクショナリを表示可能ではあるが編集不可に指定すると、ディクショナリ内のすべてのフィールドが HTML ラベル(読み取り専用テキスト)としてレンダリングされます。
• 複数の選択肢を持つフィールド(チェックボックス、複数選択ドロップダウン リスト)のテキストでは、これらのフィールドに対してすでに選択されているオプションが、カンマ区切りの値リストで示されます。
• [Person] フィールドのラベルには、以前選択された個人の名前が表示されます。付随する [Search] ボタンは無効になっています。2 番め(非表示)のオブジェクトには、選択した個人の一意の識別子が含まれます。
• URL は、ハイパーリンクされた HTML ラベルとしてレンダリングされます。
• ディクショナリ内のフィールドにはヘルプ テキストは表示されません。
• フィールドに値を設定しようとする条件付きルールは、無視されます。
編集不可のディクショナリ内のフィールドには HTML DOM オブジェクト(つまり、<input> タグ)が存在しないため、適用できるルールまたは ISF 関数はサブセットに制限されます。これらの制限は、以降の条件付きルールと ISF 関数の詳細な説明に記載されています。
アクセス レベルは、ディクショナリ レベルで適用されます。特定の時点で、そのすべてのフィールドを含めてディクショナリ全体が非表示か、または表示されるが、その表示可能なフィールドがすべて定型文としてレンダリングされるか、または表示されるが、そのフィールドはユーザによって編集可能かルールによって操作可能な HTML 入力オブジェクトのセットとしてレンダリングされます。
すべてのアクセス コントロールの割り当ては、提供計画の一部として実行されるすべてのタスクに関係しています。異なるタスクの異なるユーザに対してディクショナリに異なる権限を割り当てる必要がある場合は、条件付きルールによってこの権限を割り当てる必要があります。アクセス コントロール設定は、常に、特定のユーザまたはグループに対して特定のディクショナリに必要となるすべての権限を付与する必要があります。条件付きルールは、アクセス特権を削除できますが、アクセス特権が [Access Control] タブを使って元から指定していない場合は、それらを付与することはできません。
[Access Control] タブを使って権限を割り当てると、アクティブ フォーム ルールを指定する設計者および ISF のプログラマに重要な影響を与えます。
• 非表示ディクショナリの場合、アクセス コントロールを介してディクショナリを非表示にするということは、その時点およびディクショナリが非表示にされた参加者のサービス フォームには、ディクショナリで定義されたオブジェクトが提示されないことを意味しています。したがって、ルールまたは ISF を使用してディクショナリやフィールドの内容、または可視性を操作することはできません。
• 表示専用ディクショナリの場合は、フィールドを編集できません。ただし、ルールまたは ISF を使用して、アクセス コントロールによって表示専用に設定されたディクショナリ内のフィールドの現在値を取得すること、ビューでフィールドを一時的に非表示にすること、またはフレームワークによって提供された他の機能を適用できます。
• 編集可能なディクショナリの場合は、全機能を使用して、ディクショナリまたはディクショナリ内のフィールドの外観と動作を操作できます。
ディクショナリ内でユーザに対して非表示のフィールドの値を操作する必要がある場合(たとえば、ユーザが値を意識することなく、フィールドのセットにデフォルト値を入力)は、これらのディクショナリに対して作用するフォーム ルールをサーバ側で実行するように設定できます(「サーバ側イベント」を参照)。
ディクショナリのアクセス コントロールを「設定しない」(つまり、[View] と [Edit] のいずれもオフ)と、ディクショナリはブラウザに送信されません。ただし、ルールがサーバで実行されることを条件として、引き続きフォーム ルールを設定して、ディクショナリにデータを格納できます(「サーバ側イベント」を参照)。これは、引き続きブラウザ セッションの結果を収集およびデータベースに格納するとともに、ブラウザにレンダリングされるサービス フォームを可能な限り小さく維持するための強力な手法です。
「Manage Service Dictionaries」機能が付与されているユーザによってサービス フォームが実行されると、Service Designer を使って割り当てられたアクセス コントロールは無視されます(この機能は「Site Administrator」ロールおよび「Distributed Service Designer」ロールに含まれます)。そのようなユーザに対しては、指定したアクセス コントロールにかかわらず、すべてのディクショナリがすべての時点で編集可能になります。この機能はフォームの外観の構築とテストを容易にするために提供されており、慎重に割り当てる必要があります。
複数のサービスで使用されるフォーム コンポーネントに付与する必要のあるアクセス コントロールは、場合によっては、各要求の履行に関係するサービス チームに応じて、サービスごとに変える必要があります。ディクショナリの表示または編集を行う参加者を、サービス定義に追加できます。サービスの [Form] タブでディクショナリを選択し、適切な参加者を追加します。サービス レベルでは、アクセス コントロール設定にその他の変更を行うことはできません。
アプリケーションは、次の 2 種類のアクティブ フォーム ルールをサポートしています。
• データ取得ルールは、リレーショナル データベースに格納されたデータを取得し、返された値を現在のフォームのフィールドに表示するか、取得した結果に対してフォームのデータを検証します。
• 条件付きルールは、一連のアクションを実行するために満たす必要がある条件のセットを指定します(条件のセットを空にすれば、トリガー イベントが発生したときにいつでもルールが適用されるようにできるため、これらのルールを「条件付き」と呼ぶのは、多少の語弊があります)。
大部分のルール定義は「宣言的」に行われます。つまり、ルール ウィザードが一連の手順をガイドすることにより、ルールの定義を支援します。ほとんどの場合、一連の質問に答えるだけで、コードを記述する必要はありません。フォームを含むサービスをオーダーすると、ルールが取得され、Web ページのコンテキストで動作するコードが自動的に生成されます。
すべてのルールの定義で重要な部分は、ルールを実行するタイミングを指定することです。各ルールには、1 つ以上の「トリガー イベント」があります。これらのイベントは、ユーザがサービス フォームで作業する際に発生し、結果的にルールが実行されます。たとえば、サービス フォームをブラウザにロード(カスタマーがサービスをオーダーした場合、またはサービス実行者が Service Manager でフォームを開いた場合)すると、「フォーム ロード」イベントの [When the form is loaded] が発生します。このイベント中は、通常の条件付きルールによって、現在のコンテキストに無関係のディクショナリまたはフィールドが非表示になり、データ取得ルールによって、フォームにデフォルト値が事前に入力されます。ユーザがフィールドの値を変更すると、「フィールド」イベントの [When an item is changed] が発生します。このようなイベントに付随する一般的なルールで、ドリル ダウンの値が設定される場合があります。たとえば、ユーザが一度だけリージョンを選択すると、そのリージョン内のファシリティがドロップダウン リストに設定されます。
次に、サービス フォーム フレームワークによってサポートされるフォーム レベル イベントおよびフィールド レベル イベントの概要を示します。
|
|
ユーザがボタンを押して、フォームが完了したことを示しました。コンテキストに基づいて、ボタンには、[Submit Order]、[Update]、[Done] などのラベルが付けられていますが、このようなボタンを押すことによってフォーム送信イベントがトリガーされます。 |
|
サービス フォームがユーザのブラウザに表示されます。(新しいサービスをオーダーする際に)ユーザが作業するサービスを選択しました。サービス実行者により、サービス フォーム データの表示、現在のタスクに必要なデータ入力の完了、以前入力したデータの確認が求められます。 |
|
サーバ フォームは、ブラウザに送信される前にサーバで準備されています(「サーバ側イベント」を参照)。 |
|
ブラウザ上でサービス フォームが送信されており、処理のためにサーバに送信されました(「サーバ側イベント」を参照)。 |
|
|
別のフィールドに Tab キーで移動するか、別のフィールド内をマウスでクリックすることにより、ユーザが指定されたフォーム フィールドを終了します。 |
|
現在、グリッド内には、トリガーされたフィールド イベントはありません。
上記の表では、最後の 2 つのフォーム イベントは「サーバ側」のイベントであると見なされ、より安全なイベントであることを示す、ロック アイコン 付きで表示されます。これらはサービス設計者に、サービス フォームをブラウザに送信またはブラウザから受信する前後に、フォーム ルールを適用する柔軟性を提供します。ユーザによって使用されないデータ(たとえば、ワークフローまたは外部システム統合の事前定義属性)は、ユーザに表示されるサービス フォームから除外でき、フォームの送信後にフォーム ルールで操作できます。サーバ側イベントを使用すると、ブラウザに送信されるデータの量を最小限に抑えるだけでなく、最高のセキュリティ レベルを実現するために役立ちます。
他のすべてのフォーム レベルのトリガーとフィールド レベルのトリガーは、「クライアント側」イベントまたは「ブラウザ側」イベントと見なされます。それらは主に、表示用のアクション、またはユーザとの対話を要求するアクションに使用されます。フィールドを読み取り専用にすること、必須としてマークすること、またはフォーカスを設定することは、すべてブラウザ固有のアクションです。このため、ISF 関数と JavaScript 関数は、クライアント側のイベントに関連付けられた場合にのみ有効になります。
サーバ側で実行される 2 つのフォーム レベル イベント、pre-Load と post-Submit は、ブラウザ セッション内のイベントと比較して、サーバ上でルールを実行する強力な機会となります。このようなルールは、一般に「サーバ側ルール」と呼ばれています。サーバ側ルールには、次のプロパティがあります。
• ブラウザにロードされたサービス フォームに対して作用するクライアント側ルールとは異なり、サーバ側ルールは、サービス フォーム内の任意のディクショナリに対して作用します。これには、ブラウザに送信されることのない(ユーザに表示権限も編集権限もない)ディクショナリが含まれます。
• 上記で説明した強力な動作は、1 つ以上のデータ取得ルールを pre-Load イベントにアタッチする場合、すべてのシステム時点で、これらのルールがすべてのディクショナリに対して効力を持つことを意味しています。したがって、ディクショナリが読み取り専用になるときに、オーダー時点でデータを事前入力し、それ以降のシステム時点では無視されることを意図するフォーム ルールを作成する場合、サーバ側イベントに関連付けないでください。
• フォームは、pre-Load データの取得が完了した後でのみレンダリングされます。これにより、ブラウザ上でのサービス フォームの初期レンダリングとクライアント側イベントの完了間の時間を短縮できるため、しばしばユーザ エクスペリエンスが向上します。ただし、フォームのサイズと複雑性によっては、pre-Load データの取得を最小化すると、フォーム ロードに関するエンドユーザの認識が改善される場合があります。
• フォーム ロード時にトリガーされるクライアント側ルールとは異なり、プリロード時にトリガーされるフォーム ルールは、検証エラーが発生した後にフォームがリフレッシュされるときに再実行されません。
データ取得ルールは、リレーショナル データベースに格納されたデータを取得し、返された値を現在のフォームのフィールドに表示するか、それらの値に対してフォームのデータを検証します。この取得はソース データベースに対して SQL クエリーを実行することによって行われ、指定したカラムの値がサービス フォームに返されます。
データソース 。Service Portal がデータベースにアクセスするためには、対応する 「 データソース 」 を定義する必要があります。データソースはデータベースを識別し、有効なユーザ名とパスワードを含めて、データベースに接続するための情報を提供します。アプリケーションには、REQUESTCENTERDS という名前の事前設定されたデータソースが 1 つ付随しており、これにより Service Portal データにアクセスできます。データベース管理者は、システム管理者と協力して、企業に固有のデータが含まれた追加のデータソースを定義し、その定義を、Service Portal がインストールされているアプリケーション サーバにパブリッシュする必要があります。データソースの設定とインストールの詳細な手順は、『 Cisco Service Portal Installation Guide 』に説明されています。
Standards と Service Items をデータ取得ルールのデータのソースとして使用できます。しかし、その用途は、Query Type が「Database Table Lookup」のルールに制限されます。手作業で記述した SQL を使用するルールでは使用できません。
データベース テーブル検索を定義する場合には、データソースのリストに Standards(と Service Items)だけでなく、トランザクション データベースおよびデータ マート データベースを含めます。「Standards」を選択すると、使用可能な Standards テーブルが表示され、クエリーのテーブル名として 1 つを選択できます。データ取得ルールを構成する他のすべての側面は、この項で前に説明した内容と同じです。
ソース データ 。取得する必要のあるデータの構造、およびそのデータを保存するテーブル(1 つまたは複数)を確認する必要があります。この情報は、一般に、ソース システムに精通した IT 専門家が提供します。取得する必要のあるすべてのデータが 1 つのテーブルに存在する場合には、単にそのテーブルの名前と取得するカラムを指定します。Request Center は、テーブル内のすべてのカラムを取得する SQL クエリーを自動的に構築します。しかし、複数のテーブルからデータを取得する必要がある場合、またはサービス フォーム上で使用するために値を操作(値の連結や計算の実行など)する必要がある場合には、SQL クエリーを自分で記述し、テストする必要があります。この作業には、ソース システムの知識を持ち、SQL の開発ツールを使用できる、データベースまたは IT 専門家が必要不可欠です。クエリーのテストが終わると、ここに概要を示す細かい変更を行い、「Enter Your Own SQL Query」の Query Type を使用して Data Retrieval Rule ウィザードにカット アンド ペーストします。
[Active Form Components] オプションで [Active Form Rules] タブを選択し、[New Rule] ボタンをクリックし、さらに [New Data Retrieval Rule] の作成を依頼することにより、データ取得ルールを作成します。次に示すように、Data Retrieval Rule ウィザードの最初のページが表示されます。
ウィザードの各ページに入力し、[Next] をクリックして次のページに進みます。ウィザードの最後のページには、ここで定義したルールのサマリーが表示されます。[Save] をクリックしてルールを保存するか、または [Previous] をクリックして前のページに戻り、定義を変更します。
Data Retrieval Rule ウィザードの最初のページには、次のフィールドがあります。
• [Rule Name] と [Description]:ルールの名前と説明。任意の語句を使用できます。ルール名は、ディクショナリとフィールド(適用可能な場合)を明確に示し、イベントをトリガーする簡略な名前にします。フォーム内に定義されたすべてのルールが、[Active Form Rules] タブの左側に一覧表示されます。確認または編集するルールを(ルール名で)明確に指示できれば、ルールの確認と維持が格段に簡単になります。[Description] フィールドには、追加情報を記述できます。
– [Distributing Rule] : クエリーの結果をフォームに返すことが主な目的の場合は、このオプションを選択します。たとえば、選択リスト、選択やデータ入力により別のフィールドにトリガーするフィールドのセット、またはグリッドの場合があります。このタイプのルールは、任意の数のフォーム レベル イベントおよびフィールド レベル イベントにアタッチできます。
– [Validating Rule] : このオプションは、クエリーで返された結果のセットに対して、フォームに入力されたデータを検証することが主な目的の場合に選択します。検証は、post-Submit イベント(サーバ側)に対してのみ行われます。ルールを、他のイベントにアタッチすることはできません。
– [Distributing Rule with implicit validation performed on the post-Submit event] : このオプションは、クエリーの結果をフォームに返すのが主な目的の場合で、post-Submit イベントに対してフォーム データを検証する必要がある場合に選択します。このルールは、任意の数のフォーム レベル イベントおよびフィールド レベル イベントにアタッチできます。また、このルールと「同等の検証」が、post-Submit イベントに自動的にアタッチされます。
• [Query Type]:[Database Table Lookup] または [Enter Your Own SQL Entry]。[Database Table Lookup] は簡便なオプションです。対象となるデータがすべて 1 つのテーブル(またはデータベース管理者が作成したデータベース ビュー)内に存在する場合、このタイプを使用します。画面のセット全体を通して、ウィザードのガイドに従ってダイアログに入力することにより、クエリーを定義できます。一方、さらに複雑なクエリーが必要な場合、構造化照会言語(SQL)を使用して、「Enter Your Own SQL Query」の Query Type でクエリーを記述する必要があります。
ルール タイプに [Distributing Rule] または [Distributing Rule with implicit validation performed on the post-Submit event] を指定した場合、次に示すように、1 つ以上のトリガー イベントを選択する必要があります。
• [Select Triggering Event(s)]:次のイベントのチェックボックスをオンにすることにより、ルールを実行(トリガー)できます。
– [Form Load]:My Services または Service Manager にサービス フォームが初期表示される場合。
– [Before the form is loaded (server-side)]:このサーバ側ルールは、ブラウザに送信する前にサーバ側で実行されます(「サーバ側イベント」を参照)。
– [After the form is submitted (server-side)]:「Distributing Rule」に対してのみ使用可能であり、このサーバ側ルールは、ブラウザ上でフォームが送信され、処理のためにサーバに送信された後で、サーバ上で実行されます(「サーバ側イベント」を参照)。
– [Dictionary Field Action]:フォームでのユーザの作業に伴って発生するイベントに対応して、データを入力するとともに、フィールド間を移動します。
• [Dictionary Name] 、 [Dictionary Field Name]、[Event] :イベントを「Dictionary Field Action」として指定する場合、ドロップダウン メニューから [Dictionary Name]、[Dictionary Field Name]、および [Event] を選択することにより、アクションを定義する必要があります。「トリガー」イベントは、Web ページ設計者が精通しているイベントに類似していますが、まったく同じではありません。使用可能なイベントのリストは、フィールドに割り当てられた入力タイプに依存して変わる場合あります。たとえば、オプション ボタンには「When the item is clicked」イベントがあり、これはテキスト フィールドには適用できません。
(注) グリッド フィールドは、データ取得ルールの作成時に、「トリガー フィールド」として選択できません。
Query Type に 「Database Table Lookup」を指定した場合、データが存在するデータソースとテーブルを指定する必要があります。データソースを指定すると、[Table Name] のドロップダウン リストに、そのデータソースにアクセス可能なすべてのテーブルが表示されます。
|
|
Service Item Manager の [Design Standards] タブを使用して作成したテーブル、または Service Item Manager の [Import Data] タブを使用してインポートしたテーブルが含まれます。詳細については、「データ取得ルールでの標準の使用」を参照してください。 |
|
仮想マシン サービス項目、ServiceItemHistory テーブルと ServiceItemSubscription テーブル、および Service Item Manager の [Design Service Items] タブで定義された任意のサービス項目が含まれます。詳細については、「データ取得ルールでのサービス項目の使用」を参照してください。 |
Database Table Lookup ルールには、一般に、「Where」句を関連付ける必要があります。これは、指定したテーブルから取得される行を指定する基準です。これらの基準は、取得する行に適合する必要のある 1 つ以上の条件で構成されています。これらの条件では、テーブル内のカラムの値と、リテラルまたはフォーム上のフィールドの現在値を比較できます。
この条件では、Memory テーブル内の行のうち、AssetId カラムがサービス フォーム上の AssetId の現在値に等しい行が取得されます。このようなルールは、一般に、AssetId フィールドの Change イベントとして適用されます。
条件は任意の数だけ入力できます。各条件を入力するごとに、[OK] をクリックします。ここで指定した条件は、ページの最上部に表示されます。複数の条件を使用する場合、行が返されるためには、すべてが true である必要があります(つまり、条件は AND で結合されます)。
検索条件を指定しない場合、指定したテーブル内のすべての行が返されます。これは、一般に、ドロップダウン リスト(単一選択または複数選択)に値を入れるときに発生します。このようなルールを Form Load イベントにアタッチするよりも、フィールドの表示プロパティの一部として、単にテーブル ベースのオプション リストを定義する方が簡単かつ効率的です。
(注) グリッド ディクショナリは、検索条件の作成には使用できません。
ルールで 2 行以上を返すことを想定している場合には、結果が適切な順序になるように、返されるデータをソートする場合があります。任意の数のソート フィールドを指定できます。また、それぞれにソート方向(昇順または降順)を指定できます。各ソート条件を入力するごとに、[OK] をクリックして、ページの最上部に表示されるソート条件に新しいフィールドを追加します。
Distributing Rule つまり「 Distributing Rule with implicit validation performed on the post-Submit event 」では、配布ターゲットを少なくとも 1 つ定義する必要があります。「配布」は、テーブル ベースの検索と SQL クエリーの両方から返される値をフォームでどのように使用するかを定義します。
配布では、クエリー内で返されたカラム値が、サービス内で使用されるフィールドにマッピングされます。各ルールには、1 つ以上の配布を使用できます。たとえば、ドロップダウン リストの値の設定に使用するルールには、1 つの配布のみ使用します(カラムを、単一選択または複数選択の HTML 表現を持つディクショナリにマッピング)。また、ルールで、それぞれ 1 つのカラムを 1 つのディクショナリ フィールドにマッピングする複数の配布を使用する場合があります。ターゲット ディクショナリ フィールドは、フォーム上で書き込み可能である必要はありません。読み取り専用または非表示にすることができます。
ルールは、結果をグリッド ディクショナリと非グリッド ディクショナリの組み合わせに配布すること、また 2 つの異なるグリッド ディクショナリに配布することはできません。1 つのグリッド ディクショナリ フィールドを配布ターゲットとして選択すると、すべての追加ターゲットは、同じディクショナリ内のフィールドに限定されます。
配布のターゲットは、現在のフォーム コンポーネントに含まれていないディクショナリ上のフィールドにできます。参照されるすべてのディクショナリが別のフォーム コンポーネントに含まれること、次にそれが現在のフォーム コンポーネントを持つサービス内に含まれることを保証するのは、サービス設計者の責任です。
次に示すように、[Validating Rule] では、少なくとも 1 つの検証フィールドを定義する必要があります。
この手順を使用して、クエリーによって返されるカラム、つまりクエリー結果に対して検証されるフィールドを選択します。ここで指定する各フィールドの値は、フォームの送信後に、対応するクエリー結果に対して確認されます。フィールド値がいずれの結果にも一致しない場合には、送信が失敗し、エンドユーザに、そのことを示すメッセージが表示されます。
グリッド内のフィールドは、カラム内で複数のセルとしてレンダリングされるため、ここでグリッドとして設定されたディクショナリ内のフィールを選択することはできません。
ルールは、グリッド ディクショナリと非グリッド ディクショナリの組み合わせに対して検証すること、また 2 つの異なるグリッド ディクショナリに対して検証することはできません。1 つのグリッド ディクショナリ フィールドを検証として選択すると、すべての追加検証は、同じディクショナリ内のフィールドに限定されます。
検証フィールドは、現在のフォーム コンポーネントに含まれていないディクショナリ上のフィールドにすることができます。参照されるすべてのディクショナリが別のフォーム コンポーネントに含まれること、次にそれが現在のフォーム コンポーネントを持つサービス内に含まれることを保証するのは、サービス設計者の責任です。
ウィザードの最後のページに、ルール定義が表示されます。[Save] をクリックするとルールが保存され、[Cancel] をクリックするとルール(またはウィザードのこのセクションで行った変更)が廃棄され、または [Previous] をクリックするとウィザードの前のページに戻ります。また、[Active Form Rules] ページでルールを選択することによっても、ルール定義が表示されます。
注意すべき制限の 1 つとして、取得ルールによって選択肢が設定されるオプション ボタン フィールドとチェックボックス フィールドについては、フォーム データがサーバに送信された時点で初めてそのフィールド値が評価および格納されるという点があります。そのため、これらのフィールドの値を検証または使用するすべてのフォーム ルールは、正しく動作しません。
専門的なアラート:データ取得ルールはサーバ上で動作し、バインド変数を使用します。これは、安全であるとともに効率的です。SQL が値を想定している任意の場所で、何らかの名前ではなく、名前空間を使用できます。
Query Type が「Enter Your Own SQL Query」の場合、情報を取得するデータソースを指定する必要があり、また実行される完全な SQL SELECT ステートメントを記述する必要があります。フォーム上でフィールドの値を参照するには、クエリーに、そのフィールドを参照する Lightweight 名前空間を含める必要があります。
(注) 実行時にパーサーにより、名前空間に返される値の前後に、自動的に一重引用符が挿入されます。これは、'datetime' を除くすべてのデータ型に対して行われます。datetime データ型の値は、RDBMS が想定する datetime 形式と正確に一致する必要があります。各 RDBMS は、datetime 形式の設定が異なっている可能性があります。
(注) Query Type に「Database Table Lookup」を選択すると、ウィザードの終わりの [SQL Query] フィールドに、生成された SQL が表示されます(保存時に、フィールド名が [Generated SQL Query] に変わります)。これは、2 番めのタイプを介して、独自の SQL を作成できる開始ポイントとなります。つまり、生成された SQL をコピーし、次にウィザードのステップ 1 に戻り、[Enter Your Own SQL Query] を選択して、生成された SQL を [SQL Statement] フィールドに貼り付けます。
最も単純な場合には、データベース テーブル取得で、互いに AND で結合されたクエリー基準のセットによって単一のテーブルからデータを取得するダイレクト SQL クエリーの結果を複製できます。
ただし、[SQL Query] オプションを使用すれば、さらに複雑な SQL ステートメントを記述できます。指定されたデータソース用に使用されるドライバによってサポートされる任意の SQL ステートメントを指定できます。たとえば、SELECT ステートメントは、次のものを含むことができます。
• 複数のテキスト フィールドを連結する式や算術演算を実行する式。式は、配布に含めるために、エイリアスを設定する必要があります。
• データベース ベンダーによって提供されたデータベース関数と、ユーザ定義のデータベース関数の両方(プロシージャは未サポート)。
• SQL ステートメントは、SQL プロセッサによって検証されます。@ や # などの記号は、フォーム データ処理で特殊な意味を持ち、特定のコンテキストではサポートされません。
• この時点では、Microsoft SQL Server の CASE-WHEN 構文はサポートされていません。
独自の SQL クエリーを記述する理由として考えられるのは、「LIKE」比較を行うことです。たとえば、Lightweight 名前空間 #Hardware.ServerName# によって参照されるディクショナリ フィールドにユーザが入力した検索文字列を含む名前を持つサーバをすべて取得する場合です。LIKE 演算子は、一般にワイルドカード(%)を検索文字列のプレフィックスまたはサフィックスとして使用します。SQL ステートメントにワイルドカードを使用するときは、個別に引用符で囲んで入力する必要があります。
DBA または IT アナリストがユーザのために SQL クエリーを記述してデバッグする場合を除き、作業を行う SQL 開発環境が必要になります。Data Retrieval ウィザードは、SQL を検証するにもかかわらず、SQL が無効な場合に役立つヒントを提供しません。そのため、他の環境が必要になります。詳細については、「データ取得ルール作成の前提条件」を参照してください。
Laptop Selection の例では、グリッド内でドロップダウン メニューからフィールドが選択された場合に、グリッド サービス項目ディクショナリとデータ取得ルールを使用して、サービス項目データを自動的に取得する方法を示します。また、データ取得ルールには、データ インスタンスを検索から除外する検索条件が含まれます。
2. 新しいディクショナリ グループとグリッド ディクショナリを作成
4. グリッド ディクショナリをフォームおよび編集表示プロパティに追加
7. フォームを、My Services のサービスおよび表示サービスに追加
ステップ 1 [Service Item Manager] > [Design Service Items] を選択します。[Design Service Items] ページが表示されます。
ステップ 2 次に示すように、プラス記号(+)をクリックし、[Service Item Group] を選択します。
ステップ 3 グループ名(この場合は Dave Group)を入力し、表示される [Add New Service Item Group] ポップアップ ウィンドウの対応するフィールドに任意で説明を入力して、[Add] をクリックします。左側の [Service Items] パネルに、新しいサービス項目グループが表示されます。
ステップ 4 もう一度プラス記号(+)をクリックし、[Service Item] を選択します。
ステップ 5 [Add New Service Item] ポップアップ ウィンドウで、[Display Name] フィールドに Laptops、[Name] フィールドに Laptop_Service_Item と入力します。[Group] ドロップダウン メニューで、作成したサービス項目グループ [Dave Group] を選択して、[Add] をクリックします。左側の [Service Items] パネルに、Dave Group という名前の新しいサービス項目が表示されます。
ステップ 6 次に示すように、ページの下部にある [Add] を 5 回クリックして、[Laptops] サービス項目に 5 つの属性を追加します。各属性または行は、サービス項目インスタンスです。各属性の [Display Name] は、グリッドのカラム ヘッダーになります。
ステップ 7 すべての属性を追加した後、ページの下部にある [Save] をクリックします。
ステップ 8 Service Designer モジュールの [Dictionaries] コンポーネントを選択します。
ステップ 9 次に示すように、[New] > [New Dictionary Group] を選択します。
ステップ 10 表示される [New Dictionary Group] ウィンドウの [Title] フィールドに、この例では Dave Dictionary Group と入力します。必要に応じて、グループに関する説明を入力します。
ステップ 11 [Add This Dictionary Group] をクリックします。左側の [Dictionaries] ツリーに、新しいグループが表示されます。
ステップ 12 [New] > [New Dictionary] を選択します。[New Dictionary] ウィンドウが表示されます。
ステップ 13 次に示すように、[Add New Internal Dictionary] セクションの [Service Item] フィールドに Laptops と入力して、作成した [Laptops] サービス項目を検索し、次に表示されるポップアップ ウィンドウで [Laptops] をクリックします。
ステップ 14 次の例に示すように、表示される [Dictionary] ウィンドウでディクショナリの各フィールドを設定します。[Dictionary Name] フィールドと [Default Caption] フィールドに Laptops と入力します。[Default Caption] は、グリッドのタイトルとして表示されます。[Group Name] ドロップダウン メニューから、今作成したディクショナリ グループ [Dave Dictionary Group] を選択します。[Use] カラムと [Show in Grid] カラムで、自分が作成した Laptops サービスの 5 つのインスタンスのみオンにします。[Use] と [Show in Grid] をチェックすることにより、そのインスタンスがグリッド内にカラムとして表示されます。デフォルトで、[Name] フィールドはすでにオンになっており、変更はできません。
ステップ 15 [Save Dictionary] をクリックします。
ステップ 16 Service Designer モジュールの [Active Forms Components] コンポーネントを選択します。
ステップ 17 次に示すように、[New] > [Form Group] を選択します。
ステップ 18 表示される [Form Group] ウィンドウの [Name] フィールドに、この例では Dave Form Group と入力します。必要に応じて、グループに関する説明を入力します。
ステップ 19 [Save] をクリックします。左側の [Active Form Components] ツリーに、新しいフォーム グループが表示されます。
ステップ 20 [New] > [Active Form Component] を選択します。
ステップ 21 表示される [New Active Form Component] ウィンドウの [Name] フィールドに、この例では Laptop Selection と入力します。必要に応じて、フォームに関する説明を入力します。[Form Group] フィールドの右にある参照ボタン( )をクリックします。表示される [Search] ポップアップ ウィンドウで、作成したフォーム グループを検索するために Dave Form Group と入力して、[Search] ボタンをクリックします。そのオプション ボタンを選択した状態で、[Add] をクリックして、[From Group] フィールドに Dave Form Group を入力します。
ステップ 23 [Add Dictionaries] を選択します。[Add Dictionaries] ポップアップ ウィンドウが表示されます。
ステップ 24 [Search] フィールドで、Laptops と入力して、作成した [Laptops] ディクショナリを検索します。
ステップ 25 次に示すように、表示される [Laptop] ディクショナリで、[Name] カラムと [Display as Grid] カラムをオンにします。[Display as Grid] をオンにすると、[Show in Grid] にチェックされた [Laptops] ディクショナリのフィールドが、グリッド内にカラムとして表示されます。
ステップ 26 [Add] をクリックして、Laptops ディクショナリをフォームに追加します。[Laptop Selection] フォームの [Form Content] タブに、[Display as Grid] がチェックされた状態で [Laptops] ディクショナリが表示されます。ここではグレーアウトされており、変更できないことに注意してください。変更する唯一の方法は、削除した後、[Display as Grid] をオンにせずにもう一度追加することです。
ステップ 27 [Save Form] をクリックしてフォームを保存します。
ステップ 28 [Laptop Selection] フォームの [Display Properties] タブをクリックします。
ステップ 29 次に示すように、[Enable automatic retrieval of service item instance data] をオンにします。このオプションは、デフォルトでは無効になっています。このオプションを使用すると、既存のサービス項目インスタンスに関するデータを自動的に取得および事前に入力できるようになります。この例では、[Grid Options] をデフォルトの選択および値のままにします。特に、ユーザがグリッド行を追加できるようにするために、Edit アクセス コントロールを付与したい場合があります。
ステップ 31 左側の Laptops ディクショナリの下の [Name] フィールドをクリックして、その HTML 表現ウィンドウを表示します。[Input Type] フィールドで、ドロップダウン メニューから [select (single)] を選択します。[Select Single] の [Input Type] では、[Name] フィールドは、単一の値のみ選択できるドロップダウン メニューとしてレンダリングされます。また、[Columns] 値を 32 に変更すると、[Name] カラムの幅が小さくなります。
ステップ 33 Laptop ディクショナリの残りの各フィールドを選択し、[Label] フィールドを変更してアンダースコア文字を削除し、「GB」の前後にカッコを追加します。また、[RAM] フィールドと [Hard Disk] フィールドの [Columns] 値を 32 に変更し、すべてのカラムを同じ幅にします。各フィールドを変更した後、右下の [Save] をクリックします。
ステップ 34 [Laptop Selection] フォームの [Active Form Rules] タブをクリックします。
ステップ 35 次に示すように、ウィンドウの左下の [New Rule] > [New Data Retrieval Rule] を選択します。
ステップ 36 Data Retrieval Rule ウィザードのステップ 1 が表示されます。[Rule Name] フィールドと [Description] フィールドに Get Laptop Names と入力します。[Rule Type] を [Distributing Rule] に設定し、[Query Type] が [Database Table Lookup] に設定されたままにします。
ステップ 38 Data Retrieval Rule ウィザードのステップ 2 が表示されます。次に示すように、トリガー イベントとして [Form Load] を選択します。
ステップ 40 Data Retrieval Rule ウィザードのステップ 3 が表示されます。次に示すように、[Datasource] ドロップダウン メニューから [Service Items] を選択し、[Table Name] ドロップダウン メニューから [Laptops] を選択します。[Laptops] は前もって作成したサービス項目です。
ステップ 42 Data Retrieval Rule ウィザードのステップ 4 が表示されます。データ インスタンス「HP」を [Brand_Name] フィールドから除外する検索条件を作成するには、次に示すように、[Table Column Name] ドロップダウン メニューから [Brand_Name] を選択し、[Operator] ドロップダウン メニューから [is not equal to] を選択し、さらに [Literal Value] フィールド(そのオプション ボタンをオンにする)に HP と入力します。[OK] をクリックします。
ステップ 44 Data Retrieval Rule ウィザードのステップ 5 が表示されます。[Table Column Name] フィールドでドロップダウン メニューから [Name] を選択し、[Sort Direction] の [Ascending] オプション ボタンを選択します。[OK] をクリックして、ソート方向を定義します。
ステップ 46 Data Retrieval Rule ウィザードのステップ 6 が表示されます。Laptops サービス項目の [Name] カラムを [Laptops] ディクショナリの [Name] フィールドにマッピングするには、次に示すように、3 つのドロップダウン メニューからそれらの項目を選択し、[OK] をクリックします。
(注) [Laptops] の横の「*」は、[Laptops] がグリッド ディクショナリであることを示しています。
ステップ 48 次に示すように、Data Retrieval Rule ウィザードのステップ 7 が表示されます。
ウィザードのこの最終ページでは、ルールを確認した後、保存できます。すべての内容を正しく入力したことを確認してください。直前のステップに戻って変更を行う必要がある場合には、[Previous] ボタンをクリックします。ルールを保存した後、いつでも戻ってルールを編集できます。
ステップ 49 [Save] をクリックして、Data Retrieval Rule ウィザードを終了します。
ステップ 50 [Service Designer] モジュールの [Services] コンポーネントを選択します。
ステップ 51 次に示すように、[New] > [New Service Group] を選択します。
ステップ 52 表示される [New Service Group] ウィンドウの [Name] フィールドに、この例では Dave Service Group と入力します。[Service Team] ドロップダウン メニューから [Site Administration] を選択します。必要に応じて、グループに関する説明を入力します。
ステップ 53 [Add This Service Group] をクリックします。左側の [Services] ツリーに、新しいグループが表示されます。
ステップ 54 [New] > [New Service] を選択します。
ステップ 55 表示される [New Service] ウィンドウの [Name] フィールドに、この例では Laptop Upgrade と入力します。説明として、「Upgrade one or more laptops.」と入力します。[Service Group] ドロップダウン メニューから、今作成したサービス グループ [Dave Service Group] を選択します。
ステップ 56 [Add This Service] をクリックします。Laptop Upgrade サービスの [General] タブが表示されます。
ステップ 57 Laptop Upgrade サービスの [Form] タブを選択します。
ステップ 58 ウィンドウの左下の [Add Forms...] を選択します。[Add Form] ポップアップ ウィンドウが表示されます。
ステップ 59 [Search] フィールドで、Laptops Selection と入力して、以前作成した [Laptops Selection] フォームを検索します。
ステップ 60 次に示すように、Laptop Selection フォームをチェックして、[Add] をクリックします。
ステップ 61 次に示すように、Laptop Selection フォームが [Laptop Upgrade] サービスに追加されます。
ステップ 62 ここで、ユーザにはフォームがどのように見えるか表示してみます。Service Portal で、[My Services] モジュールを選択します。
ステップ 63 [Search for Services containing:] フィールドに Laptop Upgrade と入力して、[Search] をクリックします。次に示すように、Laptop Upgrade サービスが表示されます。
ステップ 64 次に示すように、[Order] をクリックして、作成したグリッドを表示します。
グリッドは、ディクショナリの [Default Name] から取った「Laptops」というヘッダー付きで表示されます。カラム ヘッダー名は、ディクショナリ フィールドの [HTML Representation Label] フィールドから取られます。
ステップ 65 [Name] フィールドの [Input Type] に [select (single)] を選択したため、[Name] フィールドは、単一の値のみ選択できるドロップダウン メニューとして表示されます。[Name] カラムの最初の行内をクリックし、ドロップダウン メニューから名前を選択します。残りのフィールドは、自動的に埋められます。これは、フォーム ディクショナリの [Enable automatic retrieval of service item instance data] をチェックし、[Laptops] サービス項目の [Name] カラムを [Laptops] ディクショナリの [Name] フィールドにマッピングしたために行われます。
ステップ 66 [Add] 行アイコン( )をクリックして、作成した他の 2 行のサービス項目データを入力します。データ取得ルールのステップ 3 で、[Brand_Name] フィールド内で「HP」のデータ インスタンスが選択から除外されるように検索条件を作成したため、「name3.lt」は [Name] ドロップダウン メニューに表示されません。
View All Laptops の例では、データ取得ルールを使用してグリッド上のすべてのサービス項目インスタンスに値を入力する方法、および条件付きルールを使用してディクショナリを読み取り専用にする方法を示します。
(注) View All Laptops の例では、前の Laptop Selection の例と同じグリッド サービス項目ディクショナリを使用するため、View All Laptops の例の前に Laptop Selection の例を実行する必要があります(「例:Laptop Selection」を参考)。
2. グリッド ディクショナリをフォームおよび編集表示プロパティに追加
6. フォームを、My Services のサービスおよび表示サービスに追加
ステップ 1 [New] > [Active Form Component] を選択します。
ステップ 2 表示される [New Active Form Component] ウィンドウの [Name] フィールドに、この例では View All Laptops と入力します。必要に応じて、フォームに関する説明を入力します。[Form Group] フィールドの右にある参照ボタン( )をクリックします。表示される [Search] ポップアップ ウィンドウで、Dave Form Group と入力し、[Search] をクリックします。そのオプション ボタンを選択した状態で、[Add] をクリックして、[From Group] フィールドに Dave Form Group を入力します。
ステップ 4 [Add Dictionaries] を選択します。[Add Dictionaries] ポップアップ ウィンドウが表示されます。
ステップ 5 [Search] フィールドで、Laptops と入力して、[Laptops] ディクショナリを検索します。
ステップ 6 表示される [Laptop] ディクショナリで、[Name] カラムと [Display as Grid] カラムをオンにします。[Display as Grid] をオンにすると、[Show in Grid] にチェックされた [Laptops] ディクショナリのフィールドが、グリッド内にカラムとして表示されます。
ステップ 7 [Add] をクリックして、Laptops ディクショナリをフォームに追加します。[View All Laptops] フォームの [Form Content] タブに、[Display as Grid] がチェックされた状態で [Laptops] ディクショナリが表示されます。ここではグレーアウトされており、変更できないことに注意してください。変更する唯一の方法は、削除した後、[Display as Grid] をオンにせずにもう一度追加することです。
ステップ 8 [Save Form] をクリックしてフォームを保存します。
ステップ 9 [View All Laptops] フォームの [Display Properties] タブをクリックします。
ステップ 10 次に示すように、Laptops ディクショナリの [Properties] の [Grid Options] セクションで、[Allow user with Edit access control to add/delete rows] のチェックをオフにします。
ステップ 12 左側の Laptops ディクショナリの下の [Name] フィールドをクリックして、その HTML 表現ウィンドウを表示します。[Columns] 値を 32 に変更すると、[Name] カラムの幅が小さくなります。Laptop ディクショナリの残りの各フィールドを選択し、[Label] フィールドを変更してアンダースコア文字を削除し、「GB」の前後にカッコを追加します。また、[RAM] フィールドと [Hard Disk] フィールドの [Columns] 値を 32 に変更し、すべてのカラムを同じ幅にします。各フィールドを変更した後、右下の [Save] をクリックします。
ステップ 13 [View All Laptops] フォームの [Active Form Rules] タブをクリックします。
ステップ 14 ウィンドウの左下の [New Rule] > [New Data Retrieval Rule] を選択します。
ステップ 15 Data Retrieval Rule ウィザードのステップ 1 が表示されます。[Rule Name] フィールドに Get All Laptops と入力し、[Description] フィールドに Get all laptop information in grid と入力します。[Rule Type] を [Distributing Rule] に設定し、[Query Type] が [Database Table Lookup] に設定されたままにします。
ステップ 17 Data Retrieval Rule ウィザードのステップ 2 が表示されます。トリガー イベントとして [Form Load] を選択します。
ステップ 18 Data Retrieval Rule ウィザードのステップ 3 が表示されます。[Datasource] ドロップダウン メニューから [Service Items] を選択し、[Table Name] ドロップダウン メニューから [Laptops] を選択します。
ステップ 20 Data Retrieval Rule ウィザードのステップ 4 が表示されます。検索条件を作成しないので、単に [Next] をクリックして続行します。
ステップ 21 Data Retrieval Rule ウィザードのステップ 5 が表示されます。[Table Column Name] フィールドでドロップダウン メニューから [Name] を選択し、[Sort Direction] の [Ascending] オプション ボタンを選択します。[OK] をクリックして、ソート方向を定義します。
ステップ 23 Data Retrieval Rule ウィザードのステップ 6 が表示されます。[Laptops] サービス項目のカラムを [Laptops] ディクショナリのフィールドにマッピングするには、次に示すように、ドロップダウン メニューからそれらの項目を選択し、各々の後に [OK] をクリックします。
(注) [Laptops] の横の「*」は、[Laptops] がグリッド ディクショナリであることを示しています。
ステップ 25 Data Retrieval Rule ウィザードのステップ 7 が表示されます。
ウィザードのこの最終ページでは、ルールを確認した後、保存できます。すべての内容を正しく入力したことを確認してください。1 ステップ前に戻って変更を行う必要がある場合には、[Previous] をクリックします。ルールを保存した後、いつでも戻ってルールを編集できます。
ステップ 26 グリッドを専用にするには、条件付きルールを作成してグリッド ディクショナリを読み取り専用にします。ウィンドウの左下の [New Rule] > [New Conditional Rule] を選択します。
ステップ 27 Conditional Rule ウィザードのステップ 1 が表示されます。[Rule Name] フィールドに Make Laptop Dictionary Read-Only と入力します。必要に応じて、フォームに関する説明を入力します。
ステップ 28 検索条件を追加しないので、単に [Next] をクリックして続行します。
ステップ 29 Conditional Rule ウィザードのステップ 2 が表示されます。次に示すように、[Add Action] ドロップダウン メニューをクリックして、[Make Read-Only] を選択します。
ステップ 30 次に示すように、[Make Read-Only] ドロップダウン メニューで、ディクショナリとして [*Laptops] を選択し、フィールドとして [All fields] を選択します。[OK] をクリックしてアクションを追加します。
ステップ 32 Conditional Rule ウィザードのステップ 3 が表示されます。
ウィザードのこの最終ページでは、ルールを確認して保存できます。すべての内容を正しく入力したことを確認してください。1 ステップ前に戻って変更を行う必要がある場合には、[Previous] をクリックします。ルールを保存した後、いつでも戻ってルールを編集できます。
[Automatic Associations (Recommended)] セクションで、[When the form loads (browser-side)] チェックボックスをオンにします。他のチェックボックスはオフにします。
ステップ 33 [Save] をクリックして、Conditional Rule ウィザードを終了します。
ステップ 34 [Service Designer] モジュールの [Services] コンポーネントを選択します。
ステップ 35 [New] > [New Service] を選択します。
ステップ 36 表示される [New Service] ウィンドウの [Name] フィールドに、この例では View All Laptops と入力します。説明として「View all laptop information in grid」と入力します。[Service Group] ドロップダウン メニューから [Dave Service Group] を選択します。
ステップ 37 [Add This Service] をクリックします。View All Laptops サービスの [General] タブが表示されます。
ステップ 38 View All Laptops サービスの [Form] タブを選択します。
ステップ 39 ウィンドウの左下の [Add Forms...] を選択します。[Add Form] ポップアップ ウィンドウが表示されます。
ステップ 40 [Search] フィールドで、View All Laptops と入力して、以前作成した [View All Laptops] フォームを検索します。
ステップ 41 [View All Laptops] フォームを選択し、次に [Add] をクリックします。
[View All Laptops] フォームが、View All Laptops サービスに追加されます。
ステップ 42 ここで、ユーザにはフォームがどのように見えるか表示してみます。Service Portal で、[My Services] モジュールを選択します。
ステップ 43 [Search for Services containing:] フィールドに View All Laptops と入力して、[Search] をクリックします。View All Laptops サービスが表示されます。
ステップ 44 次に示すように、[Order] をクリックしてグリッドを表示します。
グリッドは読み取り専用であり、すべてのサービス項目インスタンス データが入力された状態で表示されます。
条件付きルールを使用することにより、設計者は、サービス フォームの動作と外観を変更できます。条件付きルールには、次のコンポーネントがあります。
ルールの定義後、1 つ以上のトリガー イベントにアタッチします。ルールは、たとえば、サービス フォームを含むページが最初にユーザのブラウザにロードされたとき、ユーザが特定フィールドの値を変更したとき、ユーザが開始したその他のアクションに対応して起動されます。ルールに対して最もよく発生するトリガー イベントは、ルールを定義するときに一覧表示される自動的な関連付けを使って最初に指定しておきます。[Active Form Behavior] タブを使用して、これらのアタッチ内容を確認/変更すること、またはその他のイベントを追加することができます。
条件付きルールは、「エンドユーザとの会話」中(つまり、ブラウザ セッション中)、および「会話」の前後(つまり、サーバ側)の両方でロジックを適用する強力なメカニズムです。しかし、条件付きルールを効果的に使用するためには、ブラウザ内で実行可能な内容と サーバ側で実行可能な内容を理解する必要があります。さらに、ディクショナリ フィールドを表現および格納する方法、およびグリッド ディクショナリ内のフィールドとそれに対応する非グリッドのフィールドがどのように異なるか、理解する必要があります。
Conditional Rule ウィザード(この項で詳細に説明)は、たとえば、どのアクションがブラウザ側またはサーバ側に限定されるか、およびグリッドでは何が実行可能で、何が実行可能でないかを説明することにより、効果的なルールの作成を支援します。
Conditional Rule ウィザードの最初のページ( ステップ 1 )では、 ゼロ個以上 の条件句を指定することにより、条件を設定できます。条件が指定されていない場合、[Active Form Behavior] タブを使用して指定されたトリガー イベント時に、アクションが無条件に実行されます。
各コンポーネント条件は、true または false で評価されます。複数の条件句は、優先順位の標準的な関係ルール、および AND 演算と OR 演算を使用して結合できます。条件が true(つまり、すべての条件句の組み合わせが true)に評価される場合、指定されたすべてのアクションがトリガー イベント時に実行されます。
(注) グリッド ディクショナリとそのフィールドは、条件付きルールの「トリガー条件」に選択できません。
たとえば、サービス フォームで役立つ条件、およびその結果として実行されるアクションには、次のものがあります。
|
|
その場合には、同じディクショナリ内の Description フィールドを表示し、ユーザに対して追加情報を入力するように要求する。 |
|
[Add Condition] をクリックして、各条件句を作成します。どの「条件」を選択するかによって、多少異なる [Condition Builder] ダイアログが表示され、ユーザに対して完全な条件を作成するように要求します。
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# を使用して、複数のサービス内で発生する同じタスクを区別できます。条件付きルールで使用される Task Name では、すべての名前空間の参照が正しく評価されます。文字列操作(タスク名の先頭と終端のみ確認、またはタスク名に特定のフレーズが含まれるかを確認)を使用して、名前空間に由来しないタスク名部分を比較できます。
条件内の 演算子:使用できる演算子はコンテキストによって異なり、選択した条件に依存するドロップダウン リストに表示されます。たとえば、フィールドには数字、英数字、または日付データを含めることができるため、算術演算と文字列演算の両方が許可されるだけでなく、フィールドの用途を判断する演算子も許可されます。タスク名とサービス名はテキストであるため、文字列演算のみ該当します。true または false のいずれかの値をとる条件の場合、または可能なオプションの数が限定されている(現在のコンテキストなど)条件の場合には、オプション ボタンを使用できます。
|
|
|
|
|
|
ディクショナリ フィールドに適用可能な大部分の演算子は、そのフィールドの値を確認し、特定のフィールドの値またはリテラルと比較します。これらの演算子のうち、「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 つのルールを定義します。
|
|
ルール 1:DatabaseType_Other |
|
ルール 2:DatabaseType_Defined |
ウィザードの 2 ページめ( ステップ 2 )には、ルールのアクションが表示されます。[Add Action] をクリックして、各アクションを追加します。ルールに関連付けられたアクションは、指定された順に実行されます。
フィールドとディクショナリの表示と非表示の切り替え。条件付きルールは、フォーム上の別のフィールドの現在値または指定された他の条件に基づいて、フィールドやディクショナリの表示と非表示を切り替えるために、頻繁に使用されます。ディクショナリ内のすべてのフィールドではなく、大部分のフィールドを非表示にする必要がある場合には、ディクショナリを非表示にした後、必要なフィールドだけを表示します。フィールドがルールによって非表示になっていても、その値は、引き続き他の条件付きルールでアクセスできます。
フィールドを必須または任意に設定。フィールドを必須にすることは、Service Designer を使用してフィールドを必須に指定するのと同じ効果があります。
• 必須であることを表す記号が、フィールド ラベルの左に表示されます。
• フォームを正しく送信するためには、ユーザが値を入力する必要があります。
• 管理設定にフォーム モニタが含まれる場合には、値が指定されるまで、モニタはディクショナリを不完全なものとして表示します。
フィールド(またはディクショナリ)を非表示に設定している場合、必須に設定されたフィールドがディクショナリ内に存在しないことを確認する必要があります。必須フィールドが存在する場合には、ユーザがフォームを送信しようとすると、エラー メッセージが表示されます。ルール(または ISF)を使用して、フィールドの必須と任意を切り替える場合、フィールドの HTML 表現を使用してフィールドを任意に設定する必要があります。HTML 表現ですでに必須としてマークされているフィールドを、条件付きルールを使用して上書きすると、予期しない動作が発生します。
必須フィールドが読み取り/書き込みモードの間で切り替えられる場合は、読み取り専用に設定されるときにそのフィールドを任意に設定するか、または無効にすることにより、ユーザの混乱を防止する必要があります。
フィールドにフォーカスを設定。フォーム上のフィールドは、フィールド内にカーソルがあり、データを入力できる場合、「フォーカスを持つ」と言います。フィールド内をマウスをクリックするか、またはフォーム内のフィールド間を Tab で移動すると、フィールドは自動的にフォーカスを取得します。Set Focus アクションで、指定したフィールドに明示的にフォーカスを設定できます。これは、一般に、アラート後、またはフォームでの送信が停止した後に、問題のあるフィールドにユーザの注目を向けさせるために使用されます。
フィールド値を設定。フィールド値を設定するときには、フィールドのデータ型と HTML 表現を考慮する必要があります。
|
|
Person 要素の HTML 表現は、実際にはその Person の名前(フォーム上に表示される)と Person の ID(非表示)の 2 つの項目で構成されています。SetValue コマンドは、これらの両方を設定する必要があります。 |
値にリテラルまたは式の結果が設定されている場合、そのリテラルまたは式には、現在のサービスで使用される任意の数の数字フィールドまたはテキスト フィールドを含めることができます。(日付算術演算はサポートされません)。フィールドは、Lightweight 名前空間構文を使用する式(# DictionaryName.FieldName #)で表現されます。
式が無効(たとえば、ゼロ除算を含む)な場合、その式は処理対象から除外されます。値は更新されません。また、同じイベントに対して残りのアクションまたはルールが存在する場合、それらが引き続き実行されます。ユーザには、エラー メッセージが表示されません。
フィールドの [Editable only on server-side] 設定は、[Set Value] の動作にも影響を及ぼします。[Editable only on server-side] とマーク付けされたフィールドは、ブラウザ セッション中に値を傍受しようとしても、できないように保護されます。自動取得に対応している個人ベースのディクショナリとサービス項目ベースのディクショナリの場合、[Editable only on server-side] 設定が有効な場合には、データベースから取得される属性値が、ブラウザから送信される値よりも常に優先されます。その理由から、このようなフィールドに適用するすべての Set Value アクションは、Post-Submit イベントに関連付けられたルール内に存在する必要があります。言いかえれば、Set Value を使用してフィールドを編集できますが、それはサーバ側イベントに限定されます。
サービス価格の設定。Set Price アクションは、サービスの動的な価格設定をサポートします。価格には、Set Value アクションの場合と同じルールを使用して、定数、別のフィールドの値、または式の計算結果を設定できます。Set Price アクションは、任意のイベントによってトリガーされるルールに含めることができますが、新しい価格は、サービス フォームが送信されたときにのみ実際に効力を持ちます。トランザクションがキャンセルされると、新しい価格は記録されません。
新しい価格は、フォームが送信されたときにのみ実際に効力を持つため、Set Price を含むルールの実行のために選択する必要のある最も適切なイベントは、Post-Submit です。
ウィザードの最後のページ( ステップ 3 )には、ルールの定義が表示されます。[Previous] をクリックして、条件とアクションの一方または両方を変更できます。
このページの [Automatic Associations] 部分では、このルールを 1 つ以上のトリガー イベント([Set this rule to fire:])にアタッチできます。
• [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)]:このサーバ側ルールは、ブラウザ上でフォームが送信された後、および処理のためにサーバに送信された後で、サーバ上で実行されます(「サーバ側イベント」を参照)。
これらのチェックボックスは、[Active Form Behavior] タブを通して、該当するイベントにルールをアタッチするためのショートカットです。既存のルールを編集する場合、これらのチェックボックスは表示されません。[Active Form Behavior] タブでルールがアタッチされたイベントを確認または変更する必要があります(「アクティブ フォームの動作」を参照)。
既存のデータ取得ルールまたは条件付きルールを変更するために、ルールを編集し、必要な変更を適用し、Rule Wizard のすべてのページをナビゲートする必要があります。[Save] ボタンは、各ウィザードの最後のページでのみ使用できます。このプロセスにより、ルールのすべての側面が内部的に整合していることが保証されます。
ディクショナリとフィールドに対する変更は、対応するディクショナリ、フィールド、または Lightweight 名前空間を使用するルールに、自動的には反映されません。ディクショナリまたはフィールドの名前を変更する場合には、すべてのページをナビゲートして、ルールを編集する必要があります。条件付きルールとテーブル ベースのデータ取得ルールの場合には、ディクショナリやフィールドに対する参照は、各ページに進むごとに自動的に更新されます。SQL 入力データ取得ルールの場合には、正しい Lightweight 名前空間を使用して、SQL を再入力する必要があります。
フィールドまたはディクショナリを削除する場合には、ルールを編集して、削除されるオブジェクトへの参照を削除する必要があります。以前機能していたルールが突然機能しなくなった場合には、名前が変更されたオブジェクトまたは削除されたオブジェクトが、そのままの状態でルール内から参照されていることが原因の可能性があります。
[Active Form Behavior] タブでは、サービス設計者がサービス フォームの処理中に発生したイベントに条件付きルールおよび ISF 関数(JavaScript)をアタッチすること、ルールまたは関数をフォームから分離すること、およびルールの実行順序を変更することができます。
フォームを強調表示(上記の [This Active Form Component])するか、または特定のディクショナリおよびフィールドにドリル ダウンし、適切なイベントを選択することによって、トリガー イベントを選択します。
フォーム レベルおよびフィールド レベルのトリガー イベントには、次のものがあります。
|
|
コードまたはルールは、[Submit] ボタンまたは [Update] ボタンをクリックした 後 、およびフォームの [Display] で指定されたすべての検証(数値データや必須データの確認など)の 後で 、フォームがサーバに送信される 前 に実行されます。これにより、通常、データがサーバに送信される前に追加の検証、フォーマット、または任意の処理を実行するためのウィンドウが表示されます。 |
|
コードまたはルールは、My Services または Service Manager にサービス フォームが最初に表示されるときに実行されます。ディクショナリ内のフィールドに値を入力するコード、またはブラウザにフォームがレンダリングされる前に何らかのフォーム メッセージングを実行するコードを追加する際に、ここが 最適な 場所となります。これは、HTML イベントの body ... onLoad に対応しています。 |
|
このイベントは、フォームを閉じるときに呼び出されます。このイベントは、ウィンドウを閉じると失われるデータをユーザに通知するために使用できます。これは、HTML イベントの body ... onUnload に対応しています。 |
|
サーバ フォームは、ブラウザに送信される前にサーバで準備されています(「サーバ側イベント」を参照)。これは、サーバ専用の編集可能フィールドに影響を与えるルールをアタッチする最適な場所です。また、データ検証を適用する最適な場所でもあります。これは、すべてのデータ取得検証(および暗黙的な検証)ルールが、自動的にここにアタッチされる理由となります。 |
|
このサーバ側イベントは、ブラウザに送信する前にサーバ側で実行されます(「サーバ側イベント」を参照)。 |
(注) JavaScript 関数は、サーバ側トリガーにアタッチすることはできません。
|
|
別のフィールドに Tab キーで移動するか、別のフィールド内をマウスでクリックすることにより、ユーザが指定されたフォーム フィールドを終了します。 |
|
ルールまたは JavaScript(関数)は、必要な数だけ追加できます。Active Form ウィザードの [Automatic Associations] オプションを使用して以前アタッチしたルールも表示されます。ルールの実行順序は、リスト内でルールを上下に移動することによって変更できます。関数の実行順序は決まっていません。この動作の回避策については、本書の「ISF を利用」の項で説明します。
[Customer Information] フォームは、データベースから(Lightweight 名前空間を介して)いくつか暗黙的なルックアップを実行します。この取得は、ルールまたは関数がフォーム ロード イベントで実行される前に行われます。
サービスに複数のフォームがあり、各フォームにフォーム ロード イベントのルールや JavaScript 関数が存在する場合、ルールはサービスに属するフォームの見た目上の順序どおりに実行され、その後に JavaScript が続きます。
複数のサービスは、1 つの親サービスと 1 つ以上の子サービスで構成されている 1 つのサービス バンドルとして結合できます。要求者がサービス バンドル/親サービスをオーダーすると、サービス フォームの内容、外観、および動作が調整されます。アクティブ フォーム コンポーネントの動作は、以下を除いて変更されません。
• 子サービスのフォーム レベル イベント(フォームがロードまたは送信されている場合)にアタッチされているルールまたは JavaScript は、無視されます。これらのルールを指定するフォーム コンポーネントは、親サービスに含まれる必要があります。
• ディクショナリが重複する場合は自動的に解消されます。つまり、あるディクショナリが複数の子サービスに存在する場合、サービス バンドルでは 1 つだけ含まれるようになります。ディクショナリの設定は、そのディクショナリが含まれているアクティブ フォーム コンポーネントを含んでいる最初の子サービスで指定されている設定と一致します。ディクショナリの設定がサービスによって異なる場合(たとえば、サービス固有のルールを適用)、その差異は無視されます。
Service Portal を使用すると、サービス フォームをすばやく簡単に作成できます。ただし、サービス提供プロセスの複雑なビジネス要件や技術要件を満たすフォームを作成し、さらに使いやすさとエンドユーザに対する応答性を維持する作業は、容易ではありません。これは、エンドユーザと円滑に「会話」するとともに、ダウンストリーム、つまり協調して動作するサードパーティ システムまたは手動で手順を実行する必要があるサービス提供担当者が必要とするすべてのデータを収集する作業をバランス良く実行することだと考えられます。
この点を念頭に置いて、次に最適なサービス フォームを設計するためのガイドラインおよび原則を示します。
以前のリリースの Service Portal では、操作が必要なディクショナリ フィールドは、ブラウザに送信して操作する必要がありました。リリース 9.3.2 では、サーバ側イベントが追加されたことにより、その必要がなくなりました。
サーバ側イベント(詳細については、「フォームとフィールドのトリガー イベント」を参照)は、エンドユーザが権限を持たないディクショナリ(Read および Edit のアクセス コントロールなし)内のフィールドの値を更新する強力なメカニズムです。サーバ側イベントで実行されるルールは、HTML 表現で「Editable on server-side only」フラグの付いたフィールドの値も操作できます。
ブラウザにロードされていないディクショナリのデータをサーバ側イベントを使用して操作すると、2 つの利点があります。まず、ブラウザ セッションに送信されるデータ量が減少します。これにより、フォームのロード時に知覚されるパフォーマンスを向上できます。2 番めに、機密性が高いデータをサーバ側での実行の制御下に置くことにより、データを傍受できないようにします。
これらの理由から、特定のデータがどうしてもブラウザ内になければならないのかという視点で確認し、フィールドをディクショナリにグループ化する必要があります。少なくともオーダー時点でブラウザ セッションにロードする必要のないフィールドは、1 つ以上の「非ロード」ディクショナリ(View および Edit アクセス コントロール権限を持たないディクショナリ)にまとめてグループ化する必要があります。「非ロード」ディクショナリの一般的な例としては、パラメータを調整エージェントに提供するディクショナリがあります。調整機能は通常、フォームに表示されるデータより多くのデータを必要とします。このデータは通常、ユーザが誰か、ユーザのロールは何か、ユーザの OU メンバーシップは何かなどを判断する条件付きルールまたはデータ取得ルールを通して取得されます。これらはすべて、フォームがブラウザにロードされる前(Pre-Load イベント中)、またはユーザが [Submit] ボタンをクリックした際(Post-Submit イベント中)のいずれかが、抽出する最適なタイミングとなります。
Post-Submit イベントが発生するまで設定されている値を確認できないため、「非ロード」のディクショナリで動作するルールの効果を確認するには、通常よりも多くのテストを必要とします。したがって、「非ロード」のディクショナリの使用には通常、フォームで定義されたすべてのディクショナリを確認できる Manage Service Dictionaries 権限を持つユーザとして、後続の時点(たとえば、Service Group Authorization または Service Delivery)にフォームを確認することが含まれます。
ここまでの「非ロード」のディクショナリの使用に関する説明から、常に On-Load イベントよりも Pre-Load イベントを使用する方が良いと思うかもしれません。既存の Service Portal ユーザは、既存のすべての条件付きルールとデータ取得ルールを On-Load イベントから Pre-Load イベントに移動しようとすることがあります。
実際はそれほど単純ではありません。一般に、条件付きルールとデータ取得ルールは、ブラウザに存在するオブジェクトに対してアクションを実行します。したがって、たとえば、Pre-Load イベントに関連付けられている条件付きルール「Hide Fields」の場合、実際には非表示にされるフィールドはありません。これは、Pre-Load イベント中は非表示にするフィールドがまだ存在しないためです。
前に「非ロード」のディクショナリで説明したように、この一般的なルールには、注目すべき例外があります。リリース 9.3.2 以降、Set Value 条件付きルールのアクション、またはデータ取得ルールのいずれかを通して、ブラウザにロードされていないフィールドの値を操作できます。これら両技法の鍵となるのは、ルールをサーバ上で実行する必要があるということです。つまり、サーバ側イベントに関連付ける必要があるということです。
条件付きルールとデータ取得ルールの機能は非常に柔軟であり、複数のターゲットに複数のルールのアクションを組み合わせること、また任意の 1 つのルールを複数のイベントに関連付けることができます。ターゲットにアクセスできないアクション(たとえば、実際にはサービス フォームに存在しないフィールドに対する Set Value アクション)は、「メッセージを出力せずに失敗」するか、または効力がないと考えられます。一連のアクション(たとえば、いくつかのフィールドの非表示化、他のフィールドの必須化、アラート メッセージのポップアップ、さらに Set Value の実行)を実行する条件付きルールがある場合、ブラウザで、そのほとんどのアクションの実行を確認できます。ただし、ターゲット フィールドが現在非表示になっているか、またはブラウザ内に存在しないために、Set Value アクションの実行がブラウザに表示されない可能性があります。条件付きルールのフレームワークでは、そのようなルールも作成できますが、実行できないアクションは、単に無視されます。
幸い、これらの動作については、ルールを構築する際に、条件付きルールとデータ取得ルールのウィザードで詳しく説明されます。各ステップに組み込まれているヘルプ テキストには、サーバ側イベントで特定のアクションを使用する際に生じる制限が説明されています。
サーバ側イベントでは、データベースに直接データを書き込むことができます(具体的には、要求エントリごとにデータベースに格納される WDDX データ)。特に Post-Submit イベントは、ブラウザでのアクションによって収集または取得したデータをデータベースに書き込みます。
Pre-Load イベントと Post-Submit イベントの重要な違いは、Pre-Load がデータベースに書き込むことができるのは、要求データがすでにデータベースに存在する場合に限られるという点があります。言いかえれば、ユーザがまだ [Order] ボタンまたは [Add & Review] ボタンをクリックしていない場合、要求に対するデータがデータベースに存在しないため、Pre-Load ルールで操作される対象はありません。Pre-Load イベントでは表示可能な値を変更できますが、その値をデータベースに保持しません。Post-Submit イベントは値を保持します。
リリース 9.3.2 でサーバ側イベントが導入されたことによって、サーバによって保護され、サービス フォームの一部となっているデータを操作できるという高い柔軟性が実現されました。これは、「非ロード」のディクショナリがデータベースに格納されることで、サーバ側ルールによってアクセス可能になったためです。ブラウザ側ルールはフォーム上で JavaScript として生成されますが、これらのルールと同等のサーバ側ルールは Java コードとして生成されます。要するに、2 つの異なる表現でルールを生成することが可能ということです。
ISF フレームワーク(「ISF Application Programming Interface(API)」で説明)を使用すると、フォーム データと外観に対してより複雑な操作を行う JavaScript を記述できます。この JavaScript は、ブラウザでのみ実行できます。したがって、作成した ISF 関数は、サーバ側イベントに関連付けることはできません。
この新しいフラグは、入力タイプが読み取り専用または非表示に定義された任意のフィールドについて [HTML Representation] タブで使用可能で、競合することがある要件を満たすために役立ちます。まず、要求側ユーザに役立つデータを表示したり、ビジネス ロジックを適用する「非表示変数」をフォームで使用します。次に、データをユーザによる介入(悪意のあるアクティビティなど)から完全に保護します。
• Dictionaries モジュール内に作成可能な個人ベースのディクショナリである「テンプレート ディクショナリ」
• Dictionaries モジュール内に構造が自動的に作成されるサービス項目ベースのディクショナリ
この 2 つのディクショナリは、「自動入力」動作を実行する点で類似しています。個人ベースのディクショナリでは、フォーム ユーザが個人を選択([Select Person] コントロールを使用)します。選択された個人の詳細は、フォームに自動的に表示されます。サービス項目ベースのディクショナリでは、フォーム ユーザは、所有する、またはアクセス権を持つ特定のサービス項目を選択できます。そのサービス項目インスタンスの属性値は、自動的に表示されます。
これは、読み取り専用のフィールド(つまり、[HTML representation] タブで入力タイプが「読み取り専用」として設定されたフィールド)として自動的に入力される大部分の属性(またはすべての属性)を定義する一般的なサービス設計技法です。たとえば、ユーザ ベースに同じ名前の複数の人物を格納するための十分なスペースがある場合は、これらの人物の電子メール アドレスなどの属性を使用してフォーム ユーザを区別し、目的の個人を正しく選択できます。ここでは、フォーム ユーザが、選択したユーザの電子メール アドレスを更新することは想定していません。一方、フォーム ユーザはこの人物を良く知っており、その人物が Directory Integration を通して取得した卓上電話番号ではなく、携帯電話だけを使用していることを知っているかもしれません。この場合は、[Work Phone] フィールドを読み取り専用ではなく、編集可能にして、少なくとも要求を処理するサービス提供担当者が、選択した個人に到達するために最も信頼できる方法を確保します。
[Editable on server-side only] チェックボックスを使用すると、入力タイプに読み取り専用または非表示としてマークを付けたフィールドがサーバによって完全に制御され、ブラウザ セッションでこれらの値を操作しても、Service Portal データベースに存在するデータが優先され、操作が破棄されます。実際、データベース内に存在するデータを上書きする唯一のメカニズムは、サーバ側イベント中に実行するルール(条件付きルールまたはデータ取得ルールのいずれか)であり、この場合はルールが実際にデータベース値を更新します(個人ベースのディクショナリの場合、DirPerson 内の Person レコードは更新されませんが、データベースに格納されている、要求エントリに対する WDDX データは更新されます)。
言いかえれば、サービス設計者は、サーバ側イベント中に実行されたルールを通してのみ、[Editable on server-side only] としてマーク付けされているフィールドの値を操作できます。サービス設計者は、これら「保護された」フィールドを使用するには、[Editable on server-side only] フラグのチェックをオンにするだけでよいと考える可能性があるため、これは考慮すべき重要な要因です。データベースから返される値を操作する理由がない場合は、チェックをオンにするだけで十分です。しかし、フォーム ユーザが行った選択に応じてこれらの値を設定するようにビジネス ロジックで要求されている場合、条件付きルール(Set Value アクション用)またはデータ取得ルール(クエリーからのデータ提供用)をサーバ側イベントに必ず関連付ける必要があります。
データ取得ルール ウィザードの最初のステップでは、取得ルール タイプについて選択肢が 3 つ表示されます。
• Distributing Rule with implicit validation
ウィザードには 3 つの選択肢がありますが、実際の取得動作は、Distributing と Validating の 2 タイプのみです。3 番めの選択肢(Distributing with implicit validation)は、他の 2 種類の選択肢を便宜上組み合わせたものです。
リリース 9.3.2 よりも前は、すべてのデータ取得ルールが Distributing 動作でした。Validating は新しい動作です。これら 2 つの動作の違いの概要は、次のとおりです。
Distributing ルールは、主にクエリーを実行し、結果をフォームに提供するためのルールです。Validating ルールはフォームのデータをチェックするためのルールであり、セキュリティなどが特定の標準に準拠していることを確認します。つまり、Validating ルールの主な目的は、悪意のあるユーザによるフォームの傍受や内容の操作を防止することです。
Validating ルールは、次のような質問に効果的に答えます。「この特定フィールドのこの値は、特定のクエリーを通して取得可能であったいずれかの値に一致しますか。もし値が一致しない場合、何らかの不具合があり、送信を停止する必要があるためです」。
場合によっては、これら両方のルールの動作を必要とする可能性があります。つまり、フォームに提供するためのデータを取得する一方、フォーム ユーザがブラウザで不都合な操作を行っていないことを確認する必要がある場合があります。このため、これら両方のタイプのルールを作成するショートカットとして、「組み合わされた」ルール(Distributing with implicit validation)が提供されています。
Validating の動作は、常に Post-Submit イベントのコンテキスト内でのみ動作します。Validating ルールを作成し、[Active Form Behavior] タブでバインディングされたイベントを調べると、Post-Submit イベントから削除対象として選択できないことが示されます。同様に、暗黙の検証は、Post-Submit イベントから削除対象として選択できません。これらいずれかを Post-Submit イベントの結果から削除すると、ルール/動作が意味を成さなくなります。
また、暗黙の検証で、Validating、Distributing、および Distributing with implicit validation の選択に適用すべきパフォーマンスに関する考慮事項があります。これらの詳細については、次の項で説明します。
通常、最も安全なタイプのデータ取得動作は、新しいルールを作成する際に、Distributing with implicit validation がデフォルトでオンになっている動作です。したがって、たとえば、ドロップダウン コントロールに値としてサーバ プロビジョニング ロケーションのリストを入力するときに、ロケーションがフォーム ユーザのロールによって制限されている場合には、[Distributing with implicit validation] オプションを使用すると、ルールによって「Seattle」がロールの有効な選択肢から除外されている場合は、悪意のあるユーザが「Seattle」を指定できなくなります。
ただし、暗黙の検証を実行するには、負荷がかかります。サーバ側で何かを実行する場合はアプリケーション サーバのサイクルが使用されますが、ユーザのブラウザ セッションに制限されます。大部分のドロップダウン リストでは、悪意のあるユーザが、ルールによって実際に取得される値以外の値を指定しても、不適切な動作は発生しません。アプリケーション サーバのサイクルを使用することが、追加のセキュリティ手段に見合う価値があるかどうか判断する必要があります。ほとんどの場合、アプリケーション サーバの「負荷の増加」は無視できる程度の問題であり、すべてのユーザに対して、ソリューションのパフォーマンス全体に与える影響はありません。ただし、データ取得ルールのメカニズムは非常に柔軟であるため、不適切なクエリーが定義され、サービス フォームに含まる可能性があります。たとえば、カスタマーによっては、数千ものレコードを返すルールを記述する場合があります。このようなルールは推奨されませんが(エンドユーザは、表示されたドロップダウンの結果の数に圧倒されてしまうでしょう)、アプリケーションにはこのようなルールが定義されるのを防止する手段はありません。このタイプのルールは、サーバ側イベントで実行された場合に、ソリューションのパフォーマンス全体に影響を与えるおそれがあります。
1 つのガイドラインとして、データ取得ルールのトリガー イベント( サーバ側とブラウザ側)またはタイプ(Distributing と Validating)にかかわらず、可能な限りクエリーを洗練することにより、膨大な量の結果が返されるのを防止することができます。これは、最高のエンドユーザ エクスペリエンスとパフォーマンスにつながります。
多くのデータ取得ルール(特にサービス フォームのドロップダウン コントロールに値を入力するルール)は、On-Load イベントに対して実行された場合に意味を持ちます。実際に、リリース 9.3.2 よりも前のリリースでは、これだけが、使用可能な適切な選択肢でした。しかし、リリース 9.3.2 では新しい Pre-Load イベントが使用可能になったため、良好なパフォーマンスを得るために、すべての On-Load ルールを Pre-Load イベントに移動する傾向があります。一般的に、サーバ上で実行するクエリーはブラウザによって呼び出されるクエリーよりも高速ですが、ルールを On-Load から Pre-Load に移動する前に、いくつかの追加の要因を考慮する必要があります。
要因の 1 つに、クエリーによって返される大量の結果があります。数百もの行を返すルールを設計した場合(もう一度言えば、このようなルールの設計は、推奨されていません)、このルールをアプリケーション サーバ上で実行すると、すべてのユーザのソリューション パフォーマンス全体に影響を与える可能性があります。
もう 1 つの要因として、フォームのエンドユーザが認識するパフォーマンスがあります。通常、数十個または数百個のフィールドを持つ複雑なサービス フォームをブラウザ ウィンドウに完全にロードするには、多少の時間がかかります。そのフォームに On-Load イベントでドロップダウンを入力するデータ取得ルールも含まれている場合、一般にフォームが最初に描写され、それに続いてドロップダウンに値が入力されます。ドロップダウンの描写と値の入力の間、フォーム上に「空」に見えるドロップダウン コントロールが表示される場合があります。
この効果は、ドロップダウンに入力するルールを Pre-Load イベントに関連付けることによって軽減できます。ただし、Pre-Load という用語に注意してください。データ取得ルールを Pre-Load イベントに移動することは、ルールの実行が終了するまで、フォームがロードされないことを意味しています。したがって、ユーザは、フォームがブラウザにロードされるのを見ることはありません。そのため、フォームを完全にロードするパフォーマンス全体は向上する場合がありますが、ユーザは、[Order] ボタンをクリックした際のアプリケーションの応答が遅いと感じる可能性があります。
サービス フォームの設計者および試験者として、どの程度のロジックをサーバ側イベントにするのが最善か最終的に判断する必要があります。幸い、比較のために、ルールのセットを On-Load イベントに関連付け、その後その関連付けを Pre-Load イベントに非常に簡単に変更できます。アプリケーションがロード中にこの比較を行うと、効果がよりはっきりと表示されるため、最も適切なアプローチを選択できます。
ISF は、 対話型サービス フォーム を意味しています。ISF は、JavaScript プログラミングをサービス フォームに追加するためのインターフェイスと技法のセットです。ここで、 サービス フォーム がキーワードになります。JavaScript プログラミングは、サービス データが表示されている場合、つまりサービスが My Services、または Service Manager の [Task Details] タブでオーダーされている場合のみ実行できます。
ISF を含めて、JavaScript プログラミングは、アクティブ フォーム ルールで提供される機能を補完することを目的としています。アクティブ フォーム ルールでは、サービス フォームの対話性を強化するために関連付けられる最も一般的な動作(フィールドやディクショナリを動的に表示および非表示にする、コンテキストまたは以前入力したデータに基づいてフィールド値を設定する、フィールドを読み取り専用または編集可能、必須または任意に設定する)を提供できます。したがって、サーバ側イベント(Pre-Load と Post-Submit)は 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 は、同じイベントにアタッチされたルールの後に実行する必要があるという点に注意する必要があります。
次の表に、グローバル変数とそれらの取り得る値の概要を示し、詳しく説明します。条件付きルールに、これらの ID と同等の条件がある場合、その同等の条件が示されます。詳細については、前述のアクティブ フォーム コンポーネントの項を参照してください。
すべてのユーザは、Organization Designer に登録されている必要があります。アプリケーションは、Organization Designer 内のユーザのレコードに一意の ID を割り当てることにより、これらのユーザを識別します。アプリケーションは、現在の要求の発信者(ReqInitiatorID)、現在の要求のカスタマー(ReqCustomerID)、および現在要求で作業しているユーザ(UserID)を追跡します。
オーダー時点では、ReqInitiatorID は常に UserID と同じです。サービス提供、および承認/確認の時点では、タスク実行者または確認者が UserID によって識別されます。Order On Behalf(OOB)機能が使用された場合、ReqCustomerID は ReqInitiatorID とは異なります。それ以外の場合は同じです。
JavaScript 関数は、ISF フレームワークに組み込まれます。ISF はオブジェクト指向のフレームワークです。ISF JavaScript 関数は、実際には基本オブジェクト serviceForm に基づくメソッドです。たとえば、ディクショナリを非表示にする場合は、次を呼び出します。
以下の各項では、太字フォントおよびイタリック体フォントは、プログラマが項目の名前を置き換える必要があることを意味しています。
(注) JavaScript 関数は、グリッド ディクショナリおよびそのフィールドのイベントに割り当てることはできません。
次の表に、ディクショナリに適用可能な関数の概要を示し、詳しく説明します。グリッドの使用については、「グリッドを操作するための条件付きルールと ISF」を参照してください。
(指定された時点および参加者のセット、またはそのいずれかの)Service Designer を介して読み取り専用に指定されたディクショナリの外観(および HTML 表現)は、ISF の dictionaryName .setReadOnly() 関数を介して読み取り専用に設定されたディクショナリの外観(および HTML 表現)とは異なります。
• Service Designer を介してディクショナリが Edit only に設定されている場合、ディクショナリを構成するフィールドに HTML 入力タグは生成されません。これらは、サービス フォームにテキストとしてレンダリングされます。
• ディクショナリのアクセス コントロールに編集機能が含まれており、ISF または条件付きルールを通して読み取り専用に設定されている場合は、ディクショナリ フィールドが入力オブジェクトとして表示されます。ただし、それらは入力可能ではありません。
ディクショナリが設計時に読み取り専用に設定されている場合(つまり、Service Designer のアクティブ フォーム コンポーネントの [Access Control] タブで指定されている現在の参加者および時点に対する Edit 権限を持たない場合)、ISF またはルールによって書き込み可能にすることはできません。これは、読み取り専用のディクショナリがレンダリングされた場合、結果の HTML に <span ../> タグ付きのテキストが含まれており、HTML の <input ..> タグは存在しないためです。
「Manage Service Dictionaries」機能が付与されているユーザでは、ディクショナリ権限は無視されます。(この機能は「Site Administration」組織に所属するユーザに自動的に付与され、ユーザ定義のルールおよび Service Portal 定義のロールも含まれる場合があります)。ディクショナリは、編集可能であるかのように表示されます。「Manage Service Dictionaries」機能によって、指定したディクショナリ権限が上書きされるため、管理ユーザとしてログインしている場合は ISF をテストしないように注意する必要があります。
は、ブール値を返す関数ではありません。 dictionaryName は、serviceForm オブジェクトの属性です。 dictionaryName 属性は、ISF が実行されたサービス内にディクショナリが存在する場合は true 値を持ち、ディクショナリが存在しない場合は未定義になります。したがって、1 つ以上のディクショナリが存在することを確認し、現在のサービスにディクショナリが存在する場合のみアクションを実行する堅牢なコードは、次のようにコーディングします。
次の表に、フィールドに適用可能な関数の概要を示し、詳しく説明します。
は、ブール値を返す関数ではありません。 fieldName は、serviceForm. dictionaryName オブジェクトの属性です。 fieldName 属性は、フィールドが現在のサービスに存在していない場合は未定義となります。(フィールドは非表示の場合がありますが、引き続き存在していると見なされます)。したがって、1 つ以上のディクショナリが存在することを確認し、現在のサービスにディクショナリが存在する場合のみアクションを実行する堅牢なコードは、次のようにコーディングします。
コードで以前にディクショナリの「存在」が確認されている場合は、必ずしもフィールドの存在をチェックする必要はありません。
getValue() メソッド( serviceForm.dictionaryName.fieldName.getValue() )は、常に配列を返します。項目が 1 つしかない場合は、1 項目の配列です。.getValue()[0] を使用して最初の要素にアクセスします。ディクショナリに編集アクセス権が定義されている場合、現在の時点でフィールドが読み取り専用、読み取り/書き込み、または非表示にされているかどうかに関係なく、getValue() はすべてのフィールドに作用します。
• チェックボックスや Select (Multi) などの入力タイプでは、値に Tab 文字が含まれていると getValue() が正しく処理されません(たとえば、Tab 文字を使用してリスト内の値が区切られている外部ソースからデータのインポートを試行する場合)。値に含まれる Tab 文字は、¥t で表現されます。
• 複雑な制御(オプション、チェックボックス、複数選択、単一選択/ドロップダウン)の場合、返される値は「選択した値」のセットになります。つまり、強調表示されている値のみが返され、表示にはラベルまたはテキストではなくしばしば「Value」プロパティが使用されます。
セキュリティ上の理由で、このメソッドは入力タイプが password のフィールドでは機能しません。空白の文字列が返され、エラーは表示されません。
setReadOnly() メソッド(serviceForm. dictionaryName.fieldName .setReadOnly())は、フィールドを読み取り専用と読み取り/書き込みの間で切り替えます。
• 入力タイプが Person、Date、または Datetime のフィールドにはボタンが関連付けられており、ユーザは、そのボタンをクリックしてフィールドの値を選択できます。これらのフィールドを読み取り専用に設定すると、フィールドの横の [Select] ボタンが無効になり、クリックできなくなります。説明情報(個人の名前、日付、または日付時刻)を含むテキスト フィールドは、常に読み取り専用です。
• Service Designer で特定の時点に対してディクショナリが読み取り専用にマークされている場合、フィールドは定型文としてサービス フォームに表示されます。HTML 入力オブジェクトは生成されません。このようなディクショナリ(またはディクショナリ内のフィールド)は、ISF を通して読み取り/書き込みに設定できません。ISF setReadOnly() を使用してディクショナリまたはディクショナリ内のフィールドを書き込み可能にしようとすると、失敗しますがメッセージは表示されません。同様に、ISF を介してフィールドまたはディクショナリを読み取り専用にしようとしても効果がなく、エラーは生成されません。
• ISF を通してディクショナリまたはフィールドを読み取り専用に設定すると、引き続き HTML 入力ボックスは表示されますが、フィールドの内容は編集不可であり、フィールドは Tab シーケンスから除外されます。
setVisible() メソッド(serviceForm. dictionaryName.fieldName .setVisible())は、サービス フォームでフィールドを非表示と表示可能の間で切り替えます。
• Service Designer で特定の時点に対してディクショナリが非表示としてマークされている場合、そのディクショナリ内のフィールドは、ISF を介して表示可能にできません。ISF setVisible() を使用してディクショナリまたはディクショナリ内のフィールドを表示可能にしようとすると、失敗しますがメッセージは表示されません。
• ISF を介してディクショナリが非表示になっている場合にディクショナリ内のフィールドを表示可能にしようとすると、失敗しますがメッセージは表示されません。
フィールドの値の設定には、次の 2 つのメソッドを使用できます。
• serviceForm. dictionaryName.fieldName .setValue())
• serviceForm. dictionaryName.fieldName .setSelection())
3 番めのメソッドは setValue() メソッドと同等ですが、グリッド内のセルに対するものです。
• serviceForm.dictionaryName.fieldName.setCellValue())
詳細については、「グリッドを操作するための条件付きルールと ISF」を参照してください。
setValue() メソッドは、指定したフィールドの値に指定した inputValues を設定します。inputValues は配列の必要があり、inputValues の最初の値は、任意の単一オプション フィールドに割り当てられます。
• セキュリティ上の理由で、このメソッドは入力タイプが password のフィールドでは機能しません。
• 入力タイプが Select (single)、Select (multiple)、checkbox、および radio ボタンの inputValues には表示値が設定され、この関数は同じ値を選択します。checkbox タイプのフィールドは、inputValues の配列を取ることができます。フィールド内にない無効な表示値が渡されると、関数は選択を行わずに戻ります。サービス フォームの保存時には、選択が維持されます。
• inputValues に対する検証は行われません。[Person]、[SSN]、[URL]、または [Date] のようなフィールド タイプの場合であっても、サービス フォームの送信時に、この関数を通して設定された誤った値が保持される可能性があります。
• [Person] タイプのフィールドに関しては、次の「特殊なフィールド レベル関数」の項を参照してください。
setSelection() メソッドは、複数オプションのフィールド(select (single)、select (multiple)、checkbox、および radio)に使用する必要があります。引数は、フィールドのさまざまな要素の値に一致します。radio フィールドまたは checkbox の場合は、この関数を使用して、選択に 1 つの制御を設定すること、または制御を設定しないことができます。たとえば、.setSelection([‘']) は、すべてのオプション ボタンをクリアして「初期状態」に戻します。
複数選択または単一選択の入力項目の場合、setSelection は、要求された項目を選択した状態にマークします。リスト内で検出されなかった項目は無視されます。
この関数は、入力タイプが password、text、または textarea のフィールド、または読み取り専用ディクショナリ内のフィールドに使用しても効果がありません。
フィールド レベル関数によっては、特定タイプのフィールドだけに適用できる関数があります。これらを、次の表にまとめます。
Person のデータ タイプと HTML 表現は、Organization Designer に保存された個人のプロファイル データの表示および検証用に設計されています。次に示すように、このフィールドは、サービス フォーム上に、「Select」というラベル付きで、関連付けられたコントロールを持つ単一行のテキスト ボックスとして表示されます。
[Select] ボタンをクリックすると表示されるポップアップ ウィンドウを使用して、Service Community 内のユーザを検索し、目的の個人を選択できます。サービス フォームに、個人の名前と電子メール アドレス([Site Administration] で設定したフィールド)が表示されます。
ISF 関数を Person タイプのフィールドに適用すると、次のように動作します。
• personFieldName .getValue() は、Service Portal の個人レコードに対する一意の ID である個人の ID を返します。カスタマイズされた適切なサーバ側コードでその ID を使用することにより、サービス フォームの他のフィールドで、追加の個人のプロファイル情報を検索して表示できます。
• personFieldName_disp .getValue() は、サービス フォームに現在表示されている個人の名前を返します。
• Select コントロールを使用すると、[PersonField] フィールドと [PersonField_disp] フィールドが自動的に更新され、同期を維持できます。
• personFieldName .setValue() を使用して、PersonID の値を設定できます。この関数と personFieldName_disp .setValue() を組み合わせて使用することにより、現在の ID に対して常に正しい名前を表示できます。
PersonField.setValue () 関数は有効な Person ID を想定していますが、クライアントによる検証は行われません。そのため、無効な ID を割り当てても、送信/更新アクションが失敗することはありません。[Person] フィールドの表示値には、fieldName にサフィックスとして「_disp」を付加することによってアクセスできます。
fieldName_disp .setValue(inputValues)
• サービス フォームを送信すると、この関数を使用して設定された Person ID 値は保持され、表示値は無視されます。
• Person の名前を変更しても、サービス フォームは Person の表示値と同期しません。つまり、この関数を使用して設定された値が引き続き表示されます。
複数選択のフィールドおよびチェックボックスに対する HTML 表示では、同じフィールドで複数の値を選択できます。次の例に示すように、選択した値は、カンマ区切りのリストで表示されます。
ISF およびサービス フォームは、類似しているが同一ではないイベント モデルを Document Object Model(DOM)イベント モデルに実装します。つまり、カスタマイズした JavaScript 関数を呼び出して、サービス フォームの処理中に発生するイベントを処理できます。
通常、JavaScript 関数は、HTML フォームが表示され、ユーザがフォームの入力フィールドにデータを入力すると発生する処理イベントに対するイベント ハンドラとして呼び出されます。サービス フォームは、以前リポジトリに保管したディクショナリおよびフォームの定義に基づいて動的に生成されるため、プログラマが単純に ISF コードを HTML ファイルに入力することはできません。Service Designer によって提供されたユーザ インターフェイスに従って関数を記述し、それらの関数を適切なイベントにアタッチする必要があります。したがって、イベント ハンドラとしてアクセスされるすべての JavaScript 関数も、リポジトリ内に定義する必要があります。このような関数は、Service Designer の [Scripts] オプションを通して定義され、フォームの [Active Behavior] タブを通して該当するイベントに関連付けられます。
次に、イベント ハンドラとして記述された JavaScript 関数は、他の JavaScript 関数を呼び出すことができます。これらの関数は(パブリック スコープを持つ必要がある場合)、Service Designer 内でスクリプトとして定義することはできません。代わりに、それらの関数は、1 つ以上の関数を含むテキスト ファイルとして JavaScript ライブラリ内に記述し、アプリケーション サーバからアクセス可能なファイル システム内に配置する必要があります。次に、Service Designer インターフェイスを使用して、その関数を必要とするフォーム内に、これらのライブラリを組み込みます。
ISF コードを記述し、そのコードをフォームに統合する Service Designer オプションは、次のようになります。
• [Scripts] > [JavaScripts]:個々の ISF 関数を作成し、オプションで関数内にライブラリを組み込み、さらに関数の使用方法をモニタします。
• [Scripts] > [Libraries]:複数の関数を格納できる JavaScript ライブラリへの参照を作成します。
• [Active Form Components] > [select a form] > [Active Form Behavior] タブ:フォームまたはフォーム上のフィールドに対するイベント ハンドラとして、JavaScript をアタッチします。
[Service Designer] > [Scripts] で [JavaScript] 関数を選択すると、次の 3 つのタブが表示されます。
• [General] タブでは、JavaScript 関数を作成し、維持できます。
• [Libraries] タブでは、JavaScript ライブラリを現在の関数、および拡張により、関数がアタッチされるフォームに組み込むことができます。
新しい JavaScript 関数を作成するには、[Service Designer] > [Scripts] で [New] > [New Function] を選択します。関数を作成した後、ページの左側のツリー構造から、メンテナンスのためにその関数を選択します。
• [Name]:関数の名前。Service Designer 内でこの名前が使用されますが、JavaScript 関数を参照するには、生成されたコード内で関数を識別する JavaScript 識別子を使用するのが良い方法です。JavaScript 識別子としての名前は、大文字と小文字を区別する単一の単語であり、文字と数字で構成され、文字で始まります。関数の命名に対するガイドラインについては、「アクティブ フォーム コンポーネントの使用に関するベスト プラクティス」を参照してください。
• [Description]:任意ですが、関数の説明を記述するように強く推奨されています。
• [Add this script to the following events on all forms]:これらのチェックボックスは、チェックされたイベントに対するイベント ハンドラとして関数を指定するために使用します。この「グローバルな」アタッチによって、[Active Form Behavior] タブを介したイベントへの関数の「ローカルな」アタッチが置き換えられます。本書の次の項で説明するように、大部分のプロジェクトでは、グローバルなアタッチは推奨されません。
• [JavaScript Function]:ISF コードをインクルードする関数の実際のコード。関数シグニチャは「function」キーワードを含むことはできませんが(これは、生成されたサービス フォームに関数が取り込まれるときに自動的に追加されます)、それ以外は、関数の内容は標準的な JavaScript ルールに従います。次に例を示します。
|
|
|
|
[Add new JavaScript] ボタンをクリックして、JavaScript 関数を追加します。JavaScript 関数を作成した後、その関数を編集できます。
ここで、関数定義の [General] ページの最下部にある [Function Arguments] タブを使用して、関数に引数を追加できます。
JavaScript 関数に引数を追加するには、次の手順を実行します。
ステップ 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 と入力します。
関数が、ライブラリに存在する関数を追加で呼び出す場合、[JavaScripts] オプションの [Libraries] タブを使用して、ライブラリを指定します。
• [Add Libraries] ボタンをクリックして、1 つ以上のライブラリを選択できるウィンドウを開きます。
• 追加するライブラリ(複数可)に対応するチェックボックスをオンにし、[Add] をクリックして、選択した項目を JavaScript 関数にインクルードします。
関数にインクルードされたすべてのライブラリが、[Libraries] ページに表示されます。対応するチェックボックスをオンにし、[Remove] をクリックすることにより、1 つ以上のライブラリを削除できます。
次に示すように、[Active Form Components] タブには、現在の JavaScript がアタッチされているフォームと、そのトリガー イベントが表示されます。フォーム名をクリックして、フォーム定義を確認します。
クロスリファレンスには、関数の「ローカルな」アタッチのみ反映されます。JavaScript 関数の [General] タブで [Add this script to the following events on all forms] をチェックすることによりサービスに「グローバル」にアタッチされた JavaScript は含まれません。
ライブラリは、1 つ以上の JavaScript 関数のコードを含む ASCII テキスト ファイルです。
[Service Designer] > [Scripts] で [New] > [New Library] を選択することにより、リポジトリ内にライブラリのエントリを作成します。
これを「New Library」という名前にするのは、適切な命名ではありません。実際には、Service Portal の外部に作成した(または作成する)ライブリへの「新しい参照」になります。
• [Name]:説明フィールドであるため、ライブラリに任意の名前を指定できます。この名前は、Service Designer 内でライブラリの参照に使用されます。
• [Import from URL]:ライブラリの位置。ライブラリは、Web 展開ディレクトリ内に配置する必要があります(/RequestCenter/ と指定)。慣例として、ISF ライブラリは、ルート ディレクトリ /RequestCenter の直下にある isfcode ディレクトリに配置します。
• [Include this library in all functions]:このチェックボックスでは、実際にはすべての「関数」ではなく、すべてのサービス フォーム内のライブラリがインクルードされるため、この命名も若干適切ではありません。このチェックボックスをオンにすると、サービス フォーム内のライブラリが(参照により)インクルードされ、ライブラリ内に定義されたすべての関数を呼び出せるようになります。(ライブラリの <script> タグがサービス フォーム内に生成されます)。この詳細と他のオプションについては、「ISF コーディングとベスト プラクティス」を参照してください。
フォームに JavaScript 関数を追加するには、次の手順を実行します。
ステップ 1 Service Designer のアクティブ フォーム コンポーネント内のフォームを編集します。
ステップ 2 [Active Form Behavior] タブをクリックします。
ステップ 3 [Form or Field] カラムで、最初の行である [This Active Form Component] を選択します。[Triggering Event] カラムに、すべてのフォーム レベル イベントが一覧表示されます。
ステップ 4 JavaScript 関数をアタッチするフォーム レベル トリガー イベントを選択します。
JavaScript 関数に対して使用できるフォーム レベル トリガー イベントには、次のものがあります。
(注) サーバ側トリガー イベントの [After the form is submitted (server-side)] と [Before the form is loaded (server-side)] は、フォーム ルールに対してのみ提供されます。
ステップ 5 [Add JavaScript] ボタンをクリックします。
[Add Functions] ダイアログボックスが表示され、Scripts オプションで事前定義された JavaScript 関数が一覧表示されます。
ステップ 6 使用する JavaScript 関数の横のチェックボックスをオンにして、[Add] ボタンをクリックします。必要に応じて [Search] ボックスを使用して、JavaScript 関数を検索できます。
ステップ 7 次に示すように、[JavaScripts] セクションの [Behavior] カラムに関数が表示されます。
(注) 単一フォーム内の同じイベントに複数の JavaScript 関数をアタッチできますが、関数を指定(および実行)する順序を定義できないため、これは最も回避すべき方法です。したがって、特定の順序で関数を実行する必要がある場合には、目的とする順序ですべての関数を含む JavaScript 関数を作成します。
フィールド レベル イベントに JavaScript 関数を追加するには、次の手順を実行します。
ステップ 1 Service Designer のアクティブ フォーム コンポーネント内のフォームを編集します。
ステップ 2 [Active Form Behavior] タブをクリックします。
ステップ 3 [Form and Field] カラムで、ディクショナリ ノードを展開し、関数をアタッチするフィールドを選択します。
ステップ 4 [Triggering Event] カラムで、関数を実行するタイミングに対応するフィールド レベル トリガー イベントを選択します。
|
|
onChange イベントは、[Text]/[Single-select] フィールドの変更の検出に最も適しています。同じ [Person] が [Select Person] ポップアップ ウィンドウから選択された場合、または同じ [Date] が [Calendar] ポップアップから選択された場合であっても、[Person]、[Date]、または [DateTime] に対する onChange イベントは常にトリガーされます。同様に、[Text] フィールドに入力すると、フィールド内の値を実際に変更したかどうかに関係なく onChange イベントがトリガーされます。
• 現在のフィールドの値に基づいて、フィールドに入力します(たとえば、ユーザが入力した別のフィールドの値に基づいてサービスにフラグを設定)。
• ドロップダウンから [Other] を選択すると、フォーム上にさらにテキスト ボックスを表示する必要があります。
onClick イベントは、Radio/Checkbox コントロールで最もよく機能します。onClick イベントは、[Person]、[Date]、および [DateTime] フィールドに対してはトリガーされません。その理由は、これらのフィールド タイプに対するテキスト ボックスは常に読み取り専用であり、ポップアップを通してのみ選択可能なためです。
ステップ 5 [Add JavaScript] ボタンをクリックします。
[Add Functions] ダイアログボックスが表示され、Scripts オプションで事前定義された JavaScript 関数が一覧表示されます。
ステップ 6 使用する JavaScript 関数の横のチェックボックスをオンにして、[Add] ボタンをクリックします。必要に応じて [Search] ボックスを使用して、JavaScript 関数を検索できます。
ステップ 7 次に示すように、[JavaScripts] セクションの [Behavior] カラムに関数が表示されます。
(注) 単一フォーム内の同じイベントに複数の JavaScript 関数をアタッチできますが、関数を指定(および実行)する順序を定義できないため、これは最も回避すべき方法です。したがって、特定の順序で関数を実行する必要がある場合には、目的とする順序ですべての関数を含む JavaScript 関数を作成します。
ステップ 8 必要に応じて、[Behavior] カラムで JavaScript 関数をクリックし、次に [Edit Arguments] ボタンをクリックすることにより、関数の引数を編集できます(詳細については、「JavaScript 関数への引数の追加」を参照)。
ディクショナリ フィールドには、そのフィールドの [Display Properties] の [Add a Button] セクション内の指定に従って、ボタンが関連付けられている場合があります。
設計者は、キャプション(ボタン上に表示されるテキスト)と URL を指定できます。URL は、JavaScript 関数またはネットワーク上でアクセス可能な外部の任意の場所を指すことができます。
外部 Web ページを参照する場合、完全修飾 URL を使用します。
• URL は、ライブラリ内で使用可能な JavaScript 関数、または埋め込まれた JavaScript コードを指すことができます。関数呼び出しにパラメータが含まれる場合、フォーム データをそのパラメータに含めることはできません。しかし、関数は、ISF を含むことができます。
• [Send Data] オプションは、外部 Web ページにのみ適用できます。これにより、現在のフォーム上のすべてのデータを含めて、応答がそのページに POST されます。
イベント ハンドラ内にコードを配置するのではなく、関連付けられたボタンを使用する短所は、コードを起動するために余分なキーストローク(ボタンのクリック)が必要になることです。したがって、ボタンは、通常のフォーム処理の手順内、または拡張ダイアログや外部サイトのブラウズで使用するのではなく、オンデマンドで実行する必要のあるイベント用に使用するのが最もよい方法です。
URL を指定するだけで、指定された Web ページが別のウィンドウに表示されます。ただし、そのウィンドウのサイズは変更できず、スクロールバーもありません。したがって、アプリケーションによっては、JavaScript を使用して、明示的に指定したウィンドウに Web ページを表示する方が望ましい場合があります。次に、コード例を示します。
JavaScript は、すべて 1 行に記述する必要があります(改行なし)。以下の出力例を参照してください(基本的なものですが、考え方がわかります)。上記の行は、「URL with JavaScript」というラベルのボタンの URL エントリからコピーして貼り付けたものです。
ISF を使用すると、サービス カタログ プロジェクトの複雑性が増します。この項では、この環境での開発に役立つ方法論的および技術上のヒントの概要を説明します。
JavaScript と ISF を効率的に開発、テスト、デバッグするには、クライアント ワークステーションに追加ツールをインストールすることや、以前インストールしたソフトウェアの再構成が必要になる場合があります。
JavaScript には、大きな落とし穴があります。 エラーに警告を出しません 。構文エラーの中には、他の言語では捕捉されるが、大部分の JavaScript の実装では無視されるものがあります。たとえば、関数呼び出し内に余分なカッコがあると、 そのページ内のすべての JavaScript コードの実行が失敗します 。警告は発行されず、ブラウザの左下に「Error in page」というメッセージが表示されることがあります。このメッセージをクリックすると、エラーが検出されたページの行番号が表示される場合があります。
さらに役立つエラー メッセージおよびデバッグ機能を取得するには、JavaScript Debugger をインストールする必要があります。Microsoft Script Debugger を Microsoft から無償でダウンロードできます(インターネット検索で確認してください)。Visual Studio など、いくつかの Web 開発環境に使用可能なデバッガが含まれています。
デバッガを使用するには、Internet Explorer を再構成して、スクリプトのデバッグを有効にする必要があります。この設定には、[Tools] > [Internet Options] > [Advanced] オプションでアクセスできます。
JavaScript プログラムの構文を強調表示するテキスト エディタを使用すると便利です。このようなエディタの中には、フリーウェアまたはトライアル バージョンとして提供されているものもあります。いくつかの Java 統合開発環境(IDE)は、JavaScript ファイルの編集もサポートしています。
ISF 開発者は、JavaScript ライブラリが存在するアプリケーション サーバ上のディレクトリ(一般には、RequestCenter.war Web アーカイブ下の isfcode ディレクトリ)に対して、読み取り/書き込みアクセス権を持つ必要があります。また、ワークステーションとアプリケーション サーバ間でファイルを転送するソフトウェアも必要です。
ライブラリ ファイルは、アプリケーション サーバからサービスを受けます。したがって、ライブラリの改訂版をロード可能にするために、ページ キャッシングを無効にする必要があります。
Service Designer では、JavaScript 関数をスクリプト(リポジトリ内)またはライブラリ(ファイル システム上の外部ファイルとして)に保存できます。
JavaScript を外部の JavaScript(ライブラリ)ファイルに保存すると、次の利点があります。
• 各イベントに Script Manager 内でアタッチされた関数が存在する場合のように、ユーザが別々の画面をナビゲートする必要に迫られることがないように、多数の関数のコードを 1 つの場所に維持する。
• コードをファイル内に維持することにより、ソース コードのバージョン管理が容易になる。
• コードをテキスト ファイル内に維持することにより、グローバル検索/置換、およびファイルに対する検索の実行が容易になる。
• JavaScript ライブラリは、単に、アプリケーション サーバ上に存在する ASCII ファイルであるため、強力なエディタを使用してファイルの内容を管理できる。
• 同じコード部分が 1 つ以上の関数から参照されるため、変更が必要な部分を 1 つにすることができ、テストも 1 回で済む。
• JavaScript ライブラリは、アプリケーション サーバの Web 展開ディレクトリ(RequestCenter.war)上に存在する必要があります。慣例で、ライブラリは「isfcode」という名前のディレクトリに配置します。
• したがって、プログラマは、アプリケーション サーバのファイル システムに対するアクセス権を持つ必要があります。これにより、サーバ上に追加のログインが作成される場合や、追加のクライアント ソフトウェア(たとえば、Remote Desktop サービス)が提供される場合があります。
• ISF コードが存在するディレクトリには、ISF プログラマに対して読み取り/書き込み権限を設定する必要があります。
ISF スクリプトを格納する場所は、設計コストに影響を与えるため、詳細な設計を行う前に、その場所を決定する必要があります。すべての ISF をリポジトリに埋め込むよりも、ライブラリ アプローチを使用する方が、はるかに効率的です。
原則的には、すべてのクライアント コードを 1 つのライブラリに格納できます。しかし、状況によっては、コードを複数のライブラリに分割する方が望ましい場合や、分割する必要がある場合があります。
• 1 つ以上の JavaScript ライブラリを使用して、同じサービスやサービスのグループで使用される可能性が高い ISF 関数が 1 つのライブラリ内に存在し、別のサービスのセットで使用されるものは別のライブラリに存在するようにグループ化することができます。これにより、独立したプロジェクトで作業する可能性の高い開発者のグループは、自分の作業を分離できます。
• 複数の独立したライブラリを使用する場合、それらのライブラリは、サービス フォームにグローバルにアタッチしないでください([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 は、JavaScript 関数内に置かれます。特定のディクショナリやそのディクショナリ内のフィールドに関数を適用する場合、関数名は、この階層を反映する必要があります。これで、関数の使用方法を格段に簡単に追跡できるようになります。関数名は、次の表記法に従います。
• dictionaryName_fieldName_event
• ST_UserLocation_FieldOffice_onChange
ディクショナリ固有の関数とフィールド固有の関数に加えて、Cisco Advanced Services により、サイト全体にわたる次の関数が作成される場合があり、必要に応じて修正できます。
この命名規則により、各スクリプトがどのように使用されるか簡単に理解でき、また新しい機能を作成する適切な位置を見つけることができます。また、サイト固有のコードが、標準サービス ライブラリとともにインストールされた ISF コードと正しくインターフェイスを取れるようにします。
ISF JavaScript 関数は、外部 JavaScript ライブラリに配置するよう推奨されています。特定の関数を見つけやすくするために、ファイル内で関数を順に並べることが重要です。
すべてのコードは、Tab 文字なしで ANSI テキスト ファイルに格納し、空白文字 2 個のインデントを使用して、コードを読みやすく、また理解しやすくする必要があります。各行は 76 文字以内にしてください。
ディクショナリ内のフィールド名を変更するときには、十分に注意する必要があります。フィールドが関数内で参照されている場合、その関数は機能しなくなります。
JavaScript 内のすべての標準プロパティとメソッドは小文字で始まり、その次の単語は大文字で始まります。たとえば、プロパティ「 readOnly 」やメソッド「 onSubmit 」は、この規則に従っています。ISF 内で強制されているわけではありませんが、次の同様の規則も推奨されています。この方法では、コード内または JavaScript 言語の一部のどちらの場合でも、プロパティ名の記述方法を記憶しておく必要はありません。ここでの例では、この規則を使用します。
サービス フォームは、Service Designer にインタラクティブに入力する指定に従って自動的に生成されます。手動で HTML ページを記述しないため、特定のページやページ群にライブラリをインクルードするための HTML タグ、またはページ内に埋め込まれた特定のイベントに JavaScript を割り当てるための HTML タグが生成されている必要があります。スクリプトを使用して、サービス フォームを含む生成された HTML ページにライブラリをインクルードする方法を指定します。また、[Active Form Behavior] タブを使用して、どのスクリプトが特定のイベントに対するイベント ハンドラであるかをアプリケーションに指示します。Service Portal の外部で作業して、ライブラリ内のコードを維持する必要があります。
前に説明したように、大部分のカスタム ISF コードを、1 つ以上の JavaScript ライブラリに配置したい場合があります。前項の説明に従って、[Service Designer] > [Scripts] の [Libraries] オプションを使用します。
ライブラリはテキスト ファイルであるため、アプリケーションの外部で、テキスト エディタでライブラリの内容を維持する必要があります。JavaScript 対応エディタまたは開発環境が強く推奨されています。
また、サードパーティの JavaScript ライブラリも、ISF と組み合わせて使用できます。[Libraries] オプションを使用して、単にライブラリを登録します。
サービス フォームからアクセス可能にするために、ライブラリは、URL /RequestCenter にマッピングされた、アプリケーション サーバ上のディレクトリ構造に存在する必要があります。慣例では、ライブラリは、ルート直下の isfcode という名前のディレクトリに配置されます。/RequestCenter サイトの物理的な位置は、ユーザのアプリケーション サーバ上で Service Portal がインストールされている方法、および使用中のアプリケーション サーバによって異なります。ISF ライブラリが存在する必要のある物理的な位置を決めるには、システム管理者に連絡てください。また、ISF 開発者が、このディレクトリに対する読み取り/書き込みアクセス権、およびディレクトリにファイルを転送するツールを持っていることを確認する必要があります。
サービス フォームでライブラリ内の関数を使用するためには、生成されたサービス フォームにライブラリへの参照(HTML スクリプト タグとして実装)を組み込む必要があります。この参照は、2 つの方法のいずれかで生成されます。
• [Scripts] オプションの [JavaScripts] ノードの [Libraries] タブを使用して、ライブラリを特定の関数に関連付ける必要があります。これで、ライブラリは、この関数を使用するすべてのフォームで使用可能になります。
• [Scripts] の [Library] オプション上の [Include this library in all functions] チェックボックスを使用して、すべてのサービス フォームにライブラリを組み込みます。
これは、ライブラリ参照をサービス フォームに組み込む推奨アプローチです。onLoad イベントとして起動される関数が存在する必要があります。これで、ライブラリは関数に組み込まれます。1 つ以上の onLoad 関数をコーディングできます。それぞれに、異なるライブラリ セットをアタッチできます。この方法では、異なる開発者のチームが、そのサービス フォームで使用可能なライブラリを制御できます。
[Library] ページの [Include this library in all functions...] チェックボックスは、適切な名前ではありません。ライブラリは、フォームごとに一度しかロードできないため、[Include this library in all forms...] にする必要があります。このチェックボックスを使用すると、ライブラリの <script> タグが、生成された HTML ページの先頭に置かれ、ページ レベル ISF から呼び出されたときに、ライブラリとその関数が存在することが保証されます。
この時点で、ライブラリ(コードが含まれない可能性がある)と、すべてのサービス フォームでライブラリを使用するための仕様が存在します。サービス フォームを実行し、ソース コードを表示し、ライブラリの名前を検索することにより、自分の作業を検証できます。サービス フォームのソース コードを表示するには、ブラウザの [View Source] オプションは使用できません。サービス フォームは、HTML ページ内のフレームとして表示されるため、生成されたソース コードは表示されません。代わりに、マウス ポインタをサービス フォーム内(フィールド内ではない)に移動し、右マウス ボタン オプションの [View Source] を使用します。検索すると、ライブラリの名前が示されます。
ここで、実際にコードを記述します。HTML および JavaScript 環境でのデバッグの困難さから、一度に 1 つの関数を記述、デバッグ、およびテストするように強く推奨します。もちろん、JavaScript を含むライブラリ ファイルをローカルに編集できます。しかし、テストするには、アプリケーション サーバ上の指定されたディレクトリにコピーして戻す必要があります。初期的にコードを開発するとき、またはアプリケーション サーバへのアクセス権が限定されている場合には、スクリプト内でコードを記述し、完了した時点でリファクタリングを行い、スクリプト下でライブラリ関数を呼び出すラッパー関数のみ残して、関数をライブラリに移動します。言うまでもなく、頻繁に保存を行い、以前のバージョンのコードに戻す必要がある場合のために、バックアップ コピーを維持してください。
コードを記述したら、そのコードをフォーム内のイベントにアタッチする必要があります。サービス フォームの HTML ページは動的に生成されるため、これを実行するためには Service Designer を使用する必要があります。詳細については、「フォームへの JavaScript 関数の追加」を参照してください。
ディクショナリ フィールドにフィールド レベル イベントをアタッチするには、次の項目を実行します。
• JavaScript ライブラリ内で関数を記述します。 dictionaryName_fieldName_event に従って、たとえば RC_REQUESTORLOCATION_LocationName_OnChange という名前を付けます。
• サイト固有のコードを持つ関数に、以前 JavaScript ライブラリにインクルードした関数の名前にプレフィックスを付けて、名前を付けます。Service Portal が提供する関数(たとえば、Service Portal ライブラリに含まれるサービスで使用されるもの)はプレフィックス「rc」を使用するため、コードは次のようになります。
• [Active Form Components] オプションの [Active Form Behavior] タブを使用して、関数を該当するフィールド レベル イベントにアタッチします。フィールドとトリガー イベントを選択して、次に [Add JavaScript] ボタンをクリックすることにより関数を追加します。(ディクショナリが複数のフォームで使用される場合、関数は、すべてのフォーム内のディクショナリ フィールドにアタッチする必要があります。このアプローチは推奨されません)。
ISF コードは、多数のサービスで再使用可能なアクティブ フォームにアタッチされます。しかし、1 つのサービスをテストするだけでは十分ではありません。たとえば、別のフォームのディクショナリ内のフィールドが、サービス内にも存在することを想定するコードが考えられます。そうでない場合には、ISF コードは、JavaScript エラーで失敗します。したがって、使用可能なフォームの異なる組み合わせに基づいて、テスト マトリクスを設定する必要があります。
特に、テストの初期フェーズでは、Service Portal の複数のセッションを同時に実行するのが有効です。
• 表示されるオプションに [Scripts](関数コードを変更)または [Active Form Components: Active Form Behavior](JavaScript アタッチを変更)を設定して Service Designer を起動します。
• 別のセッションで My Services または Service Manager を実行して、その時点で定義されているルールや ISF に関してサービス フォームをテストします。
• ライブラリ内に存在するコードをテストする場合には、もちろん、ライブラリ ファイルの編集、アプリケーション サーバへの変更のアップロードのために、もう 1 つのウィンドウが必要になります。
JavaScript エラーが発生すると、JavaScript デバッガが表示されます。(関数またはライブラリ コードを編集して)エラーを修正し、デバッガを閉じた後、現在のサービス フォームを終了して、新しい要求を開始する理由はありません。単に、ページをリフレッシュして、現在のサービス フォームを新しい ISF コードで再ロードします。
[Administration Settings] で [Browser Cache] が有効になっている場合、JavaScript ライブラリに対する変更は、ブラウザ キャッシュが削除されるまで効力を持ちません。したがって、開発環境では、ブラウザ キャッシュを無効にするのが最善です。JavaScript ライブラリへの変更を、ブラウザ キャッシュが有効になっている可能性がある実稼働環境に展開する場合、アプリケーション ユーザは、このブラウザ キャッシュを削除する必要があります。アプリケーション ユーザにこの操作を促すためには、『 Cisco Service Portal Configuration Guide 』の指示に従ってブラウザ キャッシュ バージョンを追加してください。詳細については、このマニュアルを参照してください。
すべての JavaScript コードはディクショナリに固有であると考えられるため、オーサリングの間、コードは、各関数がスタンドアロンであり、他の関数やディクショナリに依存しないことを確認します。そのため、新しいディクショナリが追加された場合や、既存のディクショナリが削除された場合にも、他のコードは以前のとおり引き続き機能します。
たとえば、特定のサービスで使用されている 2 つのディクショナリに、onLoad イベントで実行する必要のあるコードが存在すると仮定します。一体となった大きな関数を 1 つ記述するよりも、次のように、ディクショナリに固有の関数を 2 つ記述して、それらをライブラリに配置し、スクリプトとして定義され、onLoad イベントとしてフォームにアタッチされたラッパー関数からそれらを呼び出します。
すべての場合に可能とは限りませんが、できるだけサービスに依存しないコードを作成するようにしてください。その場合、1 つのサービスでコードをテストするだけで、そのコードを使用するすべてのサービスが検証されます。
前の例のコードは、サービスに依存しません。Common_Service_onLoad() 関数は、一方または両方のディクショナリが欠落しているサービスで実行すると失敗します。しかし、これは簡単に修正できます。
上記のコードで、ディクショナリに固有のコードを適用する前に、サービスにディクショナリが存在するかテストしているように、フィールドに固有のコードを適用する前に、特定のフィールドが存在するかテストする必要がある場合があります。ベスト プラクティスは、ディクショナリを 1 つのアクティブ フォーム コンポーネントだけで使用することです。しかし、サービスに固有のルールは、ディクショナリの外観に影響を与える可能性があります。たとえば、サービスを要求する個人に対する上司情報の表示は、上司の承認が必要なサービスに対してのみ必要です。したがって、上司に関連するフィールドを操作するコードを、次のようなコード ブロックに含める必要があります。
フィールドはフォーム内で使用できますが、前に実行されたルールまたは ISF コードによっては、非表示になる場合があります。このような場合には、次のようなコードがより適切であり、またより堅牢です。
表記上はまったく問題ありませんが、ディクショナリ、フォーム、およびフィールドには同じ名前を付けないでください。同じ名前を付けると、次のように非常にわかりにくくなる場合があります。
|
|
|
|
|
ディクショナリはプレフィックス表記法を使用して、その使用方法と、場合によっては格納されているディクショナリ グループを示すのが理想的です。「Reason」ディクショナリには、かなり汎用的な響きがあり、多くのフォームで使用されているように思われます。したがって、たとえば「Common」などの名前が付けられたディクショナリ グループに配置して、ディクショナリ名にこのディクショナリ グループを示すコードのプレフィックスを付ける(たとえば、CMN_Reason)と理解しやすくなります。ディクショナリ グループは、サービス固有のディクショナリが使用されているサービス グループ、または場合によっては、ディクショナリおよびサービスを開発している会社の部門や部署を反映している場合があります。
また、容易に理解できるフォームの表記も必要です。これは、同じディクショナリまたはディクショナリのグループを使用している複数のフォームを区別する必要がある場合に特に重要です。
設計上の主な判断の 1 つに、1 つのフォームに含まれるディクショナリの数、およびどのディクショナリが含まれるかを決定することがあります。次のような場合には、複数のディクショナリを同じフォームに含める必要があります。
• これらのディクショナリがすべて同じサービスで必要とされる場合。
• ディクショナリが表示される順序がすべてのサービスで同じ場合。
• このフォームのディクショナリ間で、これ以上表示するディクショナリがない場合。サービス フォームでは、1 つのフォーム コンポーネント内のすべてのディクショナリが、そのコンポーネントで指定された順序で表示されます。そして、そのサービスに含まれている次のフォーム コンポーネントのディクショナリが、指定された順序で表示されます。以下同様です。
施設部門に対して開発されたサービスのグループには、カスタマーの役職や部門に基づき、最大 3 人の承認者によって構成されている承認のチェーンがあると想定します。この場合、Facilities_Approval フォームは、FirstApprover、SecondApprover、および ThirdApprover の 3 つのディクショナリを含む必要があり、また 3 つの承認うち、実際に収集が必要な承認の数を判断するルールを含む必要があります。
施設部門に対して開発された大部分のサービスでは、最大 3 つの標準的な承認を必要としますが、さらに高価なサービスには VP レベルの追加の承認者を必要とするものと想定します。次の 2 つのオプションから選択できます。
ほとんどの場合、最初のソリューション(わずかに複雑なフォーム)を優先する必要があります。複数のフォームで、3 つのディクショナリおよびそれらに関連付けられたルールを設定する作業を重複して行う必要はありません。これらのディクショナリまたはそれらのルールを変更する必要がある場合、それらを変更する場所は 1 箇所のみです。2 番めのソリューション(部分的に冗長な 2 つのフォーム)は、ディクショナリを追加することにより、他方のディクショナリの表示または処理方法も変更される場合のみ使用を考慮する必要があります。
ここで、フォームが使用されるサービスに基づき、フォームの動作または外観を大幅に変更する場合を想定します。さまざまなシナリオを選択できます。次に記載された条件に基づいて優先されるシナリオを決定できるのは、サービス設計者に限られます。
たとえば、実質的にすべてのサービスに、「Reason」ディクショナリが含まれている必要があります。しかし、フィールド ラベルは、「Reason」、「Justification」、または「Explanation」の場合があります。さらに、フィールドに関連付けられたヘルプ テキストは、サービスまたはサービスのグループごとに大幅に異なる必要があります。この場合、ディクショナリは単純で容易に設定できるため、判断は容易です。ディクショナリのレンダリングごとに別々のフォームを作成し、対応するサービスに適切なフォームを含めます。
しかし、サービスごとにカスタマイズの必要な単一または複数のフィールドが、潜在的に複雑なルールを持つ大きなディクショナリの一部の場合はどのようになるでしょうか。ここでも、上述と同じ 2 つのオプション(1 つのフォームまたは複数のフォーム)を選択できます。だだし、これらのオプションの内容に注意してください。
One-Form オプションは、条件付きルールを使用してディクショナリの外観をカスタマイズできないという事実によって複雑になります。条件付きルールは、フィールドの外観と動作のみを変更し、フィールドのラベルやヘルプ テキストの内容は変更しません。Multiple-Forms オプションには、前記と同様の欠点があります。事前にフォームの作成作業を行う必要があり、またルールを維持するメンテナンス作業を複数の場所で行う必要があります。
• 要件を変更します。サービスの要求時に情報を提供する方法に関し、ユーザに提供される情報が減少する可能性があるため、このオプションは推奨されていません。
• 問題があるフィールドを、複数のフォームで使用される個別のディクショナリに移動し、ディクショナリの残りの部分に対してはフォームを 1 つに維持します。これは、そのフィールドが他のフィールドの間に表示されるのではなく、他のすべてのフィールドの前または後に表示できる場合にのみ可能です。
これまでの説明では、ディクショナリ、フォーム、およびルールは、次のように構造化されていることを前提としていました。
• フォームは通常、ディクショナリのセットおよびルールのセットによって構成されます。
• ルールは、同じフォーム内のディクショナリ(およびそれらのフィールド)だけでなく、他のフォーム内のディクショナリにも影響を与える可能性があります。
• 特定のサービスのコンテキストでルールを徹底的にテストし、参照されるすべてのディクショナリがそのサービスに含まれるフォーム内に存在することを確認することが非常に重要です。Best Practices Reports には「Dictionaries in Services」レポートが含まれます。これを使用すると、このテストの実行、および提案された変更がディクショナリまたはルールに与える潜在的な効果を調べるための影響分析が容易になります。
また、特定のサービスに適用されるルールのみが含まれるように Form 2 を構成する場合にも最適です。多くのサービスは、Form 1 のみを含むことができますが、追加の要件付きサービスのみ Form 2 を含みます。これにより、Form 2 のルールに必要な条件が大幅に簡素化(場合によっては不要化)され、適切なサービスに対してのみ実行されることが保証されます。
また、サービス名(変更される可能性のあるテキスト要素)をテストする条件付きルールを記述する必要もなくなります。影響を受けるサービス内に、影響を受けるディクショナリ持つフォームに続いて、順番にルール専用フォームを含めることのみ必要となります。ルールは、フォームがサービスに含まれる順序に従って、次にルールがフォーム内に配置される順序に従って実行されます。
ルールとそのルールが影響を与え、参照するディクショナリが同じ AFC 内にある場合、そのルールとディクショナリは「密結合」されているといいます。別のフォーム内のディクショナリの外観に影響を与えるルールを使用した上記の例では、ルールとディクショナリは「疎結合」されています。
一般に、両方のフォームが同じサービスに含まれる場合、ルールは、任意のフォーム内のディクショナリに影響を与えることができます。ただし、疎結合されたルールとディクショナリには、1 つ重要な制限事項があります。つまり、1 つのフォーム内で定義されたルールは、別のフォーム内のディクショナリのフィールドにアタッチされたフィールド レベル イベントによってトリガーすることができません。したがって、疎結合されたルールは、通常、フォームがロードまたは送信されたときに、フォーム レベル イベントによってトリガーする必要があります。
要求が送信されると、ディレクトリのすべての定義、HTML 表現、アクセス コントロール、およびそのサービスのタスク計画が、要求データとともに保存(圧縮形式)されます。これにより、処理中の要求のサービス フォームの動作または外観に影響を与えるフォームの定義を後から変更することなく、承認時点と提供時点を通して要求を処理できます。
ディクショナリを変更すると、そのディクショナリを使用するすべてのフォームが自動的に変更を継承します。また、それらのフォームを使用するすべてのサービスも変更を継承します。保存されているが送信されていない、変更されたサービスに対するすべての要求は、古い要求としてマーク付けされます。要求をキャンセルするかサービスを削除し、再度追加してサービス フォームにデータを入力する必要があります。送信された要求は、ディクショナリまたはアクティブ フォーム コンポーネントへの変更によって影響されません。
ただし、ルールと ISF 関数(スクリプトまたは外部のライブラリにある)は、サービス フォームが My Services または Service Manager に表示されると、常に動的にロードされます。したがって、現在のバージョンのルール/コードが、すでにフォーム上に存在しないフィールドを参照しないこと、または逆に、すでに使用されていない前バージョンのフォーム上のフィールドは、関連する関数を持つことができることを確認する必要があります。前に説明したように、この柔軟性は、ISF を介してディクショナリまたはフィールドを操作する前に、ディクショナリまたはフィールドが存在することを常に確認することによって容易に実現できます。必要に応じて、異なるバージョンのライブラリを新しいバージョンのフォームにアタッチできます。これにより、たとえば、関数の名前を変更することなく、改訂された要件に準拠してその内容を更新できます。
専門的なアラート:ディクショナリおよびアクティブ フォーム コンポーネントは、真の「継承」を示します。前述の「ルール、ISF、および要求ライフ サイクル」の項で説明したように、ディクショナリ内のフィールドの定義を変更すると、その変更はすべてのアクティブ フォーム コンポーネントに反映されます。同様に、アクティブ フォーム コンポーネント定義の任意の側面を変更すると、その変更はそのフォームを使用するすべてのサービス定義に反映されます。
条件付きルールに関連付けられたディクショナリやディクショナリ フィールド、またはデータ取得ルールをトリガーするディクショナリやディクショナリ フィールドを削除/変更することはできません。まず、関連付けを削除する必要があります。この検査は、JavaScript 関数に対しては実行されません。
フォームを変更するたびに、そのフォームを組み込むすべてのサービス定義のバージョン番号が、アプリケーションによって自動的に更新されます。フォームが多数のサービス内で使用されている場合、このような変更の保存にわずかな遅延が生じる場合があります。また、Requisition API(RAPI)SubmitRequest 操作では、指定するサービスのバージョン番号が必要となるため、サービスをオーダーするために実装されたすべての RAPI プログラムに影響を与える場合があります。
SQL に精通していない場合、SQL 入力データ取得ルールのコーディングには、多少身構えてしまうかもしれません。SQL に詳しくなる「秘訣」は、より単純なバージョンとしてデータベース テーブル検索ルールの設定から始めることです。ルールを保存した後、生成した SQL がルールの概要に表示されます。SQL ステートメントをコピーして SQL 入力データ取得ルールに貼り付け、必要に応じて修正できます。
#Customer# および #Initiator# の Lightweight 名前空間は、Customer-Initiator フォーム コンポーネントで使用される Customer_Information ディクショナリおよび Initiator_Information ディクショナリのフィールドに、デフォルト値として自動的に提供されます。ただし、これらの名前空間は、すべてのフォーム コンポーネントでデフォルト値として使用できます。
カスタマー ロケーションに関する情報を保持するディクショナリの設計には、この技法を使用できます。カスタマー ロケーションに関するフィールドは、Customer_Information ディクショナリに含めることができます。ただし、このようなフィールドを必要とするサービスは、サービスをカスタマーの物理的な場所に提供する必要がある場合などに限定されており、非常に少数です。より柔軟な設計では、カスタマー ロケーションに対して個別のディクショナリ(およびフォーム コンポーネント)を設定し、このフォーム コンポーネントをカスタマー ロケーションに関係するサービスにのみ含めます。
複数の名前空間をデフォルト値として指定できます。たとえば、#Customer.FirstName# #Customer.LastName# という式は、カスタマーの姓と名前を 1 つのスペースで区切って連結します。この式は、個人ベースのディクショナリの最初のフィールドの外観を複製します。
(注) Lightweight 名前空間のグリッド ディクショナリ フィールドの使用は、現在サポートされていません。
複雑なサービス カタログでは、数百ものインスタンスを容易に入手できます。ここで、アクティブ フォーム ルールまたは ISF 関数を使用して、サービス フォームの使用性と対話性を向上させることができます。
1. 使用例の分析を実行して、必要とされるルールおよびそれらを起動するタイミングを判断します。
2. 詳細設計分析を実行して、指定された使用例のサポートに必要なディクショナリとフィールド、ディクショナリをフォームに組み込む方法、および要件の実装に必要なツールを判断します。
3. ディクショナリとフォームを定義します。フォームの表示とアクセス コントロールのプロパティを指定します。
4. アクティブ フォーム ルールを記述し、詳細設計の条件を満たすように並べます。必要に応じて、JavaScript 関数とライブラリを記述して、関数を適切な HTML イベントまたはイベント群にアタッチします。
5. 以前定義した再使用可能なフォーム コンポーネントを使用するサービスを定義します。
この項では、サービス フォームに統合されたルールと ISF コードの両方の例、および要件を満たすための実装上の各判断を示します。また、これらの例では、次のようないくつかの一般的な設計パターンを示します。
• 特定のタスクに基づいて、ディクショナリの外観と動作、またはそのいずれかを調整する
• サービス フォームがロードされた場合、またはユーザが別のフィールドの値を変更した場合に、ディクショナリまたはフィールドを表示/非表示にする
• マネージャが [Person] フィールドの変更を検索する
ユーザ要件を確認し、サービス フォームのデフォルトの動作および外観を、ルールと ISF の一方または両方によって補完する必要がある場合を判断します。これらのユーザ要件は不定形の文書にまとめることもできますが、動作とそのトリガー イベントを明示的に定義した表を使用することを推奨します。次に例を示します。
|
|
|
サービス名 は、要件による影響を受ける「すべて」のサービス名、またはサービスのリストのいずれかです。
使用例の説明 は、ビジネス ユーザがアクセス可能な言語で、サービス フォームが目的とする動作を指定します。
時点 は、要求の実施中に発生する「すべて」の時点、または 1 つ以上の時点のいずれかです。有効な時点のリストについては、「サービス フォームのフレームワーク」を参照してください。
詳細設計フェーズでは、プログラマは、以前定義した使用例を確認し、記述する必要のあるルールや JavaScript コンポーネント、およびこれらのルール/関数のトリガー イベントをおおまかに指定する必要があります。設計には、関連するフォーム、ディクショナリ、およびフィールドの詳細な仕様が組み込まれます。特に、次の点に注意して分析を実行する必要があります。
• ISF を使用して、フォーム ルールを補完する必要がありますか。補完する必要がある場合には、自身の開発環境が ISF(JavaScript)の開発、テスト、およびデバッグをサポートするように設定され、必要なスキル セットを備えた担当者が作業できることを確認してください。
• データ取得ルールまたは SQL オプション リストを使用する必要がありますか。使用する必要がある場合は、開発環境に SQL クエリーをテストおよびデバッグする手段が含まれること、目的のデータにアクセスできるようにデータソースが定義されていること、ソース データの構造に関する知識および必要なスキル セットを備えた担当者が作業できることを確認してください。
データベースの作成を要求する場合には、データベース サーバのタイプを、Oracle、SQLServer、または「その他」のデータベースから選択する必要があります。エンタープライズ標準ではないその他のデータベースを選択すると、追加の情報をユーザから収集する必要があります。それ以外の場合は、追加のフィールドが非表示になります。
その場合には、同じディクショナリ内の Description フィールドを表示し、ユーザに対して追加情報を入力するように要求する。 |
たとえば、NewDatabase という名前のディクショナリを定義します。
• ディクショナリには、オプション ボタンとしてレンダリングされた DatabaseType という名前のフィールドが含まれており、これを使用して、Oracle、SQLServer、またはその他のデータベースを指定できます。
• [Other] を選択すると、必ずデータベースのタイプを指定する必要があります。それ以外の場合は、このフィールドは非表示になります。
[AIT_DATABASE.DatabaseServer] フィールドには、フィールドの値が変更された際に起動するルールが必要です。
• ユーザが選択した値が「Other」の場合、ルールによって、「Other」に依存したディクショナリ フィールドを表示し、そのようなすべてのフィールドを必須にする必要があります。
• ユーザが選択した値が「Other」ではない場合、ルールによって、「Other」に依存するフィールドが表示されないようにする必要があります。
残念なことに、このリリースの Service Portal では、if/then/else ロジックがルールに含まれていないため、この設計を実装するには 2 つのルールが必要です。
このルールは、いつ適用すべきでしょうか。より技術的な用語では、サービス フォームにデータを入力する過程で「トリガー イベント」とは何であり、このルールを「起動」するタイミングはいつでしょうか。
ユーザが [DatabaseServer] オプション ボタンから値を選択した場合、明らかにルールを実行する必要があります。したがって、このフォームの [Active Form Behavior] タブを使用して、これら 2 つのルールを「When the field changes」イベントに関連付けます。この場合は、ルールを適用する順序は関係ありません。いずれかのルールが起動しますが、両方ではありません。
このシナリオをテストするには、定義したばかりのアクティブ フォームが含まれているサービスの定義を完了する必要があります。簡単なテストを実行するため、そのフォームだけを含むサービスを最初に作成できますが、これは最初のステップにすぎないことは明らかです。フォームとそのルールは、他のフォームおよびそのルールと相互作用できるため、最も現実的なテストが最良のテストになります。
複数のブラウザ ウィンドウを使用すると、このシナリオを最も容易にテストできます。1 つのブラウザで Service Designer を開いた状態で、[Active Form Components] オプションを表示します。次に、新しいセッションを開始し、サービスをオーダーする権限を持つ My Services ユーザとしてログインします。何が起きるか観察します。
以前定義したルールは、正しく機能するはずです。ただし、カスタマーがオペレーティング システムを変更(または最初に選択)した場合にのみ動作がトリガーされるため、実装は不完全です。ディクショナリが編集可能な場合に、それ以降のシステム時点でフォームを保存して確認、または送信して表示する場合は、[DatabaseServer] フィールドの保存された値を使用してフォームの外観を調整する必要があります。したがって、フォームがロードされた際に起動するには、追加のトリガー イベントが必要です。
使用方法に関しては、Customer ディクショナリに影響を与えるシナリオと、Customer-Initiator フォームに影響を与えるシナリオの、2 つの異なるシナリオを考慮する必要があります。
標準的なフィールドに加えて、カスタマー プロファイルに格納されたカスタマー ロケーションに関するフィールドを表示しますが、たとえば、ファイル上のロケーションが古い場合や、カスタマーが一時的に別の場所にいる場合のために、代替サービス ロケーションを指定できます。 |
設計は、次の 3 つのディクショナリを使用して実装できます。
• 両方のタイプのサービスに提供する必要のあるすべてのフィールドを含むように、Customer ディクショナリを設計します。これらのフィールドには、常に必須のフィールド、および要求者がサービスの提供先のロケーションを指定または確認する必要がある場合のみ必須のフィールドがあります。
• 本人に直接提供されるサービスに対してのみ表示される Perform Work ディクショナリを設計します。このフォームには、作業がカスタマー ロケーションで実行されたか、別の(サービス)ロケーションで実行されたかを問い合わせるフィールドが 1 つあります。
• デフォルトでは、カスタマーのプロファイルからロケーション情報が入力される Service Location ディクショナリを設計します。ただし、発信者が、この情報とプロファイル内の情報が異なることを指摘した場合には、上書きすることができます。
Customer ディクショナリと Initiator ディクショナリは、通常、すべての時点で読み取り専用です。つまり、データは個人のプロファイルから表示され、カスタマーとタスク実行者のいずれによっても変更できません。
ディクショナリ内のすべてのフィールドを読み取り専用にするには、少なくとも次の 3 つの方法があります。
• フォームの [Access Control] タブを使用して、該当する時点と参加者に対してディクショナリを表示可能(編集可能ではない)に指定します。このコントロールは、ルールと ISF のいずれでも上書きできません。表示可能ディクショナリは非表示にできますが、編集可能にはできません。また、フィールド値は、入力フィールド内ではなく、定型文として表示されます (Q: Would lightweight namespaces work?)
• ディクショナリを [Access Control] タブで編集可能にしますが、デフォルト フィールドを読み取り専用の HTML 入力タイプを持つように、またロケーション関連フィールドを非表示の入力タイプを持つように定義します。非表示フィールドと読み取り専用フィールドの両方が、関連付けられた Lightweight 名前空間から値を提供されます。
• [Access Control] タブでディクショナリを編集可能にし、適切な入力タイプを標準フィールドに割り当てますが、フォームがロードされるときに適用されるルールを作成し、ディクショナリ内のすべてのフィールドを読み取り専用にします。このルールは、非表示フィールドには影響しません。
この場合には、2 番めのオプションが最も大きな意味を持ちます。たとえば、ユーザが自分の個人ファイルの古いデータを更新できる場合、フィールドを潜在的に書き込み可能にすることができます。また、追跡しない余分なルールもありません。これは、Customer-Initiator フォームに対処します。
また、PerformWork ディクショナリと ServiceLocation ディクショナリが使用されているフォームも必要です。このフォームを ServiceLocation と呼びます (Q: Naming conventions?) PerformWork ディクショナリ内のフィールドは、チェックボックスとして実装できますか?(作業は、カスタマー サイトで実行しますか)。ServiceLocation ディクショナリには、Customer ディクショナリに含まれる個人フィールドに対応するフィールドが存在する可能性があります。
ここで、サービス ロケーションが必要なサービスに対するルールが必要になります。ルールは、以下を実行する必要があります。
• デフォルトのロケーション値を Customer ディクショナリから ServiceLocation ディクショナリにコピーします。これは、onLoad イベントで実行できます。
• ユーザが異なるサービス ロケーションを必要とする場合、ServiceLocation フィールドを書き込み可能にします。これは、[PerformWork] フィールドの onChange イベントで実行する必要があります (Q: Nomenclature, again).
COBOL を覚えている人はいますか。多くの場合、COBOL でのコーディングは耐えがたいほど冗長でしたが、本当に簡潔なコマンドが 1 つ存在しました。それは、COPY CORR(esponding)です。COPY CORR コマンドは、名前によって、1 つの構造体からすべての値を、別の構造体の対応する名前の値にコピーしました。COPY CORR Dictionary1 TO Dictionary2 を実行できればよいのですが、これは不可能です。したがって、最初のルール(ServiceLocation_onLoad)をオーダー時点で適用し、すべてのロケーション フィールドに対して Copy Value を実行します。
2 番めのルール(PerformWork_onChange)は直接的であり、最初のシナリオで記述したルールを想起させます。
このシナリオをテストするには、ServiceLocation フォームを含むものと含まないものの、2 つのサービスが必要です。
サービスは、「知る必要がある」人物のみ使用可能であり、サービスの実行に関係するすべての承認者またはタスク実行者は使用できない、社会保障番号やクレジット カード情報のような機密性の高いデータを指定するようユーザに要求します。これらのデータは、ハッカー行為からも保護する必要があります。
デフォルトでは、ディクショナリの表示プロパティが Service Designer で「none」に設定されている場合、ディクショナリおよび以前入力されたフィールドの値は、生成されユーザに表示されるサービス フォームには含まれません。(この設定は、2007 よりも前のバージョンの Request Center の動作に対する下位互換性のため、変更される可能性があります。dictionary.permission.none.show newScale プロパティの設定については、Request Center 管理者に確認してください)。そのため、フィールドのデータは、ブラウザからページ ソースを表示するために十分な知識も持っているユーザに対しても表示されなくなります。
最初にユーザがフィールド値を入力できるようにするには、(当然ながら)フィールドをフォームで表示する必要があります。また、ディクショナリの表示設定は読み取り/書き込みに設定します。フィールドの HTML 表現は、「password」に設定できます。フィールド値は、一連のアスタリスクとして表示されます。
これにより、背後から覗き見する人から値を保護できます。しかし、ページのソースを表示すると、フィールドの値が表示されます。フィールドの値は ISF の getValue() 関数ではアクセスできず、「undefined」が返されます。フィールドの値は、DOM、つまり次のような JavaScript メソッドを通して使用できます。
暗号化と上記の方法のいくつかを組み合わせて使用することにより、機密性の高いデータの保護を強化できます。パスワード フィールドを使用する代わりに(または、それに加えて)、機密性の高いデータを保存する前に JavaScript 関数を使用して暗号化し、フォームで表示する前に復号化します。 「Tiny Encryption Algorithm」と呼ばれる Web 上のオープンソース アルゴリズムを使用できます。
スクリプトでコードを暗号化/複合化する関数を定義した場合、ユーザが View Source を実行するとフォームに関数が表示されます。 しかし、ライブラリに関数をインクルードした場合、ソースを表示しようとするユーザに対して関数が表示されず、リバース エンジニアリングの対象になりません。
サービスは、オーダーするアイテムの「数量」と「価格」を指定するようユーザに要求します。サービスは、「合計価格」を計算し、サービス フォームにこの値を表示する必要があります。
3 つの数字フィールドを含む、SVC_PRICE と呼ばれるディクショナリを作成する必要があります。要件の詳細に応じて、フィールドは 10 進数精度の場合とそれ以外の場合があります。ディクショナリはサービス フォームに含まれており、オーダー時点でカスタマーによる書き込みが可能です。すべてのフィールドは、テキスト フィールドとしてレンダリングされます。
[Total] フィールドは、ユーザによる値の入力が許可されていないため、読み取り専用の必要があります。計算された値が入力されます。ユーザが [Price] または [Quantity] のいずれかを変更すると、計算を実行する必要があります。
このタスクには、次の 3 つのカスタム イベントが必要です。
• SVC_PRICE_onLoad イベントは、[ExtendedPrice] フィールドを読み取り専用に設定します。
最初のタスクは、初めてフォームをロードした際に実行するよう推奨します。そのためには、Script Manager で SVC_PRICE_onLoad と呼ばれる関数を作成します。
このコードは、[Behavior] タブの [When the form is loaded (browser-side)] イベントに関連付けられています。
2 番めのタスクでは、[Quantity] と [Price] に基づいて [ExtendedPrice] を計算します。[Quantity] と [Price] の両方に対して、[When the item is changed] イベントを使用します。コードは、両方のフィールドに有効な値があることを確認して [ExtendedPrice] を計算する必要があります。この関数は、SVCPRICE_Price_onChange と呼ばれます。
Service Designer でスクリプトとして定義された上記のコードは、[Price] フィールドと [Quantity] フィールドの 2 つの異なるフィールドの onChange イベントにアタッチできます。実際に、これは、コードを最初にテストする場合に効率的な方法です。ただし、このアプローチは、この使用方法を反映しない関数名を持ち、ライブラリを使用しない場合には、長期的に維持することは困難です。したがって、次のリファクタリングを実行することを推奨します。
• 関数コードを編集して、関数名を「ComputeExtendedPrice」などの汎用な名前に変更し、スクリプトからコードを抽出してアプリケーションのカスタム ライブラリに配置します。
• カスタム ライブラリが [Scripts] > [Libraries] で定義され、この関数が要求された際にサービス フォームに取り込まれることを確認してください。
• これらの関数を、それぞれ [Price] フィールドと [Quantity] フィールドの onChange イベントにアタッチします。
JavaScript 関数を作成し、フォームにある社会保障番号と電話番号の 2 つのフィールドの書式を設定します。SSN は、「999-99-9999」のように書式化された 9 桁の番号があることを確認する必要があります。ユーザによって作成された書式は無視されます。電話番号は、「(999) 999-9999」のように書式化された 10 桁の番号である必要があります。
formatSSN と呼ばれる関数と、 formatPhoneNo と呼ばれる関数の 2 つの関数を作成します。両方の関数を「isfprimerlib.js」という名前のファイルに入れます。前述の項で説明したように、このファイルは、アプリケーション サーバの RequestCenter.war ディレクトリ下の任意のディレクトリに存在する可能性があります。慣例では、ISF ライブラリは「isfcode」という名前のディレクトリに配置されます。
Script Manager 内の JavaScript ファイルに、ライブラリ参照を作成します。[Libraries] タブで、サービスにアタッチされる JavaScript 関数のライブラリを必ず指定してください。
[SSN] のフィールドに対して、 formatSSN を呼び出す、 Customer_SSN_onChange と呼ばれる関数を作成します。
[PhoneNo] フィールドに対して、フィールドの値が変更された場合に formatPhoneNo を呼び出す、 Customer_PhoneNo_onChange と呼ばれる別の関数を作成します。単に別の実装方法を示すため、これらの関数はフィールドの名前を渡して、「値によって」ではなく「参照によって」機能します。
この項では、外部サーバとの間で、HTTP 要求を介してサービス フォーム データを相互に転送する方法を説明します。この機能の目的は、アプリケーション サーバとは別の Web サーバに存在する Web ウィジェットを、Service Designer で使用できるようにすることです。この項では、サービス フォーム データの実際の転送および処理についてのみ説明します。
サービス フォーム データは、HTTP フォーム ポストを介して外部の Web ウィジェットに送信されます。データは、WDDX パケットとして WDDXData 変数で wddxdataform フォームに渡されます。WDDX は、シリアル化されたパケットにデータ構造を保存するための XML スキーマです。これにより、使用するプログラミング言語に依存せずに、データを Service Portal に渡すこと、または Service Portal から渡されることができます。Service Portal ページに対する HTTP 要求を使用して、サービス フォームに結果のデータ セットを戻すことができます。