Solution

Several of our customers have asked us how to allow for attachments on a SOAP service that does not have a WSDL defined to accept attachments. Often these arrive from a 3rd party and the customer cannot edit them. While this is easily facilitated by checking the 'Allow for operations not intended for this WSDL' box on the service properties, this often leaves the service more open than customers would like, as they wish to keep WSDL validation on the message payload, and simply allow for attachments.

Work arounds:
1. In policy, add the Decode MTOM assertion.?MTOM messages have additional MIME components as well. The assertion, in part, marks the service as one that accepts additional MIME attachments. swaRef is also facilitated by enabling this message structure. The proper method of resolving this would be to modify your WSDL to allow for attachments. This solution is a work around that we can facilitate within our product, using an assertion that is named for its created purpose, not for it's functionality as a potential work around. We do have an option in the service properties to allow for operations not intended for your WSDL. Checking this would be the 'proper' method to facilitate this use case if you are unable to modify your WSDL, however that completely opens up the service, so often using this work around is more desirable. This method is defined below.

2. Checking the 'Allow for operations not intended for this WSDL' box on the service properties allows for attachments to come through with the payload, but this also allows for SOAP Ops not allowed by WSDL, not just attachments.

Environment

Release:
Component: APIGTW

Feedback

thumb_up Yes

thumb_down No