- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-31-2016 04:20 AM
Hi I'm troubleshooting the ECC queue to receive attachments. Small attachments are OK. I have read that for SOAP it's a 5M size limit. 3.9M is OK. 4.5M fails. How can I find out why it's failed? payload result is "Attachment creation failed" I't probably something to large, but I can't see if the actual payload is missing. Or can I? The parameter glide.soapprocessor.large_field_patch_max was 512000 and I increased it to 2000000, but I don't know if it's related. com.glide.attachment.max_size = 1024 (1G) I can't find any other parameter that impact this that should prevent the file size. Any idea, or am I to close to 5M limit? BR Gunnar
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-02-2016 02:22 PM
Hi Gunnar,
..(you) have read that for SOAP it's a 5M size limit - YES
AttachmentCreator SOAP Web Service - ServiceNow Wiki
..
Is there size limit on the attachment in the message
- Attachments are limited to a maximum of 5MB.
REST attachment api
..
The Attachment API respects any system limitations on uploaded files, such as maximum file size and allowed attachment types. You can control these settings using the properties com.glide.attachment.max_size, 1024MB by default, and glide.attachment.extensions.
..
If you are using SOAP Attachment creator and if you see 3.9MB is OK and 4.5 MB is not OK, then it is probably not possible to fix this - other than change to using the REST attachment api available in Geneva.
Best Regards
Tony
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-18-2020 12:37 AM
Another reason for the attachment creation failure could be unexpected characters in the file name such as "/", "\" or ":" which will still throw the same "Attachment creation failed" error in ECC.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-26-2025 03:51 AM
For those wondering why files much smaller than 5mb also fails through the SOAP integration, it's likely related to the fact that attachments gets base64 encoded as a payload in the message, and base64 encoding takes more space.
What is the space overhead of Base64 encoding? -Daniel Lemire's blog 2019[...] the base64 version of a file is at least 4/3 larger than the the original: we use at least 33% more storage than the original file size when encoding a file as base64.
So in practice, in some situations the filesize limit is something like 5mb/1.33= ~3.75mb
My own testing for a relevant integration resulted in files 3.9mb or larger always failed to be created regardless of filetype, and at least 3.5mb managed to come through. (didn't test further for more exact results, as the 3.75mb seems close/clear enough.)
