Fakturierungsserver

[jobo]

Was ist so kompliziert an den Rechnungen?
Iterative Preisberechnung? Oder vielfältige Rabattmodelle und Rechnungsvorschriften?

Noch zu Indizes:
Das Anlegen von Rechnungen dürfte ja zu großen Teilen mit dem Anlegen von Datensätzen verbunden sein, da hilft viel nicht unbedingt viel, eher umgekehrt.

[psycodad]

Zitat von jobo:

Was ist so kompliziert an den Rechnungen?
Iterative Preisberechnung? Oder vielfältige Rabattmodelle und Rechnungsvorschriften?

Noch zu Indizes:
Das Anlegen von Rechnungen dürfte ja zu großen Teilen mit dem Anlegen von Datensätzen verbunden sein, da hilft viel nicht unbedingt viel, eher umgekehrt.

Erstmal vielen Dank für die Anregungen/Tips.

Es ist so dass im Extremfall eine Rechnung basierend auf 100'000 Records berechnet werden muss. Dazu werden alle Records durchlaufen und die Felder mit diversen Checks auf Gültigkeit geprüft. Dann wird für jeden Record ein Preis berechnet. Du bringst es auf den Punkt, wir haben hier ein fantasievolles Rabattsystem und ziemlich komplizierte Rechnungsvorschriften. Danach werden die Records gruppiert und dann werden Rechnungspositionen basierend auf diesen Gruppen geschrieben. Jeder Record ist genau einer Rechnungsposition zugeordnet. Wie gesagt, für eine einfache Rechnung bewegen wir uns da inkl. Reporterstellung im Sekundenbereich.

Es gäbe noch einiges zu optimieren in den verschiedenen STP's betreff der Granularität von Transaktionen etc. Da aber bald viele neue Vorschriften dazukommen (z.B: Splitten von Rechnungen auf verschiedene Debitoren etc.) werden haben wir uns für ein Refactoring entschieden.

Es geht nicht darum, das letzte Quentchen Perfomance herauszukitzeln. Es geht mir darum, dass der Job vom User angestossen werden kann ohne dass er auf dessen Ende warten muss. Er soll normal in der Destop-MDI weiter arbeiten können. Er wird informiert, wenn der Job fertig ist. Er kann jederzeit den Status eines Jobs einsehen und das Log des Jobs verfolgen.

Technisch geht es darum, die ebenfalls langsam etwas monströsen STP's in logische Einheiten aufzubrechen. Der Fakturaserver sorgt sich nur um die Job-Verwaltung, Gibt den Status eines Jobs auf Anfrage zurück und führt den Job aus. Dabei soll er einem Prozessplan folgen. Die einzelnen Prozessschritte starten dann z.B. eine STP oder schreiben wieder um einen Job an den Reportserver. Wenn der Prozessschritt ausgeführt ist gehts bei Erfolg zum nächsten Schritt. Ich könnte mir auch vorstellen, dass je nach Resultat/Zustand eines Prozessschrittes ein anderer Prozessbaum abgearbeitet werden kann. Da bin ich jetzt eben am Informationen beschaffen, ob es da Design Patterns oder sogar irgendwelche Frameworks/Libraries gibt wie man so etwas aufbaut.
Ich könnte einfach loslegen und mit ein paar verschachtelten Ifs usw. das ganze niedernageln. Ich suche aber einen mehr generellen Ansatz so etwas zu machen. Ich kann mir gut vorstellen in Zukunft weitere andere Prozesse über den Fakturaserver laufen zu lassen.

Ich habe diese Infos gefunden:
https://www.delphipraxis.net/186504-...er-delphi.html
http://melander.dk/delphi/statemachine/

Ich bin mir nicht sicher, ob das "the way to go" ist. Wie löst man sowas? Gibt es da andere Lösungsansätze soetwas zu machen?

[psycodad]

Debuggen von STP geht im SQL Server Management Studio wunderbar. Mehr brauchte ich bis jetzt nicht. Auch SQL Optimierungen, Laufzeitanalysen usw. kann man damit alles machen.

[jobo]

Also das sieht mir so aus, als ob Du einfach eine Entkoppelung brauchst. Das wäre z.B. über klassische Datenbank Job zu machen oder auch über autonome Transactionen.
Ausgehend davon brauchst Du natürlich eine Haupt SP, die den ganzen Prozess durchackert.

Du startest einen losgelösten Prozess und schaust über irgendwelche Tabellen, was er so treibt. Irgendwann ist er fertig (und Du kannst eine Benachrichtigung einbauen oder einen Alarm bei Fehler und Maske mit Blick auf Fehlerprotokoll)

[p80286]

so richtig neu ist dieAnforderung ja nicht, die Lösung auch nicht.

Gruß
K-H

[jobo]

ot
Kennst Du Dich mit sowas aus?
Ich fand IBM schon immer faszinierend, wahrscheinlich weil ich nie ein solches System in den Fingern hatte.

[p80286]

Ich hab darauf das Laufen gelernt. SPF war ein starker Editor mit dessen Makros man richtig programmieren konnte (Zeilen und Spaltenorientiert). Nur wenn man es übertrieb (visualisierung) bekam man Ärger mit dem RZ Das waren halt echte Batch-Maschinen aber darin waren sie gut. Verglichen mit den 70/80 Jahren bringt jeder Aldi-Rechner mehr Hardware-Leistung mit. Aber die Software war besser (und wesentlich teurer) und die Handbücher noch richtig dick. Und trotzdem gab es damals schon die gleichen Probleme wie heute (welchen Zeichensatz versteht jetzt der Drucker nochmal?)
Es waren andere Zeiten aber genauso spannend wie Heute, und wer sich heute mit SAP oder Oracle herum schlägt der hat schon beinahe IBM-Feeling

Gruß
K-H