Inoffizielles deutsches Xbase-Forum

Hallo zusammen,
wir Entwickeln eine Software die Sowohl vom PC, als auch von Mobilgeräten verwendet werden kann.
Innerhalb der Anwendung werden Daten von Aufträgen geändert. Für Änderungen von einem Mobilgerät aus, verwende ich einen HttpEndpoint(), was auch an sich gut funktioniert.

Mein Problem ist aber nun folgendes:
Wenn ein Mitarbeiter an einem PC einen Datensatz sperrt, und über längere Zeit bearbeitet, kann das Mobilgerät natürlich keine Änderungen vornehmen, und muss warten bis der PC fertig ist. Im Anschluss ändert das Gerät dann seine Daten, weiß aber unter umständen noch nichts von den Daten des PC Mitarbeiters.

Wie behandelt Ihr diese Art von Änderungen, welche geänderten Daten haben nun Vorrang? Wie stelle ich sicher, das nichts verloren geht?

Hallo, Dominik -


das Thema lautet "konkurrierendes Update".

Ich verwende SQL-Tabellen, die über einen eindeutigen Schlüssel verfügen, und einen TIMESTAMP haben, der automatisch die letzte Änderung zeitlich festhält.

Der Anwender liest den Datensatz (ohne Sperre!), das Programm merkt sich den eingelesenen TIMESTAMP. Nachdem der Sachbearbeiter Kaffee-, Mittags- und Nachmittagspause hinter sich hat und endlich weiss, was er ändern wollte, ändert er den Datensatz (den schon n andere User zwischenzeitlich bearbeitet haben). Das Programm liest den aktuellen Satz und vergleicht den TIMESTAMP. Ist der identisch, hat keiner etwas geändert, dann werden die Änderungen übernommen.

Stimmt der TIMESTAMP nicht mehr, wird ein Abgleich der Felder durchgeführt und der Mitarbeiter darauf hingewiesen, dass in der Zwischenzeit folgende Änderungen durchgeführt wurden: (tabellarische Ansicht alt / neu / geplante Änderung durch den Mitarbeiter).

Das ist ein Ansatz, das Problem zu lösen.

Eine generelle Sperre des Satzes empfiehlt sich in den seltensten Fällen.

In Xclass++ speichern wir eine Kopie des Satzinhaltes vor dem Editeiren.
Vor dem Speichern wird überprüft, ob der aktuelle Satzinhalt noch mit der Kopie übereinstimmt (als allgemein gültige Logik können wir ja kein Timestamp oder ADS-Rowversion erwarten, kann über Callbackslot angepasst werden)
Wenn ja, dann wird der Satz erst gesperrt
Wenn nicht, dann kommt eine Meldung und der aktuelle Satz wird wieder zur EIngabe angezeigt (kann per Callbackslot überschrieben werden)
Das machen wir siet Jahren so und es gab nie Probleme.
So werden unnötig lange Satzsperren vermieden.
Eine andere Variante besteht darin, einen Timerthread nach dem Sperren zu starten und nach einer Timeout Zeit ohne Keyboard EIngabe den Satz zu entsperren.

Wir machen das auch so ähnlich wie Marcus, ergänzt um Timeouts - wenn ein Datensatz länger als eine (letztlich konfigurierbare) Zeitspanne gesperrt wird (tatsächlich wird er nicht gesperrt, sondern quasi „reserviert“ - wir fertigen ebenfalls Datenkopien an), ohne dass erkennbar bei der Bearbeitung etwas geschieht, wird die Bearbeitung abgebrochen.

Unsere gesamte Software ist nach dem Schema der Datensatz Sperren aufgebaut. Das zu ändern, wäre vermutlich eine Aufgabe die zu meinen Lebzeiten nicht mehr zu erledigen ist...

Aktuell läuft das so. Das Mobilgerät schickt eine Änderung der Daten über den HttpEndpoint() auf einen Dienst. Dieser prüft, ob der Betroffene Datensatz gesperrt werden kann. Falls nicht, werden die Daten in eine Schattentabelle geschrieben und von Dienst geändert, sobald der Datensatz wieder frei ist. Das Handy bekommt hiervon überhaupt nichts mit. Auch wäre der Bediener des Mobilgeräts nicht wirklich in der Lage Entscheidungen zu treffen, welche Daten getauscht werden können und welche nicht. Der tanzt in aller Regel auf der Autobahn rum und hat andere Probleme.

Ich wollte auch gar nicht nur auf den Fall raus, das jemand vergisst den Datensatz zu schließen. Das kommt tatsächlich gar nicht so häufig vor.
Die Bearbeitung auf dem Mobilgerät geht nur in aller Regel schneller wieder am PC.
Beispiel:

-> PC-Benutzer öffnet den Datensatz und fängt an zu editieren (Datensatz wird gesperrt)
-> Mobilgerät-Benutzer öffnet eine Kopie des Datensatzes welches Lokal auf dem Mobilgerät liegt und fängt an zu editieren (Datensatz wird nicht gesperrt)
-> Mobilgerät-Benutzer beendet das Editieren und schickt die Änderung ab.
-> HttpEndpint() nimmt die Anfrage entgegen, scheitert aber am Sperren des Datensatzes. Daten werden in eine Schattentabelle geschrieben.
-> PC-Benutzer speichert den Datensatz (Datensatz wird entsperrt)
-> Windows-Dienst stellt fest, das der Datensatz frei ist und schreibt die Daten des Mobilgerätes. Möglicherweise werden Daten des PC-Benutzers überschrieben.

Hallo Dominik,

wenn Du aus der Geschichte des bisherigen Lockings nicht mehr raus kommst: Ich habe mal eine eigene Locking-Funktion gebaut wegen Abfangens von Problemen in eine Sequence-Schleife. Und wenn ich schon dabei war habe ich da eine Schleife eingebaut die es 10x versucht den Satz zu sperren. Erst wenn das nicht geklappt hat gibt es eine Rückmeldung zum Bediener, das es mit dem Locken nicht geklappt hat, und der Frage ob er es noch mal versuchen will.

Mit so etwas könntest Du diese kurzzeitigen Konflikte eventuell abfangen ohne gleich die gesamte Programmlogik umzuschreiben.

Jan

Ich denke die ganze Zeit über Szenarien nach, in denen zwei Benutzer ein- und denselben Datensatz gleichzeitig, aber auf verschiedene Arten ändern wollen. Mir sind nicht so schrecklich viele eingefallen.

Stammdaten ( z.B. Adressen) sind da wahrscheinlich keine Kandidaten dafür.
Aber Bewegungsdaten, z.B. Auftragspositionen, die in verschiedenen Abteilungen ergänzt/gepflegt werden: gefertigt, geliefert, berechnet, QS geprüft, etc.
Man denke nur an Murphy...

Es sind Auftragsdaten um die es mir geht.
Es ist nicht unüblich das das Mobilgerät Daten an den Auftrag sendet (Standort, Stati, etc.), das Büropersonal aber ebenfalls neue Daten in den Auftrag einpflegt, sollte es beispielsweise neue Informationen geben. Spezifisch geht es hier um Abschleppaufträge.

Hallo Dominik,
ich bin der Meinung, das die mobil erfassten Daten in einer eigenen Datenbank zum Auftrag landen sollten und diese dann im Programm auch extra dargestellt werden sollten. An den Grunddaten zum Auftrag vom Büro sollte das Mobilgerät nichts ändern. Wenn gewünscht, kann das Büro ja dann die mobilen Daten in den Auftrag übernehmen.

Mobilanwendungen sollten ohnehin nicht so arbeiten, wie wir das von Desktopanwendungen gewöhnt sind. Ich würde da eher Endpoints wie "StatusAktualisieren", "StandortAktualisieren" usw. bauen, die es den Fahrern ermöglichen, zu einem Auftrag bestimmte Informationen zu liefern, und diese Informationen gehen dann, wie Wolfgang vorgeschlagen hat, in eine zusätzliche Tabelle, oder landen in einer Art Queue, bis sie durchgeschrieben werden können, wenn der Auftrags-Kopfsatz gerade zufällig gesperrt ist.

Ich kann da Tom nur zustimmen. Schon wegen der Nachvollziehbarkeit speichere ich in solchen Fällen jede Erfassung einzeln ab. Mit timestamp, etc.. verdichten kann man dann immer.

Dann werde ich das ganze Konstrukt nochmals überdenken müssen.
Vielen dank erstmal für den Input.

Servus Dominik,

wir machen das seit Jahren über einen Replikations-Server. Die Mobile-APPs arbeiten draußen offline, speichern ihre Daten also lokal in Tabellen, weil ja nicht immer sichergestellt ist, dass man online ist. Somit max. Geschwindigkeit, keine Verzögerungen.
Dann gibts einen Menüpunkt (oder auch die Option, das in regelmäßigen Zeitabständen automatisch im Hintergrund laufen zu lassen) Replikation. Damit werden die Daten dann in beide Richtungen abgeglichen. Jeder Satz hat eine UUID. Gibts einen Konflikt, wird das auf der APP angezeigt und der Benutzer kann dann entweder selbst entscheiden (je nach Benutzer-Recht) oder weiß, er hat jetzt vom Server den aktuellen Stand bekommen und kann die Daten nochmal neu ändern.

Konflikte kommen bei der APP aber so gut wir gar nicht vor, da es sich nicht um z. B. Auftragsdaten handelt, sondern 1 Datensatz immer einen kompletten Vorgang beschreibt (mit Relationen). Es kommt nicht vor, dass 2 Mitarbeiter gleichzeitig vor Ort beim selben Kunden sind und beide gleichzeitig über ihre APP was ändern. In der Zentrale und den Außenstellen werden "Vor-Ort-Daten" i. d. R. auch nicht geändert, sondern kommen dort dann automatisch an und werden ggf. korrigiert (Rechtschreibfehler) oder ergänzt.

Es versteht sich von selbst, dass die App nicht in Xbase++ erstellt ist, da Xbase++ keine nativen Apps unter Android und IOS erzeugen kann. Der Replikationsserver ist ein Standard-Produkt der Programmiersprache der Apps, ich wollte Dir nur eine funktionierende Lösung aus der Praxis aufzeigen.

Wenn das mobile Gerät in einer Großstadt auf der Straße unterwegs ist, mag ja so einiges gehen.
Wenn man aber aufs Land oder gar in ein Gebäude muss, braucht man dringend lokale Daten (mangelndes Funknetz, oder Gebäudeabschirmung).
Beim Synchronisieren kommt es auf jeden Fall auf Nachvollziehbarkeit an und was wer überhaupt ändern darf.

Wir synchronisieren auch, wenn es möglich ist, und halten die Daten ansonsten in der App persistiert lokal vor (SQlite). Wir haben auch Kunden, die nur in der Einrichtung selbst synchronisieren, weil die Datenschutz- und -sicherheitsrichtlinien grundsätzlich keinen Zugriff auf die Daten von außen erlauben. Da stehen die Server in DMZs und haben höchstens passive Wege nach draußen.

Aber. Es gibt bezogen vor allem auf die zurückzusynchronisierenden Daten ganz klare und eindeutige Hoheitsrichtlinien. Bestimmte Daten aus der Mobilapp haben grundsätzlich Priorität, während die App zugleich andere (Arten von) Daten niemals überschreiben darf. Das hat auch etwas mit der Prozessintegrität zu tun. Ich kann es nicht erlauben, dass zwei unterschiedliche Instanzen dieselben Daten auf unterschiedliche Weise manipulieren, und was richtig ist, das entscheidet dann ein simples "First come, first serve". So geht das nicht. Daten haben nicht nur zeitliche Priorität, sondern auch prozessuale und solche, die mit der Nutzerrolle zu tun haben. Ein mobiler Mitarbeiter, der die Erbringung eines krankenpflegerischen Einsatzes dokumentiert, hat in Bezug auf diese Dokumentation immer den Hut auf. Ich muss dafür sorgen, dass die Synchronisations- und Bearbeitungswege, die ich überall zur Verfügung stelle, das auch abbilden. Nur weil zufällig in der Einrichtung selbst jemand auf die Idee kommt, diese Daten gerade zu bearbeiten, darf die Information, die von außen kommt, nicht verlorengehen. Das muss man einfach sicherstellen, auch inhaltlich. Sonst hauen einem sämtliche Kontrollinstanzen, die es da inzwischen gibt, auch alles um die Ohren.

Und ich denke, ähnliches gilt für sämtliche Branchen und Geschäftsfelder. Ein mobiler Mitarbeiter eines Abschleppdienstes hat eine ganz andere Sicht auf die (Auftrags-)Daten als jemand in der Disposition oder in der Abrechnung. Es sollte gewährleistet sein, und zwar prozessual, dass die sich nicht ins Gehege kommen. Das ist eine essentielle Anforderung an eine Softwaretopologie, die da eingesetzt wird.

Habt Ihr das von der Post in England mitbekommen ?
In der Firmenzentrale und beim Software Hersteller war bekannt, dass es wohl Probleme mit der Software der Postoffices gab.

Aber über mehrere Jahre wurden die selbständigen Postleiter in den Filialen vor Gericht gezerrt und teilweise zu vielen Jahren Haft wegen Veruntreuung verurteilt.

Bis heute sind nicht alle rehabilitiert und nur eine TV Serie über den Skandal hat dafür gesorgt, dass das öffentlich wurde.
Vorher waren ja nicht nur die betroffenen Mitarbeiter unschuldig im Gefängnis, sondern auch die Familie im jeweiligen Ort "unten durch".

https://de.wikipedia.org/wiki/Royal-Mai ... on-Skandal