Sie arbeiten sicher mit einem abgeschlossenen Clustering, das mehrere Bearbeiter gleichzeitig geöffnet haben. Die Ergebnisansicht aktualisiert nach Änderungen die gespeicherten Baum- und Teiledaten, sodass kein Bearbeiter mit einem veralteten Stand weiterarbeitet.
Für diesen Ablauf brauchen Sie zwei unabhängige, angemeldete Sitzungen mit clustering-view und clustering-edit. Verwenden Sie ein abgeschlossenes Clustering mit einem befüllten und einem leeren Blatt-Cluster, das entfernt werden darf. Die Änderungen betreffen gespeicherte Daten; verwenden Sie für Untersuchungen oder Schulungen Daten, die verloren gehen dürfen.
Eine unabhängige Sitzung ist ein separat angemeldetes Browserprofil oder ein eigener Browserkontext. Zwei Tabs derselben Browsersitzung sind keine unabhängigen Bearbeiter.
Gleichzeitiges Bearbeiten – Bedienelemente, Bedeutung und Entscheidungen im Betrieb
Lassen Sie dasselbe abgeschlossene Clustering in beiden Bearbeitersitzungen geöffnet, wenn Sie eine Änderung abstimmen. Eine Änderung des Teilestatus wird über die Anfrage des jeweiligen Bearbeiters gespeichert; danach werden Baum, gewählte Teile und Kennzahlen neu geladen. Nimmt der Server konkurrierende Änderungen nacheinander an, zeigen beide Sitzungen nach ihrer nächsten Aktualisierung den zuletzt gespeicherten Status.
Der Server kann eine Änderung ablehnen, weil sich die zugrunde liegenden Daten geändert haben. Dann stellt die Ergebnisansicht den aktuellen Serverstand wieder her, bevor sie den Aktionsfehler anzeigt. Teilekarten, Baum, „Overview“ und Graph beschreiben danach dieselbe gespeicherte Revision, statt veraltete Summen zu zeigen.
Änderungen am Baum folgen demselben Prinzip. Das Entfernen eines leeren Clusters aktualisiert die Hierarchie und die aktuellen Ergebnisdaten. Eine Sitzung, in der der entfernte Knoten noch gewählt war, muss neu laden, bevor sie weiterarbeitet; die Anwendung bleibt in einem vorhandenen Baumkontext bedienbar, statt den entfernten Knoten als gültig zu behandeln.
Die Arbeitsfläche liest die Hierarchie und die aktuellen Cluster-Daten als eine zusammengehörige Ergebnisrevision. Verweisen die Antworten vorübergehend auf verschiedene Revisionen, weil ein anderer Bearbeiter das Clustering ändert, wiederholt die Anwendung das gemeinsame Laden einige Male. Eine neuere Anfrage ersetzt eine ältere ausstehende, damit keine veraltete Antwort eine neuere Auswahl überschreibt.
Lässt sich kein konsistentes Ergebnis laden, zeigt die Seite die Fehlermeldung zur Konsistenz mit der Aktion „Reload“. „Reload“ fordert den aktuell gewählten Kontext erneut an. Auch Übertragungsfehler erscheinen an dieser Stelle; sie werden nicht wie abweichende Revisionen automatisch wiederholt.
Bei einer veralteten Revision eines Vorschaubilds fordert der Hierarchiegraph dieselbe Aktualisierung des Ergebnisses an. Lesen Sie den Graph erst, nachdem Baum und Ergebnisdaten aktualisiert sind.
Nach einer abgeschlossenen Aktualisierung arbeiten beide Bearbeiter mit dem gespeicherten Clustering-Stand. Ein abgelehnter, ersetzter oder veralteter Vorgang hinterlässt keine fehlerhafte Ansicht: Die Arbeitsfläche zeigt bei Bedarf den Fehler und bietet eine Aktion zum Neuladen; Baum, Ergebniskarten, „Overview“ und Graph kehren zu einem konsistenten aktuellen Stand zurück.
Nehmen Sie keine Zugangsdaten in Dokumentation, Quelldateien, Logs oder Supportanfragen auf.
Verhält sich ein gleichzeitiger Vorgang unerwartet, notieren Sie das betroffene Clustering, die beiden zuletzt beobachteten Zustände und den angezeigten Fehlertext.
Dieser Ablauf wurde anhand des Quellcodes geprüft und ist nur als Text beschrieben. Er wurde nicht in einem Durchlauf im Browser überprüft und enthält bewusst keine Screenshots.