Attaching a file to a record within the ServiceNow interface is a trivial task. However, many customers have found it necessary to send an attachment via web services to Service-now. This need is usually spawned from an integration with a 3rd-party product. The SOAP Attachments update set is the perfect solution for this problem.
The attachment creator allows a third-party user to send base64 encoded binary (or ASCII) data via SOAP and have it attached to any table within ServiceNow. The solution is actually quite simple. You need to send a web service message to the ecc_queue. You can access the WSDL and SOAP endpoint here:
WSDL: | https://instance_name.service-now.com/ecc_queue.do?WSDL |
Endpoint: | https://instance_name.service-now.com/ecc_queue.do?SOAP |
The values for your fields will need to be as follows:
agent | AttachmentCreator |
topic | AttachmentCreator |
name | problem_data.xls:application/vnd.ms-excel |
source | incident:a7e6c1840a0a3c1e018ac300f684be29 |
payload | base64 encoded binary (or ASCII) data |
Using the data specified above, the resulting SOAP message will attach the problem_data.xls file to the incident that has the sys_id of a7e6c1840a0a3c1e018ac300f684be29. The SOAP message would look like the following:
<soapenv:Header/>
<soapenv:Body>
<ecc:insert>
<agent>AttachmentCreator</agent>
<name>problem_data.xls:application/vnd.ms-excel</name>
<payload>AAAAIGZ0eXBxdCrG[..truncated..]</payload>;
<source>incident:a7e6c1840a0a3c1e018ac300f684be29</source>
<topic>AttachmentCreator</topic>
</ecc:insert>
</soapenv:Body>
</soapenv:Envelope>
Prerequisites:
- None
Related Links:
- Download: SOAP Attachments
- Supporting Documentation: Installing an update set on your instance
- Related Article: Sending attachments from ServiceNow to a 3rd-party service desk
That would really complete the story….
We are trying to do this, but are not yet successful….. We get what looks like the first 40 characters of the attached files from a record, but not more.
Any hints?
How can you tell that you’re just getting the first 40 characters? When you look at your ecc queue record that comes in, are you seeing just 40 base64 encoded characters in the payload field?
The previous reply is a bit confusing. Inbound base64 string is picked up fine. What was meant is that we tried the opposite to convert incident attachments back as type=xsd:base64Binary
to an external Webservice. On first testing I experienced some truncation but on retesting everything seems to work fine and the full encoded string is generated.
Next challenge is to try and zip the attachment. any suggestions ?
The following code is used to output the first attachment found link to a record:
gattachxxxx are global defined vars
function AttachmentsChanged( record ) {
gattachcontent = ”;
gattachfilename = ”;
var gr = new GlideRecord(‘sys_attachment’);
if ( gr.get(‘table_sys_id’, record.sys_id) ) {
var attachdate = gr.sys_updated_on;
var StringUtil = Packages.com.glide.util.StringUtil;
var sa = new Packages.com.glide.ui.SysAttachment();
gattachcontent = StringUtil.base64Encode(sa.getBytes(record.getRecordClassName(), record.sys_id));
gs.log(‘AttachmentsChanged content:’ + gattachcontent );
gattachfilename = gr.file_name;
gs.log(‘AttachmentsChanged filename:’ + gattachfilename);
} else {
//gs.log(‘AttachmentsChanged no attachment found’);
}
}
Mark,
great article, thank you! is it possible to remove an attachment as well?
thanks,
Ron
Hi Ron,
For this scenario, you may need to update the existing Script Include(SoapAttachments). Twist your logic in the code that when this Script Include is called, first delete all the existing attachments from the record and then add the attachments(if any) onto the record.
Thanks,
Harish
Hi
I am doing a Service-now to Service-now Integration via web services but i am facing a issue. In my scenario what is happening is when I log the incident in one instance it creates a same ticket in other instance and when I update the same ticket it updates the same ticket in other instance as well.It’s working fine but if I update in means of the field it does not not clear the same field in other instance.
can anyone tell how can i achieve this if i pass a null value in a field so, it updates the same in other instance.
Thanks
I think you are checking the null values when you are updating field in Instance B.
Please check those stuff in Instance B.
Thanks!
It should be noted that the attachment web service accepts the number for incident or request item, presumably checking the display value.
It’s not documented anywhere that you don’t have to send the sys_id
Hi Jacob
In this article you are talking about Base 64 encoded payload is there a OOB capability where we can have a payload without the Base64 encoding.
Thanks
Roli
You want it to be base64 encoded. Otherwise, it would be binary data and would make your XML invalid.
Great Article! Works like a charm
Hi,
I am trying to attach multiple attachments in a Incident in SNow.
My first file attaches fine, however not the 2nd and third. Has anyone had the same experience before or has any idea on how to resolve this.
Also I am not able to see the the 2nd and 3rd files in ecc queue.