Build Integrations on your Integrations in ServiceNow

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:

• Get Project by Name - determine which project we are using in Octopus, retrieve the Project ID
• Get Octopus Release Version - using the Project ID from Get Project, get most current release version
• Get Octopus Environment - get the environment ID from Octopus, depending on environment name
• Get Octopus Deployment Variables - in order to send and deploy information over to Octopus we need to retrieve the variables from the deployment matching the release ID and environment ID obtained from the previous two actions
• Post Octopus Deploy with Variables - with all of the information we’ve obtained so far we post to <your-octopus-url>.com/<project>/api/deployments with a JSON body of the release ID, environment ID, and the form values that match the deployment variables to the values in our request item. An example of this payload from the previous screenshot would be as follows:
  
  

• Get Task Logs from Deployment - Now, just because the post is successful to Octopus doesn’t mean the deploy from Octopus to Informatica was successful.  Here, we run an asynchronous do until action to get the task logs from the deployment we just fired.  If it returns a success, failure, or a timeout then we end the do until and proceed accordingly.

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.

‍