4.3.3 通知の設計

Ops Iの通知機能には、ワークフローやスケジュール・作業項目の作成、変更または削除が行われたときに通知する方法(以下、「イベントによる通知」)と、ワークフローの定義で任意のタイミングで通知を行う方法(以下、「ワークフローからの通知」)があります。
通知の設計は、NotificationとNotifierの2つのタイプのYAML定義を行います。

(表)通知の設計項目と概要

項目 定義手段 設計のポイント
・Notification
・Notifier
YAMLファイル ワークフローのステップごとに通知する担当者の割り当てや、申請完了時の申請者への通知を設定します。またスケジュールごとに通知する担当者の割り当てや設定をします。通知手段はGUIまたはメールで行います。

【イベントによる通知】

(図)Notification、Notifierの概念図(イベントによる通知)

(図)Notification、Notifierの概念図(イベントによる通知) (図)Notification、Notifierの概念図(イベントによる通知)

Ops Iではワークフローやスケジュール・作業項目を起点とした通知設定を定義できます。ここで起点とは、通知が行われるきっかけになるイベントを指します。YAMLファイルに通知を送るイベントの条件やメッセージ、宛先や送信手段などを定義することで、ユーザーが実行したいアクティビティの担当者に通知を送ったり、申請者が申請受理/完了の報告を受けたりできます。
ワークフローを起点とした通知については「ワークフローを起点にした場合の通知」を参照してください。

また、スケジュールの開始や完了の通知を送ったり、作業項目の更新によって通知を送ったりすることができます。
スケジュールが予定表に属している場合は、予定表の担当グループに所属するユーザーを宛先にしたり、予定表に関連したスケジュールに限定したりできます。その場合予定表の情報から通知の本文、タイトル、リンクを定義できます。
スケジュール・作業項目を起点とした通知については「スケジュール・作業項目を起点にした場合の通知」を参照してください。

【ワークフローからの通知】

ワークフローの中で通知を行いたいタイミングの位置に通知のタスクを追加します。ワークフローの任意のタイミングで通知を行いたい場合は、こちらの方法を使用します。


(1)通知の流れ

イベントによる通知と、ワークフローからの通知のいずれの場合にも、事前にNotificationのYAMLファイルに、以下のラベルの設定が必要です。

  • event.resource:通知の監視対象のリソース(作成、更新など)
  • event.type:イベント(作成、更新など)のタイプ
  • conditions:通知する条件。"type"が"onDemand"の場合は設定が不要です。

【イベントによる通知】

"type"が"onDemand"以外で、eventで設定した対象がconditionsで設定した条件を満たすと、通知の送信元は通知オブジェクトを作成し、宛先に通知します。通知条件の例とそれらのYAMLの定義例は「スケジュール・作業項目起点の通知例」を参照してください。

【ワークフローからの通知】

"type"が"onDemand"で、conditionsの設定は行わず、Ops I提供部品「oi.notify」を使います。ワークフローで指定したタイミングで通知を行い、WorkflowのYAMLファイルで定義したパラメータを埋め込めます。YAMLの定義例は「通知を含めたワークフローの定義例」を参照してください。

通知オブジェクトとは、通知の宛先や、通知の送信手段、通知メッセージの情報を表し、NotificationのYAMLファイルのラベル「notifications」で設定します。通知の宛先は、Ops Iのユーザー、またはグループへの通知が選択できます。
通知の手段はNotifierのYAMLファイルによって管理されます。Ops IのGUIでの通知に加え、メールでの通知をすることもできます。
.GetValueを使用する場合、resourceに指定したリソースが起点となります。使用できる値は「(表)Notificationで使用可能なオブジェクト・フィールド」を参照してください。

宛先は、scheduleオブジェクトのassignedToに申請者などを設定することで指定できます。scheduleオブジェクトについては「(表)Notificationで使用可能なオブジェクト・フィールド」を参照してください。
どのイベントに通知設定をしたかは、ワークフローやスケジュールのGUI上ではわからないため、必要に応じて通知の定義をしたユーザーから関係者に周知する必要があります。

(図)通知の流れ

(図)通知の流れ (図)通知の流れ

NotificationとNotifierのYAML定義の詳細については「Notification、Notifier」を参照してください。



(2)スケジュール・作業項目を起点にした場合の通知

スケジュール機能には、予定表、予定表にひもづく作業項目、作業項目にひもづく個々のスケジュールや、ユーザーにひもづくスケジュールがあります。本機能では、作業項目とスケジュールを起点とした通知の設定ができます。以下に、スケジュールを起点にした通知例と、通知条件と通知の流れを示します。

(図)スケジュール起点の通知の流れ

スケジュールの更新による通知の流れ スケジュールの更新による通知の流れ

注意事項注意事項

1つのYAMLファイルに1つのオブジェクトしか指定できないため、複数のオブジェクトについて設定をする場合は、複数のYAMLファイルに記載する必要があります。

通知条件の例とそれらのYAMLの定義例については「スケジュール・作業項目起点の通知例」を参照してください。


(3)ワークフローを起点にした場合の通知

以下に、ワークフローを起点にした通知例として、VM貸出業務を行った場合の各アクティビティに対する通知例を示します。

(図)VM貸出業務を行った場合の通知例

(図)VM貸出業務を行った場合の通知例 (図)VM貸出業務を行った場合の通知例


(表)VM貸出業務を行った場合の通知内容の一覧

作業名 ワークフロー
ステップ
宛先 タイトル 本文
VM貸出 申請 運用担当者 [ワークフロー番号(直リンク)]VM貸出の申請通知 VM貸出の申請通知が到着しています。対応お願いします。
 申請日時:申請日時
 申請者:申請者
申請内容の確認 申請者 [ワークフロー番号(直リンク)]VM貸出の却下通知 VM貸出の却下通知が到着しています。申し送り事項を確認の上、対応お願いします。
 申請日時:申請日時
 申請者:申請者
VM生成の確認 申請者 [ワークフロー番号(直リンク)]VM貸出のキャンセル通知 VM貸出のキャンセル通知が到着しています。申し送り事項を確認の上、対応お願いします。
 申請日時:申請日時
 申請者:申請者
VM生成の確認 運用管理者 [ワークフロー番号(直リンク)]VM貸出の承認通知 VM貸出の承認通知が到着しています。対応お願いします。
 申請日時:申請日時
 申請者:申請者
VM生成の最終確認 運用担当者 [ワークフロー番号(直リンク)]VM貸出の承認却下通知 VM貸出の承認却下通知が到着しています。申し送り事項を確認の上、対応お願いします。
 申請日時:申請日時
 申請者:申請者
VM生成の最終確認 申請者 [ワークフロー番号(直リンク)]VM貸出の完了通知 VMが貸し出されました。貸出VM台帳を参照してください。
 申請日時:申請日時
 申請者:申請者

【宛先の設定】

assignedToに宛先としてワークフローのステップの担当者を設定する場合、いくつか必要な手順があります。
通知の宛先を設定する手順については、「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス概要>APIを使うユースケースと作業の流れ>(表)「ワークフローの特定のステップに対応するアクティビティの担当者を変更する」の流れ」を参照してください。
以下に例として、宛先として申請者を設定するWorkflowのYAML定義の概念図と定義例を示します。それぞれのタスクによって得られる情報(コンテキストID、親のscheduleオブジェクトのID、更新対象のscheduleオブジェクトのID)を用いて、次のタスクを実行します。

(図)通知の宛先に申請者を設定するYAML定義の概念図

(図)通知の宛先に申請者を設定するYAML定義の概念図 (図)通知の宛先に申請者を設定するYAML定義の概念図


<定義例>宛先として申請者を設定するWorkflowのYAML定義

(中省略)

tasks:
  ### fetch_context_id アクティビティの説明
  # 概要
  #   practice-contextの一覧から現在のワークフローのExecution IDを使用してコンテキストIDを取得する
  #
  # ラベルの説明
  # action: core.http
  #   現在実行しているワークフローの情報を取得するため、
  #   GET /api/v1/practice-contexts APIを実行します。
  #   REST APIを実行するためには、StackStorm部品のcore.http actionを使用します。
  #
  # input:
  #   actionに渡す引数を指定するセクションです。
  #   ここではcore.http actionを実行するための引数を指定します。
  #   "url"には実行するREST APIのURLを指定します。
  #       ポイント:
  #         <% ctx().oiapi_location %>は"Ops IのURL/api/v1"を定義したワークフローの変数を
  #         参照する場合の例です。実行環境に合わせて変更してください。
  #   "method"にはREST APIのメソッドを指定します。
  #   "headers"にはREST APIのヘッダー情報(REST APIの実行に必要な認証情報など)を指定します。
  #       ポイント:
  #         REST APIの実行に必要な認証情報(Ops IトークンまたはOps Iアクセストークンを指定します。
  #         例では、Ops I提供部品のoi.fetch_access_token actionで
  #         事前に取得したOps Iアクセストークンを設定した変数oi_access_tokenを参照しています。
  #
  # next:
  #   REST APIの実行結果に基づき、次に実行するタスクを選択します。
  #   また、publish属性を利用して、後続の処理で使用するコンテキストIDを保存しています。
  #   コンテキストIDはpractice-contextの一覧(GET /api/v1/practice-contexts APIのレスポンス)の
  #   1件目のレコードから取得できます。
  #   1件目のレコードを検索して変数contextに設定、次にcontextのidを取得して変数context_idに
  #   設定しています。
  fetch_context_id:
    action: core.http
    input:
      url: <% ctx().oiapi_location %>/practice-contexts?filterBy=executionId%3Aeq%3A<% ctx().parent_execution_id %>
      method: GET
      headers:
        Content-Type: application/json
        Authorization: Bearer <% ctx().oi_access_token %>
    next:
       - when: <% succeeded() %>
         publish:
          - context: <% result().body.data.content.first(null) %>
          - context_id: <% ctx().context.id %>
         do: fetch_context
       - when: <% failed() %>
         do: fail

  ### fetch_context アクティビティの説明
  # 概要
  #   ワークフローの詳細情報を取得し、親のscheduleオブジェクトのIDを取得する
  #
  # ラベルの説明
  # action: core.http
  #   ワークフローの詳細情報を取得するため、GET /api/v1/practice-contexts/{id} APIを実行します。
  #   REST APIの実行にはfetch_context_id taskと同様にcore.http actionを使用します。
  #   {id}にはfetch_context_id taskで取得したpractice-contextのIDを使用します。
  #
  # input:
  #   actionに渡す引数を指定するセクションです。
  #   ここではcore.http actionを実行するための引数を指定します。
  #   指定する情報についてはfetch_context_idアクティビティと同様です。
  #
  # next:
  #   ここではpublish属性を利用して、取得したワークフローの詳細情報から
  #   親のscheduleオブジェクトのIDを取得し、変数parent_schedule_idに値を設定します。
  fetch_context:
    action: core.http
    input:
      url: <% ctx().oiapi_location %>/practice-contexts/<% ctx().context_id %>
      method: GET
      headers:
        Content-Type: application/json
        Authorization: Bearer <% ctx().oi_access_token %>
    next:
       - when: <% succeeded() %>
         publish:
          - parent_schedule_id: <% result().body.data.schedule %>
         do: fetch_schedule
       - when: <% failed() %>
         do: fail

  ### fetch_schedule アクティビティの説明
  # 概要
  #   親のスケジュールの情報から更新対象のscheduleオブジェクトのIDを取得する
  #
  # ラベルの説明
  # action: core.http
  #   更新対象のscheduleオブジェクトを取得するため、
  #   GET /api/v1/schedules/{id} APIを用いて子のスケジュール一覧を取得します。
  #   REST APIの実行にはfetch_context_id taskと同様にcore.http actionを使用します。
  #   {id}にはfetch_context taskで取得した親のscheduleオブジェクトのIDを使用します。
  #
  # input:
  #   actionに渡す引数を指定するセクションです。
  #   ここではcore.http actionを実行するための引数を指定します。
  #   指定する情報についてはfetch_context_idアクティビティと同様です。
  #
  # next:
  #   子のスケジュール一覧から更新対象のscheduleオブジェクトを検索し、
  #   変数target_scheduleに値を設定します。
  #   子のスケジュール一覧は配列のため、where式で各要素のactivityを参照し、
  #   更新対象(例ではcreate_vm_wf_01)を検索しています。
  #   変数update_schedule_bodyには次のtaskで実行するREST APIのリクエストボディを設定しています。
  #   更新にはPUT /api/v1/schedules/{id} APIを使用するため、リクエストボディに必要な情報を
  #   このtaskで取得した変数target_scheduleを利用して作成しています。
  #   例では担当者を更新するため、変数target_scheduleのassignedToを担当者のユーザーIDにset式で
  #   設定してから変数update_schedule_bodyに値を設定しています。
  #   where式、set式またはその他の使用できる式についてはStackStormのマニュアルを参照してください。
  fetch_schedule:
    action: core.http
    input:
      url: <% ctx().oiapi_location %>/schedules/<% ctx().parent_schedule_id %>
      method: GET
      headers:
        Content-Type: application/json
        Authorization: Bearer <% ctx().oi_access_token %>
    next:
       - when: <% succeeded() %>
         publish:
          - target_schedule: <% result().body.data.children.where($.activity = "create_vm_wf_01").first(null) %>
          - target_schedule_id: <% ctx().target_schedule.id %>
          - update_schedule_body: <% ctx().target_schedule.set("assignedTo", ctx().user_id) %>
         do: update_schedule
       - when: <% failed() %>
         do: fail

  ### update_schedule アクティビティの説明
  # 概要
  #   更新対象のスケジュールの情報からワークフローの担当者を変更する
  #
  # ラベルの説明
  # action: core.http
  #   更新対象のscheduleオブジェクトを更新するため、
  #   PUT /api/v1/schedules/{id} APIを用いて行います。
  #   REST APIの実行にはfetch_context_id taskと同様にcore.http actionを使用します。
  #   {id}にはfetch_schedule taskで取得した更新対象のscheduleオブジェクトのIDを使用します。
  #
  # input:
  #   actionに渡す引数を指定するセクションです。
  #   ここではcore.http actionを実行するための引数を指定します。
  #   "body"にはREST APIのリクエストボディを設定します。
  #   core.http actionでは文字列での入力が必要ため、
  #   変数update_schedule_bodyの値をstr式で文字列に変換し、設定します。
  #
  # next:
  #   一度定義した変数は繰り返し使用することができます。
  #   繰り返し使いたい場合は使用済みの値を使用しないように
  #   変数にnullを設定することで初期化できます。
  update_schedule:
    action: core.http
    input:
      url: <% ctx().oiapi_location %>/schedules/<% ctx().target_schedule_id %>
      method: PUT
      headers:
        Content-Type: application/json
        Authorization: Bearer <% ctx().oi_access_token %>
      body:
        <% str(ctx().update_schedule_body) %>
    next:
       - when: <% succeeded() %>
        publish:
         - target_schedule: null
         - update_schedule_body: null
        do: create_vm_wf_01
       - when: <% failed() %>
         do: fail

(中省略)

その他のWorkflowのYAML定義に関しては、「中省略」としています。WorkflowのYAML定義については「Workflow」を参照してください。



項構成

4.3.3.1 スケジュール・作業項目起点の通知例
4.3.3.2 通知を含めたワークフローの定義例