Introduction
ServiceNow is one of the leading IT Service Management (ITSM) providers and is a repository of information regarding operational incidents within the technology estate.
This article describes the method for importing incident information into Ardoq and augmenting existing Ardoq Solutions for enhanced insight into capabilities and the technology estate.
Scope
Operational incidents can help to provide an enhanced level of insight into your enterprise architecture, identifying components with significantly high (or low) rates of impact from operational incidents. This article describes the method for achieving this.
Note: The method assumes integration between Ardoq and ServiceNow in-line with the ServiceNow CSDM (see How to map from the ServiceNow CSDM to Ardoq Solutions).
The approach described here will provide a solution across 3 different ServiceNow configuration items / Ardoq component types:
Business Application / Application
Application Service / Application Instance
Server / Server
It will also describe the ability to roll-up incidents to the level of business and/or technical capabilities. This can be modified as needed to include or exclude configuration items (CIs). This would be used if you have also imported these additional CIs from ServiceNow.
Note: This approach uses a daily import schedule and, therefore, does not provide a 'live' view of incidents. ServiceNow should continue to be used for any live operational views regarding incident status.
If you currently have large numbers of operational incidents that may present a performance challenge for regular import, then you may wish to explore alternative options such as:
reducing the number of incidents by constraining the import to a reduced time period (e.g. last 6 months)
developing a bespoke integration using the ServiceNow aggregation API (see Appendix A)
Step-by-Step Guide
Step 1: Create the Incidents workspace and Incident component type
Create a new workspace called Incidents and add a component type to the metamodel called Incident.
Then add a reference type called 'Impacts' to the Incidents workspace.
Fields you want to import from ServiceNow can be created and added to the Incident component type here, or they can be created automatically when configuring your import. Four additional fields are shown above.
Note: You must always import the Sys ID for the import schedule to work correctly (this field will already exist if you have followed the CSDM Mapping - see above).
Note: If you have an existing workspace, component type, or fields that cause a naming conflict, then select alternative names and use those names in the subsequent steps.
Step 2: Create an import configuration for each component type that you want to track incidents against
You will now need to create an import configuration and schedule for each component type that you want to track incidents against. For more information on configuring ServiceNow imports (see How to import ServiceNow data into Ardoq).
We will be tracking incidents against the Application, Application Instance, and Server component types, as per the CSDM mapping.
Select Data
The source table for the imports from ServiceNow is:
CIs Affected (task_ci)
For the CIs Affected (task_ci) imports you should filter the content of the table for each component type you wish to import. For our component types the filter strings are:
Component Type | Filter String |
Server |
|
Application Instance |
|
Application |
|
You can then select the following fields:
Field Name | ID |
Configuration item |
|
Configuration item |
|
Task |
|
Task |
|
Configure Data
Table rows contain: Components
Select or create workspace to import this table: Incidents
Data sync strategy - n/a
Configure columns: as per table below:
Field | Configuration |
Configuration item | None |
Configuration item (Sys ID) | Column type: Reference Column represents: Target component Target Workspace: <Target> Reference type: Impacts If target component is missing: Exclude reference Format: Custom ID Field Name: Sys ID Item separator: , |
Task | Column type: Component (Name) Hierarchy level: Level 1 Component Type: Incident |
Task (Sys ID) | Column type: Custom ID Exclude duplicates of components with same ID - Yes Field name: Sys ID |
Review Import
Ensure there are no errors and proceed to Import Data.
Import & Schedule
Save your configuration and create a schedule. You can update the interval of your schedule to your preferred frequency and tick the checkbox to disable manual data changes in the workspace.
Repeat this configuration for each component type (Application, Application Instance, Server).
Step 3 (Optional): Import additional Incident information
If you want to use additional information about incidents, you will need to import it from ServiceNow. We will import the ‘Description’, the ‘Active’ indicator, the ‘Created’ date, and the ‘Incident Category’ as examples.
The source table for the import from ServiceNow is as follows:
Incident (incident)
The filter string is as follows:
Component Type | Filter String |
Incident |
or, if performance becomes an issue:
|
You can then select the following fields:
Field Name | ID |
Active |
|
Category |
|
Created |
|
Description |
|
Number |
|
Sys ID |
|
Configure Data
Table rows contain: Components
Select or create a workspace to import this table: Incidents
Data sync strategy
Select 'Update only existing assets when using custom ID or Ardoq OID.'
Configure columns as per table below:
Field | Configuration |
Active | Column type: Field Name: Active Type: List |
Category | Column type: Field Name: Incident Category Type: List |
Created | Column type: Field Name: Creation Date Type: Date |
Description | Column type: Description |
Number | Column type: Component (Name) Hierarchy level: Level 1 Component Type: Incident |
Sys ID | Column type: Custom ID Field name: Sys ID |
Review Import
Ensure there are no errors and proceed to Import Data.
Import & Schedule
Save your configuration and create a schedule. You can update the interval of your schedule to your preferred frequency and tick the checkbox to disable manual data changes in the workspace.
Step 4: Create calculated fields on target component types
Once you have imported your incidents and linked them to their impacted configuration items you can create calculated fields on your target component types to support visualization and reporting.
We will create two calculated fields:
Incident Count (Calculated Number)
Incident Impact Count (Calculated Number)
Depending on the additional fields you bring across from ServiceNow you may want to create alternative or additional calculated fields. For further examples, see Appendix B.
We will add these fields to the 4 different component types:
Application
Application Instance
Server
Business Capability (Note: Incident Count is not required because capabilities are not directly impacted by incidents)
Field Definition
Name: Incident Count
Type: Calculated Number
Description: The number of incidents that have impacted this component
Number Format: Default
Applies To: <Target Component Type>
Calculation (Gremlin):
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(
inE('Impacts').outV().hasLabel('Incident').count()
)
–
Name: Incident Impact Count
Type: Calculated Number
Description: The number of impacts by incidents on this component and its dependents
Number Format: Default
Applies To: <Target Component Type>
Calculation (Gremlin):
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(
union(identity().values('incident_count'),out('Is Supported By').values('incident_impact_count'),out('Is Realized By').values('incident_impact_count'),constant(0)).sum()
)
–
Step 4: Update/Create visualizations, reports, and dashboards as required
Once you have created the calculated fields on the target component types you can use perspectives to gain insight. Two examples are provided below:
Example 1: Application view showing the number of incidents across the estate
Example 2: A business capability heat-map showing the accumulated impact of incidents across your capabilities
Appendix A - ServiceNow Aggregate API
ServiceNow offers an aggregate API where you can retrieve the number of incidents related to each configuration item. This could be used to update component field values using a bespoke integration.
More information regarding the aggregate API can be found here:
ServiceNow Aggregate API
An example request to retrieve all active incidents grouped by configuration item is shown below:
Sample URL:
https://<your-instance>.service-now.com/api/now/stats/incident?sysparm_count=true&sysparm_group_by=cmdb_ci&active=true
Sample output can be seen below:
<response>
<result>
<stats>
<count>1</count>
</stats>
<groupby_fields>
<field>cmdb_ci</field>
<value>963a31003b4bb095e57ffb8843tg3f</value>
</groupby_fields>
</result>
<result>
<stats>
<count>2</count>
</stats>
<groupby_fields>
<field>cmdb_ci</field>
<value>ee728f933a310034be57ffb8afer3ferfe</value>
</groupby_fields>
</result>
</response>
Appendix B - Alternative Calculated Fields
You can create additional fields and reports by using imported t ServiceNow Incident information.,. For example, you can show only active incidents. In this scenario, you would create the columns as below:
Field Definition
Name: Active Incident Count
Type: Calculated Number
Description: The number of active incidents that have impacted this component
Number Format: Default
Applies To: <Target Component Type>
Calculation (Gremlin):
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(
inE('Impacts').outV().hasLabel('Incident').has('active',"true").count()
)
–
Name: Active Incident Impact Count
Type: Calculated Number
Description: The total number of impacts by active incidents on this component and its dependent components
Number Format: Default
Applies To: <Target Component Type>
Calculation (Gremlin):
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(
union(identity().values('active_incident_count'),out('Is Supported By').values('active_incident_impact_count'),out('Is Realized By').values('active_incident_impact_count'),constant(0)).sum()
)
–
Other options might include reporting on incidents by severity or by category. The Gremlin above can be adjusted as needed.