Last week we decided to upgrade all our OSB project from OSB3 to OSB10GR3. A few of our project worked with attachment's which failed on new version of OSB. In this post we will explain briefly all the necessary step to upgrade project working with attachments to version 10g release 3.
Assume that, we have a proxy service which will get arbitrary MTOM attachment. First of all, after exporting the project on workspace we must enable mtom support on proxy properties page. When XOP/MTOM Support is enabled, you can further select how to handle binary data in the $header and $body message context variables from among the following options:
* Include Binary Data by Reference: (Default) In an inbound request message, replace xop:Include elements with ctx:binary-content elements when setting up the $header and $body message context variables.
* Include Binary Data by Value: In an inbound request message, replace xop:Include elements with Base64-encoded text versions of corresponding binary data when setting up the $header and $body message context variables.
You can use Include Binary Data by Reference when you need direct access to binary data, for example to pass data to a Java callout or Message Format Language (MFL) transform.
You can use Include Binary Data by Value in the following cases:
* To bridge between MTOM and non-MTOM services. For example, consider an MTOM-enabled proxy service that receives a request that is then routed to a non-MTOM-enabled service. You could use this option to comply with existing standards for sending binary data in XML in Base64-encoded form.
* To validate the contents of the message against an XML schema that requires a base64binary element to be used in place of binary data
Note that if XOP/MTOM Support is enabled for a proxy service, it is not required that every inbound message be in the MTOM format. Instead, this setting specifies that when an MTOM-formatted message arrives, the proxy service should handle it accordingly. Note also that when proxy services not enabled for XOP/MTOM Support receive an MTOM-formatted message, the service rejects the message and issues a runtime error.
When XOP/MTOM support enable on proxy service, the variable $attachment will no longer active. For example on version OSB3 we could define total attachment by following xpath statement as follows:
fn:count($attachment/attachments)
Above frugment of xpath will return 0, because on version 10gR3, MTOM attachment will no longer available in variable $attachment.
When the Binary by Reference option is selected, Oracle Service Bus parses the root of the message checking for the presence of xop:Include tags. These tags, when found, are converted to ctx:binary-content elements with a reference pointing to the corresponding source in binary repository. The resulting document is represented by the $body message context variable.
This means that when pipeline actions access the contents of the $body message context variable, the actions do not encounter xop:Include elements, but instead work with ctx:binary-content elements.
As example:
Guess, from the client side we have sent following soap message with attachment
In Osb $body variable you will get following transformed of code:
con:binary-content element will hold the reference of the binary data on hash table. We can easily get the content of the binary data and send it to save on file or drive it to ftp or email attachment. For more information see my previous post.
See for detail information.
Assume that, we have a proxy service which will get arbitrary MTOM attachment. First of all, after exporting the project on workspace we must enable mtom support on proxy properties page. When XOP/MTOM Support is enabled, you can further select how to handle binary data in the $header and $body message context variables from among the following options:
* Include Binary Data by Reference: (Default) In an inbound request message, replace xop:Include elements with ctx:binary-content elements when setting up the $header and $body message context variables.
* Include Binary Data by Value: In an inbound request message, replace xop:Include elements with Base64-encoded text versions of corresponding binary data when setting up the $header and $body message context variables.
You can use Include Binary Data by Reference when you need direct access to binary data, for example to pass data to a Java callout or Message Format Language (MFL) transform.
You can use Include Binary Data by Value in the following cases:
* To bridge between MTOM and non-MTOM services. For example, consider an MTOM-enabled proxy service that receives a request that is then routed to a non-MTOM-enabled service. You could use this option to comply with existing standards for sending binary data in XML in Base64-encoded form.
* To validate the contents of the message against an XML schema that requires a base64binary element to be used in place of binary data
Note that if XOP/MTOM Support is enabled for a proxy service, it is not required that every inbound message be in the MTOM format. Instead, this setting specifies that when an MTOM-formatted message arrives, the proxy service should handle it accordingly. Note also that when proxy services not enabled for XOP/MTOM Support receive an MTOM-formatted message, the service rejects the message and issues a runtime error.
When XOP/MTOM support enable on proxy service, the variable $attachment will no longer active. For example on version OSB3 we could define total attachment by following xpath statement as follows:
fn:count($attachment/attachments)
Above frugment of xpath will return 0, because on version 10gR3, MTOM attachment will no longer available in variable $attachment.
When the Binary by Reference option is selected, Oracle Service Bus parses the root of the message checking for the presence of xop:Include tags. These tags, when found, are converted to ctx:binary-content elements with a reference pointing to the corresponding source in binary repository. The resulting document is represented by the $body message context variable.
This means that when pipeline actions access the contents of the $body message context variable, the actions do not encounter xop:Include elements, but instead work with ctx:binary-content elements.
As example:
Guess, from the client side we have sent following soap message with attachment
<?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:SubmitAttachmentRequestEle xmlns:ns2="http://www.ru.fors.nsi/SOAPwithAttachment/"> <messageId>messageId</messageId> <senderAppName>fts NSI</senderAppName> <receiver>rtu-1</receiver> <department>department</department> <attaches> <Attach> <documentName>test.doc</documentName> <zipFile> <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:83842c6c-2dbc-459d-98b1-f185f89ce9ec@example.jaxws.sun.com"/> </zipFile> <comment>comment</comment> </Attach> <Attach> <documentName>README.txt</documentName> <zipFile> <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:ea1779f1-4477-46b5-8364-9a525f49c734@example.jaxws.sun.com"/> </zipFile> <comment>comment2</comment> </Attach> </attaches> </ns2:SubmitAttachmentRequestEle> </S:Body> </S:Envelope>
In Osb $body variable you will get following transformed of code:
<attaches xmlns:ns2="http://www.ru.fors.nsi/SOAPwithAttachment/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <Attach> <documentName>test.doc</documentName> <zipFile> <con:binary-content ref="cid:1c6b1828:120c78cd5fd:-7fd4" xmlns:con="http://www.bea.com/wli/sb/context"/> </zipFile> <comment>comment1</comment> </Attach> <Attach> <documentName>README.txt</documentName> <zipFile> <con:binary-content ref="cid:1c6b1828:120c78cd5fd:-7fd3" xmlns:con="http://www.bea.com/wli/sb/context"/> </zipFile> <comment>comment2</comment> </Attach> </attaches>
con:binary-content element will hold the reference of the binary data on hash table. We can easily get the content of the binary data and send it to save on file or drive it to ftp or email attachment. For more information see my previous post.
See for detail information.
Comments