Discovery Payload Library

Cookdown provide payloads for commonly used technologies which you are free to use/modify on the Discovery Payload Store:

https://github.com/cookdown/DiscoveryPayloadLibrary

Before discovering using these payloads, please read this document as there are some important points to consider before using them, that if not planned for will result in duplicate CIs or undesired results in your ServiceNow instance.

What store payloads are good for

  • Greenfield environments with no other CMDB discovery sources

  • CMDBs that discover from ServiceNow's own discovery tool – these payloads will result in CIs compatible with those from ServiceNow Discovery. They have been built around compatibility with ServiceNow's own discovery tool

  • ServiceNow's out of the box Identification and Reconciliation rules – if a payload requires any Identification and Reconciliation rule changes from default it will be noted in the readme within each file or within this readme

  • Getting inspiration for your own custom payloads

What store payloads are not good for

  • CMDB population without the Cookdown Discovery product – they won't do anything without it

  • Highly customized CMDBs – if there are CMDB fields made mandatory that we have not planned to populate, discovery will fail

  • ServiceNow instances with custom Identification and Reconciliation rules – these payloads have been designed around compatibility with CIs from ServiceNow's own discovery product. Please review the payload(s) you would like to use before pushing CIs with them to avoid duplicate CIs when used with your custom/modified rules

  • CMDBs which use ServiceNow's SCCM discovery tool – these payloads use the "correlation_id" field for storing the SCOM object ID of each discovered CI into ServiceNow. The SCCM discovery tool uses this same field so avoid the SCCM correlation ID being overwritten or duplicate CIs, simply change the correlation_id field in these payloads for another field to make them compatible with the ServiceNow SCCM discovery tool

Other important considerations

The "Correlation_id" field is used to store the SCOM object ID with each CI. If you have another discovery tool that uses this same field (like the SCCM discovery tool from ServiceNow) then use a different field for the SCOM object ID.

Do not use payloads from this store without first testing what they will do in your own environment or you risk creating duplicate CIs or unusual relationships in your CMDB.

Service Mapping and store payloads

For customers with the Cookdown Mapping solution, we provide payloads to create Application Services in your ServiceNow instance. These payloads (those with "Y EAs" in their name) are designed to push mapped applications from SCOM into ServiceNow and to relate the CIs they create to them, or for example the SQL database payload created SQL databases and relates them to the mapped application. These payloads push applications into the "Application Service" CI class (table cmdb_ci_service_discovered). If this is not the desired type of service simply change the CI class that is mentioned in each payload.

Payloads whose name contains "Y EAs and Y Groups" will create an Application Service for both the mapped application and the groups displayed in the Squared Up VADA UI – pushing up the groups is visually pleasing when viewing the created Application Services in ServiceNow, but is not ServiceNow best practice.

Out of the box, ServiceNow ships with no Identification rule for Business/Application Services, so for mapping payloads to work an Identification Entry needs to be created, identifying apps as unique based on "name" and "correlation_id" (or whichever field you choose to store the SCOM object ID in your CMDB).

Full documentation on Cookdown Discovery and Mapping can be found at http://support.coookdown.com

Search