Resumen

La integración de ServiceNow de Rootly utiliza flujos de trabajo para crear y actualizar automáticamente tickets de ServiceNow. Si no está familiarizado con cómo funcionan los Flujos de trabajo, visite primero nuestraWorkflowsdocumentación.

Workflows

Crear un Incidente de ServiceNow

Esta acción de flujo de trabajo crea un registro en laIncidenttabla (por ejemplo,INC0010001) y lo vincula al registro de incidente de Rootly.

Actualizar un Incidente de ServiceNow

Esta acción de flujo de trabajo actualiza las propiedades de datos de un registro existente de laIncidenttabla (por ejemplo,INC0010001).

Campos Personalizados Comunes

Incidente Mayor

// Example create major incident (make sure acts_as_user is set) and ACL good (Cf. https://community.servicenow.com/community?id=community_question&sys_id=fae73aeb1b7370900b8a9979b04bcb1a)
{
  "assignment_group": "3De45d9ebc3b333200fe02c9bb34efc434",
  "major_incident_state": "proposed"
}

Notas de Trabajo

Las notas de trabajo son comentarios internos que se pueden agregar a un incidente de ServiceNow. Las notas de trabajo no pueden ser vistas por los clientes.

{
 "work_notes": "{{ incident.events[0].event_raw }}"
}

Comentario

Los comentarios se pueden agregar a un incidente de ServiceNow y pueden ser vistos por los clientes.

{
  "comments": "{{ incident.events[0].event_raw }}"
}

Agregar Elemento de Configuración (CI) al Incidente

Agregar un elemento de configuración (CI) a un incidente es una acción complicada debido a las limitaciones técnicas de las API de ServiceNow. Para facilitar esta acción, necesitaremos utilizar la acción de flujo de trabajo del Cliente HTTP de Rootly para consolidar múltiples llamadas a la API de ServiceNow en una sola acción.

La API de ServiceNow que usaremos para agregar CIs a un incidente es laTable API.

curl -X POST \
'https://<instance-domain>.com/api/now/table/task_ci' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <username:password>' \
--data '{
  "task": "<incident_id>",
  "ci_item": "<ci_sys_id>"
}'

Dado que la API de ServiceNow solo permite agregar un CI por llamada a la API, usaremos suBatch APIpara envolver múltiples llamadas a la API de Table juntas y aprovechar la acción de flujo de trabajoHTTP Clientde Rootly para llevar a cabo la llamada.

Nombre

Este campo se establece automáticamente para usted. Puede renombrar este campo a lo que mejor describa su acción. El valor en este campo no afecta cómo se comporta la acción del flujo de trabajo.

URL

Este es el punto final de la API Batch de ServiceNow. El valor debe estar en el siguiente formato:https://<instance-domain>.com/api/now/v1/batch

Método

Esta es la operación de la API. En este caso, seleccionePOST.

Parámetros de Encabezado

Estos son los parámetros de encabezado requeridos por la API Batch. Los valores se configuran en formato JSON e incluyen el token de autenticación.

Si no quiere que su nombre de usuario:contraseña sea visible para los no administradores, puede almacenarlo como una variableSecreten Rootly.

En este caso, establezca el siguiente formato:

//using exposed username:password
{
  "Accept": "application/json",
  "Content-Type": "application/json",
  "Authorization": "Basic <base64 encoded username:password>"
}

//using Rootly secret - this is the recommended method
{
  "Accept": "application/json",
  "Content-Type": "application/json",
  "Authorization": "Basic {{ secrets.service_now_key_encoded }}"
}

Parámetros de Consulta

Dado que esta es una llamada POST, no habrá parámetros de consulta. Deje este campo vacío.

Parámetros del Cuerpo

El cuerpo es donde queremos consolidar las llamadas individuales a la API de Table en un solo cuerpo.

Cada campobodyde las llamadas API individuales envueltas dentro de la API BATCH debe estar codificado en base64.

El formato sigue algo como esto:

//includes base64 encoding of body field
//this format is required to complete the API call
{
  "batch_request_id": "1",
  "rest_requests": [
    {
      "id": "11",
      "headers": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ],
      "url": "/api/now/table/task_ci",
      "method": "POST",
      "body": {<base64 encode of request body>}
    },
    {
      "id": "12",
      "headers": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ],
      "url": "/api/now/table/task_ci",
      "method": "POST",
      "body": {<base64 encode of request body>}
    },
    {
      "id": "13",
      "headers": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ],
      "url": "/api/now/table/task_ci",
      "method": "POST",
      "body": {<base64 encode of request body>}
    }
  ]
}

//body field is NOT base64 encoded
//this format is just to show you the raw data
{
  "batch_request_id": "1",
  "rest_requests": [
    {
      "id": "11",
      "headers": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ],
      "url": "/api/now/table/task_ci",
      "method": "POST",
      "body": {
        "task": "<incident_id>",
        "ci_item": "<ci_1_sys_id>"
      }
    },
    {
      "id": "12",
      "headers": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ],
      "url": "/api/now/table/task_ci",
      "method": "POST",
      "body": {
        "task": "<incident_id>",
        "ci_item": "<ci_2_sys_id>"
      }
    },
    {
      "id": "13",
      "headers": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ],
      "url": "/api/now/table/task_ci",
      "method": "POST",
      "body": {
        "task": "<incident_id>",
        "ci_item": "<ci_3_sys_id>"
      }
    }
  ]
}

Un caso de uso común es tener elservicesseleccionado de Rootly para un incidente automáticamente agregado al incidente de ServiceNow como unAffected CIs.

Para admitir este caso de uso, debe tener cadasys_idde ServiceNow CI vinculado a su equivalenteservicesde Rootly.

La siguiente sintaxis aprovecha la sintaxis Liquid para establecer dinámicamente cada campotaskyci_itemcodificado en base64 en cada llamada a la API de Table:

{
  "batch_request_id": "1",
  "rest_requests": [
{% for service in genius_workflow_run.newly_added_services %}

{% assign task_value = incident.service_now_incident_id %}
{% assign ci_item_value = service | get: 'service_now_ci_sys_id' %}
{% assign body_string = '{ "task": "' | append: task_value | append: '", "ci_item": "' | append: ci_item_value | append: '" }' %}


    {
      "id": "1{{ forloop.index }}",
      "headers": [
        {
          "name": "Content-Type",
          "value": "application/json"
        }
      ],
      "url": "/api/now/table/task_ci",
      "method": "POST",
      "body": "{{ body_string | base64_encode }}"
    }{% unless forloop.last %},{% endunless %}
{% endfor %}
  ]
}

Éxito en Estado

Establecer en200. A diferencia de la mayoría de las solicitudes POST que devuelven201, el punto final POST de la API Batch de ServiceNow devuelve200código de estado para indicar éxito.

No necesita llenar el resto de los campos en la acción del flujo de trabajo. Son más para depuración y uso de notificaciones.