No announcement yet.

Mirth and Base64 in/binary out PDF attachments

  • Filter
  • Time
  • Show
Clear All
new posts

  • Mirth and Base64 in/binary out PDF attachments

    We are having trouble with Mirth 3.5 receiving Base64 encoded PDF files, processing them out as attachments, and then reattaching them in a multi-part form post in binary format.

    On the inbound side we receive the PDF as part of a JSON post and parse it out using the following Javascript attachment script:

    var pattern = /\"data\"\s*:\s*\"/g; 
    var match; 
    var replacements = [];
    while ((match = pattern.exec(message)) !== null) { 
    	var startIndex = match.index + match[0].length
    	var endIndex = message.indexOf("\"", match.index + match[0].length);
    	var attachment = addAttachment(FileUtil.decode(message.slice(startIndex, endIndex)), "application/pdf");
    	var replacement = { startIndex: startIndex, endIndex: endIndex, attachmentId: attachment.getId() };
    if (replacements.length == 0) {
    	return message;
    var startIndex = 0;
    var outMessage = "";
    replacements.forEach(function(replacement) {
    	outMessage += message.slice(startIndex, replacement.startIndex) + "${ATTACH:channelId:messageId:" + replacement.attachmentId + "}";
    	startIndex = replacement.endIndex;
    outMessage += message.slice(startIndex);
    return outMessage;
    Reattachment is occuring in a different channel, so the attachment ID includes channel ID and message id which are substituted in the channel:
    jsonRequest.attachments.forEach(function(attachment) {
    					if (attachment.hasOwnProperty('data'))
 ='channelId', connectorMessage.getChannelId()).replace('messageId', connectorMessage.getMessageId());
    This does create the attachment on the message. However, it can't be viewed in the PDF viewer when double click in the dashboard on the attachment. If export is selected, and exporting in binary, the file is corrupt. If exporting in text then the file is a valid PDF. Not sure if that's related to the following problem.

    I tried using the method described in this thread to reattach in binary mode. When using the channel group included there it only includes the opening boundary in the output. It seems only the first thing that is Base64 encoded is decoded and sent. Anything past that is ignored.

    We have a hack of a workaround with the following destination transformer, but this breaks on large files and we can't view it in the dashboard due to the large message sizes.

    var attachmentId = msg['data'].toString();
    var payload1 = new java.lang.StringBuilder();
    payload1.append('Content-Type: application/pdf\r\n');
    payload1.append('Content-Disposition: form-data; name="file"; filename="').append($('filename')).append('"\r\n\r\n');
    var payload1Bytes = FileUtil.encode(payload1.toString().getBytes('UTF-8'));
    var attachedBytes = AttachmentUtil.reAttachMessage(payload1.toString(), connectorMessage, 'UTF-8', false, true, false);
    msg = FileUtil.encode(attachedBytes);
    We really need a solution to the reattachment issue so we can avoid having these large messages sizes in the dashboard. Ideally, the PDF viewer would work correctly so we can see and verify the files we're sending without having to export as text.

    Many thanks,

  • #2
    Try adding the base64 string as the attachment instead of the byte array. I.e.:
    var attachment = addAttachment(message.slice(startIndex, endIndex), "application/pdf");


    • #3
      I've tried the base64 attachment approach, which results in the file still not working when double clicked, but it does export as binary correctly. Maybe this is a step in the right direction, but I still can't get it to reattach correctly without doing it manually which for large files creates timeout issues and an inability to read the problem message in the dashboard (due to size, I assume).


      • #4
        I've run across pdf files that the dashboard viewer has trouble displaying correctly, but I've found that when I try to add the attachment as a byte[] instead of base64 string, the viewer doesn't even recognize it as a valid pdf.

        I know they've made some improvements to the AttachmentUtil and Attachment User API classes in 3.6, but I haven't tried them yet.