How to handle errors for semantic key with number range in RAP?

[fabianlupa]

Following scenario:

Managed RAP BO wit draft with managed numbering and UUID as key. In addition a semantic key should be generated by the system as a non-key field using a number range object. How do you do this correctly?

I tried using a determination on save and using number_get_next there. That works usually, but:

• In case of errors you can only report a warning in a determination using reported as there is no failed which the user can chose to ignore. According to the documentation (https://help.sap.com/docs/abap-cloud/abap-rap/determination-and-validation-modelling#failed-entries-...) you should store the error somewhere in a buffer and check for it in a validation.
• While that does work, in case of an error the save is blocked but also the number from the number range has still been picked since the LUW used in the determination is not rolled back? This results in a number gap.

I had a look at late unmanaged numbering but that only seems to be usable for the key field which in my case should still be managed numbering with UUID.

Is this scenario not covered or am I missing something?

[fabianlupa]

@Andre_Fischer maybe?

[fabianlupa]

Hm, a "late determination". Is there some keyword I do not know about? Can you share a link to the documentation, I could not find anything relevant searching for "late determination".

[wridgeu]

Hey Fabian, some time passed since you first raised this question and I've found myself to have this question too recently so I was wondering, were you able to find a reasonable conclusion or sort of acceptable workaround?

[fabianlupa]

@wridgeu Hi wridgeu, unfortunately I did not. I also didn't bother further asking here after getting the AI generated nonsense below. Even answering to your comment is cumbersome on this platform as the comment button is way at the top instead of next to your comment and I cannot even format the comment or see if the tagging works. But I digress...

[Sschlegel]

First of all: find the German Version here: Late Numbering für Non-Key-Fields

What WOULD be the best solution?

Here the AI is right: a LATE DETERMINATION (i.e., a determination AFTER validation) would be the way to success – unfortunately, this does not exist (although something similar might come one day).

What IS the best solution?

Well, tastes are known to differ, so depending on the use case, there is no single perfect solution, but in my opinion, there are 3 approaches (each with pros and cons):

1. UNMANAGED SAVE
2. ADDITIONAL SAVE (without EML)
3. ADDITIONAL SAVE (with EML)

What does this mean respectively? Let’s start with the explanation at bronze level and work our way up the ladder.

ADDITIONAL SAVE (with EML)

Here we would implement an ADDITIONAL SAVE, which runs in the late SAVE SEQUENCE – that is, after validation. However, at this point the entries are not yet persisted. So you would have to wait until this has happened... here the BgPF framework or a V2 poster could be used (although I don’t know whether it can even call EML?!?!?).
In this method, the new number is then drawn, and the object is changed or a change is triggered via an action in which the number is drawn. All this with EML.

Advantage

- It looks very professional because you are using a broad bouquet of new techniques...

Disadvantages

- Depending on the object, it may have a final, no-longer-changeable status based on the programming logic.
- Via EML we would go through the entire validation phase again, which can impact performance.
- This can also lead to effects in all directions, like determinations being executed AGAIN or similar.

ADDITIONAL SAVE (without EML)

We do the same as above, but instead of an EML call, the table entry is modified directly.

Advantage

It looks "dumber," but is significantly more robust due to less ping-pong through the RAP phases.

Disadvantage

Here we leave the RAP phases such as locking and similar. For example, before the number is reset, a new draft could be created (if the user clicks quickly or the application directly creates a new draft), which does not yet know the new number and simply deletes it from the database during save.

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 basically invites you to call "legacy APIs." But you can also write the changes into the database yourself based on the passed parameters such as CREATE, UPDATE, and DELETE – to avoid going through all hell during mapping, MAPPING FROM ENTITY helps here. But before writing, you quickly pull the desired number from the number range and put it into the field before writing.

If anyone asks why not change the values in ADDITIONAL SAVE via EML: In the late save phase, changing EML is **NOT** allowed because it would, in a way, jump out of the poster while it is running, as it would open a new interaction phase again.

Advantage

Exactly as intended by SAP: If the framework doesn’t do what you want, you can manually intervene here and be creatively flexible.

Disadvantage

You do updates directly on the database? I thought we were past that era, but apparently, you still need this druid knowledge in some places. Okay – besides my inner monk, there is another potential problem: If the object is extended with new entities, you must also consider these in the save method. This might not be a big deal in development but could drive some developer in the distant future to the brink of madness. Now bets can be placed: How often will this "UNMANAGED SAVE" be replaced by a regular save via the framework, only to find weeks or months later in production that "oh, something is broken now." In such cases, leaving comments in the code is highly recommended – the next generation will thank you! 😄

Conclusion

As the AI already knows by now, there is still no LATE DETERMINATION, so you have to find other ways, and I hope I was able to provide one or two thought-provoking approaches.

[fabianlupa]

Hi @Sschlegel, thanks for the response! I guess having transactional consistency (no object is actively persisted if the number picking fails) requires the unmanaged save. Which I would personally avoid when this is the only reason for it and a managed save would otherwise work just fine because of the complexity in the implementation.

[Attila]

It was definitely thought provoking 😁. In the scenario: ADDITIONAL SAVE (without EML), to solve the issue of losing the number, we could utilize the Shared Memory which is independent of the SAP LUW. We could place a central class there which gets the new number when we provide the UUID. This can be hooked in the SAVE_MODIFIED(additional save). At the same time the UUID-Number pair is cached in SHMA. When the new draft is created and sees, there is no number, askes for it. For the same UUID the cached number is returned. Using ADDITIONAL CLEANUP, or at some point later in time in mass using a timestamp, the UUID-Number pairs could be FREEd from SHMA. There is no SHMA access in the Cloud although 😄, and there is no working cl_numberrange_runtime=>number_check method on BTP  now 🤐 😁. There are still many walls we hit, smart pioneer developers risk they lives at customer side but finally solve it always as best they can 😊. This post is very useful and come from experience I hope no one misses this discussion and options before dealing with such. Otherwise many surprise can occur. Thanks for sharing all this useful information guys !

[umasaral]

In the context of the ABAP RESTful Application Programming (RAP) model, late determination refers to the execution of determinations during the save sequence, specifically at the end of a transaction when changes from the transactional buffer are  persisted to the database. This approach ensures that certain business logic or validations are applied just before the data
is saved, maintaining data integrity and consistency.

Key Aspects of Late Determination:

Timing: Late determinations are executed during the save sequence, after all modifications have been made but before the data is committed to the database.

Trigger Conditions: These determinations can be triggered by specific operations such as create, update, or delete, or by changes to particular fields.

Implementation: In the RAP handler method FOR DETERMINE within the local ABAP behavior pool, the business logic for the determination is implemented.

Benefits of Late Determination:

Data Consistency: Ensures that all necessary validations and business rules are applied just before data persistence, maintaining the integrity of the data.

Performance Optimization: By executing determinations at the end of the transaction, unnecessary computations during intermediate stages are avoided, potentially improving performance.

For more detailed information, you can refer to the following resources:

[RAP determination | ABAP Keyword Documentation] (https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/enUS/ABENBDL_DETERMINATIONS.html)

[ABAP RESTful Application Programming [24] – External Numbering and Managed Early Numbering – Discovering ABAP](https://discoveringabap.com/2023/03/02/abaprestfulapplicationprogramming24externalnumberingandmanage...)

These resources provide comprehensive insights into the implementation and advantages of late determinations within the RAP model.

Note:

https://community.sap.com/t5/technology-blogs-by-sap/determinations-in-abap-restful-programming-mode...

https://discoveringabap.com/2023/03/02/abap-restful-application-programming-24-external-numbering-an...

https://help.sap.com/doc/abapdocu_cp_index_htm/CLOUD/en-US/ABENBDL_DETERMINATIONS.html

[fabianlupa]

Most of your links do not work and your answer looks AI generated to be honest. I still don't see how a "late" determination would be classified as such instead of a normal determination.