Wait for response from ui in ABAP Odata

0
votes

I am trying to make an ABAP OData, that receive a request, does some calculation, then, should return a message to the End User and make an decision based on the user input. So basically, the OData service should be put "on hold", before its receives a response.

Does anyone have a good idea?

Appreciate your response. Regards!

1
odatasapui5
As far as i know this is not possible. You could split the task in 2 separate requests. 1. Calculate request 2. User Action 3. Process user action I think you requirements sounds more like a Remote Enabled RFC Function Module would be the better choice. Hope that helps. – Beka
Hey Beka. Thanks for your reply. 2 separate request is an option, but that means, same payload to be sent twice. So I was kinda looking for another option. – KranzFafka
maybe you can explain your request a little bit more. in one request this won't be possible due to asynchrone handling of NW Gateway. Would SuggestionHelp/LiveValues help? It is like a value help when a user types he receives auto-suggestion values (this suggestion can be bound to an odata service). If your calculation is fast enough, you could suggest values according to the input of the user. Might this help? – dotchuZ
So, from UI part I will make a request with a payload. The payload is processed in the back-end part. After some processing, the back-end should make a decision, either delete or not some entries. The decision should be done based on a decision made by user. So the back-end should send back to UI a message, and wait for its response, without loosing the data from the process. So no Suggestion Help works here. – KranzFafka

1 Answers

0
votes

OData is a special kind of REST. REST is stateless. What you want is stateful.

The good way to do turn this stateful flow into a stateless one is:

Send a first request (REST: POST, OData: CREATE) that creates and saves(!) a document that represents the calculation and its result. That first request may return the calculation's result to be presented to the user.

The user's choice then sends a second request that addresses the previously created document (e.g. via a GUID) and includes the user's choice. This means the second request neither has to send the computation input again, nor does it actually perform any calculations; it only changes the existing object's state.

If the calculation is not needed anymore afterwards, that second request may delete it. To prevent data leakage, removing older calculations after a time limit (e.g. 24h) may be a wise move.