on 2023 Feb 01 10:54 AM
Hello All,
I have implemented precheck during creation operation in the behavior definition, and want to achieve the following functionality:
1. While creating a new entry to a table, check if the entry is already present.
2. If present, give a error message mentioning "Entry already present, do you want to overwrite"?
3. If user still click on create after the error, then delete the old entry and create the new entry / or modify the existing entry.
I was able to achieve the functionality of step 1 and 2, but unable to figure out the way to capture the error, when user clicks on 'create' button again.
Is there any way that I can achieve this?
This probably requires some UI coding.
The typical Fiori Elements UI orchestration sends a "Prefer: handling=strict" header with the first request. The backend precheck would raise a warning message (not an error and no failed key) in case of a conflict. This results in a http=412 precondition failed, which is recognized by the UI and a confirmation popup with the warning message is shown.
When you confirm this, a "Prefer: handling=lenient" header is sent and the processing continues.
Problem is, that your precheck implementation does not know about the http header sent by the client (which on the other hand is good, because in a stateless protocol you don't know if the first call has ever happened...). So the precheck will throw the warning again, which is then sent along with the http 200 response to the client. So you probably need some UI code on the client to suppress the second message.
Best Regards,
Volker
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks volker.drees for this detailed answer. It helped me overcome a different issue I was facing. In my case I accidentally forgot to remove the failed key when I converted the message I was reporting from 'error' to 'warning'. This caused the confirmation popup message dialog at draft activate action not appearing as the response code was 400 instead of 412. Then your comment helped me lead to the right direction. I removed the code for assigning the failed key and the confirmation dialog appeared as expected.
Best regards,
Sumit
Hello Ana Morozova,
We were using one more additional primary key field as version, so that even though we have a same entry in the backend, we will keep the version number as different and save the values.
Ideal way of generating entries with same key combination, please use the concept of
Please have a look into this blog:
Regards,
Naga
User | Count |
---|---|
80 | |
11 | |
10 | |
10 | |
10 | |
8 | |
8 | |
7 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.