I am trying to post data from InfoPath using the WebServiceConnection, to a WFC service inside of AppFabric.
The messgae never arrives in AppFabric, and I think I know why.
My WCF service is configured like this
<endpoint address="Workflow1.xamlx" binding="basicHttpBinding" contract="WorkflowOperation" />
And when it is called by WCF Test Client, it generates the header
<s:Header>
<a:Action s:mustUnderstand="1">http://tempuri.org/WorkflowOperation/ReceiveFormPayload</a:Action>
</s:Header>
However, InfoPath does not generate this Soap header, it only generates the HTTP header
POST /Workflow1.xamlx HTTP/1.1
SOAPAction: "http://tempuri.org/WorkflowOperation/ReceiveFormPayload"
Content-Type: text/xml; charset="UTF-8"
User-Agent: SOAP Toolkit 3.0
Host: localhost:51842
Content-Length: 1893
Connection: Keep-Alive
Cache-Control: no-cache
How do I configure my WCF endpoint to only need the HTTP-header action, and not the Soap Action?
Well, I'm back again, with the answer for anyone who is interested in getting InfoPath to submit data to an AppFabric service.
The .NET BasicHttpBinding uses a combination of Soap1.2+WSAddressing1.0 - while the InfoPath client will ONLY submit to web services using Soap1.1 (with NO WSAddressing support) - rending the two completely incompatible.
I actually ended up having to write an intermediary broker which would adapt the invocations.
Many thanks to "codemeit" for a very descriptive page of the composition of the various WCF binding types.
Related
How to enable WS-Addressing in Web service Consumer of Mulesoft.
When I search for WS-Addressing in mulesoft. It points to CXF. However the docs point that it's recommended to use web service consumer rather than CXF.
So is there any way to enable WS-Addressing. SoapAction is added into the WSDL
POST /esi2/esi-gateway/v2/common/v1 HTTP/1.1
SOAPAction: "http://www.macquarie.com/...."
Host: www.macquarie.com
User-Agent: AHC/1.0
Connection: keep-alive
Accept: */*
Content-Type: text/xml; charset=UTF-8
Content-Length: 1453
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-2004
...................
When Tested in SOAP UI I can find WS-A with all the details filled. How can i get a similar stuff in Mulesoft
Note :- This is the official answer. And it works. Fix the dummy web address in TO, Action and messageID.
Please add the following before webservice consumer . you should be set to go
<set-property propertyName="soap.to" value="<wsa:To xmlns:wsa="http://www.w3.org/2005/08/addressing">http://www.asdfadsf.com/esi/common/v1</wsa:To>" doc:name="Soap.To"/>
<set-property propertyName="soap.Action" value="<wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing">http://www.xyzdadadf.com/esi/common/1.0/getAuthenticationExpiryRequest</wsa:Action>" doc:name="soap.action"/>
<set-property propertyName="soap.messageID" value="<wsa:MessageID xmlns:wsa="http://www.w3.org/2005/08/addressing">urn:entity-name:version:1</wsa:MessageID>" doc:name="soap.messageID"/>
I post this in the form for larger community help.
I'm having problems talking to Java WS. I'm using "wsHttpBinding" binding with client certificates for authentication, message encoding is set "Text", .net framework is 4.0. Server side is Java and I have no control over it. Connection is being proxied through Fiddler (this is how I see requests on the wire, much more user friendly than tracing "System.Net").
Exception I get is following:
The content type application/xop+xml; type="application/soap+xml" of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8).
If I change message encoding to "Mtom", then the exception changes:
The content type application/xop+xml; type="application/soap+xml" of the response message does not match the content type of the binding (multipart/related; type="application/xop+xml").
Server is accepting both "Text" and "Mtom" message encodings for request, and response is always the same. This is the raw response that I'm getting from the server:
HTTP/1.1 200 OK
X-Backside-Transport: OK OK
Connection: Keep-Alive
X-Powered-By: Servlet/3.0
SOAPAction: ""
Content-Type: application/xop+xml; type="application/soap+xml"
Content-Language: en-US
Date: Thu, 25 Jul 2013 13:05:09 GMT
Content-Length: 628
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope ... </env:Envelope>
From all the docs which I have been reading, response that is being returned is somewhere between regular SOAP message and MTOM message. I'm saying this because every example which I've seen says that the MTOM request and response use MIME as an envelope for communication: regular SOAP message is enveloped in XOP package, and then this XOP message is enveloped with MIME. Even the W3C recommendation uses MIME for XOP packages: W3C: XML-binary Optimized Packaging. Excerpt from this link:
Content-Type: Multipart/Related;boundary=...
If I try calling web service using tool "soapUI" (written in Java, available from "www.soapui.org"), service call is successfully executed and response is parsed without any problem.
FYI, this is a cross-post from MSDN WCF forum., but no responses there yet.
Any idea is appreciated, thanks in advance,
Alex
I'm also using CXF, and has a C# client. Try modifying your binding setting, replace textMessageEncoding with mtomMessageEncoding. Something like this:
<binding name="yourSoapBinding">
<mtomMessageEncoding messageVersion="Soap12"/>
<httpTransport />
</binding>
Try setting the message encoding in the binding configuration to messageEncoding="Mtom" and basicHTTPBinding instead of wsHTTP one...
Hope it helps!
I'm building a WCF web service that requires interop with non-WCF clients (in fact, there will be no WCF clients).
I've already written a WSDL using SOAP 1.2 (as per this example). I've validated the WSDL and have used this file (not the WSDL generated by WCF, which is superficially different) to create a soapUI test project.
I have a requirement that the web service will support SOAP 1.2, so I can't just fall back to SOAP 1.1 (which worked just fine in an early prototype).
I've used WSCF.blue to generate my WCF service, interface, and data contract classes. Everything compiles nicely and the endpoint is exposed if I hit the WCF service in my browser. All seems well with the world.
When I try to call a method from soapUi I get the following response from the server (as visible from soapUI):
HTTP/1.1 415 Cannot process the message because the content type
'application/soap+xml;charset=UTF-8;action="http://tempuri.org/FetchMyThing"'
was not the expected type 'text/xml; charset=utf-8'.
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 30 Apr 2012 08:15:29 GMT
Content-Length: 0
(Actual method names and namespaces have been manually changed for the purposes of this question. Any typos in namespace are not errors in my code - just an oversight in typing up this question)
I know that SOAP 1.1 specifies that the content type must be text/xml. SOAP 1.2 requires application/soap+xml.
My raw request (as per soapUI):
POST http://localhost/MyWs.svc HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/soap+xml;charset=UTF-8;action="http://tempuri.org/FetchMyThing"
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:ns="http://tempuri.org">
<soap:Header/>
<soap:Body>
<ns:fetchMyThingRequest attribute1="1" attribute2="10">
</ns:fetchMyThingRequest>
</soap:Body>
</soap:Envelope>
From this response, it tells me that my request is properly formed - it's a SOAP 1.2 request with the correct content type. My WCF service, however, does not expect this content type, which I assume means I have not configured it correctly and it still thinks it's a SOAP 1.1 web service.
Minimal Web.config, as per this blog post:
<system.serviceModel>
<services>
<service name="MyNamespace.MyPort">
<endpoint address="" binding="customBinding" bindingConfiguration="httpSoap12" contract="IWsPort12" />
</service>
</services>
<bindings>
<customBinding>
<binding name="httpSoap12">
<textMessageEncoding messageVersion="Soap12" />
<httpTransport />
</binding>
</customBinding>
</bindings>
</system.serviceModel>
A snippet of the service contract:
[ServiceContract(Namespace = "http://tempuri.org")]
public interface IWsPort
{
[OperationContract(Action = "http://tempuri.org/FetchMyThing")]
[FaultContract(typeof(WsFault), Action = "http://tempuri.org/FetchMyThing", Name = "fetchMyThingFault")]
[XmlSerializerFormat(SupportFaults = true)]
FetchMyThingResponse FetchMyThing(FetchMyThingRequest request);
}
I enabled service tracing for my WCF service and see the following exception that seems to confirm my hypothesis:
Activity: Listen at 'http://mycomputer/MyWs.svc
<Exception>
<ExceptionType>System.ServiceModel.ProtocolException, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</ExceptionType>
<Message>Content Type application/soap+xml;charset=UTF-8;action="http://tempuri.org/FetchMyThing" was sent to a service expecting text/xml; charset=utf-8. The client and service bindings may be mismatched.
</Message>
(erroneous detail snipped)
</Exception>
So, my contract and service bindings are probably mismatched, if this message is to believed, but from what I understand of WCF my configuration (or at least the intent behind it) is correct.
Does anyone have any ideas as to what's wrong with my configuration?
The only thing I can think with it is that because you've not specified a binding in a lot of detail, and its using HTTP (as per this: "Listen at 'http://mycomputer/MyWs.svc'") then is it using the default (i.e. basicHttpBinding) for this, which is creating the mismatch?
I had the same issue when I had multiple bindings on my service. When I removed all bindings and only left one unnamed binding in place, the error message disappeared.
Please check this link How to: Configure WCF Service to Interoperate with ASP.NET Web Service Clients
.
To configure a Windows Communication Foundation (WCF) service endpoint
to be interoperable with ASP.NET Web service clients, use the
System.ServiceModel.BasicHttpBinding type as the binding type for your
service endpoint.
Also, defining two endpoints you can use HTTP and HTTPS versions of the same service
How do I set custom HTTP headers on an ESB proxy service Out Sequence? I'm trying to set "Access-Control-Allow-Origin" to allow my javascript/html front-end page to be able to GET the XML that is provided by this service. I also need to add a Cache-Control.
If there is a way to do this directly on my WSO2 Data Services Server (DSS), that would be preferable as it would avoid adding an ESB server to my process. According to this forum post from about a year ago, it's not possible: http://wso2.org/forum/thread/13991
I've tried it several ways, but looking at fiddler, the header is unchanged:
HTTP/1.1 200 OK
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 637
Date: Wed, 28 Mar 2012 20:58:31 GMT
Server: WSO2 Carbon Server
I'm somewhat new with WSO2 servers (more of a front-end dev), so the answer could be right in front of me.
You can do this by adding a Property mediator to the out-sequence. Once you set the property with the transport scope there, it will be added to the transport header of the out going message from the ESB.
This property mediator worked for me:
<property name="Access-Control-Allow-Origin" value="*" scope="transport" type="STRING"></property>
It allows access from any origin.
-Kari
When I try to access WCF client, I get the following error. I was able to access my service using IE and able to reference in VS 2010. My development environment is Windows server 2008. I hosted service in Sharepoint Project server. I am stuck with this error. Please advice.
"The content type text/html; charset=UTF-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. "
Here is some data Headers from Fiddler.
GET /_vti_bin/psi/helloservice.svc HTTP/1.1
Content-Type: text/xml; charset=utf-8
MicrosoftSharePointTeamServices: 14.0.0.4762
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-SharePointHealthScore: 4
WCF HTTP Activation must be enabled on the server. If the script maps for WCF are not installed you may receive the error.