Wenn eine Anfrage im Chat nicht ankommt: Zustände, Protokoll und keine Doppelten

Vor der Black Week stehen nicht nur Shop und Kasse unter Last, sondern auch die Systeme dahinter: Kundenverwaltung, Ticketsystem, Warenwirtschaft. Ein Chat-Assistent, der in diese Systeme schreibt, legt dort Tickets, Interessenten oder Rückrufwünsche an, und genau an dieser Stelle wird eine langsame Schnittstelle heikel. Fehlt beim Lesen eine Angabe, bleibt eine Antwort unvollständig. Scheitert dagegen ein Schreibvorgang, ist offen, ob etwas angelegt wurde, und der Besucher klickt im Zweifel ein zweites Mal. Dieser Beitrag zeigt, welche Zustände ein schreibender Aufruf bei XICBOT annehmen kann, was der Besucher in jedem Fall liest, warum nach der Frist Schluss ist und nichts nachgeholt wird, wie ein Einmalschlüssel doppelte Einträge verhindern hilft und was im Protokoll steht.

Grafik vergrößern

Beschriftungen der Abbildung

• Freigabe im Chat
• Endzustand
• Was der Assistent sagt (Beispiel)
• vorgeschlagen
• wartet auf Klick
• bestätigt
• Bestätigen
• Ablehnen
• zu lange offen
• ausgeführt
• Ihre Anfrage ist angelegt.
• fehlgeschlagen
• Das hat gerade nicht geklappt.
• Frist überschritten
• Keine Antwort, ich nenne kein Ergebnis.
• abgelehnt
• In Ordnung, es wird nichts angelegt.
• abgelaufen
• Der Vorschlag gilt nicht mehr.
• Einmalschlüssel
• Zweiter Klick legt nichts doppelt an
• Gebildet aus Gespräch, Werkzeug, Eingabe
• Der Riegel liegt in der Datenbank
• Protokoll: eine Zeile je Aufruf
• 14:02:27
• ticket_create
• Frist überschritten
• nur Fehlertext
• 14:05:03
• crm_lead
• ausgeführt
• Ergebnis zurück
• 14:07:40
• callback_note
• abgelehnt
• nichts ausgeführt

Sieben Zustände einer schreibenden Aktion im Chat

Vor der Black Week: wenn die schreibende Seite hakt

In den Wochen vor der Black Week steigt die Last nicht gleichmäßig. Spitzen treffen häufig gerade die Systeme, die im Tagesgeschäft unauffällig laufen: das Ticketsystem, in dem Rückfragen zu Bestellungen landen, die Kundenverwaltung, in die Interessenten eingetragen werden, und die Warenwirtschaft, die Bestände und Aufträge führt. Ein Assistent, der über die Tool-Steuerung an diese Systeme angebunden ist, bekommt das unmittelbar zu spüren, denn er fragt in dem Moment an, in dem der Besucher im Chatfenster wartet. Antwortet ein System langsamer als sonst, ist das für eine Auskunft ärgerlich. Für einen Vorgang, der etwas anlegen soll, wird es zu einer offenen Frage.

Ob gelesen oder geschrieben wird, entscheidet darüber, wie schwer ein Ausfall wiegt. Bleibt eine lesende Abfrage aus, fehlt eine Angabe, etwa ein Lagerbestand, und der Assistent antwortet ohne sie. Wie er dabei gestuft zurückfällt, beschreibt der Beitrag zu Ausfall und Notbetrieb. Bei einem schreibenden Vorgang drohen drei andere Schäden: Der Chat meldet einen Eingang, den es nicht gibt. Der Besucher klickt ein zweites Mal, und das Ticket liegt doppelt vor. Oder niemand kann hinterher sagen, was aus der Anfrage geworden ist. Um diese drei Fälle geht es hier.

Sieben Zustände statt erledigt oder nicht erledigt

Ein schreibender Aufruf führt bei XICBOT zunächst nichts aus. Er geht als Vorschlag an den Besucher, mit dem Satz, der die Tat benennt, den echten Werten und zwei Knöpfen darunter. Erst der Klick auf Bestätigen bringt ihn weiter. Von da an endet er in einem von mehreren benannten Zuständen, und jeder davon beantwortet die Frage, ob in Ihrem System etwas entstanden ist, auf seine Weise. Die Seite zu den individuellen Funktionen führt sieben Zustände auf: vorgeschlagen, bestätigt, ausgeführt, abgelehnt, abgelaufen, fehlgeschlagen und Frist überschritten.

Entscheidend sind die beiden letzten Zeilen. Fehlgeschlagen und Frist überschritten sehen für den Besucher ähnlich aus, für Ihr Team bedeuten sie Verschiedenes. Ein Fehlschlag heißt in der Regel: Das Ziel hat geantwortet, aber nicht mit Erfolg, oder es war gar nicht erreichbar. Meist ist dann nichts angelegt. Kommt die Fehlerantwort aber von einem vorgeschalteten Server oder reißt die Verbindung nach dem Absenden ab, kann der Vorgang dahinter trotzdem angekommen sein. Eine überschrittene Frist heißt dagegen, dass gar keine Antwort kam. Ob das Ticket drüben trotzdem entstanden ist, weiß in diesem Moment niemand im Chat. Deshalb trennt das Protokoll beide Ausgänge und hält den Fehlertext fest, und deshalb trägt der Aufruf einen Einmalschlüssel, auf den wir weiter unten eingehen.

Was der Besucher im Chat liest

Der Besucher sieht den Zustand des Aufrufs in derselben Karte, in der vorher der Vorschlag stand. Er muss also nicht aus dem Ton einer Antwort herauslesen, ob sein Anliegen angekommen ist. Den technischen Fehlertext bekommt er dabei nicht zu sehen: An dessen Stelle steht ein allgemeiner Satz, der Fehlertext selbst bleibt in der Verwaltung. Dafür gibt es zwei gute Gründe. Ein Fehlertext aus einem fremden System hilft dem Besucher nicht weiter, und er kann Einzelheiten über Ihre Anbindung verraten, die im öffentlichen Chat nichts zu suchen haben.

Wie das im Gespräch klingt, zeigt ein Beispiel auf der Seite zu den individuellen Funktionen. Ein Besucher fragt nach seiner Bestellung, bestätigt den Abruf, und die Warenwirtschaft antwortet nicht innerhalb der Frist. Der Assistent sagt dann sinngemäß, dass er keinen Status hat und deshalb keinen nennt, dass er es von allein nicht noch einmal versucht, und fragt, ob er das Anliegen weitergeben soll. Für schreibende Vorgänge gilt dasselbe Muster. Eine gute Meldung in diesem Moment enthält in der Regel diese Bestandteile:

• Was nicht geklappt hat, in einem Satz und ohne Fachbegriff, etwa: „Das Ticket konnte gerade nicht angelegt werden.“
• Keine Eingangsbestätigung, weder nach einem Fehlschlag noch nach einer überschrittenen Frist, und keine Ersatzangabe wie eine Vorgangsnummer, die nicht vergeben wurde.
• Was jetzt noch möglich ist: die Übergabe an eine Person, ein neuer Anlauf durch den Besucher selbst oder ein anderer Kontaktweg.
• Keine Zusage, wann sich jemand meldet. Wann eine Anfrage bearbeitet wird, entscheidet Ihr Betrieb, nicht der Assistent.
• Die Zusicherung, dass der bisherige Gesprächsverlauf erhalten bleibt, damit der Besucher nichts zweimal erzählen muss.

Die Frist: acht Sekunden, einstellbar je Werkzeug

Ein Aufruf in ein angebundenes System hat bei XICBOT eine feste Frist. In der Voreinstellung sind es acht Sekunden, je Werkzeug lässt sich der Wert zwischen einer und zwanzig Sekunden setzen. Läuft die Frist ab, ist der Aufruf beendet. Er arbeitet nicht im Hintergrund weiter, während das Gespräch schon weiterläuft, und er endet im Zustand Frist überschritten. Jeder andere Fehler endet als fehlgeschlagen. Dazu zählt etwa eine Weiterleitung, denn ein Ziel, das umleitet, gilt als nicht erreichbar.

Warum eine ausbleibende Antwort nichts über den Ausgang aussagt, zeigt schon die HTTP-Spezifikation. Für den Fall, dass ein Vermittler zwischen zwei Systemen keine rechtzeitige Antwort bekommt, kennt sie einen eigenen Statuscode, die 504. Steht ein solcher Vermittler vor Ihrem System, kommt seine 504 bei XICBOT als fehlgeschlagen an und nicht als Frist überschritten, denn geantwortet hat ja jemand. Der Ausgang ist dann genauso offen. Die Definition spricht nur von der fehlenden Antwort und sagt nichts darüber, ob der Vorgang dahinter ausgeführt wurde:

Wer den Beitrag zum Notbetrieb kennt, findet dort für lesende Abfragen ein knapperes Zeitbudget je Fremdsystem empfohlen. Das ist eine Planungsempfehlung für Auskünfte und keine Produktangabe, und sie steht nicht im Widerspruch zur Voreinstellung, denn die Frist ist je Werkzeug einstellbar. Bei schreibenden Vorgängen spricht einiges dafür, nicht zu knapp zu planen. Eine zu kurze Frist macht aus einem langsamen, aber erfolgreichen Anlegen einen Aufruf mit offenem Ausgang. Eine zu lange Frist lässt den Besucher warten, ohne dass er erfährt, warum. Welcher Wert passt, hängt davon ab, wie Ihr System unter Last antwortet, und das lässt sich messen, bevor die Spitze kommt.

Warum nichts nachgeholt wird

Naheliegend wäre, einen gescheiterten Aufruf einfach noch einmal zu schicken. XICBOT tut das nicht: Scheitert ein Aufruf oder überschreitet er die Frist, wird er nicht nachgeholt, weder sofort noch später im Hintergrund. Das Modell sieht den Fehlertext und ist angewiesen zu sagen, dass es nicht geklappt hat, statt ein Ergebnis zu erfinden. Die Zurückhaltung hat einen Grund, den die HTTP-Spezifikation für Anfragen festhält, die nicht idempotent sind:

Ein Ticket anzulegen ist kein idempotenter Vorgang: Zweimal geschickt, entstehen ohne weitere Vorkehrung zwei Tickets. Nach einer überschrittenen Frist weiß der Assistent zudem nicht, ob die erste Anfrage angekommen ist. Ein automatischer zweiter Versuch wäre in dieser Lage ein Ratespiel auf Kosten Ihres Teams. Die Entscheidung bleibt deshalb beim Menschen. Der Besucher kann sein Anliegen erneut vorbringen und bestätigt dann einen neuen Vorschlag, oder er lässt es an eine Person weitergeben. Nach einer überschrittenen Frist ist die Übergabe oft der sicherere Weg: Ein neuer Vorschlag ist häufig anders formuliert, trägt damit einen neuen Einmalschlüssel und kann im Zielsystem einen zweiten Vorgang anlegen. Worauf es bei der Übergabe ankommt, beschreibt der Beitrag zur Übergabe an Mitarbeiter.

Der Einmalschlüssel: zweimal geklickt, einmal angelegt

Doppelte Einträge entstehen selten aus böser Absicht. Ein Besucher tippt zweimal, weil die erste Reaktion auf sich warten lässt, ein zweiter Tab ist offen, oder die Verbindung reißt im falschen Moment ab. Bei XICBOT trägt deshalb jeder schreibende Schritt, der einen Vorgang anlegt oder ändert, einen Einmalschlüssel. Er entsteht aus Gespräch, Werkzeugschlüssel und sortierter Eingabe und wird per sha256 gebildet; dieselbe Anfrage im selben Gespräch ergibt also denselben Schlüssel. Der Riegel gegen den Doppelklick liegt in der Datenbank und nicht in der Oberfläche. Der Wechsel von vorgeschlagen auf bestätigt läuft als bedingtes Schreiben: Zwei gleichzeitige Klicks führen einmal aus, und der zweite wird als Dublette gemeldet, nicht als Fehler. Innerhalb von XICBOT bekommt ein Vorgang, der von Natur aus nicht idempotent ist, damit die Eigenschaft, die die HTTP-Spezifikation so beschreibt:

• Anfrage aufnehmen: Name, E-Mail, Telefon und Anliegen gehen in das Postfach des Betriebs. Wiederholt sich derselbe Aufruf, wird nichts doppelt angelegt.
• Interessent in der Kundenverwaltung (crm_lead): Der Doppelklick ist gesperrt; ob ein wiederholter Aufruf drüben nur einmal wirkt, entscheidet Ihr System anhand des Schlüssels.
• Termin: Zwei Klicks erzeugen keine zwei Anfragen.
• Übergabe an eine Person: Ein Riegel aus Gespräch und Eingabe verhindert die doppelte Meldung.
• Bestellung ändern: Der Schlüssel geht in einer Kopfzeile des Abrufs mit, damit das angebundene System einen wiederholten Aufruf erkennen kann.
• Lesende Aufrufe tragen keinen Einmalschlüssel. Er wird nur dort gebraucht, wo etwas entstehen kann.

Das Protokoll: eine Zeile je Aufruf

Jeder Aufruf hinterlässt eine Zeile, der ausgeführte ebenso wie der abgelehnte und der gescheiterte. Die Zeile wird vor der Ausführung geschrieben und danach fortgeschrieben. Im Protokoll soll nichts stehen, was nicht zurückkam: Scheitert ein Aufruf, wird kein Ergebnis gespeichert, sondern der gekürzte Fehlertext. Der Vorschautext, den der Besucher vor dem Klick gelesen hat, wird beim Anlegen des Vorschlags gespeichert und später nicht neu gebildet. Was im Protokoll steht, ist damit derselbe Wortlaut, den der Besucher bestätigt hat. Eine Zeile hält außerdem Folgendes fest:

• das Werkzeug, also die benannte Aktion, etwa ticket_create oder callback_note
• die Eingabe, nachdem alles beschnitten wurde, was nicht im Feldschema steht
• das Ergebnis, beschränkt auf die Felder, die der Adapter als Ergebnis nennt, und gekürzt
• die Dauer des Aufrufs
• den Freigabeweg, also automatisch oder vom Besucher bestätigt (im Testgespräch und über die Schnittstelle: von der Anwendung bestätigt); eine Ablehnung steht im Zustand
• den Zustand, in dem der Aufruf geendet ist, und bei einem Fehlschlag den gekürzten Fehlertext

Im Chatfenster zeigt das Widget weniger als die Verwaltung: Dauer und Freigabeweg fehlen dort, und den Fehlertext ersetzt ein allgemeiner Satz. Für die Nachbereitung ist deshalb die Verwaltung der Ort. Dort sehen Sie, welche Aufrufe ausgeführt, abgelehnt, gescheitert oder am Deckel hängengeblieben sind. Daraus ergibt sich, welche Frist zu knapp bemessen ist, welches System unter Last nachgibt und welche Aktion als nächste dazukommen sollte. Wie sich solche Aufgaben im Team verteilen lassen, beschreibt der Beitrag zu Rollen und Freigaben im Team.

Vorbereitung vor der Lastspitze

Die meisten Fragen dieses Beitrags lassen sich vor der Black Week klären und nicht erst währenddessen. Bei einer Anbindung über die Tool-Steuerung fahren wir jeden Vorgang vor dem Livegang einmal durch, auch den Fehlweg. Es ist sinnvoll, diesen Durchlauf vor einer erwarteten Spitze zu wiederholen, und zwar mit dem Blick auf die schreibenden Aktionen. Die folgenden Punkte eignen sich als Gerüst:

• Alle schreibenden Aktionen auflisten und je Aktion festhalten, in welches System sie schreibt und wer dort zuständig ist.
• Je Werkzeug die Frist prüfen: Reicht der Wert, wenn das Zielsystem unter Last langsamer antwortet, oder wird aus einem erfolgreichen Anlegen ein Aufruf mit offenem Ausgang?
• Beim Betreuer des Zielsystems nachfragen, ob es den Einmalschlüssel in der Kopfzeile auswertet.
• Den Fehlweg gezielt auslösen, einmal mit einem Ziel, das nicht antwortet, und einmal mit einem Ziel, das einen Fehler meldet. Dabei prüfen, welcher Satz im Chat erscheint und welche Zeile im Protokoll entsteht.
• Den Doppelklick ausprobieren: zweimal bestätigen, in zwei Tabs bestätigen und nachsehen, dass im Zielsystem ein einziger Vorgang liegt.
• Festlegen, wer nach einem lastreichen Tag die Zeilen mit fehlgeschlagen und Frist überschritten durchsieht und wie nachgefasst wird.
• Die Vorschautexte der schreibenden Aktionen lesen: Benennt jeder die Tat so, dass ein Besucher weiß, was sein Klick auslöst?

Passende Testfälle für den Livegang listet der Beitrag zur Abnahme mit Testfällen auf. Vor der Black Week kommt eine zweite Sorte Anfragen dazu, die nichts anlegt, aber viel Zeit kostet: die Frage, ob es bald günstiger wird. Wie ein Assistent damit umgeht, ohne Rabatte zu erfinden, beschreibt der Beitrag zu Fragen nach künftigen Rabatten.

Was der Assistent bewusst nicht tut

• Er führt Schreibendes nicht ohne Bestätigung aus. Schreibende Aktionen werden beim Anlegen und Ändern hart auf Bestätigung gesetzt, auch wenn jemand automatisch wählt.
• Er wiederholt keinen gescheiterten Aufruf und lässt keinen im Hintergrund weiterlaufen.
• Er nennt kein Ergebnis, das nicht zurückkam, und bestätigt keinen Eingang, den es nicht gibt.
• Er sagt nicht zu, wann sich jemand meldet. Das entscheidet Ihr Betrieb.
• Er bewegt kein Geld. Unter den ausgelieferten Anbindungen ist keine, die bezahlt.
• Er führt je Antwort höchstens fünf Aufrufe aus. Der sechste wird als gedeckelt protokolliert, und der Besucher liest dazu einen eigenen Satz.

Diese Grenzen sind Festlegungen und keine offenen Baustellen. Die Tool- und API-Steuerung gehört zum Paket Individuell. Welche Ihrer Systeme eine Schnittstelle bereitstellen, welche Vorgänge schreibend sind und wie die Fristen stehen sollten, klären wir gern im Erstgespräch. Die Seite zur Tool-Steuerung zeigt den Weg vom Vorschlag bis zur Zeile im Protokoll im Einzelnen.

Häufige Fragen