Introduction
Oracle Service Bus message context is a set of properties, so called context variables, that hold message content as well as information about messages as they are routed through Oracle Service Bus (OSB). The Message Context Schema specifies the element types for the predefined message context variables.
Such a predefined context variable is the variable attachments.
Fig. 1 shows in an excerpt of the Message Context Schema the definition of the element attachmens.
|
Fig. 1
Obviously the attachment body can hold either a reference of the content or the content itself!
In this article we analyze what contains exactly the element /mc:attachments/mc:attachment/mc:body and how we can handle its contents.
First of all let us focus on the variables
- Content-Types
- Content-Transfer- Encoding
their meanings and their possible values.
Content-Type
According to the W3 specifications (s. [1]) Fig. 2 contains an excerpt of the main characteristics of the variable Content-Type:
An initial set of seven Content-Types is defined by this document. This set of top-level names is intended to be
|
Fig. 2
Content-Transfer- Encoding
According to the W3 specifications (s. [1]) Fig. 3 contains an excerpt of the main characteristics of the variable Content-Transfer-Encoding:
Unlike Content-Types, a proliferation of Content-Transfer- Encoding values is undesirable and unnecessary.
|
Fig. 3
Both variables play a role when a multipart message hits a proxy service that accepts messaging request.
Contents of attachment/body
We can gather the possible combinations of Content-Type and Content-Transfer-encoding in a 2-dimensional Matrix. We ignore the possible values „x-token“ as special cases that are out of scope of this analysis. We will also omit the value „message/*“ as a special case of mail mime attachments, but we will add the possibility of missing one or both of them.
When the content of the attachment body is a reference to a binary content, we need some kind of materialization of the content in order to analyze it, which might be performed through
- a java callout or
- a service callout to a simple Proxy-service
|
application/* |
audio/* |
Image/* |
Text/* |
Video/* |
none |
BASE64 |
By ReferenceContent has to be base64 encoded otherwise the attachment is empty.Reference points to decoded data. |
By ReferenceContent has to be base64 encoded otherwise the attachment is empty.Reference points to decoded data. |
By ReferenceContent has to be base64 encoded otherwise the attachment is empty.Reference points to decoded data. |
By ValueContent has to be base64 encoded otherwise the attachment is empty.attachment/body contains decoded data. |
By ReferenceContent has to be base64 encoded otherwise the attachment is empty.Reference points to decoded data. |
By ValueContent has to be base64 encoded otherwise the attachment is empty.attachment/body contains decoded data. |
QUOTED-PRINTABLE |
By ReferenceReference points to the original data |
By ReferenceReference points to the original data |
By ReferenceReference points to the original data |
By Value.attachment/body contains the original data |
By ReferenceReference points to the original data |
By Valueattachment/body contains the original data |
8BIT |
By ReferenceReference points to the original data |
By ReferenceReference points to the original data |
By ReferenceReference points to the original data |
By Value.attachment/body contains the original data |
By ReferenceReference points to the original data |
By Valueattachment/body contains the original data |
7BIT |
By ReferenceReference points to the original data |
By ReferenceReference points to the original data |
By ReferenceReference points to the original data |
By Value.attachment/body contains the original data |
By ReferenceReference points to the original data |
By Valueattachment/body contains the original data |
Binary |
By ReferenceReference points to the original data |
By ReferenceReference points to the original data |
By ReferenceReference contains the original data |
By Value.attachment/body contains the original data |
By ReferenceReference points to the original data |
By Valueattachment/body contains the original data |
none |
By ReferenceReference points to the original data |
By ReferenceReference points to the original data |
By ReferenceReference points to the original data |
By Value.attachment/body contains the original data |
By ReferenceReference points to the original data |
not valid |
Exceptional case
application/xml or application/xhtml+xml |
|
BASE64 |
By Valueif the decoded string is a xml-structure then attachment/body contains this xml-structure rather than a reference to it. If the decoded string is not an xml-structure then the attachment will be rejected. |
QUOTED-PRINTABLE |
By Valuethe data will be passed if contain a valid xml-structure otherwise will be rejected. |
8BIT |
By Valuethe data will be passed if contain a valid xml-structure otherwise will be rejected. |
7BIT |
By Valuethe data will be passed if contain a valid xml-structure otherwise will be rejected. |
Binary |
By Valuethe data will be passed if contain a valid xml-structure otherwise will be rejected. |
none |
By Valuethe data will be passed if contain a valid xml-structure otherwise will be rejected. |
Using this matrix one can take the appropriate steps in order to process the contents of the attachments.
Literature
[1] The Content-Type Header Field s. http://www.w3.org/Protocols/rfc1341/4_Content-Type.html
[2] The Content-Transfer-Encoding Header Field s. http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
[3] MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
2 Kommentare
Pingback: Handling inbound Attachments by Oracle Service bus – Part 2 | The Cattle Crew Blog
Pingback: SOA & BPM Community Newsletter December 2015 | SOA Community Blog