Reputation: 1
We are working on an SAP ICF Service (HTTP), which allows mobile devices to call function modules via an XML interface.
The given XML contains data about what function module to be called and what parameters have to be used.
Whenever the function module finishes, the result is sent back to the mobile device. We are using an IF_HTTP_EXTENSION
handler.
The issue is, that, whenever the function module takes a long time to run, the mobile device runs into a timeout and then closes the connection, re-connects and re-sends the request.
Whenever this happens, the handle_request
method of the IF_HTTP_EXTENSION
handler immediately terminates.
But we need to continue the execution of the called function, as the client resends the request with the same sequence number.
So we do not call the actual function twice, but a "waiting"-method, which waits for the previously invoked function to complete.
We do this by checking the database on a regular basis (WHILE
loop with WAIT UP TO 2 SECONDS
in each iteration).
As long as the client does not timeout, we want to send the response as soon as possible. Therefore in the first request it is not appropriate to do a while loop with 2 seconds delay.
Our current approach is the following (in handle_request
):
CALL FUNCTION 'CLIENT_DESIRED_FUNCTION'
STARTING NEW TASK l_client_id
CALLING processing_finished ON END OF TASK
EXPORTING
...
After this, we wait for its completion by:
WAIT UNTIL a_running <> 'X'.
But, as soon as the client disconnects, the called function (and the handle_request
method as well) terminates.
When we remove the CALLING processing_finished ON END OF TASK
, the function actually continues!
This is our desired behavior. However, now, there is no way to wait for the function to complete, as the WAIT UNTIL
statement returns with sy-subrc = 4
(No async rfc function calls).
We could just use a simple WHILE
-WAIT UP TO 2 SECONDS
-loop, but then we have the delay, which we really want to prevent.
Another solution we thought about, was to send an HTTP Code 102 to the client, just before the timeout occurs. But this is not a good solution, as the mobile device could be without network and then does not receive the 102 in time.
Is there a way to prevent SAP ICF from terminating the handle_request
method OR is it possible to efficiently wait for the async task without using the CALLING ... ON END OF TASK
parameter?
Kind regards, Tobias
Upvotes: 0
Views: 650
Reputation: 742
I don't have the code at hand, but I have solved this issue before when SAP Gateway wasn't around and you had to build your own REST services.
I used a timeout for the processing of 2 seconds. After that time, the server must reply with something. If the processing isn't finished (using the async function module), the server responds with HTTP Status 202 Accepted. The client may then send another request at a later time, asking for status of the previous request.
This pattern worked very well. The frontend developer used a async model for all requests, creating an application that never had delays even if response times in SAP did vary. As an example, committing a Sales Order during peak hours could take 1 to 15 seconds.
Upvotes: 0