Outbound REST through MID Server - saveResponseBodyAsAttachment error

[matt_kean]

Any help?  I am doing an outbound REST call through my MID Server to get user pictures. I can verify that I get a successful response until I add a saveResponseBodyAsAttachment statement to my script.  With that statement I always get the following error:

-  java.net.SocketTimeoutException: connect timed out when posting to https://xxx.service-now.com/api/now/v1/attachment/file

Here is my script (with private data removed) -

var user = new GlideRecord('sys_user');

user.addQuery('xxx','xxxxxxxx');

user.query();

if(user.next()) {

try {  

var token = '';

var s = new sn_ws.SOAPMessageV2('xxxxx', 'xxxxx');

s.setStringParameterNoEscape('userId', 'xxxxx');

s.setStringParameterNoEscape('credential', 'xxxxxx');

var responseS = s.execute();

var responseBodyS = responseS.getBody();

var xmlDoc = new XMLDocument(responseBodyS.toString(), true);

var token = xmlDoc.getNodeText("//authenticateReturn");

var r = new sn_ws.RESTMessageV2('User Photos', 'Get User Picture');

r.setStringParameterNoEscape('cookie', 'xxxxxx' + token);

r.setStringParameterNoEscape('xxxx', user.xxx.toString());

r.saveResponseBodyAsAttachment('ZZ_YYsys_user', user.sys_id.toString(), 'photo', 'image/jpeg');

var response = r.execute();

gs.print(response.getStatusCode());

gs.print(response.getErrorMessage());

}

catch(ex) {

gs.print('Got an exception:  ' + ex.getMessage());

}

}

[jarodm]

Keep us posted if/when it's resolved. I don't have this specific problem yet, but may need to use this feature in the future.

[marcelo_moreli]

Last feedback I have (when asking to backport)

Hi Marcelo,

The Development team has reviewed the PRB for the possibility of backporting this to a version lower then London.
Due to the major changes required, they have indicated that the risk to other functionality would be too high to attempt a backport.

One possible workaround they provided, is to set the following properties in the MID server config file and restart the mid server (https://hi.service-now.com/kb_view.do?sysparm_article=KB0547347)

<parameter name="glide.http.proxy_host" value="<YOUR_VALUE_HERE>" />
<parameter name="glide.http.proxy_port" value="<YOUR_VALUE_HERE>" />
<parameter name="glide.http.proxy_username" value="<YOUR_VALUE_HERE>" />
<parameter name="glide.http.proxy_password" value="<YOUR_VALUE_HERE>" />
<parameter name="glide.http.proxy_bypass_list" value="<YOUR_VALUE_HERE>" />

Please note that these settings will affect ALL web services running on the MID server, so be careful to set the by pass list properly (https://docs.servicenow.com/bundle/geneva-servicenow-platform/page/administer/import_sets/concept/c_WebProxy.html).

This is a potential work around, but the true solution will be to uptake London when it is available. Our London release should be available within a few months. We do not have an exact release date scheduled at this time.

I'm going to move this incident to Solution Proposed since the PRB has been fixed and a potential work around has been provided by Development.
Please let me know if you have any additional questions.

[JonathanJacob]

Do you happen to have a problem open with ServiceNow already?

If so what is the problem number, I seem to be experiencing the same issue.

What release of ServiceNow are you on?

Thanks,

Jonathan

[matt_kean]

The problem I had open was closed.  The issue is apparently fixed in London.

[JonathanJacob]

Can you provide the PRB Number?

Thanks!