Jake Gillespie
Mega Guru

Before I get into the magic of Connection & Credential Alias, let me talk a bit about (what I call) the legacy equivalent. Way back in 2014, I was tasked with building an outbound integration with a SOAP endpoint. So I created a SOAP Message and SOAP Message Function record similar to the one below.

 

JakeGillespie_0-1722036052887.png

 

While there were a couple of authentication options available, I was using Basic Auth which was common at the time. Note that I had to select my "Basic auth profile" as a direct reference on the SOAP Message Function record. While this worked great in the Development instance, it became a problem when I deployed the integration into another instance. Why? Because the SOAP Message Function record was captured into my Update Set and then deployed as-is, along with my Basic auth profile containing my credentials. This goes against security best practices because each environment (e.g. ServiceNow Instance) should use a different set of credentials. It was also a problem because the SOAP endpoint URL was hardcoded into this SOAP Message Function too.

 

Now I hear you saying "just update it with a manual post-deployment step". Ok, sure, we could do that. But what happens when the next clone from Production down to non-Production instances occurs? The default clone configuration would include this record, meaning our "Production" endpoint URL and credentials would now be in the non-Production instance(s), thus defeating the purpose of having separate credentials per environment in the first place! You can see where I'm going with this. I'll fast forward a little. I (of course) did not build the solution this way. I opted for a combination of System Properties and look-up script to override the endpoint URL and Basic auth credential values at the time of execution. This was a common practice at the time, albeit cumbersome and error-prone to maintain, let alone time-consuming to build. I should also mention that these issues were not exclusive to the SOAP Message configuration, they also existed for the legacy REST Message configuration as well.

 

Now that I've painted that grim picture, let's move on to greener pastures. Let's talk about what makes up a Connection & Credential Alias configuration. At its core, it is made up of 3 components: The Alias record, The Connection record, and (while optional) a Credential record. In comparison to the issues I described earlier regarding the legacy integration configuration, only the Alias record is captured into an Update Set (or Application Repository etc.) and is deployed as such. The Connection record is not captured, nor is it included in clones, as it is expected that each ServiceNow Instance will connect to a different endpoint URL. The same goes for the Credential record which is directly referenced by the Connection record. This architecture solves the environment management issue from earlier. Great!

 

JakeGillespie_1-1722036078486.png

 

So, how and where is this used I hear you ask? Well, it is natively used in Flow Designer, or Integration Hub to be more precise. Integration Hub Spokes will often contain Flow Actions where a (SOAP/REST/PowerShell/SSH etc.) Step references an Alias. This could be hardcoded or passed into the Flow Action as an Input. The same goes for custom integrations. From here, the Step will look up the Active Connection (and Credential) for that Alias at the time of execution and use those details. This is necessary because the Connection is cleverly defined as a Related Record against the Alias (as shown above). Not a direct reference (as we saw with the legacy configuration). It is possible to define more than one Connection against the same Alias, but it's more common to use a single Active Connection at a time. This allows Developers or System Administrators to easily repoint their integration from one endpoint to another if required. For example, you might first build the integration against a Development endpoint but then repoint it to a SIT endpoint for more in-depth testing.

 

There are more features I could talk about, but this article is already longer than I anticipated. Stay tuned for the next article!

6 Comments