Keeping MTOM Relaxed for Oracle SOA Suite

Keeping MTOM Relaxed for Oracle SOA Suite

Published on: Category: Oracle

MTOM is used in SOAP to separate binary attachments from the actual XML payload in a request or response. Oracle SOA Suite gracefully supports MTOM simply by defining the MTOM policy on the composite level. However, since Oracle SOA Suite the MTOM policy implementation changed, enforcing MTOM more strictly than before. Potentially breaking your existing implementation. We will briefly show the scenario in which your service implementation can break, followed by the solution.

What changed?

Imagine a SOAP PDF Document Service, which enables clients to fetch a PDF document based on a DocumentID.

Fig 1
Fig 1: PDFService composite

The request consists of a documentID string element, the response is a base64Binary element as defined in the WSDL (figure 2).

  1. <?xml version= '1.0' encoding= 'UTF-8' ?>
  2. <wsdl:definitions
  3. name="PDFService"
  4. targetNamespace=""
  5. xmlns:tns=""
  6. xmlns:wsdl=""
  7. >
  8. <wsdl:types>
  9. <schema xmlns="" targetNamespace=""
  10. elementFormDefault="qualified">
  11. <element name="DocumentID" type="string"/>
  12. <element name="base64Binary" type="base64Binary"/>
  13. </schema>
  14. </wsdl:types>
  15. <wsdl:message name="requestMessage">
  16. <wsdl:part name="request" element="tns:DocumentID"/>
  17. </wsdl:message>
  18. <wsdl:message name="replyMessage">
  19. <wsdl:part name="document" element="tns:base64Binary"/>
  20. </wsdl:message>
  21. <wsdl:portType name="execute_ptt">
  22. <wsdl:operation name="getDocument">
  23. <wsdl:input message="tns:requestMessage"/>
  24. <wsdl:output message="tns:replyMessage"/>
  25. </wsdl:operation>
  26. </wsdl:portType>
  27. </wsdl:definitions>

Fig 2: PDFService.wsdl

The request for the PDF document is a simple string element, so no real use for enforcing MTOM on the request itself.  In SOA Suite 12c this was still possible by defining the MTOM policy on the composite and keep it disabled. This way the request did not have to comply with the MTOM policy, but it did instruct SOA Suite to apply MTOM on the response message (see fig 3).

Fig 3
Fig 3: WSMTOM Policy disabled

Since Oracle SOA Suite disabling this policy will completely disable all MTOM functionality. The only way of getting SOA Suite to send an MTOM response document is to enable the MTOM policy as well. Thus also enforcing clients to call this service with MTOM enabled. In effect breaking the client interface (figure 4).

Fig 4
Fig 4: Error calling an MTOM enabled service while not enforcing MTOM on the client side

As one can see based on figure 5 and 6 there is no big difference between MTOM messages except for a content-type on the HTTP header of the request. To be quite honest, the change to clients is minimal. However, a change is a change and clients are not always willing or capable to adapt.

  1. POST http://localhost:7001/soa-infra/services/default/PDFService/PDFService HTTP/1.1
  2. Content-Type: text/xml;charset=UTF-8
  3. SOAPAction: "execute"
  5. <soapenv:Envelope xmlns:soapenv="" xmlns:pdf="">
  6. <soapenv:Header/>
  7. <soapenv:Body>
  8. <pdf:DocumentID>12</pdf:DocumentID>
  9. </soapenv:Body>
  10. </soapenv:Envelope>

Fig 5: SOAP request without MTOM

  1. POST http://localhost:7001/soa-infra/services/default/PDFService/PDFService HTTP/1.1
  2. Content-Type: multipart/related; type="application/xop+xml"; start="<>"; start-info="text/xml"; boundary="----=_Part_7_1660008608.1566398322338"
  3. SOAPAction: "execute"
  4. MIME-Version: 1.0
  6. ------=_Part_7_1660008608.1566398322338
  7. Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
  8. Content-Transfer-Encoding: 8bit
  9. Content-ID: <>
  11. <soapenv:Envelope xmlns:soapenv="" xmlns:pdf="">
  12. <soapenv:Header/>
  13. <soapenv:Body>
  14. <pdf:DocumentID>12</pdf:DocumentID>
  15. </soapenv:Body>
  16. </soapenv:Envelope>
  17. ------=_Part_7_1660008608.1566398322338--

 Fig 6: SOAP request with MTOM enabled


Luckily, we were not the first encountering this issue, and searching Oracle Support quickly found us a patch. The patch can be found using patch number 29026751.

BPEL Is Not Accepting The Request Received From OSB Which Is Not In The MTOM Format(Oracle (Doc ID 2497644.1)


How to apply the solution however, was less obvious (figure 7)?

Fig 7
Fig 7: Solution instructions after applying patch

After decompiling the patch, we have extracted how to use the relaxed MTOM policy. Just add the property "oracle.webservices.wsmtompolicy.processrequest" onto the binding in the composite, and assign the value “relax” (see figure 8).

Fig 8
Fig 8: Relaxed MTOM composite property

After applying the patch and adding the property, we were once again able to call the service without MTOM on the request. Giving us a nice MTOM attachment as response (figure 9).

Fig 9
Fig 9: MTOM-less request, but MTOM response
Richard Velden
About the author Richard Velden

Oracle Fusion Middleware Developer at Qualogy. Specializes in integration and cloud development using Oracle technologies such as: SOA Suite, Service Bus, Integration and Process Cloud.

More posts by Richard Velden