“The way to get started is to quit talking and begin doing.”
— Walt Disney
The other day I needed to fetch a file that was posted on another web site via its URL and process it. I have processed ServiceNow file attachments before, but I have never attempted to go out to the Internet and pull in a file using an HTTP GET of the URL. There are several ways to do that in Javascript such as XMLHttpRequest or fetch, but none of those seemed to work in server-side code in ServiceNow. But you can open up a URL using the ServiceNow RESTMessageV2 API, so I thought that maybe I would give that a shot. How hard could it be?
I decided to encapsulate everything into a Script Include, mainly so that if I ever needed to do this again, I could call the same function in some other context. My thought was to pass in the URL of the file that I wanted to fetch along with the table name and sys_id of the record to which I wanted the file to be attached, and then have the function fetch the file, attach it, and send back the attachment. Something like this:
var FileFetchUtils = Class.create();
FileFetchUtils.prototype = {
initialize: function() {
},
fetchFileFromUrlAndAttach: function(table, sys_id, url) {
...
},
type: 'FileFetchUtils'
};
That was idea, anyway. Let’s say that I wanted to attach this file, available on the ServiceNow web site, to some Incident:
The code to do that would look something like this:
var fileFetcher = new FileFetchUtils();
fileFetcher.fetchFileFromUrlAndAttach('incident', incSysId, 'https://www.servicenow.com/content/dam/servicenow-assets/public/en-us/doc-type/success/playbook/implementation.pdf');
All we need to do now is come up with the code needed to do all of the work of fetching the file, attaching it to the specified record, and returning the attachment. To begin, we will need to extract the name of the file from the URL. Assuming that the file name is the last component of the path on the URL, we can do that by splitting the path into its component parts and grabbing the last part.
var parts = url.split('/');
var fileName = parts[parts.length-1];
Next, we will need to create and configure the request object.
var request = new sn_ws.RESTMessageV2();
request.setHttpMethod('get');
request.setEndpoint(url);
The next thing to do would be to execute the request, but before we do that, we can take advantage of a nice built-in feature that will really simplify this whole operation. There is an available function of the RESTMessageV2 API that allows you to declare your intent to turn the retrieved file into an attachment, which will then handle all of the details of doing that on your behalf when the request is executed. You just need to invoke the function before you execute the request.
request.saveResponseBodyAsAttachment(table, sys_id, fileName);
response = request.execute();
Although that really makes things super simple, it’s still a good idea to check the HTTP Response Code, just to make sure all went well. If not, it’s a good practice to relay that to the user.
if (response.getStatusCode() == '200') {
...
} else {
returnValue = 'Error: Invalid HTTP Response: ' + response.getStatusCode();
}
Now, assuming that things actually did go well and our new attachments was created, we still want to send that back to the calling script as a response to this function. The RESTMessageV2 API saveResponseBodyAsAttachment function does not return the attachment that is created, so we will have to use the table and sys_id to hunt it down. And if we cannot find it for any reason, we will want to report that as well.
var attachmentGR = new GlideRecord('sys_attachment');
attachmentGR.addQuery('table_name', table);
attachmentGR.addQuery('table_sys_id', sys_id);
attachmentGR.orderByDesc('sys_created_on');
attachmentGR.query();
if (attachmentGR.next()) {
returnValue = attachmentGR.getUniqueValue();
} else {
returnValue = 'Error: Unable to fetch attachment';
}
That should now be everything that we need to fetch the file, attach it, and send back the attachment. Putting it all together, the entire Script Include looks like this:
var FileFetchUtils = Class.create();
FileFetchUtils.prototype = {
initialize: function() {
this.REST_MESSAGE = '19bb0cde2fedd4101a75ad2ef699b6da';
},
fetchFileFromUrlAndAttach: function(table, sys_id, url) {
var returnVlaue = '';
var parts = url.split('/');
var fileName = parts[parts.length-1];
var request = new sn_ws.RESTMessageV2();
request.setHttpMethod('get');
request.setEndpoint(url);
request.saveResponseBodyAsAttachment(table, sys_id, fileName);
response = request.execute();
if (response.getStatusCode() == '200') {
var attachmentGR = new GlideRecord('sys_attachment');
attachmentGR.addQuery('table_name', table);
attachmentGR.addQuery('table_sys_id', sys_id);
attachmentGR.orderByDesc('sys_created_on');
attachmentGR.query();
if (attachmentGR.next()) {
returnValue = attachmentGR.getUniqueValue();
} else {
returnValue = 'Error: Unable to fetch attachment';
}
} else {
returnValue = 'Error: Invalid HTTP Response: ' + response.getStatusCode();
}
return returnValue;
},
type: 'FileFetchUtils'
};
Now all we need to do is find an Incident to use for testing and use the background scripts feature to give it a try. First, we’ll need to pull up an Incident and then use the Copy sys_id option of the hamburger drop-down menu to snag the sys_id of the Incident.
Now we can pop over to the background script processor and enter our code, using the sys_id that we pulled from the selected Incident.
After running the script, we can return to the Incident to verify that the file from the specified URL is now attached to the Incident.
Just to make sure that all went well, you can click on the download link to pull down the attachment and look it over, verifying that it came across complete and intact. That pretty much demonstrates that it all works as we had intended. If you would like a copy to play around with on your own, you can pick it up here.
