How to show soap request xml for a web service call? - asp.net

I am using a web method of a company's web service.
This web method requires one parameter when calling it:
CompanyOpereations srv = new CompanyOperations();
srv.getCustomerInfo(input);
How can I see my soap request xml when calling this method?

How do you want to see it? If it's inside the code; I don't know. (Un)Fortunately .NET does a pretty good job of hiding it for the developer.
However, if you just want to debug the calls and nothing else: try Fiddler. It will show you the Request/Response (including headers and everything else) for the webservice calls. This is what we use for debugging webservices. But you can use it for everything that uses the HTTP protocol for communication.

Related

ASP.NET Web Service - Log SOAP XML

I have an ASP.NET asmx web service running on IIS.
A client is trying to consume the service, and I can see (after a rebuild) that the Global.asax Application_Start is getting hit from his attempt... but the specific function is not getting hit.
This link
Getting RAW Soap Data from a Web Reference Client running in ASP.net gives a "solution" for what I'm trying to do, but it didn't work.
I placed the above link's suggestion in my web.config, but no log file is generated even when I successfully call the service myself.
If you're looking to trap request/response on the client side, you can connect to ASMX webservices using WCF-style generated proxies just by using a "Service Reference" rather than a "Web Reference", then follow the WCF tracing you linked to for raw data, as well as using System.ServiceModel.MessageLogging for SOAP-specific stuff. Keep in mind that:
the maxdatasize attribute for System.Net will truncate the data logged, so pick a bigger number if your request/responses are larger. Use maxSizeOfMessageToLog with System.ServiceModel.MessageLogging.
remove the raw ascii/hex and only show the xml with tracemode="protocolonly" in the <source name="System.Net"> element
But if you want to trap requests on the server side (i.e. from within your ASMX webservice) you can try the suggestion here, which is to just read the data out of the request stream in Application_BeginRequest and probably also the response stream in Application_EndRequest.

Intercepting the SOAP envelop in an HttpRequest

I want to look at the XML created in my HttpRequest but can't see how. I've tried looking at the request during runtime but no luck.
I'm working in a .NET 4.0 project (just for context here, not that it matters much starting with 2.0)
I'm making a call to a third party API via my project's service reference:
SomeResponseType response = _apiClient.AddUser(userToAdd);
So how do I capture what AddUser is creating in terms of the raw XML being sent to the host without having to go through the pain of creating an Intercept filter which is not the easiest thing to put together?
You should be able to use Fiddler on your machine to capture the underlying HTTP request.
Alternatively, if you're using WCF, you can enable tracing via your config file. To go this route, see Configuring Message Logging. Then you can use the Service Trace Viewer Tool (SvcTraceViewer.exe) to pretty print your logs.
You can use a network sniffing tool such as Fiddler (www.fiddler2.com). Simply fire up Fiddler and then run your app. Fiddler will capture all of the traffic that is going across the wire, and you can look at the XML that is being sent and received from the SOAP service.

find which server in a web farm the web method got executed?

This question is a consequence of the following question: determining which server (in a web farm) the asp.net ajax request came from?
The problem is that we commonly use automatically generated proxy classes to communicate with the web method (which may be part of asmx/wcf service). When we receive the response from the web services server, how do we know which server it got processed from?
We receive the response from the server side code which is executing (mostly). When its a script service (which can be called via javascript) its another case altogether.
How can we read the response headers once the web service returns?
Am I constrained to build my own proxy classes to solve this problem?
One way. Its not the best way but it will do until something new comes about. If you have a tool like fiddler/burp, you can inspect the response headers. So we must configure the IIS to set the response headers appropriately.
By default they are configured to output something like X-ASP.NET...a good idea would be to add the server name to that...

WebTestPlugin and Http Request parameters (Visual Studio Test)

I am using Visual Studio 2010 Ultimate to perform web and load tests. I have a set of web tests that call REST web services that require OAuth credentials and I'm looking for information on how I can access the associated Http Headers and Post body the request. I've created a web test plugin that acts as an Authorization Manager and have overriden the PreWebTest method. When I look at the PreWebTestEventArgs argument, I see the WebTest and its WebTestContext but I don't see any obvious way to access the actual Http Headers or the Post Body where I might be able to insert the OAuth components. Has anyone been able to affect the Http Request with the associated web test? Any insight will be much appreciated. Thanks.
I think you'll need to override PreRequest instead of PreWebTest.
PreRequestEventArgs has the Request property which is the WebTestRequest object that has access to the headers and post body.

asp.net webservice with jquery on different domain

I got to work on PHP app which requires a webservice call to an Asp.net webserivce. Client insist to call this webservice with POST directly via jquery.
My knowledge says its not possible to call different domain webservice from JS and I'll have to create a proxy page to consume this webservice.
So I just want to confirm, is there any hack around to consume webservice directly from jQuery POST call and parse response (Which is XML not JSON) on page.
Thanks
No there is no way around it x-browser. Server Proxy or json-p are your choices.

Resources