The following texts were partially or completely generated with the help of generative AI models.
How it all began...
A few days ago, Marco Beier pointed me to the post How to handle errors for semantic key with number range in RAP? and asked me for a good solution. To make it clear for everyone: There is NO LATE DETERMINATION, no matter how often ChatGPT or its "power users" claim otherwise. So what options do you have here?
Where is the problem?
In this case, a number is supposed to be drawn from a number range object, which is a classic case for late numbering. BUT in this case it is NOT a key field, and therefore late numbering - which you need for key fields - is off the table.
Why don't you simply draw a number in a DETERMINATION ON SAVE?
The validation only comes AFTER the determination, AND should it run into an error AND the user does not know how to proceed AND discards the draft, then the number drawn from the number range is used up and gaps are created, which is undesirable in many scenarios.
What WOULD be the nicest solution?
Here the AI is right: A LATE DETERMINATION (i.e. a determination AFTER the validation) would be the way to success - unfortunately it does not exist (even if something similar may come one day).
What IS the nicest solution?
Well: tastes differ, as we all know, so depending on the use case there is THE perfect solution, but in my opinion there are 3 approaches (with pros and cons)
- UNMANAGED SAVE
- ADDITIONAL SAVE (without EML)
- ADDITIONAL SAVE (with EML)
What does each of these mean? Let's start the explanation at bronze and work our way up the podium.
ADDITIONAL SAVE (with EML)
Here we would implement an ADDITIONAL SAVE, which is run in the late save sequence - i.e. after the validation. But at that point the entries are not yet persisted. So you would have to wait until this has happened... this is where the BgPF framework or a V2 update comes in handy (although I'm not sure whether the latter can even call EML?!?!?). In this method, the new number is then drawn and the object is changed, or it is changed via an action in which the number is then drawn. All of this with EML.
Advantage
- It looks very professional, since you draw on a broad bouquet of new techniques...
Disadvantage
- Depending on the object, it may - based on the programming logic - have a final status that can no longer be changed.
- Via EML we would run through the entire validation phase again, which can definitely cost performance.
- Here there may then be effects in all directions again, such as determinations being executed AGAIN or similar.
ADDITIONAL SAVE (without EML)
We do the same thing as above, but instead of an EML call, the table entry is modified directly.
Advantage
It may look "dumber", but it is considerably more robust, since there is less ping-pong through the RAP phases.
Disadvantage
Here we leave the RAP phases, such as locking and the like. For example, a new draft can be created even before the run that sets the new number (if the user clicks quickly or the application directly creates a new draft), which then does not yet know the new number at all. And when saving, it is simply deleted from the database again.
UNMANAGED SAVE
Here we come to the "best" approach - the UNMANAGED SAVE. Even in a managed scenario you can be equipped with an UNMANAGED SAVE, which actually invites you to call "legacy APIs". But you can also use the passed parameters such as CREATE, UPDATE and DELETE to write the changes to the database yourself - and so you don't go through all the hells directly with the mapping, MAPPING FROM ENTITY helps here. But before writing, you quickly draw the desired number from the number range and put it into the desired field before writing.
If anyone is wondering why not change the values via EML in the ADDITIONAL SAVE: In the late save phase, modifying EML is NOT permitted, since with it you would in a certain way jump out of the update again while it is running, because you would open a new interaction phase again.
Advantage
This is exactly how SAP intends it: If the framework does not do what you want, then you can intervene manually here and let your imagination run wild.
Disadvantage
You do updates directly on the database? I thought we were past that age, but as it looks you still need this druid knowledge in some places. Ok - besides my inner monk there is another potential problem: If the object is extended with new entities, you have to take these into account in the save method as well. Which may not be a big deal during development, but can drive some developer in the distant future to the brink of insanity. And now you may already place your bets: How often will the "UNMANAGED SAVE" be replaced by a regular save via the framework, so that weeks and months later in production you realize "oh, but now something is broken". In such cases, feel free to leave comments in the code - the next generation will thank you! :-D
Conclusion
As the AI now knows by now, there is still no LATE DETERMINATION, so you have to find another way to help yourself, and I hope I was able to provide one or two food for thought.
