I would post this elsewhere, but it's scary out there and H/A is smart peoples.
I'm going through the approval process on a 3rd party web service API (UPS) and they need me to send them the XML from various requests and responses. The problem is since I implemented my solution using C#, I don't have easy access to the XML sent and received. There's some .NET voodoo going on when you add a web reference and they hide any way to access the plain text XML.
I've looked everywhere online for a way and the top 3 suggestions I see are:
- Edit the web.config to trace your socket connections
- Write a SoapExtension to process the content before/after serialization.
- Use a proxy to intercept the message.
I've tried (1), and since the XML data was so large, there were gaps in the data and I couldn't create a valid XML file by what I could parse out of the log file.
I tried (2), but can't get any of the msdn examples to work. I think this is because the SoapExtensionAttributes only work on your own WebMethods, not invocations of outside services.
I saw instructions on (3) somewhere, but I forgot to bookmark it and can't find it again.
Unfortunately, UPS is fairly stingy on developer support, so I think I'm out of luck there.
Help me H/A, I've been stuck on this for almost a week.
Posts
I add a web service reference to a .NET app, and classes and what not are generated for the reference. When calling a method of the web service, I load up an class object that the method accepts as an argument, make the web service call, and the method returns an object for the response.
I'm talking about serializing the objects passed and returned into .xml files.
Oh. You'll need to be running fiddler on the server. I assumed you were testing locally.
Wireshark won't be able to read the encrypted HTTPS packets. Fiddler acts as a proxy and can therefore decrypt the packets as it already has the keys going back and forth.
To do it within the code, you can change the proxy class (i.e., the Reference.cs under your Service Reference) generated by VS so that it returns XML instead of the auto-generated type. Of course, that will be overwritten anytime you update the reference. There are also very easy ways in .NET to serialize objects into XML, so you could serialize the enter request/response object.
If you don't need it programatically and just want to view it, Fiddler is the way to go, as mentioned. wmelon is right, you need to run Fiddler on the server that is actually making the service call.
I am running it locally right now, just fiddler wasn't picking it anyway and I read this was because the serverside code (still on my machine while I'm developing) is running under this IIS user.
This was kind of one of one of the first things I tried, but when it didn't work I started searching online, and everyone seemed to pointing in the direction of SOAP extensions and tools like fiddler.
I think part of the problem is that UPS request isn't really valid XML, like it sends 2 separate documents in one call or something.
Well, it is likely valid XML, otherwise the .NET serialization would shit its pants.
Did you try changing your return values in the generated proxy class? If you find the method name you're calling, you should be able to just change "public MyObject GetStuff()" to "public XmlElement GetStuff()" and then throw it to a string. I may have the class name wrong on the XML but the idea is the same.
I was sick for a week straight then was on vacation for a while. I was frustrated with this so much that I tried just working on some other stuff for a while, but management pulled me back to this.
Does anyone specifically have any experience developing a .NET application using the UPS Shipping API? They offer little to no developer support, and I have more questions than just my problem above
This is a little late but you need to setup .NET to send it's requests through the Fiddler proxy in order for the external web service calls to show up. You can do it two ways. Update the web.config to contain
Or add this to Application_Start in Global.asax
Also don't forget to remove those once you're done testing. Otherwise your site will break once you close Fiddler and you stare at it for an hour wondering why the site doesn't load. Not that I've ever done anything like that.
Super Mario Maker ID: DBB-1RH-JJG
in the Global.asax Application_Start earlier and had no luck. I'll try your way if I get a chance, but it seems equivalent.