Summary

In that document I am presenting a way on how to use the mail package in graphical mapping to send email with binary attachment (pdf).

In my scenario I have an incoming RFC call containing pdf lines which are base64 encoded. These lines are concatenated into one pdf document which is sent out as email attachment. The email has also a normal body part.

My first attempt was to use multipart/mixed content type and to create the mail package content in an udf taking care of the inline email body and the pdf attachment separated by boundaries. The problem was that the pdf attachment was base64 encoded in the email thus invalid. Decoding the pdf in the udf is not an option as the mail package content field is of string type (as it contains also the body text). So this approach works only for non binary attachments.

Next I tried to create the attachment in the global container and that did the trick. I am showing now that solution focusing only on the key objects which are the message mapping and the receiver channel.

Message Mapping

/wp-content/uploads/2015/06/scrshot1_717065.png

In the source message we have DIJNET_NAM used for the file name, EMAIL_ADDRESS and DIJNET_TAB containing the pdf lines in BASE64.

We might have different type of lines but we are interested in pdf lines only (TYPE=’P’).

In the target message I deactivated the irrelevant fields.

Content_Type is set to text/html; charset=ISO-8859-2 because I am sending the email with html body.

Content_Disposition is set to inline because I want to display the html content in the email body (and not as attachment).

Content is created by the udf CreateContent.

UDF CreateContent

The udf is taking rows (pdf lines), row types (for filtering on ‘P’) and filename as argument. We execute it on the whole queue as we need all the pdf lines to create the attachment.

/wp-content/uploads/2015/06/scrshot2_717078.png

/wp-content/uploads/2015/06/scrshot3_717079.png

We create the attachment as message attachment in the global container so we can use the Keep attachment flag in the mail receiver channel.

We also need to decode the pdf lines because we need the original binary content to get a valid pdf.

I am not using error handling (try/catch) to keep the tutorial as short as possible.

Receiver channel

/wp-content/uploads/2015/06/scrshot4_717093.png

That’s it

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Anupam Ghosh

    Thank you Gabor for this blog.

    I tried the same using java mapping, I am getting errors as shown in receiver mail adapter.

    MP: exception caught with cause com.sap.aii.af.sdk.xi.srt.BubbleException: Failed to call the endpoint  [null “null”]; nested exception caused by: com.sap.aii.af.sdk.xi.util.XMLScanException: Can’t parse the document; nested exception caused by: org.xml.sax.SAXParseException: The content of elements must consist of well-formed character data or markup.

    Regards

    Anupam

    (0) 
    1. Gabor Hornyak Post author

      Hi Anupam,

      I don’t know your scenario but my first guess would be character encoding issue.

      You could also try using multipart type in your java mapping (instead of the global container attachment approach), like the following where emailAttachment is the base64 encoded pdf string:

      String boundary = “–AaZz”;

      String CRLF = “\r\n”;

                         

      //     create XML structure of mail package

      String output = “<?xml version=\”1.0\” encoding=\”UTF-8\”?>”

      + “<ns:Mail xmlns:ns=\”http://sap.com/xi/XI/Mail/30\”>”

      + “<Subject>” + mailSubject       + “</Subject>”

      + “<From>” + mailSender    + “</From>”

      + “<To>” + emailAddress    + “</To>”

      + “<Content_Type>multipart/mixed; boundary=\”” + boundary + “\”</Content_Type>”

      + “<Content>”;

      out.write(output.getBytes(“UTF-8”));

      // create the declaration of the MIME parts

      //First part

      output = “–“ + boundary + CRLF

      + “Content-Type: text/html; charset=UTF-8” + CRLF

      + “Content-Disposition: inline” + CRLF + CRLF

      + emailContent + CRLF + CRLF

             //Second part

      + “–“ + boundary + CRLF

      + “Content-Type: application/pdf; name=” + attachmentName + CRLF

      + “Content-Transfer-Encoding: base64” + CRLF

      + “Content-Disposition: attachment; filename=” + attachmentName + CRLF + CRLF;

      out.write( output.getBytes(“ISO-8859-2”) );

      //Source is taken as attachment

      out.write( emailAttachment.getBytes() );

      // Close the email

      out.write( “</Content></ns:Mail>”.getBytes() );

      (0) 
      1. Anupam Ghosh

        Thank you Gabor for your quick response. my question  is if we are encoding the pdf content with base 64 encoding , how will the reader read the attachment without decoding again??

        Regards

        Anupam

        (0) 
        1. Gabor Hornyak Post author

          Hi Anupam,

          my experience is that by specifying the content-transfer-encoding as base64, the email will be delivered with a valid pdf attachment and when saving it in Outlook (or opening it), you will get a normal binary pdf and your pdf reader will get along just fine.

          cheers

          Gabor

          (0) 
  2. Sachin Jangir

    Hi Gabor,

    Indeed a good read.

    I want to know more on it, if we can handle other file formats in attachments such as jpg, docx, xlsx, txt & etc.

    Please let me know your input on this

     

    Best Regards,

    Sachin Jangir

     

     

     

    (0) 

Leave a Reply