Source string Read only

type: Content of: <section><section><section><section><para>
459/4590
Context English State
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.
Web service requester network transport (HTTP::REST)
<graphic fileref="screenshots/administration/genericinterface/genericinterface-webservice-requester-transport-rest.png" scalefit="1" width="100%" contentdepth="100%"></graphic>
Web Service Invoker
The actions that can be performed when you are using OTRS as a requester are called <emphasis>Invokers</emphasis>. 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.
<emphasis>Name</emphasis>, <emphasis>Description</emphasis>, <emphasis>Backend</emphasis> and <emphasis>Mappings</emphasis> 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 <literal>TicketCreate</literal>, <literal>ArticleSend</literal>, 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.
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 <emphasis>Event Triggers</emphasis> list.
From the <emphasis>Event Triggers</emphasis> 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 <emphasis>Event Triggers</emphasis> 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 <emphasis>Delete</emphasis> to remove the event trigger from the list, or <emphasis>Cancel</emphasis> to close the dialog.
In the left part of the screen on the action column you have the options: <emphasis>Go back to web service</emphasis> (discarding all changes since the last save) and <emphasis>Delete</emphasis>. If you click on the last one, a dialog will open and ask you if you like to remove the invoker. Click on the <emphasis>Delete</emphasis> button to confirm the removal of the invoker and its configuration or <emphasis>Cancel</emphasis> to close the delete dialog.
Web service invoker
<graphic fileref="screenshots/administration/genericinterface/genericinterface-webservice-invoker.png" scalefit="1" width="100%" contentdepth="100%"></graphic>
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 <emphasis>Condition 1</emphasis> if more than one field is planned. Both linking fields accept <emphasis>and</emphasis>, <emphasis>or</emphasis> or <emphasis>xor</emphasis> as values.
Fill the <emphasis>Field</emphasis> name, set the matching type (<emphasis>String</emphasis> for exact match, <emphasis>Regexp</emphasis> for regular expression or <emphasis>Validation Module</emphasis>) and set Value to match (in case of <emphasis>Validation Module</emphasis> the full class name like: <literal>Kernel::GenericInterface::Event::Validation::ValidateDemo</literal>).
To add more fields to the condition, click on the <emphasis>+</emphasis> button in the fields header. To remove a field, click on the <emphasis>-</emphasis> 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 <emphasis>-</emphasis> 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.
Web service invoker event
<graphic fileref="screenshots/administration/genericinterface/genericinterface-webservice-invoker-event.png" scalefit="1" width="100%" contentdepth="100%"></graphic>
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 <literal>Mapping::Simple</literal> should cover most of the mapping needs.
When <literal>Mapping::Simple</literal> 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.

Loading…

User avatar None

New source string

OTRS 6 / Administration ManualEnglish

New source string a year ago
Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
type: Content of: <section><section><section><section><para>
Flags
read-only
Source string location
en/content/administration/genericinterface/genericinterface-webservice-gui.xml:948
String age
a year ago
Source string age
a year ago
Translation file
i18n/doc-admin.pot, string 2467