Wie alles begann...
Vor einigen Tagen wurde ich von Marco Beier auf den Post How to handle errors for semantic key with number range in RAP? aufmerksam gemacht und nach einer guten Lösung gefragt. Um es für alle klar zu stellen: Es gibt KEINE LATE DETERMINATION, egal wie häufig ChatGPT oder dessen "Power-User" das behaupten. Also was hat man hier für Möglichkeiten?
Wo ist das Problem?
In diesem Fall soll eine Nummer aus einem Nummernkreisobjekt gezogen werden, was ein klassischer Fall für ein Late Numbering ist. ABER in diesem Fall handelt es sich NICHT um ein Key-Feld und damit ist das Late Numbering - was man ja für Key-Felder benötigt - raus.
Wieso zieht man sich nicht einfach eine Nummer in einer DETERMINATION ON SAVE?
Die Validierung kommt erst NACH der Determination UND sollte diese auf Fehler laufen UND der User nicht weiter wissen UND den Entwurf verwerfen, dann ist die gezogene Nummer aus dem Nummernkreis verbraucht und es entstehen Lücken, was in vielen Szenarien unerwünscht ist
Was WÄRE die schönste Lösung?
Hier hat die KI recht: Eine LATE DETERMINATION (also einer Determination NACH der Validation) wäre der Weg zum Erfolg - leider gibt es diese nicht (auch wenn etwas ähnliches vllt eines Tages kommt).
Was IST die schönste Lösung?
Nunja: Geschmäcker sind bekanntlich verschieden, daher gibt es auch je nach Use-Case DIE perfekte Lösung, aber m.E. gibt es 3 Ansätze (mit Vor-und Nachteilen)
- UNMANAGED SAVE
- ADDITIONAL SAVE (ohne EML)
- ADDITIONAL SAVE (mit EML)
Was bedeutet das jeweils? Fangen wir mit der Erklärung mal bei Bronze an und arbeiten uns die Treppchen hoch.
ADDITIONAL SAVE (mit EML)
Hier würden wir ein ADDITIONAL SAVE implementieren, welches in der späten SAVE SEQUENCE - also nach der Validation - durchlaufen wird. Da sind aber die Einträge noch nicht persistiert. Also müsste man warten, bis dies geschehen ist... hier bietet sich das BgPF-Framework oder ein V2-Verbucher an (wobei ich bei diesem nicht weiß, ob dieser überhaupt EML aufrufen kann?!?!?). In dieser Methode, wird dann die neue Nummer gezogen und das Objekt geändert oder über eine Aktion zur Änderung gebracht, in welcher dann die Nummer gezogen wird. All dies mit EML.
Vorteil
- Es sieht sehr professionell aus, dann man auf einen breiten Blumenstrauß neuer Techniken zugreift...
Nachteil
- Je nach Objekt, kann es vllt. anhand der Programmierlogik einen finalen, nicht mehr änderbaren Status haben.
- Wir würden über EML nochmal durch die komplette Validation-Phase laufen, was durchaus Performance kosten kann.
- Hier kann es dann ggf. auch nochmal zu Auswirkungen in alle Richtungen kommen, wie Determinations die NOCHMAL ausgeführt werden oder vergleichbares.
ADDITIONAL SAVE (ohne EML)
Wir machen das gleiche wie oben, aber anstatt eines EML-Aufrufs wird direkt der Tabelleneintrag modifiziert
Vorteil
Sieht zwar "dümmer" aus, aber ist erheblich Robuster, da weniger Ping-Pong durch die RAP-Phasen.
Nachteil
Hier verlassen wir die RAP-Phasen, wie Sperren und ähnliches. Zum Beispiel kann noch vor dem Durchlauf des neu setzens der Nummer ein neuer Draft erzeugt werden (wenn der Anwender schnell klickt oder direkt die Anwendung einen neuen Draft erzeugt), welches dann die neue Nummer noch gar nicht kennt. Und beim Speichern einfach wieder aus der Datenbank löscht.
UNMANAGED SAVE
Hier kommen wir zu "besten" Ansatz - dem UNMANAGED SAVE. Auch in einem Managed Scenario kann man mit einem UNMANAGED SAVE ausgestattet werden, was eigentlich dazu einlädt "Legacy APIs" aufzurufen. Man kann aber auch anhand der üebrgebenen Parameter wie CREATE, UPDATE und DELETE selbst die Änderungen in die Datenbank schreiben - damit man nicht mit dem Mapping direkt alle Höllen durchläuft hilft hier MAPPING FROM ENTITY. Aber vor dem Schreiben, zieht man sich noch eben schnell aus dem Nummernkreis die gewünschte Nummer und gibt diese in das gewünschte Feld bevor geschrieben wird.
Wenn sich jemand Fragt, wieso nicht im ADDITIONAL SAVE die Werte per EML ändern: In der späten Save-Phase ist änderndes EML NICHT zulässig, da man damit auf gewisse Art und Weise aus dem Verbucher wieder raus springen würde, während er läuft, da man ja wieder eine neue Interaction-Phase aufmachen würde.
Vorteil
Genau so ist es von der SAP gedacht: Wenn das Framework nicht das tut was man will, dann kann man hier manuell eingreifen und sich fantasievoll austoben.
Nachteil
Man macht Updates direkt auf der Datenbank? Ich dachte aus dem Alter sind wir raus, aber wie es aussieht braucht man dieses Druidenwissen doch noch an manchen stellen. Ok - nebst meinem inneren Monk gibt es noch ein anderes, potentielles Problem: Wird das Objekt um neue Entitäten erweiter, muss man in der Save-Methode diese ja ebenfalls berücksichtigen. Was vllt. in der Entwicklung kein großes Thema ist, aber irgend einen Entwickler in ferner Zukunft an den Rande des Wahnsinns bringen kann. Und jetzt dürfen schon Wetten abgeschlossen werden: Wie häufig wird das "UNMANAGED SAVE" wohl durch ein reguläres Save übers Framework ersetzt werden, damit man dann Wochen und Monate später in der Produktion feststellt "oh, da ist jetzt aber was kaputt". In solchen Fällen darf man gerne Kommentare im Code hinterlassen - die nächste Generation wird es einem Danken! :-D
Fazit
Wie die KI mittlerweile schon weiß, gibt es noch immer keine LATE DETERMINATION, also muss man sich anders zu helfen wissen und ich hoffe, dass ich den oder anderen Denkansatz liefern konnte.
