Hej!

Jag har en Web Service som skall returnera ett meddelande och detta iform av ett xmldokument.
Datat som jag skall returnera hämtas ur en databas med en vanlig sqlfråga, och tas ner i ett dataset. Givet att jag har ett xsd dokument på hur returmeddelandet skall vara uppbyggt, hur "konverterar" jag ett dataset till ett xmldokument?

Jag antar det finns något smartare sätt än att gå igenom en hel tabell i datasetet och bygga xmldokumentet själv. Jag har sett att det finns en method på ett dataset som heter GetXml();
Jag har gjort xsddokumentet och genererat klassen.

På klientsidan skulle jag behöva göra tvärtom, konvertera ett xmldokument till ett dataset...

Tack på förhand
/Lars

Med risk för att jag missförstår din fråga så kan ett svar vara:

Från Dataset till XmlDocument

System.Xml.XmlDocument xmlDoc = new System.Xml.XmlDocument();
xmlDoc.LoadXml(dataSet11.GetXml());

Från XmlDocument till Dataset

System.IO.StringReader sr = new System.IO.StringReader(xmlDoc.OuterXml);
dataSet11.ReadXml(sr);
sr.Close();

Jag vill dock poängtera att jag inte helt häger med på vad du vill göra egentligen. Ett DataSet är i grunden xml och ett XmlDocument är egentligen bara en DOM representation av xml. Om du ska skicka informationen via en webservice över http så är det ju ändå bara en xml sträng som skickas och då spelar det ingen roll vilken returtyp du väljer. Borde du inte kunna sätta returtypen på din webbservice till DataSet?

Om du använder Sql Server så kan du returnera xml direkt från databasen och sedan köra frågan via SqlCommand objektets ExecuteXmlReader metod.

<code>select * from my_table for xml auto, elements</code>

Bifoga gärna korta men förklarande kodsnuttar för såväl webservice som klient så kanske jag kan ge mer specifika tips.

Med risk för att också missförstå dig drar jag en rövare. Om du skapar ett dataset från din webservice kan du returnera det

<code>
<WebMethod()> Function ReturnData () As DataSet

Dim ds as new dataset
... hämta data
return ds

End Function
</code>

Sedan via din proxy kallar du på funktionen:

<code>
dim ds as new dataset = NameSpace.ProxyName.ReturnData()
</code>

Sen kan du använda allting på en gång, om detta nu var det du var ute efter.

Hej

Tack för ett bra svar. Jo, i dagsläget har jag DataSets som returtyp. Problemet som jag har uppfattat genom att kolla runt lite är att DataSets inte riktigt är "interoperable". Det var därför jag ville göra en ren xmlrepresentation av datat som jag får efter jag har ställt min fråga till databasen, dvs utan diffgramm informationen och liknande.

Mvh Lars

Hej
Jo, det är så jag gör nu, men jag tänkte försöka få bort alla plattformsberoenden på tjänsten. Som jag har uppfattat det kan inte ett DataSet anses vara helt "interoperable", och därför tänkte jag se om det gick att använda något smidigt som inte innebar några plattformsberoenden.
Rätta mig gärna om jag har fel, det är ett ämne som är svårt att läsa sig till, alla säger olika, och jag har inte riktigt tid att prova klientlösningar på diverse plattformar.

Mvh Lars

Om mottagaren inte gör på detta sätt så kommer faktiskt ren xml till klienten. Testa att surfa till webservicen och kör invoke på testsidan så ser du att det faktiskt är så.

Om jag förstår ditt problem så är det redan löst. Dom får tolka xml-datat med de programvaror som finns för den aktuella plattformen. Din leverans bör fungera som exemplet ovan.

Ja, när man kör Web Servicen så får man svaret i xml, men det är ju en massa annat som egentligen inte hör till svaret, som t.ex.
Anledningen till att jag är lite petig är att jag håller på att utforskar området Service Oriented Architecture, och där interoperabilitet är en mycket diskuterad fråga ;-)

Anledninen till att jag var tveksam var artiklar såsom denna:
Exchanging Data - shipping typeless containers
http://blogs.msdn.com/richardt/archive/2004/07.aspx

DataSets and Web services don't mix (Tyvärr måste man nog registrera sig på denna, och jag ville inte klippan nåt)
http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci1048679,00.html

Det är ju lite svårt att definiera vem som skall göra jobbet, skall man låta klienten anpassa datat, eller skall datat vara såpass "generellt" att klienten kan använda det direkt

Mvh Lars

Webservicen och klienten ska båda följa WSDL definitionen och eftersom det är webservicen som exponerar WSDL definitionen skulle jag nog vilja påstå att klienten anpassar sig efter webservicen. Men givetvis måste de båda följa det gällande SOAP protokollet.

Om du vill ha ren xml kan du bygga upp din egen class eller struct och fylla denna med data som sedan returneras.

Ja, tror jag får göra det, som jag förstår det så är det bara att använda xsd.exe verktyget för att generera klasserna utifrån ett xsdschema.

Ja, om tittar i WSDL filen för en Web Service som har en method som returnerar ett dataset, även om det är typat så står det ingen information om vilka kolumner/fält som detta innehåller, men om man istället använder sig av genererad klass som returnerar ren xml, så står det de förväntade kolumnerna/fält:

Vad jag menar är:

DataSet versionen:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<returnDSOrder xmlns="http://....">
<returnDSOrderResult>dataset</returnDSOrderResult>
</returnDSOrder >
</soap:Body>
</soap:Envelope>


ren XML versionen:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<returnOrder xmlns="http://...">
<Aorder xmlns="http://../aorder.xsd">
<namn>string</namn>
<telnr>integer</telnr>
</Aorder>
</returnOrder >
</soap:Body>
</soap:Envelope>

Om jag ska vara ärlig så är jag inte helt förtjust i webservice implementationen i Visual Studio.Net/.Net Framework. Personligen så brukar jag skriva klienten på låg nivå med hjälp av HttpWebRequest och HttpWebResponse klasserna och returnera data från webservicen med en struct. Nästa gång skriver jag nog även webservice implementationen själv via HttpWebRequest och HttpWebResponse klasserna.

Ja, det är helt klart att det i dagsläget finns lite frågor runt implementation av Web Services. Det känns som att man måste ha en mycket djup kunskap om alla standarder för att lyckas göra en bra Web Service (vilket jag inte har, än ;-)). Har du provat Visual Studio 2005, det finns väl en hyffsad version nu, är de något bättre på just Web Services. Har för mig att de skall stödja WS-I Basic Profile.

/Lars

Har inte hunnit kika så mycket på VS2005 än.

Ett tips är att ni tittar på Web Services Enhancements, som kan underlätta att implementera en rad nya standarder inom Web Services området:

http://www.microsoft.com/downloads/details.aspx?FamilyId=FC5F06C5-821F-41D3-A4FE-6C7B56423841&displaylang=en

Har kollat lite på det, men det känns tyvärr inte lika användarvänligt som resten av visual studio. Rätt konstigt att det är ett plugin, och att det inte ingår från början, men det kanske det gör i den slutliga VS 2005.

Man får väl se när Windows Communication Foundation/Indigo skeppas, om allt är mer sammanhängande.

/Lars

Det är inte alltid som programmerarens verktygslåda är användarvänlig... =)

Varför det inte var med från början beror väl helt enkelt på att standarder som typ WS-Security helt enkelt inte var klara när man utvecklade Visual Studio 2003.

Jag har inte hunnit med att kolla så mycket på 2005 än, men jag har för mig att WSE skall finnas inbakat från början då, m.fl. förbättringar och nya grejer - inte helt osannolikt just kring integrationen med andra plattformar oxå, M$ har ju fått en del kritik på det området.

Ja, när vi får Indigo blir säkert allt frid o fröjd...
(.. men vänta nu.. jag känner igen detta.. vi sa väl likadant när DotNet kom ut... =))