Fakturierungsserver

[psycodad]

Grüezi miteinander,

WIr haben hier ein gar nicht mehr so kleines Fakturierungsprogramm, das aus z.B. 100'000 Datensätzen eine Rechnung generiert. Dabei fallen viele Tasks an die meistens seriell getätigt werden müssen. Ich zähl mal grob auf:

1. Datenvalidierung
2. Rechnungskopf schreiben
3. Daten summieren zu Rechnungspositionen und Subpositionen usw.
4. Diverse Reporte (Fastreport) generieren
5. Reports per Mail versenden

Daneben gibt es noch ein paar weitere (ich nenn das jetzt mal Prozesse ) die so oder ähnlich abgearbeitet werden müssen. Im Moment sind die einzelnen Prozesse als moströse Prozeduren direkt im Desktop Programm (MDI-Devexpress Applikation) implementiert als richtig toll zu wartender Sphagetti Code (Ironie off). Da Problem daran ist dass ein solcher Prozess gut mal 5 Min. in Anspruch nehmen kann. Währendessen ist die Applikation so quasi eingefroren. Ich könnte jetzt jeden dieser Prozesse in einen TTask legen und schon ginge das besser. Aber eingentlich hat diese Arbeit gar nichts in dem Desktop Programm zu suchen. Ich möchte diese Verarbeitungsprozesse auslagern in einen Fakturierungsserver. Ein weiterer Grund dafür ist dass die Desktop App in einem Terminalserver läuft und dort so ziemlich viel CPU und RAM abzweigt wenn es ans Fakturieren geht. Deshalb soll das Fakturierungsserver-Programm auf einem anderen Server laufen.
Ich stelle mir vor das man vom Desktop Programm aus einen oder mehrere Jobs aufgibt. Der Fakturierugsserver trägt den Job in eine JobListe ein und liefert eine JobID zurück. Das Desktop-Programm pollt dann beim Fakturierungsserver mit dieser JobID von Zeit zu Zeit den Fakturierungsserver und fragt den Job-Status ab. Wenn Fehler auftreten kann der Desktop-Programm das Log des Jobs abholen und anzeigen.
Ich habe schon solche Sachen als (Webservice) SOAP-Server geschrieben. Das funktioniert gut.
Jetzt zu meiner Frage:
1. Ich würde gerne wissen ob es für die Implementierung einer solcher Task-Abarbeitungs-Maschine irgendwelche Design Patterns gibt? Ich hab da mal was von einer Statefull machine gehört, bin ich da richtig?
2. Gibt es da Librarys die einem dabei helfen können das elegant hinzukriegen (z.B. Spring4D oder so)? Oder ist das Overhead, macht man das mit Bordmitteln?

Ich würde mich über ein paar Tips und Anregungen freuen.

[hoika]

Hallo,
zu Punkt 2

Zitat:

und dort so ziemlich viel CPU und RAM abzweigt wenn es ans Fakturieren geht

Welche Datenbank benutzt ihr?
Welche Zugriffskomponenten?
Gerade wenn es ein "älteres" Programm ist, könnte dort mit TXTable usw. gearbeitet worden sein,
was meistens sehr lange dauert.
Eine Stored Procedure bringt da u.U. Wunder.

Zitat:

JobListe

Bedenke hier auch, dass es Abhängigkeiten der Jobs untereinander gibt.
1. Datenvalidierung
2. Rechnungskopf
3. usw.

Ich würde erst mal anfangen, das Speed-Problem zu prüfen (Punkt 2).

[jobo]

Ich würde das alles in der Datenbank machen.
Jedes externe Tool / Lib / .. muss naturgemäß die Daten erstmal von der DB lesen, berechnen, neue erzeugen und wegschreiben und dann wieder reporten, mailen, ...
Der Datentransport fällt innerhalb der DB ja schon mal weg und es sollte alles flott gehen.

Wahrscheinlich ist das aber nicht die Antwort, die Du hören willst.

Jenseits der DB wird es dann relativ beliebig. Es gibt dutzende oder hunderte Libs die einem an verschiedenen Stellen die Arbeit erleichtern.
Wenn es wirklich darum geht, voll durchautomatisiert, intelligent Daten aufzubereiten, zu verteilen, zu reporten und zu vermailen, dann vielleicht eine Workflow Engine.
Z.B. sowas wie Camunda, aber das ist natürlich nicht Delphi.

Davon ausgehend dann also vielleicht sowas (hab ich natürlich noch nie benutzt)
https://www.tmssoftware.com/site/workflow.asp

[himitsu]

Jupp, wie schon erwähnt wurde, ist ja grade ein gutes DBMS dafür da mit vielen Daten ordentlich zu rechnen.

* in der DB alles berechnen (paar SELECTs von einem Programm aus sind da dann aber nicht unbedingt das opzimale)
** alles in StoredProcs/Trigger, wo dann durch irgendwen regelmäßig eine Berechnungsfunktion angestoßen wird

* Report-Daten und zu versendende Mails (ReportID, Text, Mailadressen uns) in Tabellen sammeln und dann von einem Programm abrufen
** ab und an anfragen ob was da ist, oder direkt über Notifications die Abfrage anstoßen


Gut, mit den dir bekannten Mitteln lässt sich in der DB dann die Berechnung nicht Debuggen, aber auch dafür gibt es entsprechende Lösungen.





Aber wenn du erstmal nur aufräumem willst, dann nicht mit Tasks/Threads anfangen. Vergiss nicht, dass du dort dann auf eine Trennung oder Synchronisierung global/gemeinsam verwendetet Objekte/Variablen/... sorgen mußt.
Mach es einfach wie viele andere Programme ala Browser, Datenbankserver uvm.:
> Lege Einzelteile in eigenständige Programminstanzen, gesteuert/gestartet/verwaltet von einem "einfachen" Masterprogramm.
= RAM hat dann jeder seinen Eigenen, globale Objekte gibt es erstmal auch nicht mehr, ein schlimmer Fehler beeinflusst Andere nicht
und von den Tasks/Threads her macht es für das System keinen Unterschied (ist insgesamt ja gleich) und der gesamte RAM ... OK, der wird etwas mehr (jeder bekommt seine eigene Connection usw.), aber RAM kostet nun wirklich nichts.
= außerdem verreckt dann nicht gleich alles, wenn ein Teil abkratzt,
du kannst die Einzelteile auch viel einfacher Debuggen, wenn nicht ständig was anderes reinkretscht,
und wenn du an einem Teil rumschraubst, ist die Wahrscheinlichkeit viel kleiner, dass andere Teile auch kaputt gehn (bei gemeinsamen Sourcen auch dann nicht, wenn nicht jedesmal alle EXEn neu erstellt werden)

Und wenn jede Programminstanz dann nur einen kleinen Teil erledigt, dann lassen sich davon auch Mehrere starten, wenn noch genügend Rechenleistung frei ist.
(je ein Datensatz und sich dann beendet oder den nächsten Satz abholen)

[psycodad]

Erstmal vielen Dank für die detaillierten und informativen Antworten.

Wir benützen einen SQL Server 2018 mit 255GB RAM. Die DB (die grösste) ist so um die 300GB gross. Die einzelnen Datenaufbereitungen (Datenvalidierung, Durchrechnen der Preise, Generieren von Positionen etc.) finden alles bereits in Stored Procedures statt. Die Tabellen der einzelnen Selects innerhalb der STP's sind alle mit Indexes optimiert dort wo es Sinn macht. Wir werden in den nächsten Monaten neuere Storages mit SSD bekommen. Das wird das ganze erheblich beschleunigen.

Das Desktop Programm startet die STP's, wartet auf deren Beendigung und ruft dann einen ebenfalls selbst geschriebenen Reportserver auf, der dann die verschiedenen PDF-Formulare generiert und ggf. versendet. Dieser Reportserver funktioniert auf Basis eines Webservices, dem Jobs übergeben werden können.

Da wir pro Monat tausende Rechnungen generieren (Kleine gehen ein paar Sekunden. Monsterrechnungen eben bis zu 2-5 Min.) macht es aus den im ersten Beitrag erwähnten Überlegungen aus meiner Sicht schon Sinn, diese Aufgabe in ein zweites Programm auszulagern.

Im Gegensatz zu einem Reportserver, wo die Anzahl Prozessschritte sich in Grenzen halten (Reports drucken, ablegen oder versenden) muss der Fakturierungserver einen oder mehrere ziemlich komplizierten Prozesse durchlaufen. Dabei können Warnungen oder Errors anfallen. Deshalb musss jeder Prozessschritt geloggt werden. Je nach Resultat eines Prozesses fallen Entscheidungen an, der Prozess geht also nicht einfach linear durch.


Daher meine Frage nach Design Patterns und Librarys, die mich bei meinem Vorhaben unterstützen könnten.

[psycodad]

Zitat von himitsu:

Gut, mit den dir bekannten Mitteln lässt sich in der DB dann die Berechnung nicht Debuggen, aber auch dafür gibt es entsprechende Lösungen.

Hmm, ich weiss sehr wohl wie man STP's debuggen kann. Woher die Annahme ich könne das nicht?

[jobo]

Interessant!

SSD bringen vermutlich nicht so viel, ich tippe mal Faktor 2 oder 3. Aber gut, kommt darauf an, wie alt / mies die jetzige Hardware ist.

Die größte DB passt also fast in den RAM, das müsste ja dann bei kleineren DB einigermaßen flott gehen. Aber wahrscheinlich laufen die alle zusammen und die Rechnungen werden natürlich immer von verschiedenen Systemen angefordert.

Wenn alles schon in SP ist, ist das schon mal gut. Dann kannst Du eigentlich nur nach Libs schauen, die intelligent mit den Zwischenergebnissen umgehen.


Große Performance Steigerung würde man dann wohl jetzt nur über Tuning von einzelnen Statements erreichen. Und über eine Zugriffsoptimierung, um möglichst viele blockierende Operationen zu finden und zu eleminieren. Dabei wäre z.B. spannend, wie in dem Prozess mit Transaktionen gearbeitet wird. Das Sperrverhalten von sql server war zumindest früher nicht so dolle. 2014 hat aber bestimmt schon dazu gelernt, 2018 wahrscheinlich um so mehr.

Das mit dem Debuggen ist nicht bei jedem System möglich, ich kenne es von der Nutzung her nur von Oracle. Das meint himitsu wahrscheinlich. Am Ende tun es hier aber meist auch ein paar Logausgaben in Textfiles. Um Long Running Statements zu finden, muss man aber wohl nicht debuggen.

[Jumpy]

Zitat von psycodad:

Ich könnte jetzt jeden dieser Prozesse in einen TTask legen und schon ginge das besser.

Das wäre das erste, was ich auf jeden Fall machen würde. Entwickelt eine saubere entkoppelte Programm-Logik, die eure Dinge fakturiert. Multitheraded mit Pools und Queues usw., die ggf. mehrere Dinge gleichzeitig fakturieren kann. Optimiert es soweit es geht.

Dann kann man überlegen, dass im Desktop-System einzubauen. Ist wahrscheinlich dann immer noch nicht optimal, weil es Resourcen an der falschen Stelle frisst. Oder aber man baut losgelöst ein Server-Programm in dem man seine Fakturierungs-Logik unterbringt. Dann muss man sich "nur" im Desktop-Programm um eine Kommunikation mit dem Server kümmern und da ist es dann sowohl denkbar, dass Client und Server direkt miteinander kommunizieren oder aber das sie über die Datenbank "kommunizieren", indem der Client ein Ding zur fakturierung frei gibt, der Server nach solchen Dingen sucht und dies dann einem Thread zur bearbeitung übergibt.

Was ich eigentlich sagen will: Betrachtet das als zwei Dinge: Optimierung der Fakturierungs-Logik und Client-Server-Geschichte.
Für letzteres findest du dann vielleicht eher Vorlagen oder Pattern, bei ersterem kann euch eh kein Fremder wirklich helfen.

[jobo]

Wenn man
die SP auf dem SQL Server variiert und
über DB Jobs und Schedules anspricht und
den Delphi Client nur noch zum Einlagern in die Jobqueue
und zur Visualisierung von (Zwischen)Ergebnissen nimmt, braucht man nicht mal threads in Delphi.

Wenn man natürlich in Delphi viel Rechnungslauf Know How implementiert hat und erhalten möchte, dann ist es wahrscheinlich sinnvoller, es dort zu behalten und optimiert zu nutzen.