Troubleshooting Ignition Email Attachments in Gateway Scripts

Ignition sent the body-only message, but adding a file exposed two separate failures: a byte-array shape mismatch, followed by a JavaMail error while building the attachment message. Treat them as separate layers. Nesting the bytes fixes the first error; it does not, by itself, fix a missing MIME data handler.

Where does the attachment request stop?

The request crosses several boundaries. The script calls system.net.sendEmail; the client-side stack shown for the failing event passes through Ignition’s gateway interface; the gateway then calls its email utility, which uses JavaMail to assemble and send the message. Attachments add a multipart MIME body that the body-only test does not exercise.

A successful body-only email shows that the tested sender, recipient, and basic email path worked without an attachment. It does not show that the gateway can construct a multipart message or that the SMTP server accepted an attachment-bearing message. The reported trace contains no SMTP response code, so the MIME exception should not be diagnosed as a server rejection.

What does the [B to [[B error mean?

In the Java type notation shown by the exception, [B represents one byte array. [[B represents an array whose elements are byte arrays. system.file.readFileAsBytes returns the bytes for one file, so assigning its result directly to attachmentData supplies one byte array where the send function expects a collection of file payloads.

Wrap that byte array in an outer list:

fileBytes = system.file.readFileAsBytes('c:\\Temp\\Test.txt')
attachmentData = [fileBytes]

The inner value remains the file’s byte array; the outer list represents the attachment collection. Do not convert the file contents to a string or a printed representation of the array. The value printed as something like [B@4813cc is an object identity-style representation, not the file contents.

Writing the byte array to another file exercises a different operation. It demonstrates that the script obtained bytes that the file-writing function can use. It does not validate the container type required by system.net.sendEmail, nor does it exercise JavaMail’s multipart handling.

Which failure are you seeing?

Read the deepest exception in the stack trace and branch on that message. The outer Gateway Error 500 is a wrapper and is not specific enough to choose a fix.

The reported test file was a .txt file containing abc. After the attachment data was wrapped in a list, the coercion error changed to the multipart data-handler exception. That change is diagnostically useful: the argument-shape problem was passed, but the send still failed later.

The same multipart exception appeared in another report involving Ignition 7.6.0, and that report identified a fix in Ignition 7.6.1 release candidate 2 or later. Treat that as a separate version-specific branch; it does not make the original coercion error a version bug.

How should attachment names and payloads be paired?

Pass filenames in attachmentNames and byte arrays in attachmentData. Treat the two as parallel lists: the name at an index describes the payload at that index. For one file, each list contains one item; for multiple files, add one name and one byte array per attachment in matching order.

attachmentNames = ['Test.txt']
attachmentData = [system.file.readFileAsBytes('c:\\Temp\\Test.txt')]

Do not leave the name list empty when sending a file if the receiving message needs a filename. The original body-only call used empty lists because it had no attachments. Once a payload is added, provide its corresponding filename as well. Before sending multiple files, check that both lists have the same number of entries and that each position refers to the intended file.

Use a simple, known file first. The small text file from the reported case is useful for isolating structure from unrelated file-format questions. If a one-file test reaches the MIME error, adding more attachments will not help diagnose the handler failure.

What should the corrected Ignition call look like?

Keep the already-working email settings unchanged and modify only the attachment arguments. This makes the first retry a controlled test of the attachment input instead of a simultaneous change to SMTP settings, credentials, and file data.

1. Read the file in the script’s execution context and hold the returned byte array in a variable.
2. Place that byte array inside a one-item list; place the matching filename in a one-item attachmentNames list.
3. Pass both lists in the attachment argument positions used by the working call.
4. Run the call with the same sender, recipient, timeout, and credentials as the body-only test.

smtp = 'my smtp server'
myFrom = 'my email address'
subject = 'Test email from Ignition'
body = 'This is a test email'
html = 0
to = ['destination email']
attachmentNames = ['Test.txt']
attachmentData = [system.file.readFileAsBytes('c:\\Temp\\Test.txt')]
timeout = 60000
username = 'email account username'
password = 'email account password'

system.net.sendEmail(
    smtp, myFrom, subject, body, html, to,
    attachmentNames, attachmentData, timeout, username, password
)

This call follows the positional order shown in the working body-only call: SMTP host, sender, subject, body, HTML flag, recipient list, attachment names, attachment data, timeout, username, and password. Preserve the actual configured values in the project; the placeholders above are not literal credentials or server settings.

Why can nesting the bytes still produce a MIME error?

The outer list corrects the type presented to Ignition’s email function. It does not provide JavaMail with the MIME data-content handler needed to serialize a multipart message. Once the call gets beyond argument coercion, JavaMail has a new task: combine the message body and attachment into a multipart/mixed message and write that message for sending.

The exception names javax.activation.UnsupportedDataTypeException and says there is no object DCH for multipart/mixed. That points to MIME content handling, not to the file’s contents being unreadable. In the reported case, a text file containing abc was used, and the same multipart exception remained after the attachment data was nested.

The stack reaches SMTPTransport.sendMessage, but the nested cause is the useful diagnostic. The trace does not show an SMTP server rejection or a response code. Do not spend the first troubleshooting cycle changing the SMTP host, recipient, or attachment extension when the deepest exception still identifies a missing multipart handler. Confirm the input structure, then test the Gateway’s JavaMail/activation environment or the applicable Ignition version.

Which runtime and library changes are supported by these results?

Check the Gateway’s own Java runtime rather than relying on the Java version installed for a separate workstation. In the reported case, the Gateway configuration showed Sun Microsystems Inc. 1.6.0_18. Another incident was recalled with Java 6u4, but that observation did not establish Java 6u4 as the cause here; the runtime number alone is not a diagnosis.

Manual changes to bundled archives affect the Gateway runtime and did not fix the documented multipart failure. If such a change has already been made, restore the installation’s supported library state before evaluating another change. Record the exact Ignition and Gateway Java versions, restart only when a version or library change requires it, and test one change at a time.

How can you isolate the file input from the email subsystem?

Use the same small file for each test and keep the body-only call as the baseline. A disciplined sequence prevents a file-read issue, an argument-shape issue, and a MIME-handling issue from being mistaken for one another.

1. Run the established body-only call and record that it still succeeds with the same destination and credentials.
2. Read the test file with system.file.readFileAsBytes. Confirm that the script can read the intended path and that the returned data represents the expected file. If needed, write those bytes to a separate test file and compare the resulting contents; this checks file I/O, not email packaging.
3. Wrap the byte array in a one-element outer list. Set attachmentNames to a one-element list containing the intended filename.
4. Call system.net.sendEmail without changing the working SMTP or authentication arguments.
5. Classify the deepest exception. If it still reports [[B coercion, inspect the value actually passed as attachmentData. If it reports multipart/mixed and no DCH, proceed to Gateway MIME/runtime troubleshooting.

A path or file-access failure occurs before JavaMail has a valid payload to serialize. A successful system.file.writeFile test is useful at that earlier boundary, but it does not prove that the email API received a list of byte arrays. Conversely, a multipart exception after nesting indicates the call moved beyond the original type mismatch; it does not prove that the SMTP server delivered the message.

What should the final attachment test verify?

Verify the result at both ends of the path. First confirm that the script passes a filename list and a payload list with the same count, and that each payload came from the intended file. Then test from the same execution context and Gateway runtime used by the application, rather than relying only on a local file-write test or a Designer-side assumption.

Inspect the complete Gateway error, including the deepest cause, after each retry. A remaining ClassCastException means the input shape still needs correction. A multipart/mixed DCH exception means JavaMail’s multipart handling remains the active failure. A successful API call is not the final content check: confirm that the recipient receives the attachment under the expected name and that its contents match the source file. Repeat that check after any Gateway version or library change.

FAQ