Cisco Prime Service Catalog 11.0 設計者ガイド

名前空間 #Site.URL# は、Service Catalog にアクセスするための URL を指定します。 この URL パスには、実行する特定のモジュール、およびそのモジュールに渡すパラメータ（とそれに続く疑問符）が含まれることがあります。 上記の例では、ユーザを My Services モジュール、Service Manager モジュール、またはそれらのモジュールで利用可能な機能に移動するハイパーリンクが、電子メール本文に生成されます。

My Services または Service Manager の任意のページに単純にリンクする、名前空間参照を作成することが可能です。 正しい URL の判別で重要なことは、サイト管理者に一時的にサイトのデバッグを有効にしてもらい（ただし『Cisco Prime Service Catalog Administration and Operations Guide』の警告をよくお読みください）、目的のページに移動したときに表示される URL を確認することです。 電子メールにその URL を埋め込む場合、アンパサンド（&）など、文字の符号化表現を使用する必要があります。

名前空間参照のその他の例を次に示します。

インストール プロセスの一環として、管理者は Service Catalog の URL を指定します。 この URL は設定ファイル be.properties に保存されます。 入力例を次に示します。

!-------------------------------------------------------------------
!Define the URL for the application
!This is used in emails for constructing the various urls
!-------------------------------------------------------------------
ObjectCache.Application.URL=http://appsrv01.celosis.com/RequestCenter/

ObjectCache.Application.URL のエントリは名前空間 #Site.URL# and #URL# の値です。 通常、URL は末尾が「/RequestCenter/」になりますが、要求を /RequestCenter/ に自動的に転送するようアプリケーション サーバを設定することが可能なため、プロパティ ファイルにはパスのこの部分がない場合があります。

この場合、単語 /RequestCenter/ は、#Site.URL#/RequestCenter/myservices/myservice.do? などのように #Site.URL# の後に追加したり、 #URL#/RequestCenter/myservices/myservice.do? などのように #URL# に追加する必要があります。 これは、名前空間のリンクが正しい URL に確実に解決されるようにするためです。

/RequestCenter 参照を挿入する必要があるかどうかを判断するには、be.properties ファイルを参照します（またはアプリケーション サーバ管理者にその内容を問い合わせます）。 または、次の代替方法があります。

• 電子メールに #Site.URL# または #URL# 自体を入力し、たとえばタスクが開始されたときに電子メールを送信します。
• 電子メールを受信したとき、URL が http://www.mycompany.com または http://www.mycompany.com/RequestCenter/ に解決されるかどうかを確認します。
• 解決された URL に /RequestCenter/ が含まれていない場合、#Site.URL# または #URL# の後に /RequestCenter/ をそれぞれ追加します。

名前空間ノード #Message# を使用できるのは、Service Link で発信メッセージの配信に失敗した結果生成された電子メール メッセージの本文内だけです。 使用するテンプレートは、Service Link エージェント定義に「失敗した電子メール（Failed Email）」として指定されます。 このノードの要素は、管理者が失敗の原因を診断するときに役立ちます。

承認または確認タスクの件名は名前空間を使用して要求データを反映するように構成して、カスタマーのオーダーに固有の件名にすることができます。 これには、[件名（Subject）] フィールドに名前空間を含めるだけです。

最も頻繁に使用される名前空間は、現在の確認/承認が適用されるサービスの名前です。 これは通常、他の説明文に連結して使われます。次に例を示します。

Group Review for #Name#

名前空間 #Name# は、サービス名の短縮形として使用できます。

サービス フォームの内容ではなく、サービスの特定の属性を参照する名前空間だけが組織単位の確認/承認および財務承認に使用できます。 たとえば、名前空間を使用してカスタマーの名を参照する場合は、次のようになります。

#Requisition.Customer.FirstName# -- CORRECT
#Service.Data.Customer_Information.First_Name# -- INCORRECT

サービス グループの確認および承認には #Service.Data# 名前空間を使用できます。 この確認/承認は個々のサービスに適用されるため、サービス（フォーム）データを使用できます。 財務承認および組織単位の確認/承認は、要求全体に適用されます。これには複数のサービス（要求エントリ）が含まれることがあるため、個々のサービスのサービス データは使用できません。

プロジェクト マネージャは、担当者、キュー、または式から割り当てることができます。 この式では、Organization Designer 内の個人を識別する任意の割り当てタイプを使用できます。

次に、例を示します。

LOGINNAME=#Service.Data.Project.ManagerLogin#
ID=#Customer.Supervisor.ID#

監視タスクの件名には通常 #Name# 名前空間を含めて、監視されるサービスの名前を参照します。

Monitor Plan for #Name#

実行者（担当者またはキュー）を参照する名前空間は使用できません。

サービス フォームの内容を参照する名前空間は使用できますが、次の「提供タスク名」で説明されているように悪影響が生じる場合があります。

提供タスク名には通常、#Name# 名前空間を使用してサービス名を含めます。 サービス データ（#Service.Data....#）も使用できます。 すべてのタスクはフォームが送信された時に作成されるため、指定されたフィールドの値は発注時点で入力されている必要があります。

（注）	レポート環境ではタスク名でタスクをグループ化できなくなっていることがあるため、タスク名にフォーム データを使用するのはよい方法ではありません。 また、Service Manager クエリで「次を含む（contains）」演算子を使用して、タスク名の残りの部分を取得する必要があるため、パフォーマンスが低下することがあります。

承認の場合と同様に、提供計画のタスクに割り当てられるサービス チームまたは担当者は、カスタマーのロケーションなどの各要求に関するデータによって異なります。 シナリオごとに異なるフォームやワークフローを作成するのではなく、式を使用してタスクをインテリジェントにルーティングできます。

動的にルーティングできる計画タスクには、各タスクの [参加者（Participants）] タグにある実行者とスーパーバイザのロールが含まれます。

図 3. 提供計画タスクの参加者

「式を使って」割り当てるには、[割り当て（Assign）] ドロップダウンリストからそのオプションを選択し、[割り当て先（Assign to）] フィールドの横にある省略記号（...）をクリックします。 [式の編集（Edit Expression）] ウィンドウが開き、ここで式を入力し検証できます。

図 4. 確認の詳細ウィンドウ

[検証（Validate）] 機能により、指定された名前空間が、ディクショナリ フィールド（Data.DictionaryName.FieldName）を除いて、現在のスコープ（特定のレベルの確認/承認またはタスク）で有効であるかを検証できます。 これは、確認/承認が、統合されるサービスに関係なく、サイトレベルまたは組織レベルで定義されても、適正を確保できます。 ただし、指定された名前空間（たとえば、Data.EUIT_ACCESS.Access_Type）が存在しない場合、ランタイム エラーが発生することがあります。

検証では、正しい関係演算子および算術演算子が使用されていることも確認されます。

承認および確認タスクと同様に、サービス提供時点の計画タスクも条件付きにすることができます。

図 5. タスク定義の [全般（General）] タブ

条件を入力したら、ステートメントが評価される時期を決定する必要があります。 条件付きの各タスク（許可、確認、または提供）は、次のいずれかで評価できます。

• フェーズ（承認または提供時点）の開始時、または
• アクティビティがアクティブになったとき

条件文には、算術演算子および関係（論理）演算子を含めることができます。

使用可能な論理演算子のタイプは、テスト対象のフィールドの HTML 表現によって異なります。 ほとんどのフィールドには、1 つの値だけを割り当て可能な（入力要素）があります。そのようなものとしては、テキスト、テキスト領域、オプション ボタン、単一選択（ドロップダウン）リスト、オプション ボタンなどがあります。 このようなフィールドに適用される条件文には、次の論理演算子を使用できます。

条件の演算子の標準的な演算順序は次のとおりです。

-  (negative)
*  (multiplication), /  (division)
+  (addition),   -  (subtraction)
<, >, >=, <=, <> (not equal), =
NOT
OR
AND

カッコを使用して演算子の優先順位を変更したり、条件を明確にすることができます。

次に、例を示します。

ActivityID >= 50
Customer.FirstName = "Ann"
Requisition.ActualCost >= 2000
Service.Quantity * Service.PricePerUnit <= 1000
Data.Approver.Custom_2 = "VP" OR Data.Approver.Custom_2 = “Director”

INCLUDES 演算子は、複数の値を入力できるフィールドに適用できます。 これには、複数選択（ドロップダウン ボックス）およびチェック ボックスが含まれます。 このようなフィールドに適用される条件文には、次の論理演算子を使用できます。

次に、例を示します。

Data.EUIT_ACCESS.AccessType INCLUDES “DSL” AND NOT
Data.EUIT_ACCESS.AccessType INCLUDES “Dial-Up”

（注）	名前空間を囲む際に「#」記号は使用しません。

• 条件に含める英数値は二重引用符（""）で囲む必要があります。
• 名前空間名では、大文字と小文字が区別されません。 推奨される基準は先頭文字の大文字の指定（すべての単語の最初の文字を大文字にする）を使用することです。
• すべての英数字比較では、大文字と小文字が区別されます。 たとえば、条件「Data.MoveIndividual.FirstName=”Matt」 は、MoveIndividual ディクショナリの [FirstName] フィールドの値が「Matt」（最初の文字が大文字で残りが小文字）である場合にのみ true となります。
• すべてのブール名前空間（名前が「Is」で始まるもの）は、その元となるデータベースに応じて異なる値を持ちます。 SQLServer では、ブール値は true または false です。 Oracle では、対応する値は 1（true）および 0（false）です。
• 数値比較用の小なりおよび大なり演算子は、ディクショナリ フィールドでサポートされません。 比較時にテキストとして扱われます。 たとえば、条件「Service.Data.VM.MemoryGB > 4」は、ディクショナリ フィールド VM.MemoryGB の値が 16 の場合に false と評価されます。
• テキスト文字列比較では、マルチバイト文字がサポートされません。
• リテラルに含まれるアンパサンド（「&」）は「&」として符号化する必要があります。 たとえば、値「2 & 3」は式では「2 & 3」になります。
• 次の演算子はブール値フィールドでサポートされていません。
  • が次より大きい（is greater than）
  • が次より小さい（is less than）
  • 大文字と小文字を区別しないと等しい（is equal to ignore case）
  • が次の文字列で始まる（begins with）
  • が次の文字列で終わる（ends with）
  • が次の文字列を含む（contains）
  • 含まない（does not contain）

条件文で常に false と評価する条件（たとえば、「1=2」）を使用して、自動的に省略されるタスクを指定します。

この場合の最も一般的な使用例は次のとおりです。

• いずれかのタスクが完了してなくても、サービスが「自動完了」する必要がある場合。 省略されたタスクは提供計画の終了を示し、要求は完了としてマークされます。
• 次のように、タスクを完了せずに電子メールを送信する必要がある場合、または特定の時点で複数の電子メールが必要な場合。
  • 親タスクを作成する。 [電子メール（email）] タブで、完了時に送信する電子メールを選択します（アクティビティがアクティブになったときに送信される電子メールを設定することもできます）。
  • 1=2 の条件で子タスクを作成する。 アクティビティがアクティブになったときに評価する条件を設定します。

次の図に、名前空間のノードおよびノード間の関係を示します。 ノードのタイプによって、固有のプロパティだけでなく、アクセスを提供するサブコンテキスト（他のノード）も決まります。

この図のラベル付きボックスは、名前空間ノードのタイプを表します。 ラベル付き矢印は、1 つのノードのプロパティに別のノードからアクセスできる名前空間要素を示します。 この図は、名前空間をナビゲートして Service Catalog のデータにアクセスする必要のある、サービス設計者および管理者のガイドとして利用できます。 たとえば、プロセス ノードから「Customer」というラベルが付いた矢印を追跡すると、「Customer」要素がプロセス ノードに個人ノードのプロパティへのアクセスを提供していることがわかります。 したがって、たとえば提供計画のタスク用の条件文にあるカスタマーのログイン名にアクセスするには、条件は次の名前空間を参照します。

Requisition.Customer.LoginName

提供計画の電子メールで同じ名前空間にアクセスする場合、名前空間参照は次のようになります。

#Service.Requisition.Customer.LoginName#

ノード関係は双方向ではありません。 プロセス ノードが個人ノードのプロパティにアクセスできることは、個人ノードがプロセス ノードのプロパティにアクセスできることを意味しません。

フォーマッティングされた電子メールまたは条件文で Service Catalog のデータを使用する、サービス設計者または管理者から見て、ノード間のパスには複数の「エントリ ポイント」があります。

• 要求エントリ（サービス）に関連付けられたアクティビティ。提供計画タスク、サービス グループ承認、サービス グループ確認、そうしたアクティビティで生成された電子メールなど。
• 要求に関連付けられたアクティビティ。部門承認、部門確認、財務承認など。

このようなエントリ ポイントによって、サービス設計者または管理者がアクティビティから送信される電子メールを設定するとき、または条件付き実行文を定義するときに適用される、名前空間コンテキストが決まります。 これらはノード間のパス内を移動するための開始点と考えてください。 名前空間を入力する場所によって、その特定のアクティビティから使用できるノード、および最終的には、プロパティとデータ値が決まります。

図 7. 名前空間オブジェクトとその関係

組織レベルでの承認および確認によって、電子メールを送信できます。

• 組織単位の承認
• 組織単位の確認
• ファイナンシャル承認

これらの電子メール エントリ ポイントは、次に示す名前空間要素をサポートします。

#ActivityID#
#Priority# - priority assigned to the task: 1=high, 2=normal, 3=low
#DueOn#
#Subject# - the name of the task
#Waiting#
#ScheduledStart#
#StartedOn#
#CompletedOn#
#ExpectedDuration# - typical task duration, in hours
#ExpectedDurationUnits# - units in which task duration is displayed
#ActualDuration# - actual task duration, in hours
#CurrentDate#
#StateName# - the status of the task
#URL#
#Customer.*# - where * denotes any Customer element
#Performer.*# - where * denotes any Performer element
#PerformerQueue.*# where * denotes any PerformerQueue element
#Process.*# -- where * denotes any Process (task) element
#Requisition.*# - where * denotes any Requisition element

提供計画に含まれるタスク、およびサービス グループの承認および確認によって、電子メールを送信できます。

• サービス グループの承認
• サービス グループの確認
• 計画タスク
• 遅延タスク
• アドホック タスク
• 失敗した Service Link タスク

これらの電子メール エントリ ポイントは、次に示す名前空間要素をサポートします。

#ActivityID#
#Priority#
#DueOn#
#Subject#
#Waiting#
#ScheduledStart#
#StartedOn#
#CompletedOn#
#ExpectedDuration#
#ActualDuration#
#Instructions# -- for Adhoc tasks only
#CurrentDate# -- the current date and time in GMT
#StateName# -- the current status (state) of the activity
#URL# -- the URL for directly accessing Task Details for this activity
#Customer.*# -- all Customer elements; for an adhoc task only, this   refers to the service performer who created the task
#Performer.*# -- all Performer elements
#PerformerQueue.*# -- all Queue elements
#Process.*# - all Process elements
#Service.ServiceID#
#Service.ProcessTrackingID#
#Service.Quantity#
#Service.PricePerUnit#
#Service.HasPrice# -- false (0) if the service has no price, 1 (true)otherwise
#Service.Bundled# -- true (1)if the service is a child service in a   bundle, false (0) otherwise
#Service.isBundle# -- true (1) if the service is itself a bundle, false  (0) otherwise
#Service.BundledServices# -- the number of child services bundled with  the current service
#Service.ServiceDefinition.Name#
#Service.ServiceDefinition.IsEntitlement#
#Service.ServiceDefinition.DescriptionURL#
#Service.ServiceDefinition.ExpectedDuration#
#Service.ServiceDefinition.FunctionalPosition.PersonTypeElement#
#Service.ServiceDefinition.ServiceGroup.Name#
#Service.ServiceDefinition.ServiceGroup.FunctionalPosition
.PersonElement#
#Service.RequisitionEntryID#
#Service.Requisition.URL#
#Service.Requisition.ProcessTrackingID#
#Service.Requisition.ExpectedDuration#
#Service.Requisition.StartedDate#
#Service.Requisition.ActualCost#
#Service.Requisition.ExpectedCost#
#Service.Requisition.RequisitionID# 
#Service.Requisition.Name# 
#Service.Requisition.Customer.*# --all Customer elements
#Service.Requisition.Initiator.*# -- all Initiator element
#Service.Requisition.ClientOU.*# -- all ClientOU elements
#Service.Data.DictionaryName.FieldName#

通常、サービス データの名前空間の書式は次のとおりです。

#Service.Data.DictionaryName.FieldName#

組織内レベルでの承認および確認は条件付きで実行できます。

• 組織単位の承認
• 組織単位の確認
• ファイナンシャル承認

これらの条件付きエントリ ポイントは、次の名前空間をサポートします。

Site.URL
Customer.*
Initiator.*
ClientOU.*

サービス グループの承認と確認、および提供計画に含まれるタスクでは、条件によりタスク/確認を実行するかどうかを決定できます。

• サービス グループの承認
• サービス グループの確認
• 計画タスク
• 遅延タスク

これらの条件付きエントリ ポイントは、次の名前空間をサポートします。

Requisition.* 
Data.DictionaryName.FieldName

エスカレーションを含む提供タスクでは、カスタマーはタスク スーパーバイザです。 アドホック タスクでは、カスタマーとはそのアドホック タスクを開始したタスク実行者です。 その他のすべてのタスクおよび要求の場合は、カスタマーはサービスが要求されている担当者です。 Customer 名前空間では、次のようなカスタマー情報にアクセスできます。

• 個人のプロファイルで定義され、[Organization Designer] > [ユーザ（People）] でアクセス可能なカスタマー（個人）情報
• カスタマーのスーパーバイザ用に定義されたすべての担当者/プロファイル情報
• カスタマーのホーム組織単位に関する情報
• カスタマーのホーム OU のマネージャ用に定義されたすべての担当者/プロファイル情報

次の名前空間は、電子メールに使用する場合はハッシュ記号（#）で囲む必要がありますが、式に使用する場合はハッシュ記号で囲まずに入力します。 個人タイプの名前空間の完全なリストをPerson-Based 名前空間に示します。

Customer 名前空間。

#Customer.PersonTypeElement#
#Customer.Supervisor.PersonTypeElement#
#Customer.HomeOU.Name#
#Customer.HomeOU.OrganizationalUnitID#
#Customer.HomeOU.OrganizationalUnitTypeID# -- the type of unit, where 1=service team, and 2=business unit
#Customer.HomeOU.CostCenterCode#
#Customer.HomeOU.Manager.PersonTypeElement#
#Customer.HomeOU.ParentOU.Name#
#Customer.HomeOU.ParentOU.OrganizationalUnitID#
#Customer.HomeOU.ParentOU.OrganizationalUnitTypeID# -- the type of unit, where 1=service team, and 2=business unit
#Customer.HomeOU.ParentOU.CostCenterCode#

実行者は、サービスの提供計画でタスクを実行する担当者です。 Performer 名前空間は、現在のタスクがないコンテキストでは使用できません。たとえば、組織単位確認および承認の電子メール、および財務承認などがあります。

Performer 名前空間では、次のような実行者情報にアクセスできます。

• 個人のプロファイルで定義され、Organization Designer > ユーザ（People）でアクセス可能な発信者（個人）情報
• 実行者のスーパーバイザ用に定義されたすべての担当者/プロファイル情報
• 実行者のホーム組織単位に関する情報
• 実行者のホーム OU のマネージャ用に定義されたすべての担当者/プロファイル情報

次の名前空間は、電子メールに使用する場合はハッシュ記号（#）で囲む必要がありますが、式に使用する場合はハッシュ記号で囲まずに入力します。 個人タイプの名前空間の完全なリストをPerson-Based 名前空間に示します。

#Performer.PersonTypeElement#
#Performer.Supervisor.PersonTypeElement#
#Performer.HomeOU.Name#
#Performer.HomeOU.OrganizationalUnitID#
#Performer.HomeOU.OrganizationalUnitTypeID#
#Performer.HomeOU.CostCenterCode#
#Performer.HomeOU.Manager.PersonTypeElement#

Performer Queue 名前空間は、確認、承認、またはタスクが割り当てられたキューに関する情報を提供します。 Person-Based 名前空間要素およびプロパティのサブセットには意味があります。これらは、Organization Designer でクエリを維持するため、ユーザ インターフェイスに提示されます。

#PerformerQueue.FirstName#
#PerformerQueue.LastName#
#PerformerQueue.TimeZoneID#
#PerformerQueue.Email#
#PerformerQueue.WorkPhone#
#PerformerQueue.HomePhone#
#PerformerQueue.Fax#
#PerformerQueue.Mobile#
#PerformerQueue.Pager#
#PerformerQueue.TimeZone#
#PerformerQueue.HomeOU.Name#
#PerformerQueue.HomeOU.OrganizationalUnitID#
#PerformerQueue.HomeOU.OrganizationalUnitTypeID#
#PerformerQueue.HomeOU.CostCenterCode#
#PerformerQueue.HomeOU.ParentOU.Name#
#PerformerQueue.HomeOU.ParentOU.OrganizationalUnitID#
#PerformerQueue.HomeOU.ParentOU.OrganizationalUnitTypeID#
#PerformerQueue.HomeOU.ParentOU.CostCenterCode#
#PerformerQueue.HomeOU.Manager.PersonTypeElement#

発信者とはサービスをオーダーする担当者です。

Initiator 名前空間では、次のような依頼者情報にアクセスできます。

• 個人のプロファイルで定義され、[Organization Designer] > [ユーザ（People）] でアクセス可能な発信者（個人）情報
• 発信者のスーパーバイザ用に定義されたすべての担当者/プロファイル情報
• 発信者のホーム組織単位に関する情報
• 発信者のホーム OU のマネージャ用に定義されたすべての担当者/プロファイル情報

次の名前空間は、電子メールに使用する場合はハッシュ記号（#）で囲む必要がありますが、式に使用する場合はハッシュ記号で囲まずに入力します。 個人タイプの名前空間の完全なリストをPerson-Based 名前空間に示します。

#Initiator.PersonTypeElement#
#Initiator.Supervisor.PersonTypeElement#
#Initiator.HomeOU.Name#
#Initiator.HomeOU.OrganizationalUnitID#
#Initiator.HomeOU.OrganizationalUnitTypeID#
#Initiator.HomeOU.CostCenterCode#
#Initiator.HomeOU.Manager.PersonTypeElement#
#Initiator.HomeOU.ParentOU.Name#
#Initiator.HomeOU.ParentOU.OrganizationalUnitID#
#Initiator.HomeOU.ParentOU.OrganizationalUnitTypeID#
#Initiator.HomeOU.ParentOU.CostCenterCode#

[役職（Functional positions）] を使用して、役職に割り当てられている個人の担当者情報にアクセスできます。 アクセスできるのは、デフォルトの役職と、特定の実装に対して設定された役職の両方の情報です。

役職は、モジュール選択の [Organization Designer] > [役職（Functional Positions）] で定義されます。 役職はそれぞれ特定のエンティティに割り当てられます。そのエンティティとしては、サービス、サービス グループ、組織単位があります。

地位の定義後、組織単位の [地位（Positions）] ページまたは、サービスあるいはサービス グループの [全般（General）] タブで個人をその地位に割り当てます。 次に使用例を示します。

カスタマーのホーム組織単位の Budget Manager の電子メール アドレスにアクセスするには、Requisition.Customer.HomeOU.BudgetManager.Email を使用します。

タスク実行者のホーム組織単位の親組織単位のマネージャのファーストネーム（名）にアクセスするには、Performer.HomeOU.ParentOU.Manager.FirstName を使用します。

デフォルトの役職には、「Budget Manager」のように地位名の間に空白が入っているものがあります。 名前空間参照で使用される役職ではスペースは省略します。

ユーザ指定の役職にはスペースを入れることはできません。 名前空間参照は、次の例のように役職の前にキーワード「Position」を付ける必要があります。

#Service.ServiceDefinition.Position.EscalationManager.Email#

すべての役職において、上記の Person 表で定義されているすべての変数を利用できます。 担当者の変数が含まれていない場合、式は担当者のデータベース ID を返します。

要求またはサービスのコンテキストでアクセスできる担当者のロールから、ホーム OU、親 OU、またはクライアント OU の役職に関する情報にアクセスできます。 サービスまたはサービス グループの役職に関する情報は、サービスのコンテキストだけで利用できます。

これらの式を使用して電子メールおよびタスク名に動的データを含める場合、式の最初と最後にポンド記号の区切り文字（「#」）を追加する必要があります。次に例を示します。

#Customer.HomeOU.Manager.Email#

カスタマー情報が予約されたディクショナリに使用する Customer-Based 名前空間を、以下にまとめます。

発信者情報が予約されたディクショナリに使用する Initiator-Based 名前空間を、以下にまとめます。