Step-by-step configuration of web services in OTRS 5
In this article I’ll tell you how to configure a web service in OTRS 5, where and what to enter, and how to check the service’s performance through SoapUI. We will configure SOAP, not REST. We configure OTRS as a provider, i.e. the system will provide data upon request. If interested, then I ask for a cat.
So, we installed a wonderful OTRS, started working in it. And here the management needed reporting. And not some, but rather complicated. Instead of deeply cutting internal reports, we decided to simply collect data from the web service system and build reports in a separate program.
So, go to administration → web services.
We create a new web service:
1) Enter the name of the interface
2) Select the HTTP :: SOAP network transport
3) Click “Save”.
After saving, it is possible to select Operations .
We needed only three to work with tickets:
SessionCreate - allows you to create a session and use its ID in the future, rather than transmitting a login password every time.
TicketSearch - allows you to find tickets by specified criteria (in our case, open and closed for a certain period). Returns a list of ticket IDs (moreover, IDs, not numbers).
TicketGet - allows you to get a specific ticket (or several) by ticket ID.
When creating Operationyou indicate the name by which you will later call it.
And the last touch - go to the configuration of network transport and set the namespace and message length. The length of 1000 was quite fine with us.
The namespace is the following link:
example.com/otrs/nph-genericinterface.pl/Webservice/InterfaceName
Where example.com is your domain, InterfaceName is the name of your interface. If encryption is configured, then https, not http.
Everything from OTRS all settings are made. Now how to access the service outside? To do this, put SoapUI, take a wsdl scheme and give it to SoapUI.
On the Internet, many complained that OTRS itself does not give up the WSDL scheme, and this is, in fact, a problem.
Thanks to the kind people who shared it.
github.com/OTRS/otrs/tree/master/development/webservices
So we slightly redo the file they proposed for us.
In the headers of the GenericTicketConnectorSOAP.wsdl file, change the definitions name to the name of your web service.
Further, in all soap: operation in soapAction, change http: //www.otrs.org/TicketConnector to your NameSpace.
And at the very end of the document in wsdl: port, specify your NameSpace in location .
Launch Soap UI, create a new SOAPProject, specify the file with the scheme.
The result should be something like this. SoapUI will generate basic requests automatically.
And the final chord is a service performance check. The service returned to us a SessionID, which can already be used in other requests without transferring the username and password each time.
Some nuances:
1) As already mentioned, OTRS does not give WSDL scheme, which is very inconvenient.
2) Upon request, TicketSearch gives out no more than 500 IDs. So if you should receive more than 500, you will still receive only 500. I did not find how to get around this.
3) In order for TicketGet to return SolutionDiffInMin (how long the solution time of the application differs from the target by SLA), you need to transfer something to the request in Extended.
If anyone has interesting comments, comments are welcome :)
PS Regarding the fact that no more than 500 messages were returned during the search, an increase in the “GenericInterface :: Operation :: TicketSearch ### SearchLimit” parameter helped.
Thanks eisaev for the help.
PPS is the second article on how to configure OTRS as an interrogator.
So, we installed a wonderful OTRS, started working in it. And here the management needed reporting. And not some, but rather complicated. Instead of deeply cutting internal reports, we decided to simply collect data from the web service system and build reports in a separate program.
So, go to administration → web services.
We create a new web service:
1) Enter the name of the interface
2) Select the HTTP :: SOAP network transport
3) Click “Save”.
After saving, it is possible to select Operations .
We needed only three to work with tickets:
SessionCreate - allows you to create a session and use its ID in the future, rather than transmitting a login password every time.
TicketSearch - allows you to find tickets by specified criteria (in our case, open and closed for a certain period). Returns a list of ticket IDs (moreover, IDs, not numbers).
TicketGet - allows you to get a specific ticket (or several) by ticket ID.
When creating Operationyou indicate the name by which you will later call it.
And the last touch - go to the configuration of network transport and set the namespace and message length. The length of 1000 was quite fine with us.
The namespace is the following link:
example.com/otrs/nph-genericinterface.pl/Webservice/InterfaceName
Where example.com is your domain, InterfaceName is the name of your interface. If encryption is configured, then https, not http.
Everything from OTRS all settings are made. Now how to access the service outside? To do this, put SoapUI, take a wsdl scheme and give it to SoapUI.
On the Internet, many complained that OTRS itself does not give up the WSDL scheme, and this is, in fact, a problem.
Thanks to the kind people who shared it.
github.com/OTRS/otrs/tree/master/development/webservices
So we slightly redo the file they proposed for us.
In the headers of the GenericTicketConnectorSOAP.wsdl file, change the definitions name to the name of your web service.
Further, in all soap: operation in soapAction, change http: //www.otrs.org/TicketConnector to your NameSpace.
And at the very end of the document in wsdl: port, specify your NameSpace in location .
Launch Soap UI, create a new SOAPProject, specify the file with the scheme.
The result should be something like this. SoapUI will generate basic requests automatically.
And the final chord is a service performance check. The service returned to us a SessionID, which can already be used in other requests without transferring the username and password each time.
Some nuances:
1) As already mentioned, OTRS does not give WSDL scheme, which is very inconvenient.
2) Upon request, TicketSearch gives out no more than 500 IDs. So if you should receive more than 500, you will still receive only 500. I did not find how to get around this.
3) In order for TicketGet to return SolutionDiffInMin (how long the solution time of the application differs from the target by SLA), you need to transfer something to the request in Extended.
If anyone has interesting comments, comments are welcome :)
PS Regarding the fact that no more than 500 messages were returned during the search, an increase in the “GenericInterface :: Operation :: TicketSearch ### SearchLimit” parameter helped.
Thanks eisaev for the help.
PPS is the second article on how to configure OTRS as an interrogator.