If you have looked at the schema for many of the tables within Service-now, you’ve probably noticed the Correlation ID and Correlation Display fields and may have wondered what they are for. Typically, these fields are used for integrating a third-party system with Service-now. Let’s assume that I am doing an integration with a alerting system system from HP called OpenView. In this integration, alerts are sent from HP to Service-now. When the ticket is updates and/or closed, Service-now updates/closes the alert in OpenView.
Correlation ID
When an alert is received by Service-now, the relevant fields from the alert are mapped to a Service-now incident. Since it is so common to want to know what the actual alert number is in OpenView, we have place to store that on the incident table. The field is called the correlation_id.
The correlation_id field stores the unique identifier (in the other system) for the incoming task, or for the sake of our example, the incoming alert. This field is important for a couple of reasons. First, many customers want to display the OpenView ticket number on the incident form itself in case the operator wants to go to OpenView and look at the alert himself. Second, storing this information allows Service-now to update the alert in OpenView when the incident is updated and/or closed. In this integration, we use our mid server to call an OpenView shell command that accepts the unique id for the ticket in addition to other parameters to update that ticket.
Correlation Display
It is common for administrators to desire to know the origin of the tasks, CI’s, users, etc, that exist in their table. If they are looking at a list of CIs, it might be important to know whether the Service-now discovery tool, a LANDesk integration, or a consumed csv file was the source of each of the CIs now existing in our CMDB. This is where the correlation display comes in handy. In our OpenView integration example, whenever we receive an incident from an alert sent from OpenView, we hardcode the correlation_display to be “HPOVO”. This allows administrators to know the source of their incident. Using this field they will know that it became an incident because of the OpenView system, as opposed to their MS SCOM alerting tool or even a service desk operator.
Another use for the correlation display is to assist with the integration itself. When a business rule is written to send data back to OpenView, it is good practice to put in the condition field: current.correlation_display == “HPOV” in addition to your other conditions. The reason should be obvious. If you want to update an alert in the 3rd party system, you want to make sure that you’re sending the updated alert information to the correct system! While many people often leave this out of the condition statement, it is considered good practice to put it in. If you do, your integration will not break if a new alerting integration is added in the future.
I see where these two fields would be extremely important in Incident, Problem and Change Management, especially when the system is under the control of an outside vendor. And I am defiantly passing this information on. But what I’m wondering and having a hard time with understanding is why the field of “Correlation ID” would be available in a CMDB table, specifically the applications CMDB. What would be the business reason to add a vendor’s ticket number to a CI record? Ticket numbers would change depending on the issue or change, and I see this a being a constant update to the CI. Is there another use for “Correlation ID” in a CMDB?
Thank you,
Terry
ITIL Certified
Ms. Terry L Marcus | APP. SOFTWARE DEV. SR CNSLT. | CMDB Manager | Terry.Marcus@nttdata.com
Correlation ID isn’t really a ticket number at all, it’s just a unique ID from the record in the system you’re integrating with. In the case of an incident or other ticket, the correlation ID will most likely contain the ticket number from the other system. For a CI, it’s a unique ID to the corresponding device record in the other system. I also use correlation ID fields for user and group records coming in from LDAP so that I’ve got a truly-unique ID I can coalesce on.