There is an existing application which consumes a webservice. Now I want to make a new webservice for this application. I have no access to the source of this application. In the existing application it should be possible to just change the wsdl url definition and everything works as before.
So at least, I'm trying to prey an existing webservice. In that case the returned soap response must be the same as the existing one.
Now my question: How can I change the wcf soap response xml?
For example if we create a new wcf project in VS we get the Service.svc. In this project there is a built in wcf test client:
With MessageContracts I can't accomplish what I want.
With the IClientMessageInspector implementation I'm able to hook up the response soap xml and do changes but this only works from a separate client project. I want access this soap xml response in the same webservice project and do changes before it gets sent out to the wcf test client window.
Any ideas on how I can do this?
You can use the IDispatchMessageInspector to modify the outgoing response.
https://msdn.microsoft.com/library/ms733104(v=vs.100).aspx
I.e. IDispatchMessageInspector is what is used to inspect (and modify) the messages on the server (applies to both incoming and/or outgoing messages).
Related
I'm writing an application using Visual Studio 2010 that needs to communicate with a remote web service. Because the amount of data being submitted is potentially large, (up to 100MB), the service's documentation says that the request message must be sent using GZIP HTTP compression.
My question is how to do that, given that I'm just calling a method on the proxy object that Visual Studio generated, and not actually performing the POST myself? In other words, since there isn't a "request" anywhere in my code to GZIP, how can I tell WCF to do it for me?
I've connected to the service by adding a service reference to my application using the WSDL provided, then invoking a method on the Visual Studio generated proxy to submit the request. An exception is thrown with the message "Request message must be sent using HTTP compression." (This is not unexpected, of course.)
Is there an attribute within the web.config settings that define the WCF service that will cause WCF to GZIP the request before sending it to the remote host?
Note: I've spent significant time searching the web about this, but the problem is that most posts assume that it's the web service's response that needs to be compressed. In my case, however, it's the request that's being sent from my client.
It seems like I have been able resolve this issue in a way that makes no sense to me from a "why does this even exist" way.
First, I was working on the same task as you: trying to use proxy objects to create a web request, and ended up running into the same issue being unable to compress the client object.
The resolution I ended up with was manually creating an XDocument object (XmlDocument would work as well) which has the same structure as the required SOAP XML, and then used the (already) populated proxy object to populate the necessary XML values in the string of SOAP XML.
From there I made a HttpWebRequest object and added the appropriate headers to the request. One of the headers was for compression. Executing the code resulted in getting an entirely different, non-compression related, error.
You can see my solution for the HttpWebRequest here: Compress a HttpWebRequest using gzip
It seems silly that it isn't easy to do through this the proxy object; however, it may be that the third-party did not expose what is necessary in order to add properties to the request header and either a.) they don't know or b.) they don't care, but that's what we have to work with, unfortunately.
I had to figure something out as I am on a deadline, but I hope this helps you out as well.
Have you tried adding <binaryMessageEncoding /> to the <customBinding /> element? I think we are working on similar tasks and I am also receiving the above FaultException. Two other SO topics led me down asking this question. It's something that makes sense, as I'm also not making a WebRequest through the code, but calling the service through the Service Reference created when I imported the WSDL provided by the third-party.
WCF custom binding for compression (a code-based approach)
and
WCF client endpoint compression (a configuration-based approach)
Let me know if you have any success with the above approaches.
Edit
An answer in the following thread indicates that unless you have control over the web service and the client, it might be something that can be done.
Using compression with C# webservice client in Visual Studio 2010
Edit #2
I think a few folks have been able to make progress in compressing a third-party service request using GZip. Please check out this post: Getting error for content mismtach while consuming client web service.
That post helped me get rid of the error message I was receiving (which was telling me that the request must be made using HTTP compression). I hope it helps you as well.
The request message must be sent using HTTP compression (RFC 1952 - GZIP).
We are building a C# Windows Service to host a WCF service integrated with a legacy C++ backend that will service requests made to the WCF service.
Is it possible to construct the C# front-end so that it accepts a minimum SOAP request (possibly a default query in the envelope) and then pass the entire SOAP message (or at least the XML contents of the envelope) to the C++ backend for interpretation so that the details of the interface don't have to be duplicated in C# or exposed to clients of the service (which would know which requests are available and the data structures required for each)?
We would also need to be able to construct partial XML in the C++ backend which the C# front-end would then insert into a SOAP envelope to make the response.
Is it sensible to target using SOAP for this or would it simplify things to use a simpler XML structure (home-grown or alternate standard) that can be passed in its entirety to the backend where the entire response would be constructed?
Thanks for reading, any advice welcomed :)
we have a legacy middleware application and we want to implement WCF Adapter for it. lets say for the time being we would only be consuming WCF service. the middleware is capable of processing XML messages. we would like to get the message xml from middleware, forward it to WCF client. after getting the response we would like to reply the middleware with the response xml.
following are few of our concerns that we would like to be looked into.
we should be able to send raw xml instead of object based WCF invocation
upon receiving the xml after all the layers of WCF (this is important since the validations of xml itself should already be performed according to contract) we will be forwarding it to middleware.
our middleware implements classical webservices but there are various concerns with the datacontract serializer. one of those is object references. as we can already see that the reference of the object is kept by using id attribute in xml element. how could we catter that. are there any further things that we may consider for data contract serializer.
Middleware is concerned about the original message itself. we would like other message related properties like SOAP, WS-Security etc be handled by WCF proxy itself.
Does anyone has any idea how Biztalk adapter for WCF works
any feedback would be appreciated.
1) What you're looking for is known as POX (Plain Old XML). WCF supports this using the WebHttpBinding. Here's a good starting point.
It's not strictly speaking "raw XML" because WCF decides what to send, but what comes out is a plain XML document rather then a SOAP message. If you can't get WCF to send what you want even with something like POX, then it might make more sense to skip WCF for that component and simply open a socket to your middleware layer and send the XML directly. In that case you really can send exactly what the legacy middleware app expects. WCF could still handle the client-facing connections.
2) If you have a WCF service facing the client, WCF will parse the client message and give you some kind of object in your code (depending on the service contract). At that point it's up to your WCF service code to either use another WCF connection to contact the middleware, or as I mentioned open a socket and send the necessary request. But stripping off the WCF "stuff" is done for you before your service method will start.
4) That should be no problem. WCF and your code will handle that before sending anything to the middleware.
Hope that helps a bit. :)
I've got a simple WCF Web service that uses basicHttpBinding to make it SOAP 1.1 compliant. When called with a WSDL-derived proxy (by setting a service or Web reference), the service works great.
A business partner wants to call the service directly with the SOAP XML. I know how to provide that XML, but I'm not sure how to process the XML when the business partner submits the request.
Am I making this harder than I need to? Will the XML request call the service as though it were called through the proxy and will the response naturally make the request happy? Or do I need to do something extra to process the XML request and then hand something (what?) off to my service?
I know there are some similar questions on SO, but they all seem to deal with the issue of getting the XML, not processing it.
It should be sufficient to just send the raw SOAP message to the endpoint URL of the service. The WSDL-derived proxy just generates the SOAP from your objects and manages connection handling and transport (probably HTTP) details.
It might be possible that you need to add a SOAPAction HTTP header, depending on the service.
If you intercept the communication between your WSDL-derived proxy and the servcie (e.g. using TCPmon), you will see the SOAP message and the used HTTP headers.
I am trying to use a SOAP Web Service provided by a third party. I am having trouble getting the service to work correctly in .NET 3.5. I have added it as a web reference and all seems to go well. Problem is when I call the service all I get returned is a NULL object. I have worked with the provider and there service appears to be working correctly. He did mention:
"We are using Axis2 Document/Literal and support SOAP 1 and 2."
I am not exactly sure what that means as I am a semi-newbie to using Web Services. Do I need to change some configuration parameters or something in .NET to get this service to work correctly?
From my experience, web service interoperability isn't the magic it claims to be. Especially, between .NET and Java.
Axis2 is a Java web service "engine"
Document/Literal is a style of writing a WSDL that results in a special SOAP appearance
SOAP 1 and 2 (you probably know) the message format and specific versions thereof
all I get returned is a NULL object
Is not much to start with, could you provide more information?
I would recommend, that you try to intercept the exchanged SOAP messages (you can use tcpmon) and check if they are valid. You would probably get an exception if the remote service can't handle your request so I guess your client as some trouble parsing the response. Additionally, you can use soapUI to generate example request to see what a valid request should look like.
Doc/lit (and at least SOAP 1) ought to work with WCF, but I'm not sure how the legacy (pre-.NET 3.0) web service client deals with that.
Did you, in Visual Studio, add a web reference or a service reference? If you added a web reference, you are not using WCF, which may be the reason it's not working. If this is the case, you should delete the web reference and see if adding a service reference instead helps.
It sounds like the proxy that you have generated (via add web reference) is not de-serializing the xml into the type you expect.
As wierob suggests the first thing I would do is trace the messages that you send to the service and the response you receive - that way you can examine the xml you can check that the proxy is creating a suitable request message and see whether the response does contain data that is not being de-serialized into the object you expect
As well as tcpmon you could use fiddler (from microsoft) to trace the traffic or the simplest would be to switch on the message tracing in WCF to log the request and response to files which could then you examined in the service trace viewer tool
With these kind of interoperability issues I find the best thing is to look at the message "on the wire" first - you may then have to tweak the wsdl so that the proxy gets generated correctly or hand craft the proxy yourself
If you post the wsdl and your proxy that might give us a clue as to the issues