Table of Contents

Introduction

CMDB tables will generally be available to anyone in ITS. ServiceNow's built-in web services enables the derivation of data service endpoints which, combined with knowledge of the data model, lets people and applications consume CMDB data for other purposes. This document defines:

• a set instructions for constructing URLs to identify the CMDB data and metadata exposed by Yale's ServiceNow instances
• a list of query operators for data filtering
• an explanation of the schema so users/agents can grok what they're pulling
• a list examples containing ready-made, commonly requested URLs

Obtaining a Service Account

If you want to do non-interactive batch work, you must obtain a service account. We generally hand these out by department or application. Request a service account by clicking here. Please be sure to:

• mention the department or application name
• route the request to the INF SN App Support group.

URL Building

ServiceNow's documentation for this is their wiki: https://wiki.servicenow.com/index.php?title=Navigating_by_URL. Yale specifics are below.

Server

URL construction begins with the instance names. Below are the instances by environment; generally, you will want production, pre-production, or testing for most purposes.

Tables

The next component is the table. The table name is used in API calls - note that table names in the schema don't always match the object's display name in the ServiceNow UI.

¹ technically, these is not a CMDB table as categories are not CIs in ServiceNow. Use of the available "CMDB" view is recommended for this table.

Query Construction

UI Constuction

• go to the application navigator (Left Pane, Configuration application)
• select the desired class (IT Provider Services, Applications, Modules, etc)
• when the list view appears, you can adjust the filter as desired (see the arrow at the left of the breadcrumb)
• when you have the correct query, right-click on the last term of the breadcrumb and click "Copy Query"
• urlencode this query (optionally, if you use the same steps and click "Copy URL" you will get the encoded query)

External Construction

Sometimes it's quicker to generate a long query with cut-and-paste or a script, especially if there are a lot of similar terms. In this case, you can use the primitives as documented by ServiceNow: Navigating by URL: Elements. Common elements:

• sysparm_view= - followed by a view name. Views are used at the sysadmin's discretion for filtering out columns or presenting joins.
• sysparm_query= - followed by a query spec.
• sys_id= - followed by a 32-byte GUID, used to specify a list of one or more individual records. Used for manually cross-referencing table references.

Data Formats

Depending on your access rights, you can specify a data format at the end by appending this sequence:
%26▉▉▉ or &▉▉▉: specifies a file format, ▉▉▉ possible values are CSV, XML, PDF, or UNL (Unload).

Otherwise, you'll see the list view in the ServiceNow UI.

Views

Different groups have different data needs. When using some data types, exports can be done against a specified view, which can provide a specific set of fields. Example views are "eGRC" (for cmdb_ci_application) and "CMDB" (for sc_category).

URL Examples

Combine the querie with the desired instance name, along with the the https scheme, to get a URL.

CMDB Schema

Overview

The CMDB is represented in an object-oriented fashion. There are some key points to understand:

• Labels are the table and field names seen in the UI. The underlying schema names may differ.
• different cmdb_ci_* tables represent different classes of CI. Each class self-identifies via the Class sys_class_name column.
• CI classes exhibit a hierarchy:
  • cmdb_ci is the base class for CI types. From the systems's perspective, anything in this table or child tables are CIs. So listing all cmdb_ci rows will also show you rows in child tables (e.g. cmdb_ci_appl)
  • Child classes are extensions of the parents, so they inherit the parent columns
  • Child classes may (and probably will) have their own type-specific columns
• For scope purposes, separate classes may have columns of the same name, but belong to the child and not the parent.
• relationships have two common types:
  • references (many-to-one) - a column that points to another record.
  • relationships (many-to-many) - a m2m table which glues many records to many others. The CMDB uses cmdb_rel_ci to do this, though custom m2m tables may exist.

Understanding Relationships

cmdb_ci_rel has three fields:

• parent - a GUID (sys_id) of the "parent" record of the relationship
• child - a GUID (sys_id) of the "child" record of the relationship
• type - the selected relationship type. The semantics of the various types are subject to revision. To start, we are creating a generic "Parent of::Child of" and using that by default.

Label to Schema Mappings

Schema names underlying table and field labels can be seen in the sys_documentation table. For convenience, here are the some labels filtered by CI type: