Erstellen von Quartz Jobs pro Aufgabe oder zusammenfassen

[OnDemand]

Hallo ihr Lieben,

ich spamme grad ganz schön das Forum zu..Sorry falls es wen nervt Hilft mir aber grad ungemein, hab keinen Entwicklerkollegen den ich nerven kann 🥲

Folgende Situation:

Ein Import-Service importiert Daten:
- legt neue Datensätze an
- updated Attribut X eines Datensatzes
- updated Attribut Y eines Datensatzes
- updated Attribut Z eines Datensatzes

Wenn es zu einer Änderung kommt (x ist von Wert 0 auf 10 gestiegen zb) wird diese Änderung in eine History-Tabelle gespeichert. Kann man sich so vorstellen als hätte man eine Lagerverwaltung, eine Bestellung kommt rein, reduziert Audi A3 von Bestand 5 auf 4.

Nun kommt ein anderer Service, holt die Historien ab. Der Service hat nun eine Liste mit tausenden Änderungen (Preise der Autos haben sich verändert, Bestände der Autos haben sich verändert usw)

Diese Änderungen müssen nun an ein Programm geschickt werden, welches neue Fahrzeuge produziert (da ja der Audi A3 1 mal verkauft wurde zb).

Nun hab ich verschiedene Ansätze:

1. Ein Listener der hört "ah ein Bestand wurde geändert > holen > an die Produktion senden damit die ein neues Auto bauen"
2. Alle Historien erstmal sammeln, wenn der Import fertig ist triggerd der den Exporter an "hole alle Änderungen und sende diese an die Produktionsfabrik"
3. Alle Historien erstmal sammeln, wenn der Import fertig ist triggerd der den Exporter an "hole alle Änderungen und sende diese an die Produktionsfabrik" und erstellt für jeden Änderungseintrag einen Job, der in einen Scheduler kommt und dann nach und nach abgearbeitet wird.

1. fällt nahezu aus, da die "Fabrik-API" Limits hat. Zb nur 2 Calls pro Sekunde. Wenn da dann pro Änderun g drauf los gedonnert wird, gibts nur Error-Requests
2. ist die aktuelle Variante, es werden zb erst alle Bestandsänderungen geholt und nach und nach an die Fabrik geschickt, dannach werden die Preisänderungen geholt und an die Fabrik geschickt usw.
3. War jetzt so ein Einfall. Jeder Job ist dann erfolgreich oder auch nicht > das kann man vernünftig loggen, den Fehler beheben und ggf. den Job neu starten

Hat jemand so etwas in der Art schon mal gehabt oder Verbesserungsvorschläge/Input?

 

[Dukel]

Eine History ist für mich etwas anderes. Darauf möchte ich nichts machen.

Wenn ein Prozess etwas macht dann soll sich dieser bei dem nächsten (neuen A3 herstellen) melden oder es meldet sich der Hersteller Prozess bei diesem und fragt nach offenen Aufgaben.

Man kann dies z.B. mittels eines Brokers machen.
Import Prozess schreibt in den Broker. Hersteller abonniert die Meldung, wenn Autos verkauft werden.

 

[mihe7]

@NicoDeluxe hört sich für mich nach einer Art Event Sourcing an. Wie auch immer: könntest Du die Dinge nicht einfach vollständig voneinander trennen? Auf der einen Seite wird bestellt. Die Bestellungen werden notiert. Auf der anderen Seite wird produziert. Hat die Produktion freie Kapazitäten, holt sie sich die nächsten Bestellungen ab.

 

[OnDemand]

Die Ziel API kann nur Empfangen (sind unternehmensfremd). Problem ist, dass es pro 5 Minuten zu 50.000 Änderungen kommen kann die dann an die externe API gesendet werden. Die API erlaubt aber nur 2 Aufrufe pro Sek. Also muss erstmal alles irgendwo gesammelt werden und abgearbeitet werden.
Die Änderungen werden als Historie benutzt um zu sehen was sich wann geändert hat. Einen Broker hab ich auch schon im Einsatz gehabt, aber noch ein System mehr zu warten, wenn es eine Tabelle auch tut hmm

 

[mihe7]

Die Ziel API kann nur Empfangen (sind unternehmensfremd). Problem ist, dass es pro 5 Minuten zu 50.000 Änderungen kommen kann die dann an die externe API gesendet werden. Die API erlaubt aber nur 2 Aufrufe pro Sek. Also muss erstmal alles irgendwo gesammelt werden und abgearbeitet werden.

Dann entspricht in meinem Beispiel der "Exporter" der Produktion: der Exporter holt sich die Bestellungen ab (und schickt sie an die API), sobald er wieder Kapazitäten hat. Der Unterschied besteht hauptsächlich darin, dass hier nicht auf jedes Event reagiert wird/werden muss, sondern der Spaß von der anderen Seite (Exporter) aus "gesteuert" wird.

 

[OnDemand]

Joa also so wie ich es jetzt habe (2. Alle Historien erstmal sammeln, wenn der Import fertig ist triggerd der den Exporter an "hole alle Änderungen und sende diese an die Produktionsfabrik")

Nur muss der Exporter irgendwie ne Info bekommen wann er loslegen soll. Das am Besten nach dem die Daten updated sind. Dann ist es ja wie es jetzt ist nicht falsch

 

[mihe7]

Dann ist es ja wie es jetzt ist nicht falsch

Nein, falsch ist es nicht. Ich dachte nur, vielleicht wird es einfacher, wenn der Exporter selbständig abruft.

 

[OnDemand]

Achso meinst du, dass er nicht getriggered wird. Joa.

Man könnte auch einen "Bestandjob" erstellen welcher alle 5 Minuten schaut ob es Änderungen gibt und diese holt und weiter reicht. Das macht sich glaube sehr gut.