4.3.3 通知の設計

通知の設計は、NotificationとNotifierの2つのタイプのYAML定義を行います。

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

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

(図)Notification、Notifierの概念図

(図)Notification、Notifierの概念図 (図)Notification、Notifierの概念図

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

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


(1)通知の流れ

通知イベントが発生した際、送信元は通知オブジェクトを作成し、Notifierによって送信先に届けられます。
通知の中身を表す通知オブジェクトはNotificationタイプのYAMLファイルによって管理されます。通知オブジェクトには、通知の宛先や、通知の送信手段、通知メッセージの情報が含まれます。通知の宛先は、Ops Iのユーザー、またはグループへの通知を選択できます。
通知の手段はNotifierタイプのYAMLファイルによって管理されます。
通知先は、scheduleオブジェクトのassignedToに申請者などを設定することで指定できます。scheduleオブジェクトについては「(表)Notificationで使用可能なオブジェクト・フィールド」を参照してください。
どのイベントに通知設定をしたかは、ワークフローやスケジュールのGUI上ではわからないため、必要に応じて通知の定義をしたユーザーから関係者に周知する必要があります。

(図)通知の流れ

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

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



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

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

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

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

NotificationのYAML定義で通知条件を指定できます。例えば、通知条件としてスケジュールのイベント(担当者の変更や定期監視など)の設定や、特定の予定表に属したスケジュールへ通知を限定することができます。複数の条件は階層によってand条件とor条件の使い分けが可能です。第一階層はor条件、第二階層以下はand条件で判定されます。詳細は「Notification、Notifier 」を参照してください。

注意事項注意事項

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貸出の完了通知 Mが貸し出されました。貸出VM台帳を参照してください。
 申請日時:申請日時
 申請者:申請者

【通知先の設定】

assignedToに通知先としてワークフローのステップの担当者を設定する場合、いくつか必要な手順があります。
通知の送信先を設定する手順については、「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス概要>APIを使うユースケースと作業の流れ>(表)「ワークフローの特定のステップに対応するアクティビティの担当者を変更する」の流れ」を参照してください。
以下に例として、通知先として申請者を設定するYAML定義の概念図と定義例を示します。

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

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


<定義例>

(中省略)

tasks:
  # Practice-contextの一覧から現在のワークフローのExecution 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:
          # practice-contextを取得する
          - context: <% result().body.data.content.first(null) %>
          - context_id: <% ctx().context.id %>
         do: fetch_context
       - when: <% failed() %>
         do: fail

  # ワークフローの詳細情報を取得する
  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:
    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
    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:
       # 変数の初期化およびcreate_vm_wf_01へ遷移
       - 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 スケジュール・作業項目起点の通知例