4.3.3 Designing notifications

Notes

Since only one object can be specified in a single YAML file, settings for multiple objects must be described in separate YAML files.

(omitted)

tasks:
  ### fetch_context_id Activity description
  # Overview
  #   Retrieve the context ID from the list of practice-context using the current workflow’s Execution ID.
  #
  # Label description
  # action: core.http
  #   To retrieve information about the currently running workflow,
  #   execute the GET /api/v1/practice-contexts API.
  #   To execute a REST API, use the “core.http” action in the “StackStorm” component.
  #
  # input:
  #   This section specifies the arguments to pass to “action”.
  #   Here, specify the arguments required to execute the “core.http” action.
  #   Specify the URL of the REST API to execute in the “url” field.
  #       Points:
  #         <% ctx().oiapi_location %> is an example of referencing a workflow variable
  #         defined as “Ops I’s URL/api/v1”. Modify this as required for your execution environment.
  #   Specify the REST API method in “method”.
  #   Specify the REST API header information (such as the credentials required to execute the REST API) in “headers”.
  #       Points:
  #         Specify the credentials required to execute the REST API (Ops I token or Ops I access token).
  #         In this example, the variable “oi_access_token”, which stores the Ops I access token
  #         obtained in advance by using the Ops I component’s “oi.fetch_access_token” action, is referenced.
  #
  # next:
  #   Based on the execution results of the REST API, select the next task to execute.
  #   In addition, use the “publish” attribute to save the context ID for use in subsequent processing.
  #   The context ID can be obtained from the first record in the list of “practice-context”
  #    (the response from the “GET /api/v1/practice-contexts” API).
  #   Retrieve the first record and assign it to the variable “context”, then retrieve the ID of “context” and assign it
  #   to the variable “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 Activity description
  # Overview
  #   Retrieves detailed information about a workflow and obtains the ID of the parent “schedule” object.
  #
  # Label description
  # action: core.http
  #   Executes the “GET /api/v1/practice-contexts/{id}” API to retrieve details about a workflow.
  #   To execute the REST API, use the “core.http” action, just as in the “fetch_context_id” task.
  #   Use the “practice-context” ID obtained from the “fetch_context_id” task for {id}.
  #
  # input:
  #   This section specifies the arguments to pass to “action”.
  #   Here, specify the arguments required to execute the “core.http” action.
  #   The information to be specified is the same as that for the “fetch_context_id” activity.
  #
  # next:
  #   Here, use the “publish” attribute to retrieve the ID of the parent “schedule” object
  #   from the retrieved workflow details and assign it to the variable “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 Activity description
  # Overview
  #   Retrieves the ID of the “schedule” object to be updated from the parent schedule information.
  #
  # Label description
  # action: core.http
  #   To retrieve the “schedule” object to be updated,
  #   execute the “GET /api/v1/schedules/{id}” API to retrieve a list of child schedules.
  #   To execute the REST API, use the “core.http” action, just as in the “fetch_context_id” task.
  #   Use the ID of the parent “schedule” object obtained from the “fetch_context” task for {id}.
  #
  # input:
  #   This section specifies the arguments to pass to “action”.
  #   Here, specify the arguments required to execute the “core.http” action.
  #   The information to be specified is the same as that for the “fetch_context_id” activity.
  #
  # next:
  #   Search for the target “schedule” object in the list of child schedules
  #    and assign it to the “target_schedule” variable.
  #   Since the list of child schedules is an array, use a “where” expression to reference the “activity” of each element
  #    and search for the update target (in this example, “create_vm_wf_01”).
  #   The “update_schedule_body” variable contains the request body for the REST API call to be executed in the next task.
  #   Since the update uses the “PUT /api/v1/schedules/{id}” API,
  #   construct the request body using the information obtained in this task through the “target_schedule” variable.
  #   In this example, to update the assignee, use a “set” expression to set the “assignedTo” property of the “target_schedule” variable
  #   to the assignee’s user ID, and then assign the value to the “update_schedule_body” variable.
  #   For details about “where” expressions, “set” expressions, and other supported expressions, see the StackStorm manual.
  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 Activity description
  # Overview
  #   Change the workflow assignee based on information from the schedule being updated.
  #
  # Label description
  # action: core.http
  #   To update the target “schedule” object,
  #   use the “PUT /api/v1/schedules/{id}” API.
  #   To execute the REST API, use the “core.http” action, just as in the “fetch_context_id” task.
  #   Use the ID of the “schedule” object to be updated, obtained from the “fetch_schedule” task, for {id}.
  #
  # input:
  #   This section specifies the arguments to pass to “action”.
  #   Here, specify the arguments required to execute the “core.http” action.
  #   Set the request body for the REST API in “body”.
  #   Since the “core.http” action requires string input,
  #   convert the value of the “update_schedule_body” variable to a string by using a “str” expression, and then set it.
  #
  # next:
  #   Once defined, variables can be reused.
  #   If you want to reuse a variable, initialize it by setting the variable to “null”
  #   to avoid using a previously assigned value.
  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

(omitted)