If we don't, we might get something lame and unhelpful, like That's no good. So if we want to convert these bytes into a string, we have to do it the Rhino way first, by using (). Rhino runs Java (not JavaScript)-based implementation of JavaScript, and doesn't like to share super neat data types such as bytes with JavaScript. The byte data exists within the underpinning platform that ServiceNow uses, which is called Rhino. This sets us up for what we'll do next on line 11, where we convert that data into a string using (). This returns the raw bytes of the file - that means binary data. On line 9, I use an undocumented method of the GlideSysAttachment class: getBytes(). Note: A scoped version of this class is now documented, but some of the methods we need to use in scoped scripts, are not available on the global version of GlideSysAttachment. While this class is used in two scripts in the ServiceNow documentation, there is no actual documentation on it in the global scope, at the time of updating this article (4/21/19). On line 7, I declare an instance of the undocumented global GlideSysAttachment class, as the variable gsa. In your case, these values will be different, and might be assigned differently, depending on how you're using this code. All the important work is being done in the getAttachmentContentsAsString() function, which I call on line 3. On lines 1 and 2, I'm just declaring the table and record that I'm working with.
Colormag pro attachment page download#
The Position field determines the order of the data in sequence, for when ServiceNow needs to re-combine the data into the original file (such as when a user wants to view or download it). This means that each attachment file will have one or more entries in the sys_attachment_doc table, which corresponds to the binary data of the original file that was attached. The Attachment Documents table also contains a reference field ( sys_attachment), which points to the parent record in the Attachments table. This table has a few other interesting fields, such as length (which defines the number of bytes stored in this chunk), and position (which defines what order this chunk of bytes fits in). The actual binary data of the file is split into ~4KB (3736 byte) chunks, which are then saved into the Data field of the Attachment Documents table. When you upload an attachment file to ServiceNow, a record is created in the Attachments table with some metadata, including the file name, content type, and the size of the attached file. There are two tables which do the work of dealing with attachments: Attachments ( sys_attachment), and Attachment Documents ( sys_attachment_doc). You can store binary data as well, including pictures, audio, and even executable files but what happens when you upload a binary file as an attachment, to ServiceNow? You may be aware that you can store more than just text within ServiceNow, in the form of attachments. I recommend using try blocks around any undocumented function, with a very clear log message in the catch. As always, be careful to note anywhere you use such APIs, in case they are not supported in a future update. Note : This article discusses some little-documented APIs.
Colormag pro attachment page how to#
Recently, I needed to copy some attachments programmatically and otherwise fiddle around with attachments. After finding nothing in the ServiceNow product documentation, and very little through the usual search channels, I figured it was time to write an article about how to programmatically deal with attachments in ServiceNow.
This article was originally written in February 2016, but was last updated on 4/21/19.Īttachments in ServiceNow are not as straight-forward as email attachments, and it's not always obvious how to do what you want with them.