NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, ACCENTURE.
DIFFICULTY LEVEL: INTERMEDIATE
Assumes basic knowledge and/or familiarity of ITIL, CMDB, and Business Services in ServiceNow.
____________________________________________________________________________
It is possible to have more than one Affected CI associated to an Incident. One scenario where this could occur would be if a supporting server were to go offline. The upstream dependent CIs would then be affected.
Out-of-the-box (OOB) there is no related list displayed for the Incident record to show these. It exists, but by default is not displayed. Also, it would be nice to roll these up from all Incidents to an owning Business Service. There is no OOB way provided to see these rollups.
Additionally there is a little bit of a problem with the current Business Service to Incident related list. It simply does not show all Incidents where the Business Service is an Affected CI. BTW, this is a problem with not just Business Services, but also any CI that is in the Affected CIs (task_ci) table.
Requirements/Design
1. Add the existing Affected CIs related list to the Incident form.
2. Create a mechanism to roll up a Business Service's associated Incident's, and then those incident's Affected CIs and show them on the Business Service form.
a. Create a System Definition Relationship that relates the Business Service to all Incidents where it is listed as an Affected CI.
b. Create a System Definition Relationship that relates the Business Service to all Affected CIs in the related Incidents.
c. Add the new related lists (Relationship) to the Business Service form.
Lab 1.1: Adding the Affected CIs Related List to the Incident Form
OOB you will find that there is no related list shown of all CIs affected by an incident; even though there is minimum of one if the Affected CI field is filled in. BTW, I consider this to be a bit of an oversight. This tab really should be already added to the form.
1. Navigate to Incidents -> Open. The open incident list view will be displayed.
2. Open one of the listed Incidents. The incident form will be displayed.
The related lists at the bottom of the Incident form. Note the Affected CI related list is not present.
The form showing the Affected CI filled in:
3. Right-click on the form header to bring up the context menu and go to Configure -> Related Lists. The Related Links choice form will be displayed.
4. Find Affected CIs in the Available list and move it to the Selected list (left-side).
5. Click on the save button. The Incident form will be redisplayed.
6. Navigate to the bottom of the form again. You will not that the Affected CIs related list is now displayed.
That polishes off our first requirement. Now to start on the next requirement by creating the Relationship!
Lab 2.1: Creating a Relationship Between Business Services and Incidents
Now we need to create a relationship record that will allow us to display a related list of our Incidents on the Business Service form.
1. Navigate to System Definition -> Relationships. The Relationships List View will be displayed.
2. Click on the New button. The New Relationship form will be displayed.
3. Fill out the form with the following:
a. Name: Business Service to Incident
b. Applies to Table: Business Service [cmdb_ci_service]
c. Queries from Table: Incident [incident]
d. Query with:
(function refineQuery(current, parent) {
var incidentList = _retrieveIncidentList();
current.addQuery('sys_id', 'IN', incidentList);
})(current, parent);
// get all incidents where the business service is an Affected CI.
function _retrieveIncidentList() {
var incidentList = [];
var incidentRecords = new GlideRecord('task_ci');
incidentRecords.addQuery('ci_item', parent.sys_id);
incidentRecords.query();
while (incidentRecords.next()) {
incidentList.push(incidentRecords.getValue('task'));
}
incidentList = new ArrayUtil().unique(incidentList);
return incidentList;
}
e. Click the Submit button to save your work.
That completes requirement 2a. This establishes a Related List association between the Incidents and the Business Service, and shows the correct Affected CI relationship.
Lab 2.2: Creating a Relationship Between Business Services and Affected CIs
Now we need to create a relationship record that will allow us to display a related list of our Configuration Items (CIs) on the Business Service form.
1. Navigate to System Definition -> Relationships. The Relationships List View will be displayed.
2. Click on the New button. The New Relationship form will be displayed.
3. Fill out the form with the following:
a. Name: Business Service to Affected CIs
b. Applies to Table: Business Service [cmdb_ci_service]
c. Queries from Table: Configuration [cmdb_ci]
d. Query with:
(function refineQuery(current, parent) {
var affectedCIList = _retrieveaffectedCIList();
current.addQuery('sys_id', 'IN', affectedCIList);
})(current, parent);
function _retrieveaffectedCIList() {
// get all incidents where the business service is an Affected CI.
var incidentList = [];
var incidentRecords = new GlideRecord('task_ci');
incidentRecords.addQuery('ci_item', parent.sys_id);
incidentRecords.query();
while (incidentRecords.next()) {
incidentList.push(incidentRecords.getValue('task'));
}
incidentList = new ArrayUtil().unique(incidentList);
// go back and get all Affected CIs for the incidents found
var affectedCIList = [];
var affectedCIRecords = new GlideRecord('task_ci');
affectedCIRecords.addQuery('task', 'IN', incidentList);
affectedCIRecords.query();
while (affectedCIRecords.next()) {
affectedCIList.push(affectedCIRecords.getValue('ci_item'));
}
affectedCIList = new ArrayUtil().unique(affectedCIList);
return affectedCIList;
}
e. Click the Submit button to save your work.
That completes requirement 2b. This establishes a Related List association between the Affected CIs and the Business Service.
The final step will be to add our new Related List to the Business Service form.
Lab 2.3: Modifying the Business Service Form to Add the New Relationship
Finally let's add the new related list of Affected CIs to the Business Service form. This will automatically filter it to only show Incidents/Affected CIs that belong to that particular Business Service (the roll-up).
1. Navigate to Configuration -> Business Services. The Business Services list view will be displayed.
2. Click on your favorite Business Service. The Business Service form will be displayed.
3. Right-click on the form header to bring up the context menu, and click on Configure -> Related Lists. The Related List form will be displayed.
4. Search for, and move to the right the Business Service to Incident, Business Service to Affected CIs related lists. For comparison I will move the Incident->Business Service and Incident->Affected CI related lists as well, but this is not necessary for you to do.
5. Click on the Save button. The Business Service form will be redisplayed.
So now let's check to see that everything is working.
Steps for testing:
1. Create or make note of a Business Service.
2. Create or edit an Incident, and add the Business Service as an affected CI. Add other affected CIs to the Incident.
3. Create or edit a second Incident, and add the Business Service as a secondary affected CI (not entered into the Affected CI field, but rather added via the Edit button on the Affected CI list of the Incident).
4. Re-edit the Business Service and note the Related Links tabs.
Mine looked like the following (remember I added the two Incidents tabs onto the end for comparison):
1. The Business Service to Incident related list show all of the related incidents.
2. The Business Service to Affected CIs related list shows all actual CIs that were found in the two incident's Affected CIs list, and it has been de-duped.
3. The Incidents to Business Service OOB related list is empty. Which is a bit of a mystery; that I have not bothered to dig out.
4. The Incident to Affected CI OOB related list is odd in that it displays Incidents, and not the Affected CIs. Regardless it only shows those Incidents where the Affected CI is the primary; which is the case in the scenario I set up. Secondaries will not be displayed in this OOB related list. Therefore, it is inaccurate.
There you have it! You now see how you can use a more advanced approach with the System Definition Relationships to create useful related lists that do not exist OOB. The examples I present here should give you insight on how much more complex models can be approached.
Kind of a side-note: Yes, I could have build a Database View to help with the gaps I am filling in with code here. That also would have given me a way of reporting on the Affected CIs for all Business Services. I went this route because I didn't need that reporting mechanism. You always need to think of the balance. What might be needed vs. what will accomplish the current need.
Have fun!
Steven Bell
For a list of all of my articles: Community Code Snippets: Articles List to Date
Please Share, Like, Bookmark, Mark Helpful, or Comment this blog if you've found it helpful or insightful.
Also, if you are not already, I would like to encourage you to become a member of our blog!
