Mattermost-Verbindung: Methode und funktionaler Hintergrund

Die Mattermost-Verbindung spiegelt Support-Webchat-Gespräche in einen Mattermost-Kanal, sodass das Team das Gespräch aus seinem eigenen Team-Messenger heraus verfolgen und beantworten kann. Darüber hinaus kann i-Reserve Benachrichtigungen (wie Buchungsbestätigungen oder Statusänderungen) an bestimmte Kanäle senden. Die Verbindung kommuniziert mit der Mattermost REST API v4.

Status: Beta. Die ausgehende Richtung (i-Reserve → Mattermost) funktioniert; die eingehende Richtung (Antworten aus Mattermost zurück in das Gespräch) ist Phase 2.

Authentifizierung

Die Verbindung verwendet ein Bot-Konto mit einem Personal Access Token. Ein gewöhnlicher “incoming webhook” genügt nicht, da dieser keine Nachrichten in einem Thread platzieren kann — und Threading ist erforderlich, um jedes Gespräch sauber unter einer Hauptnachricht zu bündeln. Für die eingehende Richtung (Phase 2) wird zudem ein Outgoing-Webhook-Token verwendet, um eingehende Anfragen zu authentifizieren.

Ausgehend (i-Reserve → Mattermost)

• Gespräch gestartet → es wird eine Hauptnachricht (Root-Post) in den eingestellten Kanal platziert, mit Gesprächs-ID, Besuchername und der Seite, auf der das Gespräch begann.
• Neue Nachricht (Besucher oder Agent) → platziert als Threaded Reply unter dieser Hauptnachricht, mit dem Namen des Absenders. Anhänge werden mit hochgeladen und inline angezeigt.
• Benachrichtigung → pro Benachrichtigungstyp können Sie einen Zielkanal verbinden (z. B. Buchungsbestätigung in einen separaten Kanal). Die Nachricht wird einzeln (nicht in einem Thread) platziert.

Die Gespräch↔Thread-Verbindung wird gespeichert, sodass Folgenachrichten im selben Thread landen. Der Versand erfolgt synchron ohne Retry; fällt die Hauptnachricht weg, dann stellt sich die Verbindung wieder her (eine folgende Nachricht erstellt sie erneut).

Eingehend (Mattermost → i-Reserve, Phase 2)

Ein outgoing webhook in Mattermost sendet Antworten im Thread an einen i-Reserve-Endpunkt. i-Reserve:

1. authentifiziert die Anfrage anhand des Outgoing-Webhook-Tokens (das bestimmt auch, welche Lizenz/welcher Eigentümer betroffen ist);
2. sucht den zugehörigen Thread/das zugehörige Gespräch über die Root-Post-ID;
3. ignoriert Nachrichten vom Bot selbst (Schleifen-Prävention);
4. verbindet den Mattermost-Benutzer mit einem i-Reserve-Benutzer (über die E-Mail; gelingt das nicht, wird die Nachricht dennoch mit dem Mattermost-Namen als Autor erfasst);
5. erfasst die Antwort (inkl. Anhänge) im Gespräch.

Einschränkungen

• Der Bot muss Mitglied jedes Kanals sein, in dem er postet; andernfalls folgt ein 403.
• Der Versand erfolgt synchron und wird bei einem Fehler nicht erneut versucht (wird jedoch protokolliert).
• Das Matching eingehender Benutzer erfolgt anhand der exakten E-Mail-Adresse; keine partielle Übereinstimmung.
• Die eingehende Richtung ist Phase 2 (Beta) — verwenden Sie für die Produktion vorerst die ausgehende Spiegelung.