Cisco Service Portal 設計者ガイド リリース 9.3.2
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月6日
章のタイトル： 名前空間
名前空間
•
「概要」
• 「式」
概要
名前空間について
Business Engine には、サービス設計者およびシステム管理者が条件付きワークフローを指定することで、承認および提供プロセスによって電子メールの内容をカスタマイズし、要求の進行を動的に設定する機能が用意されています。
この機能を実現するため、Cisco Service Portal（Service Portal）では、要求の発信者や、要求に関連するサービス フォーム データなどのデータ要素の値に統一的な手段でアクセスできるようになっています。この統一的な手段は Business Engine 名前空間と呼ばれます。
名前空間機能を利用すると、名前空間変数の現在の値に応じて、提供計画に承認や条件に応じて実行されるタスクを組み込んだり、特定のタスクのルーティングを動的に調整できたりするようになり、サービス設計の柔軟性が高まります。電子メールの内容、件名、アドレスを動的に調整することもできます。
（注） Business Engine 名前空間に対するグリッド ディクショナリ フィールドの使用はサポートされていません。
名前空間の定義
名前空間 とは、Service Portal 内で使用されるデータ オブジェクトを示す、一連の有効な名前を表すために使用される用語です。サービス設計者には、そのオブジェクトがその名前で提示されます。その結果、設計者は次のコンテキストでこれらの要素を使用できます。
• 電子メールの中で、受信者、件名、または電子メール本文中の参照先を動的に解決する場合。
• 提供計画の中で、確認、承認、またはタスクを条件に応じて実行する場合。
• 承認または提供タスクの割り当て先となる個人またはキューを判定する式の中。
名前空間は階層的になっています。名前空間の名前は、サービスを定義するデータの構造、およびサービスが要求されたときにサービス フォームに入力されるデータを反映したものとなります。名前空間変数の操作で重要となるのは、Service Portal のデータを定義する階層構造、およびその名前空間変数を使用可能なコンテキストに関する知識です。
階層内の各要素では大文字と小文字が区別されます。要素はピリオド（「.」）で区切られます。最後の要素は「プロパティ」と呼ばれることもあります。最後の要素の前にあるすべての要素は階層の「ノード」です。
参照
名前空間がテキスト型コンテキストの中で電子メール テンプレートまたは代入式として使用される場合は、名前空間を周囲のテキストと区別するためにデリミタが必要です。その場合はデリミタとして「#」文字で名前空間参照を囲みます。
ノード
階層内のすべてのノードにはノード タイプがあります。タイプによって、その要素で使用可能なサブノードとプロパティが決まります。
|
|
|
ノード タイプ OrganizationalUnit（OU）と Person は、名前空間内に複数のインスタンスを持ちます。たとえば、Person ノードは要求の Customer および Initiator として、およびその他の多くのコンテキストに出現します。この場合、該当する個人のデータの参照には「PersonType」が使用されます。
Service ノード、およびその子ノードは特定のサービス要求に関連しています。このようなノードの要素を使用できるのは、現在のサービス要求が存在するコンテキスト内だけです。特に、個別の要求ではなく、買い物カゴ全体に適用される、サイトおよび組織レベルの承認に関連する電子メールおよび設計コンフィギュレーションには、Service ノードを含むことができません。同様に、個別のサービス要求ではなく要求に関連する Order Confirmation Email テンプレートには、Service ノードを含むことができません。
PersonType の詳細、および名前空間の階層構造と、各ノードで使用可能なプロパティおよびサブノードについては、「Person-Based 名前空間」に概要を示します。
すべての日付はグリニッジ標準時（GMT）で維持されます。日付データには日付と時刻の両方が含まれます。すべての日付は次の形式で表示されます。
4 桁の年、2 桁の月、2 桁（1 桁の場合はゼロを追加）の日と、それに続く 24 時間制の分、時、秒、小数点以下の秒となります。たとえば、「2007-06-27 23:19:39.197」は 2007 年 6 月 27 日、午後 11:19 を表しています。
式
承認、確認、提供の各タスクは、個人またはキューに割り当てるか、式を使用して割り当てることができます。式は、Organization Designer 内に格納され、タスクの動的割り当て先となる個人またはキューを識別する手段として利用できます。
式の設定
個人またはキューは、次の 4 つの割り当てタイプのいずれかを使用して識別できます。
|
|
|
• 代入演算子（=）の直前に AssignmentType、直後に Namespace_Expression を指定し、空白を入れない。
• Namespace_Expression で使用する名前空間はハッシュ マーク（#）で囲む。
• 式では、名前空間と定数データを組み合わせて、個人のフルネームまたはキューの名前を作成できる。式の要素は空白 1 つで区切ります。
• 変数および役職名には空白を入れず、式が正しく評価されるようにする。
• 式の結果を使用したすべてのデータベース ルックアップでは大文字と小文字が区別されない。たとえば、代入タイプ LOGINNAME で式が「Ann」と「ann」のどちらに評価された場合も同じ結果となり、ログイン名が「ann」、「Ann」、または「ANN」という個人が検索されます。
CN（Common Name）代入
代入タイプ CN では、指定されたフルネームと、Organization Designer に格納されたデータを照合することで、個人が検索されます。
名前空間式内の値は、Organization Designer に格納された該当ユーザの名前と完全に一致している必要があります。たとえば、値が「Carroll Hastings」という CN 式は、Organization Designer 内の名前が「Carol Hastings」というユーザと一致しません。そのため、ユーザが自由形式テキストでデータを入力可能なディクショナリ フィールドは使用しないでください。その代わりとして、Person データ型を使用して入力されるディクショナリ フィールドを使用し、ユーザが個人をダイアログボックスで選択するようにすることで、タイプ ミスを防止してください。または、状況に応じて Customer、Initiator、Performer など他の名前空間を使用する方法もあります。
CN 代入を使用する場合は注意が必要です。姓名が同一の個人が 2 人いる場合は使用しないでください。この代入では、指定された名前で最初に検索された個人（PersonID が小さいほう）が必ず選択されます。
ディクショナリのフィールドが、個人ベースのディクショナリの「Select_Person」フィールドと同様に、Person データ型で定義されている場合は、[Select Person] 検索ボックスで個人を選択すると、そのフィールドの値が入力されます。その値は、Organization Designer 内の個人の固有識別子に設定されます。この「ID」値は CN 代入で参照できます。
ID（識別子）代入
名前空間で利用可能なすべての Person ノードの PersonID は、ID 代入と呼ばれることがあります。または、PersonID がコピーまたは割り当てられたテキスト フィールドを使用することもできます。
LOGINNAME 代入
ログイン名はアプリケーション内で個人を一意に識別し、代入に安全に使用することができます。
QUEUE 代入
キューは、サービス チームに基づくだけでなく、カスタマーの位置に基づいた代入が必要になることがあります。このような位置ベースのキューは、QUEUE 割り当てを使用すると利用できます。
この代入では、タスクまたは承認が「 Location Desktop Services」という名前のキューに割り当てられます。この Location は、サービス フォームの RC_Queue ディクショナリにある Location フィールドの現在の値です。その結果得られる QUEUE の値は、Organization Designer で定義されたキューに割り当てられた名前と 完全に 一致している必要があります。この照合では大文字小文字が区別されます。一致するものが見つからなかった場合、そのタスクは未代入作業キューに割り当てられます。
電子メール テンプレート
名前空間は、電子メール テンプレートの次のセクションで使用できます。
電子メール テンプレートの定義
[Email Template] 定義ページには [Administration] メニューからアクセスします。
電子メールテンプレートのプレビュー
電子メール テンプレートをプレビューするには、次の手順に従います。
ステップ 1 Service Designer モジュールを起動します。
ステップ 2 Services コンポーネントで、画面左側からサービスを選択します。
ステップ 5 プレビューする電子メール テンプレートを、[Email] サブタブ領域にあるドロップダウン リストに表示されたいずれかのタイミングに割り当てます。
ステップ 6 割り当てを行った電子メール テンプレートの右にある、対応する [Preview] ボタンをクリックします。
電子メール テンプレートでの名前空間の使用法
使用可能な名前空間データは、電子メールの送信されるコンテキストによって異なります。たとえば、タスクレベルのデータ（プロセスまたはアクティビティの詳細）は、財務承認など要求レベルのイベントでトリガーされる電子メールで使用できません。どの電子メールでどの名前空間が使用可能かの詳細については、「名前空間の参考資料」を参照してください。
受信者
名前空間は、要求に興味を持つ個人への電子メールの送信に使用できます。
Subject
電子メール テンプレートの件名行にハード コーディングされたデータに加えて、名前空間を使用してテンプレートを（サービス全体で外観を一定に保ちながら）要求に応じたものにすることができます。
|
|
|
本文
件名フィールドと同様、電子メールの本文も要求データ、タスク データ、サービス データ、またはサービス フォーム データが含まれるよう設定できます。
|
|
|
Service Portal にアクセスするための URL。[Profiles] > [Preferences] で設定された、ユーザのデフォルト ビューに解決されます。 |
|
サイト URL 名前空間
名前空間 #Site.URL# は、Service Portal にアクセスするための URL を指定します。この URL パスには、実行する特定のモジュール、およびそのモジュールに渡すパラメータ（とそれに続く疑問符）が含まれることがあります。上記の例では、ユーザを My Services モジュール、Service Manager モジュール、またはそのモジュールで利用可能な機能に移動するハイパーリンクが、電子メール本文に生成されます。
My Services または Service Manager の任意のページに単純にリンクする、名前空間参照を作成することが可能です。正しい URL の判別で重要なことは、サイト管理者に一時的にサイトのデバッグを有効にしてもらい（ただし『 Cisco Service Portal Configuration Guide 』の警告をよくお読みください）、目的のページに移動したときに表示される URL を確認することです。その URL を電子メールに埋め込むには、アンパサンド（&）などの文字に、符号化された形式を使用する必要があります。
サイト URL の設定
インストール プロセスの中で、管理者は Service Portal の URL を指定します。この URL はコンフィギュレーション ファイル be.properties に格納されます。エントリの例を次に示します。
ObjectCache.Application.URL のエントリは、名前空間 #Site.URL# の値になります。通常、URL は末尾が「/RequestCenter/」になりますが、要求を/RequestCenter/ に自動的に転送するようアプリケーション サーバが設定されていることが可能なため、プロパティ ファイルにはパスのこの部分がない場合があります。その場合は、#Site.URL# /RequestCenter/ myservices/myservice.do? のように、#Site.URL# の後ろに /RequestCenter/ を追加し、名前空間リンクが正しい URL に解決されるようにする必要があります。
/RequestCenter 参照を挿入する必要があるかどうかを調べるには、be.properties ファイルを確認してください（または、アプリケーション サーバ管理者に内容を報告してもらってください）。次の方法もあります。
• 電子メールに #Site.URL# だけを入力し、その電子メールをタスクの開始時などに送信します。
• その電子メールを受信したら、URL が http://www.mycompany.com とだけ解決されているか、http://www.mycompany.com/RequestCenter/ と解決されているかを確認します。
• 解決された URL に /RequestCenter/ が含まれていない場合は、#Site.URL# の後ろに /RequestCenter/ を追加します。
Service Link メッセージ名前空間
名前空間ノード #Message# を使用できるのは、Service Link で発信メッセージの配信に失敗した結果生成された電子メール メッセージの本文内だけです。使用するテンプレートは、Service Link エージェント定義に「Failed Email」として指定されます。このノードの要素は、管理者が失敗の原因を診断するときに役立ちます。
Service Manager タスク詳細 URL
#URL# 名前空間では、ユーザが Service Manager 内のタスクのフォーム データに直接移動します。これは Ad-Hoc タスク、および Service Portal でほとんどタスクを実行しないチームに最適です。承認タスクにも使用できますが、承認者がサービスを承認または拒否後、Service Manager に自分が移動したことに気付き、混乱の元となることがあります。
カスタマーによっては、#Site.URL#myservices/navigate.do?query=authorizationtask&taskId=#ActivityID# 名前空間で承認する場合に、フォーム データの表示に必要なマルチステップ プロセスに、これが好まれることがあります。実際には、承認者がフォーム データを見ることなく承認することができ、そのデータが承認するうえで重要な場合は、監査上でやや問題となることがあります。サービスの名前をクリックするとフォーム データを確認できることを、承認者が知っておく必要があります。
名前空間の処理と代替値
名前空間要素が参照されると、Service Portal はその値を現在のコンテキストから取得し、電子メール内の名前空間の参照を、解決された値で置換します。カスタマーや要求の発信者に関連するものなど、一部の名前空間要素は常に存在し、有効な値を持つことが保証されています。それに対して、その他の名前空間要素は、一時的に未定義になることがあります。たとえば、役職が空席となったり、代理承認者が指名されていなかったり、従業員が一時的に上司なしになることがあります。
未定義の名前空間への参照は、すべて空白となります。電子メール名前空間を除いては、その名前空間要素名の直後にスラッシュ（/）を使用し、代替値を割り当てることができます。
• 指定された確認者と、可能性のある代理人（代理承認者）の両方に送信する電子メールを設計します。現在、委任が指定されていない場合、#Alternate.email# は空白になります
• 現在、参照されている個人に上司がいる場合は、その上司の姓が電子メールに表示されます。いない場合は、「Your current supervisor」という文字列が表示されます。
Demand Center テンプレート
名前空間は、ある契約で作業中に発生するイベントへの応答として、Demand Center から送信される電子メール通知で使用できます。ユーザは、Administration モジュール内の契約通知イベントにリストされたイベントへの応答として送信される、デフォルトの Demand Center 電子メール テンプレートをセットアップできます。契約通知イベントは、Demand Center 電子メール テンプレートの下、または [Email Templates] リストの下にある [Go To Agreement Notification Events] ボタンをクリックすると表示されます（Demand Center 電子メール テンプレートを表示するには [Demand Center] タブをクリックする必要があります）。
マッピングによって、これらのイベントへの応答で使用されるデフォルト テンプレートがセットアップされます。このようなデフォルト テンプレート以外に、テンプレートは特定のサービス提供用にカスタマイズできます。
承認、確認、および提供タスク
承認および確認
承認によって、要求が処理される確認および承認のステップが決まります。Service Portal では、サービス設計者とサイト管理者が次のレベルで承認を設定できます。
• サイト 。サイトレベルの承認では、そのサイトのすべてのサービスに対するデフォルト承認構造が設定されます。このような承認は、Administration モジュール | [Authorizations] タブ、または Service Designer で [Site]（最上部）を選択 | Catalog コンポーネントで保守されます。
• 組織単位 。組織単位レベルの承認では、現在の組織による部門承認および確認に対する承認構造が設定されます。指定された構造は、サイト全体の承認を上書きするもの、または補足するものとして設定できます。組織単位承認は、Organization Designer モジュール | [Org Units] タブ | [Authorization] リンクで保守されます。
• サービス グループ 。サービス グループレベルの承認では、サービス グループに対する承認構造が設定されます。この構造は、サイトの承認構造を上書きするもの、または補足するものとして設定できます。サービス グループに対する承認は、Service Designer の Service Catalog でサービス グループを選択し、[Authorizations] をクリックすることで保守されます。
• サービス 。個別のサービス レベルの承認では、サービスに対する承認構造が設定されます。サービスレベルの承認は、選択したサービスの [Authorizations] タブで保守されます。
承認および確認に対する名前空間の使用法
名前空間は、承認または確認定義の次のコンポーネントで使用できます。
• Subject：名前空間を使用して、タスク名にフォーム データを含めることができます
• Assign to：承認または確認を、式から割り当てることができます。
• Condition：承認または確認タスクを、条件に応じて実行できます
承認または確認の詳細を指定するサブタブは、次の図のようになります。
Subject
承認または確認タスクの件名は、名前空間を使用して要求データを反映したものに設定でき、件名がカスタマーの注文に応じたものになります。[Subject] フィールドに名前空間を含めるだけでできます。
最もよく使用される名前空間は、現在の確認または承認が適用されるサービスの名前です。通常は、次のように他の説明テキストと結合されます。
名前空間 #Name# はサービス名の短縮形として使用できます。
組織単位確認または承認、または財務承認に使用できるのは、サービスの特定の属性を参照し、サービス フォームのコンテンツでは ない 名前空間だけです。たとえば、カスタマーの名を参照する名前空間を使用する場合を考えます。
サービス グループ確認および承認では、#Service.Data# 名前空間が使用されることがあります。そうした確認または承認はサービスごとに適用されるため、サービス（フォーム）データを使用できます。財務承認および組織単位確認/承認は要求全体に適用され、複数のサービス（要求エントリ）が含まれていることがあるため、サービスごとのサービス データは使用できません。
式からの代入
• Organization Designer で定義された 役職 を現在果たしている個人。
多くの場合、事前定義された地位、個人、またはキューへのタスクの代入は、必ずしも可能ではありません。たとえば、要求者の場所に応じて、同じサービスが異なるキューで処理されることがあります。このような場合は、入力された要求データに基づいてタスクをルーティングする必要があり、そうしない場合は注文時に指定する必要があります。
ステップ 1 [Assign] ドロップダウン メニューで [From an expression] を選択します。
ステップ 2 [Assign to] フィールドに、必要な式を入力します。
提供計画とタスク
提供計画は、[Service Designer] > [Services] の [Plan] タブで設定します。
各タスクは、タスクのリストからタスクを選択し（または、[New] ボタンをクリックして新しいタスクを作成し）、そのタスクに関連するサブタブに入力することで設定します。
提供タスクでの名前空間の使用法
サービスの提供計画とコンポーネント タスクを設定すると、式と名前空間を複数の状況で使用できるようになります。
名前空間は、承認または確認定義の次のコンポーネントで使用できます。
• Project Manager：名前空間式から割り当てることができます。
• Subject for Monitor Plan：名前空間とリテラル テキストを含められます。
• Task name：名前空間とリテラル テキストを含められます。
• Participants：実行者や上司を、名前空間式から割り当てることができます。
• Condition：タスクが実行されるのは、指定された条件が満たされた場合だけです。条件では名前空間を使用できます。
提供計画の Project Manager
Project Manager は、個人、キュー、または式から割り当てられます。この式では、Organization Designer 内の個人を識別する任意の割り当てタイプを使用できます。
モニタリング タスクの件名
通常、モニタリング タスクの件名には #Name# 名前空間が含まれ、モニタ対象のサービスの名前が参照されます。
実行者（個人またはキュー）を参照する名前空間は使用できません。
サービス フォームのコンテンツを参照する名前空間は使用できますが、次の「提供タスク名」に示すように副作用が発生することがあります。
提供タスク名
通常、提供タスク名には、#Name# 名前空間を使用してサービス名が含まれます。サービス データ（#Service.Data....#）も使用できます。すべてのタスクはフォームの送信時に作成されるため、指定されたフィールドの値は注文時に入力されている必要があります。
（注） レポート時にはタスク名でタスクをグループ化できなくなっていることがあるため、タスク名にフォーム データを使用するのはよい方法ではありません。また、Service Manager クエリーで「contains」を使用して、タスク名の残りの部分を取得する必要があるため、パフォーマンスが低下することがあります。
タスクへのロール（実行者と上司）の割り当て
承認と同様、提供計画のタスクに割り当てられるサービス チームまたは個人は、カスタマーの場所など各要求のデータによって異なります。可能性のあるシナリオごとに異なるフォームやワークフローを作成しなくても、式を使用するとインテリジェントにタスクをルーティングできます。
実行者および上司ロールを含む、動的にルーティング可能な計画タスクは、各タスクの [Participants] タブにあります。
式から割り当てるには、[Assign:] ドロップダウンでそのオプションを選択し、[Assign to:] フィールドの横にある省略記号をクリックします。[Edit Expression] ウィンドウが表示され、式を入力および検証できます。
条件付き文
条件付き文では、条件に基づいてタスクを起動またはスキップでき、承認、確認、および提供計画のさまざまなタイミングで評価されるよう設定できます。
条件付き承認タスクおよび確認タスク
承認と確認は、特定の条件が存在する場合だけ必要になることがあります。たとえば、単価が指定されたしきい値を超えた場合だけ、承認が必要になります。条件付き承認または確認タスクを定義するには、次の手順に従います。
ステップ 1 設定する承認または確認をクリックします。[Review/Authorization Details] ウィンドウが表示されます（図 6-5 を参照）。
ステップ 2 その承認または確認タスクを実行すべき条件を入力します。
ステップ 3 [Validate...] ボタンをクリックし、条件を検証します。
ステップ 4 [Validate] ウィンドウが表示されます。「unexpected token」というメッセージが表示された場合は、使用する名前空間がこのコンテキストでは有効でないか、英数字リテラルが引用符で囲まれていない可能性があります。
ステップ 5 [OK] をクリックして [Validate] ウィンドウを終了します。
ステップ 6 [ Update] をクリックし、確認/承認の詳細を保存します。
検証では、ディクショナリ フィールド（Data. DictionaryName.FieldName ）を除いて、指定した名前空間が現在の範囲（確認、承認、またはタスクの特定のレベル）で有効であるかをチェックします。確認または承認は、それが統合されるサービスから独立して、サイトレベルまたは組織レベルで定義されることがあるため、これは非常に合理的です。ただし、指定した名前空間（たとえば、Data.EUIT_ACCESS.Access_Type）が存在しない場合、ランタイム エラーが生じる場合があります。
条件付き提供計画タスク
承認および確認タスクと同様、サービス提供時の計画タスクも条件付きにできます。
条件の評価
条件の入力後は、その文をいつ評価するかを決定する必要があります。条件付きの各タスク（承認、確認、または提供）は、つぎのいずれかで評価できます
承認/提供段階の開始時に条件を評価
設計者が、指定したタスクで [Evaluate condition when delivery phase starts (if condition evaluates to "false", times will be computed as zero)] オプションを選択すると、その 段階 の開始時に条件文が評価されます。「段階」とは、要求を処理するために定義されたシステムの任意のタイミングに対応しています。承認または確認にはそれぞれ固有のタイミングがあり、すべての提供タスクはサービス提供時に実行されます。
承認タスクは常に 1 つずつ実行されます。たとえば、field= "somevalue" で別の条件が field<> "somevalue" のように、1 つのタスクに 1 つの条件を配置できます。このように、常に承認タスクが 1 つ実行され、[when authorization phase starts] を選択すると、プロセス ビューには承認タスクが 1 つだけ表示されます。[when task becomes active] を選択すると両方のタスクが表示されますが、1 つはスキップされます。
[if conditions evaluate to "false", times will be computed as zero] 文は、Service Portal が段階の開始時に条件を評価することを表しています。これらの条件が満たされなかった場合は、対応するタスクが実行されず、サービスの [Due Date] はこれらのタスクの実行期間を含まずに計算されます。
アクティビティがアクティブ時に条件を評価
一方、設計者が [Evaluate condition when activity becomes active (times will not be affected, scheduling will be done by using these efforts)] オプションを選択すると、タスクの開始時に条件文が評価されます。
Service Portal は、各タスクの開始時に条件を評価します。条件が満たされなかった場合は、対応するタスクが実行されません。このオプションが設定されたすべてのタスクの実行期間は、送信時の期日の計算に使用されます。
計画進行時の式の再評価
式の再評価機能は、複数の承認が存在する設計で役立ちます。承認タスクを実行する個人がサービス フォームに情報を入力でき、 その後の 承認タスクの実行者の割り当てに使用する式の再評価に、その情報を使用できます。このオプションをオンにしなかった場合は、承認タスクの式で使用されるすべての情報が、注文時に指定されている必要があります。
この機能では、承認または確認タスクをユーザ（個人またはキュー）に動的に割り当てることができ、承認または確認時にタスクのタイトルを動的に調整できます。承認または確認がアクティブになると、式が評価されて、タスクが正しく割り当てられます。この機能を利用できるのは承認および確認タスクのみで、提供タスクでは利用できません。
段階の開始とタスクの開始
次の図は、段階の開始とタスクの開始の違いをわかりやすく示したものです。
|
|
|
|
|
条件文の構文
条件文には、算術演算子と関係（論理）演算子を含めることができます。
使用可能な論理演算子のタイプは、テストされるフィールドの HTML 表現によって異なります。ほとんどのフィールドには、1 つの値だけを割り当て可能な s（入力要素）があります。そのようなものとしては、テキスト、テキスト領域、オプション ボタン、単一選択（ドロップダウン）リスト、オプション ボタンなどがあります。次の論理演算子は、そうしたフィールドに適用される条件文で使用できます。
|
|
|
2 つ以上の文の論理 OR を 実行。すべての文が True の場合は結果が True となり、それ以外、つまりいずれかの文が False の場合は False となります。 |
|
2 つ以上の文の論理 AND を 実行。いずれかの文が True の場合は結果が True となり、それ以外の場合は False となります。 |
括弧を使用すると、演算子の優先順序を変更したり、条件を明確化することができます。
INCLUDES 演算子を適用できるのは、複数の値を格納可能なフィールドだけです。そのようなものとしては、複数選択（ドロップダウン ボックス）やチェックボックスがあります。次の論理演算子は、そうしたフィールドに適用される条件文で使用できます。
• 条件に含める英数値は二重引用符（""）で囲む必要があります。
• 名前空間名では大文字と小文字が区別されません。このマニュアルでは、推奨標準として Title 形式（すべての単語の先頭文字が大文字）で示してあります。
• すべての英数比較では、大文字と小文字が区別されます。たとえば、次の条件があるとします。
Data.MoveIndividual.FirstName="Matt"
これが True となるのは、MoveIndividual ディクショナリの FirstName フィールドの値が「Matt」で、先頭文字が大文字、それ以外の文字が小文字の場合だけです。
• すべてのブール名前空間（名前が「Is」で始まるもの）は、その元となるデータベースに応じて異なる値を持ちます。SQLServer では、ブール値が True または False となります。Oracle では、その値が 1（True）および 0（False）となります。
• 数値比較用の小なりおよび大なり演算子は、ディクショナリ フィールドでサポートされません。比較時にテキストとして扱われます。たとえば、条件 Service.Data.VM.MemoryGB > 4 は、ディクショナリ フィールド VM.MemoryGB の値が 16 の場合に False と評価されます。
• テキスト文字列比較では、マルチバイト文字がサポートされません。
• リテラルに含められたアンパサンド（「&」）は「&」と符号化する必要があります。たとえば、「two & three」という値は式の中で「two & three」となります。
ヒントとテクニック
自動的にスキップされるタスクを指定する条件文では、常に False と評価される条件（「1=2」など）を使用します。
• いずれかのタスクが完了してなくても、サービスが「自動完了」する必要がある場合。スキップされるタスクには、提供計画の最後でマークが付けられ、要求には完了のマークが付けられます。
• タスクが完了しなくても電子メールを送信する必要がある場合、または次のように、あるタイミングで複数の電子メールが必要な場合。
– 親タスクを作成する。電子メール タブで、完了時に送信する電子メールを選択します（アクティビティがアクティブになったときに送信されるものも設定することがあります）。
名前空間の参考資料
ここでは、すべての名前空間と、それぞれを使用可能なコンテキストについて説明します。
名前空間オブジェクトとその関係
次の図は、名前空間内のノードと、それらのノード間の関係を示しています。ノードのタイプによって、それ自体のプロパティだけでなく、そのアクセス先となるサブコンテキスト（他のノード）も決まります。
この図でラベルの付いたボックスは、名前空間ノードのタイプを表しています。ラベル付きの矢印は、あるノードのプロパティを別のノードからアクセス可能な、名前空間要素を表しています。この図は、名前空間をナビゲートして Service Portal のデータにアクセスする必要のある、サービス設計者および管理者のガイドとして利用できます。たとえば、Process ノードから「Customer」というラベルの矢印をたどると、「Customer」要素によって Process ノードは Person ノードのプロパティにアクセスできることがわかります。そのため、たとえば提供計画のタスク用の条件文でカスタマーのログイン名にアクセスするには、その条件で次の名前空間を参照します。
提供計画の電子メールから同じ名前空間にアクセスするには、名前空間参照が次のようになります。
ノードの関係は双方向型ではありません。Process ノードが Person ノードのプロパティにアクセスできるからといって、Process ノードのプロパティを Person ノードからも利用できるわけではありません。
フォーマッティングされた電子メールまたは条件文で Service Portal のデータを使用する、サービス設計者または管理者から見て、ノード間のパスには複数の「エントリ ポイント」があります。
• 要求エントリ（サービス）に関連付けられたアクティビティ。提供計画タスク、サービス グループ承認、サービス グループ確認、そうしたアクティビティで生成された電子メールなど。
• 要求に関連付けられたアクティビティ。部門承認、部門確認、財務承認など。
このようなエントリ ポイントによって、サービス設計者または管理者がアクティビティから送信する電子メールを設定するとき、または条件付き実行文を定義するときに適用される、名前空間コンテキストが決まります。これらは、ノード間のパスをナビゲートするための開始点と考えることができます。名前空間を入力すると、そのアクティビティからどのノードを利用できるのか、および最終的にはどのプロパティとデータ値を利用できるのかが決まります。
電子メール名前空間の要素
OU ベースの承認と確認
組織レベルの承認と確認では、次の電子メールがトリガーされます。
このような電子メールのエントリ ポイントでは、次に示す名前空間要素がサポートされています。
タスクおよびサービス グループ承認/確認
提供計画の一部となっているタスク、およびサービス グループ承認と確認では、次の電子メールがトリガーされます。
このような電子メールのエントリ ポイントでは、次に示す名前空間要素がサポートされています。
タスクを作成したサービス実行者を参照する
一般的に、サービス データ名前空間にはフォーマットがあります
条件付き名前空間要素
条件内の変数へのアクセスでは # を使用しません。条件の左辺に #、"、&、+、- などの文字があると、データベースで問題が発生することがあります。
OU ベースの承認と確認
組織レベルの承認と確認は、条件付きで実行されることがあります。
このような条件付きエントリ ポイントは、次の名前空間をサポートしています。
タスクおよびサービス グループ承認/確認
サービス グループ承認と確認、および提供計画の一部となっているタスクでは、タスクまたは確認を実行するかどうかを決定する条件を使用できます。
このような条件付きエントリ ポイントは、次の名前空間をサポートしています。
Organizational Unit-Based 名前空間
組織単位に関する名前空間では情報を入手できます。組織単位は多くのコンテキストで出現し、次の名前空間エンティティ タイプで示されます。
|
|
|
|
ClientOU のコンテキストの場合の組織単位要素タイプ（OrgElementType）を次に示します。
Person-Based 名前空間
Customer、Initiator、Alternate、および Performer 名前空間要素は、Organization Designer に格納された個人に関する情報を提示します。そのため、すべてのエントリ タイプは同じ変数をサポートし、エントリ タイプを表す要素（「Customer」、「Initiator」、「Alternate」、「Person」）のみが変化します。
個人ベース名前空間のリストを、次に示します。名前空間は、すべての基本個人属性および拡張個人属性で使用できます。有効な名前空間変数を構成するには、これらを名前空間名の最後の部分として使用し、最初の部分はエンティティ タイプとしてください。他と同様、電子メールで使用する場合は、名前空間をハッシュ マーク（#）で囲む必要があります。
|
|
|
一般的に、現在の要求が発注された個人。タスクベースの電子メールおよびエスカレーションでは、タスク実行者の上司。Ad-Hoc タスクでは、その Ad-Hoc タスクを作成したタスク実行者。 |
|
Person タイプの名前空間ノードの要素を次に示します。要素が指定されなかった場合、式はデータベース内のその個人の固有識別子を返します。
Customer 名前空間
エスカレーションを含む提供タスクでは、カスタマーとはタスク スーパーバイザです。Ad-Hoc タスクでは、カスタマーとはその Ad-Hoc タスクを開始したタスク実行者です。その他すべてのタスクおよび要求では、カスタマーとはサービスが要求された個人です。Customer 名前空間では、次のようなカスタマー情報にアクセスできます。
• 個人のプロファイルで定義され、[Organization Designer] > [People] でアクセス可能なカスタマー（個人）情報
• カスタマーの上司に対して定義されたすべての個人/プロファイル情報
• カスタマーのホーム OU のマネージャに定義されたすべての個人/プロファイル情報
次に示す名前空間は、電子メールで使用する場合にハッシュ マーク（#）で囲む必要がありますが、式で使用する場合はハッシュ マークなしで入力します。PersonType 名前空間は、前述の「 Organizational Unit-Based 名前空間」の項に示してあります。
組織単位に関する名前空間では情報を入手できます。組織単位は多くのコンテキストで出現し、次の名前空間エンティティ タイプで示されます。
|
|
|
|
ClientOU のコンテキストの場合の組織単位要素タイプ（OrgElementType）を次に示します。
Performer 名前空間
実行者とは、サービスの提供計画にあるタスクの実行を担当する個人です。Performer 名前空間は、現在のタスクがないコンテキストでは使用できません。たとえば、組織単位確認および承認の電子メール、および財務承認などがあります。
Performer 名前空間では、次のような実行者情報にアクセスできます。
• 個人のプロファイルで定義され、[Organization Designer] > [People] でアクセス可能な実行者（個人）情報
• 実行者の上司に対して定義されたすべての個人/プロファイル情報
• 実行者のホーム OU のマネージャに定義されたすべての個人/プロファイル情報
次に示す名前空間は、電子メールで使用する場合にハッシュ マーク（#）で囲む必要がありますが、式で使用する場合はハッシュ マークなしで入力します。
PeformerQueue 名前空間
Performer Queue 名前空間では、確認、承認、またはタスクが割り当てられたキューに関する情報が提供されます。Person-Based 名前空間要素およびプロパティのサブセットには意味があります。これらは、Organization Designer でクエリーを保守するため、ユーザ インターフェイスに提示されます。
Initiator 名前空間
Initiator 名前空間では、次のような発信者情報にアクセスできます。
• 個人のプロファイルで定義され、[Organization Designer] > [People] でアクセス可能な発信者（個人）情報
• 発信者の上司に対して定義されたすべての個人/プロファイル情報
• 発信者のホーム OU のマネージャに定義されたすべての個人/プロファイル情報
次に示す名前空間は、電子メールで使用する場合にハッシュ マーク（#）で囲む必要がありますが、式で使用する場合はハッシュ マークなしで入力します。
役職
役職では、その地位に割り当てられた個人の個人情報にアクセスできます。この情報としては、デフォルトの役職に対するものと、特定の実装に対して設定されたものの、両方の情報にアクセスできます。
役職は、モジュール選択の [Organization Designer] > [Functional Positions] で定義されます。役職はそれぞれ特定のエンティティに割り当てられます。そのエンティティとしては、サービス、サービス グループ、組織単位があります。
地位の定義後、組織単位の [Positions] ページまたは、サービスあるいはサービス グループの [General] タブで個人をその地位に割り当てます。たとえば、次のような使用法があります。
Requisition.Customer.HomeOU.BudgetManager.Email を使用して、カスタマーのホーム組織単位の予算マネージャの電子メール アドレスにアクセスする。
Performer.HomeOU.ParentOU.Manager.FirstName を使用して、タスク実行者のホーム組織単位の親組織単位のマネージャの名にアクセスする。
デフォルトの役職には、「Budget Manager」のように地位名の間に空白が入っているものがあります。役職を名前空間参照で使用する場合は、この空白を省略します。
ユーザ指定の役職には、空白が含まれていないものがあります。名前空間参照は、次の例のように役職の前にキーワード「Position」を付ける必要があります。
すべての役職では、前述の Person テーブルで定義されたすべての変数にアクセスできます。個人変数が含まれていない場合、式では個人のデータベース ID が返されます。
要求またはサービスのコンテキストでアクセス可能なすべての個人ロールから、ホーム OU、親 OU、またはクライアント OU の役職に関する情報にアクセスできます。サービスおよびサービス グループの役職に関する情報は、サービス コンテキストでのみ入手できます。
このような式を使用して電子メールとタスク名に動的データを格納する場合は、次のように式の先頭と末尾にポンド区切り記号（「#」）を追加する必要があります。
Lightweight 名前空間
アクティブ フォーム ルールには、使用または評価するフィールド値に動的にアクセスするため、名前空間に相当するものが必要です。たとえば、ユーザが前のフィールドで「Other」と入力した場合、サービスは追加のディクショナリまたはフィールドを表示する必要があります。また、サービス提供の有効な場所を表示するためのドロップダウン リストを作成する条件として、現在のカスタマー組織の使用が必要になることがあります。あるいは、カスタマーおよび発信者データに対するデフォルト値を提供する必要があります。
Lightweight 名前空間はこれらの機能を提供します。これらの機能は、ルール内では、フォームにアクセス可能な情報だけ（サービスの提供計画やタスク実行者に関する詳細などではありません）を使用できるため「軽量」です。
個人ベースのディクショナリが含まれたすべてのフォームでは、選択された個人のプロファイルに格納されたフィールドの対応する値に基づき、Lightweight 名前空間を使用してフォーム フィールドに値を提供します。これには、Customer-Initiator フォームとユーザ定義のすべてのフォームの両方が含まれます。Lightweight 名前空間の形式は #Customer. FieldName # または #Initiator. FieldName # です。
（注） Lightweight 名前空間に対するグリッド ディクショナリ フィールドの使用はサポートされていません。
名前空間は、フィールドのデフォルト値として自動的に入力されます。必要に応じ、初期割り当てを置換できます。
カスタマーまたは発信者データを参照する Lightweight 名前空間は、個人ベースではないディクショナリのフィールドのデフォルト値としても使用できます。この場合、ディクショナリ フィールドから該当する個人属性へのマッピングは、当然ながらサービス設計者が行います。この機能では、個人ベースのデータとその他のデータの両方が格納されたディクショナリを定義できます。
Customer-Based 名前空間
カスタマー情報が予約されたディクショナリに使用する Customer-Based 名前空間を、以下にまとめます。
|
|
|
|
Initiator-Based 名前空間
発信者情報が予約されたディクショナリに使用する Initiator-Based 名前空間を、以下にまとめます。
|
|
|
|
Process 名前空間
Process 名前空間は電子メール内だけで使用できます。条件内で使用することはできません。Process オブジェクトには、カスタマーおよび要求に関するすべての名前空間が含まれます。Process は現在のタスクを参照します。
Requisition 名前空間
Message 名前空間
Message 名前空間は、Service Link タスクが失敗した結果生成された電子メール内だけで使用できます。その他の電子メールまたは条件内で使用することはできません。Message 要素は Service Link 失敗の診断に役立つことがあり、診断のためにログ ファイルを調べる必要がなくなります。
フィードバック