Creating EA Sync payloads

The contents of this page require you are familiar with creating Discovery payloads for the standard Cookdown Discovery product. If you are not familiar with this process. please review this page firstly as the majority of the concepts and approach is the same.

An EA Sync Payload is very similar to the payload you will have used to push up CIs for objects not in an EA with the below important changes, and as with our standard Discovery product, the Discovery payload library contains payloads for common technologies that are EA Sync compatible. EA Sync compatible payloads names contain “EAs Y” in their name.

EAs mapped to Services

An EA Sync payload must contain the mapping between the EA itself from SCOM and a Service type from your ServiceNow instance. EAs contain two useful properties:

  • EA Name

  • SCOM Object Id

We use these properties to create Services in ServiceNow. Consider the below examples:

Example payload without EA - IIS 10 ASP.net Application Endpoint

The below payload is used where SCOM objects of class “IIS 10 ASP.net Application Endpoint” are not part of an EA.

{
  "items": [
    {
      "className": "cmdb_ci_web_site",
      "lookup": [],
      "values": {
        "tcp_port": "Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::ServerBindings,Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::SecureBindings",
        "short_description": "Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::Description",
        "name": "Microsoft.Windows.InternetInformationServices.10.0.AspNetWebApplicationEndpoint::System.Entity::DisplayName",
        "config_directory": "Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::Path",
     "correlation_id": "Microsoft.Windows.InternetInformationServices.10.0.AspNetWebApplicationEndpoint:ObjectId, Microsoft.Windows.InternetInformationServices.10.0.WebSite:ObjectId"
      }
},
{
      "className": "cmdb_ci_microsoft_iis_web_server",
      "lookup": [],
      "values": {
        "version": "Microsoft.Windows.InternetInformationServices.10.0.ServerRole::Microsoft.Windows.InternetInformationServices.ServerRole::MajorVersion.Microsoft.Windows.InternetInformationServices.10.0.ServerRole::Microsoft.Windows.InternetInformationServices.ServerRole::MinorVersion",
        "sys_class_name": "cmdb_ci_microsoft_iis_web_server",
        "name": "Microsoft.Windows.InternetInformationServices.10.0.WebServer::System.Entity::DisplayName@Microsoft.Windows.Computer:::NetbiosComputerName",
        "correlation_id": "Microsoft.Windows.InternetInformationServices.10.0.WebServer:ObjectId"
      }
    },
    {
      "className": "cmdb_ci_win_server",
      "lookup": [],
      "values": {
        "name": "Microsoft.Windows.Computer:::NetbiosComputerName",
        "correlation_id": "Microsoft.Windows.Computer:ObjectId"
      }   
    }
    
  ],
  "relations": [
    {
      "type": "Hosted on::Hosts",
      "parent": 0,
      "child": 1
    },
    {
      "type": "Runs on::Runs",
      "parent": 1,
      "child": 2
    }
  ]
}

Example payload with EA - IIS 10 ASP.net Application Endpoint

The below payload is the same as the above example except where the EA is mapped to cmdb_ci_service_discovered (ServiceNow Application Service CI Class).

{
  "items": [
    {
      "className": "cmdb_ci_web_site",
      "lookup": [],
      "values": {
        "tcp_port": "Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::ServerBindings,Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::SecureBindings",
        "short_description": "Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::Description",
        "name": "Microsoft.Windows.InternetInformationServices.10.0.AspNetWebApplicationEndpoint::System.Entity::DisplayName",
        "config_directory": "Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::Path",
     "correlation_id": "Microsoft.Windows.InternetInformationServices.10.0.AspNetWebApplicationEndpoint:ObjectId, Microsoft.Windows.InternetInformationServices.10.0.WebSite:ObjectId"
      }
},
{
      "className": "cmdb_ci_microsoft_iis_web_server",
      "lookup": [],
      "values": {
        "version": "Microsoft.Windows.InternetInformationServices.10.0.ServerRole::Microsoft.Windows.InternetInformationServices.ServerRole::MajorVersion.Microsoft.Windows.InternetInformationServices.10.0.ServerRole::Microsoft.Windows.InternetInformationServices.ServerRole::MinorVersion",
        "sys_class_name": "cmdb_ci_microsoft_iis_web_server",
        "name": "Microsoft.Windows.InternetInformationServices.10.0.WebServer::System.Entity::DisplayName@Microsoft.Windows.Computer:::NetbiosComputerName",
        "correlation_id": "Microsoft.Windows.InternetInformationServices.10.0.WebServer:ObjectId"
      }
    },
    {
      "className": "cmdb_ci_win_server",
      "lookup": [],
      "values": {
        "name": "Microsoft.Windows.Computer:::NetbiosComputerName",
        "correlation_id": "Microsoft.Windows.Computer:ObjectId"
      }   
    },
    {
      "className": "cmdb_ci_service_discovered",
      "lookup": [],
      "values": {
        "name": "EnterpriseApplication:::DisplayName",
        "correlation_id": "EnterpriseApplicationGroup:::ApplicationId",
        "service_classification": "Application Service"
      }
    }
  ],
  "relations": [
    {
      "type": "Hosted on::Hosts",
      "parent": 0,
      "child": 1
    },
    {
      "type": "Runs on::Runs",
      "parent": 1,
      "child": 2
    },
    {
      "type": "Depends on::Used by",
      "parent": 3,
      "child": 0
    }
  ]
}

Looking at the differences in the values section of the payload in more detail:

{
"className": "cmdb_ci_service_discovered",
"lookup": [],
"values": {
"name": "EnterpriseApplication:::DisplayName",
"correlation_id": "EnterpriseApplicationGroup:::ApplicationId",
"service_classification": "Application Service"
}
}

Purple = The ServiceNow CI class that EAs should be created as (in this case the Application Service class, cmdb_ci_service_discovered). To switch from this class to another, simply replace the selected table with your desired one (EG cmdb_ci_service for Business Service)

Green = The EA’s keys from the second set of keys that are displayed as part of the Create Discovery wizard. For this example, we have used the correlation_id field to hold the SCOM object ID - this field may be used by other discovery tools (EG ServiceNow SCCM Discovery) so check before using the same field in your instance.

The other key addition in the second of the above payloads is the relationship definition, which defines the relationship between the Service which will be created, and the CIs that will make up the Service.

{
"type": "Depends on::Used by",
"parent": 3,
"child": 0
}

In this example we want the parent (the depends on side of the relationship) to be the Application Service and the child (the used by side of the relationship) to be the IIS Website. Position 0 in these relationships is the first CI Class listed in the payload (so in this case the Web site/cmdb_ci_web_site), which means that the Application Service (cmdb_ci_service_discovered) is position 3 as it the 4th CI class defined in the payload.

The type of relationship you use is up to you, the only hard requirement is that the relationship type you pick is defined in your ServiceNow instance and is available on the ServiceNow CI Class you are pushing CIs to, however, the relationship type you pick will set whether Incidents that are raised against the created CIs flow up the hierarchy or not. for more info see ServiceNow’s documentation.

Example payload outcomes - IIS 10 ASP.net Application Endpoint

The below screenshots show the result of pushing up CIs using these example payloads in ServiceNow (from ServiceNow’s dependency viewer).

For CIs contained in an EA

For CIs that aren't contained in an EA

Mapping EA’s groups to ServiceNow

When you map apps in Squared Up’s VADA tool, the objects that are discovered are grouped and these groups are given logical names. See the below example containing groups “SCOM_12”, “DB” and “Web”:

It is possible to create these groups within ServiceNow as nested Services. The below guide tells you how to set this up and show you what the result is, but while the result is visually pleasing, note that creating these groups is not ServiceNow best practice as not all discovery tools contain the notion of groups so cannot be reproduced consistently across multiple discovery tools.

Groups are exposed by Cookdown discovery as keys in the “EA sync variables” stage of the wizard. Keys for the SCOM Object ID and Group name are made available:

The below payload shows an example of how these keys are used, again for the IIS 10 ASP.net application endpoint SCOM class:

{
  "items": [
    {
      "className": "cmdb_ci_web_site",
      "lookup": [],
      "values": {
        "tcp_port": "Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::ServerBindings,Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::SecureBindings",
        "short_description": "Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::Description",
        "name": "Microsoft.Windows.InternetInformationServices.10.0.AspNetWebApplicationEndpoint::System.Entity::DisplayName",
        "config_directory": "Microsoft.Windows.InternetInformationServices.10.0.WebSite::Microsoft.Windows.InternetInformationServices.WebSite::Path",
        "correlation_id": "Microsoft.Windows.InternetInformationServices.10.0.AspNetWebApplicationEndpoint:ObjectId, Microsoft.Windows.InternetInformationServices.10.0.WebSite:ObjectId"
      }
    },
    {
      "className": "cmdb_ci_microsoft_iis_web_server",
      "lookup": [],
      "values": {
        "version": "Microsoft.Windows.InternetInformationServices.10.0.ServerRole::Microsoft.Windows.InternetInformationServices.ServerRole::MajorVersion.Microsoft.Windows.InternetInformationServices.10.0.ServerRole::Microsoft.Windows.InternetInformationServices.ServerRole::MinorVersion",
        "sys_class_name": "cmdb_ci_microsoft_iis_web_server",
        "name": "Microsoft.Windows.InternetInformationServices.10.0.WebServer::System.Entity::DisplayName@Microsoft.Windows.InternetInformationServices.10.0.WebServer::Microsoft.Windows.Computer::PrincipalName",
        "correlation_id": "Microsoft.Windows.InternetInformationServices.10.0.WebServer:ObjectId"
      }
    },
    {
      "className": "cmdb_ci_win_server",
      "lookup": [],
      "values": {
        "name": "Microsoft.Windows.Computer:::NetbiosComputerName",
        "correlation_id": "Microsoft.Windows.Computer:ObjectId"
      }
    },
    {
      "className": "cmdb_ci_service_discovered",
      "lookup": [],
      "values": {
        "name": "EnterpriseApplication:::DisplayName",
        "correlation_id": "EnterpriseApplicationGroup:::ApplicationId",
        "service_classification": "Application Service"
      }
    },
    {
      "className": "cmdb_ci_service_discovered",
      "lookup": [],
      "values": {
        "name": "EnterpriseApplicationGroup:::DisplayName",
        "correlation_id": "EnterpriseApplicationGroup:::GroupId",
        "service_classification": "Technical Service"
      }
    }
  ],
  "relations": [
    {
      "type": "Hosted on::Hosts",
      "parent": 0,
      "child": 1
    },
    {
      "type": "Runs on::Runs",
      "parent": 1,
      "child": 2
    },
    {
      "type": "Depends on::Used by",
      "parent": 4,
      "child": 0
    },
    {
      "type": "Depends on::Used by",
      "parent": 3,
      "child": 4
    }
  ]
}

As you will see this payload is more or less identical to the EA sync example from earlier on this page. We have added an additional Application Service containing the group keys and a Service classification of Technical Service (so you can filter out groups from the Application Services table from the Application Services themselves):

{
     "className": "cmdb_ci_service_discovered",
     "lookup": [],
     "values": {
       "name": "EnterpriseApplicationGroup:::DisplayName",
       "correlation_id": "EnterpriseApplicationGroup:::GroupId",
       "service_classification": "Technical Service"
     }
}

You will also note an additional relationship which relates the group to the EA:

 {
      "type": "Depends on::Used by",
      "parent": 4,
      "child": 0
    },

Finally, we updated the parent/child relationships, originally between the EA and the Website, to relate the Website to the Group.

Outcomes

You will see from the below screenshot the outcome of this updated payload is to insert an extra Application Service between the EA and the IIS 10 ASP.net Application Endpoint’s CIs for the group:

Search