The Generic Interface (GI) is an OTRS framework that allows EriZone5 to communicate with other systems via web service. The communication can be bidirectional: EriZone5 can act both as a service provider and/or as a service requestor.
You can use the GI to define a “Webservice” and to configure its behavior as a requestor and/or a provider. “Operations” can be defined and configured in order to perform the requested actions internally. In the other case, when a request should be performed by a remote system, “Invokers” can be defined and configured to forward the request. Inside both the Operations and the Invokers it is possible to define, when required, a data mapping between the communicating systems in order to receive/send formatted data.
For both the provider and the requestor you can define the “Network transport” which is the protocol over which OTRS/EriZone5 will communicate with the remote systems (e.g. another EriZone5 server).
When OTRS/EriZone5 is acting as requestor, the Invokers and the “Network transport” must be configured. The configuration of the Network transport is quite straightforward – just set the protocol type (REST in this example), the correct remote host URL and the mapping for the invoker:
Controller mapping for the invoker: Ticket/:ExternalSystemID?UserLogin=:UserLogin&Password=:Password
where “:ExternalSystemID” is a placeholder for the external system element ID and “:UserLogin” and “:Password” are placeholders for the credentials
The Invoker itself needs to be configured by setting the “Event trigger” and the “Invoker Backend”. In this example, we have used the “EriZone::Default” in order to have parameters and credentials passed to the right placeholders used in the Network Transport. N.B.: “EriZone::Default” is used only as an example for this simple case (see the sample EriZoneGIInvoker-1.0.0.opm).
You must enable the invoker used for the webservice through sysconfig:
In the example below for the SetExternalSystemInfo invoker, the ExternalSystemID placeholder will be substituted by the value of the dynamic field ExternalSystemID (Ticket Text Dynamic Field). The credentials are managed in the same way. All additional ticket information to be sent will be retrieved via xml query using the XSLT Mapping. In this case, the field ExternalSystemInfo (Ticket Text Dynamic Field on the remote side) will be set with the current Impact field value.
In order to use the XSLT Mapping, you need to install the following third party Perl modules: XML::Simple, XML::LibXML and XML::LibXSLT – all of which are available at CPAN.
You can examine the final call parameters inside the debugger of the webservice:
It’s worth noting that in the JSON parameters it’s possible to specify all the data that are requested by the remote system. We have assembled data for OTRS/EriZone5 in the example below. In this case, an OTRS/Erizone5 webservice is acting as a provider.
The provider requires Operation and the Network Transport to be configured.
For Network Transport, set the protocol type (REST in this example) and the operation routing mapping:
Route mapping for the Operation “SetInfo”: /Ticket/:TicketID
No particular settings are required in this example for the Operation:
For completeness, the debugger log for the provider is shown below:communication, EriZone, webservice