How to parse a SOAP XML?

Spacerat

Expert Member
Joined
Jul 29, 2015
Messages
1,524
Reaction score
653
I need to parse a SOAP request in C#. I have the WSDL and created a C# file using the WSDL.exe but not sure how to actual do the parsing using this class. Any pointers?
 
I probably need more context to give a good answer, but given it is SOAP, it is probably coming from a SOAP based server somewhere, so following one of the WCF Client tutorials for C# on the web is probably your first port of call. Or if you are writing a server, then a WCF server tutorial should do the trick.
 
Another system is HTTP POSTing an XML (SOAP) to me. Not using IIS. Using an embedded HTTP server to process the request. So I need to extract the elements in the XML in order to handle the individual parts...
 
you shouldn't have to parse the xml. The wdsl.exe should create the classes with the bindings generated. You then use these bindings, or the wdsl, to publish a soap service. You app the exposes an endpoint which people can then consume( eg from soapui). (This is at least how you do it with axis in Java, but the concept is the same)

Contract first web services are pain though, as it seems that every wsdl in existence contains overly complex and strangely named elements.
 
Ok So here I have the wsdl file, the generated class and the request XML.

https://www.dropbox.com/s/fq4mho1xkripbav/printer.zip?dl=0

Somehow I cannot get the XML parsed. I try to do it like this:

XmlSerializer xmlSerializer = new XmlSerializer(typeof(fiscalPrintRequest));
TextReader tr = new StringReader(requestXml);
object obj = xmlSerializer.Deserialize(tr);

but I get an exception
An unhandled exception of type 'System.InvalidOperationException' occurred in System.Xml.dll
Additional information: There is an error in XML document (2, 2)

The other way is to do it like this:
var Value = XDocument.Parse(requestXml);
IList<XElement> rootElement = Value.Elements().ToList();
IList<XElement> bodyElement = rootElement.Elements().ToList();
IList<XElement> fiscalPrintRequestElement = bodyElement.Elements().ToList();
IList<XElement> elements = fiscalPrintRequestElement.Elements().ToList();
IList<XElement> elements1 = fiscalPrintRequestElement.Elements("transactionMetaData").ToList();
etc
but that is very cumbersome

any ideas?


EDIT:
OK if i remove the Envelope and Body tags, the XML parses. but that wrong...

EDIT2:
Ok so I created my own classes to represent the Envelope and Body elements but the namespaces causes it to fail. not sure why tho...
 
Last edited:
Did you try a web search?

One of the first results: http://stackoverflow.com/questions/5794206/deserialize-a-soap-message
This may not be your answer, but will get you a long way to what you are trying to do. Just reading that guy's question should already get you going...

Also, look at the SoapFormatter class -> https://msdn.microsoft.com/en-us/library/wkyt1t1f(v=vs.110).aspx

You got the wsdl so just generate your objects from that and then use that to deserialize your messages as they come in.

For interest sake, why reinventing the wheel here and not using IIS? If you absolutely cannot be using IIS, then why not have a WCF service with tcp bindings? You are overcomplicating this to another level for yourself.

Also, register on SO, you may have a bitter hit rate on solutions to your problem...
 
Did you try a web search?

One of the first results: http://stackoverflow.com/questions/5794206/deserialize-a-soap-message
This may not be your answer, but will get you a long way to what you are trying to do. Just reading that guy's question should already get you going...

Also, look at the SoapFormatter class -> https://msdn.microsoft.com/en-us/library/wkyt1t1f(v=vs.110).aspx
Yes I searched a lot. Most of the searches I did, did not address my problem.


You got the wsdl so just generate your objects from that and then use that to deserialize your messages as they come in.
I did gen my classes from the wdsl, but the generated classes did not include the Envelope and Body

For interest sake, why reinventing the wheel here and not using IIS? If you absolutely cannot be using IIS, then why not have a WCF service with tcp bindings? You are overcomplicating this to another level for yourself.

I am actually trying to simplify it for the user from a support perspective. The app runs embedded as a POS terminal issuing prepaid airtime vouchers in deepest Africa. I prefer not to have the complexity of IIS in there and it has to be as bare-bones as possible. Some terminals still run XP .. :wtf:

Anyway I solved my problem. I just had to create a serializable wrapper for the request Envelope and Body tags and get the namespaces right.
 
I haven't done manual parsing in a longtime but there was a method in c# 2.0 I think where you could basically parse the XML into a dataset. From there you could use normal query syntax or take advantage of LINQ is your code base allows a higher level.

The best way would be to create a proper SOAP binding though.
 
The fact is that these terminals have noi internet connectivity. The guys installing the software have no it skills . Installation has to be one click and bulletproof. Would you honestly choose iis for that?
 
Slight hijack...


What is the best for a beginner to master.

SOAP or REST ?
 
The fact is that these terminals have noi internet connectivity. The guys installing the software have no it skills . Installation has to be one click and bulletproof. Would you honestly choose iis for that?

You don't require iis for the method I mentioned. Can run in a command or service.
 
Rest. Soap is always a nightmare to work with, no matter your competency level.

Just a note.

REST is great however it's not as strongly typed in the data itself whereas SOAP has to be. REST is lighter and easier to work with but SOAP is still a good standard of enforced data structure communication and security where needed. To put it bluntly at the moment, we use REST services internally for all applications etc however we most often use SOAP to communicate externally with other companies. Basic explanation, SOAP has a wsdl describing itself, REST does not.
 
The fact is that these terminals have noi internet connectivity. The guys installing the software have no it skills . Installation has to be one click and bulletproof. Would you honestly choose iis for that?

Here, this is a basic snippet of code, obviously its wrapped in other items for selecting a file and closing the file stream as well as error handling but it has the prevalent part.

Code:
#region FileRead into Stream

                    StreamReader sr = new StreamReader(new FileStream(file, FileMode.Open));
                    Console.WriteLine("Parsing file " + file);
                    string output = sr.ReadToEnd();

                    #endregion FileRead into Stream

                    DataSet ds = new DataSet();
                    //Set XML into dataset

                    #region XML Read into DS

                    try
                    {
                        ds.ReadXmlSchema(new StringReader(output));
                        ds.ReadXml(new StringReader(output));
                    }
                    catch (Exception x)

The code in the Try is what you need. Then just traverse the dataset using objects or Linq.
 
Just a note.

REST is great however it's not as strongly typed in the data itself whereas SOAP has to be. REST is lighter and easier to work with but SOAP is still a good standard of enforced data structure communication and security where needed. To put it bluntly at the moment, we use REST services internally for all applications etc however we most often use SOAP to communicate externally with other companies. Basic explanation, SOAP has a wsdl describing itself, REST does not.

Yeah i know its not strongly typed. I'd still use it over soap or i'd use msgpack or protocol buffers.
 
Slight hijack...


What is the best for a beginner to master.

SOAP or REST ?

REST IMHO, but as said before since its not very fussy about what it receives Ive had people send me the biggest load of crap EVER. But yes I found REST to be slightly easier to work with too...
 
REST IMHO, but as said before since its not very fussy about what it receives Ive had people send me the biggest load of crap EVER. But yes I found REST to be slightly easier to work with too...

If you're just taking whatever is posted to you and saved, then that's just stupid. If you have an object that gets serialized from json to a contract then you should be easily protected against the "biggest load of crap you receive". All our REST services are very cognisant of what it receives.
 
Reason I am asking, again sorry for the thread hijack OP

I am using the wordpress JSON API

And was thinking of REST on the mobile app to pull the post data.
 
Top
Sign up to the MyBroadband newsletter
X