Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Intro

Server CI data are collected in two ways:

  • periodic SCCM data import (federated data about Windows servers)
  • periodic SNMP discovery (instrumented data about UNIX servers)

Use Cases

The initial requirement is to:

  • deliver an updated list of servers (Infrastructure groups, Windows and UNIX)

...to which ITIL users can associate incidents, changes, or problems, as with other CI types.

Fields

These exact header names must be present in the source file, and are subject to the following conditions:

Servers

Business Service Field Label

Rules

"Serial Number"

text

"Number"

must be unique

"Service Category"

must match an existing Category name, else ignored ¹

"Service State"

must be: "Planned", "Active", "Deprecated", "Inactive", else ignored

"Portfolio Owner UPI"

must match an existing user UPI in ServiceNow, else ignored

"Service Owner UPI"

must match an existing user UPI in ServiceNow, else ignored

Provider Services

Provider Service Fields

Rules

"Provider Service Name"

text

"Number"

must be unique

"Service Category"

must match an existing Category name, else ignored ¹

"Service State"

must be: "Planned", "Active", "Deprecated", "Inactive", else ignored

"Portfolio Owner UPI"

must match an existing user UPI in ServiceNow, else ignored

"Service Owner UPI"

must match an existing user UPI in ServiceNow, else ignored

"Support Assignment Group"

must match an existing group name in ServiceNow, else ignored

Applications

Application Fields

Rules

"Name"

text

"AI Record ID#"

must be unique

"State"

must be: "Planned", "Active", "Deprecated", "Inactive", else ignored

"Platform Testing Required"

must be "TRUE", "FALSE", or blanks interpreted as "FALSE"

"Brief Description"

text

"Support Assignment Group"

must match an existing group name in ServiceNow, else ignored

"Vendor Name"

if blank, will default to "Yale University"

"Primary Support UPI"

must match an existing user UPI in ServiceNow, else ignored

"Secondary Support UPI"

must match an existing user UPI in ServiceNow, else ignored

Modules

Module Fields

Rules

"Module Number"

must be unique

"Module Name"

text

"Status"

must be: "Planned", "Active", "Deprecated", "Inactive", else ignored

"Parent Application Number"

must match existing application number, else ignored

Data Sources

Since there is no official data ensconced in an existing database, and the Configuration process is new, it was decided as an interim step to bootstrap updates via simple spreadsheets, which have been exposed via Box.com. Each file has a corresponding data source and transform map in ServiceNow.

One person per table is responsible for content updates, which are filtered through a transform map; this serves as a choke point for enforcement of the contract, and avoids immediate changed to existing processes, delaying the implementation ACLs, business rules, and workflow in ServiceNow until the relevant process changes have a chance to develop.

Business Services.xls
Provider Services.xls
Applications.xls
Modules to App Relationships.xls

Data Contract

  • The ITSM organization is responsible for the source data content; the POC is Adriene Radcliffe for now. Eventually this will have to be managed via other means yet to be specified (change management, delegates).
  • spreadsheets containing data will exist at the above data source URLs (don't delete these files, or the integration will break)
  • must remain XLS (Excel 97/2000) format
  • must remain publicly accessible
  • data will be loaded daily at midnight

Data Source - CMDB Business Services
Data Source - CMDB Provider Services
Data Source - CMDB Applications

¹ To find categories as maintained by the Request Process, use the Category on the desired instance; URI:
/sc_category_list.do?sysparm_userpref_module=544cce908795810094ad56926d434de8&sysparm_view=CMDB

  • No labels