Sending an attachment to ServiceNow via Web Services

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 update set has now been added to the latest release of ServiceNow as part of the core code. You will only need this update set if you’re on an older build.

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:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ecc="http://www.service-now.com/ecc_queue">
<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>

Remember, just like any of the ServiceNow web services, you will need to use basic authentication and specify a user in your instance that has rights to create attachments to the target record.

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

By Jacob Andersen|2013-10-11T05:57:53-05:00March 24th, 2010|Categories: Integration, Web Services|Tags: Attachments, Integration, web services|12 Comments

About the Author: Jacob Andersen

Jacob is the co-founder of Crossfuze, a ServiceNow implementation product and services company. He is one of the foremost ServiceNow integration experts in the world and designed/wrote many of the plugins found in the ServiceNow product today. Prior to co-founding Crossfuze he worked at ServiceNow during its startup years to write the SSO solutions and 3rd-party integrations.

12 Comments

TheBrain April 12, 2010 at 10:09 pm - Reply

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?
Jacob Andersen April 13, 2010 at 4:05 am - Reply

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?
- ElPunto April 14, 2010 at 8:17 am - Reply
  
  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’);
  
  }
  
  }
Ron August 1, 2012 at 4:25 pm - Reply

Mark,
great article, thank you! is it possible to remove an attachment as well?

thanks,
Ron
- Harish March 16, 2015 at 4:27 am - Reply
  
  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
Akshat March 9, 2013 at 9:32 pm - Reply

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
- Abdul Fathah September 19, 2014 at 3:06 am - Reply
  
  I think you are checking the null values when you are updating field in Instance B.
  Please check those stuff in Instance B.
  
  Thanks!
Tom March 12, 2014 at 5:43 am - Reply

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
Roli Khanna June 10, 2014 at 11:13 am - Reply

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
- Jacob Andersen June 11, 2014 at 10:23 am - Reply
  
  You want it to be base64 encoded. Otherwise, it would be binary data and would make your XML invalid.
Sid December 22, 2014 at 2:01 pm - Reply

Great Article! Works like a charm
Sandeep September 29, 2017 at 10:45 am - Reply

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.