HTTPS Post an Server in einer Queue senden

[linxxruxx]

Hallo,

ich arbeite noch nicht lange in Delphi. Habe zu meinem Thema viel gegoogelt und seh den Wald vor lauter Bäumen nicht mehr.

Folgendes:
Ich habe eine SQL-Lite Datenbank in Delphi erstellt, welche Aufträge enthält (ID, ServicePartnerID, Auftragsart,..., SentToServer).
Habe verschiedene Queries erstellt, um den Auftrag zu erstellen, zu befüllen und zu laden.
Diese Vorgänge geschiehen alle in der App, wenn jemand die Aufträge bearbeitet etc.
Änderungen werden also bei mir in Delphi in die SQL-Lite Datenbank in eine neue Tabelle (AuftraegeCache) gespeichert.
Nun möchte ich die bearbeiteten Aufträge auch, wenn Serververbindung besteht, ans Backend schicken.

Mein Plan:
- In einer Unit eine MemTable mit den geänderten Aufträgen der AuftraegeCache-Tabelle laden

- Die Memtable durchgehen und auf den Boolean (SentToServer = false) prüfen

- Ist der Eintrag der Memtable auf false, geh in eine Warteschlange und warte dort so lange bis Verbindung zum Server besteht

- Wurde Verbindung zum Server hergestellt, versende den Auftrag an den Server

- Kommt eine Antwort vom Server, dass das Senden erfolgreich war, setzte das Feld SentToService auf True

- nächsten Eintrag der Memtable und alles von vorne-




Die Memtable zu befüllen, in einer

Code:

while not Memtable.Eof

durch die Memtable gehen und auf

Code:

if FDMTAuftragCache.FieldByName('SentToServer') = false then

prüfen habe ich bereits gemacht..
Wie ich allerdings in der if-Anweisung eine Queue erstelle und den Auftrag dann an den Server schicke weiß ich allerdings überhaupt garnicht ...

Es wäre so lieb, wenn mir jemand hilft.
Ich weiß ihr braucht immer Code-Beispiele aber mehr als das was ich erklärt habe, habe ich derzeit nicht.

Delphi-Quellcode:

unit SendeCacheUnit;

interface

uses FireDAC.Comp.Client, FireDAC.Comp.DataSet, Data.DB,
   Data.FireDACJSONReflect, DBHelperUnit;

procedure SendeCache(Sender: TObject);

implementation

procedure SendeCache(Sender: TObject);
Var
   FDMTAuftragCache: TFDMemTable;
   LDataSetList: TFDJsonDataSets;
begin


   FDMTAuftragCache := TFDMemTable.Create(nil);                                          //erstelle die Tabelle und füge Felder hinzu
   FDMTAuftragCache.FieldDefs.Add('id', ftInteger, 0, false);
   FDMTAuftragCache.FieldDefs.Add('ServicePartnerID', ftInteger, 0, false);
   FDMTAuftragCache.FieldDefs.Add('BenutzerID', ftInteger, 0, false);
   FDMTAuftragCache.FieldDefs.Add('Auftragsart', ftString, 0, false);
   FDMTAuftragCache.FieldDefs.Add('Status', ftString, 0, false);
   FDMTAuftragCache.FieldDefs.Add('Zeitstempel', ftString, 0, false);
   FDMTAuftragCache.FieldDefs.Add('ZeitstempelUpdate', ftInteger, 0, false);
   FDMTAuftragCache.FieldDefs.Add('SentToServer', ftBoolean, 0, false);

   LDataSetList := DBHelperUnit.DBHelper.ladeAuftraegeCache;                             //befülle die Tabelle durch die Datenbankabfrage
   FDMTAuftragCache.AppendData(TFDJSONDataSetsReader.GetListValue
      (LDataSetList, 0));
   FDMTAuftragCache.Open;

   while not FDMTAuftragCache.Eof do                                                     //solange nicht am Ende Der Tabelle, geh durch die Tabelle
   begin

      if FDMTAuftragCache.FieldByName('SentToServer') = false then                       //wenn noch nicht an den Server gesendet wurde, geh in die Anweisung
      begin

//hier soll der Eintrag in einer Queue warten, bis Serververbindung besteht und dann mittels HTTPs den Eintrag an den Server schicken.. 
//wenn dann Antwort vom Server kommt, wird der Boolean SentToServer auf true gesetzt und man beginnt mit dem nächsten Auftrag


      end;

   end;

end;

end.

Viele Grüße

[Schokohase]

Wofür eine MemTable? So etwas speichert man in der lokalen SQLite, damit dieser Zustand (übertragen an Backend) auch einen Neustart der Anwendung übersteht.

[linxxruxx]

Ich speichere die Änderungen doch in einer lokalen SQL-Lite.
Dachte nur, ich muss irgendwie drauf zugreifen, damit ich nur die ans Backend schicke, welche SentToServer = False sind.
Nach erfolgreichem Senden ändere ich den Wert auf True.

Wenn eine Memtable nicht richtig ist, dann wäre ich über einen zusätzlichen Vorschlag super dankbar.

Viele Grüße

[Schokohase]

Es geht nicht um die MemTable, sondern darum, dass NUR die MemTable etwas dürftig ist, weil die Information auch in die lokale Datenbank selber zurückgeschrieben werden sollten.

Du kannst auch nebenbei noch ein Lied pfeifen, einen Drachen steigen lassen oder in der Nase bohren. Hauptsache die Daten werden zurück in die Datenbank geschrieben.

Du hast davon aber nirgends etwas geschrieben und darum habe ich gefragt, denn ich kann einiges aber nicht Gedanken lesen.

[linxxruxx]

"Änderungen werden also bei mir in Delphi in die SQL-Lite Datenbank in eine neue Tabelle (AuftraegeCache) gespeichert."

Also die Änderungen werden in die Datenbank geschrieben.
Zum Einen in die ursprüngliche lokale Tabelle (Auftraege) und zum anderen in eine Cache Tabelle (AuftraegeCache).
Aus der AuftraegeCache sollen sie irgendwann auch wieder gelöscht werden.

Es tut mir leid, wenn ich mich nicht so gut ausdrücken kann. Das ist keine böse Absicht von mir.
Und ich weiß auch, dass die Arbeit, die ihr auch noch völlig kostenfrei leistet, sehr gut ist.

[Schokohase]

Wo werden die Aufträge erstellt?

Speziell geht es mir darum, wie die ID des Auftrags erzeugt wird. Wie ist da die Logik um doppelte IDs zu vermeiden?

[Rolf Frei]

Besteht denn das Backend schon und gibt es da eine Schnittstelle die du per HTTP nutzen kannst? Das Schicken an den Webserver ist jetzt noch das kleinste Problem (z.B. mit Indy idHttp), wenn da noch garkeine Schnittstelle besteht.

[linxxruxx]

Die Aufträge werden im Backend erstellt und an meine SQL-Lite Datenbank geschickt und rein geschrieben. Ich hole mir in Delphi lediglich die bereits vom Backend befüllte Tabelle "Auftrag".

Ich habe eine DBHelperUnit geschrieben. Darin sind alle Queries hinterlegt, welche ich in Delphi nutze.
Darin gibt es dann verschiedene Queries für die Aufträge, die ich aus der Datenbank lade, um sie in der App anzuzeigen oder zu bearbeiten (CreateAuftrag, LadeAuftrag, UpdateAuftragStatus zb.)

Wird in der App dann etwas geändert, werden die Änderungen z.B über die "UpdateAuftragStatus"-Query wieder zurück in die eigentliche Datenbanktabelle "Auftrag" geschrieben.
Parallel werden die Änderungen dann aber auch in die Datenbanktabelle "AuftragCache"geschrieben.
Diese Tabelle ist quasi eine Kopie-Tabelle der eigentlichen Tabelle "Auftrag", nur dass sie am Anfang leer ist und erst befüllt wird, wenn Änderungen kommen.

Aus dieser "AuftragCache" sollen dann die Daten auch noch an das Backend geschickt werden (Ist eine Webanwendung).
Im Backend wird der Auftrag dann über die ID gesucht und geupdated mit einem Zeitstempel.


Eine Schnittstelle gibt es schon an das Backend. Jap ich kann diese über http nutzen.
--> Über Indy und idHttp etc hab ich schon viel gelesen, nur weiß ich nicht wie ich das schreiben kann, wenn ich einen kompletten Datenbank-Eintrag versenden will.

[Rolf Frei]

Was du machen willst ist mir absolut klar, aber das wird nicht einfach so gehen. Das Backend muss mit deinen Daten zurecht kommen.

Wie du das senden musst, bestimmt das Backend. Du musst dann nur noch die URL wissen und die die vom Backend benötigten Parameter, entsprechend übergeben (via HTTP POST oder GET).

Ich vermute mal, dass das was du da genau machen willst, so nicht direkt gehen wird. Ich bezweifle dass das Backend genau dafür eine Funktion hat. Wenn es im Backend über HTTP eine Schnittstelle gibt, um Auftrage einzulesen, müsstest du deine lokalen DB-Daten in das geforderte Format bringen (ev. JSON, XML oder halt per HTTP POST/GET Parameter) und diese dann an den HTTP-Server senden.

[linxxruxx]

Okay, ja das werde ich auf jedenfall mit einem Kollegen abklären, wie das Backend die Daten erwartet.

Ist das mit der Queue denn umsetzbar? Das bedeutet: so lange in der Queue bleiben, bis Kontakt zum Server besteht?
Ich weiß absolut nicht wie ich das angehen kann, würde wenigstens schon mal den Kopf dafür basteln und dann den Inhalt (was ich sende) noch abklären.

Danke für die Antworten.