Ich habe mir gerade mal überlegt, ob dieser Workflow an dieser Stelle hilfreich wäre. Wie es aussieht scheint ja das Problem zu sein, dass die TSE-Daten nicht korrekt abgespeichert werden können weil mit der DB irgendwas ist. Also wird ein Rollback durchgeführt, richtig? Damit besteht ja immer das Problem, dass die TSE-Daten nicht ankommen.
Um eine langlaufende Transaktion zu vermeiden, könnte man so vorgehen. Auch die TSE-Daten gehen nicht verloren.
1. Bestellung wird in die DB committed.
2. Das TSE wird für die Signatur angesteuert und eine ID mitgegeben.
3. Der TSEConnector signiert und speichert die Daten temporär in eine Datei mit der mitgegeben ID.
4. Die TSE-Daten werden in der DB hinzugefügt.
5. Dem TSEConnector wird bestätigt, dass die ID gespeichert wurde.
6. Der TSEConnector löscht die temporäre Datei.
Nun kann gut unterschieden werden, ob die TSE-Daten noch nicht in der DB hinterlegt wurden oder noch gar nicht beim TSE angekommen sind.
Fehlen die TSE-Daten, kann dies in der DB erkannt werden und mittels der ID die TSE-Daten beim TSEConnector erneut abgefragt werden. Dazu braucht es natürlich eine weitere API im Connector, dass die ID erwartet. Somit kann man die TSE-Daten mehrfach abholen bis bestätigt wurde, dass sie gesichert wurden. Kennt der TSEConnector die ID nicht, wurden die Daten noch gar nicht signiert.
Was meinst du? Sinnvoll für Ordersprinter? Kenne das darunterliegende System nicht wie Ordersprinter agiert.
Eventuell könnte man noch einen Admin-Checker einbauen, ob es Lücken beim TSE-Counter gibt um rechtzeitig Alarm zu schlagen, dass irgendwas hief läuft.
Viele Grüße
André
Ich habe mir gerade mal überlegt, ob dieser Workflow an dieser Stelle hilfreich wäre. Wie es aussieht scheint ja das Problem zu sein, dass die TSE-Daten nicht korrekt abgespeichert werden können weil mit der DB irgendwas ist. Also wird ein Rollback durchgeführt, richtig? Damit besteht ja immer das Problem, dass die TSE-Daten nicht ankommen.
Um eine langlaufende Transaktion zu vermeiden, könnte man so vorgehen. Auch die TSE-Daten gehen nicht verloren.
1. Bestellung wird in die DB committed.
2. Das TSE wird für die Signatur angesteuert und eine ID mitgegeben.
3. Der TSEConnector signiert und speichert die Daten temporär in eine Datei mit der mitgegeben ID.
4. Die TSE-Daten werden in der DB hinzugefügt.
5. Dem TSEConnector wird bestätigt, dass die ID gespeichert wurde.
6. Der TSEConnector löscht die temporäre Datei.
Nun kann gut unterschieden werden, ob die TSE-Daten noch nicht in der DB hinterlegt wurden oder noch gar nicht beim TSE angekommen sind.
Fehlen die TSE-Daten, kann dies in der DB erkannt werden und mittels der ID die TSE-Daten beim TSEConnector erneut abgefragt werden. Dazu braucht es natürlich eine weitere API im Connector, dass die ID erwartet. Somit kann man die TSE-Daten mehrfach abholen bis bestätigt wurde, dass sie gesichert wurden. Kennt der TSEConnector die ID nicht, wurden die Daten noch gar nicht signiert.
Was meinst du? Sinnvoll für Ordersprinter? Kenne das darunterliegende System nicht wie Ordersprinter agiert. :-)
Eventuell könnte man noch einen Admin-Checker einbauen, ob es Lücken beim TSE-Counter gibt um rechtzeitig Alarm zu schlagen, dass irgendwas hief läuft.
Viele Grüße
André