HowTo: Connect OTRS with ServiceNOW
Robert Ullrich16. Aug 2017 | ConsultingMiscellaneousUse cases
Disclaimer:
The practical examples presented in our technical blog (blog.otrs.com) and now in the expert category in our FAQ blog section serve as a source of ideas and documentation to show what is theoretically possible with OTRS in concrete scenarios or sometimes even for more exotic configurations. All configurations presented here were developed under laboratory conditions as a proof of concept.
We can only guarantee testing and implementation of these concepts to be error-free and productive if implemented in a workshop with one of our OTRS consultants. Without this, the responsibility lies with the customer himself. Please note that configurations from older OTRS versions may not work in the newer ones.
With the OTRS Business Solution™ 6, you have the possibility to connect OTRS with ServiceNow. The following article will explain how to configure the SNOWConnector to establish a connection between OTRS and ServiceNow.
To complete this HowTo, you need a running OTRS & a valid ServiceNow-System. Furthermore, you need a valid agent login. The REST/JSON API of ServiceNow is activated by default. Additionally, you have to specify a user, which is allowed to use the REST/JSON API of ServiceNow.
OTRS Requirements for this HowTo:
OTRS Framework
- at least OTRS 6.0.x
OTRS Packages
You need the following Freely selectable Features of the OTRS Business Solution™ 6:
- OTRSTicketInvoker
(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)
Third Party Software
You need this third-party software:
- XML::Simple
- XML::LibXML
- XML::LibXSLT
DynamicFields
- “SNOWTicketNumber” of type „TEXT“ to store the ServiceNow TicketNumber (e.g.: INC0010017)
- “SNOWSysID” of type “TEXT” to store the ServiceNow SysID (e.g.: 33d23ade0f20030010694d9ce1050ebb)
- “SNOWLastUpdate” of type “TEXT” to store the timestamp of the last contact to ServiceNow
- “SNOWState” of type “TEXT” to store the latest ticket state of the ServiceNow ticket
Configuring the SNOWConnector in OTRS
After you satisfied the pre-requirements, you’re ready to create a new web service within OTRS. The name of the new web service is SNOWConnector. Afterward, you have to set up the needed providers and invokers.
Configuring the Provider “TicketCreate”
We start with the configuration of our first Provider “TicketCreate”. ServiceNow should be able to create tickets in OTRS, if necessary.
Because ServiceNow is able to specify the data and also the format, which is sent out, we don’t need an incoming mapping.
Configuring the Provider “TicketUpdate”
It should also be possible for ServiceNow to update tickets in OTRS. For that reason, you have to configure a second provider which is called “TicketUpdate”.
We also don’t need an incoming mapping.
Configuring the Invoker “CreateIncident”
Now you’re ready to start the configuration of our Invokers. To be able to create tickets in ServiceNow, you have to set up an Invoker called “CreateIncident”. Select all the needed data for your outgoing requests and use “XSLT” as mapping for your outgoing and incoming response data.
For the incoming response data, you have to select the dynamic fields (SNOWTicketNumber, SNOWSysID & SNOWState), which you created before.
Now you can configure your outgoing XSLT-mapping. If you need a working XSLT-mapping, you can use the following example:
You also need a XSLT-mapping for the incoming response data, because you have to store the ServiceNow TicketNumber and the ServiceNow SysID:
OTRS stores the ServiceNow TicketNumber in the dynamic field “SNOWTicketNumber”. Afterward, it’s shown in the OTRS TicketZoom.
For some use cases (updating a ServiceNow ticket, upload an attachment to a ticket), you have to use the SysID of the ServiceNow ticket. For that reason, we store the SysID in the DynamicField “SNOWSysID”. Furthermore, we want to know the latest State of the ServiceNow ticket, for that reason, we’re using the <xsl:choose> element to convert the StateID into a readable format.
The used “Event trigger” is the last point for this invoker. Just select one and you’re done with the first Invoker.
Configuring the Invoker “UpdateIncident”
The next invoker is “UpdateIncident”. Select all the needed data for your outgoing requests (please don’t forget the dynamic field “SNOWSysID” in the “Ticket dynamic fields” dropdown) and use “XSLT” as a mapping for your outgoing data.
As outgoing XSLT-mapping, you can use my example. I will transmit the content of an article and add this content as a comment to the ServiceNow ticket.
A mapping for the incoming response data is necessary if you want to store the “LastUpdate” timestamp of ServiceNow.
The used “Event Trigger” is the last point for this Invoker. Just select one and you’re done with the second Invoker. In my example I’m using an ArticleCreate event in OTRS, to trigger the Invoker.
Configuring the Invoker “CreateAttachment”
The next invoker is “CreateAttachment”. Select all the needed data for your outgoing requests (please don’t forget the dynamic field “SNOWSysID” in the “Ticket dynamic fields” dropdown) and use “XSLT” as a mapping for your outgoing data.
Please use my example as outgoing XSLT-mapping:
Furthermore, a mapping for the incoming response data is necessary, if you want to store the “LastUpdate” timestamp of ServiceNow.
The used “Event trigger” is the last point. Select one and you’re done with the last Invoker. In my example I’m using an ArticleCreate event in OTRS, to trigger the Invoker.
Configuring the SNOWConnector “Network Transport”
Provider configuration
We have to set up the “Route mapping” and the “Valid request methods” for the provided Operations.
Make sure you use unique “route mappings” and/or “request methods” for all operations.
Requester configuration
It’s necessary to configure the network transport for the Invokers because we’ve to use the right requests commands towards ServiceNow. But it’s quite easy as you can see:
It’s important to use “BasicAuth” as an authentication module. Please use a valid ServiceNow user for authentication! Keep in mind, this user must be authorized to use the ServiceNow API!
Be careful with the controller mapping for “CreateAttachment”. It’s /ecc_queue instead of /incident
Afterward just click on “Save and finish”.
Testing the SNOWConnector
Testing the Providers
Finally, we can do some tests. At first, we create a ticket in OTRS from ServiceNow.
Now we test the second Provider “TicketUpdate”. Here’s the debug log for a ticket update from ServiceNow:
Testing the Requester
Create or take an already existing ticket and trigger the “CreateIncident” Invoker.
As result you should see something similar in the OTRS Debugger:
In ServiceNow you now see this Incident:
If we now trigger the Invoker “UpdateIncident” we’ll see the following in the Debugger:
ServiceNow adds a new comment to the ticket. The comment is visible in the comment section:
And the last the Invoker “CreateAttachment”:
You can now see the ServiceNow ticket state & last update time in OTRS.
In ServiceNow, you see the attachment in the activity stream.
More information about the ServiceNow API
You can also use other resources which are provided by the ServiceNow API.
If you need more information about the ServiceNow API, please go to the following website: https://developer.servicenow.com/app.do#!/api_doc?v=jakarta&id=server
Justin at 20.02.2019, 21:28
How about if the ServiceNow instance is Domain Separated?
Jens Bothe at 06.12.2018, 12:47
the /Ticket endpoint is used. Please check the documentation of SNOW for further details to use BasicAuth for Authentification
Robins Kumar at 03.12.2018, 09:08
What endpoints or credentials used in SNOW side for make a connection with OTRS