cl_rest_http_client GET - Communication Failure

[Deon_van_Zyl]

Hi,

I have an interesting error which I am not sure how to solve. I am calling an API with HTTP REST Service with a GET request. If I run my program as is, I get a communication failure from CL_REST_HTTP_CLIENT-IF_REST_RESOURCE~GET. If I put a debug point on my method call, the GET request works perfectly and I get a status 200 back with a response. The only difference is that I enter debug mode, nothing else changes. Without debug, I get a communication failure, with debug, I get response 200 and everything works perfectly.

I get see the the communication failure happens in CL_REST_HTTP_CLIENT-SEND_RECEIVE when it does the CALL METHOD mo_http_client->receive. When I try to debug the method, then I don't get the communication error anymore 😞

Any suggestions? I have tried to do a commit and wait before the HTTP Get and Wait up to 10 seconds but that makes no difference.

* Create REST client instance
    CREATE OBJECT lo_rest_client
      EXPORTING
        io_http_client = go_http_client.


    "/--- Do HTTP GET Request ---/"
    TRY.


        lo_rest_client->if_rest_client~get( ).


      CATCH cx_rest_client_exception INTO DATA(lo_exc).
        lv_message = lo_exc->get_text( ).


        CALL METHOD send_mail EXPORTING iv_message = lv_message.


        WRITE:/ 'HTTP Connection Error: ', lv_message.


        EXIT.


    ENDTRY.

Kind Regards
Deon

[FredericGirod]

Could be a response time

Did you try to check the SMICM trace ?

[michael_piesche]

>> If I put a debug point on my method call, the GET request works perfectly and I get a status 200 back with a response.

a) Have you tried a "WAIT UP TO sec SECONDS." statement before that call? Does it work then?

If something works in debug mode but not in a normal dialog or background mode, it is mostly related to 'parallel processes' (e.g. something written to DB or file and later read from DB or file), where the secondary process is slower than the main process. By setting the debug mode, you give the parallel process enough time to catch up. This is just a thought though. With WAIT UP TO sec SECONDS (e.g. 1 or 2 seconds maybe even 5 seconds), this could be confirmed, that it is not primarly due to the Debug mode. If you dont mind waiting a short amount of time, this could also be a somewhat 'acceptable' solution.

• Can you think of anything that might run in parallel in your coding?
• Can you post the entire error message, including the id and number of the error?

b) Have you tried to set a breakpoint just after the statement when the error occurs? (e.g. in CALL METHOD mo_http_client->receive.) I assume you will not be able to debug into 'getting' the error but only after the error already occurred, right?

[Deon_van_Zyl]

Hi Frederic/Michael,

My first thoughts was parallel processing. I have tried wait up to 20 seconds and it makes no difference. When i do a debug it much quicker than that.

I did look at SMICM but did not see anything funny. I am not sure if you can limit the log a specific HTTP call?

The response I am getting is quite big so my gut feeling is that is must something regarding that with something that is timing out. But then why won't the "Wait up to sec Seconds" then work? Debug must do something else differently then.

I did try to debug but it is difficult because I have to trigger the breakpoint after error occurred otherwise it goes through successfully (haha.. urg).. I have tried everywhere it throws an communication error exception in IF_HTTP_CLIENT~RECEIVE but the breakpoints does not trigger. I am trying random breakpoints at this point to get the exact point.

Any other suggestions?

Kind Regards

Deon

[Deon_van_Zyl]

BASIS increased the HTTPS timeout and it now it works. I am still not sure why the "WAIT UP TO sec SECONDS" worked but at least it is working now 🙂

[Deon_van_Zyl · Accepted solution]

BASIS increased the HTTPS timeout and it now it works. I am still not sure why the "WAIT UP TO sec SECONDS" worked but at least it is working now 🙂