1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<!-- $Id: genericinterface-layers.xml,v 1.2 2011/10/21 05:01:40 mb Exp $ -->
<section id="genericinterface-layers">
<title>Generic Interface Layers</title>
<para>
Generic Interface is build based on a layer model, to be flexible and easy to customize.
</para>
<para>
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.
</para>
<note>
<para>
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.
</para>
<para>
The list of provided Generic Interface modules shipped with OTRS will be updated and
increased over time.
</para>
</note>
<para>
<screenshot>
<screeninfo>The Generic Interface Layers</screeninfo>
<graphic srccredit="genericinterface layers - screenshot" scale="50" fileref="screenshots/genericinterface-layers.png"></graphic>
</screenshot>
</para>
<para>
<emphasis>Figure: The graphical interface layers.</emphasis>
</para>
<section>
<title>Network Transport</title>
<para>
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.
</para>
<para>
Provider communication is handled by a new web server handle called
"nph-genericinterface.pl".
</para>
<para>
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 deamon designed to process tasks asynchronously).
</para>
</section>
<section>
<title>Data Mapping</title>
<para>
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.
</para>
<para>
<remark>Example: </remark>
"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.
</para>
</section>
<section>
<title>Controller</title>
<para>
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.
</para>
<para>
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.
</para>
</section>
<section>
<title>Operation (OTRS as a provider)</title>
<para>
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.
</para>
<para>
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.
</para>
</section>
<section>
<title>Invoker (OTRS as a requester)</title>
<para>
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.
</para>
</section>
</section>
|
