setHttpTimeout(milliseconds) : what is the maximum value we can pass into this method?

[ARG645]

Hello All,

I was told that "Integration session for a " single http request" can only stay alive for maximum 30 mins. This value is hard-coded and not configurable.

Does this mean for the setHttpTimeout method, the parameter we pass is limited to "1800000" Milliseconds (30 minutes)

Example Code:

var sm = new sn_ws.RESTMessageV2("<REST_message_record>","get"); //Might throw exception if message doesn't exist or not visible due to scope.
sm.setHttpTimeout(1800000);//Is this Wrong ?

We have a scheduled Job that makes an Outbound Rest API call, and we need this API call to be synchronous and alive for more than 30 minutes. 

Any help is greatly appreciated. 

[sachin_namjoshi · Accepted solution]

You can increase timeout with below system property

glide.rest.outbound.ecc_response.timeout

Alternatively, use the "waitForResponse" property to overwrite the glide.rest.outbound.ecc_response.timeout value on the REST message call.

E.g.:

var sm = new sn_ws.RESTMessageV2(SLOW_REST_MESSGE,"get");
var response = sm.executeAsync();
response.waitForResponse(20);

Regards,

Sachin

[Deepak Ingale1]

Hi Aman,

Better way to perform this would be to use executeAsync method and let MID server and ECC queue take care making a call and returing the response. This will prevent the instance thread or semaphore getting blocked for "n" amount of seconds unncessarily. 

We have done this several times by using MID server where single call of ours was expected to take around 10 - 12 minutes.

You can use setEccParameter() method to pass on your "custom" XML tag and write a sensor script ( business rules on ECC queue table ) to parse the response and correlate back based on this customer parameter. You have to make BR conditional for your TOPIC ( Please see BRs on ECC Queue for more information )

https://community.servicenow.com/community?id=community_question&sys_id=49a70fa9db1cdbc01dcaf3231f961935&view_source=searchResult

[ARG645]

Deepak thank you for the response, how ever we are not using Mid Server in this integration.