Base 64 decode string and add attachment

[eyal abu hamad]

Hey, im trying to decode base64 string and add it to an incident but I got this error

this is my business rule

(function executeRule(current, previous /*null when async*/) {

	// Add your code here
	//var base64String = current.field_name; // Replace 'field_name' with the actual field name

// Decode the base64 string into a byte array
var base64Bytes = GlideStringUtil.base64DecodeAsBytes('dGVzdA==');

// Create an attachment record
var attachment = new GlideSysAttachment();
attachment.setFileName("test.txt"); // Set the desired file name for the attachment
attachment.setTableName(current.getTableName());
attachment.setTableSysId(current.getUniqueValue());

// Attach the decoded image to the attachment record
attachment.writeBase64Content(base64Bytes);

// Insert the attachment record
attachment.insert();

})(current, previous);

[Iraj Shaikh · Accepted solution]

Hi @eyal abu hamad 

The error you're encountering, `Illegal access to method setFileName(string) in the class com.glide.ui.SysAttachment`, suggests that you're trying to call a method that is not accessible or does not exist in the GlideSysAttachment API within ServiceNow.

The `GlideSysAttachment` class does not have a method called `setFileName`. Instead, you should use the `write()` method to create an attachment, which allows you to specify the file name, content type, and the byte array of the file content.

Here's how you can modify your business rule to correctly create an attachment:

(function executeRule(current, previous /*null when async*/) {

    // Add your code here
    //var base64String = current.field_name; // Replace 'field_name' with the actual field name

    // Decode the base64 string into a byte array
    var base64Bytes = GlideStringUtil.base64DecodeAsBytes('dGVzdA==');

    // Create an attachment record
    var attachment = new GlideSysAttachment();

    // The write method takes the table name, sys_id of the record, file name, content type, and the byte array of the file content
    var attachmentSysId = attachment.write(current.getTableName(), current.getUniqueValue(), "test.txt", "text/plain", base64Bytes);

    // The attachmentSysId now contains the sys_id of the newly created attachment record

})(current, previous);

In this updated code, the `write()` method is used to create the attachment. It takes the following parameters:

• `tableName`: The name of the table to which the attachment will be linked.
• `tableSysId`: The sys_id of the record to which the attachment will be linked.
• `fileName`: The desired file name for the attachment.
• `contentType`: The MIME type of the file (e.g., "text/plain" for a text file).
• `data`: The byte array of the file content.
  
  

The `write()` method returns the sys_id of the newly created attachment, which you can use if you need to reference the attachment later in your code.

Please mark this response as correct or helpful if it assisted you with your question.

[eyal abu hamad]

is there anyway to find the content type of the Base64 string ? I will only get the base64 string and to parse it to attachment. is there any way to do that ?

[Iraj Shaikh]

Hi @eyal abu hamad 

Base64 encoding does not inherently contain metadata about the content type of the data it represents. The content type (MIME type) is typically transmitted along with the Base64 data in various protocols and formats, such as in HTTP headers or data URIs.

However, if you only have the Base64 string and no additional information about the content type, you cannot determine the content type from the Base64 string alone. You would need some external context or information to know what type of data the Base64 string represents.

If you are dealing with a limited set of known file types, you could potentially guess the content type by looking at the beginning of the decoded data for specific "magic numbers" or file signatures. For example, a PNG image file always starts with the following bytes: `89 50 4E 47 0D 0A 1A 0A`. After decoding the Base64 string into bytes, you could check for such signatures to infer the file type.

Here's a very basic example of how you might implement this in ServiceNow using a business rule:

(function executeRule(current, previous /*null when async*/) {

    // Assume we have a base64String variable that contains our Base64 data
    var base64String = current.u_base64_field; // Replace with the actual field name that contains the Base64 string

    // Decode the base64 string into a byte array
    var base64Bytes = GlideStringUtil.base64DecodeAsBytes(base64String);

    // Function to guess the MIME type based on the file signature (magic numbers)
    function guessContentType(bytes) {
        // Convert the first few bytes to a hex string for comparison
        var header = '';
        for (var i = 0; i < Math.min(4, bytes.length); i++) {
            header += ('00' + bytes.charCodeAt(i).toString(16)).slice(-2);
        }

        // Compare the header to known file signatures
        switch (header) {
            case '89504e47':
                return 'image/png'; // PNG image
            case 'ffd8ffe0':
            case 'ffd8ffe1':
            case 'ffd8ffe2':
                return 'image/jpeg'; // JPEG image
            // Add more cases for other file types if necessary
            default:
                return 'application/octet-stream'; // Unknown file type
        }
    }

    // Guess the content type of the file
    var contentType = guessContentType(base64Bytes);

    // Create an attachment record
    var attachment = new GlideSysAttachment();

    // The write method takes the table name, sys_id of the record, file name, content type, and the byte array of the file content
    var attachmentSysId = attachment.write(current.getTableName(), current.getUniqueValue(), "unknown", contentType, base64Bytes);

    // The attachmentSysId now contains the sys_id of the newly created attachment record

})(current, previous);

Please note that this method is not foolproof and can only guess the content type based on a limited set of known signatures. If you have no information about the possible content types you're dealing with, it's best to use a generic content type like `application/octet-stream`.

Please mark this response as correct or helpful if it assisted you with your question.