Fakturierungsserver

[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

[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.

[jobo]

Zitat von p80286:

..oder Oracle herum schlägt der hat schon beinahe IBM-Feeling

Das kenne ich ja, aber (alte) IBM stelle ich mir irgendwie noch anders vor.

[p80286]

[ot]
Ja klar IBM war Großrechner und MIDI-Rechner, 3270 und Token Ring, Festplatten,Monitore und Drucker und Betriebssysteme, Datenbanken und Textverarbeitung, Disketten und Tastaturen und Compiler und Interpreter
und Schreibmaschinen und Kopierer.
Und die eine oder andere (informelle) Norm.
Und das wichtigste "Niemandem wurde gekündigt weil er IBM gekauft hat"

Gruß
K-H
[/OT]

[psycodad]

Hallo an alle,
Vielen Dank für eure Anregungen/Meinungen. Ich werde mich mal daran machen einen Prototyp zu bauen und verschiedene Sachen auszutesten.