The Red Hat Ansible Certified Content Collection for ServiceNow helps you create automated workflows targeting IT service management (ITSM) tasks faster while establishing and maintaining a single source of truth in the ServiceNow configuration management database (CMDB). In this blog, I’ll share the latest features we’ve added to the Collection, and you can find additional resources about existing features at the end of this blog.
We’ve added three major updates to the Red Hat Ansible Certified Content Collection for ServiceNow:
- Advanced inventory features
- Customized list mappings
- Creating problem tasks and change requests tasks
Let’s take a closer look at each of these.
Support for advanced inventory features
A new feature in ServiceNow Collection introduces a new inventory functionality, called “enhanced inventory”, which provides the ability to create groups based on CMDB relationships. Previous versions of the inventory plugin allowed us to create predefined groups, such as the “Linux Red Hat” and “Windows XP” examples shown here:
---
plugin: servicenow.itsm.now
query:
- os: = Linux Red Hat
- os: = Windows XP
keyed_groups:
- key: os
prefix: os
Inspecting the inventory collected using the above configuration results in:
ansible-inventory -i inventory.now.yaml --graph` output:
|--@os_Linux_Red_Hat:
| |--DatabaseServer1
| |--DatabaseServer2
|--@os_Windows_XP:
| |--FileServerFloor1
| |--FileServerFloor2
| |--INSIGHT-NY-03
|--@ungrouped:
If no group information was defined, inventory items were left ungrouped, as in this example:
---
# example1-inventory.now.yaml
plugin: servicenow.itsm.now
query:
- sys_class_name: = cmdb_ci_unix_server
Which creates the following inventory with all hosts being ungrouped with no way of isolating hosts based on relationships:
@all:
|--@ungrouped:
| |--dbaix900nyc
| |--dbaix901nyc
| |--dbaix902nyc
| |--lawson_app_100
| |--lawson_db_100
| |--unix200
| |--unix201
Now, in the latest Collection updates, we can define relationships using “enhanced: true” and the CMDB relationships are invoked and automatically grouped as shown in this example:
---
# example1-enhanced-inventory.now.yaml
plugin: servicenow.itsm.now
enhanced: true
query:
- sys_class_name: = cmdb_ci_unix_server
Which generates the following inventory:
@all:
|--@Bond_Trading_Depends_on:
| |--unix201
|--@Retail_Adding_Points_Depends_on:
| |--dbaix901nyc
|--@Securities_Lending_Runs_on:
| |--unix200
| |--unix201
|--@lawson_db_Runs_on:
| |--lawson_db_100
|--@nc6500_a01_Connected_by:
| |--lawson_app_100
| |--lawson_db_100
|--@nyc_oracle_rac_cluster_Members:
| |--dbaix900nyc
| |--dbaix901nyc
| |--dbaix902nyc
|--@nyc_rac_nas200_Used_by:
| |--dbaix900nyc
| |--dbaix901nyc
| |--dbaix902nyc
|--@ungrouped:
The inventory of hosts created now shows that hosts are grouped by their associations.
Unlike in the previous Collection, this enhanced inventory plugin does not require any additional scripts to be imported into your ServiceNow instance and works on top of the standard REST API that ServiceNow provides.
Support for customized mappings
ServiceNow is extremely customizable, allowing you to define most anything within your instance. One example of this is “choice lists,” which is a field type that allows you to define a list of options that a user must select. You can also add, remove, or rename labels for any choice list items. For instance, for the field “incident state” the default values are “In Progress”, “On Hold”, “Resolved”, “Closed”, and “Canceled.” With customized mappings, for instance, you can add an additional option such as “Testing.”
In previous versions of the ServiceNow Content Collection, changes to the choice list would disrupt the playbook execution. In order for this to work correctly and not disrupt any existing servicenow.itsm automated workflows, we added an optional user mapping argument within each module. For example, see the following state mapping within servicenow.itsm.incident_info:
- name: Retrieve all incidents
servicenow.itsm.incident_info:
incident_mapping:
state:
1: "new"
2: "in_progress"
3: "on_hold"
6: "resolved"
7: "closed"
8: "canceled"
9: "test"
register: result
In the above example, a new state was added labeled “test”. This state was first defined in ServiceNow System Definition -> Choice Lists. The matching here is done by key, which is a number used to map the actual state within ServiceNow.
Interacting with problem tasks and change request tasks
NOTE: These modules are not currently supported with either the Rome or San Diego versions of the ServiceNow REST API.
Finally, the latest in the ServiceNow Content Collection also includes new modules for two task types: problem task (supported by modules: problem_task and problem_task_info) and change request task (supported by modules: change_request_task and change_request_task_info).
According to ServiceNow, a problem task is the “smallest unit of work that you should perform to complete a problem.” Each problem task can be assigned to a different group or user. A change request is “a piece of work related to the change request” which includes all the discrete steps required to implement the change.
These two modules allow you to automatically create problem tasks and create change tasks for change requests. As you can see in the following example, you can simply create a new problem task by referring to a source problem and defining some fields.
- name: Create a problem
servicenow.itsm.problem:
short_description: my-problem
state: new
register: problem
- name: Create a problem task
servicenow.itsm.problem_task:
state: new
type: general
source_problem: "{{ problem.record.number }}"
short_description: my-problem-task
priority: low
register: problem_task
Similarly, you can create a change request task by referencing the “change_request_number” as shown below:
- name: Create test change_request_task - check mode
servicenow.itsm.change_request_task: &create-change_request_task
change_request_number: "{{ change_request_result.record.number }}"
type: planning
state: pending
short_description: "Implement collision avoidance"
description: "Implement collision avoidance based on the newly installed TOF sensor arrays."
other:
approval: approved
register: result
What’s next
The Collection for servicenow.itsm continues to improve the automated ITSM experience. By continuing to adapt to additional usage patterns, this Collection assures that ITSM processes are followed even within automated workflows. For hands on experience, check the additional resources at the end of the post.
Additional resources
Learn more about the Red Hat Ansible Certified Content Collection for ServiceNow ITSM with these resources:
- Solution brief: Ansible Certified Content Collection for ServiceNow
- Blog: What’s new: Automating ServiceNow with Ansible Automation Platform
- Blog: Automating ServiceNow with Red Hat Ansible Automation Platform
- Hands on demo: Interactive hands-on labs with Ansible Automation Platform
Originally posted on Ansible Blog
Author: