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:
Der Kalender und die Karte sind zwar auch Perspektiven, gehören aber natürlich nicht dazu, weil es technische Objekte sind (Darstellungshilfen), keine fachlichen. Einzelne Objekt zu bearbeiten wäre aber sehr mühsam, da man jedes kleine Objekt separat suchen, laden und bearbeiten müsste. Also z.B. erst den Namen des Events, dann die Modulliste, dann für jedes Modul separat die Mitarbeiter usw.
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.
Zum Beispiel gibt es das fachliche Basisobjekt Event. Nun möchte man beim Anlegen und Bearbeiten von Events aber nicht nur das Event selber, sondern alle mit ihm in Beziehung stehenden Informationen sofort sehen und editieren können. Deshalb ist das Event die umschließende Entität eines Containerobjektes, der zu diesem Event alle weiteren Informationen hinzufügt, z.B. die Module des Event, die Teilnehmer, die Teilnehmergruppen usw. Und natürlich sollen innerhalb dieser zugeordneten Objekte auch wieder alle Eigenschaften und dort zugehörigen Objekte bearbeitet werden können. Also z.B. für alle Module des Events sollen die dort eingesetzten Mitarbeiter bearbeitet und eingesehen werden können usw.
Das Ergebnis ist also ein fettes Objekt, dessen Wurzel der Event ist, der aber alle Informationen zu diesem Event zur Verfügung stellt und zur Bearbeitung anbietet. Das ist ein Event-Container.
Das gleiche gilt aber auch für alle anderen fachlichen Basisobjekte. 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.
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:
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:
- 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.
- 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).
- 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