Use Travel Security Information in Your Travel Processes
Robert Ullrich14. Aug 2018 | Best PracticesConsultingCyber SecurityUse cases
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.
“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 https://www.reisewarnung.net 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 https://en.wikipedia.org/wiki/ISO_3166-1 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”:
Now we need a new invoker, to send requests to Reisewarnungen.net:
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:
Incoming XSLT mapping:
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:
Next point is to configure the network transport. It’s an easy job:
The used endpoint is “https://www.reisewarnung.net”, the controller mapping “/api?country=:Country” and the request method is “GET”. You’ll also find this information in the Reisewarnungen.net 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:
I combined this connector with the “OTRSConnector“, which adds the travel security information to the ticket, I’m working with:
More information about the Reisewarnungen.net API
Please go to the following website, if you need more information: https://www.reisewarnung.net/en/about-the-api