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
119
120
121
122
123
124
125
|
<?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.1 2012/02/23 13:44:38 mg 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>
|
