Zur Kommunikation zwischen verschiedenen 1stAnswer Systemen und/oder Mandanten bietet 1stAnswer eine System Schnittstelle an.
Dies ermöglicht es direkt aus dem akutellen System/Mandanten heraus einen neuen Incident im entfernten System/Mandanten zu erstellen.
Zusätzlich können noch dem Incident zugehörige Kommentare, Lösungen, Dateianhänge an den Incident im entfernten System/Mandanten übertragen werden.

Die Übertragung von Kommentaren, Lösungen, Dateianhängen und Aktualisierungen der Verknüpfung erfolgt im Hintergrund, durch den FirstAnswer.Scheduler Dienst “1stAnswer Transaction Queue Service”. Dieser sendet die Elemente an einen Webservice im Ziel-System.

<note tip> Diese Funktion steht Ihnen ab Version 4.2 zur Verfügung. </note>

<note tip> Die Version des Quell- und Zielsystems muss übereinstimmen! </note>

Die Konfiguration der System Schnittstelle erfolgt in der Datenbank, siehe: Konfiguration Remote-System
Es müssen jeweils beide Seiten konfiguriert werden, das Quellsystem/Mandant und das Zielsystem/Mandant.
Die URL des jeweils entfernten Systems muß vom lokalen System erreichbar sein, damit die Übertragung an den jeweiligen Webservice erfolgen kann.

<note> Achtung: 1stAnswer hält diese Einstellungen 15 Minuten lang im Zwischenspeicher.
Nachdem die Einstellungen in der Tabelle tbRemoteSystemConnection geändert wurde muss 15 Minuten gewartet werden - erst dann werden die neuen Einstellungen in 1stAnswer übernommen. </note>

1. Quellsystem vorbereiten
   1. Eine Rolle anlegen mit der man nur lesenden Zugriff auf Incidents hat Rechte für Rolle um Remoteanfragen anzuzeigen
   2. Benutzer anlegen und diesem die Rolle aus erstens zuweisen
   3. ID des Benutzers ermitteln (siehe Datenbank)
2. Eintrag in die tbRemoteSystemConnection Tabelle des Quellsystems
   • tbRemoteSystemConntection_ID = wird automatisch befüllt
   • connectionName = Eindeutiger Name für das Quellsystem
   • connectionType = 2 (1 = ZielSystem, 2 = Quellsystem, 3 = Beides)
   • connectionAccessKey = frei definierbarer Key, der identisch sein muß mit dem Key aus Zielsystem
   • remoteSystemPrefix = Prefix für Benutzer, die von der System-Schnittstelle für den Zugriff auf das Quell-System angelegt werden
   • remoteSystemAddress = URL zum 1stAnswer Webroot des Zielsystems (z.b. http://support.samhammer.de/1stAnswer)
   • remoteSystemConnectionName = Der connectionName des Zielsystems
   • remoteSystemDisplayName = Angezeigter Name für das Zielsystem
   • tbMandator_ID = Mandant, in dem die Verbindung zum Ziel-System sichtbar ist
   • tbRole_ID = NULL
   • tbSupportTeam_ID = NULL
   • tbUser_ID = ID des Benutzer für lesenden Zugriff (siehe Quellsystem vorbereiten)
   • isEnabled = 1 (0 = deaktiviert, 1 = aktiviert)
   • enableOnlyOnceActivation = 0 (0 = deaktiviert, 1 = aktiviert)
3. Zielsystem vorbereiten
   1. Eine Rolle anlegen mit der man nur lesenden Zugriff auf Incidents hat (siehe Rechte für Rolle um Remoteanfragen anzuzeigen)
   2. Eine Rolle im Ziel-Mandanten anlegen mit der man Incidents anlegen bzw. bearbeiten darf (siehe Rechte für Rolle um Remoteanfragen anzulegen)
   3. Benutzer anlegen
   4. Ein SupportTeam anlegen
   5. Dem SupportTeam eine oder mehrere Kategorien zuweisen, in der später Remoteanfragen erstellt werden dürfen
4. Eintrag in die tbRemoteSystemConnection Tabell des Zielsystems
   • tbRemoteSystemConntection_ID = wird automatisch befüllt
   • connectionName = Eindeutiger Name für das Zielsystem
   • connectionType = 1 (1 = ZielSystem, 2 = Quellsystem, 3 = Beides)
   • connectionAccessKey = frei definierbarer Key, der identisch sein muß mit dem Key aus Quellystem
   • remoteSystemPrefix = Prefix für Benutzer, die von der System-Schnittstelle für für den Zugriff auf das Ziel-System angelegt werden
   • remoteSystemAddress = URL zum 1stAnswer Webroot des Zielsystems (z.b. http://bizteam.samhammer.de/1stAnswer)
   • remoteSystemConnectionName = Der connectionName des Quellsystems
   • remoteSystemDisplayName = Angezeigter Name für das Quellsystem
   • tbMandator_ID = Mandant, in dem die Verbindung zum Ziel-System sichtbar ist und genutzt werden kann evtl. unnötig bei Zielsystem
   • tbRole_ID = Rolle für Zielsystem Zugriffe (siehe Zielsystem vorbereiten)
   • tbSupportTeam_ID = SupportTeam für Zielsystem Zugriffe (siehe Zielsystem vorbereiten)
   • tbUser_ID = Benutzer für lesende Zielsystem Zugriffe (siehe Zielsystem vorbereiten)
   • isEnabled = 1 (0 = deaktiviert, 1 = aktiviert)
   • enableOnlyOnceActivation = 0 (0 = deaktiviert, 1 = aktiviert)

Beispiel für die Tabelle tbRemoteSystemConntection:

Quellsystem:

Zielsystem:

Sollen beide Systeme sowohl Quelle als Zielsystem sein, muss für beide Systeme die Schritte: “Zielsystem vorbereiten” und “Eintrag in die tbRemoteSystemConnection Tabell des Zielsystems” ausgeführt werden. Der ConnectionType ist muss auf beiden Systemen 3 sein.

Soll eine Verbindung zwischen zwei Mandanten des selben Systems hergestellt werden, gibt es spezielle Voraussetzungen.
Ein Benutzer kann sich innerhalb eines Browsers nicht mehrfach in das selbe 1stAnswer System einloggen.
Dies läßt sich umgehen, indem man über eine andere Domain auf das selbe 1stAnswer System zugreift, dann kann man sich parallel einloggen.

Für die System-Schnittstelle sollten also außer der Standard-Domain (z.b. http://support.samhammer.de/1stAnswer),
für die Verbindung auf beiden Seiten eine zusätzliche Domain/Subdomain angelegt werden
und als remoteSystemAddress in der tbRemoteSystemConnection hinterlegt werden.
(z.b. Quellsystem http://sagremote.samhammer.de/1stAnswer und Zielsystem http://bizremote.samhammer.de/1stAnswer)

Beispiel für die Tabelle tbRemoteSystemConntection:

Quellsystem:

Zielsystem:

Soll eine Verbindung zwischen zwei 1stAnswer-Systemen - die aber auf der gleichen Domain erreichbar sind (z.B. das erste System ist unter “http://1stAnswer.de/Eins” und das zweite System unter “http://1stAnswer.de/Zwei” erreichbar) - hergestellt werden, muss beachtet werden, dass beide Systeme einen unterschiedlichen Cookie-Namen benutzen.
Dies wird erreicht, dass in der web.config folgender Eintrag verändert wird:

 <forms name=".ASPXAUTH" loginUrl="Login.aspx" timeout="480" />

In diesem Fall ist der Cookie-Name “.ASPXAUTH”, welcher auf beiden Systemen abgeändert werden sollte.

Hinweis: wurde der Cookie-Name nicht geändert, stößt man auf folgendes Problem: wenn man sich an System “A” anmeldet, dann an System “B” anmeldet ist man auf System “A” nicht mehr angemeldet (man muss sich erneut anmelden). Bei der Remote System Schnittstelle hat man das Problem, wenn man einen Incident von System “A” nach System “B” schickt, ist man nach dem Vorgang auf System “A” nicht mehr angemeldet.

1. Der Benutzer auf dem entfernten System konnte nicht authentifiziert werden. Bitte wenden Sie sich an Ihren Systemadministrator.
   • Prüfen ob der Loginname + konfiguriertes Prefix auf dem Zielsystem schon vergeben sind
   • Prüfen ob für die Email des Benutzers auf dem Zielsystem mehr als ein Ergebnis gefunden wird
   • Prüfen ob für die Email des Benutzers auf dem Zielsystem ein Benutzer vom Typ “Kunde” existiert. Falls ja muß die konfigurierte Remote-Rolle am Zielsystem das Flag “für Kunden erlaubt” aktiviert haben.
2. Der Zugriffsschüssel der Verbindung ist ungültig. Bitte wenden Sie sich an Ihren Systemadministrator.
   • Prüfen ob der “connectionAccessKey ” in der Verbindung des lokalen Systems übereinstimmt mit dem “connectionAccessKey ” der Verindung im entfernten System
3. Die Verbindung wurde nicht gefunden. Bitte wenden Sie sich an Ihren Systemadministrator.
   • Prüfen ob der “remoteSystemConnectionName” in der Verbindung des lokalen Systems übereinstimmt mit dem “connectionName” der Verindung im entfernten System
   • Prüfen ob der die Verbindung im entfernten System nicht deaktiviert wurde “isEnabled”
4. Die Versionen des lokalen Services und des entfernten Services sind nicht kompatibel. Bitte wenden Sie sich an Ihren Systemadministrator.
   • Bedeutet, daß die Schnittstellen nicht mehr kompatibel sind. Hier ist ein Update des 1stAnswer Systems nötig.
5. Der gewählte Incident existiert nicht. Bitte wenden Sie sich an Ihren Systemadministrator.
6. Der Benutzer auf dem entfernten System konnte nicht gefunden werden. Bitte wenden Sie sich an Ihren Systemadministrator.
   • Bedeutet, daß diese Daten auf dem Ziel-System nicht gefunden wurden. Ursache kann ein Programmfehler sein oder die Daten wurdem im Ziel-System gelöscht.
7. Ungültige Parameter übergeben. Bitte wenden Sie sich an Ihren Systemadministrator.
   • Bedeutet, daß das lokale System ungültige Werte an das entfernte System geliefert hat. Ursache kann ein Programmfehler sein oder die Daten im Quell-System sind korrupt.
8. Das Ziel-System hat ein ungültiges Ergebnis zurückgeliefert. Bitte wenden Sie sich an Ihren Systemadministrator.
   • Bedeutet, es ist ein Fehler auf dem Remote System aufgetreten. Ursache kann ein Programmfehler sein oder die Daten im Ziel-System sind korrupt.

Für die Übertragungen zwischen den System-Schnittstellen muß der Dienst “1stAnswer Transaction Queue Service” vom 1stAnswer Scheduler eingerichtet sein.

Folgende Optionen können im Block <transactionQueueService> konfiguriert werden:

Begriffe:

Das System, an dem der User ursprünglich angemeldet ist, wird im Folgenden lokales System genannt, der Begriff Fremdsystem bezeichnet das Remote-System, auf dem über die Schnittstelle Remote-Incidents erstellt und verwaltet werden.

Um die Remote-Schnittstelle für einen User zu aktivieren, müssen der Rolle dieses Users im lokalen System folgende Rechte zugeordnet sein:

1. Der Benutzer muss im lokalen System die allgemeinen Remoterechte besitzen
2. Beim Aufruf eines Remote-Incidents ist jeder Anwender automatisch mit einem Standard-Benutzer aktiv, der in der tbRemoteSystemConnection des Fremdsystems konfiguriert ist.
3. → Es muss sichergestellt sein, dass dem Standard-Benutzer auf dem Fremdsystem irgendeine Rolle mit folgenden Rechten zugewiesen ist:
   

1. Der Benutzer muss im lokalen System die allgemeinen Remoterechte besitzen
2. Klickt man auf “Remote Incident erstellen” wird auf dem Fremdsystem ein zugehöriger eigener User geladen, und zwar:
   • Ist auf dem Fremdsystem ein User mit derselben Email-Adresse vorhanden, wird dieser geladen
   • Ansonsten wird ein neuer User erstellt (mehr zum Thema in der Doku)
3. Ihm werden die Remote-Rolle und das Remote-Supportteam zugewiesen, welche in der tbRemoteSystemConnection des Fremdsystems konfiguriert sind.
4. Auf dem Fremdsystem sind also folgende Einstellungen nötig:
   • Das Remote-Supportteam muss den gewünschten Kategorien zugeordnet sein
   • Der Remote-Rolle müssen die Rechte zugewiesen sein: