Event based ticket movement via web service

Robert Ullrich07. Jun 2018 | Administration Best Practices Case study Consulting Use 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.

Let’s continue with our use case from last week. In part 1 we build the pre-requirement for this web service. For sure this can also be realised with another OTRS built-in functionality called GenericAgent, but do you really want to build one GenericAgent per language? Because I really want to avoid this I’m using the OTRSConnector. This has several benefits:

The administration is much easier
A possible performance impact is much lower

So let’s start!

OTRS Requirements for this HowTo

OTRS Framework

at least OTRS 6.0.x

OTRS Packages

You need the following OTRS Feature Add-On:

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

Configuring the provider for the OTRSConnector

As usual the general configuration should look like the following:

In our new web service we need a provider and a requester (invoker). Let’s start with the provider, because it’s the easier one. Add a new operation “Ticket::TicketUpdate” and simply call it “TicketUpdate”. We don’t need an incoming mapping.

The last point for the provider part is the configuration of the network transport. Define a valid route mapping and a request method for the provider.

That’s all for the provider side. Let’s continue with our invoker!

Configuring the invoker for the OTRSConnector

Now we’ll configure the “magic”. Create a new invoker of type “Ticket::TicketUpdate” and include at least the TicketNumber and the dynamic field “Language” in your outgoing request data:

For our outgoing XSLT mapping, you can use my example:

The last part is the used event trigger. I want to trigger my invoker, if the dynamic field “Language” is udpated:

The last part is the configuration of the network transport. The most important here is the controller mapping, because this needs to be the same as in the configuration of our provider. Otherwise you’ll receive errors.

Testing the OTRSConnector

Depending on your configured event trigger for the invoker, please trigger at first the LanguageConnector and wait until the dynamic field “Language” is populated. You should now see something similiar in the web service debug log:

You’ll now see in the ticket history, that the queue was changed by our webservice user:

More information about the OTRS API

Please go to the following website, if you need more information: http://doc.otrs.com/doc/api/otrs/stable/Perl/Kernel/GenericInterface/Operation/Ticket/TicketUpdate.pm.html