{"id":21,"date":"2022-06-19T18:47:00","date_gmt":"2022-06-19T18:47:00","guid":{"rendered":"https:\/\/olyareri.nl\/?p=21"},"modified":"2022-07-01T18:50:31","modified_gmt":"2022-07-01T18:50:31","slug":"keeping-mtom-relaxed-for-oracle-soa-suite-12-2-1-3","status":"publish","type":"post","link":"https:\/\/olyareri.nl\/?p=21","title":{"rendered":"Keeping MTOM Relaxed for Oracle SOA Suite 12.2.1.3"},"content":{"rendered":"\n

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.<\/strong><\/p>\n\n\n\n

<\/p>\n\n\n\n

What changed?<\/h2>\n\n\n\n

Imagine a SOAP PDF Document Service, which enables clients to fetch a PDF document based on a DocumentID.<\/p>\n\n\n\n

\"Fig<\/a>
Fig 1: PDFService composite<\/figcaption><\/figure>\n\n\n\n

The request consists of a documentID string element, the response is a base64Binary element as defined in the WSDL (figure 2).<\/p>\n\n\n\n

<?xml version='1.0' encoding='UTF-8'?>\n<wsdl:definitions name=\"PDFService\"\n                  targetNamespace=\"http:\/\/qualogy.com\/SOAMTOM\/PDFService\/PDFService\"\n                  xmlns:tns=\"http:\/\/qualogy.com\/SOAMTOM\/PDFService\/PDFService\"\n                  xmlns:wsdl=\"http:\/\/schemas.xmlsoap.org\/wsdl\/\">\n\t<wsdl:types>\n\t\t<schema xmlns=\"http:\/\/www.w3.org\/2001\/XMLSchema\"\n\t\t        targetNamespace=\"http:\/\/qualogy.com\/SOAMTOM\/PDFService\/PDFService\"\n\t\t        elementFormDefault=\"qualified\">\n\t\t\t<element name=\"DocumentID\"\n\t\t\t         type=\"string\"\/>\n\t\t\t<element name=\"base64Binary\"\n\t\t\t         type=\"base64Binary\"\/>\n\t\t<\/schema>\n\t<\/wsdl:types>\n\t<wsdl:message name=\"requestMessage\">\n\t\t<wsdl:part name=\"request\"\n\t\t           element=\"tns:DocumentID\"\/>\n\t<\/wsdl:message>\n\t<wsdl:message name=\"replyMessage\">\n\t\t<wsdl:part name=\"document\"\n\t\t           element=\"tns:base64Binary\"\/>\n\t<\/wsdl:message>\n\t<wsdl:portType name=\"execute_ptt\">\n\t\t<wsdl:operation name=\"getDocument\">\n\t\t\t<wsdl:input message=\"tns:requestMessage\"\/>\n\t\t\t<wsdl:output message=\"tns:replyMessage\"\/>\n\t\t<\/wsdl:operation>\n\t<\/wsdl:portType>\n<\/wsdl:definitions><\/code><\/pre>\n\n\n\n
Fig 2: PDFService.wsdl<\/strong><\/em><\/p>\n\n\n\n
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).<\/p>\n\n\n\n
\"Fig<\/a>
Fig 3: WSMTOM Policy disabled<\/figcaption><\/figure>\n\n\n\n
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).<\/p>\n\n\n\n
\"Fig<\/a>
Fig 4: Error calling an MTOM enabled service while not enforcing MTOM on the client side<\/figcaption><\/figure>\n\n\n\n
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.<\/p>\n\n\n\n
POST http:\/\/localhost:7001\/soa-infra\/services\/default\/PDFService\/PDFService HTTP\/1.1<\/em>\nContent-Type: text\/xml;charset=UTF-8\nSOAPAction:\"execute\"\n\n<soapenv:Envelope xmlns:soapenv=\"http:\/\/schemas.xmlsoap.org\/soap\/envelope\/\" xmlns:pdf=\"http:\/\/qualogy.com\/SOAMTOM\/PDFService\/PDFService\">\n  <soapenv:Header\/>\n  <soapenv:Body>\n    <pdf:DocumentID>12<\/pdf:DocumentID>\n  <\/soapenv:Body>\n<\/soapenv:Envelope><\/code><\/pre>\n\n\n\n
Fig 5: SOAP request without MTOM<\/strong><\/em><\/p>\n\n\n\n
POST http:\/\/localhost:7001\/soa-infra\/services\/default\/PDFService\/PDFService HTTP\/1.1<\/em>\nContent-Type: multipart\/related; type=\"application\/xop+xml\"; start=\"<rootpart@soapui.org>\"; start-info=\"text\/xml\"; boundary=\"----=_Part_7_1660008608.1566398322338\"\nSOAPAction:\"execute\"\nMIME-Version:1.0\n\n------=_Part_7_1660008608.1566398322338\nContent-Type: application\/xop+xml; charset=UTF-8; type=\"text\/xml\"\nContent-Transfer-Encoding: 8bit\nContent-ID:<rootpart@soapui.org>\n<soapenv:Envelope xmlns:soapenv=\"http:\/\/schemas.xmlsoap.org\/soap\/envelope\/\" xmlns:pdf=\"http:\/\/qualogy.com\/SOAMTOM\/PDFService\/PDFService\">\n  <soapenv:Header\/>\n  <soapenv:Body>\n    <pdf:DocumentID>12<\/pdf:DocumentID>\n  <\/soapenv:Body>\n<\/soapenv:Envelope>\n------=_Part_7_1660008608.1566398322338--<\/code><\/pre>\n\n\n\n
 Fig 6: SOAP request with MTOM enabled<\/strong><\/em><\/p>\n\n\n\n
Solution<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
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)<\/strong><\/em>
With associated bug: Bug 28972821: NEED TO CONFIGURE SEPARATE WSMTOM_POLICIES FOR REQUEST AND RESPONSE<\/em><\/p>\n\n\n\n
How to apply the solution however, was less obvious (figure 7)?<\/p>\n\n\n\n
\"Fig<\/a>
Fig 7: Solution instructions after applying patch<\/figcaption><\/figure>\n\n\n\n
After decompiling the patch, we have extracted how to use the relaxed MTOM policy. Just add the property “oracle.webservices.wsmtompolicy.processrequest<\/strong>” onto the binding in the composite, and assign the value \u201crelax<\/strong>\u201d (see figure 8).<\/p>\n\n\n\n
\"Fig<\/a>
Fig 8: Relaxed MTOM composite property<\/figcaption><\/figure>\n\n\n\n
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).<\/p>\n\n\n\n
\"Fig<\/a>
Fig 9: MTOM-less request, but MTOM response<\/figcaption><\/figure>\n\n\n\n