Die Aktionen, die ausgeführt werden können, wenn Sie OTRS als Requester verwenden, werden Invoker genannt. Jeder Invoker gehört zu einem Controller (Controller sind Sammlungen von Operationen oder Invokern). In der Regel benötigen Invoker desselben Controllers ähnliche Einstellungen und teilen sich die gleichen Konfigurationsdialoge. Jeder Invoker kann bei Bedarf unabhängige Konfigurationsdialoge haben.
Nach der Installation des Pakets stehen zwei neue Invoker im Abschnitt Invoker zur Verfügung. Wenn Sie einen Invoker aus der Dropdown-Liste auswählen, öffnet sich ein neues Einstellungsfenster.
Beispiel für eine Anfrage
Die Invoker TicketCreate und TicketUpdate geben die kompletten Ticket- und Artikeldaten basierend auf der Ticket-ID und der Artikel-ID des ausgelösten Ereignisses zurück.
Bereiten Sie den Aufruf des konfigurierten Remote-Websrvice vor. Ereignisdaten:
my $Result = $InvokerObject->PrepareRequest(
Data => { # data payload
TicketID => 123,
ArticleID => 123, # optional
},
);
Invoker-Resultat:
{
Data => {
Ticket => {
Title => 'some ticket title',
Queue => 'some queue name',
Lock => 'some lock name', # optional
Type => 'some type name', # optional
Service => 'some service name', # optional
SLA => 'some SLA name', # optional
State => 'some state name',
Priority => 'some priority name',
Owner => 'some user login', # optional
Responsible => 'some user login', # optional
CustomerUser => 'some customer user login',
PendingTime { # optional
Year => 2011,
Month => 12
Day => 03,
Hour => 23,
Minute => 05,
},
},
Article => {
SenderType => 'some sender type name', # optional
AutoResponseType => 'some auto response type', # optional
From => 'some from string', # optional
Subject => 'some subject',
Body => 'some body'
ContentType => 'some content type', # ContentType or MimeType and Charset is required
MimeType => 'some mime type',
Charset => 'some charset',
TimeUnit => 123, # optional
},
DynamicField => [ # optional
{
Name => 'some name',
Value => 'Value', # value type depends on the dynamic field
},
# ...
],
Attachment => [
{
Content => 'content' # base64 encoded
ContentType => 'some content type'
Filename => 'some fine name'
},
# ...
],
},
};
Bemerkung
Der Invoker gibt den neuesten Artikel des Tickets zurück, wenn keine Artikel-ID angegeben wird.
Bemerkung
Der Invoker wird keine dynamischen Felder mit undefinierten Werten zurückgeben, da die gleichnamigen Operationen TicketCreate und TicketUpdate nicht mit dynamischen Feldern mit undefinierten Werten umgehen können.
Erweitertes Filtern für ausgehende Daten
Für ausgehende Daten ist es möglich zu definieren, welche Art von Ticket-, Artikel- oder dynamischen Feldern die Anfrage enthalten soll. Weiterhin ist es möglich, nach Artikeltyp und Artikel-Absendertyp zu filtern.
Die verschiedenen Filteroptionen können innerhalb jeder einzelnen Invoker-Konfiguration ausgewählt werden und sind im Abschnitt Einstellungen für ausgehende Anfragedaten aufgelistet.
Im linken Teil der Ansicht haben Sie in der Spalte „Aktion“ die Möglichkeit, zum Web Service zurückzukehren (wobei alle Änderungen seit der letzten Speicherung verworfen werden) und zu löschen. Wenn Sie auf die letzte Option klicken, wird ein Dialogfeld geöffnet, in dem Sie gefragt werden, ob Sie den Invoker entfernen möchten. Klicken Sie auf die Schaltfläche Löschen, um das Entfernen des Invokers und seiner Konfiguration zu bestätigen, oder klicken Sie auf die Schaltfläche Abbrechen, um den Löschdialog zu schließen.
Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit Stern gekennzeichneten Felder sind Pflichtfelder.
Allgemeine Invoker-Daten
- Name *
-
Der Name der Ressource. In dieses Feld können beliebige Zeichen eingegeben werden, einschließlich Großbuchstaben und Leerzeichen. Der Name wird in der Übersichtstabelle angezeigt.
- Beschreibung
-
Fügen Sie dieser Ressource zusätzliche Informationen hinzu. Es wird empfohlen, dieses Feld als Beschreibung der Ressource zur besseren Übersichtlichkeit immer mit einem vollständigen Satz zu füllen, da der Kommentar auch in der Übersichtstabelle angezeigt wird.
- Invoker-Backend
-
Dieses Invoker Backend-Modul wird aufgerufen, um die an das entfernte System zu sendenden Daten vorzubereiten und dessen Antwortdaten zu verarbeiten. Das Feld ist schreibgeschützt, es wurde in der vorhergehenden Ansicht ausgewählt.
Einstellungen für ausgehende Anfragedaten
- Ticket-Felder
-
Ein Multi-Auswahl-Menü mit den verfügbaren Ticket-Attributen (Feldern), die an ein entferntes System übermittelt werden können. Nur die ausgewählten Felder werden in ausgehende Anfragen aufgenommen.
- Artikelfelder
-
Ein Multi-Select-Menü mit den verfügbaren Artikelattributen (Feldern), die an ein entferntes System übermittelt werden können. Nur die ausgewählten Felder werden in ausgehende Anfragen aufgenommen.
- Dynamische Felder bei Artikeln
-
Ein Mehrfachauswahl-Menü mit den verfügbaren dynamischen Ticket-Feldern, die an ein entferntes System übermittelt werden können. Nur die ausgewählten dynamischen Felder werden in ausgehende Anfragen aufgenommen.
- Dynamische Felder bei Artikeln
-
Ein Mehrfachauswahl-Menü mit den verfügbaren dynamischen Artikelfeldern, die an ein entferntes System übermittelt werden können. Nur die ausgewählten dynamischen Felder werden in ausgehende Anfragen aufgenommen.
- Anzahl der Artikel
-
Ein Textfeld, das die maximale Anzahl von Artikeln enthält, die bei einer ausgehenden Anfrage übertragen werden. Die Artikel werden von den neuesten bis zu den ältesten ausgewählt. Wenn keine Anzahl angegeben wird, wird nur der neueste Artikel übertragen.
- Kommunikationskanäle
-
Die ausgehenden Anfragedaten berücksichtigen nur Artikel der ausgewählten Kommunikationskanäle. Wird das Feld leer gelassen, so werden die von allen Kommunikationskanälen erstellten Artikel verwendet.
- Sichtbarkeit für Kunden
-
Die ausgehenden Anfragedaten berücksichtigen nur Artikel, die mit der ausgewählten Kundensichtbarkeit erstellt wurden.
- Sendertyp
-
Die ausgehenden Anfragedaten berücksichtigen nur Artikel, die von den ausgewählten Absendertypen erstellt wurden. Wird nichts angegeben, werden Artikel aller Absendertypen verwendet.
Mapping
Normalerweise gibt es für jeden Invoker zwei Mapping-Konfigurationsabschnitte, einen für die eingehenden Daten und einen für die ausgehenden Daten. Sie können für jede Mapping-Richtung unterschiedliche Mapping-Typen (Backends) wählen, da ihre Konfiguration unabhängig voneinander und auch unabhängig vom Invoker-Backend ist. Die normale und gängigste Praxis ist, dass der Invoker in beiden Fällen denselben Mapping-Typ mit invertierter Konfiguration verwendet. Die komplette Mapping-Konfiguration erfolgt in einer separaten Ansicht, die vom Mapping-Typ abhängt.
- Mapping für ausgehende Anfragedaten
-
Die Daten vom Invoker werden durch dieses Mapping verarbeitet, um sie in die Art von Daten zu transformieren, die das entfernte System erwartet.
- Mapping für eingehende Antwortdaten
-
Die Antwortdaten werden durch dieses Mapping verarbeitet, um sie in die Art von Daten zu transformieren, die der Invoker erwartet.
Einstellungen für eingehende Antwortdaten
Es ist möglich, bestimmte Daten der eingehenden Antworten automatisch in lokale dynamischen Feldern zu speichern. Die verschiedenen Filter-Optionen können innerhalb jeder einzelnen Aufrufer-Konfiguration ausgewählt werden.
- Dynamisches Feld für die Remote-Ticket-ID
-
Ein Drop-Down-Menü mit den im System verfügbaren dynamischen Ticketfeldern. Wenn ein solches dynamisches Feld ausgewählt wird, wird die vom Remote-System empfangene Ticket-ID verwendet, die innerhalb des ausgewählten dynamischen Feldes gespeichert wird.
- Dynamische Felder bei Artikeln
-
Ein Mehrfachauswahl-Menü, das die verfügbaren dynamischen Ticket-Felder im System enthält. Alle ausgewählten dynamischen Felder, die auch in den Antwortdaten verfügbar sind und Werte enthalten, werden in den lokalen dynamischen Feldern gespeichert.
Die dynamischen Feldwerte der Antwortdaten werden aus der folgenden Datenstruktur verwendet:
<Ticket>
<DynamicField>..</DynamicField>
</Ticket>
und/oder
<Ticket>
<Article>
<DynamicField>..</DynamicField>
</Article>
</Ticket>
Die Systemkonfigurations-Option GenericInterface::Invoker::Settings::ResponseDynamicField wurde als Fallback für die dynamischen Felder hinzugefügt, die die Ergebnis-Ticket-ID der zugehörigen Antwortdaten enthalten sollten. Sie soll verwendet werden, wenn die Konfiguration nicht über die Benutzeroberfläche des Invokers hinzugefügt wurde und beide Konfigurationen nicht gleichzeitig verwendet werden sollen!
Ereignisauslöser
Event-Trigger sind Ereignisse innerhalb von OTRS wie TicketCreate, ArticleSend, etc. Diese können als Auslöser für die Ausführung des Invokers dienen. Jeder Invoker muss mindestens einen Event-Trigger registriert haben, sonst ist der Invoker nutzlos, da er nie aufgerufen wird. Zusätzlich kann eine Reihe von Regeln (Bedingungen) für jedes Ereignis definiert werden, um mehr Kontrolle über die Auslösung der Ereignisse zu haben. Diese Regeln hängen von den Daten des Objekts ab, das mit dem Ereignis verbunden ist. Die asynchrone Eigenschaft der Ereignisauslöser definiert, ob der OTRS-Prozess den Aufrufer behandelt oder ob er an den OTRS-Daemon delegiert wird.
Bemerkung
Der OTRS-Daemon ist ein separater Prozess, der Aufgaben im Hintergrund ausführt. Wenn Sie den OTRS-Daemon verwenden, wird der OTRS-Prozess selbst nicht beeinträchtigt, falls das entfernte System lange braucht, um zu antworten, falls es nicht verfügbar ist oder falls es Netzwerkprobleme gibt. Wenn Sie den OTRS-Daemon nicht verwenden, kann die Nutzung von Web Services dazu führen, dass OTRS langsam ist oder nicht reagiert. Daher ist es sehr empfehlenswert, so oft wie möglich asynchrone Ereignisauslöser zu verwenden.
Um auf diesen Bereich zugreifen zu können, müssen Sie den aktuellen Invoker speichern, indem Sie auf die Schaltfläche Speichern klicken.
- Ereignis
-
Dieser Invoker wird von den konfigurierten Ereignissen ausgelöst.
- Ereignisauslöser hinzufügen
-
Um ein neues Ereignis hinzuzufügen, wählen Sie das Ereignisobjekt und den Ereignisnamen aus und klicken Sie auf den Plus-Button. Asynchrone Ereignisauslöser werden durch den OTRS-Daemon im Hintergrund verarbeitet (empfohlen). Synchrone Ereignisauslöser werden direkt während der Web-Anfrage verarbeitet.
So fügen Sie einen Ereignisauslöser hinzu:
-
Wählen Sie die Ereignisfamilie aus der ersten Liste aus.
-
Wählen Sie den Namen des Ereignisses aus der zweiten Liste aus.
-
Legen Sie als Eigenschaft „asynchron“ fest. Wenn sie nicht markiert ist, bedeutet dies, dass der Ereignisauslöser nicht asynchron sein wird.
-
Klicken Sie auf die Schaltfläche „Plus“. Es wird ein neuer Ereignisauslöser erstellt, der in der Liste der Ereignisauslöser des Invokers aufgeführt wird.
In der Liste der Ereignisauslöser wird für jedes Ereignis angezeigt, ob es Bedingungen enthält oder nicht. Die Schaltfläche „Bearbeiten“ neben der Bedingungseigenschaft ermöglicht das Hinzufügen oder Bearbeiten der aktuellen Bedingungen des Ereignisses.
Um einen Ereignisauslöser zu löschen, suchen Sie einfach den zu löschenden Ereignisauslöser in der Liste der Ereignisauslöser und klicken auf das Papierkorbsymbol am Ende der Zeile. Daraufhin wird ein Dialogfeld geöffnet, in dem Sie gefragt werden, ob Sie den Ereignisauslöser wirklich löschen möchten. Klicken Sie auf die Schaltfläche Löschen, um den Ereignisauslöser aus der Liste zu entfernen, oder klicken Sie auf die Schaltfläche Abbrechen, um den Dialog zu schließen.
Manchmal kann die Definition eines Ereignisses zur Auslösung eines Invokers zu vielen unnötigen oder falschen Anfragen an einen entfernten Server führen. Es können Ereignisbedingungen festgelegt werden, um die Auslösung des Invokers in solchen Fällen einzuschränken.
Um auf die Ansicht der Ereigniseinstellungen zuzugreifen, in der die Bedingungen definiert werden können, müssen Sie sich in der Invoker-Ansicht befinden und von dort aus auf das Bearbeitungssymbol neben dem Bedingungsstatus des Ereignisses klicken, in dem diese Bedingung wirksam werden soll.
In der Ansicht „Ereigniseinstellungen“ in der Aktionsleiste gibt es eine Schaltfläche, mit der Sie zur Ansicht „Invoker“ zurückkehren können, sowie eine Schaltfläche zum Entfernen aller Ereignisbedingungen. In der Standardeinstellung ist die Ansicht mit der ersten Bedingung vorbelegt. Aktualisieren Sie die Art der Verknüpfung zwischen Bedingungen, wenn mehr als eine Bedingung geplant ist, und ändern Sie die Art der Verknüpfung von Bedingung 1, wenn mehr als ein Feld geplant ist. Beide Verknüpfungsfelder akzeptieren und, oder oder xor als Werte.
Füllen Sie den Feldnamen aus, legen Sie den Übereinstimmungstyp fest (String für exakte Übereinstimmung, Regexp für reguläre Ausdrücke oder Validation Module) und legen Sie den Wert fest, der übereinstimmen soll (im Falle eines Validierungsmoduls den vollständigen Klassennamen wie Kernel::GenericInterface::Event::Validation::ValidateDemo).
Um der Bedingung weitere Felder hinzuzufügen, klicken Sie auf die „Plus“-Schaltfläche in der Kopfzeile der Felder. Um ein Feld zu entfernen, klicken Sie auf die „Minus“-Schaltfläche in der Feldzeile. Es ist notwendig, mindestens ein Feld pro Bedingung beizubehalten.
Um weitere Bedingungen hinzuzufügen, klicken Sie auf die Schaltfläche unter dem letzten Bedingungsfeld. Um eine Bedingung zu entfernen, klicken Sie auf das Minuszeichen in der Kopfzeile der Bedingung. Es ist notwendig, mindestens eine Bedingung im Satz zu behalten. Um alle Bedingungen zu entfernen, klicken Sie auf die Schaltfläche in der Seitenleiste.
OTRS als Requester – HTTP::REST
Wenn mindestens zwei Invoker hinzugefügt werden, wird die Ansicht des Requester-Transports für HTTP::REST um zwei Felder erweitert.
- Controller-Mapping für Invoker ‚<InvokerName>‘ *
-
In dieser Einstellung wird ein Ressourcenpfad festgelegt. Dieser Pfad muss entsprechend den Erfordernissen des entfernten Web Service und nach dessen Definition festgelegt werden.
Der Pfad kann Variablen in der Form
:<Variablenname>enthalten. Jeder Variablenname, der mit den aktuellen (zu sendenden) Daten übereinstimmt, wird durch den entsprechenden Datenwert ersetzt. Diese übereinstimmenden Variablennamen und -werte werden aus den aktuellen Daten entfernt. Je nach HTTP-Anforderungsbefehl können die verbleibenden Daten als JSON-String im Anforderungskörper oder als Abfrageparameter innerhalb des URI gesendet werden.Beispiele für Daten Var1 = Eins, Var2 = Zwei, Var3 = Drei und Var4 = Vier.
-
Controller-Zuordnung:
/Ressource, nach Ersetzungen:/Resource, verbleibende Daten: Var1 = Eins, Var2 = Zwei, Var3 = Drei und Var4 = Vier -
Controller-Zuordnung:
/Ressource/:Var1, nach Ersetzungen:/Resource/Eins, verbleibende Daten: Var2 = Zwei, Var3 = Drei und Var4 = Vier -
Controller-Zuordnung:
/Resource/:Var1?Param1=:Var2&Var3=:Var3, nach Ersetzungen:/Resource/One?Param1=Two&Var3=Three, verbleibende Daten: Var4 = Vier
-
- Gültiger Anfragebefehl für Invoker ‚<InvokerName>‘
-
Hiermit wird die zu verwendende HTTP-Anforderungsmethode festgelegt. Mögliche Optionen: CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT und TRACE. Wenn kein Befehl ausgewählt wird, wird Standardbefehl verwendet.
