[C#] Xml file posten naar aspx pagina

[CaptBiele]

Ik wil een aspx pagina maken die van verschillende bronnen een xml bericht kan ontvangen.
In het xml bericht zullen acties beschreven staan die uitgevoerd moeten worden.
De huidige architectuur laat geen gebruik van webservices toe

Ik heb nu een winform test appje geschreven die een synchrone post maakt. (framework 1.1)

C#:

HttpWebRequest httpRequest = (HttpWebRequest)WebRequest.Create(@"http://localhost/XMLReceiver/WebForm1.aspx");
httpRequest.Method = "POST";
httpRequest.ContentType = "text/xml";
FileStream fileStream = new FileStream("blub.xml", FileMode.Open, FileAccess.Read);
byte[] requestBody = new byte[fileStream.Length];
fileStream.Read(requestBody, 0, (int)fileStream.Length);
httpRequest.ContentLength = requestBody.Length;
Stream requestStream = httpRequest.GetRequestStream();
requestStream.Write(requestBody, 0, requestBody.Length);
requestStream.Close();
HttpWebResponse httpResponse = (HttpWebResponse)httpRequest.GetResponse();
label1.Text = new StreamReader(httpResponse.GetResponseStream()).ReadToEnd();

Bij de aspx pagina heb ik in de Page_Load staan:

C#:

if(Request.InputStream.Length > 0)
{
    XmlDocument postedXml = new XmlDocument();
    postedXml.Load(Request.InputStream);
    string actie = postedXml.SelectSingleNode("//@testje").Value;

    //voer actie uit
}

Ik ben nu dus benieuwd naar de beste methode om zo'n dergelijke communicatie op te zetten. Nu post ik vanuit mijn winform de xml file, en wacht op reactie. Als ik nu de response uitlees, krijg ik de html output van de aspx pagina. Het lijkt me handiger om hier gewoon een soort boolean uit te kunnen lezen die zegt of het succesvol is of niet.
Maar moet ik dan vanuit de aspx pagina de response stream gaan bewerken of moet ik daar direct een apart bericht gaan terugsturen? Dat lijkt me toch niet echt de bedoeling....

(ik weet niet of het van toepassing is, maar het moet uiteindelijk ook gaan werken met a-synchrone communicatie)

ik hoop dat het duidelijk is!

offtopic:
het lukt me trouwens ook niet om een waarde uit het xml bericht te lezen. Het enige wat ik nog voor elkaar krijg is om het aantal nodes uit te lezen. Ik krijg alleen maar null values. Iemand een tipje?

[ Voor 3% gewijzigd door CaptBiele op 04-07-2006 13:47 ]

[joopst]

Als response kan je ook xml maken die je winform dan weer parsed

[Annie]

Is XML-RPC niets voor je?

Ow, en als je asynchroon wil werken, zou je ook eens kunnen kijken naar MSMQ. Misschien kan je daar wat mee.

[CaptBiele]

joopst schreef op dinsdag 04 juli 2006 @ 12:10:
Als response kan je ook xml maken die je winform dan weer parsed

Maar dat wordt dus een op zich staand bericht? en niet een onderdeel van de standaard response?

Annie schreef op dinsdag 04 juli 2006 @ 12:42:
Is XML-RPC niets voor je?

Ow, en als je asynchroon wil werken, zou je ook eens kunnen kijken naar MSMQ. Misschien kan je daar wat mee.

volgens mij is XML RPC wel gemaakt voor mijn intenties, alleen willen ze hier geen externe tools/libraries gebruiken. Eigenlijk moet alles mbv het standaard framework draaien.

En ik heb de indruk dat MSMQ ook niet echt hiervoor bedoeld is (maar ik kan er naast zitten)

[bigbeng]

XML-RPC wordt vanaf .NET 2.0 ook gewoon ondersteund. Voor lagere versies kun je natuurlijk altijd SOAP gebruiken. Probeer anders gewoon eens met de webservice wizard het een en ander voor elkaar te krijgen. In visual studio 2003 kun je dat vinden onder File -> New Project -> Visual <progtaal> projects -> ASP.NET Web Service.

Andere projecten kun je middels een webreference laten refereren naar jouw webservice. Hoef je zelf verder niets voor te programmeren.

[ Voor 26% gewijzigd door bigbeng op 04-07-2006 13:28 ]

[CaptBiele]

bigbeng schreef op dinsdag 04 juli 2006 @ 13:27:
XML-RPC wordt vanaf .NET 2.0 ook gewoon ondersteund. Voor lagere versies kun je natuurlijk altijd SOAP gebruiken. Probeer anders gewoon eens met de webservice wizard het een en ander voor elkaar te krijgen. In visual studio 2003 kun je dat vinden onder File -> New Project -> Visual <progtaal> projects -> ASP.NET Web Service.

Andere projecten kun je middels een webreference laten refereren naar jouw webservice. Hoef je zelf verder niets voor te programmeren.

lees nog een keer de TS......

en op die xml-rpc link staat toch echt dat 2.0 het niet ondersteund (alleen via workaround)

[bigbeng]

CaptBiele schreef op dinsdag 04 juli 2006 @ 13:30:
[...]

lees nog een keer de TS......

en op die xml-rpc link staat toch echt dat 2.0 het niet ondersteund (alleen via workaround)

Ik neem aan dat je de draad bedoelt?

Volgens mij staat er dat ".NET 2.0 may break existing XML-RPC..." dus dat is bij jou toch niet van toepassing? Of heb je al een XML-RPC app?

Het asynchroon zijn, hoe zie je dat voor je? Moet een client een request kunnen doen en dan later het resultaat ophalen? Dat kun je doen door aparte methodes in je webservice te maken (RequestForAction en later RetrieveActionResult en eventueel GetActionStatus bijvoorbeeld).

Of bedoel je dat een applicatie bij het wegvallen van de server zijn requests in een cache zet en later oppakt?

[ Voor 33% gewijzigd door bigbeng op 04-07-2006 13:50 ]

[CaptBiele]

bigbeng schreef op dinsdag 04 juli 2006 @ 13:38:
[...]
Volgens mij staat er dat ".NET 2.0 may break existing XML-RPC..." dus dat is bij jou toch niet van toepassing? Of heb je al een XML-RPC app?

Ik draai met .Net 1.1, en webservices kan ik niet gebruiken.... (heb dus ook nog geen XML-RPC app)
Het zal toch wel met standaard functionaliteit moeten lukken...

[Not Pingu]

CaptBiele schreef op dinsdag 04 juli 2006 @ 11:33:
Ik ben nu dus benieuwd naar de beste methode om zo'n dergelijke communicatie op te zetten. Nu post ik vanuit mijn winform de xml file, en wacht op reactie. Als ik nu de response uitlees, krijg ik de html output van de aspx pagina. Het lijkt me handiger om hier gewoon een soort boolean uit te kunnen lezen die zegt of het succesvol is of niet.
Maar moet ik dan vanuit de aspx pagina de response stream gaan bewerken of moet ik daar direct een apart bericht gaan terugsturen? Dat lijkt me toch niet echt de bedoeling....

Als ik het goed begrijp, is de bedoeling dat de ASPX pagina dus de result HTML terugstuurt na de XML te hebben bewerkt, en je Winforms app heeft die vervolgens nodig, maar niet om op het beeld te tonen?

Zodra je HttpWebResponse een response krijgt met code 200, weet je toch al dat het goed is gegaan? Zorg dat je ASPX pagina de response code verandert naar 500.x of welke dan ook van toepassing is, en je HttpWebResponse kan apart de status en de HTML source uitlezen.

Maar uit het feit dat je uberhaupt result HTML krijgt, kun je toch al afleiden dat het goed is gegaan? Mocht de response body == "" of bijv. alleen het woordje 'error' bevatten, weet je dat het niet goed is.

CaptBiele schreef op dinsdag 04 juli 2006 @ 11:33:

offtopic:
het lukt me trouwens ook niet om een waarde uit het xml bericht te lezen. Het enige wat ik nog voor elkaar krijg is om het aantal nodes uit te lezen. Ik krijg alleen maar null values. Iemand een tipje?

Heb je de waarde die je terugkrijgt in je HttpWebResponse al in een XmlDocument gezet? Die maakt het makkelijk om erdoorheen te lopen.

Ik neem aan dat je de output van je ASPX pagina al gecontroleerd hebt, zodat je zeker weet dat ie iets terugstuurt?

[ Voor 20% gewijzigd door Not Pingu op 04-07-2006 13:56 ]

[bigbeng]

Waarom kun je webservices niet gebruiken als je wel een ASP.NET applicatie kunt maken? Maak je geen gebruik van visual studio?

[joopst]

[quote]
Maar dat wordt dus een op zich staand bericht? en niet een onderdeel van de standaard response?
[quote]

De truuk is dat je een soort standaard xml definieert voor alle 'terug'communicatie naar de 'invoker'. In die xml komt dan te staan of het is gelukt, en zonee, wat er dan mis is gegaan. Deze xml komt dan in plaats van de html die een aspx normaal zou uitpoepen.

als je bijv in je aspx iets doet als:

code:

{doe iets met de incoming xml}

en dan:

            HttpContext.Current.Response.Clear();

            System.Xml.XmlWriter writer = new System.Xml.XmlTextWriter(HttpContext.Current.Response.Output);
            writer.WriteStartElement("response");
            if (error)
            {
               writer.WriteAttributeString("exception", "102");
               writer.WriteAttributeString("description", "whoops there it is");
            }
            writer.WriteEndElement();

dan ben je al een heel eind.

[CaptBiele]

joopst schreef op dinsdag 04 juli 2006 @ 14:01:
De truuk is dat je een soort standaard xml definieert voor alle 'terug'communicatie naar de 'invoker'. In die xml komt dan te staan of het is gelukt, en zonee, wat er dan mis is gegaan. Deze xml komt dan in plaats van de html die een aspx normaal zou uitpoepen.

Dat is ideaal en eigenlijk precies wat ik zoek. Ik ga kijken of de met de code aan de gang kan!

Not Pingu schreef op dinsdag 04 juli 2006 @ 13:50:
Als ik het goed begrijp, is de bedoeling dat de ASPX pagina dus de result HTML terugstuurt na de XML te hebben bewerkt, en je Winforms app heeft die vervolgens nodig, maar niet om op het beeld te tonen?

Ik hoef helemaal niets te doen met die html output. Ik wil zelf de response kunnen definieren, dus is een xml bericht als output het meest flexibel.
Maar de opmerking over de http codes is wel handig, daar had ik niet eens bij stil gestaan.

Not Pingu schreef op dinsdag 04 juli 2006 @ 13:50:Heb je de waarde die je terugkrijgt in je HttpWebResponse al in een XmlDocument gezet? Die maakt het makkelijk om erdoorheen te lopen.

Dat d8 ik bereikt te hebben met

C#:

postedXml.Load(Request.InputStream);

misschien moet ik nog iets speciaals doen, maar je mag er toch vanuit gaan dat het automagisch goed gaat.

bigbeng schreef op dinsdag 04 juli 2006 @ 13:53:Waarom kun je webservices niet gebruiken als je wel een ASP.NET applicatie kunt maken? Maak je geen gebruik van visual studio?

Dat had ik al gezegd: de architectuur laat het niet toe. In het kort: alle communicatie verloopt via Biztalk, en deze versie ondersteund nog geen webservices.

[CaptBiele]

joopst schreef op dinsdag 04 juli 2006 @ 14:01:
als je bijv in je aspx iets doet als:

code:

{doe iets met de incoming xml}

en dan:

            HttpContext.Current.Response.Clear();

            System.Xml.XmlWriter writer = new System.Xml.XmlTextWriter(HttpContext.Current.Response.Output);
            writer.WriteStartElement("response");
            if (error)
            {
               writer.WriteAttributeString("exception", "102");
               writer.WriteAttributeString("description", "whoops there it is");
            }
            writer.WriteEndElement();

dan ben je al een heel eind.

ik heb de code al min of meer werkend. Ik krijg iig de xml output die ik zelf gedefineerd heb....
alleen komt daar nog de standaard html output achteraan..... dat kan ik nog niet helemaal verklaren

[Not Pingu]

CaptBiele schreef op dinsdag 04 juli 2006 @ 14:11:
Ik hoef helemaal niets te doen met die html output. Ik wil zelf de response kunnen definieren, dus is een xml bericht als output het meest flexibel.

Je kunt je ASPX pagina helemaal leegmaken (dus geen doctype en basis documentstructuur erin) en dan dmv. Response.Write je response opbouwen. Zo kun je ook een XML document terugsturen, wat je wilt.

En om dat laatste makkelijker te maken, zou je de huidige HTML structuur in je ASPX pagina kunnen vervangen door een <? xml version="1.0" ?> bovenaan, met daaronder een <asp:Literal /> waarin je je XML output.

CaptBiele schreef op dinsdag 04 juli 2006 @ 14:11:
Dat d8 ik bereikt te hebben met

C#:

postedXml.Load(Request.InputStream);

misschien moet ik nog iets speciaals doen, maar je mag er toch vanuit gaan dat het automagisch goed gaat.

In dit geval moet je postedXml.LoadXml(xmlstring) gebruiken, .Load() neemt een URL/filepath en gaat die dan opzoeken.

Zie ook MSDN

[CaptBiele]

Not Pingu schreef op dinsdag 04 juli 2006 @ 14:52:
Je kunt je ASPX pagina helemaal leegmaken (dus geen doctype en basis documentstructuur erin) en dan dmv. Response.Write je response opbouwen. Zo kun je ook een XML document terugsturen, wat je wilt.

dat krijg ik toch niet met Response.Write voor elkaar? Die zorgt volgens mij alleen voor het outputten van de response en toch niet voor het opbouwen zelf? of ben ik nu in de war?
iig lukt het helemaal leegmaken van de aspx pagina me niet. Ik krijg nu de xml en de html output.

Not Pingu schreef op dinsdag 04 juli 2006 @ 14:52:
En om dat laatste makkelijker te maken, zou je de huidige HTML structuur in je ASPX pagina kunnen vervangen door een <? xml version="1.0" ?> bovenaan, met daaronder een <asp:Literal /> waarin je je XML output.

Heb je nog een reden om dit met een literal te doen? want dan moet ik weer een extra filtering op de winforms app doen. En de literal werkt toch niet met een xml-header? of snap ik je verkeerd?!

Not Pingu schreef op dinsdag 04 juli 2006 @ 14:52:
In dit geval moet je postedXml.LoadXml(xmlstring) gebruiken, .Load() neemt een URL/filepath en gaat die dan opzoeken.
Zie ook MSDN

[C#] public virtual void Load(Stream);

[Not Pingu]

Met Response.Write kun je schrijven naar je output object. Het daadwerkelijke outputten daarvan gebeurt later pas.

Alles wat je met Response.Write invoert wordt altijd bovenaan je response geplaatst (dus eventuele HTML uit je ASPX pagina komt daaronder), dus als alternatief kun je in je ASPX pagina een <asp:Literal /> plaatsen waarnaar je schrijft.

CaptBiele schreef op dinsdag 04 juli 2006 @ 15:31:

Heb je nog een reden om dit met een literal te doen? want dan moet ik weer een extra filtering op de winforms app doen. En de literal werkt toch niet met een xml-header? of snap ik je verkeerd?!

Dit doe ik met een Literal omdat die geen overbodige HTML produceert (itt. een Label die er altijd <span> tags omheen rendert).

Het zal ASP.NET echt een worst wezen wat je voor doctype in je pagina hebt staan, daar let ie echt niet op. Je kunt heel goed een XML header in je ASPX pagina zetten en daarin strings outputten. Als de uiteindelijke output maar valide XML is, kan je winforms app daar goed mee overweg.

Ik zou niet weten waarom je dat moet filteren in je winforms app. Heb je al eens in een browser gekeken naar wat je ASPX pagina precies output?


Dus je krijgt dan zoiets:

ASPX file:

code:

<%@ Page Language="C#" etc. etc %>
<? xml version="1.0" ?>

<asp:Literal id="mijnOutput" runat="server" />

codebehind:

C#:

Page_Load(object sender, EventArgs e)
{
  Response.ContentType = "application/xml";
  mijnOutput.Text += "<tag>Hoi dit is XML output</tag>";
}

Produceert in je browser (en in je HttpWebResponse):

XML:

<? xml version="1.0" ?>

<tag>Hoi dit is XML output</tag>

CaptBiele schreef op dinsdag 04 juli 2006 @ 15:31:

[C#] public virtual void Load(Stream);

My bad

edit:
en volgens mij is die xml header niet helemaal goed, maar damned als ik het ga opzoeken

[ Voor 90% gewijzigd door Not Pingu op 04-07-2006 15:59 ]

[CaptBiele]

Not Pingu schreef op dinsdag 04 juli 2006 @ 15:46:
ASPX file:

code:

<%@ Page Language="C#" etc. etc %>
<? xml version="1.0" ?>
<asp:Literal id="mijnOutput" runat="server" />

codebehind:

C#:

Page_Load(object sender, EventArgs e)
{
  Response.ContentType = "application/xml";
  mijnOutput.Text += "<tag>Hoi dit is XML output</tag>";
}

Ja, dat heb ik nu werkend gekregen, en hij toont inderdaad alleen de xml output, en niet meer de standaard html output.
Ik heb alleen een beetje het gevoel dat het meer een soort workaround is dan een nette oplossing...

[gorgi_19]

CaptBiele schreef op dinsdag 04 juli 2006 @ 16:51:
[...]

Ja, dat heb ik nu werkend gekregen, en hij toont inderdaad alleen de xml output, en niet meer de standaard html output.
Ik heb alleen een beetje het gevoel dat het meer een soort workaround is dan een nette oplossing...

Dan zou je een HttpHandler moeten gebruiken, waarbij je direct de response stream kan aansturen zonder overhead van System.Web.UI.Page

[Not Pingu]

CaptBiele schreef op dinsdag 04 juli 2006 @ 16:51:
[...]

Ja, dat heb ik nu werkend gekregen, en hij toont inderdaad alleen de xml output, en niet meer de standaard html output.
Ik heb alleen een beetje het gevoel dat het meer een soort workaround is dan een nette oplossing...

Jah, het liefst zou je hier een webservice voor gebruiken, maar dat kan binnen jouw omgeving dus niet.

Echter kun je natuurlijk nog steeds met de hand objecten serializen (=omzetten naar XML) in je ASPX pagina, en vervolgens in je Winforms applicatie de XML weer deserializen naar objecten. Kijk daar eens naar, dat kan je een hoop handwerk schelen.

Als je ook de vrijheid wil houden om simpel een stukje platte tekst te outputten wordt dat weer lastiger, maar ook daarvoor kun je natuurlijk serialization gebruiken.

[joopst]

CaptBiele schreef op dinsdag 04 juli 2006 @ 14:43:
[...]

ik heb de code al min of meer werkend. Ik krijg iig de xml output die ik zelf gedefineerd heb....
alleen komt daar nog de standaard html output achteraan..... dat kan ik nog niet helemaal verklaren

Als je de render method van de page override, dan wordt er geen spul behalve dat van jezelf uitgeschreven.
(in de render method dan wel even Response.Clear() doen.)

[gorgi_19]

joopst schreef op woensdag 05 juli 2006 @ 15:21:
[...]


Als je de render method van de page override, dan wordt er geen spul behalve dat van jezelf uitgeschreven.
(in de render method dan wel even Response.Clear() doen.)

Waarom pak je dan geen .ashx

[joopst]

van mij mag het
maar in zijn requirements gaf hij aan dat hij graag een aspx had ...

[CaptBiele]

joopst schreef op woensdag 05 juli 2006 @ 15:21:
Als je de render method van de page override, dan wordt er geen spul behalve dat van jezelf uitgeschreven.
(in de render method dan wel even Response.Clear() doen.)

Dat is sowieso netter jah.

gorgi_19 schreef op dinsdag 04 juli 2006 @ 16:56:
Dan zou je een HttpHandler moeten gebruiken, waarbij je direct de response stream kan aansturen zonder overhead van System.Web.UI.Page

Ik ga me daarin verdiepen. Dat klinkt wel als de netste oplossing.

joopst schreef op woensdag 05 juli 2006 @ 15:28:
van mij mag het
maar in zijn requirements gaf hij aan dat hij graag een aspx had ...

Ik heb mezelf niet goed verwoord. Ik moet niet per se een aspx hebben, het moet alleen standaard in het .Net framework zitten.... maar toen ik de post maakte, wist ik nog niets van ashx-jes