[.NET]PDF streamen d.m.v. webservice

[Verwijderd]

Hallo,

Ik ben bezig om een pdf to d.m.v. een webservices aan een client aan te bieden. Hierbij converteer ik het PDF document om naar een byteArray en deze geef ik als response mee aan de webservices.

Deze byteArray wordt door een report programma genaamd Stimulsoft gegeneerd. Hierbij krijg ik via de webservices ongeveer zo'n 1,6 miljoen bytes binnen.

Op de client kant wil ik deze bytes inlezen en converteren naar een PDF bestand. Hierbij moet ik denk ik ook iets van een contentType meegeven, tenminste dat verwacht ik. Ik krijg het helaas niet voor elkaar om een onbeschadigd PDF bestand te creeeren van de data die ik verstuur.

code:

FileStream f = new FileStream(appDirectory + "\\App_Data\\oke.pdf", System.IO.FileMode.Create, System.IO.FileAccess.Write);
f.Write(response.Report.Base64ReportCode, 0, response.Report.Base64ReportCode.Length);
f.Close();

Hebben jullie ideeen.

[Gerco]

Misschien ben je vergeten om een base64 decode over de data te halen? Zo te zien schrijf je base64 encoded data weg naar de file zonder te decoden. Gezien de weinige informatie die je geeft kan ik dat echter niet zeker weten...

[Grijze Vos]

Volgens mij hoef je niet te decoden client side, probeer eens gewoon de byte array weg te zetten in dat pdf bestand.

[R4gnax]

Grijze Vos schreef op vrijdag 11 september 2009 @ 18:17:
Volgens mij hoef je niet te decoden client side, probeer eens gewoon de byte array weg te zetten in dat pdf bestand.

Klopt. Een byte array wordt door de .NET XML webservices automatisch geserialiseerd als een base64 string en de clientside proxy die je a.d.h.v. de wsdl file genereert bouwt deze automatisch weer om naar een byte array.

[ Voor 25% gewijzigd door R4gnax op 11-09-2009 19:29 ]

[Verwijderd]

Ik krijg inderdaad de bytes weer netjes terug maar zoals ik al in het code voorbeeldje laat zien hoe ik het pdf bestand weer terug wil genereren wil dat toch helaas niet helemaal lukken. Moet er niets iets van een content type meegestuurd worden ? hoe weet de client dat het om een base64 pdf format gaat ? En ik heb dus geen aparte decoder nodig ?

Verder kan ik volgensmij niet veel meer informatie geven ? wat ik nog wel kan vermelden is dat het originele bestand 215kb groot is. Als het vanaf de webservices terugkomt is het ongeveer 1250kb groot. De string dus gewoon in het bestand wegschrijven gaat dus niet goed.

Ik heb effe geen oplossing meer jullie misschien?

[Grijze Vos]

Post eens de functie in je webservice die de PDF verstuurt.

[Verwijderd]

code:

public byte[] Convert(OrderData orderData)
        {
            StiReport report = new StiReport();
            report.Load(appDirectory + "\\App_Data\\DemoRapport.mrt");
            report.Dictionary.Synchronize();

            DataSet ds = new DataSet();
            ds.ReadXml(appDirectory + "\\App_Data\\Demo.xml");
            ds.ReadXmlSchema(appDirectory + "\\App_Data\\Demo.xsd");

            report.RegData(ds);
            report.Render(false);
            StiPdfExportService pdfExport = new StiPdfExportService();
            
            pdfExport.ExportPdf(report, appDirectory + "\\App_Data\\TestDocument.pdf");
            byte[] binaryData = report.SaveDocumentToByteArray();
            
            return binaryData;
        }

Met the orderData doe ik op het moment helemaal niks. In dit voorbeeld is dat ook nog niet nodig.

[ Voor 6% gewijzigd door Verwijderd op 14-09-2009 08:48 ]

[Grijze Vos]

Hmm, hoe groot is het byte array dat aangemaakt wordt door die functie op het einde, en hoe groot is de opgeslagen PDF?

En wat is StiReport voor iets? Google kent het niet.

[ Voor 19% gewijzigd door Grijze Vos op 14-09-2009 08:54 ]

[Creepy]

code:

f.Write(response.Report.Base64ReportCode, 0, response.Report.Base64ReportCode.Length);

Schrijf je hier niet direct het report in base64 in de file weg? Als ik het zo bekijk zul je zelf nog de ontvangen data moeten decoden.
Met googlen op Base64ReportCode krijg ik in elk geval geen bruikbare resultaten. Is dat een zelf geschreven iets?

Controleer voor de zekerheid de weggeschreven file eens door te openen met een text editor.

[ Voor 30% gewijzigd door Creepy op 14-09-2009 09:03 ]

[Verwijderd]

The byteArray heeft deze grootte : {byte[1213189]}

Dat PDF document genaamd TestDocument.PDF is 215kb groot. Maar dit is direct een export van the report generator en dat werkt goed kan direct werkend openen.

De software die gebruikt wordt is van Stimulsoft. Hier bieden ze een aantal pakketten aan waarvan ik de dotNet variant heb gebruikt. http://www.stimulsoft.com/reportsnet.aspx.

Als de webservice door de client aangesproken wordt en de data overdraagt dan wordt de nieuwe PDF 1185kb groot.

The byteArray aan de clientkant is: {byte[1213189]} oftewel even groot als aan de serverkant.

[CodeIT]

En als je die byte array gewoon wegschrijft in de file, zonder Base64ReportCode etc, krijg je dan een goed werkende PDF?

[Grijze Vos]

Mja, als die PDF op de server wel gewoon opent ligt het dus aan SaveDocumentToByteArray().
Die geeft andere output dan de geexporteerde PDF.

Probeer eens gewoon die geexporteerde file meteen weer in te lezen in een byte array en die te sturen.

[Woy]

Probeer anders eerst eens wat eenvoudigers. Probeer bijvoorbeeld gewoon een byte array van 256 bytes, met oplopende waardes te versturen. Kijk dan aan de andere kant of je die byte array weer onbeschadigd terug krijgt.

Zolang je dat niet voor elkaar krijgt hoef je je nog helemaal niet bezig te houden met PDF o.i.d. want dan gaat het al mis bij je data transfer.

Als dat lukt kun je lokaal eens proberen de PDF weer weg te schrijven naar een bestand. Als dat al niet lukt zit het probleem niet in de web-service maar in het genereren van de PDF of in het wegschrijven ervan. Als je beide stappen voor elkaar hebt kun je ze combineren en zul je zien dat het gewoon werkt.

offtopic:
Ik heb je titel iets aangepast zodat hij aan onze wensen voldoet: *** Over topictitels in PRG - lezen voor topic openen!!! ***

[ Voor 10% gewijzigd door Woy op 14-09-2009 09:24 ]

[Verwijderd]

Dat is precies wat ik doe. Die base64ReportCode is een veld in een klasse die ik zelf gemaakt hebt. Die byteArray wordt gewoon letterlijk weggeschreven in een file naar mijn idee.

2 Woy

Ik heb die byteArray als gecontrolleerd zowel op server als clientSide waarbij deze indentiek zijn aan elkaar.

[ Voor 25% gewijzigd door Verwijderd op 14-09-2009 09:26 ]

[D-Raven]

Het klinkt inderdaad alsof dat ding nog ergens mee ge-encodeerd wordt. Is er anders geen tegenhanger van report.SaveDocumentToByteArray() waarmee je de byte array weer kan inlezen?

En anders probeer zelf eens die PDF naar een byte array om te zetten.


_{edit: ok, nu voel ik me spuit 11}

[ Voor 9% gewijzigd door D-Raven op 14-09-2009 09:25 ]

[Woy]

Ga dat dan eens debuggen! Kijk wat er in je byte array zit, kijk wat je erin zou verwachten, en kijk wat er uiteindelijk in je file staat.

Probeer het desnoods eens met een zelf gemaakte byte array

C#:

byte[] testArray = new testArray[256];
for(int i = 0; i < testArray.Length; i++)
    testArray[i] = (byte)i;

WriteToFile(testArray, filePath);
testArray = ReadFromFile(filePath);
//Hier kijken wat er in testArray staat

Als blijkt dat de array's aan de server en clientside identiek zijn, dan ligt het of aan de inhoud van de array, of aan het wegschrijven ervan! Ga de file die je schrijft dus eens vergelijken met het origineel, en kijk wat het verschil is.

[ Voor 21% gewijzigd door Woy op 14-09-2009 09:27 ]

[Verwijderd]

Ik zal dit even op een ander moment moeten uitproberen maar jullie horen van me. Wat ik me nog wel afvraag is hoe de client moet weten wat voor content type het is. Of is dat overbodig om dat jij het toch in een file wegschrijft met pdf als extensie.

[D-Raven]

Verwijderd schreef op maandag 14 september 2009 @ 09:35:
Ik zal dit even op een ander moment moeten uitproberen maar jullie horen van me. Wat ik me nog wel afvraag is hoe de client moet weten wat voor content type het is. Of is dat overbodig om dat jij het toch in een file wegschrijft met pdf als extensie.

Alles wat in het bestand staat is naar je byte array weggeschreven. Dus ook de file headers (en dus je content type). Dat jij het een pdf extensie geeft op het moment dat je het naar file wegschrijft doet niks af aan het feit of het een pdf bestand is of niet.

[Woy]

Content-Type is alleen nodig om aan de client aan te geven wat voor type bestand het is. Dit word dus vooral bij bijvoorbeeld HTTP gebruikt waar de client anders nooit kan weten in welke context hij de data moet zien. Omdat jij bij een web-service die context al weet, heb je niet perse een content-type nodig. Content-Type is dan ook gewoon een header die meegestuurd word, en maakt niet daadwerkelijk onderdeel uit van de data.

Doordat jij het in een bestand wegschrijft die de .pdf extensie heeft, weet het OS dat het bestand geopend moet worden met een applicatie die dergelijke bestanden kan verwerken. Het is niet zo dat er op het file-system iets als een "content-type" bestaat. In principe word ( in Windows ieder geval ) de beslissing welk programma de file opent puur gebaseerd op de extensie. "content-type" is dus echt iets voor communicatie, want de client hoeft immers niet altijd te weten wat hij binnen krijgt.

offtopic:
edit: Moet sneller leren type

[Gerco]

Verwijderd schreef op maandag 14 september 2009 @ 09:12:
The byteArray heeft deze grootte : {byte\[1213189]}

Dat PDF document genaamd TestDocument.PDF is 215kb groot. Maar dit is direct een export van the report generator en dat werkt goed kan direct werkend openen.

Dan is de byte array dus veel groter dan de gegenereerde PDF. Save die byte array eens naar disk en probeer deze te openen met een PDF reader. Grote kans dat je dan ziet wat er mis gaat. 215kB is niet 12131189 bytes, dat is namelijk 1184kB. Je probleem (als dat het is) treed al op voor je de byte array verstuurt.

[R4gnax]

Grijze Vos schreef op maandag 14 september 2009 @ 09:22:
Mja, als die PDF op de server wel gewoon opent ligt het dus aan SaveDocumentToByteArray().
Die geeft andere output dan de geexporteerde PDF.

Inderdaad.


Even een gokje: slaat SaveDocumentToByteArray() niet toevallig een geserialiseerde versie van de interne geheugen structuur van je report op (à la binary serialization), en niet de ge-exporteerde PDF?

Let nl. eens op: De PDF wordt ge-exporteerd via een speciale PdfExport klasse, de save-to-array method zit direct op het rapport...

[Jeroen V]

Ik ken StiRoport niet, maar zat net even in de documentatie te neuzen, en het lijkt erop dat je het op een andere manier moet doen.

Kijk eens even in de help file naar de ExportDocument methode, daar zie ik het volegnde staan:

code:

MemoryStream stream = new MemoryStream();
report.ExportDocument(StiExportFormat.Pdf, stream);

Dit lijkt me iets handiger dan eerst dat PDF documentje daadwerkelijk weg te schrijven in de App_Data directory (lelijke vervuiling, en het zou problemen op kunnen leveren als twee gebruikers het tegelijkertijd doen)

De stream hierboven kan jew dan weer omzetten naar een byte array die gemakkelijk door de WebService doorgegeven kan worden.