Dieses Feature beinhaltet Erweiterungsmodule für das Generic Interface, die eine Zwei-Wege-Kommunikation und Ticket-Synchronisation zwischen OTRS und SAP Solution Manager (in diesem Dokument ab jetzt SolMan genannt) ermöglicht.
Bemerkung
Der SAP Solution Manager (erreichbar über lokales oder entferntes Netzwerk) ist für diese Funktion erforderlich.
OTRS implementiert Generic Interface-Invoker, -Operationen und -Transporte, die sehr spezifisch für die Interaktion mit einem SolMan-Server sind. Die Module werden durch ihre Registrierung in der Systemkonfiguration deaktiviert, um Verwechslungen oder falsche Verwendung zu vermeiden.
Dies ist die Liste der Einstellungen, die aktiviert werden müssen, wenn Sie sie verwenden möchten.
GenericInterface::Transport::Module###HTTP::SOAPSolMan
GenericInterface::Operation::Module###SolMan::IncidentCreate
GenericInterface::Operation::Module###SolMan::IncidentUpdate
GenericInterface::Operation::Module###SolMan::RequestSystemGuid
GenericInterface::Invoker::Module###SolMan::IncidentCreate
GenericInterface::Invoker::Module###SolMan::IncidentUpdate
GenericInterface::Invoker::Module###SolMan::RequestSystemGuid
Wenn die SAP Solution Manager Connector -Feature als separates Paket installiert wurde, behält das System die Einstellungen während des Versionsupgrades bei.
Bidirektionale Kommunikation
Die Module, die von diesem Feature verwendet werden, ermöglichen die Kommunikation zwischen OTRS und einem SAP Solution Manager System. Es ist jedoch notwendig, zunächst beide Systeme unabhängig voneinander einzurichten, um sicherzustellen, dass beide Systeme korrekt funktionieren, und dann alle notwendigen Schritte im SolMan System auszuführen, um Aktionen über einen Nicht-SAP Web Service anzufordern und bereitzustellen.
Mit diesem Feature (und der notwendigen kundenspezifischen Konfiguration) kann OTRS mit einem bestehenden SolMan kommunizieren, indem es sich als ein anderes SolMan-System ausgibt und dieselben Funktionsnamen, Datenstrukturen und Wertetypen verwendet.
OTRS implementiert nicht die gesamte Palette der SolMan-API. Bitte lesen Sie das Kapitel SolMan Web Services, um zu prüfen, welche in OTRS verfügbar sind.
Vor jedem Versuch, einen OTRS-Webservice mit diesen Modulen zu erstellen, ist es notwendig zu wissen, wie SolMan mit Konzepten wie Prioritäten, Zuständen (SAPUserStatus), Artikeltypen (TextTypes) usw. und den Werten für diese Konzepte in der verwendeten Instanz des SolMan-Systems sowie in OTRS umgeht.
OTRS und das SolMan-System sollten in der Lage sein, über das Netzwerk zu kommunizieren, um SOAP-Nachrichten zwischen ihnen zu senden und zu empfangen. Bitte stellen Sie sicher, dass Sie die notwendigen Ports auf beiden Servern und jedem Netzwerkgerät zwischen ihnen (wie einem Switch oder einer Firewall) öffnen.
Um dieses Feature und die enthaltenen Module nutzen zu können, ist es notwendig, einen Webservice innerhalb von OTRS zu erstellen oder zu ändern. Weitere Informationen finden Sie im Kapitel SolMan Web Services unten.
Automatisches Erstellen von Kundenbenutzern und Agenten in OTRS
Die zwischen OTRS und SolMan ausgetauschten Tickets übertragen auch Ticket-Besitzer und Kundenbenutzer.
Wenn eine eingehende Ticket-Erstellung bzw. -Aktualisierung Daten eines unbekannten Agenten enthält, wird automatisch ein neuer Agent in OTRS angelegt. Das gleiche Verhalten besteht in ähnlicher Weise für Kundenbenutzer.
Mehrere SolMan-Instanzen
Es ist möglich, sich mit mehreren SolMan-Instanzen aus demselben OTRS-System zu verbinden. Verwenden Sie einfach einen Webservice pro Instanz.
Die System-GUID jedes Systems wird separat gespeichert, ebenso der Ticket-Synchronisationsstatus.
SolMan Webservices
Wie oben erwähnt, wird von Grundkenntnissen sowohl der OTRS- als auch der SolMan-Webservices ausgegangen.
Ein Beispiel-Webdienst wird im Ordner development/webservices/SolManConnectorSOAP.yaml bereitgestellt. Es könnte eine gute Idee sein, diesen Webservice als Duplikat auf Ihrem System als Referenz zu installieren (aber deaktivieren).
Notwendige und empfohlene Änderungen für jeden Webservice-Teil siehe Abschnitte unten. Modifikationen beziehen sich auf das mitgelieferte Beispiel.
Requester-Transport
Stellen Sie sicher, dass Sie den Transport HTTP::SOAPSolMan verwenden. Dies ist für die korrekte Namespace-Generierung notwendig.
Stellen Sie den Endpunkt (URI) Ihrer SolMan-Instanz ein und legen Sie ggf. Authentifizierungs-, Proxy- und SSL-Optionen fest.
Die SOAPAction-Optionen, der Namespace und das Namensschema sollten nicht verändert werden.
Requester Invoker
Es gibt drei verschiedene Invoker-Controller, die Funktionen für alle unterstützten Funktionsaufrufe bieten.
-
Der Controller
SolMan::IncidentCreateübernimmt die initiale Übergabe eines Tickets an SolMan (z.B.ProcessIncident,ReplicateIncident). -
Der Controller
SolMan::IncidentUpdatekümmert sich um die Folgeübertragungen eines Tickets an SolMan (z.B.AcceptIncidentProcessing,AddInfo,CloseIncident,RejectIncidentSolution,VerifyIncidentSolution). -
Der Controller
SolMan::RequestSystemGuidwird verwendet, um System-GUID-Informationen von SolMan anzufordern.
Es ist wichtig, zwischen IncidentCreate und IncidentUpdate Controllern zu unterscheiden. Ansonsten machen die Invoker-Namen handhabungstechnisch in OTRS keinen Unterschied (außer CloseIncident, der abbricht, wenn Sie versuchen, ein bereits geschlossenes Ticket zu aktualisieren).
Wenn für ein Ticket ohne vorherige Synchronisierungsaktivität ein Aufruf vom Typ „Update“ ausgelöst wird, wird automatisch ein Aufruf vom Typ „Create“ ausgelöst (ProcessIncident, falls vorhanden oder alternativ ReplicateIncident).
Der Invoker zur Abfrage der SolMan-System-GUID wird automatisch ausgelöst, wenn diese Information im OTRS nicht bekannt ist.
Jeder reguläre Invoker überträgt alle vorhandenen Artikel, die nicht bis zu diesem Punkt übertragen wurden.
Standardmäßig wird der AddInfo-Invoker für jeden in OTRS angelegten Artikel über einen Event-Trigger ausgelöst. Es wird dringend empfohlen, für alle relevanten Invoker Event-Trigger zu konfigurieren (z.B. für Status- und Prioritätsänderungen) und diese über Event-Bedingungen einzuschränken (z.B. auf Tickets in bestimmten Queues).
Requester Mapping
Das Mapping zwischen OTRS und SolMan erfolgt in OTRS über eine XSLT-Konfiguration.
Die mitgelieferte Konfiguration enthält funktionierende XSLT-Vorlagen. Für Standardanforderungen ist es nur notwendig, die Ausgangs-Mapping-Vorlage anzupassen in Bezug auf:
-
OTRS-Dateipfad für XSL-Helper-Templates
-
OTRS → SolMan-Status-Mapping
-
OTRS → SolMan Prioritäts-Mapping
-
Dynamische Feldauswahl und Namenszuordnung
-
OTRS → SolMan-Artikeltyp-Zuordnung
Die Vorlagen müssen individuell pro Invoker angepasst werden, sind aber (standardmäßig) für alle regulären Invoker identisch.
Die von den Invokern bereitgestellte Datenstruktur ähnelt der Struktur des OTRS-Ticket-Connectors, jedoch mit einigen Änderungen und zusätzlichen Daten. Dies ist eine Kurzreferenz:
<Customer>
<*> customer attributes, e.g. 'UserEmail' </*>
</Customer>
<Owner>
<*> owner (agent) attributes, e.g. 'UserEmail' </*>
</Owner>
<SolMan>
<IncidentId> incident id </IncidentId>
<IncidentGuid> incident guid </IncidentGuid>
<LocalSystemGuid> OTRS system guid </LocalSystemGuid>
<RemoteSystemGuid> SolMan system guid </RemoteSystemGuid>
</SolMan>
<Ticket>
<Article> # can occur 0-n times
<Attachment> # can occur 0-n times
<*> attachment attributes, e.g. 'Filename' </*> # 'Content' is base64-encoded automatically
</Attachment>
<DynamicField> # can occur 0-n times
<Name> dynamic field name </Name>
<Value> dynamic field value(s) </Value>
</DynamicField>
<*> article attributes, e.g. 'From' </*>
</Article>
<DynamicField> # can occur 0-n times
<Name> ticket dynamic field name </Name>
<Value> ticket dynamic field value(s) </Value>
</DynamicField>
<*> ticket attributes, e.g. 'TicketNumber' </*>
</Ticket>
Die Standard-XSLT-Vorlagentypen werden als Einzeldateien als Referenz bereitgestellt (siehe Entwicklung/Webservices/SolManConnectorSOAP/ExampleMapping-Invoker- *.xsl).
Requester Error Handling
Einige Fehlerbehandlungsmodule sind vorkonfiguriert und werden verwendet, um Anforderungen neu zu planen, wenn ein bestimmtes Problem auftritt. Umgeplante Anforderungen werden in Intervallen von 1 Minute für bis zu 5 Versuche ausgeführt.
Standardmäßig führen alle Transportfehler zu einer Neuplanung sowie eine Datenaufbereitung, bei der die SolMan-System-GUID nicht abgerufen werden konnte.
Außerdem werden die Anforderungen neu geplant, wenn der SolMan einen Fehlercode zurückgibt, außer wenn dieser Code 01, 02, 03 oder 04 ist.
Es wird empfohlen, die Wiederholungsoptionen an Ihre Bedürfnisse anzupassen und zu prüfen, ob die fehlercodespezifische Behandlung Ihren Anforderungen entspricht.
Provider-Transport
Um Verwechslungen zu vermeiden, sollten Sie den Transport HTTP::SOAPSolMan verwenden. Im Gegensatz zum Requester ist dies nicht unbedingt notwendig.
Ändern Sie die Länge der Nachricht, falls erforderlich.
Die SOAPAction-Optionen, der Namespace und das Namensschema sollten nicht verändert werden.
Provider-Operationen
Es gibt drei verschiedene Betriebssteuerungen, die Funktionalität für alle unterstützten Funktionsaufrufe bieten.
-
Der Controller
SolMan::IncidentCreateübernimmt die initiale Übertragung eines Tickets von SolMan (z.B.ProcessIncident,ReplicateIncident). -
Der Controller
SolMan::IncidentUpdatekümmert sich um die Folgeübertragungen eines Tickets an SolMan (z.B.AcceptIncidentProcessing,AddInfo,CloseIncident,RejectIncidentSolution,VerifyIncidentSolution). -
Der Controller
SolMan::RequestSystemGuidwird verwendet, um System-GUID-Informationen von SolMan anzufordern.
Es ist wichtig, zwischen IncidentCreate und IncidentUpdate Controllern zu unterscheiden. Ansonsten machen die Invoker-Namen handhabungstechnisch in OTRS keinen Unterschied.
Wenn ein Ticket ausstehende Aktualisierungen hat, die von OTRS zum SolMan übertragen werden müssen (z. B. neue Artikel), werden Aktualisierungen aus dem SolMan vorübergehend blockiert.
Aufgrund der Natur des SolMan können die gesendeten Anhänge nicht mehr als einem Artikel zugeordnet werden. Artikel, die innerhalb einer Anfrage gesendet werden, werden automatisch an den letzten Artikel angehängt, der innerhalb dieser Anfrage erstellt wurde. Wenn die Anfrage keinen Artikel enthält, wird ein Dummy-Artikel für die Anhänge angelegt.
Provider Mapping
Das Mapping zwischen OTRS und SolMan erfolgt in OTRS über eine XSLT-Konfiguration.
Die mitgelieferte Konfiguration enthält funktionierende XSLT-Vorlagen. Für Standardanforderungen ist es nur notwendig, die Ausgangs-Mapping-Vorlage anzupassen in Bezug auf:
-
OTRS-Dateipfad für XSL-Helper-Templates
-
OTRS-Ziel-Queue
-
SolMan → OTRS-Status-Mapping
-
SolMan → OTRS Prioritäts-Mapping
-
Dynamische Feldauswahl und Namenszuordnung
-
SolMan → OTRS-Artikel-Typen-Mapping
Die Vorlagen müssen pro Operation individuell angepasst werden, sind aber (standardmäßig) für alle regulären Operationen identisch.
Die Datenstruktur, die von den Operationen erwartet wird, ähnelt der Struktur des OTRS-Ticket-Connectors, jedoch mit einigen Änderungen und zusätzlichen Daten. Dies ist eine Kurzreferenz:
<Attachment> # can occur 0-n times
<*> attachment attributes, e.g. 'Filename' </*> # 'Content' is base64-decoded automatically
</Attachment>
<Ticket>
<Article> # can occur 0-n times
<*> article attributes, e.g. 'From' </*>
</Article>
<DynamicField> # can occur 0-n times
<Name> ticket dynamic field name </Name>
<Value> ticket dynamic field value(s) </Value>
</DynamicField>
<*> ticket attributes, e.g. 'TicketNumber' </*>
</Ticket>
<SolMan>
<IncidentGuid> incident guid </IncidentGuid>
<LocalSystemGuid> OTRS system guid </LocalSystemGuid>
<RemoteSystemGuid> SolMan system guid </RemoteSystemGuid>
<Person> # can occur 0-n times
<Meta>
<ID> OTRS id of agent / or login of customer user </ID>
<ExternalID> SolMan id of person </ExternalID>
<Type> CustomerUser, Owner or Agent </Type>
</Meta>
<*> agent or customer user attributes, e.g. 'UserEmail' </*>
</Person>
</SolMan>
Die Standard-XSLT-Vorlagentypen werden als Einzeldateien als Referenz bereitgestellt (siehe Entwicklung/Webservices/SolManConnectorSOAP/ExampleMapping-Operation- *.xsl).
