836.857 Aktivitäten: der Abgleich mit onOffice

Der Import ist der langsamste Vorgang des ganzen Werkzeugs. Bei einem Bestand von 15.621 Kontakten mit rund 800.000 Aktivitäten samt E-Mail-Volltexten läuft der erste Abgleich Stunden. Genau in dieser Zeit schaut jemand auf die Seite, lädt sie neu und will wissen, ob überhaupt noch etwas passiert.

Dieser Text handelt von zwei Dingen: davon, wie der Abgleich ans Ende kommt, und davon, was er währenddessen sagen darf.

Die Schleife#

Der Befund aus dem Betrieb: 2.328 abgearbeitete Aktivitäts-Pakete, Cursor trotzdem bei 1.000 von 836.857, und nur 2.237 von 15.659 Kontakten hatten überhaupt eine Aktivität aus onOffice.

Das war keine Störung, sondern eine Schleife. Die Aktivitäts-Phase begann jeden Lauf bei Position null. Das Delta-Fenster, also die Einschränkung auf alles seit dem letzten Mal, greift erst nach einem erfolgreichen Lauf. Bei 836.857 Einträgen zu 200 pro Paket wird so schnell kein Lauf fertig, also gab es nie einen erfolgreichen Lauf, also nie ein Delta-Fenster, also begann jeder Lauf wieder bei null.

Jeder Druck auf „Synchronisieren" hat die Arbeit der vorangegangenen Stunden verworfen. Und weil das Werkzeug dabei nie einen Fehler meldete, sah es aus wie ein Werkzeug, das eben langsam ist.

Die Fortsetzung, und wo sie nicht greifen darf#

Die Lösung ist ein Fortsetzungspunkt, und ein Detail daran ist entscheidend: Ein Voll-Lauf setzt am Maximum der Stände aller früheren Läufe an, nicht am Stand des letzten. Ein Lauf, der bis Position 40.000 kam und dann abbrach, gefolgt von einem, der nach 800 Einträgen starb, würde sonst bei 800 weitermachen.

Bei gesetztem Delta-Fenster wird ausdrücklich nicht fortgesetzt. Dann liefert die Quelle eine andere, kürzere Liste, und ein Fortsetzungspunkt aus dem Voll-Lauf würde die gesamte Delta-Menge überspringen. Diese Ausnahme ist der Teil, den man beim schnellen Hinschauen falsch macht.

Dazu ein Mindestabstand von 20 Stunden zwischen zwei Läufen. Nicht 24, denn dann darf ein Lauf, der gestern um neun startete, heute erst um zehn wieder starten, und übermorgen um elf. Ein Mindestabstand, der jeden Tag später wird, verschiebt sich innerhalb einer Woche aus dem Arbeitstag heraus.

Ein Zugeständnis gehört dazu: Der Fortsetzungspunkt ist eine Position in einer Liste, deren Reihenfolge onOffice bestimmt. Kommen zwischen zwei Läufen Einträge hinzu, verschiebt sich die Liste, und einzelne Einträge können übersprungen werden. Das ist bewusst in Kauf genommen. Das Schreiben ist über die onOffice-Kennung idempotent, ein späterer Delta-Lauf holt Versäumtes nach, und die Alternative, jedes Mal von vorn zu beginnen, hat nachweislich nie ein Ende erreicht.

Zwei Phasen, zwei Wasserzeichen#

Ein Lauf hat zwei Phasen: erst Adressen, dann Aktivitäten. Lange trug der Lauf gar nicht mit sich, in welcher er gerade steckt. Heute ist die Phase eine eigene Spalte mit drei zulässigen Werten. Der naheliegende Weg, sie aus dem Cursor abzuleiten, scheitert an genau der Gesamtzahl, die oft fehlt; der zweite naheliegende Weg, sie aus dem letzten Protokolltext zu lesen, bricht bei der nächsten Umformulierung.

Wichtiger noch ist die Trennung der Wasserzeichen. Das Delta-Fenster hing ursprünglich am Erfolg des Gesamtlaufs. Da die Aktivitäts-Phase über Tage nicht fertig wird, bekam die Adress-Phase nie ein Fenster und begann jedes Mal vollständig von vorn, obwohl sie längst durch war.

Heute trägt jede Phase ihr eigenes Wasserzeichen. Sind alle Adress-Seiten eines Laufs durch, wird das vermerkt, und die nächste Adress-Phase liest nur noch, was sich seither geändert hat. Die Aktivitäten behalten ihr eigenes Fenster. Die Kette trägt per Induktion: Jede abgeschlossene Adress-Phase hat alles seit ihrem eigenen Wasserzeichen gelesen.

Der Fingerabdruck, oder: 15.000 aktualisiert war eine Behauptung#

Der zweite Teil desselben Problems: Das Schreiben legte jede gelesene Adresse blind neu an und zählte sie als aktualisiert, auch wenn sich nichts geändert hatte. Die Zahl „15.000 aktualisiert" war keine Messung, sondern eine Beschreibung dessen, was der Code getan hat.

Heute hält jede Adresse einen Fingerabdruck ihrer zuletzt geschriebenen Daten, gebildet über die Spaltenwerte und den KI-Kontext. Vor dem Schreiben wird die Seite gegen den Bestand verglichen: gleicher Fingerabdruck bedeutet übersprungen. Kein Schreibvorgang, kein Zeitstempel-Sprung.

Die ehrliche Zahl steht danach im Protokoll: „500 gelesen · 3 neu · 12 geändert · 485 unverändert". Diese Zeile ist für ein Büro deutlich wertvoller als „500 aktualisiert", denn sie sagt, ob sich im CRM überhaupt etwas tut.

Ein Nebeneffekt ist gewollt: Ein in der Plattform von Hand geänderter Kontakt wird von einem unveränderten CRM-Datensatz nicht mehr überschrieben. Vorher passierte das bei jedem Lauf. Keine Neuerung in der Quelle, kein Eingriff.

Ohne Gesamtzahl kein Prozentsatz#

Der Fortschrittsbalken war lange eine Erfindung. Die Gesamtzahl wurde nur für den Demo-Modus gesetzt; bei echtem onOffice blieb sie leer, und die Oberfläche rechnete sich einen Wert zurecht: Sobald ein einziger Datensatz durch war, sprang der Balken auf 60 Prozent und blieb dort, über 15.000 Kontakte hinweg.

Heute kommt die Gesamtzahl aus der Quelle, auf einem Weg für alle Lesearten. Wo sie ankommt, gibt es einen echten Prozentsatz. Wo sie nicht ankommt, zeigt die Oberfläche die absolute Zahl, einen Schimmer-Balken ohne Wert und den Satz, dass die Quelle keine Gesamtzahl meldet.

Der Grundsatz dahinter gilt im ganzen Produkt: Ein Balken, der nicht misst, behauptet Wissen. Ein Nutzer, der einmal gemerkt hat, dass eine Anzeige rät, glaubt danach keiner Anzeige mehr, auch nicht den richtigen.

Ein Detail am Rand mit demselben Motiv: Die Gesamtzahl wird nur geschrieben, wenn sie echt ist. Sonst hätte ein späteres Paket ohne Angabe eine bereits gelernte Gesamtzahl gelöscht, und die Anzeige wäre mitten im Lauf von „3.400 von 15.621" auf „unbekannt" zurückgefallen.

Was die Anzeige während des Laufs sagt#

• welche Phase läuft, als Schritt 1 von 2 oder Schritt 2 von 2,
• absolute Zahlen, Prozentsatz nur mit echter Gesamtzahl,
• Laufzeit, Durchsatz je Minute und geschätzte Restzeit der laufenden Phase,
• eine Stillstands-Warnung, wenn das Lebenszeichen länger als fünf Minuten ausbleibt,
• der Hinweis, dass der Abgleich im Hintergrund weiterläuft und die Seite geschlossen werden darf.

Durchsatz und Restzeit erscheinen erst nach einer halben Minute und ab zehn Datensätzen. Eine Hochrechnung aus dem Verbindungsaufbau ergäbe Restzeiten wie „noch 14 Stunden", die eine Minute später „noch 40 Minuten" lauten. Eine Schätzung, die springt, glaubt niemand mehr, auch wenn sie sich später einpendelt.

Der Zustand gehört dem Lauf, nicht dem Browser-Tab#

Zum Schluss ein Fehler, der bei jedem länger laufenden Vorgang lauert. Drei Oberflächen starteten denselben Abgleich, und alle drei merkten sich „läuft gerade" lokal im Browser und verfolgten den Lauf in einer Schleife mit einer Obergrenze.

Daraus folgten zwei Fehlanzeigen. Nach einem Neuladen war der Knopf wieder klickbar, obwohl im Hintergrund noch gearbeitet wurde. Und nach rund einer Viertelstunde gab die Schleife auf und behauptete, es sei nichts mehr los, während der Lauf über Stunden weiterlief.

Heute kommt der Zustand aus dem Lauf. Beim Aufbau der Seite wird er geholt, solange er aktiv ist alle drei Sekunden nachgefragt, und der Knopf spiegelt ihn. Der Server war nie das Problem: Ein Startbefehl gab einen bereits laufenden Lauf zurück, statt einen zweiten zu stapeln. Die Oberfläche hat ihn nur nicht gefragt.