A mature Configuration Management Database (CMDB) in ServiceNow typically contains a huge volume of information related to hardware, software, services, etc. and their relationships. Users frequently struggle to locate the necessary data in their organization’s CMDB. Understanding the structure and schema of the database is usually necessary to query this complicated data model. This is where the natural language query (NLQ)-based CMDB intelligent search capability can really make a difference. It allows users to utilize queries in simple English to retrieve desired information from the CMDB. Thus, they don’t have to come up with any complicated queries or comprehend the underlying database semantics.

2. Accessing and using CMDB Intelligent Search

Step 1: Find CMDB intelligent search from the CMDB Workspace

Click the ‘Workspaces’ menu from the ServiceNow banner and then select ‘CMDB Workspace’ to launch it.

Intelligent search section can be found at the top of the CMDB Workspace, and a search box is located underneath it.

Step 2: Refer ‘Search tips’ (Optional)

Users can also find suggestions on how to perform the search more effectively. Click the ‘Search tips’ URL located next to the ‘Search’ button to view these suggestions.

A search tips pop-up window appears, as shown in the screenshot below.

The following 4 tabs are available on the search tips windows:

• Single-table search: Tips to search a single CI class and its associated attributes. This is displayed initially when the search tips window opens.
• Multi-table search: Tips to search multiple classes and related tables.
• Advanced filtering: Details about the keywords that may be applied as filters to limit the results.
• Relationships: Tips about how to query relationship data.

Step 3: Search for the required information using natural language

In the search box located under ‘Intelligent search’, users can specify what they require in natural language. E.g., Show me all servers located in San Diego.

Under the search field, we can see past searches and sample searches. As you type, ServiceNow suggests potentially relevant table names and field names.

Step 4: Refine the query if required

ServiceNow will try to convert the natural language into an appropriate database query after clicking search. If there’s still uncertainty, a dialog box will appear, prompting you to clarify certain parts of the query. For instance, the pop-up window shown in the screenshot below lets us enter the name of the table for the CI class that we need to query.

Click the ‘View search results’ button after reviewing the information requested in the pop-up window and providing our inputs if required.

Step 5: Check and interact with the results

The search results will be displayed after clicking the ‘View search results’ button in the previous step. Here we can see options to give feedback on the relevance of the results, export this data, check and modify the filter conditions, etc.

NOTE: If the constructed CMDB query contains more than one table, then the search results will have a ‘View in Query Builder’ button available near it. Click the button to open the CMDB Query Builder with your query fully constructed on the Query Builder canvas. We can use the Query Builder to edit the query if needed.

3. Improving the accuracy of CMDB Intelligent search

The NLQ is pre-trained with a certain level of natural language comprehension. But it is possible to increase its accuracy by configuring the following:

3.1 Synonyms

We can use ‘Synonyms’ to improve the search results by enabling users to find records using different terms whose meanings are the same or similar. For example, if “laptop” is defined as a synonym for “notebook”, searching for either term will yield the same results. This feature helps to make searches more flexible and inclusive. This is configured by navigating to ‘NLQ>Synonyms‘ in the application navigator and defining pairs of equivalent terms. For example, the form view of a record available Out-of-the-box (OOB) on the Synonyms table is shown in the following screenshot. This indicates that a search containing any of the keywords listed in the ‘Synonyms’ field will consider the ‘Name’ of the ‘Model ID’ of the server while fetching the search results.

3.2 Semantic Shortcuts

Semantic shortcuts enable NLQ systems to understand various kinds of user requests. They map commonly used words to fields in the database. But they are only applicable when certain conditions are met. It is accessed by going to ‘NLQ>Semantic Shortcuts’. Some semantic shortcuts are available OOB. Organizations need to look at defining custom semantic shortcuts by considering various parameters like their requirements, keywords used in past searches (accessible from ‘NLQ>Logs‘), common use cases, etc.

In the following example, a search about ‘Servers which I own’ will consider records where the ‘Owned by’ field in the cmdb_ci_server table matches the current user who is doing the search.

3.3 CMDB Implicit Relationships

We can improve the capability of Intelligent Search to find relevant results by specifying implicit relationships between CI classes. An implicit relationship defines the relationship between two tables and includes any filters to be applied. Implicit relationships are particularly useful for queries which involve service offerings and application services.

It can be accessed by navigating to ‘NLQ>Cmdb implicit relationships’ from the application navigator. The relationship tab of the ‘Search tips’ window also has a link to access this.

4. Conclusion

The CMDB intelligent search enables ServiceNow users to gather the required information from the CMDB without having to comprehend the database complexity. As a result of improving the user experience while querying the CMDB, it may indirectly increase the effectiveness of CMDB in a variety of use cases, such as service operations, compliance management, IT asset management, planning, etc. Intelligent search enables more stakeholders to tap into the authoritative CMDB intelligence through natural conversation.

The post CMDB Intelligent Search appeared first on ServiceNow Guru.

1. CI Identification rules

Identification rules are a set of criteria that ServiceNow utilizes to identify already existing Configuration Items (CIs) within the CMDB. These rules specify how a CI is recognized using some unique attribute (e.g., Name, Serial number, Device ID, Object ID, etc.) or a combination of one or more unique attributes. Properly defined identification rules are essential for maintaining and improving CMDB data quality by reducing the possibility of creating duplicate CIs.

1.1 How to access identification rules?

It can be accessed using any of the 2 ways mentioned below:

1. Go to ‘CI class manager’. Search for any CI class that you want to check (e.g., Network Gear) and open it. Click on the ‘Identification Rule’ tab.

This method is more suitable to check all the identifier entries defined for any specific CI class.

2. Go to ‘Identification/Reconciliation>CI identifiers‘ from the application navigator.

This method is useful for checking identifier entries defined across all CI classes.

1.2 Understanding CI identification rules in action

Let’s take the ‘Network Gear’ class as an example. Open ‘CI class manager’ from the application navigator. Search for Network Gear. Click on ‘Identification Rule’ tab. The ‘Identifier entries’ section shows the list of attributes which are specified as the identifier entries for this class.

We can see ‘Priority’ values assigned to each identifier entry. The entry with the lowest ‘Priority’ value (i.e., 100 here) would be evaluated first, followed by the remaining 3 entries in the increasing order of ‘Priority’. In this example, ServiceNow IRE will initially check for the presence of existing CIs with the combination of ‘Serial Number’ and ‘Serial Number Type’. If a match is found, the data will be updated for the identified CI, and the remaining identifier entries won’t be evaluated. If a match is not found, it will continue by checking the next identifier entry (only Serial Number) and so on. If a match is not found even after evaluating all the 4 identifier entries, a new CI will be created.

1.3 Configuring new Identification Rules

The ‘Replace’ button can be used to define a new identification rule for this class. Then an ‘Add’ button will appear under ‘Identifier Entries’.

Click the ‘Add’ button. A window will appear where we can choose whether we want to use the attributes from the main table or from another table (lookup table) or from a combination of tables. Click ‘Next’ after choosing.

Specify the ‘Priority’, select the ‘Criterion Attributes’ and click ‘Save’ to create the identifier entry. Repeat the process for adding more attributes with a different priority.

1.4 Best practices to consider for CI identification rules

Following are some best practices to consider regarding identification rules:

• Review the out-of-the-box (OOB) identification rules for all the CI classes that you are planning to manage in your CMDB. Modify the rules wherever required based on the unique attributes present in the data sources that will be used to populate each class.
• The attributes considered as identifier entries should be unique and must remain unchanged throughout the CI lifecycle. It should also be populated for most of the records. Leverage a combination of multiple attributes wherever possible.
• Use Service Graph Connectors (if available) for third-party data integrations that populate the CMDB. Integrations that are NOT done using this method will NOT go through the IRE. i.e., they do NOT consider the identifier entries defined for the CI classes that are populated by the integration.
• Use integration hub ETL for manual data imports. Any data imports that are NOT done using this method will NOT go through the IRE.
• Review the identification rules periodically to check if any modifications are required due to any changes in IT infrastructure. E.g., introduction of a new data source

1.5 Identification inclusion rules

This is an additional feature that may be used to limit the list of CIs that are considered for the identification procedure. If a CI class has an Identification inclusion rule specified, ServiceNow’s IRE only processes CIs that satisfy the requirements specified by the identification inclusion rules for that CI class. You may, for instance, establish a rule that only considers CIs with the operational status=Operational. There are no predefined inclusion rules in an out-of-the-box (OOB) ServiceNow instance.

Identification inclusion rules can be accessed and configured by going to the ‘Inclusion Rule (Advanced)’ section present under the Identifier entries defined in the ‘Identification Rule’ tab of a CI class. Click on ‘Add’ and then define the ‘Active record condition’. For example, the following screenshot shows how to set an inclusion rule for the ‘Computer’ CI class with the condition Operation status=Operational.

2. Reconciliation rules

CI reconciliation rules play a vital role in maintaining the integrity and accuracy of the Configuration Management Database (CMDB). These rules are important to resolve conflicts and discrepancies that arise when multiple data sources update the data for the same CI class in the CMDB. For example, if both ServiceNow discovery and an integration from a third-party data source (e.g., SCCM) are updating the same CI, reconciliation rules determine which data source should have higher priority.

2.1 How to access Reconciliation rules?

It can be accessed using any of the following 2 methods:

1. Navigate to ‘CI class manager’. Search for any CI class that you want to check (e.g., Server) and open it. Click on the ‘Reconciliation Rules’ tab

This method is more suitable for checking all the reconciliation rules defined for any specific CI class.

2. Go to ‘Identification/Reconciliation>Reconciliation Definitions’ from the application navigator.

This method is useful for checking and analyzing reconciliation rules defined across all CI classes.

2.2 How to configure Reconciliation rules?

Go to the ‘Reconciliation Rules’ tab of the required CI class (E.g., Server) from the CI class manager as mentioned in section 3.1. Click on the Add button under ‘Reconciliation Rules’ section.

Step 1: A window will appear with the tab named ‘Add Discovery Sources & Prioritize’. Specify each ‘Discovery source’ and its ‘Priority’ using the + button. Then click on the ‘Next’ button to move to the next tab. The following screenshot indicates that ServiceNow discovery will be given a higher priority over manual entry as per this reconciliation rule.

Step 2: From the ‘Select Attributes’ tab, choose the attributes for which this rule will be applicable. The ‘Apply to all attributes’ option can be enabled if we need to use the rule for all attributes of that class. As per the attributes selected in the following screenshot, manual entry will not be able to overwrite the data from ServiceNow Discovery for Manufacturer, Model ID, Name, and Serial Number.

Step 3: From the ‘Set Filter Condition’ tab, define a filter condition only if you need to restrict this reconciliation rule to CIs that meet some criteria. Click on ‘Save’ to finish creating the rule.

Note: Multiple reconciliation rules can be created for the same CI class to define discovery sources and their priorities for various attributes that are populated in the CI class.

2.3 Dynamic reconciliation rules

What we saw in Section 3.2 are static reconciliation rules. Dynamic reconciliation rules were introduced in the San Diego release. We need to enable Multisource CMDB to use this feature. Dynamic reconciliation rules can be used to choose one of the following types of values from the Multisource CMDB data:

• First Reported
• Most Reported
• Last Reported
• Largest Value
• Smallest Value

If the same CI attribute has both static and dynamic reconciliation rules, the dynamic reconciliation rule will take precedence.

2.4 Data refresh rules

This feature can be used to specify when to determine if a CI is stale for a specific discovery source and override the static reconciliation rule for stale CIs so that they can be updated by a lower-priority authorized discovery source. They are present on the ‘Reconciliation Rules’ tab itself. Click Add and then specify the ‘Discovery Source’ and its ‘Effective Duration’ (i.e., the number of days beyond which the CI will be considered as stale for that data source). Click ‘Save’ to create the rule.

For example, let’s consider that the following data refresh rule is defined for the ‘Server’ class. As per this, a lower priority data source would be able to update the data for all Server CIs that are NOT updated in 14 days by ServiceNow discovery.

2.5 Best practices to consider for CI reconciliation rules

Identify all the CI classes that are populated by more than one method (even if it is just discovery + manual entry only). List down the key attributes that are being populated in these classes from various data sources or methods. Discuss with various stakeholders like the configuration manager, various CI class owners, teams that manage each data source (e.g., SCCM team), etc. to understand which data source or method should be given higher priority for different attributes. Also, discuss and understand whether we need to define data refresh rules and dynamic reconciliation rules for any of these CI classes.

3. IRE data source rules

Consider a scenario in which a certain data source is no longer trusted to create new CIs in a particular class, but it can be trusted to update existing CIs only. IRE data source rules can be created to prevent a specific data source from inserting new CIs for a specific class. For example, the following rule indicates that insert is not allowed from the LANDesk data source to the Computer CI class.

Only a single IRE data source rule can be active for any pair of CI class and data source.

Conclusion

The CMDB is a very powerful database that can support the business objectives of an organization across a multitude of IT and non-IT functions across the enterprise. An inaccurate, incomplete, or outdated CMDB can lead to erosion of user trust. This will impact all the business functions that leverage the CMDB. Properly reviewing and defining CI identification rules as well as reconciliation rules for each CI class will help to avoid a lot of CMDB data quality issues.

The post ServiceNow CMDB Identification and Reconciliation Engine (IRE) appeared first on ServiceNow Guru.

Add a UI Action Context Menu to Show a BSM Map for a CI

This UI Action allows you to access (via a right-click context menu) a Business Service Map for any Configuration Item listed in the ‘Affected CIs’ related list.

Special thanks to Peter Oneppo for building the bulk of this script during a customer visit we had together this week!

function showBSMMapList() {
//Retrieve the 'Affected CI' record
var sysId = typeof rowSysId == 'undefined' ? gel('sys_uniqueValue').value : rowSysId;
var gr = new GlideRecord('task_ci');
gr.get(sysId);//Build the BSM map URL
var attribs = 'table=cmdb_ci';
attribs += ',id=' + gr.ci_item;
attribs += ',level=4';
attribs += ',ref=' + g_form.tableName + '.cmdb_ci';
attribs += ',ciview=';
attribs += ',restack=true';
var url = new GlideURL('bsm_map2.do');
url.addParam('sysparm_nameofstack', 'bsm');
url.addParam('sysparm_attributes', attribs);

//Open the BSM map URL in a new window
var w = getTopWindow();
w.popupOpenFocus(url.getURL(), 'show_bsm_map', 950, 700, '', false, false);
}

If you’ve set up the UI Action correctly, you should now be able to right-click a row in the ‘Affected CIs’ related list and display a BSM map by clicking the ‘Show CI Map’ option.

Add a UI Action Context Menu to Show Related Tasks for a CI

Using a similar concept to that described above, you can create a context menu UI Action to display a dialog containing all associated, active tasks for any Configuration Item in the ‘Affected CIs’ related list.

function showTasksDialogList() {
//Retrieve the 'Affected CI' record
var sysId = typeof rowSysId == 'undefined' ? gel('sys_uniqueValue').value : rowSysId;
var gr = new GlideRecord('task_ci');
gr.get(sysId);//Create and display the GlideDialogWindow
var w = new GlideDialogWindow('show_list');
w.setTitle('Other active tasks affecting this Configuration Item');
w.setPreference('table', 'task_list');
w.setPreference('sysparm_view', 'default');
w.setPreference('sysparm_query', "active=true^sys_id!=" + g_form.getUniqueValue() + "^SUBQUERYsys_id,task,task_ci^ci_item=" + gr.ci_item + "^ENDSUBQUERY^GROUPBYsys_class_name");
w.render();
}

If you’ve set up the UI Action correctly, you should now be able to right-click a row in the ‘Affected CIs’ related list and display a dialog showing open tasks for the CI by clicking the ‘Show Related Tasks’ option.

The post CI UI Macro Actions for the Affected CIs List appeared first on ServiceNow Guru.

This setup allows you to track a primary CI or Business Service against a given task in the field on the form, and it also allows you to track multiple Affected CIs against a task if necessary in the related list. What I don’t like about this setup is that these are managed independently so there’s not a single place to see ALL of the Affected CIs in your environment. My solution to this problem has always been to centralize all of this information into the ‘Affected CIs’ related list by copying the ‘Configuration Item’ field value into it. This simple idea gives you a much better look into your Affected CIs for reporting, and allows for more proactive troubleshooting through CI Business Service Maps as an input into your task processes.

This customization is pretty simple and can be accomplished through the application of two business rules. The first business rule sits on the ‘Task’ table and should be configured as follows…

if(previous.cmdb_ci){
   removeCI();
}
if(current.cmdb_ci){
   addCI();
}

function removeCI(){
   //Get Affected CI records for this task and delete the CI if necessary
   var rec = new GlideRecord('task_ci');
   rec.addQuery('task', current.sys_id);
   rec.addQuery('ci_item', previous.cmdb_ci);
   rec.query();
   while(rec.next()){
      //Delete the Affected CI record
      rec.deleteRecord();
   }
}

function addCI(){
   //Get Affected CI records for this task and add the CI if necessary
   var rec = new GlideRecord('task_ci');
   rec.addQuery('task', current.sys_id);
   rec.addQuery('ci_item', current.cmdb_ci);
   rec.query();
   if(!rec.next()){
      //Create a new Affected CI record
      var ci = new GlideRecord('task_ci');
      ci.initialize();
      ci.task = current.sys_id;
      ci.ci_item = current.cmdb_ci;
      ci.insert();
   }
}

The second business rule sits on the ‘CIs Affected’ (task_ci) table and should be configured as follows…

//Check the parent task to make sure that the CI is not listed there
if(current.ci_item && current.operation() == 'delete' && current.ci_item == current.task.cmdb_ci){
   //Disallow removal
   gs.addInfoMessage('You cannot remove this CI since it is the primary CI on the associated task.</br>Please change or remove the CI from the task form.');
   current.setAbortAction(true);
}
if(current.ci_item.changes() && current.operation() == 'update' && previous.ci_item == current.task.cmdb_ci){
   //Disallow modification
   gs.addInfoMessage('You cannot change this CI since it is the primary CI on the associated task.</br>Please change or remove the CI from the task form.');
   current.setAbortAction(true);
}

Harnessing the power of the CIs Affected (task_ci) table

Once this is done, any change to the ‘Configuration Item’ field on a task record will automatically result in the creation of an ‘Affected CIs’ entry for that same CI. Now you can set up all of your reports for this area against this table. One of the most powerful things you can do with this data is to set up a BSM Map Action icon that can be displayed to show people from within a BSM map which CIs are being affected by different tasks in the system. There’s a great example on the ServiceNow Wiki that shows you how you can do this.

The post Track Affected CIs in One Place appeared first on ServiceNow Guru.

There are essentially four main steps to accomplish this: decide what classes and fields need to be brought across, create a mapping document, extend the Service-now CMDB to accept the new classes, and send the data from the 3rd party CMDB to Service-now.

1) Decide what classes and fields should be included in Service-now

Every integration discussion starts out the same, “Can Service-now receive my 200+ different CI class types and how long will it take for us to do this?”  While it is good to know the capabilities of Service-now before embarking on such a task, perhaps the more important question that product managers should be asking is, “out of these 200 class types, what are the +/- 20 classes that make sense to integrate with our service desk?”  The first answer is usually, “All of them!”  However, when looked at more carefully, it usually makes sense to only bring over a small subset of the entire collection.

2) Create a mapping document

The difficulty of this step largely depends on the number of classes and fields that were decided in step one.  Again, you’ll want to pear down the number of fields in each class to be small and relevant.  The more common items such as IP address and MAC address will be similarly named in each system.  Determine what fields are missing in SN in this step so that you know which fields need to be added in step 3.

3) Extend the Service-now CMDB

If steps 1 and 2 were done correctly, this step should be straightforward.  The attached video is a demonstration that I put together to show how simple it is to extend the CMDB and how to go about doing it.  You should use your mapping  document to show you which classes need to be added and what fields need to be in those classes.  For the classes that already exist, you will simply be adding the new fields to the already existing class.

4) Send the data to Service-now

This is the step that scares some people and is mistakenly seen and the most difficult and time consuming step.  However, when the previous steps are completed beforehand, this step is actually the simplest of them all.

The most common method of bringing CMDB CI data into Service-now is by using a CSV/XML file. This is a perfect choice when you’re wanting to do a one-time load of CI data into your system. This can be done by creating a new data source and attaching your CSV / XML file to the record. More details on this can be found here: http://wiki.service-now.com/index.php?title=Importing_Data_Using_Import_Sets

In a CMDB integration, the most common way of sending data to Service-now from a 3rd-party is by using JDBC connection to the source of record.  A simple (or not so simple) SQL statement retrieves the classes that you’re interested in and sends them to Service-now to be mapped.

Another common way of sending data to SN is by using web services.  If your CMDB or discovery solution supports sending SOAP, then you might consider this option as well.  I cover this in the attached video as well.

A CMDB integration can be daunting.  However, if you follow this guide, you should have a good idea how to approach it in a way that encourages a successful and timely outcome![youtube]http://www.youtube.com/watch?v=1LeIKFt5ZG8[/youtube]

The post Extending the CMDB appeared first on ServiceNow Guru.

One of the great features of ServiceNow is its CMDB and relational mapping. You can easily set up relationships between any CIs in the system. Once the relationships are defined, it becomes very simple to pull up a visual representation of a CI and its dependencies by using ServiceNow BSM maps.  Using this feature allows an end user to look at that CI and identify what else in the environment is impacted by an outage or a change to that CI.

The ‘CIUtils’ Script Include is designed to help you get some of this information. You can find it by navigating to ‘System Definition -> Script Includes’.  To use it, you could do something like this in a Business rule, UI action, or Scheduled job…

var ciu = new CIUtils();
//Return all of the Business services affected by the current CI on this ticket
var services = ciu.servicesAffectedByCI(current.cmdb_ci);
//Do something with the array of Business Services returned

You can also use the ‘servicesAffectedByTask’ function to use a task record as your input parameter

var ciu = new CIUtils();
//Return all of the Business services affected by the current CI on this ticket
var services = ciu.servicesAffectedByTask(current);
//Do something with the array of Business Services returned

There are a couple of limitations with the CIUtils Script include though. To fill in some of those gaps, I recently created an enhancement to CIUtils called ‘CIUtils2’. It is used in pretty much the same way as the CIUtils Script include, but it gives you these added benefits…

• Return all impacted Business Services based on the ‘cmdb_ci’ field AND the ‘Affected CIs’ related list
• Return all impacted CIs based on the CI classes you specify
• Return all impacted CIs throughout the entire CMDB

To use it, simply create a new Script include record with the script below WITH A NAME OF ‘CIUtils2’. You can then call the functions like this…

gs.include('PrototypeServer');var CIUtils2 = Class.create();

CIUtils2.prototype = {
initialize: function () {
this.maxDepth = gs.getProperty('glide.relationship.max_depth', 10); // how deep to look
this.maxAffectedCIs = gs.getProperty('glide.relationship.threshold', 1000); // max records to return
this.defaultClasses = ['cmdb_ci_service', 'service_offering'];
this.arutil = new ArrayUtil();
},

/**
* Determine which CIs are affected by a specific CI
*
* Inputs:
* id is the sys_id of a configuration item (cmdb_ci)
* classArr is an array of CI class names that should be returned
* infoObj is an object created by _getInfoObj used to track data accross multiple
* calls to the function made by cisAffectedByTask. It is not needed when calling
* the function directly.
*
* Returns:
* an array of sys_id values for cmdb_ci records upstream of
* (or affected by) the input item
*/

cisAffectedByCI: function (id, classArr, infoObj /*optional*/) {
if (!infoObj) {
infoObj = this._getInfoObj();
}
if (infoObj.visitedCIs[id]) {
// We've already processed this CI
return [];
}
infoObj.visitedCIs[id] = true;
if (!classArr || classArr.length == 0) {
classArr = this.defaultClasses;
}

// This is to keep track of affected CIs from this CI only.
// CIs that are already listed in infoObj.affectedCIs from prior
// calls to the function will not be included.
var affectedCIs = [];
var ci = new GlideRecord('cmdb_ci');
if (ci.get(id)) {
//If class = 'ALL' then just add the CI
if (classArr[0] == 'ALL' || this.arutil.contains(classArr, ci.sys_class_name.toString())) {
affectedCIs.push(id);
this._addCI(id, infoObj);
}
this._addParentCIs(id, infoObj, affectedCIs, 1, classArr);
}
return this._unique(affectedCIs); // list of affected CIs
},

/**
* Determine which CIs are affected by a task
*
* Inputs:
* task is a task GlideRecord (e.g., incident, change_request, problem)
* classArr is an array of CI class names that should be returned
*
* Returns:
* an array of sys_id values for cmdb_ci records upstream from
* (or affected by) the configuration item referenced by the task's cmdb_ci field and Affected CIs list
*/

cisAffectedByTask: function (task, classArr) {
var infoObj = this._getInfoObj();
//Find the impacted CIs for the 'cmdb_ci' value
var id = task.cmdb_ci.toString();
if (id) {
this.cisAffectedByCI(id, classArr, infoObj);
}

//Find the impacted CIs for any Affected CIs listed on the task
var affCI = new GlideRecord('task_ci');
affCI.addQuery('task', task.sys_id);
affCI.query();
while (affCI.next()) {
this.cisAffectedByCI(affCI.ci_item.sys_id.toString(), classArr, infoObj);
}
return this._objToArray(infoObj.affectedCIs);
},

/**
* Returns an XML-formatted string showing all CIs impacted by an outage to the CI given
*
* Inputs:
* id is the sys_id of the root CI
*
* Returns:
* an XML-formatted string containing cmdb_ci records downstream of
* (or affected by) the configuration item provided as input
*/

getCIXML: function (id) {
var gr = new GlideRecord('cmdb_rel_ci');
gr.addQuery('child', id);
gr.query();
gr.next();
var str = '';
str += '';
str += '' + gr.child.sys_id + '';
str += '' + gr.child.name + '';
str += 'SELF';
ret = this._recurs(id);
if (ret) {
str += '';
str += ret;
str += '';
}
str += '';
return str;
},

_recurs: function (ci) {
var gr = new GlideRecord('cmdb_rel_ci');
gr.addQuery('child', ci);
gr.query();
var str = '';
while (gr.next()) {
str += '';
str += '' + gr.parent.sys_id + '';
str += '' + gr.parent.name + '';
str += '' + gr.type.name + '';
ret = this._recurs(gr.parent.sys_id);
if (ret) {
str += '';
str += ret;
str += '';
}
str += '';
}
return str;
},

_addParentCIs: function (id, infoObj, affectedCIs, currentDepth, classArr) {
if (infoObj.affectedCIsCount >= this.maxAffectedCIs)
return;

var rel = new GlideRecord('cmdb_rel_ci');
rel.addQuery('child', id);
rel.query();

var parents = [];
while (rel.next()) {
parents.push(rel.parent.toString());
}
if (parents.length) {
var parent = new GlideRecord('cmdb_ci');
parent.addQuery('sys_id', parents);
parent.query();

while (parent.next() && infoObj.affectedCIsCount < this.maxAffectedCIs) {
var pid = parent.sys_id.toString();
if (!infoObj.visitedCIs[pid]) {
infoObj.visitedCIs[pid] = true;
if (classArr[0] == 'ALL' || this.arutil.contains(classArr, parent.sys_class_name.toString())) {
affectedCIs.push(pid);
this._addCI(pid, infoObj);
}
if (currentDepth < this.maxDepth)
this._addParentCIs(pid, infoObj, affectedCIs, currentDepth + 1, classArr);
}
}
}
},

_addCI: function (id, infoObj) {
infoObj.affectedCIs[id] = true;
infoObj.affectedCIsCount++;
},

_getInfoObj: function () {
return {
affectedCIsCount: 0, // track how many added, since can't get size() for an Object
affectedCIs: {}, // full list of affected CIs for specified classes
visitedCIs: {} // track CIs already iterated over
};
},

_objToArray: function (obj) {
var ar = [];
for (var id in obj) {
ar.push(id);
}
return ar;
},

_unique: function (a) {
var obj = {};
for (var idx in a) {
obj[a[idx]] = true;
}
return this._objToArray(obj);
},

type: 'CIUtils2'
};

Another practical example for Change Management

Here’s an example UI action that I use for almost all of my clients. In change management, you’re often interested in the business services that will be impacted by a given change. While you can see this in a BSM map, it’s often useful to see this in a related list directly on your change form as well. By adding the ‘Impacted Services’ related list to your change form, you can populate this data. This UI action gathers all of the information about the CIs on your change request and adds the impacted services to the list.

current.update();
action.setRedirectURL(current);
removeAffectedServices();
addAffectedServices();function removeAffectedServices() {
var m2m = new GlideRecord('task_cmdb_ci_service');
m2m.addQuery('task',current.sys_id);
m2m.addQuery('manually_added','false');
m2m.query();
m2m.deleteMultiple();
}function addAffectedServices() {
var ciu = new CIUtils2();
//Find all impacted business services
var services = ciu.cisAffectedByTask(current);
//var services = ciu.cisAffectedByTask(current, ["cmdb_ci_service", "cmdb_ci_windows_server"]);
//var services = ciu.cisAffectedByTask(current, ["ALL"]);
var m2m = new GlideRecord('task_cmdb_ci_service');
for (var i = 0; i < services.length; i++) {
m2m.initialize();
m2m.task = current.sys_id;
m2m.cmdb_ci_service = services[i];
m2m.manually_added = 'false';
m2m.insert();
}
}

The post Walking the ServiceNow CMDB Relationship Tree appeared first on ServiceNow Guru.