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 (im Beispiel: Rigor Mortis)
- wann das Objekt geändert hat (im Beispiel: 10:08)
- was vorher drin gestanden ist (im Beispiel: Zeitstempel, rot hinterlegt)
- was nach der Änderung drin gestanden ist. (im Beispiel: Zeitstempel, grün hinterlegt)
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 enfach auf den neuen Aktualisieren-Button klicken Da er jezt die aktuelle Version des Containers inklusive der Änderungen seines Kollegen hat ist die Restaurantbuchung nicht mehr als kollidiert markiert.
Der Aktualisieren-Button
Das Layout des Event-Containers hat sich etwas geändert. Die Toolbar ist jetzt druchgängig um mehr Platz zur Verfügung zu haben. Ganz links befindet sich der neue Aktualisieren-Button. Dieser im grundsätzlich ausgegraut. Wenn aber eine Kollision festgestellt wurde und irgendwo ein Alert-Icon angeszeigt wird wird der Aktualisieren-Button anklickbar. Klickt man drauf, wird das Containerobjekt neu geladen und alle Alert-Icons verschwinden wil man ja jetzt die neuste Version des Objektes hat.
Im Beispiel oben ist ein bereits angefragter Mitarbeiter wieder entfernt worden, also ist der Aktualisieren-Button aktiv.
Die Mitarbeiterliste
Die Mitarbeiterliste ist wohl das Objekt dass in Bezug auf die parallele Bearbetung die meiste Aufmerksamkeit verdient weil diese ja nicht nur durch die Büromannschaft sondern auch durch die Rundgangsleiter selber bearbeitet wird: Zustimmung, Ablehnung, ...
Grundsätzlich verhält sich die Mitarbeiterliste wie alle anderen Objekte auch. ABER: Ein Klick auf die Mitarbeiterliste im Baum lädt diese neu vom Anwendungsserver und aktualisiert alle Informationen aller Mitarbeiter OHNE das der Aktualisieren-Button geklickt werden muss. Die Alert-Icons verwschwinden.
Neben dem Beispiel oben (Mitarbeiter wieder entfernt) sind hier noch 2 weitere Beispiele:
Wenn das Icon der Mitarbeiterliste selber ein Alert ist sind Mitarbeiter neu angefragt worden. Bitte beachten Sie in dem Fall dass der Tooltip auf die Mitte des Teillbaumers zeigt, nicht auf den Label Mitarbeiterliste. Ist im mittleren Beispiel gut zu sehen.
Reaktionen des Mitarbeiters (Zusage, Absage) sowie das Entfernen des Mitarbeiters aus der Liste werden im Baum direkt beim Mitarbeiter angezeigt.
Verwandte Artikel
Add Comment