我们希望听到您的声音！帮助我们深入了解 Ansible 生态系统的现状。
参加 2024 年 Ansible 项目调查

使用更新后的 Ansible 内容集合批量查找和删除 ServiceNow 记录

来源

使用更新后的 Ansible 内容集合批量查找和删除 ServiceNow 记录

您是否曾经需要查询和删除 ServiceNow 记录的长列表？是啊，直到最近我才遇到过这种情况。没有人侵入我的实例，这不是一次性操作，我只是碰巧维护一个我们用来测试 Red Hat Ansible 认证内容集合的 ServiceNow ITSM 实例。

为了设置环境，我使用一个演示系统和另一个工作流程来创建一个随机用户，然后允许学习者使用完整的 Red Hat Ansible Automation Platform 部署和共享的 ServiceNow 实例完成一些挑战。因为这是一个真实的实例，所以无法确定学习者会创建哪些类型的记录。出于这个原因，我最近不得不开发一些自动化来清理这些演示用户帐户创建的记录。

虽然我的用例是清理演示用户帐户，但这同样可以是一个关键的 ServiceNow 实例，该实例需要清理错误的记录。这个集合可以用来创建、更新、修改或删除 ServiceNow 上的几乎所有内容。

如果您正在关注，请确保您安装了 servicenow.itsm 集合的版本，该版本等于或大于 2.0.0（社区版在 Ansible Galaxy | 认证版在 Ansible 自动化中心）。

我是怎么做到的呢？

使用 sys_tags

我在 ServiceNow 中有一个标签设置，它会被应用到这些演示用户创建的所有内容。我喜欢这种方法，因为标签创建和自动应用标签可以限制为具有提升权限的帐户。标签被应用于用户创建的任何记录，作为我动手实验室的一部分，帮助我找到并清理这些特定用户创建的任何内容。首先，我需要获取标签的 sys_id（这就像特定记录的全局 ID）。为此，我利用 servicenow.itsm 集合中针对 ServiceNow 标签表的 API 模块

- name: Find tag ID by name
  servicenow.itsm.api_info:
    resource: label
    sysparm_query: name={{ tag_name }}
      columns:
        - name
        - sys_id
  register: tag_info

一旦我通过名称找到了合适的标签，我就可以查询具有该标签的事件表的活动记录

- name: Get tagged incidents
  servicenow.itsm.incident_info:
    sysparm_query:
    sys_tags.{{ tag_info.record[0].sys_id }}={{ tag_info.record[0].sys_id }}
    ^active=true
    sysparm_display_value: false
  register: incidents

什么是 sysparm_display_value？ 这个问题问得好。此参数指示我的查询返回实际值，而不是显示值。显示值因字段类型而异，在本例中，sys_tags 不包含查询返回的标签名称。将此参数设置为 false 意味着此查询返回实际值。

在查询了所有应用了该标签的事件表中的活动记录并将输出注册为名为 incidents 的变量之后，我想通过创建一个包含事件号和打开日期/时间的对象数组来简化操作

- name: query incident number and creation time
  ansible.builtin.set_fact:
    incident_list: '{{ incident_list + [{"number": item.number, "opened_at": item.opened_at}] }}'
  loop: "{{ incidents.json.result }}"
  when: incidents

数组中的每个对象应该看起来像这样

- number: INC00001234
  opened_at: 2022-04-26 18:34:16

在我的用例中，拥有记录创建的时间非常有用。我并不想破坏不到两个小时前创建的记录。毕竟，我不想删除学习者正在进行我的挑战而使用的记录。

最后一个任务是获取我的事件列表，如果它们超过两个小时，则删除它们。为此，我使用 servicenow.itsm.incident 模块，并对记录创建时间进行一些条件检查

- name: close old incidents from list
  servicenow.itsm.incident:
    state: closed
    number: "{{ item.number }}"
    close_code: "Solved (Permanently)"
    close_notes: "Closed with ansible servicenow.itsm"
  loop: "{{ incident_list }}"
  when:
    - incident_list is defined
    - (( (ansible_date_time.date + ' ' + ansible_date_time.time) | to_datetime) - (item.opened_at | to_datetime)).total_seconds() > 7200

请注意 when 下的第二行？ 它并不美观，但它基本上是在尝试评估两个日期之间的秒差之前，确保两个时间格式相同。第一个日期/时间是当前执行时间，第二个日期/时间是记录创建的时间。如果时间差大于两个小时（7200 秒），则条件为真，任务继续执行，记录被关闭。

不使用 sys_tags

如果我没有将标签自动应用于所有这些记录，该怎么办？在这种情况下，我可以使用 servicenow.itsm.*_info 模块通过其他键查询记录。例如，我可以查询和关闭由特定用户创建的所有活动事件记录

- name: find user created incidents
  servicenow.itsm.incident_info:
    query:
        - sys_created_by: = {{ username }}
        active: = true
  register: incidents

- name: query incident number and creation time
  ansible.builtin.set_fact:
    incident_list: '{{ incident_list + [{"number": item.number, "opened_at": item.opened_at}] }}'
  loop: "{{ incidents.records }}"
  when: incidents

- name: close incidents from list
  servicenow.itsm.incident:
    state: closed
    number: "{{ item.number }}"
    close_code: "Solved (Permanently)"
    close_notes: "Closed with ansible servicenow.itsm"
    other:
      active: false
  loop: "{{ incident_list }}"
  when:
    - incident_list is defined

完成图片

我有一些任务对不同类型的记录（如问题、变更请求等）执行类似的操作，但它们都遵循与上面显示的任务相同的模式。我将这些任务安排在自动化控制器中的一个工作流程中，该工作流程每天执行一次，以保持此 ServiceNow 实例的整洁。

servicenow.itsm 的 2.0.0 版本通过引入性能改进和新的 API 模块来执行任意表上的操作，使得所有这些任务变得更加容易。例如，您可能想要将角色附加到用户。通过利用针对 sys_user_has_role 表的 API 模块，这非常容易

- name: attach role to new user
  servicenow.itsm.api:
    resource: sys_user_has_role
    action: post
    data:
      user: "{{ username }}"
      role: "{{ role }}"

好极了！

这可能是一个非标准操作。您为什么通常需要销毁或关闭组织的真相源中的记录？我不确定！我知道的是，通过利用 Ansible Automation Platform 和 Red Hat Ansible 认证内容集合 for ServiceNow ITSM，将您的组织的自动化策略扩展到其他主流 ITSM 流程变得更加容易。

还有其他吗？

是的！您知道有一个地方可以获得 Ansible Automation Platform 的动手体验吗？就在这里！在那里您会找到我的 ServiceNow 自动化挑战，这些挑战将引导您完成我用来保持实例整洁和 CMDB 最新状态的集合的功能。

提供支持