Context

This page describes the different ways you can coalesce (e-bond) for a ServiceNow to ServiceNow integration. There are options depending on what variables you have access to.

For integrations between ServiceNow and other platforms, the coalescing strategy will be slightly different. Contact Perspectium Support for more information.

Strategy

Let's say you have two instances, instance A and B, and you want to make sure your tickets are coalesced properly between the two. The strategy is going to have instance A's correlation_id match instance B's sys_id, and vice versa. This way, the coalescing will be mirrored across both instances. Both instances will have a unique sys_id for their record, as well as a unique ticket number. The correlation_display will be used to display the other instance's ticket number.

In other words:

• sys_id will be unique on both instances

• coalescing will be done through the sys_id and correlation_id

• number will be unique on both instances

• correlation_display will represent the other instance's number

Implementation

The following “Default” patterns are default starting with the Bismuth release. Previous versions utilized a sys_id ↔ sys_id approach, which is still valid.

Outbound Table Map

The goal of the Outbound Table Map is to Share across the sys_id of this record in a way that the Subscribing instance can accept and process. In fact, for most of the entries you should see that the Outbound Table Map is just a one-to-one mapping of data from column X to column X.

Default (sys_id to correlation_id)

Your Outbound Map should have the following entries (among others):

In the coalescing diagram seen earlier on this page, you can see that the common incident record is just this one-to-one mapping of columns across.

Optional (sys_id to sys_id)

You could also map it to have the sys_id's be equivalent on each system. You would use the same outbound mapping like the following:

With this option, you would adjust the mapping on the Inbound Transform Map (this will be detailed more in the next section.)

Inbound Transform Map

Your Inbound Transform Map is the primary tool responsible for the coalescing. You can make tweaks to account for multiple clients, acknowledgements, and different column names. For the default behavior mentioned previously (and below), you should not need to make any modifications.

Default (sys_id to correlation_id)

For the default behavior you should not have to adjust anything for the inbound mapping. The coalescing is handled by the Transform Field Map to the Target Field sys_id. More specifically, check where:

• The incoming sys_id matches the existing correlation_id

OR

• The incoming correlation_id matches the existing sys_id

To get into the specifics a little more: if you look at the coalescing diagram again, you can see this behavior. The initial record from instance A to B goes through the Common Incident. The Inbound Transform Map checks to find a record with a correlation id of “xxxx” or no sys_id. Since no record exists with these parameters, it is inserted with its own sys_id “yyyy”. For the record updating back from instance B to A we search for a record with correlation_id “yyyy” or sys_id “xxxx”, which we do find so we are coalesced and we update.

You can see this logic under the Transform Field Map for Target Field sys_id.

For reference, here is that same code:

answer = (function transformEntry(source) {
	var gr = new GlideRecord('incident');	
	var qc = gr.addQuery('correlation_id', source.u_sys_id);
	qc.addOrCondition('sys_id', source.u_correlation_id);
	gr.query();
	if (gr.next()) {
		return gr.sys_id;
	}
 
	return gs.generateGUID(); // no return found, return a new sys_id to create a new record
})(source);

Overall the inbound map processes the target fields like:

Notice that you do not touch the Target Field “number”—let the instance auto-generate this.

Optional (sys_id to sys_id)

If you are setting up something custom and you are not using the standard approach we recommend you create a similar set up where you are coalescing against sys_id. Where the main component of the coalescing is still against sys_id.

This means that we are still going to be coalescing on sys_id as well as mapping the number into the correlation_id field.

The following script will look up a record where the target's sys_id matches the incoming sys_id:

answer = (function transformEntry(source) {
	var gr = new GlideRecord('incident');	
	gr.addQuery('sys_id', source.u_sys_id);
	gr.query();
	if (gr.next()) {
		return gr.sys_id;
	}
 
	return gs.generateGUID(); // no return found, return a new sys_id to create a new record
})(source);

You can adjust this coalescing logic to add queries for number, correlation information, or usernames (if doing sys_user).

Modifications to Column Name

If, for example, you are already using the columns correlation_id and correlation_display on your instance for something else, then you will need to adjust the mapping. The party sending the data to you should still map their outbound data the same way. This is mapping it to the common document format of:

Outbound

Inbound

The inbound logic on your side will be modified with respect to your columns. If you want to coalesce to the columns u_my_correlation_id and u_my_correlation_display, you will adjust the Transform Field Map entries and scripts to reference these different columns.

For the Transform Script, you will modify line 4 of the picture above to replace:

var qc = gr.addQuery('correlation_id', source.u_sys_id);

with:

var qc = gr.addQuery('u_my_correlation_id', source.u_sys_id);

leaving the script otherwise the same:

answer = (function transformEntry(source) {
	var gr = new GlideRecord('incident');	
	var qc = gr.addQuery('u_my_correlation_id', source.u_sys_id);
	qc.addOrCondition('sys_id', source.u_correlation_id);
	gr.query();
	if (gr.next()) {
		return gr.sys_id;
	}
 
	return gs.generateGUID(); // no return found, return a new sys_id to create a new record
})(source);