Event based ticket movement via web service

Robert Ullrich07. Jun 2018 | AdministrationBest PracticesCase studyConsultingUse cases

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 *

This site uses cookies. By continuing to use the site, you agree to the use of cookies. More information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close