I have an application which can just send SOAP messages and parse responses. My WCF service works fine if i use proxy client, but i need to have ability just send POST request in SOAP format as it was in old ASMX services. Is there any possibility to do it?
I tried copy SOAP request from debug wcf client and send it as POST request with Content-Type text/xml but it doesn't give me a correct result.
Yes, you can call them using a "plain" HTTP request - after all, as far as the server is concerned all it receives are bytes in a TCP connection. Depending on the binding which you're using, you may also need to set some HTTP header - if you're using BasicHttpBinding on your service, you'll also need to set the SOAPAction header. Try sending your request, and your request from a client using a WCF proxy, and compare them in a tool such as Fiddler. If the requests are the same, the server will respond them the same as well.
When I need to pass the full soap message by http web request, I use SoapUI. You can give it a WSDL and it does what the proxy does for code, but instead generates soap xml. And as #carlosfigueira mentioned you will want to look in the HTTP Headers section and set them appropriately.
www.soapui.org
Related
We have a SOAP proxy generated using Visual Studio connected services tooling (VS2017).
When we call an .asmx endpoint the SOAP proxy works perfectly.
When we communication to API Management endpoint, which is directed to go to
the same .asmx endpoint it fails.
When we communicate using Postman to API Managemenet endpoint the
call works, we took the HTTP headers and the SOAP body from a fiddler trace.
So in summary
We know the .asmx endpoint works when using the SOAP client and also postman.
We know API Management works over Postman, but not using the SOAP client generated by the tooling from the WCF.
We basically get back a 404 when calling API management and a small JSON body returned
{ "statusCode": 404, "message": "Resource not found" }
I just can't understand why the same response passed out over Postman works, but fails in the underlying WCF SOAP generated client.
Any one got an idea's why this may be failing?
One interesting thing to note is I tried the call using a HTTPClient, I passed in the headers and SOAP envelope and the call worked from C#. So it must be something to do with the underlying WCF infrastructure and API Management, but I just can't determine what that could be, particularly as the SOAP client works when talking to the ASMX service directly.
Just could not get to the bottom of this. I ended up rewriting the proxy manually using a HTTP client. I took the code generated XML entities from the tooling, removed all XML attributes and treated them just like POCO. I wrote a wrapper to generate the SOAP Envelope and read the corresponding result and serialize them back into the POCO objects.
Worked like a charm.
I am wanting to log information about the HTTP requests I send through my C# ASP.NET Web Application.
I want to log the proxy used for the request.
The requests use the default proxy specified by the web.config, but the default proxy has a bypass list and when the request is to one of the domains specified by the bypass list, it will not use the proxy.
I'm guessing that there must be information in the HTTP request about the proxy that its going to use or maybe in the response in the proxy it used.
You can capture this via the Via (pun intended) response header:
Informs the client of proxies through which the response was sent.
Via: 1.0 fred, 1.1 example.com (Apache/1.1)
I have a C# client application that works with a web service using SOAP request. I've generate the requests C# code from the services web address using VS05 WSDL. I want the client in case of an error to print to a log file the SOAP request and response.
It's need to be done in run time.
how can it be done?
You might check the following blog post for an example of writing a custom SoapExtension that will allow you to achieve this.
How can I get the SOAP header of my web service function as xml?
I need an XML version of my working SOAP header to use as an example for someone with broken SOAP headers. He's using a different programming language, but since the headers are sent in XML, we're hoping we can compare those easily. I'm using C# and ToString() just gives me the name of the object. After googling, I tried Fiddler, but that didn't catch anything, and SOAP Extensions look way too complicated for what seems like a really simple task.
There is no easy way to do this with ASMX web services. If you were using WCF, it would be a trivial matter of turning on message logging.
Fiddler should catch everything, and it's well worth learning how to use. Be sure to look in the online documentation to learn how to capture traffic from localhost to localhost.
The accepted answer to this question mentions that you can capture traffic to a web service using soapUI. You can use it to act as a proxy or HTTP tunnel in order to capture messages sent to your web service. I think using it in HTTP Tunnel mode makes sense, because then you won't have to do anything with your client other than to point the URL to soapUI instead of your actual service.
The soapUI website talks about the SOAP Monitor feature, though I don't think it offers a good explanation for setting up the HTTP tunnel.
Here are the steps involved (based on soapUI 3.0.1):
Open Soap UI
create a New soapUI Project...
2.1 Give your project a name
2.2 Enter the path to your service's WSDL (http://localhost/.../YourService.asmx?WSDL)
Right-click on the project you just created
Select "Launch SOAP Monitor"
Choose "HTTP Tunnel"
Specify an unused port number for "Port". The default will probably work.
Enter the URL to your web service in "Set endpoint for HTTP Tunnel"
If you are using SSL, then you may need to fill in some of the other fields; otherwise, click OK
The HTTP tunnel is running, so now just reconfigure a client to use the HTTP tunnel instead of the actual web service. So if your actual service is "http://localhost:1234/YourService.asmx", then reconfigure your client to use "http://localhost:{Port}/YourService.asmx" where {Port} is the number you entered in step #6.
Now just run your client normally. You'll see the traffic logged in the soapUI interface. Select a message and click on the "Message Content" button at the bottom of the window to view the actual SOAP message.
A C# client application we developed calls an external SOAP web service of a third party company.
Now I want to trace the exact SOAP request envelopes that are being generated by the VS.NET-generated SOAP proxy in our application and transfered to the external SOAP web service.
The method of using a network monitor like Wireshark (as described here) or using Microsoft Network Monitor is no option since the externl SOAP web service only provides an SSL/HTTPS URL, so the payload of the HTTP packages are encrypted and not viewable.
My question is:
Is there a way of configuring the .NET-built-in web service client classes to output/trace/log their underlying HTTP requests and responses that are being generated/received? (or maybe some kind of event to subscribe to?)
If you're using a standard web service (not WFC), you can extend the SoapExtension class as described here:
http://www.blog.encoresystems.net/articles/how-to-capture-soap-envelopes-when-consuming-a-web-service.aspx
If you're using WFC, then you can implement IEndpointBehavior and IClientMessageBehavior as described here:
http://weblogs.asp.net/paolopia/archive/2007/08/23/writing-a-wcf-message-inspector.aspx
I use both, depending on whether I'm using web or service references.
You can use fiddler, perhaps, as a proxy and thus monitor HTTP/HTTPS requests. This won't require you to write any code on your part.
Fiddler Web Debugger
It is worth noting that there are caveats to debugging HTTPS requests with Fiddler. This page explains how it can be done.
Fiddler Web Debugger - Debugging HTTPS traffic with Fiddler2
You can use Fiddler, or System.Net tracing.
http://blogs.msdn.com/dgorti/archive/2005/09/18/471003.aspx
http://msdn.microsoft.com/en-us/library/bb203855(BTS.10).aspx