Deserializing a xml document for sending it using a WebService
-
Hi, I have a XML document (that I've got from an InfoPath form) and it has its namespaces.I'd like to deserialize this XML document into a type and send it to a WebService.The type has been generated when I referenced the WebService in my project. When I try to deserialize the XML document I get a "xmlns was not expected" error thrown by XmlSerializer. What should I do to either remove namespaces from the XML document or introduce them to XmlSerailizer so It can recognize QNames? Regards
-
Hi, I have a XML document (that I've got from an InfoPath form) and it has its namespaces.I'd like to deserialize this XML document into a type and send it to a WebService.The type has been generated when I referenced the WebService in my project. When I try to deserialize the XML document I get a "xmlns was not expected" error thrown by XmlSerializer. What should I do to either remove namespaces from the XML document or introduce them to XmlSerailizer so It can recognize QNames? Regards
I want to make sure I understand... You have some XML from an InfoPath form and want to pass that to a Web Service. The Web Service takes a parameter (likely a class) that looks something like your XML, but when you try to cast your XML into the Web Service's type by attempting to deserialize your XML you get the error. If this is the case, you are getting the error because the InfoPath type is different from the type that the Web Service is expecting. The easiest way to get this to work is to compare what the web service expects with the XML from infopath. If only the namespace, or namespace prefix, or both is/are different, you could take the quick route and use basic string manipulation to remove/edit as necessary. Manipulating XML strings directly is not recommended in most cases, but it does make sense in some since some transformations are really that simple. The correct way of accomplishing this is to transform the XML InfoPath into the serialized version of the type that the web service expects and then send deserialze it into the WS's type. You transform from one type into another using XSL and a bit of code to do the transformation. The problems with transforming using XSL include:
- You need to know at least some XSL
- Storage of the XSL
- Changes in either the input or output require changes to the XSL
If you don't want to go with either approach, you do have one more option: extract the values you need from the InfoPath XML and copy the values into the type that the Web Service uses - sort of a manual transformation. You cold extract values from the InfoPath XML using XPath queries or just grab them using regular expressions or brute force string matches. So, you have a few options. Your choice depends on how comfortable you are with the underlying approaches and whether you'll end up maintaining whatever you choose ;)
Erik Westermann - wWorkflow.net - Consulting Services
SOA * ESB * BPI ...and lots of other cool TLAs related to integration and architecture. -
I want to make sure I understand... You have some XML from an InfoPath form and want to pass that to a Web Service. The Web Service takes a parameter (likely a class) that looks something like your XML, but when you try to cast your XML into the Web Service's type by attempting to deserialize your XML you get the error. If this is the case, you are getting the error because the InfoPath type is different from the type that the Web Service is expecting. The easiest way to get this to work is to compare what the web service expects with the XML from infopath. If only the namespace, or namespace prefix, or both is/are different, you could take the quick route and use basic string manipulation to remove/edit as necessary. Manipulating XML strings directly is not recommended in most cases, but it does make sense in some since some transformations are really that simple. The correct way of accomplishing this is to transform the XML InfoPath into the serialized version of the type that the web service expects and then send deserialze it into the WS's type. You transform from one type into another using XSL and a bit of code to do the transformation. The problems with transforming using XSL include:
- You need to know at least some XSL
- Storage of the XSL
- Changes in either the input or output require changes to the XSL
If you don't want to go with either approach, you do have one more option: extract the values you need from the InfoPath XML and copy the values into the type that the Web Service uses - sort of a manual transformation. You cold extract values from the InfoPath XML using XPath queries or just grab them using regular expressions or brute force string matches. So, you have a few options. Your choice depends on how comfortable you are with the underlying approaches and whether you'll end up maintaining whatever you choose ;)
Erik Westermann - wWorkflow.net - Consulting Services
SOA * ESB * BPI ...and lots of other cool TLAs related to integration and architecture.Thank you very much for you kind and helpful reply.