Event based ticket movement via web service

Robert Ullrich07. Jun 2018 | AdministrationBest PracticesCase studyConsultingUse 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:

  1. The administration is much easier
  2. 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:

OTRSConnector General config

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.

OTRSConnector provider config

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.

OTRSConnector provider transport config

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:

OTRSConnector invoker config

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

OTRSConnector invoker outgoing mapping

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

OTRSConnector invoker config1

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.

OTRSConnector invoker transport config

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:

OTRSConnector debug log

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

OTRSConnector ticket history

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

 

Your email address will not be published. Required fields are marked *