Generic Interface

Generic Interface Layers
Network Transport
Data Mapping
Controller
Operation (OTRS as a provider)
Invoker (OTRS as a requester)
Generic Interface Communication Flow
OTRS as Provider
Remote Request:
OTRS Response:
OTRS as Requester
OTRS Request:
Remote Response:
Web Services
Web Service Graphical Interface
Web Service Overview
Web Service Add
Web Service Example Import
Web Service Change
Web Service Clone
Web Service Export
Web Service Import
Web Service History
Web Service Delete
Web Service Debugger
Web Service Configuration Change
Web Service Command Line Interface
Web Service Configuration
Configuration Details
General
Debugger
Provider
Requester
Connectors
Bundled Connectors
Session Connector
Ticket Connector
Examples:
Web Service Configuration
Perl SOAP Requester
Perl REST Requester
cURL Examples for REST Requests

The OTRS Generic Interface consists of a multiple layer framework that lets OTRS communicate with other systems via a web service. This communication could be bi-directional:

Generic Interface Layers

Generic Interface is build based on a layer model, to be flexible and easy to customize.

A layer is a set of files, which control how the Generic Interface performs different parts of a web service. Using the right configuration, one can build different web services for different External Systems without creating new modules.

Note

If the Remote System does not support the current bundled modules of the Generic Interface, special modules need to be developed for that specific web service.

The list of provided Generic Interface modules shipped with OTRS will be updated and increased over time.

Figure 4.112. The graphical interface layers

The graphical interface layers


Network Transport

This layer is responsible for the correct communication with the Remote System. It receives requests and generates responses when acting as provider, and generates requests and receives responses when acting as requester.

Provider communication is handled by a new web server handle called "nph-genericinterface.pl".

Requester communication could be initiated during an event triggered by a Generic Interface module or any other OTRS module. This event is catched by the event handler and depending on the configuration the event will be processed directly by the requester object or delegated to the Scheduler (a separated daemon designed to process tasks asynchronously).

Data Mapping

This layer is responsible for translating data structures between OTRS and the Remote System (data internal and data external layers). Usually Remote Systems have different data structures than OTRS (including different values and names for those values), and here resides the importance of the layer to change the received information into something that OTRS can understand and on the opposite way send the information to each Remote System using their data dictionaries.

Example: "Priority" (OTRS) might be called "Prio" in a remote system and it could be that value "1 Low" (OTRS) should be mapped to "Information" on the remote system.

Controller

Controllers are collections of similar Operations or Invokers. For example, a Ticket controller might contain several standard ticket operations. Custom controllers can be implemented, for example a "TicketExternalCompany" controller which may contain similar functions as the standard Ticket controller, but with a different data interface, or function names (to adapt to the Remote System function names) or complete different code.

One application for Generic Interface could be to synchronize information with one Remote System that only can talk with another Remote System of the same kind. In this case new controllers needs to be developed and the Operations and Invokers has to emulate the Remote System behavior in such way that the interface that OTRS exposes is similar to the Remote System's interface.

Operation (OTRS as a provider)

An Operation is a single action that can be performed within OTRS. All operations have the same programming interface, they receive the data into one specific parameter, and return a data structure with a success status, potential error message and returning data.

Normally operations uses the already mapped data (internal) to call core modules and perform actions in OTRS like: Create a Ticket, Update a User, Invalidate a Queue, Send a Notification, etc. An operation has full access to the OTRS API to perform the action.

Invoker (OTRS as a requester)

An Invoker is an action that OTRS performs against a Remote System. Invokers use the OTRS Core modules to process and collect the needed information to create the request. When the information is ready it has to be mapped to the Remote System format in order to be sent to the Remote System, that will process the information execute the action and send the response back, to either process the success or handle errors.

Generic Interface Communication Flow

The Generic Interface has a defined flow to perform actions as a provider and as a requester.

These flows are described below:

OTRS as Provider

Remote Request:
  1. HTTP request

    • OTRS receives HTTP request and passes it through the layers.

    • The provider module is in charge to execute and control these actions.

  2. Network Transport

    • The network transport module decodes the data payload and separates the operation name from the rest of the data.

    • The operation name and the operation data are returned to the provider.

  3. Data External

    • Data as sent from the remote system (This is not a module-based layer).

  4. Mapping

    • The data is transformed from the External System format to the OTRS internal format as specified in the mapping configuration for this operation (Mapping for incoming request data).

    • The already transformed data is returned to the provider.

  5. Data Internal

    • Data as transformed and prepared to be passed to the operation (This is not a module based layer).

  6. Operation

    • Receives and validates data.

    • Performs user access control.

    • Executes the action.

OTRS Response:
  1. Operation

    • Returns result data to the provider.

  2. Data Internal

    • Data as returned from operation.

  3. Mapping

    • The data is transformed back to the Remote system format as specified in the mapping configuration (Mapping for outgoing response data).

    • The already transformed data is returned to the provider.

  4. Data external

    • Data as transformed and prepared to be passed to Network Transport as response.

  5. Network Transport

    • Receives the data already in the Remote System format.

    • Constructs a valid response for this network transport type.

  6. HTTP response

    • The response is sent back to the web service client.

    • In the case of an error, an error response is sent to the remote system (e.g. SOAP fault, HTTP error, etc).

OTRS as Requester

OTRS Request:
  1. Event Trigger Handler

    • Based on the web service configuration determines if the request will be synchronous or asynchronous.

      • Synchronous

        • A direct call to the Requester is made in order to create a new request and to pass it through the layers.

      • Asynchronous

        • Create a new Generic Interface (Requester) task for the OTRS Daemon (by delegating the request execution to the Scehduler Daemon, the user experience could be highly improved, otherwise all the time needed to prepare the request and the remote execution will be added to the OTRS Events that trigger those requests).

        • In its next cycle the OTRS daemon process reads the new task and creates a call to the Requester that will create a new request and then passes it through the layers.

  2. Invoker

    • Receives data from the event.

    • Validates received data (if needed).

    • Call core modules to complement the data (if needed).

    • Return the request data structure or send a Stop Communication signal to the requester, to gracefully cancel the request.

  3. Data Internal

    • Data as passed from the invoker (This is not a module based layer).

  4. Mapping

    • The data is transformed to the Remote system format as specified in the mapping configuration (Mapping for outgoing response data).

    • The already transformed data is returned to the requester.

  5. Data External

    • Data as transformed and prepared for sending to the remote system.

  6. Network Transport

    • Receives the remote operation name and the data already transformed to the Remote System format from the requester.

    • Constructs a valid request for the network transport.

    • Sends the request to the remote system and waits for the response.

Remote Response:
  1. Network transport

    • Receives the response and decodes the data payload.

    • Returns the data to the requester.

  2. Data External

    • Data as received from the Remote System.

  3. Mapping

    • The data is transformed from the External System format to the OTRS internal format as specified in the mapping configuration for this operation (Mapping for incoming response data).

    • The already transformed data is returned to the requester.

  4. Data Internal

    • Data as transformed and ready to be passed back to the requester.

  5. Invoker

    • Receives return data.

    • Handles the data as needed specifically by each Invoker (included error handling if any).

    • Return the Invoker result and data to the Requester.

  6. Event Handler or OTRS Daemon

    • Receives the data from the Requester. In the case of the OTRS Daemon this data might contain information to create a task in the future.

Web Services

A Web Service is a communication method between two systems, in our case OTRS and a Remote System.

The heart of the Web Service is its configuration, where it is defined what actions the web service can perform internally (Operation), what actions the OTRS request can perform Remote System (Invokers), how data is converted from one system to the other (Mapping), and over which protocol the communication will take place (Transport).

The Generic Interface is the framework that makes it possible to create Web Services for OTRS in a predefined way, using already made building blocks that are independent from each other and interchangeable.

Web Service Graphical Interface

The web service graphical user interface (GUI) is a tool that allows to construct complex web service configurations in a user friendly and convenient interface. It allows to:

  • Create and Delete web services.

  • Import and Export configurations (in YAML file format) for existing web services.

  • View, Revert and Export old configurations for existing web services in the Web Service History screen.

  • Track all communication logs for each web service in the Debugger screen.

Web Service Overview

The Web Services link in the main screen of Admin Interface (in the System Administration box) leads to the web services overview screen, where you are able to manage your web service configurations. You can add new web services or change the configuration of the existing ones from this screen.

Every web service configuration screen has in the upper part of the screen a bread crumbs style navigation path. This navigation path is useful to know exactly in which part of the web service configuration we are, and also enables the user to jump back to any part of the configuration process at any time (this action will not save any changes).

Note

To create a new web service, press the button Add web service, and provide the required information.

Figure 4.113. Web services overview

Web services overview


Web Service Add

The only required field in this part is the web service Name that needs to be unique in the system and can not be left empty. Other fields are also necessary for the configuration like the Debug Threshold and Validity but these fields are already populated with the default value for each list.

The default value for Debug Threshold is debug. When configured in this manner all communication logs are registered in the database. Each subsequent Debug Threshold value is more restrictive and discards communication logs of lower order than the one set in the system.

Debug Threshold levels (from lower to upper)

  • Debug

  • Info

  • Notice

  • Error

It is also possible to define the network transport protocol for OTRS as Provider and OTRS as requester.

Click on the Save button to register the new web service in the database or click Cancel to discard this operation. You will now be returned to the web service overview screen.

If you already have a web service configuration file in YAML format you can click on the Import web service button on the left side of the screen. For more information on importing web services please check the next section Web Service Change.

Note

To change or add more details to a web service, click on the web service name in the web service overview screen.

Figure 4.114. Web services add

Web services add


Web Service Example Import

Did you know there are example web services available in the OTRS Business Solution™?

Web Service Change

On this screen you have a complete set of functions to handle every part of a web service. On the left side in the action column you can find some buttons that allows you to perform all possible actions on a web service:

  • Clone web service.

  • Export web service.

  • Import web service.

  • Configuration History.

  • Delete web service.

  • Debugger.

Note

Configuration history and Debugger will lead you to different screens.

Web Service Clone

To clone a web service, you need to click on the Clone web service button. A dialog will be shown where you can use the default name or set a new name for the (cloned) web service.

Note

Remember that the name of the web service must be unique within the system.

Click on Clone button to create the web service clone or Cancel to close the dialog.

Figure 4.115. Web service clone

Web service clone


Web Service Export

The Export web service button gives you the opportunity to dump the configuration of the current web service into a YAML file, to download it and to store it on your file system. This can be specially useful if you want to migrate the web service from one server to another, for example from a testing environment to a production system.

Warning

All stored passwords in the web service configuration will be exported in plain text format.

Right after clicking the Export web service button a save dialog of your browser will appear, just like when you click on a file download link on a web page.

Note

Each browser on each operating system has its own save dialog screen and style. Depending on the browser and its configuration it is possible that no dialog is shown and the file is saved to a default directory on your file system. Please check your browser documentation for more specific instructions if needed.

Figure 4.116. Web services export

Web services export


Web Service Import

A valid web service configuration YAML file is required to use the import web service feature. Click on the Import web service button, browse for the configuration file or provide the complete path in the input box.

Click Import button to create a new web service from a file or "Cancel" to close the dialog.

Note

The web service name will be taken from the configuration file name (e.g. if the file name is MyWebservice.yml the resulting web service will be named MyWebservice). If a web service is registered in the system with the same name as the web service that you want to import, the system will lead you to the web service change screen to let you change the name of the imported web service.

Figure 4.117. Web services import

Web services import


Web Service History

Every change to the web service configuration creates a new entry in the web service history (as a journal). The web service history screen displays a list of all configuration versions for a web service. Each row (version) in the Configuration History List represents a single revision in the web service history.

Click on one of the rows to show the whole configuration as it was on that particular date / time. The configuration will be shown in the History details section of this screen. Here you are also able to export the selected web service configuration version or to restore that version into the current web service configuration.

The Export web service configuration behaves exactly as the "Export web service" feature in the web service change screen. For more information refer to that section.

If changes to the current web service configuration do not work as expected and it is not easy to revert the changes manually, you can click on the Revert web service configuration button. This will open a dialog to ask you if you are sure to revert the web service configuration. Click Revert web service configuration in this dialog to replace the current configuration with the selected version, or click Cancel to close the dialog.

Warning

Remember that any passwords stored in the web service configuration will be exported in plain text format.

Please be careful when you restore a configuration because this process is irreversible.

Figure 4.118. Web service history

Web service history


Web Service Delete

Sometimes it is necessary to delete a web service completely. To do this you can press on the Delete web service button and a new dialog will appear asking for confirmation.

Click on Delete to confirm the removal of the web service or on Cancel to close the dialog.

Warning

Deleting a web service can't be undone, please be careful when deleting a web service.

Figure 4.119. Web service delete

Web service delete


Web Service Debugger

The Debugger stores the log of a web service. In the debugger screen you can track all the web service communications for either provider or requester types.

When this screen is shown the request list starts to load. After the list is fully filled you can choose one of the rows (that means a communication sequence) to check its details. This details will appear in a box below.

You can narrow the communication list using the filter on the right part of the screen. You can filter by:

  • Communication type (provider or requester)

  • Date: before and / or after a particular date

  • The remote IP Address

  • A combination of all

After filter settings are set, push the Refresh button and a new list will be displayed meeting your search criteria.

Note

Depending on the search criteria for the filters the new list could return no results.

On the left part of the screen under the action column you can select Go back to the web service or clear the debugger log by pushing the Clear button. This will open a dialog that ask you to confirm erasing of the log. Click Clear in the dialog button to perform the action or click on Cancel to close this dialog.

In the Request details section you can see all the details for the selected communication. Here you can track the complete flow and check for possible errors or confirm success responses.

Figure 4.120. Web service debugger

Web service debugger


Web Service Configuration Change

Returning to the web service change screen, now we are going to review the right side of it. Here we have the possibility to modify all the general data for a web service such as name, description, debug threshold, etc. Also there are two more sections below that allows us to modify specific parameters for communication types OTRS as Provider and OTRS as Requester.

The web service configuration needs to be saved on each level. This means that if a setting is changed, links to other, deeper parts of the configuration will be disabled forcing you to save the current configuration level. After saving the disabled links will be re-enabled again allowing you to continue with the configuration.

On the OTRS as provider section it is possible to set or configure the network transport protocol. Only network transport back-ends that are registered are shown on the list. To configure the network transport click on the Configure button. It is also possible to add new operations in this box. To do this select one of the available operations from the Add Operation list. This will lead you to the operation configuration screen. After saving the new operation it will be listed in the table above.

OTRS as requester is very similar to the previous one, but instead of operations you can add invokers here.

Click the Save button to save and continue configuring the web service, Save and finish to save and return to the web service overview screen, or Cancel to discard current configuration level changes and return to web service overview screen.

Figure 4.121. Web services change

Web services change


Note

Like the other Generic Interface configuration screens such as Network Transport, Operation, Invoker and Mapping, the initial configuration (add) screen will only present two options: Save and Cancel. If the configuration is re-visited, a new option Save and Finish will appear. The behavior of this feature is defined below.

Save will store the current configuration level in the database and it will return to the previous screen to review your changes or to configure deeper settings.

Save and Finish will store the current configuration level in the database and it will return to the previous screen in the configuration hierarchy (to the immediate upper configuration level).

Cancel will discard any configuration change to the current configuration level and will return to the previous screen in the configuration hierarchy.

Web Service Provider Network Transport

In future the list of available network transports will be increased. Currently only HTTP::SOAP and HTTP::REST transports are available. Each transport has different configuration options to setup and they might use different frontend modules to configure them.

It is quite simple to configure the HTTP::SOAP protocol as provider. There are only two settings: Namespace and Maximum message length. These fields are required. The first one is a URI to give SOAP methods a context, reducing ambiguities, and the second one is a field where you can specify the maximum size (in bytes) for SOAP messages that OTRS will process.

Figure 4.122. Web service provider network transport (HTTP::SOAP)

Web service provider network transport (HTTP::SOAP)


Optionally, you may want to define additional response headers. These may be used to add static header values to every response. Just click on Add response header and fill both key and value fields. There is no limit in number of additional header lines.

For HTTP::REST the configuration might be a bit more complicated, as it grows dynamically for each configured operation by adding: Route mapping for Operation '<OperationName>': and Valid request methods for Operation '<OperationName>': settings to the default transport settings Maximum message length: and Send Keep-Alive:

  • Route mapping for Operation '<OperationName>':

    In this setting a resource path is set. This path must be defined according to the needs of the web service considering that the path in conjunction with the HTTP request method determines the Generic Interface operation to be executed.

    Path can contain variables in the form of ':<VariableName>' each path string that fits on the position of the variable name will be added to the request payload using the variable name defined in this setting.

    Examples:

    Route mapping: /Resource

    • Valid requests:

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource?Param1=One

    • Invalid requests:

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherResource

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherResource?Param1=One

    Route mapping: /Resource/:ID

    • Valid requests:

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/1

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/1?Param1=One

      In both cases ID = 1 will be sent to the operation as part of the payload. In the second case also Param1 = One will be added, depending on the HTTP request method other parameters will be added if they come as a JSON string in the request header.

    • Invalid requests:

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource?Param1=One

    Route mapping: /Resource/OtherResource/:ID/:Color

    • Valid requests:

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherResource/1/Red

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherReosurce/123/Blue?Param1=One

      In the first example ID = 1 and Color = Red, while in the second ID = 123 and Color = Blue.

    • Invalid requests:

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/1

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherResource/1

      http://localhost/otrs/nph-genericinterface.pl/Webservice/Test/Resource/OtherResource/1?Param1=One

      In the first example the part of the path '/OtherResource' is missing as well as the :Color variable, on the second example just :Color variable is missing.

  • Valid request methods for Operation '<OperationName>':

    The HTTP request methods to determine the operation to use together with the route mapping, possible options: CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT and TRACE.

    Totally different operations can share exactly the same mapping path, but the request method must be unique for each operation, in order to determine correctly the operation to use on each request.

Figure 4.123. Web service provider network transport (HTTP::REST)

Web service provider network transport (HTTP::REST)


Web Service Operation

The actions that can be performed when you are using OTRS as a provider are called Operations. Each operation belongs to a controller. Controllers are collections of operations or invokers, normally operations from the same controller need similar settings and share the same configuration dialog. But each operation can have independent configuration dialogs if needed.

Name, Description, Backend and Mappings are fields that normally appear on every operation, other special fields can appear in non default configuration dialogs to fulfill specific needs of the operation.

Normally there are two mapping configuration sections on each operation, one for the incoming data and another one for the outgoing data. You can choose different mapping types (backends) for each mapping direction, since their configuration is independent from each other and also independent from the operation backend. The normal and most common practice is that the operation uses the same mapping type in both cases (with inverted configuration). The complete mapping configuration is done in a separate screen which depends on the mapping type.

The operation backend is pre-populated and is not editable. You will see this parameter when you choose the operation on the web service edit screen. The field is only informative.

In the left part of the screen on the action column you have the options: Go back to web service (discarding all changes since the last save) and Delete. If you click on the last one, a dialog will open and ask you if you like to remove the operation. Click on Delete button to confirm the removal of the operation and its configuration or Cancel to close the delete dialog.

Figure 4.124. Web service operation

Web service operation


Web Service Requester Network Transport

The network transport configuration for the requester is similar to the configuration for the provider. For the Requester HTTP::SOAP network transport there are more fields to be set.

Apart from the Endpoint (URI of the Remote System web service interface to accept requests) and Namespace which are required fields, you can also specify:

  • Encoding (such as utf-8, latin1, iso-8859-1, cp1250, etc) for the SOAP message.

  • SOAPAction Header: you can use this to send an empty or filled SOAPAction header. Set to No and the SOAPAction header on the SOAP message will be an empty string, or set to Yes to send the SOAP action in Namespace#Action format and define the separator (typically "/" for .Net web services and "#" for the REST).

  • Authentication: to set the authentication mechanism, set to "-" to not use any authentication or select one from the list and the detail fields will appear.

Note

Currently only the BasicAuth (HTTP) authentication mechanism is implemented. You can decide whether or not to use it depending on the Remote System configuration. If used, you must provide the User Name and the Password to access the remote system.

Warning

If you supply a password for authentication and after you export the web service to a YAML file this password will be revealed and will be written into a plain text string inside the YAML file. Be aware of it and take precautions if needed.

Figure 4.125. Web service requester network transport (HTTP::SOAP)

Web service requester network transport (HTTP::SOAP)


In the case of HTTP::REST, this configuration also grows dynamically depending on the configured invokers by adding Controller mapping for Invoker '<InvokerName>': and Valid request command for Invoker '<InvokerName>': for each invoke. Authentication and SSL options are similar to the ones in HTTP::SOAP

  • Host

    The host name or IP Address and port of the remote system, if no port is specified, port 80 is used by default.

  • Controller mapping for Invoker '<InvokerName>':

    In this setting a resource path is set. This path must be defined according to the needs of the remote web service and following its definition.

    Path can contain variables in the form of ':<VariableName>' for each variable name that matches the current data (to be sent), will be replaced by the corresponding data value. This matched variable names and values will be removed from the current data. Depending on the HTTP request command the remaining data could be sent as a JSON string in the request body or as query parameters within the URI.

    Examples:

    For data: Var1 = One, Var2 = Two, Var3 = Three and Var4 = Four.

    Controller mapping: /Resource

    • After Replacements:

      /Resource

    • Remaining Data:

      Var1 = One, Var2 = Two, Var3 = Three and Var4 = Four

    Controller mapping: /Resource/:Var1

    • After Replacements:

      /Resource/One

    • Remaining Data:

      Var2 = Two, Var3 = Three and Var4 = Four

    Controller mapping: /Resource/:Var1?Param1=:Var2&Var3=:Var3

    • After Replacements:

      /Resource/One?Param1=Two&Var3=Three

    • Remaining Data:

      Var4 = Four

  • Valid request command for Invoker '<InvokerName>':

    This determine the HTTP request method to use, possible options: CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT and TRACE. If no command is selected, Default command is used.

  • Default command

    Used as a fall-back for all Invokers without a defined request command.

Figure 4.126. Web service requester network transport (HTTP::REST)

Web service requester network transport (HTTP::REST)


Web Service Invoker

The actions that can be performed when you are using OTRS as a requester are called Invokers. Each invoker belongs to a controller (controllers are collections of operations or invokers). Usually invokers from the same controller need similar settings and share the same configuration dialogs. Each invoker can have independent configuration dialogs if needed.

Name, Description, Backend and Mappings are fields that normally appear on every invoker. Additionally the list of event triggers and other special fields can appear on non default configuration dialogs to fulfill special needs of the invoker.

Normally there are two mapping configuration sections for each invoker, one for the incoming data and another one for the outgoing data. You can choose different mapping types (backends) for each mapping direction, since their configuration is independent from each other and also independent from the invoker backend. The normal and most common practice is that the invoker uses the same mapping type in both cases, with inverted configuration. The complete mapping configuration is done in a separate screen, which depends on the mapping type.

The invoker backend is pre-populated and can not be edited. You will see this parameter when you choose the invoker on the web service edit screen. The field is only informative.

Event triggers are events within OTRS such as TicketCreate, ArticleSend, etc. These can act as triggers to execute the invoker. Each invoker needs to have at least one event trigger registered, or the invoker will be useless, because it will never be called. Additionally a set of rules (conditions) for each event can be defined to have more control over the triggering of the events. These rules depend on the data of the object associated with the event. The asynchronous property of the event triggers define if the OTRS process will handle the invoker or if it will be delegated to the OTRS Daemon.

Note

The OTRS Daemon is a separate set of process that executes tasks in the background. Using this the OTRS process itself will not be affected if the Remote System takes a long time to respond, if it is not available or if there are network problems. If you don't use the OTRS Daemons using web services can make OTRS slow or non-responsive. Therefore it is highly recommend to use asynchronous event triggers as often as possible.

To add an Event trigger, first select the event family from the first list, then the event name from the second list, then set the asynchronous property (if unchecked means that the event trigger will not be asynchronous) and finally click on the plus button. A new event trigger will be created and it will be listed on the invoker Event Triggers list.

From the Event Triggers list each events shows if it contains conditions or not. The edit button next to the condition property allows to add or edit the current conditions of the event.

To delete an Event trigger, simply locate the event trigger to be deleted in the Event Triggers list and click on the trash icon at the end of the row. This will open a dialog that asks you if you are sure to delete the event trigger. Click Delete to remove the event trigger from the list, or Cancel to close the dialog.

In the left part of the screen on the action column you have the options: Go back to web service (discarding all changes since the last save) and "Delete". If you click on the last one, a dialog will emerge and ask you if you like to remove the invoker. Click on the Delete button to confirm the removal of the invoker and its configuration or Cancel to close the delete dialog.

Figure 4.127. Web service invoker

Web service invoker


Web Service Invoker Event

Sometimes defining an event to trigger an invoker could result in many unnecessary or wrong request to a remote server. Event conditions could be set to restrict the triggering of the invoker in such cases.

To access the event settings screen where the conditions can be defined is necessary to be in the invoker screen and from there click on the edit icon next to the condition status on the event where this condition should take effect.

Within the event settings screen in the action bar there is a button to go back to the invoker screen as well as a button to remove all the event conditions. By default the screen is pre-populated with the first condition. Update the Type of linkings between conditions if more than one condition is planned, then change the Type of linking from Condition 1 if more than one field is planned. Both linking fields accept and, or or xor as values.

Fill the Field name, set the matching type (String for exact match, Regexp for regular expression or Validation Module) and set Value to match (in case of Validation Module the full class name like: Kernel::GenericInterface::Event::Validation::ValidateDemo).

To add more fields to the condition, click on the + button in the fields header. To remove a field, click on the - button in the field row. It is necessary to keep at least one field per condition.

To add more conditions click on the button below the last condition box. To remove a condition, click on the - button in the condition header. It is necessary to keep at least one condition in the set. To remove all conditions use the button in the sidebar.

Figure 4.128. Web service invoker event

Web service invoker event


Web Service Mapping

There are cases where you need to transform the data from one format to another (map or change data structure), because normally a web service is used to interact with a Remote System, that is highly probable that is not another OTRS system and / or could not understand the OTRS data structures and values. In these cases some or all values have to be changed, and sometimes even the names of the values (keys) or even the complete structure, in order to match with the expected data on the other end. To accomplish this task the Generic Interface Mapping Layer exists.

Each Remote System has it own data structures and it is possible to create new mapping modules for each case (e.g. there is a customized mapping module for SAP Solution Manager shipped with OTRS), but it is not always necessary. The module Mapping::Simple should cover most of the mapping needs.

Note

When Mapping::Simple does not cover all mapping needs for a web service, a new mapping module should be created. To learn more about how to create new mapping modules please consult the OTRS Development Manual.

This module gives you the opportunity to set default values to map for each key or value for the whole communication data.

At the beginning of the screen you will see a general section where you can set the default rules that will apply for all the unmapped keys and values. There are three options available, these options are listed below:

  • Keep (leave unchanged): doesn't touch the keys or values in any way.

  • Ignore (drop key/value pair): when this is applied to the key it deletes the key and value, because when a key is deleted then in consequence its associated value is deleted too. When this is applied to the value, only the value is deleted, keeping the key, that now will be associated to an empty value.

  • MapTo (use provided key or value as default): all keys and / or values without a defined map rule, will use this as default, when you select this option a new text field will appear to set this default.

Clicking on the + button for new key map, will display a new box for a single mapping configuration. You can add as many key mappings as needed. Just click on the + button again and a new mapping box will appear below the existing one. From this mapping boxes you can define a map for a single key, with the next options:

  • Exact value(s): the old key string will be changed to a new one if the old key matches exactly.

  • Regular expression: the key string will be replaced following a regular expression rule.

Pressing the new value map + button will display a new row for a value map. Here it is also possible to define rules for each value to be mapped with the same options as for the key map (Exact value and Regular expression). You can add as many values to map as needed, and if you want to delete one of them, just click on the - button for each mapping value row.

Deleting the complete key mapping section (box) is possible, just push on the - button located on the up right corner of each box that you want to delete.

If you need to delete a complete mapping configuration: go back to the corresponding operation or invoker screen, look for the mapping direction that you select before and set its value to -, and save the configuration to apply changes.

Figure 4.129. Web service mapping

Web service mapping


Web Service Command Line Interface

The bin/otrs.Console.pl Admin::WebService::* commands were developed in order to create basic, but fast and powerful tools to work with web service configurations. They give you the ability to perform the following actions:

  • Add: to create web services using a YAML file as the configuration source.

  • Update: to change an existing web service, the configuration can be changed using a different or modified YAML file.

  • Dump: to save the current web service configuration to a file.

  • List: to get a complete list of all the web services registered in system.

  • Delete: to delete a web service from the system. Be careful when you use it, because this action can't be undone.

Example: Creating a new web service configuration:

shell> bin/otrs.Console.pl Admin::WebService::Add --name <webservice_name> --source-path /path/to/yaml/file
        

Web Service Configuration

From its design the web services were conceived to be portable from one OTRS system to another, e.g. from a test or development environment to a production system. Therefore it was needed to have an easy way to extract the web service configuration from the database, and import it to another. To accomplish this task the Generic Interface uses YAML files as the web services configuration basis.

Why YAML? YAML is a markup language designed to be human friendly to read and write (it is easier to understand than JSON), it does not have some of the limitations of XML like numeric tags, it is open, standardized, and is complete enough to store the whole web service configuration.

Note

To learn more about YAML please visit http://www.yaml.org/.

The following is a web service configuration file example in YAML format:

---
Debugger:
  DebugThreshold: debug
Description: This an example of a web service configuration
Provider:
  Operation:
    CloseIncident:
      Description: This is a test operation
      MappingInbound: {}
      MappingOutbound: {}
      RemoteSystemGuid: ''
      Type: Test::Test
    Test:
      Description: This is a test operation
      MappingInbound:
        Config:
          KeyMapDefault:
            MapTo: ''
            MapType: Keep
          KeyMapExact:
            Prio: Priority
          ValueMap:
            Priority:
              ValueMapExact:
                Critical: 5 Very High
                Information: 1 Very Low
                Warning: 3 Normal
          ValueMapDefault:
            MapTo: 3 Normal
            MapType: MapTo
        Type: Simple
      MappingOutbound:
        Config:
          KeyMapDefault:
            MapTo: ''
            MapType: Ignore
          KeyMapExact:
            Priority: Prio
          ValueMap:
            Prio:
              ValueMapExact:
                1 Very Low: Information
                3 Normal: Warning
                5 Very High: Critical
          ValueMapDefault:
            MapTo: ''
            MapType: Ignore
        Type: Simple
      Type: Test::Test
  Transport:
    Config:
      MaxLength: 10000000
      NameSpace: http://www.example.com/actions
    Type: HTTP::SOAP
RemoteSystem: remote.system.description.example.com
Requester:
  Invoker:
    Test:
      Description: This is a test invoker
      Events:
        - Asynchronous: 1
        Condition:
          Condition:
            '1':
              Fields:
                Queue:
                  Match: Raw
                  Type: String
              Type: and
          ConditionLinking: and
          Event: TicketCreate
        - Asynchronous: 0
          Event: ArticleUpdate
      MappingInbound:
        Type: Simple
      MappingOutbound:
        Type: Simple
      Type: Test::Test
  Transport:
    Config:
      Authentication:
        Password: '*******'
        Type: BasicAuth
        User: otrs
      Encoding: utf-8
      Endpoint: http://www.example.com:8080/endpoint
      NameSpace: http://www.example.com/actions
      SOAPAction: Yes
      SOAPActionSeparator: '#'
    Type: HTTP::SOAP
            
        

Configuration Details

General
  • Description: a short text that describes the web service.

  • RemoteSystem: a short description of the Remote System.

  • Debugger: a container for the debugger settings.

  • Provider: a container for the provider settings.

  • Requester: a container for the requester settings.

Debugger
  • DebugThreshold: the debugger level.

    Possible values

    • debug: all logs are stored in the database.

    • info: info, notice and error level logs are stored in the database.

    • notice: notice and error level logs are stored in the database.

    • error: only error level logs are stored in the database.

Provider
  • Operation: a container for each operation settings.

  • Transport: a container for provider network transport settings.

Operation
  • <OperationName>: Unique name for the operation, container for its own operation settings (cardinality 0..n, but not duplicate).

<OperationName>

This section is based on operations from type Test::Test other operations might contain more or different settings.

  • Description: a short text that describes the operation.

  • MappingInbound: a container for the mapping settings for the incoming request data.

  • MappingOutbound: a container for the mapping settings for the outgoing response data.

  • Type: the operation backend, in Controller::Operation format.

MappingInbound

This section is based on mappings from type Simple. Other mappings might contain more or different settings.

  • Config: a container for this mapping settings.

  • Type: the mapping backend.

Config
  • KeyMapDefault: a container for all non mapped keys settings.

  • ValueMapDefault: a container for all non mapped values settings.

  • KeyMapExact: a container for all exact key mappings (cardinality 0 .. 1).

  • KeyMapRegEx: a container for all regular expression key mappings (cardinality 0 .. 1).

  • ValueMap: a container for all value mappings (cardinality 0 .. 1).

KeyMapDefault
  • MapTo: the new value to be used (only applicable if MapType is set to MapTo).

  • MapType: the rule for the mapping.

    Possible values

    • Keep: leave unchanged.

    • Ignore: drop.

    • MapTo: change to the MapTo value.

ValueMapDefault

Similar to KeyMapDefault.

KeyMapExact
  • <oldkey>: <newkey> (cardinality 0 .. n but not duplicate).

KeyMapRegEx
  • <oldkey(RegEx)>: <newkey> ( cardinality 0 .. n but no duplicates).

ValueMap
  • <newkey>: a container for value mappings for this new key (cardinality depends on the new keys from KeyMapExact and KeyMapRegEx).

<newkey>
  • ValueMapExact: a container for all exact value mappings (cardinality 0 .. 1).

  • ValueMapRegEx: a container for all regular expression value mappings (cardinality 0 .. 1).

ValueMapExact
  • <oldvalue>: <newvalue> ( cardinality 0 .. n but not duplicate).

ValueMapRegEx
  • <oldvalue(RegEx)>: <newvalue> ( cardinality 0 .. n but not duplicate).

MappingOutbound

Same as MappingInbound.

Transport

This section is based on the provider network transport HTTP::SOAP, other transports might contain more or different settings.

  • Config: a container for the specific network transport configuration settings.

  • Type: the provider network transport backend.

Config
  • MaxLength: the maximum length in bytes to be read in a SOAP message by OTRS.

  • NameSpace: an URI that gives a context to all operations that belongs to this web service.

Requester
  • Invoker: a container for each invokers' settings.

  • Transport: a container for requester network transport settings.

Invoker
  • <InvokerName>: Unique name for the invoker, container for its own invoker settings (cardinality 0..n, but not duplicate).

<InvokerName>

This section is based on invokers from type Test::Test other invokers might contain more or different settings.

  • Description: a short text that describes the invoker.

  • Events: a container for a unnamed list of event trigger settings.

  • MappingInbound: a container for the mapping settings for the incoming response data.

  • MappingOutbound: a container for the mapping settings for the outgoing request data.

  • Type: the invoker backend, in Controller::Invoker format.

Events
  • List Element: (cardinality 0 .. n).

    • Asynchronous: to set if the invoker execution will be delegated to the OTRS Daemon.

      Possible values

      • 0: not handled by the OTRS Daemon.

      • 1: handled by the OTRS Daemon.

    • Condition: Container for event conditions to trigger the invoker, if there are no conditions, event will always trigger the invoker.

    • Event: the name of the event trigger.

      Possible values (for ticket events)

      • TicketCreate

      • TicketDelete

      • TicketTitleUpdate

      • TicketUnlockTimeoutUpdate

      • TicketQueueUpdate

      • TicketTypeUpdate

      • TicketServiceUpdate

      • TicketSLAUpdate

      • TicketCustomerUpdate

      • TicketPendingTimeUpdate

      • TicketLockUpdate

      • TicketArchiveFlagUpdate

      • TicketStateUpdate

      • TicketOwnerUpdate

      • TicketResponsibleUpdate

      • TicketPriorityUpdate

      • HistoryAdd

      • HistoryDelete

      • TicketAccountTime

      • TicketMerge

      • TicketSubscribe

      • TicketUnsubscribe

      • TicketFlagSet

      • TicketFlagDelete

      • TicketSlaveLinkAdd

      • TicketSlaveLinkDelete

      • TicketMasterLinkDelete

      Possible values (for article events)

      • ArticleCreate

      • ArticleUpdate

      • ArticleSend

      • ArticleBounce

      • ArticleAgentNotification

      • ArticleCustomerNotification

      • ArticleAutoResponse

      • ArticleFlagSet

      • ArticleFlagDelete

Condition
  • Condition: Container to actual event conditions.

  • ConditionLinking: Defines how multiple condition interacts with each other.

    Possible values (for condition linking)

    • and

    • or

    • xor

Condition -> Condition
  • <ConditionName>: Container for the condition elements.

<ConditionName>

Unique name for the condition within the invoker and event the GUI assigns consecutive integer condition names starting from 1.

  • Fields: Container for field conditions.

  • Type: Define how multiple fields interact within its condition.

    Possible values (for condition linking)

    • and

    • or

    • xor

Fields
  • <FieldName>: Container field attributes.

<FieldName>

The name of a field from the event object (e.g. for Ticket Events, the fields could be Queue, Priority, Type, etc).

  • Match: The value to match from the selected against the event object using the Type modifier.

  • Type: Modifier to the Match value.

    Possible values (for type modifier)

    • String: Direct compare between object field value and Match value.

    • Regexp: Compare object field value with the regular expression defined in the Match value.

    • Module: Use the module defined in the Match with the object data.

MappingInbound

Same as Operation MappingInbound.

MappingOutbound

Same as Operation MappingInbound.

Transport

This section is based on the requester network transport HTTP::SOAP, other transports might contain more or different settings.

  • Config: a container for the specific network transport configuration settings.

  • Type: the requester network transport backend.

Config
  • Authentication: a container for authentication settings.

  • Encoding: the SOAP Message request encoding.

  • Endpoint: the URI of the Remote Server web service to accept OTRS requests.

  • NameSpace: an URI that gives a context to all invokers that belongs to this web service.

  • SOAPAction: to send an empty or filled SOAPAction header in the SOAP message (in <NameSpace> <Separator> <Action> format).

    Possible values

    • Yes: to send a filled SOAPAction header.

    • No: to send an empty SOAPAction header.

  • SOAPActionSeparator: to set the <Separator> of a filled SOAPAction header.

    Possible values

    • '/': used for .net web services.

    • '#': used for all the rest web services.

Authentication
  • User: the privileged user name that has access to the remote web service.

  • Password: the password for privileged user in plain text.

  • Type: the type of authentication.

Connectors

A Connector is in essence a set of actions that are either called Operations if OTRS acts as a web service provider or Invokers if OTRS acts as a web service requester. But it can also include special Mappings or Transports.

One Connector can either have only Operations, Only Invokers or both. A connector can even use parts of other connectors like the Mappings or Transports if they are not to specific for the Connector that is trying to implement them.

In other words a Connector is not limited to just the Controller layer but it can be extended to Data Mapping or Network Transport layers if needed.

Due to the modular design of the Generic Interface a Connector can be seen as a plug-in; this means that by adding Connectors the capabilities of the generic interface can be extended using: OTRS Feature add ons, OTRS Custom modules, 3rd Party modules, and so on.

Bundled Connectors

Included with this version of OTRS the following connectors are ready to be used:

  • Session

  • Ticket

Session Connector

This connector is capable to create a valid SessionID that can be used in any other operation.

Provides:

  • Operations:

    • SessionCreate

    • SessionGet

Operations
SessionCreate

Creates a new valid SessionID to be used in other operations from other connectors like TicketCreate.

Note

To use the SessionID in other operations from other connectors it is necessary that the operation implements authentication by SessionID. All the rest of the bundled operations are capable of accepting a valid SessionID as an authentication method.

Possible Attributes:

                            
      <SessionCreate>
         <!--You have a MANDATORY CHOICE of the next 2 items at this level-->
         <!--Optional:-->
         <UserLogin>?</UserLogin>
         <!--Optional:-->
         <CustomerUserLogin>?</CustomerUserLogin>
         <!--Optional:-->
         <Password>?</Password>
      </SessionCreate>
                            
                        

SessionCreate

Gathers data from a valid session excluding sensitive information such as user password or challenge token.

Note

If any of its values is a complex structure then it is automatically converted to a JSON string.

Possible Attributes:

                            
      <SessionGet>
         <SessionID>?</SessionID>
      </SessionGet>
                            
                        

Ticket Connector

This connector supplies the basic functionality to interact with tickets.

Provides:

  • Operations:

    • TicketCreate

    • TicketUpdate

    • TicketGet

    • TicketSearch

    • TicketHistoryGet

Operations
TicketCreate

Provides an interface to create a ticket in OTRS. A ticket must contain an Article and can contain several attachments, all defined Dynamic Fields can be also set on TicketCreate operation.

Possible Attributes:

                            
      <TicketCreate>
         <!--You have a MANDATORY CHOICE of the next 3 items at this level-->
         <!--Optional:-->
         <UserLogin>?</UserLogin>
         <!--Optional:-->
         <CustomerUserLogin>?</CustomerUserLogin>
         <!--Optional:-->
         <SessionID>?</SessionID>
         <!--Optional:-->
         <Password>?</Password>
         <Ticket>
            <Title>?</Title>
            <!--You have a MANDATORY CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <QueueID>?</QueueID>
            <!--Optional:-->
            <Queue>?</Queue>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <TypeID>?</TypeID>
            <!--Optional:-->
            <Type>?</Type>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <ServiceID>?</ServiceID>
            <!--Optional:-->
            <Service>?</Service>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <SLAID>?</SLAID>
            <!--Optional:-->
            <SLA>?</SLA>
            <!--You have a MANDATORY CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <StateID>?</StateID>
            <!--Optional:-->
            <State>?</State>
            <!--You have a MANDATORY CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <PriorityID>?</PriorityID>
            <!--Optional:-->
            <Priority>?</Priority>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <OwnerID>?</OwnerID>
            <!--Optional:-->
            <Owner>?</Owner>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <ResponsibleID>?</ResponsibleID>
            <!--Optional:-->
            <Responsible>?</Responsible>
            <CustomerUser>?</CustomerUser>
            <!--Optional:-->
            <CustomerID>?</CustomerID>
            <!--Optional:-->
            <PendingTime>
               <!--You have a CHOICE of the next and the other 5 items at this level-->
               <Diff>?</Diff>
               <Year>?</Year>
               <Month>?</Month>
               <Day>?</Day>
               <Hour>?</Hour>
               <Minute>?</Minute>
            </PendingTime>
         </Ticket>
         <Article>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <CommunicationChannelID>?</CommunicationChannelID>
            <!--Optional: Possible values Email, Internal or Phone-->
            <CommunicationChannel>?</CommunicationChannel>
            <IsVisibleForCustomer>?</IsVisibleForCustomer>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <SenderTypeID>?</SenderTypeID>
            <!--Optional:-->
            <SenderType>?</SenderType>
            <!--Optional:-->
            <From>?</From>
            <Subject>?</Subject>
            <Body>?</Body>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <ContentType>?</ContentType>
            <Charset>?</Charset>
            <MimeType>?</MimeType>
            <!--Optional:-->
            <HistoryType>?</HistoryType>
            <!--Optional:-->
            <HistoryComment>?</HistoryComment>
            <!--Optional:-->
            <AutoResponseType>?</AutoResponseType>
            <!--Optional:-->
            <TimeUnit>?</TimeUnit>
            <!--Optional:-->
            <NoAgentNotify>?</NoAgentNotify>
            <!--Zero or more repetitions:-->
            <ForceNotificationToUserID>?</ForceNotificationToUserID>
            <!--Zero or more repetitions:-->
            <ExcludeNotificationToUserID>?</ExcludeNotificationToUserID>
            <!--Zero or more repetitions:-->
            <ExcludeMuteNotificationToUserID>?</ExcludeMuteNotificationToUserID>
         </Article>
         <!--Zero or more repetitions:-->
         <DynamicField>
            <Name>?</Name>
            <!--1 or more repetitions:-->
            <Value>?</Value>
         </DynamicField>
         <!--Zero or more repetitions:-->
         <Attachment>
            <Content>cid:61886944659</Content>
            <ContentType>?</ContentType>
            <Filename>?</Filename>
         </Attachment>
      </TicketCreate>
                            
                        

TicketUpdate

TicketUpdate operation adds the capability to modify attributes from an existing ticket or to add a new article, including attachments and all defined dynamic fields for the ticket and the new article.

Note

It is not necessary to create a new article to modify a ticket attribute.

Possible Attributes:

                            
      <TicketUpdate>
         <!--You have a MANDATORY CHOICE of the next 3 items at this level-->
         <!--Optional:-->
         <UserLogin>?</UserLogin>
         <!--Optional:-->
         <CustomerUserLogin>?</CustomerUserLogin>
         <!--Optional:-->
         <SessionID>?</SessionID>
         <!--Optional:-->
         <Password>?</Password>
         <!--You have a CHOICE of the next 2 items at this level-->
         <TicketID>?</TicketID>
         <TicketNumber>?</TicketNumber>
         <!--Optional:-->
         <Ticket>
            <!--Optional:-->
            <Title>?</Title>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <QueueID>?</QueueID>
            <!--Optional:-->
            <Queue>?</Queue>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <TypeID>?</TypeID>
            <!--Optional:-->
            <Type>?</Type>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <ServiceID>?</ServiceID>
            <!--Optional:-->
            <Service>?</Service>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <SLAID>?</SLAID>
            <!--Optional:-->
            <SLA>?</SLA>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <StateID>?</StateID>
            <!--Optional:-->
            <State>?</State>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <PriorityID>?</PriorityID>
            <!--Optional:-->
            <Priority>?</Priority>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <OwnerID>?</OwnerID>
            <!--Optional:-->
            <Owner>?</Owner>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <ResponsibleID>?</ResponsibleID>
            <!--Optional:-->
            <Responsible>?</Responsible>
            <!--Optional:-->
            <CustomerUser>?</CustomerUser>
            <!--Optional:-->
            <CustomerID>?</CustomerID>
            <!--Optional:-->
            <PendingTime>
               <!--You have a CHOICE of the next and the other 5 items at this level-->
               <Diff>?</Diff>
               <Year>?</Year>
               <Month>?</Month>
               <Day>?</Day>
               <Hour>?</Hour>
               <Minute>?</Minute>
            </PendingTime>
         </Ticket>
         <!--Optional:-->
         <Article>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <CommunicationChannelID>?</CommunicationChannelID>
            <!--Optional: Possible values Email, Internal or Phone-->
            <CommunicationChannel>?</CommunicationChannel>
            <IsVisibleForCustomer>?</IsVisibleForCustomer>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <SenderTypeID>?</SenderTypeID>
            <!--Optional:-->
            <SenderType>?</SenderType>
            <!--Optional:-->
            <From>?</From>
            <Subject>?</Subject>
            <Body>?</Body>
            <!--You have a CHOICE of the next 2 items at this level-->
            <!--Optional:-->
            <ContentType>?</ContentType>
            <Charset>?</Charset>
            <MimeType>?</MimeType>
            <!--Optional:-->
            <HistoryType>?</HistoryType>
            <!--Optional:-->
            <HistoryComment>?</HistoryComment>
            <!--Optional:-->
            <AutoResponseType>?</AutoResponseType>
            <!--Optional:-->
            <TimeUnit>?</TimeUnit>
            <!--Optional:-->
            <NoAgentNotify>?</NoAgentNotify>
            <!--Zero or more repetitions:-->
            <ForceNotificationToUserID>?</ForceNotificationToUserID>
            <!--Zero or more repetitions:-->
            <ExcludeNotificationToUserID>?</ExcludeNotificationToUserID>
            <!--Zero or more repetitions:-->
            <ExcludeMuteNotificationToUserID>?</ExcludeMuteNotificationToUserID>
         </Article>
         <!--Zero or more repetitions:-->
         <DynamicField>
            <Name>?</Name>
            <!--1 or more repetitions:-->
            <Value>?</Value>
         </DynamicField>
         <!--Zero or more repetitions:-->
         <Attachment>
            <Content>cid:166861569966</Content>
            <ContentType>?</ContentType>
            <Filename>?</Filename>
         </Attachment>
      </TicketUpdate>
                            
                        

TicketGet

This operation is used to get all the attributes of a ticket including the dynamic fields, all articles and all of the attachments that belong to the ticket.

Possible Attributes:

                            
      <TicketGet>
         <!--You have a MANDATORY CHOICE of the next 3 items at this level-->
         <!--Optional:-->
         <UserLogin>?</UserLogin>
         <!--Optional:-->
         <CustomerUserLogin>?</CustomerUserLogin>
         <!--Optional:-->
         <SessionID>?</SessionID>
         <!--Optional:-->
         <Password>?</Password>
         <!--1 or more repetitions:-->
         <TicketID>?</TicketID>
         <!--Optional:-->
         <DynamicFields>?</DynamicFields>
         <!--Optional:-->
         <Extended>?</Extended>
         <!--Optional:-->
         <AllArticles>?</AllArticles>
         <!--Optional:-->
         <ArticleSenderType>?</ArticleSenderType>
         <!--Optional:-->
         <ArticleOrder>?</ArticleOrder>
         <!--Optional:-->
         <ArticleLimit>?</ArticleLimit>
         <!--Optional:-->
         <Attachments>?</Attachments>
         <!--Optional:-->
         <GetAttachmentContents>?</GetAttachmentContents>
         <!--Optional:-->
         <HTMLBodyAsAttachment>?</HTMLBodyAsAttachment>
      </TicketGet>
                            
                        

TicketSearch

TicketSearch operation returns a list of Ticket IDs that matches a predefined criteria.

Possible Attributes:

                            
      <TicketSearch>
         <!--You have a MANDATORY CHOICE of the next 3 items at this level-->
         <!--Optional:-->
         <UserLogin>?</UserLogin>
         <!--Optional:-->
         <CustomerUserLogin>?</CustomerUserLogin>
         <!--Optional:-->
         <SessionID>?</SessionID>
         <!--Optional:-->
         <Password>?</Password>
         <!--Optional:-->
         <Limit>?</Limit>
         <!--Zero or more repetitions:-->
         <TicketNumber>?</TicketNumber>
         <!--Zero or more repetitions:-->
         <Title>?</Title>
         <!--Zero or more repetitions:-->
         <Queues>?</Queues>
         <!--Zero or more repetitions:-->
         <QueueIDs>?</QueueIDs>
         <!--Optional:-->
         <UseSubQueues>?</UseSubQueues>
         <!--Zero or more repetitions:-->
         <Types>?</Types>
         <!--Zero or more repetitions:-->
         <TypeIDs>?</TypeIDs>
         <!--Zero or more repetitions:-->
         <States>?</States>
         <!--Zero or more repetitions:-->
         <StateIDs>?</StateIDs>
         <!--Zero or more repetitions:-->
         <StateType>?</StateType>
         <!--Zero or more repetitions:-->
         <StateTypeIDs>?</StateTypeIDs>
         <!--Zero or more repetitions:-->
         <Priorities>?</Priorities>
         <!--Zero or more repetitions:-->
         <PriorityIDs>?</PriorityIDs>
         <!--Zero or more repetitions:-->
         <Services>?</Services>
         <!--Zero or more repetitions:-->
         <ServiceIDs>?</ServiceIDs>
         <!--Zero or more repetitions:-->
         <SLAs>?</SLAs>
         <!--Zero or more repetitions:-->
         <SLAIDs>?</SLAIDs>
         <!--Zero or more repetitions:-->
         <Locks>?</Locks>
         <!--Zero or more repetitions:-->
         <LockIDs>?</LockIDs>
         <!--Zero or more repetitions:-->
         <OwnerIDs>?</OwnerIDs>
         <!--Zero or more repetitions:-->
         <ResponsibleIDs>?</ResponsibleIDs>
         <!--Zero or more repetitions:-->
         <WatchUserIDs>?</WatchUserIDs>
         <!--Zero or more repetitions:-->
         <CustomerID>?</CustomerID>
         <!--Zero or more repetitions:-->
         <CustomerUserLogin>?</CustomerUserLogin>
         <!--Zero or more repetitions:-->
         <CreatedUserIDs>?</CreatedUserIDs>
         <!--Zero or more repetitions:-->
         <CreatedTypes>?</CreatedTypes>
         <!--Zero or more repetitions:-->
         <CreatedTypeIDs>?</CreatedTypeIDs>
         <!--Zero or more repetitions:-->
         <CreatedPriorities>?</CreatedPriorities>
         <!--Zero or more repetitions:-->
         <CreatedPriorityIDs>?</CreatedPriorityIDs>
         <!--Zero or more repetitions:-->
         <CreatedStates>?</CreatedStates>
         <!--Zero or more repetitions:-->
         <CreatedStateIDs>?</CreatedStateIDs>
         <!--Zero or more repetitions:-->
         <CreatedQueues>?</CreatedQueues>
         <!--Zero or more repetitions:-->
         <CreatedQueueIDs>?</CreatedQueueIDs>
         <!--Zero or more repetitions:-->
         <DynamicField>
            <Name>?<Name>
            <!--You have a MANDATORY CHOICE of the next 6 items at this level-->
            <!--Optional:-->
            <Equals>?</Equals>
            <!--Optional:-->
            <Like>?</Like>
            <!--Optional:-->
            <GreaterThan>?</GreaterThan>
            <!--Optional:-->
            <GreaterThanEquals>?</GreaterThanEquals>
            <!--Optional:-->
            <SmallerThan>?</SmallerThan>
            <!--Optional:-->
            <SmallerThanEquals>?</SmallerThanEquals>
         </DynamicField>
         <!--Optional:-->
         <Ticketflag>
            <!--Optional:-->
            <Seen>?</Seen>
         </Ticketflag>
         <!--Optional:-->
         <From>?</From>
         <!--Optional:-->
         <To>?</To>
         <!--Optional:-->
         <Cc>?</Cc>
         <!--Optional:-->
         <Subject>?</Subject>
         <!--Optional:-->
         <Body>?</Body>
         <!--Optional:-->
         <FullTextIndex>?</FullTextIndex>
         <!--Optional:-->
         <ContentSearch>?</ContentSearch>
         <!--Optional:-->
         <ConditionInline>?</ConditionInline>
         <!--Optional:-->
         <ArticleCreateTimeOlderMinutes>?</ArticleCreateTimeOlderMinutes>
         <!--Optional:-->
         <ArticleCreateTimeNewerMinutes>?</ArticleCreateTimeNewerMinutes>
         <!--Optional:-->
         <ArticleCreateTimeNewerDate>?</ArticleCreateTimeNewerDate>
         <!--Optional:-->
         <ArticleCreateTimeOlderDate>?</ArticleCreateTimeOlderDate>
         <!--Optional:-->
         <TicketCreateTimeOlderMinutes>?</TicketCreateTimeOlderMinutes>
         <!--Optional:-->
         <ATicketCreateTimeNewerMinutes>?</ATicketCreateTimeNewerMinutes>
         <!--Optional:-->
         <TicketCreateTimeNewerDate>?</TicketCreateTimeNewerDate>
         <!--Optional:-->
         <TicketCreateTimeOlderDate>?</TicketCreateTimeOlderDate>
         <!--Optional:-->
         <TicketLastChangeTimeOlderMinutes>?</TicketLastChangeTimeOlderMinutes>
         <!--Optional:-->
         <TicketLastChangeTimeNewerMinutes>?</TicketLastChangeTimeNewerMinutes>
         <!--Optional:-->
         <TicketLastChangeTimeNewerDate>?</TicketLastChangeTimeNewerDate>
         <!--Optional:-->
         <TicketLastChangeTimeOlderDate>?</TicketLastChangeTimeOlderDate>
         <!--Optional:-->
         <TicketChangeTimeOlderMinutes>?</TicketChangeTimeOlderMinutes>
         <!--Optional:-->
         <TicketChangeTimeNewerMinutes>?</TicketChangeTimeNewerMinutes>
         <!--Optional:-->
         <TicketChangeTimeNewerDate>?</TicketChangeTimeNewerDate>
         <!--Optional:-->
         <TicketChangeTimeOlderDate>?</TicketChangeTimeOlderDate>
         <!--Optional:-->
         <TicketCloseTimeOlderMinutes>?</TicketCloseTimeOlderMinutes>
         <!--Optional:-->
         <TicketCloseTimeNewerMinutes>?</TicketCloseTimeNewerMinutes>
         <!--Optional:-->
         <TicketCloseTimeNewerDate>?</TicketCloseTimeNewerDate>
         <!--Optional:-->
         <TicketCloseTimeOlderDate>?</TicketCloseTimeOlderDate>
         <!--Optional:-->
         <TicketPendingTimeOlderMinutes>?</TicketPendingTimeOlderMinutes>
         <!--Optional:-->
         <TicketPendingTimeNewerMinutes>?</TicketPendingTimeNewerMinutes>
         <!--Optional:-->
         <TicketPendingTimeNewerDate>?</TicketPendingTimeNewerDate>
         <!--Optional:-->
         <TicketPendingTimeOlderDate>?</TicketPendingTimeOlderDate>
         <!--Optional:-->
         <TicketEscalationTimeOlderMinutes>?</TicketEscalationTimeOlderMinutes>
         <!--Optional:-->
         <TTicketEscalationTimeNewerMinutes>?</TTicketEscalationTimeNewerMinutes>
         <!--Optional:-->
         <TicketEscalationTimeNewerDate>?</TicketEscalationTimeNewerDate>
         <!--Optional:-->
         <TicketEscalationTimeOlderDate>?</TicketEscalationTimeOlderDate>
         <!--Optional:-->
         <ArchiveFlags>?</ArchiveFlags>
         <!--Zero or more repetitions:-->
         <OrderBy>?</OrderBy>
         <!--Zero or more repetitions:-->
         <SortBy>?</SortBy>
         <!--Zero or more repetitions:-->
         <CustomerUserID>?</CustomerUserID>
      </TicketSearch>
                            
                        

TicketHistoryGet

This operation is used to get all the history entries from a ticket or tickets.

Possible Attributes:

                            
      <TicketHistoryGet>
         <!--You have a MANDATORY CHOICE of the next 2 items at this level-->
         <!--Optional:-->
         <UserLogin>?</UserLogin>
         <!--Optional:-->
         <SessionID>?</SessionID>
         <!--Optional:-->
         <Password>?</Password>
         <!--1 or more repetitions:-->
         <TicketID>?</TicketID>
      </TicketHistoryGet>
                            
                        

Examples:

Web Service Configuration

The following is a basic but complete web service configuration file in YAML format to use all the Ticket Connector operations with the SOAP network transport. In order to use it in OTRS you need to copy the content, save it into a file and call it GenericTicketConnectorSOAP.yml, and import it into OTRS in the Web Services screen in the Admin panel by clicking in the "Add web service" button from the overview screen and then clicking in the "Import web service" button in the add screen.

                    
---
Debugger:
  DebugThreshold: debug
  TestMode: 0
Description: Ticket Connector SOAP Sample
FrameworkVersion: 3.4.x git
Provider:
  Operation:
    SessionCreate:
      Description: Creates a Session
      MappingInbound: {}
      MappingOutbound: {}
      Type: Session::SessionCreate
    TicketCreate:
      Description: Creates a Ticket
      MappingInbound: {}
      MappingOutbound: {}
      Type: Ticket::TicketCreate
    TicketUpdate:
      Description: Updates a Ticket
      MappingInbound: {}
      MappingOutbound: {}
      Type: Ticket::TicketUpdate
    TicketGet:
      Description: Retrieves Ticket data
      MappingInbound: {}
      MappingOutbound: {}
      Type: Ticket::TicketGet
    TicketSearch:
      Description: Search for Tickets
      MappingInbound: {}
      MappingOutbound: {}
      Type: Ticket::TicketSearch
    TicketHistoryGet:
      Description: Retrieves history of a Ticket
      MappingInbound: {}
      MappingOutbound: {}
      Type: Ticket::TicketHistoryGet
  Transport:
    Config:
      MaxLength: 100000000
      NameSpace: http://www.otrs.org/TicketConnector/
    Type: HTTP::SOAP
RemoteSystem: ''
Requester:
  Transport:
    Type: ''
                    
                

Similar example can be done for the REST network transport, REST web services uses HTTP operations such as "POST", "GET", "PUT", "PATCH" etc. This operations in conjunction with a URI path called resource defines a OTRS Generic Interface Operation or Invoker (depending on the communication way).

The following example uses /Session resource for SessionCreate, /Ticket resource for TicketSearch and TicketCreate and resource /Ticket/{TicketID} for TicketGet and TicketUpdate (Where {TicketID} is the actual TicketID value of a ticket e.g. /Ticket/123). In order to use it in OTRS you need to copy the content, save it into a file and call it GenericTicketConnectorREST.yml, and import it into OTRS in the Web Services screen in the Admin panel by clicking in the "Add web service" button from the overview screen and then clicking in the "Import web service" button in the add screen.

                    
---
Debugger:
  DebugThreshold: debug
  TestMode: '0'
Description: Ticket Connector REST Sample
FrameworkVersion: 3.4.x git
Provider:
  Operation:
    SessionCreate:
      Description: Creates a Session
      MappingInbound: {}
      MappingOutbound: {}
      Type: Session::SessionCreate
    TicketCreate:
      Description: Creates a Ticket
      MappingInbound: {}
      MappingOutbound: {}
      Type: Ticket::TicketCreate
    TicketGet:
      Description: Retrieves Ticket data
      MappingInbound: {}
      MappingOutbound: {}
      Type: Ticket::TicketGet
    TicketSearch:
      Description: Search for Tickets
      MappingInbound: {}
      MappingOutbound: {}
      Type: Ticket::TicketSearch
    TicketUpdate:
      Description: Updates a Ticket
      MappingInbound: {}
      MappingOutbound: {}
      Type: Ticket::TicketUpdate
    TicketHistoryGet:
      Description: Retrieves history of a Ticket
      MappingInbound: {}
      MappingOutbound: {}
      Type: Ticket::TicketHistoryGet
  Transport:
    Config:
      KeepAlive: ''
      MaxLength: '100000000'
      RouteOperationMapping:
        SessionCreate:
          RequestMethod:
          - POST
          Route: /Session
        TicketCreate:
          RequestMethod:
          - POST
          Route: /Ticket
        TicketGet:
          RequestMethod:
          - GET
          Route: /Ticket/:TicketID
        TicketSearch:
          RequestMethod:
          - GET
          Route: /Ticket
        TicketUpdate:
          RequestMethod:
          - PATCH
          Route: /Ticket/:TicketID
        TicketHistoryGet:
          RequestMethod:
          - GET
          Route: /TicketHistory/:TicketID
    Type: HTTP::REST
RemoteSystem: ''
Requester:
  Transport:
    Type: ''
                    
                

Perl SOAP Requester

The following code is a Perl script that can connect to OTRS via the generic interface. In order to perform the operations provided by the Ticket Connector, it uses two Perl CPAN modules SOAP::Lite and Data::Dumper. Please make sure that your environment is capable to use these modules before you try to run the script.

                    
#!/usr/bin/perl -w
# --
# otrs.SOAPRequest.pl - sample to send a SOAP request to OTRS Generic Interface Ticket Connector
# Copyright (C) 2001-2018 OTRS AG, https://otrs.com/
# --
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see https://www.gnu.org/licenses/gpl-3.0.txt.
# --

use strict;
use warnings;

# use ../ as lib location
use File::Basename;
use FindBin qw($RealBin);
use lib dirname($RealBin);

use SOAP::Lite;
use Data::Dumper;

# ---
# Variables to be defined.

# this is the URL for the web service
# the format is
# <HTTP_TYPE>:://<OTRS_FQDN>/nph-genericinterface.pl/Webservice/<WEB_SERVICE_NAME>
# or
# <HTTP_TYPE>:://<OTRS_FQDN>/nph-genericinterface.pl/WebserviceID/<WEB_SERVICE_ID>
my $URL = 'http://localhost/otrs/nph-genericinterface.pl/Webservice/GenericTicketConnector';

# this name space should match the specified name space in the SOAP transport for the web service.
my $NameSpace = 'http://www.otrs.org/TicketConnector/';

# this is operation to execute, it could be TicketCreate, TicketUpdate, TicketGet, TicketSearch
# or SessionCreate. and they must to be defined in the web service.
my $Operation = 'TicketCreate';

# this variable is used to store all the parameters to be included on a request in XML format. Each
# operation has a determined set of mandatory and non mandatory parameters to work correctly. Please
# check the OTRS Admin Manual in order to get a complete list of parameters.
my $XMLData = '
<UserLogin>some user login</UserLogin>
<Password>some password</Password>
<Ticket>
    <Title>some title</Title>
    <CustomerUser>some customer user login</CustomerUser>
    <Queue>some queue</Queue>
    <State>some state</State>
    <Priority>some priority</Priority>
</Ticket>
<Article>
    <Subject>some subject</Subject>
    <Body>some body</Body>
    <ContentType>text/plain; charset=utf8</ContentType>
</Article>
';

# ---

# create a SOAP::Lite data structure from the provided XML data structure.
my $SOAPData = SOAP::Data
    ->type( 'xml' => $XMLData );

my $SOAPObject = SOAP::Lite
    ->uri($NameSpace)
    ->proxy($URL)
    ->$Operation($SOAPData);

# check for a fault in the soap code.
if ( $SOAPObject->fault ) {
    print $SOAPObject->faultcode, " ", $SOAPObject->faultstring, "\n";
}

# otherwise print the results.
else {

    # get the XML response part from the SOAP message.
    my $XMLResponse = $SOAPObject->context()->transport()->proxy()->http_response()->content();

    # deserialize response (convert it into a perl structure).
    my $Deserialized = eval {
        SOAP::Deserializer->deserialize($XMLResponse);
    };

    # remove all the headers and other not needed parts of the SOAP message.
    my $Body = $Deserialized->body();

    # just output relevant data and no the operation name key (like TicketCreateResponse).
    for my $ResponseKey ( keys %{$Body} ) {
        print Dumper( $Body->{$ResponseKey} );
    }
}
                    
                

Perl REST Requester

The following code is a Perl script that can connect to OTRS via the generic interface. In order to perform the operations provided by the Ticket Connector, it uses three Perl CPAN modules JSON, REST::Client and Data::Dumper. Please make sure that your environment is capable to use these modules before you try to run the script.

                    
#!/usr/bin/perl
# --
# Copyright (C) 2001-2018 OTRS AG, https://otrs.com/
# --
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see https://www.gnu.org/licenses/gpl-3.0.txt.
# --

use strict;
use warnings;
use utf8;

## nofilter(TidyAll::Plugin::OTRS::Perl::Dumper)

# use ../ as lib location
use File::Basename;
use FindBin qw($RealBin);
use lib dirname($RealBin);

use JSON;
use REST::Client;

# This is the HOST for the web service the format is:
# <HTTP_TYPE>:://<OTRS_FQDN>/nph-genericinterface.pl
my $Host = 'http://localhost/otrs/nph-genericinterface.pl';

my $RestClient = REST::Client->new(
    {
        host => $Host,
    }
);

# These are the Controllers and Providers the format is:
# /Webservice/<WEB_SERVICE_NAME>/<RESOURCE>/<REQUEST_VALUE>
# or
# /WebserviceID/<WEB_SERVICE_ID>/<RESOURCE>/<REQUEST_VALUE>
#
# See the documentation on how to setup Providers.
#
# This example will retrieve the Ticket with the TicketID = 1 (<REQUEST_VALUE>)
my $GetControllerAndRequest = '/Webservice/GenericTicketConnectorREST/Ticket/1';

# This example is the base URL for Ticket Create
my $CreateControllerAndRequest = '/Webservice/GenericTicketConnectorREST/Ticket';

# This example will update the Ticket with the TicketID = 1 (<REQUEST_VALUE>)
my $UpdateControllerAndRequest = '/Webservice/GenericTicketConnectorREST/Ticket/1';

# This is the base URL for Ticket Search
my $SearchControllerAndRequest = '/Webservice/GenericTicketConnectorREST/Ticket';

# This is the base URL for Ticket history with the TicketID = 1 (<REQUEST_VALUE>)
my $HistoryControllerAndRequest = '/Webservice/GenericTicketConnectorREST/TicketHistory/1';

# TicketGet Example
# See the documentation of OTRSGenericInterfaceREST on how to setup
#   - webservice
#   - transport
#   - operations
my $GetParams = {
    UserLogin => "some agent user login",       # to be filled with valid agent login
    Password  => "some agent user password",    # to be filled with valid agent password
};

# Build GetParams as part of the URL for REST-GET requests
my $QueryParams = $RestClient->buildQuery( %{$GetParams} );
$GetControllerAndRequest .= $QueryParams;

$RestClient->GET($GetControllerAndRequest);

my $GetResponseCode = $RestClient->responseCode();

if ( $GetResponseCode ne '200' ) {
    print "Get request failed, response code was: $GetResponseCode\n";
}
else {

    # If the request was answered correctly, we receive a JSON string here.
    my $ResponseContent = $RestClient->responseContent();

    my $Data = decode_json $ResponseContent;

    # Just to print out the returned Data structure:
    use Data::Dumper;
    print "Get response was:\n";
    print Dumper($Data);

}

# TicketSearch Example
# See the documentation of OTRSGenericInterfaceREST on how to setup
#   - webservice
#   - transport
#   - operations
my $SearchParams = {
    UserLogin => "some agent user login",       # to be filled with valid agent login
    Password  => "some agent user password",    # to be filled with valid agent password
    Queues    => ['Raw'],
};

# Build SearchParams as part of the URL for REST-GET requests
$QueryParams = $RestClient->buildQuery( %{$SearchParams} );
$SearchControllerAndRequest .= $QueryParams;

$RestClient->GET($SearchControllerAndRequest);

# If the host isn't reachable, wrong configured or couldn't serve the requested page:
my $SearchResponseCode = $RestClient->responseCode();

if ( $SearchResponseCode ne '200' ) {
    print "Search request failed, response code was: $SearchResponseCode\n";
}
else {

    # If the request was answered correctly, we receive a JSON string here.
    my $ResponseContent = $RestClient->responseContent();

    my $Data = decode_json $ResponseContent;

    # Just to print out the returned Data structure:
    use Data::Dumper;
    print "Search Response was:\n";
    print Dumper($Data);

}

# TicketCreate Example
# See the documentation of OTRSGenericInterfaceREST on how to setup
# - webservice
# - transport
# - operations
my $CreateOrUpdateParams = {
    UserLogin => "some agent user login",       # to be filled with valid agent login
    Password  => "some agent user password",    # to be filled with valid agent password
    Ticket    => {
        Title        => 'some ticket title',
        Queue        => 'Raw',
        Lock         => 'unlock',
        Type         => 'Unclassified',
        State        => 'new',
        Priority     => '3 normal',
        Owner        => 'some agent user login',
        CustomerUser => 'customer-1',
    },
    Article => {
        Subject     => 'some subject',
        Body        => 'some body',
        ContentType => 'text/plain; charset=utf8',
    },
};

my $CreateJSONParams = encode_json $CreateOrUpdateParams;

my @CreateRequestParam = (
    $CreateControllerAndRequest,
    $CreateJSONParams
);

# We have to use REST-POST requests in order to send UserLogin and Password correctly
# though other REST methods would fit better.
$RestClient->POST(@CreateRequestParam);

# If the host isn't reachable, wrong configured or couldn't serve the requested page:
my $CreateResponseCode = $RestClient->responseCode();

if ( $CreateResponseCode ne '200' ) {
    print "Create request failed, response code was: $CreateResponseCode\n";
}
else {

    # If the request was answered correctly, we receive a JSON string here.
    my $ResponseContent = $RestClient->responseContent();

    my $Data = decode_json $ResponseContent;

    # Just to print out the returned Data structure:
    use Data::Dumper;
    print "Create Response was:\n";
    print Dumper($Data);

}

# TicketUpdate Example
# See the documentation of OTRSGenericInterfaceREST on how to setup
#   - webservice
#   - transport
#   - operations
my $UpdateJSONParams = encode_json $CreateOrUpdateParams;

my @UpdateRequestParam = (
    $UpdateControllerAndRequest,
    $UpdateJSONParams
);

# We have to use REST-PATCH requests in order to send UserLogin and Password correctly
# though other REST methods would fit better.
$RestClient->PATCH(@UpdateRequestParam);

# If the host isn't reachable, wrong configured or couldn't serve the requested page:
my $UpdateResponseCode = $RestClient->responseCode();
if ( $UpdateResponseCode ne '200' ) {
    print "Update request failed, response code was: $UpdateResponseCode\n";
}
else {

    # If the request was answered correctly, we receive a JSON string here.
    my $ResponseContent = $RestClient->responseContent();

    my $Data = decode_json $ResponseContent;

    # Just to print out the returned Data structure:
    use Data::Dumper;
    print "Update response was:\n";
    print Dumper($Data);

}

# TicketHistoryGet Example
# See the documentation of OTRSGenericInterfaceREST on how to setup
#   - webservice
#   - transport
#   - operations
my $HistoryParams = {
    UserLogin => "some agent user login",       # to be filled with valid agent login
    Password  => "some agent user password",    # to be filled with valid agent password
    TicketID  => [1],
};

# Build SearchParams as part of the URL for REST-GET requests
$QueryParams = $RestClient->buildQuery( %{$HistoryParams} );
$HistoryControllerAndRequest .= $QueryParams;

$RestClient->GET($HistoryControllerAndRequest);

# If the host isn't reachable, wrong configured or couldn't serve the requested page:
my $HistoryResponseCode = $RestClient->responseCode();

if ( $HistoryResponseCode ne '200' ) {
    print "History request failed, response code was: $HistoryResponseCode\n";
}
else {

    # If the request was answered correctly, we receive a JSON string here.
    my $ResponseContent = $RestClient->responseContent();

    my $Data = decode_json $ResponseContent;

    # Just to print out the returned Data structure:
    use Data::Dumper;
    print "History Response was:\n";
    print Dumper($Data);

}

                    
                

cURL Examples for REST Requests

Given the above example on a REST configuration for Generic Ticket Connector we have that:

For Ticket Create: use POST method on /Ticket path.

For Ticket Search: use GET method on /Ticket path.

For Ticket Update: use PATCH method on /Ticket/{TicketID} path (where {TicketID} is a template represented by :TicketID in the transport configuration)

For Ticket Get: use GET method on /Ticket/{TicketID} path (where {TicketID} is a template represented by :TicketID in the transport configuration)

For Ticket History Get: use GET method on /TicketHistory/{TicketID} path (where {TicketID} is a template represented by :TicketID in the transport configuration)

Create a New Ticket

cURL Command:


shell> curl "http://localhost/otrs/nph-genericinterface.pl/Webservice/GenericTicketConnectorREST/Ticket?UserLogin=agent&Password=123" -H "Content-Type: application/json" -d "{\"Ticket\":{\"Title\":\"REST Create Test\", \"Type\": \"Unclassified\", \"Queue\":\"Raw\",\"State\":\"open\",\"Priority\":\"3 normal\",\"CustomerUser\":\"customer\"},\"Article\":{\"Subject\":\"Rest Create Test\",\"Body\":\"This is only a test\",\"ContentType\":\"text/plain; charset=utf8\"}}"  -X POST

                    

Response:

{
  "ArticleID":5484,
  "TicketNumber":"1001936",
  "TicketID":"1686"
}
                    

Get Ticket Details

cURL Command:


curl "http://localhost/otrs/nph-genericinterface.pl/Webservice/GenericTicketConnectorREST/Ticket/1686?UserLogin=agent&Password=123"

                    

Response:

{
  "Ticket": [
    {
      "Age": 777,
      "PriorityID": 3,
      "ServiceID": "",
      "Type": "Unclassified",
      "Responsible": "root@localhost",
      "StateID": 4,
      "ResponsibleID": 1,
      "ChangeBy": 2,
      "EscalationTime": 0,
      "Changed": "2014-06-30 19:08:14",
      "OwnerID": 2,
      "RealTillTimeNotUsed": 0,
      "GroupID": 1,
      "Owner": "agent",
      "CustomerID": "OTRS",
      "TypeID": 1,
      "Created": "2014-06-30 19:08:12",
      "Priority": "3 normal",
      "UntilTime": 0,
      "EscalationUpdateTime": 0,
      "QueueID": 2,
      "Queue": "Raw",
      "State": "open",
      "Title": "REST Create Test",
      "CreateBy": 2,
      "TicketID": 1686,
      "StateType": "open",
      "EscalationResponseTime": 0,
      "UnlockTimeout": 0,
      "EscalationSolutionTime": 0,
      "LockID": 1,
      "TicketNumber": "1001936",
      "ArchiveFlag": "n",
      "Lock": "unlock",
      "CreateTimeUnix": 1404173292,
      "SLAID": "",
      "CustomerUserID": "customer"
    }
  ]
}
                    

Update Ticket

cURL Command:


curl "http://localhost/otrs/nph-genericinterface.pl/Webservice/GenericTicketConnectorREST/Ticket/1686?UserLogin=agent&Password=123" -H "Content-Type: application/json" -d "{\"Ticket\":{\"Queues\":\"Postmaster\"}}"  -X PATCH

                    

Response:

{
  "TicketNumber":"1001936",
  "TicketID":"1686"
}
                    

Search for Tickets

cURL Command:


curl "http://localhost/otrs/nph-genericinterface.pl/Webservice/GenericTicketConnectorREST/Ticket?UserLogin=agent&Password=123&Queue=Postmaster"

                    

Response:

{
  "TicketID": [
    "1686",
    "102",
    "100",
    "1"
  ]
}
                    

Get Ticket History Details

cURL Command:


curl "http://localhost/otrs/nph-genericinterface.pl/Webservice/GenericTicketConnectorREST/TicketHistory/1686?UserLogin=agent&Password=123"

                    

Response:

{
  "TicketHistory":[
    {
      "History":[
        {
          "CreateBy":1,
          "HistoryType":"NewTicket",
          "TicketID":"1",
          "CreateTime":"2017-06-08 22:44:48",
          "TypeID":1,
          "OwnerID":1,
          "QueueID":1,
          "Name":"New Ticket [2015071510123456] created.",
          "StateID":1,
          "PriorityID":3,
          "ArticleID":"1",
          "HistoryTypeID":1
        }
      ],
      "TicketID":"1"
    }
  ]
}