Use Travel Security Information in Your Travel Processes

Robert Ullrich14. Aug 2018 | Best PracticesConsultingCyber SecurityUse cases


The practical examples presented in our technical blog ( 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.

STORM powered by OTRS” is used in security departments and companies for a long time due to the well-documented code of OTRS and a huge background in the CERT area.

In one of my recent projects, the team wanted to simplify their travel security process. An employee should start a process, where he has to specify to travel country and some other important values. Based on the travel country, OTRS should display possible travel security warnings, if there are some. We decided to use an external API to request information for the country the employee wants to travel. Until now they’re copying this information manually into STORM.

After some research, we decided that we want to use the API of for this use case.

There are no special pre-requirements regarding the API. So we don’t need an account or have to pay money to use this API.

My customer is using “STORM powered by OTRS” with the OTRS Feature Add-on “OTRSTicketInvoker”.

In addition, we need to add some dynamic fields in STORM to store the response data:

  • Country – Dropdown – with ISO3166-1 compliant Alpha-2 country codes (see for possible values)
  • TravelRating – Text – to store the travel rating
  • TravelLastUpdate – Text – to store the last update time (will be used in another use case)
  • TravelCountryGerman – Text – to store the travel country in german
  • TravelContinentGerman – Text – to store the continent in german
  • TravelURLDetailsGerman – Text – to store an URL for additional information
  • TravelAdviceGerman – Text – to store the travel advice in german
  • TravelCountryEnglish – Text – to store the travel country in english
  • TravelContinentEnglish – Text – to store the continent in english
  • TravelURLDetailsEnglish – Text – to store an URL for additional information
  • TravelAdviceEnglish – Text – to store the travel advice in english

Configuration of the new “STORM powered by OTRS” web service

As always we need a new web service in STORM. I call it “TravelSecurityConnector”:

travelsecurityconnector general config

Now we need a new invoker, to send requests to

travelsecurityconnector invoker config

As you can see I removed everything, except the dynamic field “Country” from my outgoing request data because I want to keep my payload small.

The next point is the XSLT mapping for our outgoing request and incoming response data:

Outgoing XSLT mapping:

travelsecurityconnector outgoing xslt

Incoming XSLT mapping:

travelsecurityconnector incoming xslt

Now you see, why we need so many dynamic fields. Every single value is stored in another dynamic field. It’s also possible to store this values into one dynamic field of type “TextArea”. The last point for the invoker is the used event trigger. I’m using the event “TicketDynamicFieldUpdate_Country” because it makes most sense in my scenario. In addition, we need to select the other dynamic fields (TravelRating, TravelLastUpdate, TravelCountryGerman, TravelContinentGerman, TravelURLDetailsGerman, TravelAdviceGerman, TravelCountryEnglish, TravelContinentEnglish, TravelURLDetailsEnglish, TravelAdviceEnglish) in the “ticket dynamic fields” dropdown to store the response data:

travelsecurityconnector invoker config part2

Next point is to configure the network transport. It’s an easy job:

travelsecurityconnector transport config

The used endpoint is “”, the controller mapping “/api?country=:Country” and the request method is “GET”. You’ll also find this information in the API documentation.

Testing the TravelSecurityConnector

Depending on your configured event trigger for the invoker, use a valid IP address in the dynamic field “IPAddress”. You should now see something similar in the web service debug log:

travelsecurityconnector debugger 1travelsecurityconnector debugger 2

I combined this connector with the “OTRSConnector“, which adds the travel security information to the ticket, I’m working with:

travelsecurityconnector ticketzoom

More information about the API

Please go to the following website, if you need more information:

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