Some time ago I wrote a two-part blog post describing how you could use Oracle Service Bus to send email and thought I’d covered just about everything people wanted to know about email. However, over the last few weeks several people have asked how to send email with attachments from Oracle Service Bus, something I didn’t cover in those blog posts, and so this is effectively Part 3.
If you didn’t read my earlier blog posts on sending email (Part 1 and Part 2), I suggest you read them now, as I will be referring to them in the remainder of this post.
Developing a service to send an email with an attachment from Oracle Service Bus is not much different from what I have described so far. In general, you will have an email business service which is responsible for actually sending the email (Part 1), and a proxy service, which routes to this email business service, responsible for defining the actual content of the email and attachment(s) (Part 2). The basic structure of the proxy service message flow for sending an email with an attachment will look something like:
We have a single Route node containing a Routing action configured to send messages to our email business service. As in Part 2, the Request Action flow of the Routing action contains the same Replace action (to set the body of the email message) and a Transport Header action (to set the subject of the email message). The key difference here is the addition of the Insert action which describes the attachment we are going to send:
As you can see in the image above, we are setting the first child element of the attachments context variable to be the XML expression in the yellow box. This expression is the key to sending an attachment, so lets look at it in more detail:
<con:attachment xmlns:con=”http://www.bea.com/wli/sb/context”>….</con:attachment>
This is the wrapper element required for any attachment.
<con:Content-Type>text/plain</con:Content-Type>
This element defines the Internet media type (aka MIME type) of the attachment – in this case a simple text file attachment.
<con:Content-Disposition>attachment; filename=”Simple.txt”</con:Content-Disposition>
This element specifies how the attachment should be handled by the recipient – in this case as an attachment (as opposed to being inline) with a filename of Simple.txt.
<con:body>I am the attachment contents</con:body>
This element represents the actual contents of the attachment.
But I don’t want the filename and/or contents to be hardcoded?
Then simply replace the static values with XPath expressions which will evaluate to the filename and/or contents of your attachment, for example:
<con:attachment xmlns:con="http://www.bea.com/wli/sb/context">
<con:Content-Type>text/plain</con:Content-Type>
<con:Content-Disposition>attachment; filename="{$body/email/attachment/filename/text()}"</con:Content-Disposition>
<con:body>{$body/email/attachment/contents/text()}</con:body>
</con:attachment>
<con:Content-Type>text/plain</con:Content-Type>
<con:Content-Disposition>attachment; filename="{$body/email/attachment/filename/text()}"</con:Content-Disposition>
<con:body>{$body/email/attachment/contents/text()}</con:body>
</con:attachment>
Note the use of the curly braces to ensure this is evaluated as an XPath expression and not just text.
What if my attachment isn’t text?
If your attachment is a binary attachment, such as a PDF, Microsoft Office Document or image, your Insert action properties will be exactly the same, apart from the XML expression which will be slightly different. For example, lets imagine we want to send an attachment called Simple.pdf, our expression will look something like:
<con:attachment xmlns:con="http://www.bea.com/wli/sb/context">
<con:Content-Type>application/pdf</con:Content-Type>
<con:Content-Transfer-Encoding>base64</con:Content-Transfer-Encoding>
<con:Content-Disposition>attachment; filename="Simple.pdf"</con:Content-Disposition>
<con:body>{$body/ctx:binary-content}</con:body>
</con:attachment>
<con:Content-Type>application/pdf</con:Content-Type>
<con:Content-Transfer-Encoding>base64</con:Content-Transfer-Encoding>
<con:Content-Disposition>attachment; filename="Simple.pdf"</con:Content-Disposition>
<con:body>{$body/ctx:binary-content}</con:body>
</con:attachment>
Note the differences from our earlier example:
- The Internet media type (the Content-Type element) is now the one for a PDF file: application/pdf (for other types of attachment refer to the list of Internet media types here to see what this value should be set to)
- We have added a Content-Transfer-Encoding element which describes how the attachment is encoded (normally in Oracle Service Bus this will be base64).
- The body element (remember this is of the attachment) refers to the binary content within the body of the original message.
But how would I get binary content in the body of the message in the first place?
The simplest way is to make sure your proxy service is a messaging service, using the file transport, expecting an input message of type binary (e.g. a binary file placed in a folder). Oracle Service Bus would read in this file and create a reference to the binary file contained within the ctx:binary-content element within the body. Alternatively, your proxy service may be reading in email which contains binary attachments already.
You can read more about how binary content is handled in Oracle Service Bus here in the documentation.
How can I send multiple attachments?
Simply add another Insert action to insert another attachment to the attachments variable. Unless you are worried about the order of the attachments (only likely for inline attachments) then the only piece that will be different is the content of the XML expression.
So, in summary I have shown how to:
- Build a proxy service to send an email with an attachment from Oracle Service Bus
- Configure the Insert action to:
- Send a text or binary attachment
- Dynamically set the filename and contents of the attachments
- Send an email with multiple attachments
If you have anymore questions about how to use the email capabilities of Oracle Service Bus, then let me know by commenting.
No comments:
Post a Comment