Skip to content

Push Service

Mit dem Push Service werden Änderungsmeldungen an die mit SignalR verbunden Web Clients verteilt.

Übersicht

Mit dem Push-Service wird sichergestellt, dass die Web-Clients die Aenderungen an den Objekten mitbekommen. Es ist also das LiveData fürs Web. Im Gegensatz zum LiveData vom Windows-Client erfolgt dabei kein Polling sondern ein Push der Meldungen zum Client.

Datenfluss

Bei eienm Save-Prozess generiert der Server-Service eine LiveData-Meldung. Diese wird zum einen auf dem Server gehalten damit der Windows-Client diese der Polling abholen kann, zum andern in eine oder Push-Meldungen umgewandelt. Push-Meldungen werden an der Push-Service geschickt (POST /api/push/data).

LivaData- und Push-Meldungen werden in der Datenbank zwischengespichert (LIV, LIV_PUSH). Beim Servicestart werden die Inhalte dieser Tabellen gelöscht.

Web-Clients registrieren die aktuellen Objekte des Entitystores beim Push-Service (SinalR Track). Dies sind die aktuell direkt oder indirekt angezeigten Objekte vom Web-Client. Der Entitystore vom Web-Client wird beim Schliessen von Ansichten aufgeräumt. Nicht mehr relevante Objekte werden dabei beim Push-Service deregistriert (SignalR Release). Bei der Registrierung, frägt der Push-Service den Server-Service, ob diese Objekte überhaupt gelesen werden dürfen (POST /api/LiveData/AllowedRead).

Empfängt nun der Push-Service vom Server-Service eine neue Push-Meldung, so wird diese per SignalR an die daran interessierten Clients weitergeleitet (SinalR SendMessageAsync). Das heisst an die Clients, welche vorgängig das Objekt registriert haben.

Da es vorkommen kann, dass der Empfänger (Web-Client) gewisse Assoziationen der Push-Meldung gar nicht sehen darf, werden diese vor dem Senden an den Web-Client noch geprüft. Dies erfolgt mit einem Aufruf an den Server-Service (POST /api/LiveData/GetAccess). Damit erhält der Web-Client nur die berechtigten Informationen und als Teil der Meldung den aktuellen access.

Recover

Es kann sein, dass durch ein Applikations- oder Systemfehler nicht alle Meldungen beim Web-Client ankommen. Wenn dies der Web-Client merkt, löst dieser ein Recover aus (SignalR Restore). Dabei schickt der Web-Client seine aktuelle Meldungs-Id. Der Push-Service holt sich dann vom Server-Service alle Meldungen mit einer höheren Meldungs-Id ab (GET /api/LiveData/RecoverMessages).

Meldungsformat

LiveData-Meldungen sind eng mit dem DataSet (ObjektDaten) vom Windows-Client verknüpft. Dieses steht beim Web-Client nicht zur Verfügung. Eine Push-Meldung beinhaltet Objekt-Guid, Version, Displayname, Typen-Informationen und Assozationen. Also keine Werte (VALs). Der access wird vom Push-Service angereichert. Es wird unterschieden zwischen Update- und Delete-Meldungen.

Meldungsnummer

Der Client geht davon aus, dass die ids der Medlungen lückenlos hochgezählt werden. Der Server Service stellt dies sicher, in dem wenn nötig Dummy-Meldungen erstellt werden.

Konfliktbehandlung

Die Konfliktbehandlung ist Sache des Clients und nicht des Push-Services.
Unser Webclient handhabt das im Moment so, dass er dir alle Felder überschreibt, aber dir danach in einem Dialog die Option anbietet, deine verworfenen Änderungen (nur Text) noch zu kopieren.

Der Push-Service hat keine persistierte Datenhaltung. Der Push-Servie ist nicht Mehrmandanten-fähig und ist derzeit nicht Loadbalancing-fähig.

Change-Log

Change-Log