OutSystems 11
I am attempting to use a SOAP integration with a WSDL, which OutSystems picks up and reads just fine, but when attempting to use the webservice at run-time, I receive this error:
Content Type application/soap+xml; charset=utf-8 was not supported by service https://webservice.address/action.svc. The client and service bindings may be mismatched.
The owner of the webservice says that his side of the integration is "WCF", which means little to me, and I have have little luck with Googling how to get OutSystems to talk to this style of integration. If anyone has any insight, I'd much appreciate it.
Hi Chris,
In that case you need a BinaryMessageEncodingBindingElement instead of a text one. The only way to do that is create an action in .NET and call that as part of an OnBeforeRequest (Advanced), see here.
I am not sure how this man thinks WCF will get you to the right solution.
If you are consuming a SOAP, you will use a WSDL to create the webservice and methods in Outsystems. This process will not create security settings other than Basic authentication.
you should check which authentication this SOAP has and then we can try to get it solved.
Did you get the SOAP working in SOAP UI or postman?
OutSystems only gives Basic Authentication as the option (other than None). I entered the credentials provided by the webservice owner, but still get the same error.
I understand. I think i was too fast with my assumption. I did it based on your "binding".
But in this case i think Kilian has a point: it might be the Content Type.
I also searched the internat and got someone with this same error, but he had somehow (not in Outsystems) changed the SOAP version from 1.2 to 1.1.
Did you get it working in SOAP UI or Postman?
No, I get the same error in SoapUI. Not familiar with Postman. In SoapUI, though, if I leave out the credentials, I get the content type error. If I put the credentials in, I get a 400 Bad Request error. More confusing...
See my post below. msbin is a proprietary Microsoft binary SOAP format used with WCF. Since OutSystems also uses WCF, you can produce that, but the owner of the webservice should be chastised for creating such an inoperable web service!
I had same kind of problems when connecting to the KvK dataservice in the Netherlands. Different authorization, same problem (binding).
First step is always to get it working in SOAPui or Postman. it really helps testing, but also because it proves the webservice works with your provided credentials (or certificate).
Good luck with your project. It can be tiresome, but the more difficult the problem, the more rewarding you will feel when you succeed!
Luckily the KvK Dataservice is a thing of the past... They've moved on to REST, thank heavens. But at least they didn't use a proprietary Microsoft encoding...
Can i send you a private message on this matter?
I haven't heard KVK moving to rest. I did hear the profile service is changing. Love to get more info on that.
WCF (Windows Communication Foundation) is the standard way of exposing and consuming SOAP and REST services in Windows and .NET, and is also used by OutSystems. So if you consume an external SOAP service you are also using WCF under the hood.
I find it odd that the webservice refuses a application/soap+xml, since that's afaik the standard Content Type for SOAP. Before even to try to send a different content type, you need to know first what content type the external service does except. Note that this has nothing to do with it being WCF, so if that's all the "owner of the webservice" can supply, you're pretty much stuck.
Apologies - I thought my original post showed the content type the webservice wanted. It's saying it expects "application/soap+msbin1":
HTTP/1.1 415 Cannot process the message because the content type 'application/soap+xml;charset=UTF-8;action="http://different.site/IServiceName/ServiceName"' was not the expected type 'application/soap+msbin1'.
I have no experience with msbin, which is binary?
do you have the wsdl? can you share it?
I was able to install SOAP Extensibility and set the content type and encoding headers. When I sent my request, I got no errors on my side of the integration, though the action was ultimately not completed on the target side (which is 100% better than we were doing before). I think I'm clear for the moment. Thanks for this suggestion - I had misread the article on SOAP Extensibility previously - didn't realize it was a Forge component.
You haven't misread, the SOAP Extensibility Forge asset is not directly related to the SOAP Extensibility API article. It can be a handy tool though, although creating your own Extension based on the article isn't too difficult.