Adding IP Information to Ticket as New Article
Robert Ullrich02. Aug 2018 | ConsultingCyber SecurityUse 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.
In one of my last blog articles I told you how to request IP information from NeutrinoAPI. At the moment this information is only stored in the dynamic field “IPAddressInformation” and is overwritten every time when you change the dynamic field “IPAddress” for a ticket. Because it can happen that the IP address changed more than one time, we should store the content of “IPAddressInformation” in an article of the ticket.
In this blog article, I’m extending the “OTRSConnector” and add a new invoker to this already existing web service.
Let’s start!
At first, we need a new invoker for the “OTRSConnector” like the one I’m using: “AddIPInformationToTicket”.
For our outgoing request data, it’s mandatory to use at least the TicketNumber and the dynamic field “IPAddressInformation”. All other fields are optional.
The next step is our XSLT mapping. As you can see, we add a new article to the ticket and use the content of the dynamic field “IPAddressInformation”:
The last point for the configuration of the invoker is the event trigger. From my point of view selecting the event “TicketDynamicFieldUpdate_IPAddressInformation” is the only one which makes sense.
The last part for this small change is to edit the transport configuration. We’re using the “TicketUpdate” operation for this use case.
From now on, the received IP address information from NeutrinoAPI, will be added as a new article to the related ticket.
