Guten Morgen!
Nachdem ich den Thread nochmal komplett gelesen und mir über das Wochenende viele Gedanken gemacht habe, möchte ich nochmal zusammenfassen und konkrete Umsetzungsvorschläge anbringen:
* Auf dem Datenbank-Server wird eine REST-
API eingerichtet. (Diese habe ich zum Glück schon aus einem anderen Projekt fertig). Die
API deshalb, weil wir tatsächlich planen, noch andere Plattformen zu bedienen und die Wartung ist viel einfacher (Queries nur auf einer Plattform aktualisieren/erstellen). Long-Polling kann umgesetzt werden.
* Auf dem Windows-Server wird ein Server-Dienst laufen. Dieser dient auch als Zwischenschicht zwischen Clients und Datenbank-Server. Die Verbindung wird über
TCP-Server/
TCP-Client von
Indy realisiert. Der Server-Dienst nimmt requests entgegen und verarbeitet sie. Diese Requests sind vom Typ TRecord und haben mindestens folgende Felder: Absender, Empfänger, Timestamp, request_id, request_str (json_string). So sollte eine exakte Zuordnung und Verarbeitung der Nachricht möglich sein (genauer ist das noch nicht durchdacht). Je nachdem, was der TRequest dem Server aufträgt, führt er die Aktion durch (Aktion mit anderen Clients oder Anfrage an die
DB). Danach sendet er an den ursprünglichen Absender oder einen "Broadcast" TResponse zurück.
* Der Server-Dienst prüft die Erreichbarkeit des Datenbank-Server (vllt. Ping, oder über eine UniDAC-Methode (weiß ich noch nicht)). Ist er mal nicht erreichbar, sendet er einen "Broadcast" (eher eine
TCP-Nachricht an alle Clients), dass der Server weg ist. Diese zeigen es dann in der
GUI an. Vllt. empfängt der Dienst Datenbank-Anfragen, die er zurückhalt, bis die Verbindung wieder aktiv ist. Weitere Aufgaben der Windows-Dienstes sind zeitgesteuerte kleinere Backups (kein Image o.ä.)/Aufräumarbeiten, Benachrichtigungssysteme etc.
* Benachrichtigungssysteme:
- User A und B haben Modul-1 offen. User B ändert Daten über Modul-1. Nun sendet der Dienst eine
TCP-Nachricht an alle User, die Modul-1 offen haben, damit sie aktuelle Daten laden können. Bzw, der Server lädt einmal die aktuellen Daten und sendet sie schon an den User.
- Ein wichtiges Modul ist gerade nicht geöffnet. Es wurden aber von B wichtige Daten für A hinterlegt. So wird User A vom Server benachrichtigt, dass wichtige Daten vorliegen.
* Optimierungen: Da z.T. auch über außenstellen gearbeitet wird, ist VPN sehr wichtig (sensible Daten und einfachere Kommunikation). Die Daten sollen also klein gehalten werden. Ein Zwischending zwischen den hier genannten Vorschlägen wird einzuhalten sein. Wenn man gut plant, mitdenkt und den rest durch ausprobieren ermittelt, dann wird es kein Thema sein.
Soweit bin ich erstmal. Hab nur eine Frage zum Format der
TCP-Anfragen. Wie soll ein Kommando an den Server aussehen? Es wird ja vermutlich ein String sein. Soll er wie Parameter in URLs aussehen (module=abc&action=getImportantData&dataId=123), soll er in
URL-Form sein (/ABC/getImportantData/123), oder soll es ein Record sein TParams (Modul: abc, Action: xyz...). Was macht da Sinn? Man müsste immer mit Explode etc. arbeiten. Habt ihr dazu noch weitere Vorschläge?
Vielen Dank für die rege Anteilnahme!