Use Case: Reporting Incidents with QR Codes

Let’s start with the use case. Picture QR codes placed in various locations like meeting rooms, printers, or other office equipment. These QR codes contain URLs with parameters that correspond to the sys_id of the Configuration Item (CI) or asset in the ServiceNow CMDB. When a user scans the QR code, it directs them to an Incident Record Producer with important fields such as Location, Asset Information already filled in. This links the reported issue directly to the correct asset and location, allowing the helpdesk team to quickly identify and resolve the problem, while freeing the user from having to manually enter all the details.

Technical Solution: Catalog Client Script for Parsing URL Parameters

To make this work, we need a catalog client script that reads the URL parameters and maps them to variables with the same name as the “key” in the URL. Here’s the script:

/**
 * Populates catalog variable fields with values from URL parameters.
 * @function
 * @throws {Error} Throws an error if an unexpected situation occurs.
 */
function onLoad() {
    try {
        /** Get the parameters from the URL */
        var _window = window ? window : this.window;
        var urlParams = new URLSearchParams(_window.location.search);

        /** Iterate over each parameter in the URL */
        urlParams.forEach(function(value, key) {
            try {
                /** Check if a variable with the same name exists in the catalog form */
                var variable = g_form.getControl(key);
                if (variable) {
                    /** Set the value in the catalog variable field */
                    g_form.setValue(key, value);
                }
            } catch (innerError) {
                /** Handle errors that occur during iteration */
                console.error('Error during parameter iteration:', innerError);
            }
        });
    } catch (error) {
        /** Handle errors that occur during the main execution */
        console.error('An unexpected error occurred:', error);
        /** You may choose to throw the error again or handle it differently based on your requirements. */
    }
}

How the Script Works

1. Get the Parameters from the URL: The script starts by checking if the window object is available. It then creates a URLSearchParams object from the URL’s query string, which allows easy access to the URL parameters.
2. Iterate Over Each Parameter: The script uses the forEach method to iterate over each key-value pair in the URL parameters.
3. Check for Matching Variables: For each parameter, the script checks if there is a corresponding variable in the catalog form with the same name as the key. It does this using the g_form.getControl(key) method.
4. Set the Variable Value: If a matching variable is found, the script sets its value to the corresponding value from the URL parameter using the g_form.setValue(key, value) method.
5. Error Handling: The script includes error handling to catch and log any errors that occur during the main execution or the iteration over parameters. This ensures that any issues are logged for debugging purposes.

Implementation Steps

Here’s how you can set up the QR code solution:

1. Create a Variable Set: Go to Service Catalog > Catalog Variables > Variable Sets and create a new variable set. Name it something generic and understandable, such as “URLParameterMapper” or “URLVariableBinder,” following your organization’s naming conventions. Add the catalog client script provided above to this variable set.
2. Generate QR Codes: Create QR codes that encode URLs pointing to the Incident Record Producer. Make sure the URLs include parameters for the CI/asset sys_id.
3. Create Record Producers or Catalog Items: Set up record producers or catalog items with their own variables or variable sets. Either match the variable names to the keys in the URL parameters, or create the QR code URL so that the keys match the variable names in the record producer. Otherwise, the variables won’t map correctly and won’t populate from the URL.
4. Add the Variable Set: Add the variable set from step 1 to the record producers or catalog items created in step 3.

Conclusion

By following these steps, users can easily raise incidents by scanning QR codes, with the incident form pre-filled with relevant information from the URL parameters. This streamlines the process of incident creation and ensures accurate reporting of issues related to specific CIs or assets.

The post QR Code-Based Incident Creation from URL Parameters appeared first on ServiceNow Guru.

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.

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.

While this solution probably isn’t for everybody, it might save somebody some work down the road so I’ll post it here :).

We were able to accomplish this by setting up an ‘HTML’ type of module under the application where we wanted the collapsible modules. Here are a couple of screenshots showing the end result for the ‘Configuration’ application…

Application Sections Expanded

Application Sections Collapsed

Here’s how you could set this up in your system for the ‘Configuration’ application. If you want to use this on other applications, simply replace all occurrences of ‘CMDB’ in the arguments below with a name that will be unique to the application that you set the module up for.

<span  id="expand_appsection_CMDB" style="display: none; cursor: pointer; font-weight: bold;" onclick="collapseAppSections_CMDB(this);"><img src="images/icons/nav_collapseall.gifx"/>Collapse All Sections</span>
<span  id="collapse_appsection_CMDB" style="display: block; cursor: pointer; font-weight: bold;" onclick="expandAppSections_CMDB(this);"><img src="images/icons/nav_expandall.gifx"/>Expand All Sections</span>
 
<script>
function collapseAppSections_CMDB(el) {
   var items = el.up('.submenu').select('tr[id*=children.]').each(function(item){
      var itemEl = $(item.id.split('.')[1]);
      if(itemEl.getStyle('display') == 'block'){
         toggleSectionDisplay(itemEl.id,'arrow','');	
      }
   });
   $('collapse_appsection_CMDB').show();
   $('expand_appsection_CMDB').hide();
}

function expandAppSections_CMDB(el) {
   var items = el.up('.submenu').select('tr[id*=children.]').each(function(item){
      var itemEl = $(item.id.split('.')[1]);
      if(itemEl.getStyle('display') == 'none'){
         toggleSectionDisplay(itemEl.id,'arrow','');	
      }
   });
   $('expand_appsection_CMDB').show();
   $('collapse_appsection_CMDB').hide();
} 
</script>

The post Expand/Collapse All Separator Modules at Once appeared first on ServiceNow Guru.

This solution relies on 2 simple customizations. For the purposes of this article, I’ll assume that we want to provide aliases for a few of the records in the Configuration Item (cmdb_ci) table. The first step is to create a new field on the ‘cmdb_ci’ table called ‘Alias for’. This field should be a reference field to the same table you create the field on…in this case the field needs to reference ‘cmdb_ci’. The purpose of the field is so that you can create a CI record that has no other purpose other than to point to another CI record. Your alias becomes a CI and it points to the true CI populated in the ‘Alias for’ field.

Once you have the ‘Alias for’ field set up and you have an alias populated, the next step is to create a client script to populate the true CI value when an alias is used. In this case, we want to set up the alias functionality for the ‘Configuration item’ field on all Task tables (Incident, Problem, Change, etc.). Our client script should be set up on the task table with the following settings…

function onChange(control, oldValue, newValue, isLoading) {
//If the page isn't loading
if (!isLoading) {
//Hide any field message on the 'cmdb_ci' field
g_form.hideFieldMsg('cmdb_ci');
//If the new value isn't blank
if(newValue != '') {
//Check to see if the CI is an alias
var rec = g_form.getReference('cmdb_ci');
if(rec.u_alias_for != ''){
//Populate the value of the true CI
g_form.setValue('cmdb_ci', rec.u_alias_for);
g_form.showFieldMsg('cmdb_ci','CI populated from alias');
}
}
}
}

The post Creating an Alias for Reference Field Searches appeared first on ServiceNow Guru.

The post Viewing CI Subscription Notifications 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.