When building integrations with ServiceNow many companies will realize that they already have integrations built within their other services and applications. For certain instances, and depending on each use case, building an integration from scratch within ServiceNow is the best way to go about it. There are no limitations or worries of other implementations or designs that may hamper with the original integration. However, there are instances where the other integration already does everything you need so all you need to do is integrate that integration with ServiceNow.
But first, what is an integration? I know I’ve been saying that word a lot, but it’s a reason why ServiceNow is such a powerful tool. Basically, an integration is when one tool – say ServiceNow – is able to communicate, modify, and retrieve data from another tool – say Octopus, an automated deployment server. If you or your company were to already have an integration set up between Octopus and another tool – say Informatica, a cloud data integration program – then it is feasible to build an automated integration from ServiceNow to an integration between Octopus and Informatica.
Let’s say that your Informatica and Octopus are fully integrated together, where you have scripts and automated processes on Octopus set up to completely communicate with Informatica functionalities. However, your company also utilizes ServiceNow and would like the ability to not have to make a request between your different teams for each program. Rather than sending in a Request Item via catalog item from ServiceNow to Octopus backend users to input data to apply to Informatica, you can automate the entire process without any human intervention. For example, we want to enable a process to move files and/or abort workflows from ServiceNow to Informatica and there already exists this process from Octopus to Informatica. Knowing that Octopus has friendly API documentation we can instead choose to integrate with Octopus’s processes to Informatica in order to perform the actions that we want.
First, we create our service account on Octopus with only the necessary credentials, such as creating releases and viewing projects. From here, we create an API key, which will be used to communicate from ServiceNow to Octopus. We make sure to copy this API key down so we may utilize it in a credential on ServiceNow along with other vital information listed throughout the API documents from Octopus, such as your company’s connection URL for the HTTP connection. And with that we should be all set in creating our connection & credential information over to Octopus.
I typically prefer breaking down a process via user experience to better understand how the integration would work, so here we create a catalog item that mimics our expected inputs from Octopus. The expectation here is that this catalog item would be requested by a user to abort a workflow named workflowName within the folder test_folder in the production environment. Once submitted, the request would optionally go through an approval process and once that is done we then make some API calls over to Octopus to retrieve/execute the following information: if this project exists in Octopus, pass the information provided from the request over to the process, fire the process to Informatica, and then determine if the process was successful.
Next, we can define how to make these API calls, which I did using Flow Designer. My flow will trigger from the Service Catalog, retrieve the variables from the request and then make the API calls from flow actions I had created for each API call:
And with that, we have fully integrated an integration between another integration! From ServiceNow, to Octopus, to Informatica we are able to run a deployment process that would normally switch hands between different groups and require multiple approvals to all within one ServiceNow service catalog request (with or without an approval). Of course, if any of these values are invalid or any unexpected errors were to occur such as MID server mishaps or Octopus and Informatica servers being down then these errors are handled appropriately and notified to the applicable parties. With all of these in place it really goes to show the possibilities of ServiceNow in your work environment.
ServiceNow Engineer residing in the East Coast with experience in the SN enterprise developing integrations, ITOM, Service Mapping, to making sushi. Certified karaoke wizard.