Ansatz für WaWi-Registrierung

Hallo.

Ich möchte in einem OXID-Shop eine Bestandsprüfung und Registrierung bei einem WaWi umsetzen und zwar soll das nach dem Klick auf “Kostenpflichtig bestellen” ansetzen und nach erfolgreicher Bezahlung soll dann die Bestellung an eben dieses WaWi bekannt gemacht werden.

Ich bin in OXID noch nicht so bewandert und die Payment-Module, die ich hier vorliegen habe, sind alle closed source, darum frage ich Euch, ob mein Ansatz so gescheit ist:

Anscheinend wird dieses letzte Formular (vom Payment abgesehen) an order::execute() gesendet. Dieser Wert wird jedoch von den oder einigen(?) Payment-Modulen überschrieben. Jetzt denke ich, wäre es gescheit im Template fnc auf eine eigene order-Methode (sagen wir order::registerOrder()) zu setzen und den ursprünglichen Wert des Hidden-Field fnc (Rückgabewert von getExecuteFunction() oder so) als weiteren Parameter (z.B. originalFnc) zu übergeben.

Da die Methode order::execute() jedoch auch z.B. prüft, ob die AGB-Checkbox gesetzt ist, muss ich einiges an Code aus dieser Methode in order kopieren, dort dann die Registrierung beim WaWi machen und einen internen forward auf die ursprüngliche Execute-Funktion machen ($_POST[‘originalFnc’]).

Für die abschließende Behandlung der Bestellung würde ich \oxOrder::finalizeOrder() überschreiben, die Parent-Funktion aufrufen und bei Erfolg die Bestellung durchgeben. Alternative wäre, die onOrderExecute()-Methode des Benutzer-Objektes, aber die wird unsinnigerweise im Controller (bzw. View heißt es in OXID ja) aufgerufen und nicht im Model, wo sie hingehören würde. Auch hat der Zugriff auf das WaWi ja nichts mit dem User zu tun, also wäre es dort eh nicht gescheit aufgehoben.

Könnt Ihr mir mit Eurer Erfahrung sagen, ob das so hinhauen wird oder ob es vielleicht irgendwelche Payment-Module gibt, mit denen diese Lösung nicht funktionieren wird.

Ein Haken ist natürlich, dass sich diese Registrierung umgehen lässt, indem man einen Post-Request an die Original-Funktion absetzt, aber welcher Hacker würde schon ein System so umbiegen, dass er zwar bezahlen muss, die Lieferung bei ihm aber nicht ankommen wird.

Meinst du nicht du tust dir viel leichter wenn du einen cron job baust der die oxorder Tabelle überwacht? Wenn es sehr zeitnah sein soll dann muss der cron halt alle Minute laufen. Ich bin mir ziemlich sicher dass einige Module sich nicht mit dieser Methode vertragen - und ein cron deckt alles ab, egal woher die Bestellung kommt.

Danke für diese Idee.

Ein Cronjob wird später laufen, um alle paar Minuten fertige Bestellungen ans WaWi zu schicken. Aber die Registrierung muss zwingend vor dem Payment-Prozess erfolgen, da der Kunde auch auf einem hochfrequentierten Shop verkauft und der Lagerbestand im OXID-Shop entsprechend nicht sehr genau sein wird.

Ich bin mir ziemlich sicher dass einige Module sich nicht mit dieser Methode vertragen

Was genau für Probleme siehst Du da?

Naja, was machst du wenn ein Modul direkt auf der Datenbank Tabelle arbeitet? Wird das dann einfach nicht unterstützt? Ich glaube da gibt es mehrere die das nicht machen, deswegen die Sache mit dem Cron.

Du meinst, das Modul würde die finalizeOrder-Methode gar nicht aufrufen, sondern die Bestellung direkt selbst durchführen. Wüste Vorstellung…

deswegen die Sache mit dem Cron.

Ja, für die endgültige Bestellabwicklung wird es ja eh einen Cronjob geben. Nur die Reservierung kann man natürlich nicht mit einem Cronjob machen, eh klar. Aber stimmt, letztlich brauche ich nur einen Ansatzpunkt für die Reservierung, denn ich muss diese weder aufheben, noch muss ich nach erfolgreicher Bestellung noch etwas tun, außer diese dann im cron-job aus der DB auszulesen, wie es ja eh geplant war.

Spricht denn irgend etwas gegen den Ansatzpunkt für die Reservierung?

Ich glaube es sollte dann schon klappen, wenn nicht wirst du es schon merken :smiley: Nein, mal ehrlich ich persönlich sehe jetzt nichts was dagegen spricht.

Danke für Deine Hilfe!