A
ttaching a file to a record within the Service-now 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 Service-now. 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 Service-now to a 3rd-party service desk
Comments
Posted On
Apr 12, 2010Posted By
TheBrainThat 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?
Posted On
Apr 13, 2010Posted By
Jacob AndersenHow 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?
Posted On
Apr 14, 2010Posted By
ElPuntoThe 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’);
}
}