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 12.2.1.3 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.

The request consists of a documentID string element, the response is a base64Binary element as defined in the WSDL (figure 2).
<?xml version='1.0' encoding='UTF-8'?>
<wsdl:definitions name="PDFService"
targetNamespace="http://qualogy.com/SOAMTOM/PDFService/PDFService"
xmlns:tns="http://qualogy.com/SOAMTOM/PDFService/PDFService"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://qualogy.com/SOAMTOM/PDFService/PDFService"
elementFormDefault="qualified">
<element name="DocumentID"
type="string"/>
<element name="base64Binary"
type="base64Binary"/>
</schema>
</wsdl:types>
<wsdl:message name="requestMessage">
<wsdl:part name="request"
element="tns:DocumentID"/>
</wsdl:message>
<wsdl:message name="replyMessage">
<wsdl:part name="document"
element="tns:base64Binary"/>
</wsdl:message>
<wsdl:portType name="execute_ptt">
<wsdl:operation name="getDocument">
<wsdl:input message="tns:requestMessage"/>
<wsdl:output message="tns:replyMessage"/>
</wsdl:operation>
</wsdl:portType>
</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).

Since Oracle SOA Suite 12.2.1.3 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).

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.
POST http://localhost:7001/soa-infra/services/default/PDFService/PDFService HTTP/1.1
Content-Type: text/xml;charset=UTF-8
SOAPAction:"execute"
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:pdf="http://qualogy.com/SOAMTOM/PDFService/PDFService">
<soapenv:Header/>
<soapenv:Body>
<pdf:DocumentID>12</pdf:DocumentID>
</soapenv:Body>
</soapenv:Envelope>
Fig 5: SOAP request without MTOM
POST http://localhost:7001/soa-infra/services/default/PDFService/PDFService HTTP/1.1
Content-Type: multipart/related; type="application/xop+xml"; start="<[email protected]>"; start-info="text/xml"; boundary="----=_Part_7_1660008608.1566398322338"
SOAPAction:"execute"
MIME-Version:1.0
------=_Part_7_1660008608.1566398322338
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: 8bit
Content-ID:<[email protected]>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:pdf="http://qualogy.com/SOAMTOM/PDFService/PDFService">
<soapenv:Header/>
<soapenv:Body>
<pdf:DocumentID>12</pdf:DocumentID>
</soapenv:Body>
</soapenv:Envelope>
------=_Part_7_1660008608.1566398322338--
Fig 6: SOAP request with MTOM enabled
Solution
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.
Patch 29026751: NEED TO BIND WSMTOM_POLICY TO REQUEST AND RESPONSE SEPARATELY
BPEL Is Not Accepting The Request Received From OSB Which Is Not In The MTOM Format(Oracle 12.2.1.3) (Doc ID 2497644.1)
With associated bug: Bug 28972821: NEED TO CONFIGURE SEPARATE WSMTOM_POLICIES FOR REQUEST AND RESPONSE
How to apply the solution however, was less obvious (figure 7)?

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).

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).
