Page History

StattBuchung schließt nicht aus, das verschiedene (berechtigte) Mitarbeiter gleichzeitig die selben Objekte bearbeiten. Dies erhöht die Parallelität und damit die Produktivität in den Büros. In diesem Artikel erkläre ich wie das funktioniert und worauf man dabei achten sollte.

Was sind eigentlich Objekte?

Als Objekte bezeichnen wir alle fachlichen Entitäten, z.B. Events, Produkte, Mitarbeiter, Partner/Orte usw. Im Prinzip sind das all diejenigen Objekte die in den verschiedenen Perspektiven der BuchungsApp zum Bearbeiten angeboten werden:

...

Deswegen ist die Ebene der Bearbeitung in StattBuchung nicht das einzelne Objekt, sondern das Containerobjekt.

Was ist ein Containerobjekt?

In den Perspektiven der BuchungsApp werden die fachlichen Objekte als "Objektbundles" zur Bearbeitung angeboten. So ein Bundle ist ein großes Objekt dass zu einem fachlichen Basisobjekt alle Detailinformationen mitbringt. Intern nenn wir diese Bundles Containerobjekte.

...

Das gleiche gilt aber auch für alle anderen fachlichen Basisobjekte. Nochmals: Jetzt können wir das also so ausdrücken: Die Liste der Perspektiven der BuchungsApp oben gibt einen Überblick darüber welche Containerobjekte es dort gibt.

Schritt-für-Schritt-Anleitung

Das Containerobjekt ist die Ebene, auf der paralleles Bearbeiten ermöglicht wird.

Welchen Regeln gelten bei der gleichzeitigen Bearbeitung?

Kurz gesagt: keine. Es gibt keine Sperrfervahren und auch keine Bevormundung der Nutzer. Schlussendlich muss jeder Nutzer die richtigen Informationen eingeben, und nur er kann entscheiden ob er eine aktuellere Information hat als sein Kollege, der von 2 Minuten die gleiche Information erfasst hat. In einem klassischen System dürfte unser Nutzer die Daten nicht ändern, weil sein Kollege bereits eine Änderung gemacht hat und diese Änderung noch nicht in der Oberfläche unseres Nutzers ersichtlich ist - einfach weil er sein Containerobjekt geladen hat, bevor der Kollege die Änderung gespeichert hat.

Unser Nutzer muss also wissen, dass sein Kollege etwas geändert hat, denn das ist auch für ihn und seine Entscheidung, selber Änderungen vorzunehmen, relevant. Welche Schlüsse er aber aus dieser Information zieht ist ihm überlassen.

Informationen über den Bearbeitungsstand  eines Containerobjektes

Immer wenn ein Nutzer ein Containerobjekt lädt werden alle darin enthaltenen fachlichen Objekte identifiziert und in einer Beobachtungsliste (Watchlist) gespeichert. Diese Watchlist wird  zu bestimmten Zeitpunkten an den Anwendungsserver gesendet und der prüft, ob seit dem Zeitpunkt der Erstellung der Watchlist darin enthaltene Objekte von anderen Nutzern bearbeitet worden sind. Wenn ja, erzeugt der Server eine Kollisionsliste und sendet diese zurück an den Computer des Nutzers. Daraufhin werden alle in der Kollisionsliste enthaltenen Objekte in der Baumdarstellung mit einem Kollisionszeichen (Icon) versehen und im Tooltip des Objektes wird angegeben:

• welcher Nutzer
• wann das Objekt geändert hat
• was vorher drin gestanden ist
• was nach der Änderung drin gestanden ist.

Das sieht dann z.B. so aus:

Image Added

Ausgestattet mit diesen Informationen kann jeder Nutzer entscheiden wie er vorgehen möchte.

Was kann bei gleichzeitiger Bearbeitung passieren?

In dem Beispiel oben ist unter anderem der Zeitraum, in dem das Restaurant#1 gebucht worden ist, von einem anderen Nutzer geändert worden. Solange unser Nutzer diese Information nicht auch bearbeiten möchte, passiert gar nichts. Folgende Szenarien sind möglich:

1. Unser Nutzer hat keinen Anlass die Änderung seines Kollegen in Frage zu stellen. Selbst wenn unser Nutzer auf "alles bearbeiten" klickt, den Zeitraum der Restaurantbuchung aber nicht ändert und dann auf "alles speichern" klickt, werden die Daten dieser Restaurantbuchung auf dem Anwendungsserver nicht aktualisiert und dort verbleibt nach wie vor die Buchungszeit die der andere Nutzer eingegeben hat. In StattBuchung werden immer nur die Teile eines Containerobjektes zum Anwendungsserver gesendet, die auch wirklich bearbeitet worden sind. 
2. Unser Nutzer  hat soeben erst mit dem Wirt des Restaurants telefoniert und die Buchung nochmals geändert. Anhand des Zeitstempels der Änderung durch seinen Kollegen erkennt unser Nutzer, dass der Kollege diese Information noch nicht haben konnte. Also ändert unser Nutzer die Buchungszeit ohne Rücksicht auf die Änderung seines Kollegen die damit überschrieben wird. (Übrigens bekommt jetzt auch der Kollege das Kollisions-Icon).
3. Unser Nutzer möchte die Restaurantbuchung zwar nicht ändern, aber der noch falsch angezeigte Termin mit dem nervigen Kollisions-Icon stört ihn. In dem Fall muss unser Nutzer das Containerobjekt einfach schließen (x im Reiter, Schließen im Kontextmenü des Kalenders oder des Suchergebnisbaumes) und danach erneut öffnen. Da er jezt die aktuelle Version des Containers inklusive der Änderungen seines Kollegen hat ist die Restaurantbuchung nicht mehr als kollidiert markiert.

Verwandte Artikel

...