This blog entry is part of a three-part series where we will ultimately build a Cloud to Cloud (C2C) integration between Service Now and Slack, utilizing Event Driven triggers to execute an automated orchestration Flow.
In this blog post, I will cover how to:
- Create a Service Now developer account and configure an OAuth application for integration.
- Use the Axway Integration Builder (IB) iPaaS to integrate and manage your Service Now instance with Event-driven notifications enabled.
- Do some basic initial testing of the integration against the Service Now REST APIs.
What is Service Now?
Service Now is a cloud-based SaaS solution that is often used as part of IT Service Management (ITSM) strategies. It is largely used as a ticketing system to track “incidents, problems, and changes” as part of IT Operations.
Configure Service Now
Create a Service Now Developer Account and Instance
Service Now gives the option for you to spin up a free developer instance for testing. Let’s get started there.
- Go to Service Now to create an account.
- Go to Manage –> Request Instance, which will allow you to request a development instance for testing. WARNING: Depending on their current load this may be immediate, or it may be a day or two before they assign you an instance.
- Once you have an instance, go to Manage –> Instance to see your development instance.
Click on the URL to open its web GUI. Make a note of the name of the instance (eg dev98449), as you will need this later. Note: You will need to change the default password at some point during this process. This may be through an email link or using the user/pass from the email to change it at first logon.
Configure a Service Now OAuth Application
- Once you are logged into your instance, go to the Filter Navigator in the top lefthand corner and search for “OAuth”.
Click on System OAuth –> Application Registry, then click New at the top of the page. When prompted to choose your application type, select “Create an OAuth API endpoint for external clients.”
- To set up an OAuth application we can use to allow Axway Integration Builder to connect, you must give the application a name, a secret, and configure the Redirect URL.
The name and secret can be whatever you want them to be. The Redirect URL be as follows: https://auth.cloudelements.io/oauth
- Once you have saved this configuration, ensure you grab the ClientID, retain your Client Secret, and still have the developer instance name as mentioned earlier. Leave Service Now open in a tab for ease of integration.
Integrate Your Service Now Instance with Axway Integration Builder
- Login to the Axway Platform and navigate to the IB Sandbox.
- Under Connectors, search for “ServiceNow OAuth” and choose to Authenticate. Fill out the fields with the information from the previous step.
- Before saving, toggle the switch under “Event Configuration”. This will allow you to setup Event Polling. For now, change the “Event poller refresh interval (mins)” to one minute to ensure we check for new events every minute. Also uncheck all resources except “Incidents,” as we only need to check for those Events for this demo.
- Click the “Create Instance” button at the bottom of the screen. When asked to authenticate, provide your user/pass for the Service Now admin account you updated earlier. You should now be connected to your Service Now instance.
- Navigate back to your Service Now developer instance. In the Filter Navigation box, search for “Incidents”. Click on Service Desk –> Incidents. These are the open “tickets” Service Now is maintaining. Note that this view is only showing active tickets.
Test the Service Now Integration in Axway Integration Builder
- Navigate back to IB and then to your instance’s API docs. From here we can do some initial testing against the REST APIs to see how developers might start working with the Service Now APIs. Here is a suggested flow for testing the Incidents API.
- Call GET /incidents, to show all Incidents returns. Compare to Service Now web GUI, which shows a different list. This is due to Service Now only showing active cases.
- Update the Fields query string with the value “active.” This shows that we are returning both active and inactive, and how we can easily limit the response we receive from the REST API.
- Update the Where query string to be “active=’true'”. This will show we can limit our search to only what is active, but note we need more data to have this result be of value.
- Update Fields to “active,number”. Shows only active cases and their numbers.
- Update Where to “active=’true’&&made_sla=’false'” and Fields to “active,number,made_sla,sys_id”. This shows active with an ID number on Incidents with failed SLAs, and their sysid for later drilldown.
- Grab systemId from one of the items and do a GET incidents/{id} with sysid. Talk about how we could do an orchestration with the above demo to identify and get details on open incidents out of SLA.
- Show POST /incidents. Do a POST (no need to change the data). Navigate back to the Service Now Incidents panel in their Web GUI. Show it appeared in ServiceNow –> Service Desk –> Incidents.
Conclusion
At this point, you should have a working Service Now integration with Axway Application Integration through our Integration Builder solution. In my next blog post, I will show you how to integrate Slack into Axway IB as well. The final post will then show how to use the Event Polling we set up in this blog entry to automate alerting to an enterprise messaging system, such as Slack, to enable real-time notifications of new Incidents being opened in Service Now. The value here is that a resource does not need to keep refreshing the Service Now dashboard all day long to track new Incidents. This functionality could also be used to integrate the Service Now Incidents API into any other application you choose.
Stay tuned, enjoy and reach out if you have any questions, comments or concerns with this configuration!