Cisco Prime Service Catalog 11.0 設計者ガイド
サービスの提供に関する計画の設計
サービスの提供に関する計画の設計

目次

サービスの提供に関する計画の設計

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

サービスの提供に関する計画の設計

提供計画は、カスタマーにサービスを提供するために完了する必要がある 1 つ以上のタスクで構成されています。 [Service Designer] > [サービス(Service)] > [計画(Plan)] タブは、サービスの提供計画を定義するために使用されます。

はじめる前に

  • タスク(または一連のタスク)が何であるかを識別します。
  • サービスが電子メール通知を必要とするかどうかを識別します。
  • 実行者、スーパバイザ、および電子メール受信者が誰であるかを識別します。

また、次の概念に関する知識が必要です。


    ステップ 1   サービスの提供プロセス用にプロジェクト マネージャを設定します。
    ステップ 2   タスク名、期間、条件、優先順位、およびその他のパラメータなど、個々のタスクを設定します。
    ステップ 3   タスクの実行者とスーパーバイザを指定します。
    ステップ 4   タスクに関連する通知電子メールを指定します。
    ステップ 5   タスク指示を設定します。
    ステップ 6   タスクのチェックリストを作成します。
    ステップ 7   タスク実行の順序、タスクの実行を同時に行うか連続して行うか、および共通のマイルストーンを共有するタスクまたは共通の通知要件を持つタスクの潜在的なグループ化など、タスクのワークフローを指定します。

    提供タスクの設定

    すべての提供計画には自動的に 1 つの全体的なタスクが組み込まれており、これを使用して、指定されたプロジェクト マネージャは提供計画の進捗をモニタできます。 [タスク(Tasks)] サブタブを使用して、サービス提供計画のタスクを指定し、各タスクの詳細なアクティビティを指定できます。 適切な順序でタスクを一覧表示することでタスクを定義します。サブタスクと親タスクは、プロジェクト管理ソフトウェアがプロジェクト内のプロジェクトおよび成果物を表示するのとほぼ同じ方法で表示されます。


      ステップ 1   [Service Designer] > [サービス(Services)] の順に選択します。
      ステップ 2   サービスを選択し、[計画(Plan)] > [タスク(Tasks)] の順に選択します。 [計画(Plan)] タブに複数のタスクがリストされている場合は、設定するタスク名をクリックします。

      タスクが青色/灰色で強調表示されている場合、開始する準備が整っています。設定する各タスクには、独自のサブタブのセットである [全般(General)]、[参加者(Participants)]、[電子メール(Email)]、[タスクの指示(Task Instructions)]、および[チェックリスト(Checklist)] があります。

      ステップ 3   タスクの詳細を定義します。 詳細については、「タスク サブタブのフィールド」を参照してください。
      ステップ 4   タスクを追加します。 理想的には、詳細な提供アクティビティを作成するときに、下記に示すフィールドに順番に進むことができるようにする必要があります。詳細については、「タスク テーブルのフィールド」を参照してください。
      ステップ 5   [全般(General)] サブ タブをクリックし、タスク名、実行順序、期間、優先順位、条件など、タスクの提供に関する詳細な計画アクティビティを作成します。

      会社のイントール済み環境が Service Link を使用してサードパーティ製のソフトウェアと統合されている場合、ここで外部アクションも選択します。 Service Item Manager を使用している場合、ここでサービス項目タスクも選択できます。

      詳細については、タスクの提供アクティビティの定義を参照してください。

      ステップ 6   [参加者(Participants)] サブ タブをクリックし、タスクを完了する人や作業の監視方法など、タスクの実行者に関する詳細を定義します。
      ステップ 7   [電子メール(Email)] サブタブをクリックし、タスクの開始時、完了時、取り消し時、再スケジュール設定時、再割り当て時、または外部タスクの失敗時に、システムが送信するオプションの電子メール テンプレートを定義します。 詳細については、提供タスクの電子メール通知の定義を参照してください。
      ステップ 8   [タスクの指示(Task Instructions)] をクリックし、タスクの手順を入力するか、または任意のタスク手順関連の URL へのリンクを設定します。 詳細については、タスクの指示の追加を参照してください。
      ステップ 9   [チェックリスト(Checklist)] サブ タブをクリックし、リマインダのリストを作成したり、タスクを完了するための手順を詳細化します。 これらは、チェックリストとして Service Manager に表示され、作業を完了するためのステップが詳細化されます。 詳細については、タスクを完了するためのチェックリストの作成を参照してください。

      タスク サブタブのフィールドの表では、「モニタ」タスク、つまり、全体的な提供計画に関係する [タスク(Tasks)] サブタブのフィールドをまとめています。 詳細については、関連サービスのバンドルの設定 を参照してください。

      表 1 タスク サブタブのフィールド

      フィールド

      説明

      プロジェクト マネージャ(Project Manager)

      役職、人/キュー、または式から、プロジェクト マネージャを割り当てます。 プロジェクト マネージャとは、Service Manager でサービスの計画モニタ タスクを受け取る人、役職、またはキューです。 このタスクにより、必要に応じて、人員配置の調整、タスクのスケジュール再設定と実行、および提供計画全体の取り消しさえも含む提供プロセス全体の監視を行うことができます。 右側の [...] ボタンをクリックするとダイアログボックスが表示され、そこで役職、人/キュー、または式のパラメータ内のタイプを検索および指定できます。 式の場合は、[式の設定(Set Expression)] をクリックして、保存します。

      計画モニタリングタスクのサブジェクト(Subject for plan monitoring task)

      計画のモニタリング タスクのサブジェクトを説明するテキスト。 サブジェクトには「モニタ」という語を入れることを推奨します。 名前空間で説明されているように、計画サブジェクトには名前空間を含めることができます。 […] ボタンをクリックすると、サブジェクトを編集できます。 [サブジェクトの設定(Set Subject)] をクリックして、変更を保存します。

      トップレベルタスクの実行(Top level tasks execute)

      提供計画内のトップレベル タスクを並列で実行(同時に実行)するか、順次に実行(1 つずつ順番に実行)するかを示します。

      計画を自動的に開始および完了しますか(Start and complete plan automatically?)

      このチェックボックスは、デフォルトでオンになっています。 これは、提供計画が始まると、計画内のすべてのタスクが自動的に作成され、それらの実行期日が算出されることを意味します。 このチェック ボックスをオフにすると、割り当てられたプロジェクト マネージャは提供計画を有効にする前に、措置を講じる必要があります。 提供時点が開始すると、タスクが 1 つのみ(MONITOR タスク)作成されます。 このタスクには、[計画の開始(Start Plan)] というラベルが貼られたボタンが表示されます。 これにより、プロジェクト マネージャは計画を「配置」できます(MONITOR タスクの [配置(Staffing)] ページを使用)。 そのページで、プロジェクト マネージャはいずれかの実行可能な役職、人、またはキューを提供計画に再割り当てできます。

      プロジェクト マネージャは計画の配置を完了したら、[計画の開始(Start Plan)] をクリックします。これにより、提供計画の最初のタスクが開始されます。 このボタンをクリックするまで、タスクは [配置(Staffing)] ステータスになります。

      将来の提供を許可する(Allow future delivery)

      これをオンにすると、エンド ユーザはサービス提供を開始しなければならないときに、前もってサービスを要求できるようになります。 このオプションを一度オンにしたら、エンド ユーザにはオーダー ページの上部全体にバーが表示されます。このバーを使用して、サービス提供を開始する日付を選択できます。

      エンド ユーザは、サービスの実行期日/完了日を指定できません。 ユーザが将来の提供日を選択すると、Service Catalog は、ユーザによって選択された日付までそのオーダーを待機状態に保持します。 その日付から、サービス提供プロセスが開始し、設定どおりに続行されます。

      計画がキャンセルされた場合に通知する(Notify when plan cancelled)

      サービス設計者は、プロジェクト マネージャがサービスの提供を取り消した場合に送信される電子メールを設定できます。

      1日あたりの稼働時間(Working hours per day)

      標準期間の営業日に時間を変換するのに使用されます。

      サービスの標準期間と表示単位を設定するには、提供タスクの設定タスクの提供アクティビティを定義するための設定テーブルの表を参照してください。

      提供タスクの定義

      次の表に、[タスク(Task)] テーブルのフィールドをまとめます。

      表 2 タスク テーブルのフィールド

      フィールド

      説明/使用方法

      新規作成(New)

      新しいタスクを提供計画に追加します。

      アップ

      ダウン

      タスク リスト内のタスクの順番を変更します。

      インデント

      インデント解除(Outdent)

      タスクをグループ化またはグループ化解除します。

      たとえば、タスクを作成して、[インデント(Indent)] をクリックすると、そのタスクはその上のタスクのサブタスクになります。

      (注)      [アップ(UP)]、[ダウン(Down)]、[インデント(Indent)]、および [インデント解除(Outdent)] フィールドを使用して、タスクが正しい順序で実行し、適切にグループ化されるようにします。

      削除(Delete)

      タスクを削除します(また、その下にあるすべてのサブ タスクも削除します)。

      タスクの提供アクティビティの定義

      1 つのタスクまたは一連のタスクの詳細な提供アクティビティを定義するには、次の手順を実行します。

      表 3 タスクの提供アクティビティを定義するための設定テーブル

      フィールド

      説明

      ワークフロータイプ(Workflow Type)

      デフォルトは、[内部(Internal)] です。 これは、外部システムを使用して定義された Service Link 統合がなく、サービス項目タスクがないサイト用に表示される唯一のオプションです。 タスクが Service Catalog 内で実行される場合は、[内部(Internal)] を選択します。

      タスクが外部アプリケーションで実行される場合(Service Catalog 内ではない場合)は、該当する [外部(External)] オプションを選択します。 外部タスクの場合のみ、タスクを保存した後に、[ワークフロータイプ(Workflow Type)] の横に省略(...)ボタンが表示されます。 詳細については、外部タスクの設定 を参照してください。

      Service Item Manager モジュールを使用して、サービス項目を設計し、それらの項目を追跡する場合は、[サービス項目タスク(Service Item Task)] を選択します。 サービス項目タスクについての詳細は、提供計画でのサービス項目タスクの定義サービスおよび属性の管理を参照してください。

      rabbitmq メッセージ ブローカ サーバにサービス リクエスト データを公開するには、[キューサービスリクエスト(Queue Service Request)] を選択します。 rabbitmq ブローカと特定の Exchange に登録している外部システムは、メッセージを受信し、独自のワークフローを実行できます。

      サービス提供計画内のグリッド ディクショナリを使用して作成されたサービス項目(複数可)への権限を付与または取り消すには、[NsApiタスク(NsApi Task)] を選択します。 詳細については、サービス項目への権限を付与および取り消すためのサービス提供タスクの作成を参照してください。

      Organization Designer エンティティ(組織単位、人、キュー)または Service Link エージェントの追加または更新のための操作である場合は、[ディレクトリタスク(Directory Task)] を選択します。

      詳細については、提供タスクの定義を参照してください。

      タスク名(Task Name)

      タスクの簡単なタイトル。 これは、Service Manager でタスクのサブジェクトとして表示されます。 提供タスク名には、#Name# 名前空間を使用して、サービス名を含めることができます。 サービス データ(#Service.Data....#)も使用できます。

      タスク名にフォーム データを使用すると、タスク実行者は Service Manager で、より簡単にタスクを識別できるようになります。 ただし、これにより、タスクはタスク名によって自動的にグループ分けされなくなるため、レポート作成モジュールでいくつかの課題が生じます。たとえば、レポート設計者は、[カスタムグループ(Custom Groups)] を使用して、そのようなタスクごとに集約する必要があります。 また、管理者は、「次を含む(contains)」検索を行えるように Service Manager を設定しなければならない場合があります。これは、パフォーマンスに悪影響を及ぼす可能性があります。 サービス設計者は、タスク名の一部としてフォーム データ名前空間を含める前に、慎重に検討する必要があります。

      エージェントの作成(Create Agent)

      タスクを保存すると、[エージェントの作成(Create Agent)] ボタンが表示されます。 このボタンをクリックして、[統合(Integration)] ウィザードを使用します。 完全な詳細については、『Cisco Prime Service Catalog Adapter Integration Guide』を参照してください。

      (注)      [統合(Integration)] ウィザードは、Service Link エージェントと変換の作成が可能なロールを付与された、サービス設計者だけが使用できます。

      [統合(Integration)] ウィサードは、統合の実装に関連する多くのステップを自動化します。 これは、Service Catalog と Web サービスの間の統合を作成する場合にのみ使用できます。

      [統合(Integration)] ウィザードは、Web サービスの統合によって起動される Web サービス記述言語(WSDL)や処理を収集することによって動作します。 統合のその定義に基づいて、[統合(Integration)] ウィザードは次を作成します。

      • 統合を実行するために外部タスクで使用できる Service Link エージェント
      • nsXML を Web サービスによって要求される SOAP メッセージに変換する変換機能
      • 初期の Web サービス要求とその応答の両方に必要なすべてのデータに対するエージェント パラメータ
      • エージェント パラメータにマップされたフィールドを含むディクショナリ
      • エージェントのパラメータ値を保持するために作成されたディクショナリを含むアクティブ フォーム コンポーネント

      サブタスクの実行(Subtasks execute)

      トップダウン メニューを使用して、このタスクの任意の「子」タスクが実行される順番を選択します。1 つずつ順番に実行(順次)するか、同時に実行(並列)するかを選択します。

      子タスク(サブタスク)が提供計画でアクティブ(実行中)になります。これらは、親タスクがアクティブになる前に完了する必要があります。

      子タスクを順次に実行すると、サービス期間にそのようなすべてのタスクの期間が含まれるようになります。 タスクを並列で実行すると、サービス期間には任意の子タスクの最大期間が含まれるようになります。

      時間(Duration)

      システムによってタスクがアクティブ(開始)であると判断されてから、タスクが完了するまでの予想時間で、小数点 2 桁に四捨五入されます。

      たとえば、ソフトウェア プログラムのインストールに 1 時間しかかからない場合、タスクの実行者のワークロードと優先順位は 2 営業日のコース全体にわたってさまざまである可能性があるため、その実行者に、タスクを完了するために 16 時間の期間を与えることができます。

      [期間(Duration)] の値はカスタマーまたは実行者には表示されませんが、タスクの実行期日の算出に使用されます。

      実行(Effort)

      実行者がタスクを完了するのにかかった実際の時間であり、小数点 2 桁に四捨五入されます。 たとえば、ソフトウェア プログラムのインストールに 1 時間かかる場合があります。 [期間(Duration)] は「合計経過時間」であるのに対し、[実行(Effort)] は「タスクを実行した時間」です。

      [実行(Effort)] の値はどのユーザにも表示されず、実行期日の算出にも使用されません。代わりに、内部生産性目標として使用されます。

      [プライオリティ(Priority)]

      タスクの優先順位を [低(Low)]、[標準(Normal)]、または [高(High)] に設定します。 フラグ以外は、タスクの優先順位に関連付けられたシステム動作はありません。このフラグは、Service Manager で表示されます。

      • 優先順位が [高(High)] に設定されると、システムは、タスクが表示される [Service Manager] ビューに赤色の感嘆符を設定します。
      • 優先順位が [低(Low)] に設定されると、システムは、タスクが表示される [Service Manager] ビューに青色の下矢印を設定します。
      • 優先順位が [標準(Normal)] に設定されると、Service Manager にフラグは表示されません。

      条件

      条件付きステートメントにより、条件に使用されている式が True(このタスクを含む)か False(このタスクをスキップする)のどちらに評価されるかに基づいて、タスクを開始したり、スキップしたりできます。 式は、名前空間に記載されている名前空間と演算子を使用して作成されます。

      式を入力した後、[検証(Validate)] をクリックして、その式が正しいことを確認します。

      以下について検証します。

      • 指定された名前空間が、ディクショナリ フィールド(Data.DictionaryName.FieldName)を除いて、現在のスコープ(特定のレベルの確認/承認またはタスク)で有効であるかどうか。 ただし、指定された名前空間(たとえば、Data.EUIT_ACCESS.Access_Type)が存在しない場合、ランタイム エラーが発生することがあります。
      • 正しい関係演算子および算術演算子が使用されているかどうか。

      「予期しないトークン(unexpected token)」というメッセージは、使用されている名前空間がこのコンテキスト内で無効であるということか、アルファベット文字を引用符で囲むのを忘れた可能性があるということを示します。

      条件が入力された場合、ステートメントが評価される時期を決定する必要があります。 各タスクの条件(承認、確認、または提供)は、いずれかの時期に評価できます。

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

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

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

      • いずれかのタスクが完了してなくても、サービスが「自動完了」する必要がある場合。 スキップされるタスクは、提供計画内の唯一のタスクです。 これがスキップされると、要求には完了のマークが付けられます。
      • 次のように、タスクを完了せずに電子メールを送信する必要がある場合、または特定の時点で複数の電子メールが必要な場合。
        • 親タスクを作成する。 [電子メール(Email)] サブタブで、完了時に送信される電子メールを選択します。 (アクティビティがアクティブになったときに送信される通知も設定することができます。)詳細については、提供タスクの電子メール通知の定義を参照してください。
        • 1=2 の条件で子タスクを作成する。 アクティビティがアクティブになったときに評価する条件を設定します。

      スケジュール済み開始日を許可する(Allow a scheduled start date)

      タスクを遅延タスクにするには、[スケジュール済み開始日を許可する(Allow a scheduled start date)] をオンにします。次に、[開始日のフォームデータ(Form data for start date)] フィールドで、次の操作を行います。

      • 日付と時刻を「YYYY-MM-DD HH:MM」のフォーマットで入力します。たとえば、「2006-12-23 13:30」のようになります(引用符が必要です)。
      • あるいは、タスクの開始ポイントの日付と時刻を保持するのに使用するディクショナリ フィールドの名前を入力します。 次の構文を使用します。
        • Data.DictionaryName.FieldName(サービスのアクティブ フォーム コンポーネントのいずれかにあるディクショナリからのフィールド用)。
        • ParentData.DictionaryName.FieldName(親サービスのディクショナリのいずれかからのフィールド用。バンドルされたサービスの場合)。

      遅延タスクに関する詳細については、「スケジュールされた開始タスクに対するシステムの動作」を参照してください。

      開始日のフォームデータ(Form data for start date)

      [スケジュール済み開始日を許可する(Allow a scheduled start date)] オプションをオンにすると、開始日のフォーム データを入力して、[検証(Validate)] をクリックできます。

      提供フェーズが開始されたときに条件を評価する(Evaluate condition when delivery phase starts)

      何らかの条件を指定した場合、このオプション ボタンをクリックして、その条件が評価される時期を示します。 このサービスの提供時点が開始した時点で条件を評価する場合は、これを選択します。 これは、提供時点が開始する前に、式を正しく評価するために必要な情報が使用可能になる必要があることを示します。 各承認または確認には固有の時点があり、すべての提供タスクはサービス提供時に実行されます。

      承認タスクは常に直列に実行されます。 たとえば、field= "x" で別の条件が field < > “x” のように、1 つのタスクに 1 つの条件を配置できます。 そうすることで、常に 1 つの承認タスクが実行されます。[承認フェーズが開始されたとき(when authorization phase starts)] を選択した場合、プロセス ビューに表示される承認タスクは 1 つだけです。 [タスクがアクティブになったとき(when task becomes active)] を選択した場合、両方のタスクが表示されますが、1 つは省略されます。

      [条件が「false」と評価された場合、時間はゼロとして計算されます(if conditions evaluate to "false", times will be computed as zero)] 文は、Service Catalog がフェーズの開始時に条件を評価することを表しています。 これらの条件が false の場合、対応するタスクは実行されず、サービスの実行期日はこれらのタスクの期間を含めずに計算されます。

      タスクがアクティブになったときに条件を評価する(Evaluate condition when task becomes active)

      条件を指定した場合は、提供プロセスが提供計画のこのタスクに達した場合にのみ条件が評価される必要があることを示すためのオプション ボタンをクリックします。

      Service Catalog は、各タスクの開始時に条件を評価します。 条件が false の場合、対応するタスクは実行されません。 このオプションで設定されているタスクの期間を使用して送信時に実行期日が計算されます。

      計画が進展したときに式を再評価する(Re-evaluate expressions as plan advances)

      この機能により、タスクに対する実行者の割り当てに加え、タスクの名前も、フォーム データに基づいて動的に変更できます。 これは、タスク名または実行者の割り当てが、フォーム データを使用した名前空間式から導き出される必要があるように指定した場合に、提供プロセス中にフォーム データが変更されるときに便利です。

      このフラグを設定すると、タスクがアクティブになったときに(提供計画全体が開始されるときではない)、式が評価されるように指定されます。 このオプションが選択されていない場合、承認タスクの式に使用されるすべての情報がオーダー時点で存在している必要があります。

      式の再評価機能は、複数の順次承認またはタスクが存在する設計で役立ちます。 これを使用すると、タスクの実行者は、後続のタスクの実行者を割り当てるために使用される式の再計算に使用されるサービス フォームに情報を入力できます。

      この機能により、ユーザ(人またはキュー)へのタスクの動的割り当てと、タスク タイトルの動的な調整を行えます。 タスクがアクティブになると、式が評価され、タスクが適切に割り当てられます。

      (注)      タスクの実行者の再評価は、タスクの実行期日に影響を及ぼしません。 提供時点が開始した後に、実行期日は再計算されません。

      タスクの開始後のキャンセルを許可しない(Do not allow cancellation of service after task starts)

      このチェック ボックスをオンにすると、このタスクがアクティブになった後に、カスタマーはサービスを取り消すことができなくなります。

      たとえば、タスクによって提供チームに多大なコストが生じたり、簡単には元に戻せないアクションを行ったりする場合に、これをオンにします。

      My Services の [キャンセル(Cancel)] オプションは、提供チームがこのタスクを開始すると、非アクティブになります。

      提供タスクの[実行(Effort)]サブページを表示(Display Effort subpage on a delivery task)

      このボックスをオンにすると、提供タスクの [実行(Effort)] サブタブが Service Manager に表示されます。

      提供計画でのサービス項目タスクの定義

      ここでは、サービス項目タスクの機能について説明します。 Service Item Manager モジュールを使用して、設計者は特定の項目を「サービス項目」に指定でき、履歴を Service Catalog 内で追跡できます。 典型的なサービス項目として、ラップトップ、デスクトップ、ソフトウェア ライセンス、または固有に識別でき、それらの使用法(および所有権)を追跡する必要のある企業資産が挙げられます。 サービス項目タスクは、サービスにサービス項目ベースのディクショナリ(SIBD)が含まれている場合にのみ使用できます。


        ステップ 1   [Service Designer] > [計画(Plan)] > [タスク(Task)] > [全般(General)] の順に選択します。
        1. [ワークフロータイプ(Workflow Type)] として [サービス項目タスク(Service Item Task)] を選択し、計画を保存します。
        ステップ 2   [ワークフロータイプ(Workflow Type)] の横に表示される省略形(...)をクリックします。

        [サービス項目のタスクパラメータ(Service Item Task Parameter)] ポップアップ ウィンドウが表示されます。

        ステップ 3   使用する SIBD を選択します。
        ステップ 4   サービス項目のステータス属性値のみを変更する操作の場合は、[ステータスのみを更新(Update Status Only)] チェック ボックスを選択します。
        ステップ 5   [操作(Operation)] ドロップダウンリストから適用する操作を選択します。
        ステップ 6   [OK] をクリックして、タスク定義を保存し、ポップアップ ウィンドウを終了します。
        ステップ 7   SIBD がグリッド ディクショナリで、グリッド行を特定のフィールド値に基づいて条件付きで処理する必要がある場合は、[グリッド行の処理(Process Grid Row)] に条件式を入力し、[検証(Validate)]、[OK] の順でクリックします。

        条件式の構文と例については、外部タスクの設定を参照してください。


        サービス項目のサブスクリプション処理ルール

        サービス項目サブスクリプション テーブル内のカスタマーと組織単位に関する情報は、要求の情報とは別個に設定に設定することができます。

        • 作成操作でサブスクリプション情報が提供されていないと、要求のカスタマーとその個人のホーム組織単位に項目が割り当てられます。
        • サービス項目インスタンスが作成されたときにカスタマー ID のみが指定されていると、項目の組織単位 ID がカスタマーのホーム組織単位に設定されます。
        • カスタマー ID または組織単位 ID のいずれかに値が指定されていると、その値はサービス項目サブスクリプションを更新するために使用されます。 値がヌルまたはゼロの場合、対応するサブスクリプション フィールドがヌルに設定されます。 サービス項目ベースのディクショナリにプロパティが存在しない場合、属性値に変更/上書きが行われません。
        • ディクショナリに指定された要求 ID と要求エントリ ID は無視され、サブスクリプション レコードの更新には使用されません。

        カスタマーと組織単位の割り当てで可能な組み合わせとその結果は次のように要約されます。

        表 4 カスタマーおよび組織単位の割り当ての組み合わせ

        サービス項目の作成時

        サービス項目ベースのディクショナリ フィールド

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

        ログイン名(Login Name)

        OU 名

        カスタマー

        OU

        なし

        なし

        要求のカスタマー

        カスタマーのホーム OU

        なし

        空白、無効な

        値、またはゼロ

        要求のカスタマー

        NULL

        なし

        有効な OU

        要求のカスタマー

        提供された OU

        ログイン名(Login Name)

        OU 名

        カスタマー

        OU

        ブランクまたは無効な値

        なし

        NULL

        カスタマーのホーム OU

        ブランク、無効な値、またはゼロ

        ブランク、無効な値、またはゼロ

        NULL

        NULL

        ブランク、無効な値、またはゼロ

        有効な OU

        NULL

        提供された OU

        有効なカスタマー

        なし

        提供されたカスタマー

        カスタマーのホーム OU

        有効なカスタマー

        値なし

        提供されたカスタマー

        NULL

        有効なカスタマー

        有効な OU

        提供されたカスタマー

        提供された OU

        サービス項目の更新時

        サービス項目ベースのディクショナリ フィールド

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

        なし

        なし

        変更なし

        変更なし

        なし

        ブランク、無効な値、またはゼロ

        変更なし

        NULL

        なし

        有効な OU 名

        変更なし

        提供された OU

        ブランク、無効な値、またはゼロ

        なし

        NULL

        変更なし

        ブランク、無効な値、またはゼロ

        ブランク、無効な値、またはゼロ

        NULL

        NULL

        ブランク、無効な値、またはゼロ

        有効な OU 名

        NULL

        提供された OU

        有効なカスタマー

        なし

        提供されたカスタマー

        カスタマーのホーム OU

        有効なカスタマー

        ブランク、無効な値、またはゼロ

        提供されたカスタマー

        NULL

        有効なカスタマー

        有効な OU 名

        提供されたカスタマー

        提供された OU

        サービス項目タスクの操作

        サービス項目タスクの操作は、サービス項目を作成、更新、または削除するよう Service Catalog に指示します。 サービス項目タスクは、サービスのワークフローにおいて、タスクの順序別に指定されたとおりに実行されます。

        • サービス項目の作成:すべてのカスタム操作は事実上「更新」です。 ここでのすべてのポイントは、それらにも適用されます。すなわち、操作タイプ「作成」でサービス項目タスクが実行されると、Service Catalog は次のことを行います。
          • サービス項目のエントリをサービス項目テーブルに作成します。 このエントリには、データがサービス フォームから指定されているサービス項目のすべての属性が含まれます。
          • サービス項目のエントリをサービス項目サブスクリプション テーブルに作成します。 このテーブルには、すべてのサービス項目とその現在のステータスが記録されます。
          • カスタマー、現在の要求、要求が送信された日時、サービス項目が作成された日時を記録します。
          • サービス項目のエントリをサービス項目履歴テーブルに作成します。 このテーブルには、サービス項目を作成した要求が記録されます。
        • サービス項目の更新:操作タイプ「更新」でサービス項目タスクが実行されると、Service Catalog は次のことを行います。
          • サービス項目の既存のエントリをサービス項目ナレッジ ベース テーブルで更新します。
          • サービス項目のエントリをサービス項目サブスクリプション テーブルで更新し、変更されたサービス項目のステータスが反映されます。
          • サービス項目のエントリをサービス項目履歴テーブルに作成します。 このテーブルには、サービス項目のステータスに影響するすべての操作(およびサービス項目のタスクが発生した要求)が記録されます。
        • サービス項目の削除:サービス項目を削除すると、サービス項目のすべてのトレースが削除され、履歴などのシステムから項目へのすべての参照が消去されます。 シナリオによっては、属性を「非アクティブ(Inactive)」または「廃止(Defunct)」にマークしてサービス項目に組み込むか、このような項目をプロビジョニングすることを禁止する条件付きルールを記述したほうがいい場合があります。

        サービス項目とサービス項目タスクの詳細については、9 章のサービスおよび属性の管理を参照してください。

        外部タスクの設定

        ここでは、外部サービス項目タスク、つまり Service Catalog の外で実行されるタスクのワークフロー タイプについて説明します。

        ワークフローでの外部タスクの定義

        デフォルトで、[ワークフロータイプ(Workflow Type)] のドロップダウンリストには、[内部(Internal)] という 1 つのエントリしか含まれていません。これは、そのタスクが Service Manager モジュール内で実行されることを示しています。 統合専門家が Service Link モジュールを使用して外部システムと統合する「エージェント」を定義した場合、各エージェントに関連付けられたアクションもドロップダウンリストに表示されます。

        たとえば、「SAP 統合」エージェントのワークフロー タイプが [データをSAPに送信(Send data to SAP)] のように表示される場合があります。「救済策」と統合されるエージェントのワークフロー タイプは [チケットを救済策に送信(Send Ticket to Remedy)] のように表示される可能性があります。


        ヒント


        Service Link と統合されるサービスおよびタスクの詳細については、サイト管理者に問い合わせてください。


        外部タスクの場合のみ、タスクを保存した後に、[ワークフロータイプ(Workflow Type)] の横に省略(...)が表示されます。

        図 1. 省略符号

        Service Link モジュールに対して権限を持っている場合、[…] ボタンをクリックして、[エージェントパラメータのオーバーライド(Agent Parameter Override)] ダイアログボックスにアクセスできます。 このダイアログボックスには、外部システムに送信されるデータが、サービス フォームのフィールド、または要求に関する他のデータにどのようにマップされるかを示す設定が含まれています。 これらの設定を変更する権限を持っている場合、ダイアログボックスは編集可能です。それ以外の場合は、読み取り専用です。 Service Link に対する権限の詳細については、『Cisco Prime Service Catalog Administration and Operations Guide』の「Capabilities for Service Link」の項を参照してください。

        外部サービス項目タスクの操作

        ワークフローで外部サービス項目タスクがアクティブになる(つまり、ステータスが実行中となる)と、Service Link はサービス項目の作成、更新、または削除を行うための受信要求をリッスンします。 サービス項目リポジトリに加えられた変更は、内部サービス項目タスクの変更と同様です。 着信要求のチャネル ID により、Service Link はサービス項目履歴の追跡に使用されるサービス要求を特定できます。

        外部タスクの代表的なものである他のタスクの更新(コメントの追加やパラメータ更新の送信など)を着信要求から実行することもできます。 すべてのサービス項目操作が正常に処理されると、タスクを完了するために「完了」アクションを送信する必要があります。これで、提供計画での次のタスクを起動できます。

        サービス項目リスナー アダプタと受信サービス項目メッセージの仕様の詳細については、『Cisco Prime Service Catalog Adapter Integration Guide』の「Designing Integrations with Service Link Standard Adapters」の章を参照してください。再設定操作によって、マシンで現在動作しているプロセスが中断する可能性があるため推奨されません。 実際に、VMware Infrastructure Client から実行されるアクションは禁止されています。 したがって、サービス設計者は「再設定」タスクの前に「電源オフ」タスクを追加する必要があります。 これで、仮想マシンを再設定する後続の要求を続行することができます。 電源オフ タスクを受信したときに仮想マシンがすでにダウンしている場合は、電源オフ タスクが失敗しますが、この失敗による悪影響はなく、再設定タスクの進行を妨げるものではありません。

        ワークフローでのディレクトリ タスクの定義

        ディレクトリ タスクは、フォーム データを使用する人、組織単位、または Service Link エージェントを作成または更新するために使用できます。 操作が失敗した場合、タスクは完了とマークされ、エラー メッセージがサービス フォームに書き込まれます。

        必須フィールドを含む自由形式のディクショナリをディレクトリ タスクで使用できます。 操作によって返されたエラーを算出するために、ディクショナリには「ErrorDescription」という名前のテキスト フィールドも含まれている必要があります。 オーダー時はこのフィールドを非表示にし、このフィールドの値を使用してエラー処理用の手動タスクを条件付きでトリガーすることを検討します。

        また、ディレクトリ タスクをグリッド ディクショナリと一緒に使用することで、同じオブジェクト タイプ(たとえば、複数の組織単位の作成など)の複数の発生を処理することができます。 タスクはグリッド ディクショナリ内のすべての行でループし、それぞれに対して操作を実行します。 例外が一部の発生で起きた場合、エラー メッセージがそれらのグリッド行の [ErrorMessage] フィールドに記録され、正常に完了済みのものには影響しません。

        また、アプリケーションが各行の条件を評価し、条件が満たされた場合に操作を進めるように、演算子を使用して条件式を設計することもできます。

        条件式の構文:Data.<DictionaryName>.<FieldName>

        条件式の:(Data.ouDict1.Type = "Service Team" and Data.ouDict1.Description="abc") または (Data.ouDict1.Type = "Business Unit" and Data.ouDict1.Description="xyz")

        ここで使用する構文は提供タスクのそれと同じですが、ディクショナリの名前空間だけがプロセス グリッド行の条件式でサポートされます。 要求、タスク、またはサービス固有の名前空間はこのコンテキストには適用されません。

        ディレクトリ タスクを設定するには、次の手順を実行します。


          ステップ 1   [Service Designer] > [計画(Plan)] > [タスク(Task)] > [全般(General)] の順に選択します。
          ステップ 2   [ワークフロータイプ(Workflow Type)] として [ディレクトリタスク(Directory Task)] を選択し、タスク名を入力して計画を保存します。
          ステップ 3   [ワークフロータイプ(Workflow Type)] の横に表示される省略形(...)をクリックします。

          [ディレクトリタスクパラメータ(Directory Task Parameter)] ポップアップ ウィンドウが表示されます。

          ステップ 4   使用するディクショナリと、適用する操作を選択します。
          ステップ 5   条件式を入力し、[検証(Validate)] をクリックして [OK] をクリックします。

          次の操作がディレクトリ タスクでサポートされています。 ディレクトリ操作の必須フィールドとオプション フィールドは、ディレクトリ タスクでサポートされる操作の表にリストしています。

          表 5 ディレクトリ タスクでサポートされる操作

          操作

          ディクショナリ フィールド

          備考

          • 新しいキューの作成
          • 既存のキューの更新
          • 既存のキューの作成または更新

          入力:(* 作成操作の場合は必須)

          [名前*(Name*)]:テキスト(100)

          [電子メールアドレス*(Email_Address*)]:テキスト(100)

          [ホーム組織単位*(Home_Organizational_Unit*)]:テキスト(200)

          [タイムゾーン*(Timezone*)]:テキスト(50)

          出力

          [個人ID(Person_ID)]:テキスト(50)

          [組織ID(Organization_ID)]:テキスト(50)

          [ErrorDescription]:テキスト(80)

          新しくキューを作成するか、そのキューがすでに存在する場合は、更新を実行します。

          参照される組織単位またはグループは、システムにそれらがまだ存在しない場合は、自動的に作成されます。

          [タイムゾーン(Timezone)] フィールドの値は、Organization Designer の [タイムゾーン(Time Zone)] 選択肢に表示される省略名のフォーム(たとえば、「America/Los_Angeles」)にする必要があります。

          [個人ID(Person_ID)] フィールドと [組織ID(Organization_ID)] フィールドの値は、キューまたはホーム OU が作成されるときに、更新されて要求フォームに返されます。

          • 人物のアクティブ化
          • 人物の非アクティブ化

          入力:[ログインID(Login_ID)]:テキスト(50)

          出力:[ErrorDescription]:テキスト(80)

          人物のステータスを「アクティブ」または「非アクティブ」に適宜変更します。

          新しい組織単位の作成

          サポートされるディクショナリ フィールドは次のとおりです:[組織ID(Organization_ID)]、[名前*(Name*)]、[説明(Description)]、[タイプ*(Type*)]、[親の名前(Parent_Name)]、[親のタイプ(Parent_Type)]、[請求可能(Billable)]、[親の説明(Parent_Description)]

          作成された組織の ID は [組織ID(Organization_ID)] フィールドでフォームに返されます。

          ディレクトリ タスク ワークフローでこの操作を選択した場合は、ユーザがサービス ワークフロー中にタスクとして新しい組織単位を作成できるようにすることができます。 ユーザは Organization Designer モジュールへのアクセス権限は必要ありません。 タスクの実行中に、[親の名前(Parent_name)] フィールドがオーダー フォームにすでに存在しているので、ここで親の名前を追加できます。 アプリケーションは、親が存在しない場合、または既存の親に関連付ける場合に新しい親を作成します。 作成された組織の ID は [組織ID(Organization_ID)] フィールドでフォームに返されます。

          • 新しい人物の作成
          • 既存の人物の更新
          • 新しい人物の作成/既存の人物の更新

          入力:(* 作成操作の場合は必須)

          [名*(First_Name*)]:テキスト(50)

          [性*(Last_Name*)]:テキスト(50)

          [ログインID*(Login_ID*)]:テキスト(50)

          [パスワード*(Password*)]:テキスト(50)

          [電子メールアドレス*(Email_Address*)]:テキスト(100)

          [ホーム組織単位*(Home_Organizational_Unit*)]:テキスト(200)

          [タイムゾーン*(Timezone*)]:テキスト(50)

          [ロックされています(Is_Locked)]

          [LoggedIn_UserPwd]

          [組織(Organizations)]:テキスト(4000)

          [グループ(Groups)]:テキスト(4000)

          [ロール(Roles)]:

          [個人識別(Personal_Identification)]:テキスト(512)

          [タイトル(Title)]:テキスト(100)

          [社会保障番号(Social_Security_Number)]:テキスト(100)

          [注意(Notes)]:テキスト(4000)

          [会社コード(Company_Code)]:テキスト(200)

          [部門(Division)]:テキスト(200)

          [営業部門(Business_Unit)]:テキスト(200)

          [部署番号(Department_Number)]:テキスト(200)

          [コストセンター(Cost_Center)]:テキスト(200)

          [管理レベル(Management_Level)]:テキスト(200)

          [地域(Region)]:テキスト(200)

          [スーパーバイザID(Supervisor_ID)]:テキスト(200)

          [従業員タイプ(Employee_Type)]:テキスト(200)

          [ロケーションコード(Location_Code)]:テキスト(200)

          [会社の番地1(Company_Street_1)]:テキスト(100)

          [会社の番地2(Company_Street_2)]:テキスト(100)

          [会社の市区町村(Company_City)]:テキスト(100)

          参照される組織単位またはグループは、それらがまだ存在しない場合は、自動的に作成されます。

          [個人ID(Person_ID)] フィールドと [組織ID(Organization_ID)] フィールドの値は、操作中に人またはホーム OU が作成されるときに、サービス フォームに返されます。

          [タイムゾーン(Timezone)] フィールドの値は、Organization Designer の [タイムゾーン(Time Zone)] 選択肢に表示される省略名のフォーム(たとえば、「America/Los_Angeles」)にする必要があります。

          [組織(Organizations)]、[グループ(Groups)]、および [ロール(Roles)] フィールドの入力タイプは、使用されるアクティブ フォーム コンポーネントで [選択(複数)(select (multiple))] に設定される必要があります。

          [更新(Update)] 操作では、人の記録を検索するのに、[ログインID(Login_ID)] フィールドが使用されます。 ディクショナリに含まれていない個人属性は、更新されません。

          ユーザのアカウントが再試行ポリシーの違反によりロックされた場合、[IsLocked] フィールドが自動的に有効になります。 ユーザ アカウントのロックを解除するには、[IsLocked] フィールドを無効にしてから、ユーザ パスワードをリセットします。

          ユーザを作成する場合、またはユーザ パスワードを変更する場合に限り、[LoggedIn_UserPwd] に入力してください。

          [レベル(Level)]:テキスト(100)

          [パーティション(Cubicle)]:テキスト(100)

          [個人の番地1(Personal_Street_1)]:テキスト(100)

          [個人の番地2(Personal_Street_2)]:テキスト(100)

          [個人の市区町村(Personal_City)]:テキスト(100)

          [個人の都道府県(Personal_State)]:テキスト(100)

          出力

          [個人ID(Person_ID)]:テキスト(50)

          [組織ID(Organization_ID)]:テキスト(50)

          [ErrorDescription]:テキスト(80)

          [個人の郵便番号(Personal_Postal_Code)]:テキスト(100)

          [個人の国(Personal_Country)]:テキスト(100)

          外部ユーザ認証(EUA)を使用して、Prime Service Catalog 内のデフォルトの認証メカニズムを上書きし、ユーザを外部ソースに対して認証することができます。

          EUA が有効になっていない場合、またはユーザ プロファイルのパスワード変更の認証にバックドア URL を使用する場合は、[LoggedIn_UserPwd] フィールドにパスワードを変更しようとしてログインしているユーザのデータベース パスワードが含まれている必要があります。 EUA が有効の場合は、[LoggedIn_UserPwd] フィールドで LDAP パスワードを使用する必要があります。

          次の場合はエラーが返されます。

          • ユーザの作成時に同じログイン名を持つユーザがすでに存在する場合、または
          • ユーザの更新時にユーザが存在しない場合
          • パスワードがパスワード ポリシーに準拠していない場合。

          組織単位の更新

          名前*(Name*)

          タイプ*(Type*)

          説明

          ステータス(Status)

          請求可能(Billable)

          ErrorDescription

          OU のタイプを変更する必要がある場合は、「Change_Type」という名前のフィールドを追加します。

          (注)      [タイプ(Type)] フィールドは操作先の組織単位を識別します。 また、すべての組織単位関連の操作は、組織単位の ID を返す Organization_ID を定義できます。

          組織単位の名前の変更

          名前*(Name*)

          新しい名前*(New_Name*)

          タイプ*(Type*)

          ErrorDescription

          組織単位のアクティブ化/非アクティブ化

          名前*(Name*)

          アクティブ化*(Activate*)

          タイプ*(Type*)

          ErrorDescription

          [アクティブ化(Activate] フィールドは、組織単位のステータスを [アクティブ(Active)] に更新する場合は [true] または [はい(yes)] に設定し、ステータスを [非アクティブ(Inactive)] に更新する場合は [false] または [いいえ(no)] に設定する必要があります。

          既存のエージェント プロパティの更新

          名前*(Name*)

          この機能を使用して、インバウンドおよびアウトバウンドのエージェント プロパティを更新するディレクトリ タスク操作付きのサービスをオーダーすることができます。

          (注)     

          エージェント プロパティの名前が自由形式のディクショナリの名前と一致することを確認します。 ただし、文字「.」は「_」と置き換える必要があります。なぜなら、アクティブ フォーム ディクショナリの作成時にアプリケーションは「.」の文字を受け付けないからです。 アップデート プロセス中は、アプリケーションはディクショナリ内の正しくないエントリを無視します。 たとえば、エージェント プロパティが FileOutbboundAdapter.FileLocation 場合、ディクショナリ フィールド名は FileOutbboundAdapter_FileLocation にする必要があります。

          アカウントの作成/アカウントの更新

          この操作のディレクトリ タスク ワークフローに関連付けるディクショナリに次のフィールドが存在することを確認します。

          名前*(Name*)

          AccountType*

          説明

          BillingRateGroup

          OrganizationalUnit

          ErrorDescription

          1)名前の最大長は 100 文字です。

          2)AccountType の値は [プロジェクトアカウント(Project Account)] または [テナントアカウント(Tenant Account)] にする必要があります。

          3)説明の最大長は 500 文字です。

          4)[組織単位(Organizational Unit)] フィールドは、複数選択ボックスの入力を取り、値はタイプ「営業部門」と見なされます。 テナント アカウントの場合は、組織単位を 1 つだけ指定できます。

          5)現時点で、役職およびカスタム属性は指定できません。

          契約の作成

          名前*(Name*)

          AccountType*

          アカウント*(Account*)

          AgreementTemplate*

          説明

          ErrorDescription

          外部システムにサービス要求を発行するための AMQP タスクの設定

          Prime Service Catalog では、Advanced Message Queuing Protocol(AMQP)を使用して、サービス要求を他のアプリケーションやシステムに発行することができます。 AMQP では、プラットフォームまたはシステム間でメッセージをどのように構造化し送信するかに関する基準が提供されます。

          オープン ソース ソフトウェアである RabbitMQ を使用している Prime Service Catalog は、AMQP を実装し、システム間でメッセージのルーティングを実行します。 サービス要求を消費するシステムの一例である Cisco Process Orchestrator は、要求を受け取り履行ワークフローを実行します。

          (注)  


          Poodle セキュリティ攻撃を回避するために、Prime Service Catalog 11.0 は TLS 1.2 プロトコルのみを経由した RabbitMQ への接続をサポートしています。したがって、カスタマーは TLS1.2 を使用してメッセージに接続して消費する必要があります。 したがって、RabbitMQ サーバからこれらのメッセージに接続して消費するには、TLS1.2 のみを使用します。


          キュー サービス要求と呼ばれるタスク タイプは、他のアプリケーションやシステムにサービス要求を発行するために使用されるワークフロー タイプ下で使用できます。

          キュー サービス要求は、順番に実行されるプレタスク、メイン タスク、およびポストタスクで構成されています。 Service Designer では、メインの AMQP タスクの前後に実行されるプレ タスクおよびポスト タスクを有効または無効にするオプションが提供されます。 メイン タスクのみが、プレ タスクおよびポスト タスクなしで実行できます。 AMQP の詳細については、『Cisco Prime Service Catalog Integration Guide』を参照してください。


            ステップ 1   [Service Designer] > [計画(Plan)] > [タスク(Task)] > [全般(General)] の順に選択します。
            ステップ 2   [ワークフロータイプ(Workflow Type)] として [キューサービスリクエスト(Queue Service Request)] を選択します。
            ステップ 3   タスク名を入力します。
            ステップ 4   計画を保存します。
            ステップ 5   [ワークフロータイプ(Workflow Type)] の横に表示される省略形(...)をクリックします。
            ステップ 6   [キューサービスリクエストパラメータ(Queue Service Request Parameter)] ポップアップで、次の手順を実行します。
            1. プライマリ タスクについては、[トピック(Topic)] フィールドに交換名を入力し、ドロップダウンリストからペイロード タイプを選択します。
            2. (任意)プレ タスクおよびポスト タスクを実行する場合は、[プレタスクの実行(Execute Pre Task)] および [ポストタスクの実行(Execute Post Task)] チェック ボックスを選択します。 これらのタスクをスキップするにはこれらのチェック ボックスをクリアします。
            3. (任意)オートコンプリートするタスクの場合は、[タスクのオートコンプリート(Task Auto Complete)] チェック ボックスを選択します。 タスクが完了すると、次のタスクが自動的に開始されます。
            4. [保存(Save)] をクリックして、タスク定義を保存します。 このオプションを使用すると、サービスがオーダーされたときのみ、タスクのトピックとキューが Rabbit MQ サーバに作成されます。 サービスの定義時に Rabbit MQ サーバでタスクのトピックとキューを作成するには、[作成(Create)] をクリックします。
            (注)      [管理(Administration)] > [設定(Settings)] で選択された AMQP 公開キーが作成されたすべての新しい AMQP タスクにデフォルトで選択されます。

            AMQP タスクの暗号化

            Service Catalog は、公開キーの選択によるあらゆる AMQP タスクの暗号化をサポートしています。 AMQP 公開キーは、セキュアな文字列の形式でデータを暗号化するために使用されます。

            ディクショナリ フィールドでは、「is-secure」属性が true に設定されると、それらのディクショナリ フィールドの値が公開キーを使用してセキュアな文字列に変換されます。 セキュアな文字列の形式は、選択する AMQP セキュアな文字列の形式に基づいています。

            手順


              ステップ 1   [管理(Administration)] > [設定(Settings)] の順に選択します。
              ステップ 2   ドロップダウンリストから AMQP 公開キーを選択し、[新規追加(Add New)] をクリックします。
              ステップ 3   [追加(Add)] をクリックします。
              ステップ 4   公開キーの名前、[モジュラス(Modulus)] フィールドに暗号化データ、および指数値を入力します。

              [名前(Name)]、[モジュラス(Modulus)] および [指数(Exponent)] に指定した値に基づいて、システムは修正/編集できない GUID を生成します。 この GUID は、パスワードおよびトークン用のセキュリティの外部層を追加するために使用されます。

              ステップ 5   [保存(Save)] と [閉じる(Close)] をクリックして、終了します。
              ステップ 6   Service Designer で特定の AMQP タスクのリストから AMQP 公開キーを選択します。
              ステップ 7   ドロップダウンリストから AMQP のセキュアな文字列の形式を選択します。 これによって、セキュアな文字列が選択した形式に暗号化されます。
              ステップ 8   [更新(Update)] をクリックして変更を保存します。

              サービス項目への権限を付与および取り消すためのサービス提供タスクの作成

              サービス提供計画内のグリッド ディクショナリを使用して作成されたサービス項目(複数可)への権限を付与または取り消すためのサービス提供タスクを作成できます。 以前はこれは、REST コールによってのみ可能でした。

              権限の付与/取り消しのためのディクショナリ属性は、次のようにする必要があります。

                • recipentName
                • recipient
                • recipientType
                • オブジェクト
                • objectName
                • スコープ
                • permission
                • instanceName
                • ドメイン
                • ErrorDescription

              API を使用した考えられるフィールド値に対する権限の付与または取り消しの詳細については、『Cisco Prime Service Catalog Adapter Integration Guide』の「Grant and Revoke Permissions API Table」を参照してください。

              NsAPI タスクを作成して SIM 権限を付与するには、次の手順を実行します。


                ステップ 1   [Service Designer] > [計画(Plan)] > [タスク(Task)] > [全般(General)] の順に選択します。
                ステップ 2   [ワークフロータイプ(Workflow Type)] として [NsAPI ] を選択し、タスク名を入力して計画を保存します。
                ステップ 3   [ワークフロータイプ(Workflow Type)] の横に表示される省略形(...)をクリックします。
                ステップ 4   使用するディクショナリと、適用する [NsAPIタスクタイプ(NsAPI Task Type)] を選択します。
                ステップ 5   [OK] をクリックします。

                提供タスクのスケジュールされた開始の作成

                デフォルトで、サービス要求のすべての承認が完了するか、承認がない場合は、サービス要求が送信されるとすぐに、提供計画はアクティブになります(また、サービスの実行者がタスクを時間どおりに完了するかどうかについて、クロックが開始します)。 場合によっては、この動作は好ましくないことがあります。 たとえば、新しい従業員の代わりに数週間以内に作業が開始するようにスケジュールされた要求を入力したり、将来増加するようにスケジュールされたプロジェクト用の新しいサーバを開発チームが要求したりする場合があります。 このような場合、Service Catalog では、指定された開始日に到達するまで実行中(アクティブ)にならない、スケジュールされた開始タスクを作成できます。

                スケジュールされた開始タスクが次のタイミングで実行されるように指定できます。

                • カスタマー、あるいは承認や確認を実行する他の人によってサービス フォームに指定された日時。
                • Service Designer の [計画(Plan)] タブでサービスの設計に指定した固定日時。

                サービス フォームのフィールドを使用して、スケジュールされた開始タスクを作成するには、以下の手順を実行します。


                  ステップ 1   サービス定義で、サービスで使用されているアクティブ フォーム コンポーネントの [フォーム(Form)] タブに移動して、データを保持するディクショナリ フィールド(たとえば、NewHire.StartDate)を見つけます。 フィールドのデータ型は、[日付(Date)] または [日時(Date and Time)] のいずれかにすることができます。
                  ステップ 2   必要に応じて、前のステップで見つけたディクショナリ フィールドを含むアクティブ フォーム コンポーネントに移動します。 [アクセス制御(Access Control)] タブと [表示プロパティ(Display Properties)] タブをクリックして、使用するフィールドに適切なディクショナリ権限と HTML 表現を設定します。
                  ステップ 3   サービスの [計画(Plan)] タブをクリックして、遅延するタスクを特定するか作成します。
                  ステップ 4   タスクの [全般(General)] サブタブで、[スケジュール済み開始日を許可する(Allow a scheduled start date)] をオンにします。
                  ステップ 5   [開始日のフォームデータ(Form data for start date)] フィールドに、タスクの開始点となる日時の保持に使用するディクショナリ フィールドの名前を入力します。 これは、ステップ 1 で見つけたフィールドと同じです。 次の構文を使用します。
                  • Data.DictionaryName.FieldName(サービスのフォーム コンポーネントの 1 つにあるディクショナリからのフィールド用)。

                  • ParentData.DictionaryName.FieldName(親サービスのディクショナリのいずれかからのフィールド用。バンドルされたサービスの場合)。


                  スケジュールされた開始タスクに対するシステムの動作

                  システムは、提供計画タスクごとに、[スケジュール済み開始日(Scheduled Start Date)] と [実際の開始日(Actual Start Date)] の両方を維持します。 これらの日付は、Service Manager のタスク フォームで確認できます。

                  システムは、先行するタスクが完了した後に、スケジュールされた開始タスクを自動的には開始しません。 スケジュールされた開始タスクは、指定された開始点に到達するまで、[スケジュール済み(Scheduled)] ステータスになります。 この時点で、システムはタスク ステータスを [実行中(Ongoing)] に変更し、割り当てられた実行者がタスクを処理できるようになります。 [スケジュールされた開始(Scheduled Start)] および [開始日(Started on)] フィールドは、スケジュールされた開始タスクに対して同じです。

                  スケジュールされた開始タスクの開始点はフォーム データから定義されており、[日付(Date)] フィールドを使用してこの開始点を定義すると、システムはタスクの実行者の就業時間に時間を設定します。 たとえば、タスクが HR グループ キューによって実行される場合に、キューの就業時間が 8:00 から 16:00 である場合、システムはユーザによって入力された日付に 8:00 という時間を設定します。

                  システムは、ワークフロー プロセスのサービス提供フェーズが開始した後、すべての提供計画タスクをスケジュールします。 (サービス提供フェーズは、承認フェーズが完了してから開始します)。

                  システムは、サービス提供フェーズの開始時にすべての提供計画タスクをスケジューリングするまで、スケジュールされた開始タスク用に指定された開始点を評価しません。 これは、開始点が(サービスをオーダーするカスタマーではなく)承認または確認ステップの実行者によって指定される可能性もあることを意味しているため、サービスを設計するときにこれを活用できます。

                  サービス設計者は、スケジュールされた開始タスクの開始点としてカスタマーが何を入力するかを制御できません。 たとえば、カスタマーはサービス内の先行するタスクが完了する前に起こることになる将来の日付を入力する可能性があります。 スケジュールされた開始タスクにカスタマーによって指定された開始日が、(残りの計画に関して)考えられる最も早い開始日より早い場合、システムは指定された開始日を無視して、タスクが遅延タスクではないかのように処理します。 これは、開始日が無視されたことを示すコメントとともにシステム履歴に記録されます。

                  • また、指定された開始日がサービス フォームの必須フィールドでなく、カスタマー/承認者が開始日を指定しない場合、Service Catalog は遅延タスクでないかのようにタスクを扱います。

                  タスク参加者の定義


                    ステップ 1   [Service Designer] > [サービス(Services)] > [計画(Plan)] > [タスク(Tasks)] > [参加者(Participants)] の順に選択します。
                    ステップ 2   タスクを完了する人と、オプションで作業の監視方法を指定します。 詳細については、タスク参加者を定義するためのフィールドを参照してください。
                    ステップ 3   このタブの変更を保存するには、[保存(Save)] をクリックします。

                    表 6 タスク参加者を定義するためのフィールド

                    フィールド

                    説明

                    役割(Role)

                    タスクの実行者のロール:タスク実行者は、タスクが割り当てられた人、キュー、または職位です。

                    タスク スーパーバイザのロール:タスク スーパーバイザは、タスク パフォーマンスの制御の基準を提供します。 管理設定 [タスクスーパーバイザがタスクを取り消すのを許可する(Allow Task Supervisor to cancel task)] と組み合わされると、指定した人、キュー、または役職がタスクを取り消せる(スキップできる)ようになります。

                    名前(Name)

                    実行者ロールの名前であり、タスクを実行するエンティティを意味します。 この名前は、[計画(Plan)] タブのタスク リストにある [/(By)] 列に表示されます。

                    または/および

                    スーパーバイザ ロールにある人の名前。タスクを実行したり、サービスを提供したりする人のスーパーバイザを意味します。

                    割り当て(Assign)

                    次のように、タスクの実行者/スーパーバイザの割り当て方法を選択します。

                    • [役職から(From a position)]:Organization Designer に定義されている役職を現在満たしている人。
                    • [個人/キュー(A person/queue)]:Organization Designer に定義されている人またはキュー。
                    • [式から(From an expression)]:[割り当て先(Assign to)] フィールドに表示される条件式。
                    • なし。

                    割り当て先(Assign to)

                    式に基づくロール ベースの割り当て

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

                    実行者、スーパーバイザ、およびプロジェクト マネージャのロールは、すべて動的に割り当てることができます。

                    • [役職から(From a position)] または [個人/キュー(A person/queue)] を選択した場合、[…] ボタンをクリックすると、タスクの割り当て先を選択するための選択ダイアログボックスが表示されます。 [追加(Add)] または [OK] をクリックして、選択内容を保存します。
                    • [式から(From an expression)] を選択した場合、[…] ボタンをクリックすると、タスクの割り当て用に評価される式を入力するための [式の編集(Edit Expression)] ダイアログボックスが表示されます。 [式の設定(Set Expression)] をクリックして、選択内容を保存します。

                    提供タスクの電子メール通知の定義

                    各タスクには複数のイベントが関連付けられています。 電子メールを各イベントに関連付けることで、サービスのカスタマー、タスクの実行者、または要求の現在のステータスの他のグループまたは個人に通知できます。

                    どのイベントにどの通知を送信するかを指定するには、[Service Designer] > [サービス(Services)] > [計画(Plan)] > [タスク(Tasks)] > [電子メール(Email)] サブタブを選択します。 通知は、管理モジュールの通知コンポーネントを使用して定義する必要があります。 Service Catalog にはいくつかのデフォルト電子メール テンプレートが出荷時に付属していますが、大部分のサイトでは、カスタム通知を設計するほうが好まれます。

                    提供計画のタスクごとに(および承認または確認ごとに)、設計者はタスクで使用されるエスカレーション構造内の層の数を選択できます。

                    たとえば、次のように 3 つのエスカレーション層を設定できます。

                    • 層 1:タスクが遅延した時点から 1 時間
                    • 層 2:層 1 の後 8 時間
                    • 層 3:層 2 の後 16 時間

                    [最大層(Maximum Tier)] の設定によって、最初の層から開始して、いくつのエスカレーション層が特定のタスクによって使用されるかが決まります。

                    • [エスカレーションにあるものすべて(As much as there are in escalations)] の場合は、すべての層
                    • [次のように指定(Specified As)] の場合は、このタスクに使用する層の数。層の数以下の任意の数が定義されます。

                    この場合、たとえば、最大層が 2 として指定されている場合、タスクが遅延した時点から 1 時間後と 9 時間後に通知が送信され、3 つ目の層のエスカレーションは適用されません。

                    タスクの指示の追加

                    タスクのに指示を与えたり、タスクの指示に関連する URL へのリンクを設定するには、[Service Designer] > [サービス(Services)] > [計画(Plan)] > [タスク(Tasks)] > [タスクの指示(Task Instructions)] サブタブを選択します。

                    表 7 [タスクの指示(Task Instruction)] サブタブのフィールド

                    フィールド

                    説明

                    URL

                    リンク先の URL を「http://」で始まる完全な URL で入力します。

                    URLの説明(URL Description)

                    ユーザが URL にリンクしたり、HTML をチェックリスト項目に組み込んだりした場合に表示される内容の簡単な説明を入力します。

                    次に例を示します。

                    タスクの実行方法の詳細については、<a href=”URL">ここをクリック</a>してください。

                    タスクの指示(Task Instructions)

                    このテキスト フィールドを使用して、必要に応じてタスク指示を入力します。

                    HTML エディタを使用して、HTML を [URLの説明(URL Description)] フィールドと [タスクの指示(Task Instructions)] フィールドに組み込みます。

                    タスクを完了するためのチェックリストの作成

                    チェックリストを使用して、リマインダのリストを作成したり、タスクを完了するための特定の手順を詳細化したりできます。 これらは、Service Manager にチェックリストとして表示され、作業を完了するための手順が詳細化されます。 チェックリストは実行期日に影響を及ぼしません。また、レポート機能はありません。


                      ステップ 1   [Service Designer] > [サービス(Services)] > [計画(Plan)] > [タスク(Tasks)] > [チェックリスト(Checklists)] の順に選択します。
                      ステップ 2   [新規追加(Add New)] をクリックし、右側の [項目プロパティ(Item Properties)] ボックスにチェックリスト項目を入力することで、新しい項目をリストに追加します。
                      ステップ 3   さらにチェックリストを設定するには、[チェックリスト(Checklists)] タブのフィールドの表を使用します。

                      表 8 [チェックリスト(Checklists)] タブのフィールド

                      フィールド

                      説明

                      項目

                      実行者に Service Manager で表示されるチェックリストは、このリストの項目で構成されます。

                      またはの矢印を使用して、項目の順番を再配置します。 最上部の項目を最初に実行する必要があります。

                      名前(Name)

                      チェックリスト項目の名前を入力します。

                      チェックリスト項目をタスクの完了のための必須項目にする(Make checklist items mandatory for task completion)

                      このオプションをオンにすると、タスクを完了するにはすべての項目が必須になります。 つまり、タスクを実行する人は、Service Manager でチェックリストのすべての項目をチェックするまで、タスクの作業を終了できなくなります。

                      遅延タスクに関するエスカレーション電子メールの設定

                      [計画(Plan)] > [エスカレーション(Escalations)] サブタブを使用して、アクティビティが遅延したときに、実行者、スーパーバイザ、およびカスタマーに送信される電子メール通知を指定できます。

                      エスカレーション階層を定義するには、次の手順を実行します。


                        ステップ 1   [Service Designer] > [計画(Plan)] > [エスカレーション(Escalations)] の順に選択します。
                        ステップ 2   [追加(Add)] をクリックします。
                        ステップ 3   [後(時間)(After (hours))] チェックボックスを選択して、アクティビティがトリガーされた後にアプリケーションがエスカレーション電子メールを送信するために必要な時間を定義します。
                        ステップ 4   受信者の電子メール アドレスを入力します。
                        ステップ 5   ドロップダウン リストからアクティビティを選択します。
                        ステップ 6   上記の手順を実行し、シーケンシャル アクティビティ用のエスカレーションを設定します。

                        サービス提供ワークフローの設計

                        Service Catalog には、提供計画を構成するタスクのワークフローを設計するための、2 つの方法が用意されています。

                        • [計画(Plan)] タブの中央にある [タスク(Task)] 領域を使用してタスクを入力し、さらに、使用可能なボタン([インデント(Indent)]、[インデント解除(Outdent)]、[アップ(Up)]、[ダウン(Down)])を使用してワークフローを設定することで、タスクが正しい順番で実行され、正しくグループ化されるようにします。
                        • [Graphical Designer] タブから使用できる Graphical Workflow Designer を使用して、タスク、コネクタ、およびサブタスクのグループを描画領域にドラッグ アンド ドロップすることで、ワークフローを描画します。

                        図は、タスクおよびサブタスクとそれらの関係を示します。 この図は、提供計画、実行される順序、および実行が順次または同時形式かを示しています。

                        ワークフローはいずれかのツールを使用して設定できます。実際に、サービス設計者は Graphical Designer と、[タスク(Task)] タブによって提供されるダイアログボックスの間を切り替えながら行き来できます。 Graphical Designer にはタスク用のワークフローが備わっており、そのプロパティ シートを使用することで、ユーザはタスクに関する大部分の一般情報と、実行者のロールを入力できます。 タスクの実行に関連付けられた電子メール、チェックリスト、およびタスクの参加者など、個々のタスクの詳細は、[計画(Plan)] タブのサブタブを使用して入力する必要があります。



                        .

                        Graphical Workflow Designer について

                        Graphical Workflow Designer を使用して、サービス設計者はタスクのドラッグ アンド ドロップ、命名、接続を行えます。 Graphical Designer には、タスク間で親/子関係を定義する機能も備わっています。 付属のタスク プロパティ シートを使用して、タスク定義と実行に関する詳細をさらに指定できます。

                        Graphical Designer には、提供計画の [全般(General)] タブで提供されているダイアログボックスを使用することで、サービスの提供計画を設計するための、ビジュアル指向の代替策が用意されています。 設計者はタスクを定義して、いずれかの方法でそれらの間のワークフローを指定し、Graphical Designer とダイアログボックスの間を自由に切り替えて行き来することができます。

                        Graphical Designer には、提供計画の簡略ビューがあります。 計画についてさらに詳細に設定するには([参加者(Participants)]、[電子メール(email)]、[タスクの指示(Task Instructions)]、および[チェックリスト(Checklist)] サブ タブで使用可能なものを設定するには)、[計画(Plan)] タブに切り替えます。 詳細については、提供タスクの設定を参照してください。

                        [Graphical Designer] ペインには、以下のセクションがあります。

                        図 2. [Graphical Designer] ペイン

                        [1]

                        [ツール(Tools)] ペイン

                        4

                        [アウトライン(Outline)] ペイン

                        2

                        ツールバー

                        5

                        表示ツール

                        3

                        作業領域

                        • 左上の [ツール(Tools)] ペインには、Workflow Designer の構成要素が含まれています。 これらの構成要素を作業領域にドラッグ アンド ドロップして接続し、完全なワークフローを作成できます。
                        • ツールバーには、提供計画の保存、計画の印刷、および作業領域のコンテンツの操作を行うためのボタンが含まれています。

                        (注)  


                        凡例には、ワークフロー図に含まれているオブジェクトを表すために使用されるカラー コーディングがリストされます。
                        • 作業領域には、ワークフロー図が含まれています。 新しい提供計画のために Designer が呼び出されると、計画の開始を示す明るい緑色の円を除き、作業領域はブランクになります。
                        • ページの左側の中央にある[アウトライン(Outline)] ペインには、図の大まかな概要が示されます。
                        • 表示ツール: [ズーム(Zoom)]/[レイアウト(Layout)] ボタンを使用して、設計者は、ワークフロー図のサイズを拡大または縮小したり、図の方向を変えたりすることができます。

                        [ツール(Tools)] ペインについて

                        [ツール(Tools)] ペインには、ワークフローを構成するオブジェクトの基本タイプを図に追加するためのツールが含まれています。

                        表 9 [ツール(Tools)] ペイン

                        オプション

                        説明



                        ワークフローは、一連のタスクが順番に配置されて構成されています。 [タスク(Task)] ツールを使用して、タスクをワークフローに追加します。



                        タスクは、親タスクに対する子タスクとしてグループ化できます。



                        [関連付け(Associate)] ツールを使用して、タスクの順番を指定し、親と子のタスクを関連付けます。

                        [ツール(Tools)] ペインのオプションに加えて、コンテキスト依存型のタスク カーソルを使用して、図の内容を操作することができます。 図に以前に配置したタスクの上にカーソルを合わせると、カーソルの形が変わり、どのアクションが使用可能であるかが示されます。

                        表 10 カーソル

                        カーソル

                        説明



                        オブジェクトを一度選択したら、選択カーソルが表示されます。 選択カーソルでマークが付けられたオブジェクトはすべて、次の [コピー(Copy)]、[移動(Move)]、または [削除(Delete)] コマンドの影響を受けます。



                        接続カーソルは、強調表示したタスクと別のタスクを関連付けることができます。 接続カーソルが表示されている状態で、現在のタスクに接続するタスクにマウスをドラッグします。 マウスを放すと、タスクの順序(関連付け)が確立されます。

                        Graphical Designer を使用した提供計画の作成

                        Graphical Designer を使用して提供計画を作成するには、Service Designer でサービスを編集し、[計画(Plan)] タブをクリックしてから、[Graphical Workflow] サブタブをクリックします。 作業領域は、「ワークフローの開始(Start Workflow)」アイコンを除き空白で表示されます。

                        図 3. ワークフローの開始


                          ステップ 1   タスクを定義します。
                          1. 通常、最初のステップはタスクをワークフローに置くことです。 ([ツール(Tool)] パネルから)[タスク(Task)] ツールをクリックし、それを作業領域までドラッグします。 タスクが表示されます。 タスクをダブルクリックして、作業領域の下部に [タスクプロパティ(Task Properties)] ダイアログボックスを表示します。
                            図 4. [タスクプロパティ(Task Properties)]:黄色のアラート アイコン

                            [タスクプロパティ(Task Properties)] ウィンドウには、タスクの [全般(General)] サブタブに表示されるすべてのデータと、主に設計セッションで役立つ実行者のロール名が含まれています。 ここに表示されているフィールドの詳細については、提供計画でのサービス項目タスクの定義を参照してください。

                          2. ここでタスクのワークフローの定義を開始しますが、タスク定義を完了するには、タスクごとに [計画(Plan)] タブのサブタブを使用する必要があります。

                            タスク定義の重要な側面は、[タスク名(Task Name)] を割り当てて、[ワークフロータイプ(Workflow Type)] を選択することです。 新しい「内部」タスク(すべてが Service Manager 内で実行されるタスク)を作成し、以前に定義されたサービス タスク(Service Link エージェントを介して指定された外部タスク)を指定するか、サービス項目タスク(Service Item Manager を介して指定されるサービス項目を作成、更新、または削除するタスク)がワークフローに組み込まれるように設定できます。

                          3. [タスクプロパティ(Task Properties)] ダイアログボックスから図に戻るとすぐに、タスク名が表示され、図の [タスク(Task)] アイコンがワークフロー タイプを反映して変わる場合があります。 タスクをダブルクリックすることで、いつでも [タスクプロパティ(Task Properties)] ダイアログボックスに戻ることができます。
                          ステップ 2   ワークフローの指定
                          1. 黄色のアラート アイコンは、現在の状態の図が無効であるということを警告します([タスクプロパティ(Task Properties)]:黄色のアラート アイコン)。 アラート アイコンにポインタを合わせることで問題の詳細を確認できますが、[タスクプロパティ(Task Properties)]:黄色のアラート アイコンでは、タスクを「ワークフローの開始(Start Workflow)」アイコンに関連付け、ワークフロー内の適当なシーケンスに割り当てる必要があることが明白です。
                          2. ワークフロー内にタスクを配置するには、[関連付け(Associate)] ツールをクリックします。 次に、ワークフロー内の最初の項目(この場合は [ワークフローの開始(Start Workflow)] アイコン)をクリックして、次の項目(この場合は、図内の最初で唯一のタスク)までマウスでドラッグします。 マウスを放すと、図に矢印が追加され、[ワークフローの開始(Start Workflow)] からワークフロー内の最初のタスクまでのフローが表示されます。
                            図 5. ワークフローの開始

                          3. タスクを接続するより簡単な方法は、接続カーソルを使用することです。
                              • 別のタスクを図に追加し、必要であれば、それに名前を付けます(たとえば、「Pull Memory」など)。 このタスクは、ワークフロー内で「インベントリのチェック」の後、次に来るタスクです。
                              • この順番でタスクを関連付けるには、最初のタスク(インベントリのチェック)の真ん中に接続カーソルが表示されるまでカーソルを動かします。
                              • 2 番目のタスクまでマウスをドラッグします。 タスクとターゲット タスクの間に太い点線が表示され、ターゲット タスクが太い実線で強調表示されます。 選択カーソルが 2 番目のタスクに表示されます。
                              • マウスを放します。 関連付けが描画され、図は有効になります。
                            図 6. フロー図

                          ステップ 3   親タスクおよびサブタスクを作成します。

                          タスクはいくつかの理由でグループ化することができます。 次に例を示します。

                          一部のタスクは条件付きであり、特定のタスクが実行されているかどうかに関係なく、連続するタスク内の最初のタスクと最後のタスクが完了したら、電子メール通知を送信したい場合があります。

                          タスクは 2 番目のタスクと同時に実行される必要があります。 サービスの Service Level Agreement(SLA)を算出する際に、両方のタスクをカウントするのではなく、より長く時間がかかった方のみをカウントしたい場合があります。

                          これらのシナリオや他のシナリオに対応するために、Service Catalog はタスクのグループ化をサポートしています。 親タスクには、1 つ以上の子またはサブタスクがあります。 サブタスクは、順次または同時のいずれかで実行できます。

                          1. [サブタスクの開始(Start Subtasks)] アイコンを適切な順番で作業領域までドラッグします。
                          2. タスク アイコンを [サブタスクの開始(Start Subtasks)] アイコンの下にある作業領域までドラッグします。 必要に応じて、タスクを定義します。
                          3. タスクが同時に実行されることを示すには、接続カーソル(カーソル ハンドル付き)が表示されるまで、カーソルを [サブタスクの開始(Start Subtasks)] アイコンの真ん中まで動かした後、各サブタスクまでマウスをドラッグします。 以下の左側の図のように、それぞれが [サブタスクの開始(Start Subtasks)] に接続されます。
                          4. タスクが順次に実行されることを示すには、接続カーソルを使用して、[サブタスクの開始(Start Subtasks)] アイコンを最初のタスクに接続します。 次に、最初のサブタスクを次のサブタスクに接続します。 その結果、図は以下の右側の例のようになります。
                            図 7. タスクの図



                          ステップ 4   ワークフローの保存

                          有効なワークフローしか保存できません。 図に何らかのアラート アイコンが表示されている場合、ワークフローは有効ではないことを示しています。 アラート アイコンの上にカーソルを合わせて、問題の詳細説明を取得できます。多くの場合、図のエレメントがお互いに適切に接続されていないことが原因です。 エラーを修正したら、もう一度 [保存(Save)] をクリックして、ワークフローを保存します。

                          Graphical Designer または [計画(Plan)] タブ ダイアログボックスのどちらを使用しても、Service Catalog は完全に同じ方法でワークフローを保存します。 この方法は、最も使いやすいツールをどれでも使用できるという点で優れています。 ただし、Service Catalog は図自体を保存しません。以前に保存した提供計画からそれを再構築した後、図で作業を続けながらその提供計画に追加します。 印刷用にワークフローの外観をカスタマイズできます。たとえば、より長い説明を表示するために、タスクを移動したり、タスク アイコンのサイズを大きくしたりします。 ただし、図を保存するときに、そのような変更はすべて除去され、ワークフローはデフォルトのレイアウトに戻されます(水平または垂直)。

                          ステップ 5   図の印刷

                          図を印刷するには、ツールバーから [印刷(Print)] オプションをクリックします。 印刷に適したバージョンでは、スケールや方向など、現在の図の表示が反映されます。 必要に応じて、図を複数のページに広げることができます。 図を印刷するには、標準ブラウザの [ファイル(File)] > [印刷(Print)] コマンドを使用します。

                          手動で図を変更できます。たとえば、個々のタスク アイコンのサイズを変更できます。 そのような変更が行われると、変更は印刷に適したバージョンで反映されます。 ただし、そのような変更はすべて一時的なものであり、ワークフローを保存しても、保存されません。


                          Graphical Designer と [計画(Plan)] タブの比較

                          [計画(Plan)] タブのダイアログボックスを使用するよりも Graphical Designer のほうがより効率的な場合があります。 たとえば、タスクの順番を変更する場合は、データの行を上下に動かすよりかなり簡単に、Designer で単にタスクを別のタスクに再接続するだけで行えます。

                          Graphical Designer には、図を印刷するためのオプションが含まれています。 印刷したバージョンを、Catalog Deployer で使用可能なサービス プレビュー(これには、テキスト フォーマットで詳細なワークフローが含まれます)と比較して、どちらの方がニーズに合致しているかを確認する必要があります。 おそらく、ユーザ表記では印刷された図が必要で、開発者文書の場合は Catalog Deployer プレビューのほうが適しているでしょう。

                          一般タスク プロパティを指定する場合、設計者は [計画(Plan)] タブまたは Graphical Designer のいずれかを使用できます。 同じプロパティの大部分が Graphical Designer の [タスクプロパティ(Task Properties)] シートと、タスクの [全般(General)] サブタブの両方に表示されます。 ただし、[全般(General)] サブタブ ダイアログボックスには次の利点があります。

                          • スケジュール設定された開始日の条件式とフォーム データを両方の場所に入力できますが、[全般(General)] サブタブ ダイアログボックスに対してのみ、入力した式または名前空間を検証するオプションを入れることができます。 通常、設計時に検証することは、フォームをテストしたときに始めてエラーを発見するより、望ましいことです。
                          • サブタスクを [サブタスクの開始(Start Subtask)] アイコンに接続する方法によって、親タスクが「サブタスクが順次に実行される」と「サブタスクが同時に実行される」のどちらで定義されているかが決定されます。 [全般(General)] サブタブで親タスク定義の「トップレベルタスクの実行」属性を単に変更するほうが、図ですべてのサブタスクを再接続するより、かなり簡単に行えます。

                          いつでも [計画(Plan)] タブ ダイアログボックスを使用して、提供計画の定義を完成させ、参加者、タスク指示、電子メール通知、およびタスクのチェックリストを必要に応じて指定できます。

                          通常、タスクは特定の人には割り当てられず、キューまたは役職に割り当てられます。 このようにすると、複数の人がそのタスクで作業できるため、1 人が作業できなくてもタスクの遅延が生じません。

                          承認の設定

                          [承認(Authorizations)] タブを使用して、サービスの承認、確認、およびエスカレーション タスクを設定し、それらを実行する順番を指定します。 サービスに対する遅延した承認/確認タスクについてのエスカレーション層、受信者、および電子メール メッセージをカスタマイズすることもできます。

                          サービスごとに、以下の 3 つのオプションから選択できます。

                          • [サービスグループの承認構造のみを使用(Use service group authorization structure only)]:サービスはサービス グループに定義された承認構造を継承します([管理(Administration)] > [承認(Authorizations)] で指定)。追加設定は必要ありません。 詳細については、『Cisco Prime Service Catalog Administration and Operations Guide』の「Site Administration」の章を参照してください。
                          • [サービスレベルの承認構造のみを使用(サービスグループレベルは使用しない)(Use service-level authorization structure only (will not use service group-level))]:サービス グループ用に定義されている承認は無視されます。 サービス用に設定された承認のみが適用されます。
                          • [サービスグループレベルとサービスレベル両方の承認構造を使用(Use both service group-level and service -level authorization structures)]:サービス グループ用に定義された承認構造を受け入れ、サービスごとにカスタマイズされたスキームでそれを補足できます。

                          ここでは、次のトピックについて取り上げます。

                          承認タイプ

                          [承認(Authorizations)] および [確認(Reviews)] サブタブでは、サービスを承認または確認する人を決定します。 固有のロールを設定して、それらのロールが要求を確認および承認する順番を定義できます。

                          • [承認(Authorizations)] は、サービスを要求している人に、その要求を受ける資格があるかどうかを判別するための機会を承認者に提供します。 承認が拒否されると、プロセスは停止し、サービスは提供されません。 複数の承認が定義されている場合、指定された順番で順次に実行されます。前の承認が認められるまで、次の承認は開始できません。
                          • [確認(Reviews)] は情報に対してのみです。 確認者はサービスを拒否したり、提供プロセスを取り消したりすることはできません。サービスを確認したことを示すのみです。 複数の確認が指定されている場合、それらは同時に実行されます。 ただし、すべての確認が完了するまで、提供プロセスは開始されません。

                          (注)  


                          選択する承認タイプに基づいて、[承認-順次プロセス(Authorizations – Sequential Process)] または [確認-同時プロセス(Reviews – Concurrent Process)] サブタブが表示されます。
                          • 各行の右側にある上下の矢印ボタンを使用して、承認プロセスでロールを上または下に移動できます。
                          承認、確認、エスカレーション タスクの設定

                            ステップ 1   [Service Designer] > [サービス(Services)] > [承認(Authorization)] の順に選択します。
                            ステップ 2   承認構造と承認タイプを選択します。
                            ステップ 3   [確認-同時プロセス(Review-Concurrent Process)] を選択し、確認プロセスを定義します。 承認ロールの [名前(Name)] フィールドの左側にあるチェック ボックスを選択します。 確認またはエスカレーションを追加するには、適切な [確認-同時プロセス(review- Concurrent Process)] または [エスカレーション-同時プロセス(escalation- Concurrent process)] を選択し、[追加(Add)] をクリックします。

                            確認またはエスカレーションを更新するには、[名前(Name)] フィールドの左にあるチェック ボックスをオンにすることで、以前に定義した承認/確認ロールを選択します。

                            ステップ 4   レビュー テーブルのフィールドを使用して、詳細を追加または更新します。
                            ステップ 5   必要に応じて、[保存(Save)] または [更新(Update)] をクリックします。

                            表 11 レビュー テーブルのフィールド

                            フィールド

                            定義

                            名前(Name)

                            承認ロールに設定された名前。

                            このロール名は、アプリケーションの他の場所では表示されません。

                            件名(Subject)

                            このロールが実行する承認/確認タスクのタイトル。 ここへのエントリは、承認者および確認者に My Services で表示される [自分の承認(My Authorizations)] ポートレットに表示されます。

                            時間(Duration)

                            確認または承認を実行するためのパブリッシュされた合計時間(時間単位)。 このフィールドでは、承認に実際にかかる合計時間に任意の時間を追加できます。

                            たとえば、設定中のサービス グループにおける承認に 0.5 時間かかると見積もります。 しかし、My Services に表示される「公式の」見積もり時間に、いくらかの時間を追加したいと考えます。 そのため、このフィールドに 1.0 時間を入力して、[実行(Effort)] フィールドには 0.5 時間を入力します。

                            実行(Effort)

                            この承認に実際にかかると予測される合計時間。

                            割り当て(Assign)

                            デフォルトの確認者/承認者を次から割り当てるためのオプション。

                            • [役職から(From a position)]:ある役職にある人。
                            • [個人/キュー(A person/queue)]:特定の人またはキュー。
                            • [式から(From an expression)]:[割り当て先(Assign to)] フィールドに表示される条件式。

                            割り当て先(Assign To)

                            [割り当て(Assign)] フィールドで選択した内容に従って、特定の人、キュー、役職のタイトル、または条件式。

                            [...] ボタンを使用して、特定の人または役職を選択するか、式を直接このフィールドに入力します。

                            ワークフロータイプ(Workflow Type)

                            [ワークフロータイプ(Workflow Type)] ドロップダウンのデフォルト設定は [内部(Internal)] であり、これはタスクがユーザによって手動で実行されることを意味します。 サードパーティ製システムで外部タスクとして実行されるようにタスクを設定するには、ドロップダウンリストを使用して、このリストから該当するアクションを選択します(Service Link とともに使用するための認証の設定を参照)。

                            エスカレーション階層(Escalation Tiers)(オプション ボタン)

                            [エスカレーション(Escalations)] サブタブでの層の選択肢(遅延タスクに関するエスカレーション電子メールの設定を参照)。

                            • すべて使用(Use all)

                            [エスカレーション(Escalations)] サブタブに設定されたすべてのエスカレーションが使用されることを示します。

                            • 使用を限定(Use only)(数字(X)に 0 から 99 までの数字を入力します)

                            [エスカレーション(Escalations)] サブタブに設定されたエスカレーションの X 個の層が使用されることを示します。

                            たとえば、3 つの層を持つエスカレーションで [エスカレーション(Escalations)] タブを設定し、最初のオプションを選択した場合、アクティビティが遅れると 3 つすべての層が実装されます。 2 番目のオプションを選択して、数字に 1 を指定した場合、アクティビティが遅れると、3 つの中の最初の層のみが実装されます。

                            条件

                            確認を実行するために満たす必要のある条件を含む式を入力します。

                            たとえば、ActualCost<=1000 と入力した場合、実コストが 1000 ドル以下のものが、選択した承認ロールによって自動的に承認されます。 条件式の作成の詳細については、条件文の構文を参照してください。

                            [検証(Validate)] をクリックして、式が正しいことを確認します。 Service Designer は、式の構文が正しいか、エラーを含んでいるかを示します。 これは構文上のチェックのみであることに注意してください。検証機能は、参照したデータが実際にシステム データベース内にあるかを確認しません。

                            承認フェーズが開始されたときに条件を評価する(Evaluate condition when authorization phase starts)(オプション ボタン)

                            [条件(Condition)] フィールドに設定された条件は、確認フェーズが開始するとすぐにアクティブになります。

                            タスクがアクティブになったときに条件を評価する(Evaluate condition when task becomes active)(オプション ボタン)

                            [条件(Condition)] フィールドに設定された条件は、確認フェーズが完了し、アクティビティ フェーズが始まるとアクティブになります。

                            承認/確認を続行するときに式を再評価する(Re-evaluate expressions as authorizations/reviews proceed)(チェックボックス)

                            各承認/確認タスクの後に、タスクの参加者とタイトルの割り当てを行うための式を再評価するようにシステムを設定します。 これは、参加者またはタスク タイトルの式がタスクを開始した後に変更された場合に便利です。

                            承認/確認が開始されたときに通知する(Notify when authorization/review starts)

                            確認プロセスが開始したときに自動的に送信される電子メール テンプレート。または、[なし(none)] を選択します。

                            承認/確認が完了したときに通知する(Notify when authorization/review completes)

                            確認が完了したときに自動的に送信される電子メール テンプレート。または、[なし(none)] を選択します。

                            アクティビティが取り消されたときに通知する(Notify when activity is cancelled)

                            要求者がアクティビティを取り消したときに自動的に送信される電子メール テンプレート。または、[なし(none)] を選択します。

                            アクティビティが拒否されたときに通知する(Notify when activity is rejected)(承認のみ)

                            承認者がアクティビティを拒否したときに自動的に送信される電子メール テンプレート。または、[なし(none)] を選択します。

                            タスクが再度スケジュール設定されたときに通知する(Notify when task is rescheduled)

                            タスクが再度スケジュール設定されたときに自動的に送信される電子メール テンプレート。または、[なし(none)] を選択します。

                            タスクが再割り当てされたときに通知する(Notify when task is reassigned)

                            タスクが再割り当てされた場合に自動的に送信される電子メール テンプレート。

                            外部タスクが失敗したときに通知する(Notify when external tasks fail)

                            外部タスクが失敗したときに自動的に送信される電子メール テンプレート。

                            サイト承認スキームの使用

                            管理モジュールの [承認(Authorizations)] タブに設定されているように、サイト承認スキームを使用できます。 これはデフォルト設定であり、多くの場合、実装が最も簡単です。 詳細については、『Cisco Prime Service Catalog Administration and Operations Guide』の「Site Administration」の章を参照してください。

                            「管理モジュール経由で現在有効になっていません(not currently enabled via the Administration module)」というメッセージが表示された場合は、特定のサービスの承認/確認がサイトで有効になっていません。 これは、管理モジュールで変更できます。

                            Service Link とともに使用するための認証の設定

                            ビジネス プロセスで、この製品以外のシステムを介して承認を実行する必要がある場合、Service Link を使用して、その外部システムによって承認タスクが実行されるようにすることができます。 外部タスクとその処理方法を定義するために必要な設定は、ロールの [詳細(Details)] 画面にある [承認(Authorization)] タブに表示されます。

                            1. [ワークフロータイプ(Workflow Type)] ドロップダウン メニューのデフォルト設定は [内部(Internal)] であり、これはタスクがユーザによって手動で実行されることを意味します。 サードパーティ製システムの外部タスクとして実行されるようにタスクを設定するには、ドロップダウンリストを使用して、このリストから該当するアクションを選択します。
                            2. 何らかの理由で、サードパーティ製アプリケーションが承認タスクを正常に完了しなかった場合、このタスクの Service Link 統合で問題が生じたことを管理者に通知できます。 [外部タスクが失敗したときに通知する(Notify when external tasks fail)] メニューで、そのような通知を送信するテンプレートを選択できます。 電子メール通知については、提供タスクの電子メール通知の定義を参照してください。
                            3. Service Link モジュールに対する適切な許可を持っている場合、[ワークフロータイプ(Workflow Type)] ドロップダウン メニューの右側に省略(...)ボタンが表示されます。 このボタンをクリックすると、[タスクデータのマッピング(Task Data Mapping)] ダイアログボックスが表示されます。

                            このダイアログボックスには、外部システムに送信されたデータがサービス オーダー フォーム上のデータ、またはシステム内の任意の場所にどのようにマップされるかを示す設定が含まれます。 これらの設定を変更する許可を持っている場合、ダイアログボックスは編集可能になります。 そうでない場合は読み取り専用です。

                            これで、エスカレーション電子メールを設定する準備が整いました。 詳細については、遅延タスクに関するエスカレーション電子メールの設定を参照してください。