cancel
Showing results for 
Search instead for 
Did you mean: 

PDF in BSP with filesize bigger 1mb

Former Member
0 Kudos

Hello,

i'm currently on a problem loading a pdf from the content management server to my BSP with a filesize bigger 1 mb. The transfer stops without showing any error at<b> 1023999 bytes</b>.

Is there any possibility to change ICM parameters or Service or BSP parameters to get files bigger 1 mb from the backbend to the browser?

thanks in advance

Felix

Accepted Solutions (1)

Accepted Solutions (1)

GrahamRobbo
Active Contributor
0 Kudos

Hi Tom,

I deliver image files that are much larger than this all the time. I do not recall having to set and parameters to achieve this.

Are you sure you are not filling up some data structure in you code?

Cheers

Graham

Former Member
0 Kudos

Hi Graham,

thanks for there repley. I'm not sure if i'm messing things up. Therefore i will post you the coding from the onRequest of the bsp:

*" Data

data: lv_length type /it2/bapi_efile_basic_struc-length,

lv_len type i,

lv_string type string,

lv_doc_type type /it2/bapi_efile_basic_struc-doc_type,

lv_mimetype type /it2/bapi_efile_basic_struc-mimetype,

ls_return type bapiret2,

ls_toav0(158) type c,

lt_docs type table of docs,

pdf_xstring type xstring.

*" Prg

ls_toav0 = efile_toahr.

*" Document lesen

call function '/IT2/BAPI_EFILE_DOC_STRI_GET'

exporting

document_id_toav0 = ls_toav0

importing

return = ls_return

length = lv_length

doc_type = lv_doc_type

mimetype = lv_mimetype

tables

archivobject = lt_docs.

if ls_return-type ca 'EA'.

append ls_return to return_tab.

else.

*" Ausgabelänge konvertieren

lv_len = lv_length.

*" mimetype konvertieren

lv_string = lv_mimetype.

*" konvertierung des docs

call function 'SCMS_BINARY_TO_XSTRING'

exporting

input_length = lv_len

  • FIRST_LINE = 0

  • LAST_LINE = 0

importing

buffer = pdf_xstring

tables

binary_tab = lt_docs

exceptions

failed = 1

others = 2.

if sy-subrc <> 0.

endif.

*" BSP Umkonfigurieren

mresponse->set_header_field( name = 'content-type'

value = lv_string ).

mresponse->set_header_field( name = 'cache-control'

value = 'max-age=0' ).

mresponse->set_data( data = pdf_xstring

length = lv_len ).

*" Konfiguration abgeschlossen

navigation->response_complete( ).

endif.

The FM does a few checks and then loads a pdf as binary usinf FM "archive_get_table" via the TOAHR and a CMS. The filelength is allways 1023999 bytes

Cheers

Felix

GrahamRobbo
Active Contributor
0 Kudos

Hi Tom,

you seem to be building the response payload correctly, assuming the data that is in pdf_xstring is a valid PDF data stream. I still suspect that your client might be the cause of the problem.

Anyway, you could check in a mime file of a PDF that is bigger than the limit you are hitting and see if you can get to it with a http request. This would eliminate any WAS configuration issues as the problem.

It is possible that your data stream might not be a valid PDF. Use the debugger to ensure you are setting the correct content-type and that the data in pdf_xstring looks okay.

Finally, here is a snippet of code I use to send a .PDF response payload. This is a smartform that I run and convert to PDF using fm CONVERT_OTF.

response->set_header_field( name = 'content-type'
value = 'application/pdf' ).

* some Browsers have caching problems when loading PDF format
response->set_header_field(
name = 'cache-control'
value = 'max-age=0' ).

* display PDF format in Browser
l_pdf_len = XSTRLEN( l_pdf_xstring ).
response->set_data( data = l_pdf_xstring
length = l_pdf_len ).

navigation->response_complete( ).

Cheers

Graham

Cheers

Graham

Former Member
0 Kudos

Hi Graham,

here the full story, we build a webbased personnel file for each employee unsing MVC and htmlb:tree. if you click on the docoumtent a new window opens BSP withaout MVC and the code i send you.

In the personnel file are included pdfs, jpgs and a few pngs. Everything works perfect as long as you open documents with a filesize less than 1024000 bytes (1mb). If you are trying to trnasfer a file bigger than 1 mb from the backend - only 1023999 Bytes are ranferd an so the file is corrupted an can not be shown in the browser or the pdf-browser-plugin. so much to the question if the datastream is correct and that is the main point (we have the same scenario using dynprologic in the SAP GUI (no WAS needed to show this one) and everything is fine.

The mimetype is set correctly by the fm.

But your idea with the http-request sounds interesting. Can you please explain what you mean by this?

Cheers and because i think it should be night now in Australia - a good night

Felix

GrahamRobbo
Active Contributor
0 Kudos

Hi Felix,

I am starting to get stumped by this problem.

The http-request idea was just to upload a large mime file ( greater then the 1mb you are having a problem with) and see if you can use it in a page.

Maybe a better idea would be to build a specific HTTP Handler for these PDF files. This is very easy to do, in fact for your example it is probably easier than using BSP.

<a href="/people/brian.mckellar/blog/2003/09/30/bsp-in-depth-writing-an-http-handler weblog</a> from Brian McKellar should give you enough information about how to build and enable it.

Cheers

Graham

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Tom,

the only parameter I could think of is icm/HTTP/max_request_size_KB

Check this one out in rz11. The default is usualy set to 100 MB and I would

have guessed that it's only for incoming requests but you never know and can give it a try.

Another thing pops into my mind when you mention pdf. Adobes plugin sometimes shows a little strange behaviour which also is sometimes version dependent.

One thing is described in SAPNote 904314.

Another funny behaviour I've experienced once was that the pdf wasn't shown when there was no .pdf in the filename to open. There the solution was to add filename=dummy.pdf as the first parameter to the query string of the page/controller delivering the file.

If this does not solve your issue I'd go for tracing the http-communication between server and client and try to figure out what's happening by having a look at the http-headers of the communication. With that you might be able to nail down the cause of the issue (WebAS or Client).

Best Regards

Michael

Former Member
0 Kudos

Hi Michael,

first off all - thnks for the reply. I allready tried the ICM Paramters but without any effect - ass you've suggested.

The concernce you wrote about the filennames and all these stuff are not the problem, becuase below 1 mb everthing is fine.

You are right with your suggestion of the http-communication from client to WAS and back, but somewhere in the WAS config is a limitation per session oder per request-response of 1 mb and i can not find where.

The clientside can not be a probelm and the plugin is ok, because if i open a pdf in browser from a non-SAP site with a filesize of much more than 1 mb it is loaded and shown correctly.

Therefore i can say for sure that the WAS is limiting the filesize to 1mb, and there is no public ICM-paramter to change that...

But i will now try a new approch. I will first off all check the filesize, divide it by 1024000 and load than parts of it vai a do x times. enddo. in the onRequest. The browsercache is handled by ie and windows localy and therefore can go on with more than 1 mb - at least i hope so.

on the others side i openend an OSS and hope that someone inside the SAP might help.

cheers for the moment, i will post if the splitt worked as temporary solution.

Felix

Former Member
0 Kudos

Hi Felix,

I'd still recommend to check the issue with the gzip-compression (in IE disabling the use of HTTP 1.1 on the advanced tab in the Internet options and restart of IE will force to HTTP 1.0 without gzip-compression). As the other site might only use HTTP1.0 or has disabled gzip-compression for pdf's this might still be an issue.

Just a brief story about IE and why I wouldn't rule out the plugin issue:

Some Version of IE have problems with large posts and using https. So if you have a slightly different version of IE installed (one patch is sufficient) or if you use http instead of https you will not be able to reproduce the issue. Even better if you disabled the "show friendly http error message" option in IE the error didn't occurr either, or to be more exact it occurred but nothing happend and the user thought the click wasn't taken correctly and clicked again and then it worked (check SAPNote 900804).

I became a glue about this because I monitored the HTTP-communication and found the error_internet_cannot_connect messages of IE where in case the friendly HTTP error messages is ticked you get the IE error page and in case it is not ticked (which is the case on my PC for getting the bsp-errors in case of dumps) you just figure that the click wasn't taken and click again.

With this in mind I never rule out the frontend but check the http-communication just to be sure.

Besides that, did you try to take a trace of the icm? If you increase the tracelevel to 3 (transaction smicm under menu point goto) you can also see the content and the size that is returned and maybe even a hint/warning/error message in case the response is stopped.

Give us an update if you find anything new about that.

Michael

Former Member
0 Kudos

Hi Michael,

i increased the tracelevel an found out nothing new. But the hint was ok. We already did - for the OSS - a watchtrace which gave usexactly the same infomration as the trace of the ICM in Tracelevel 3.

So i'm nearly through with my coding and will try in a few minutes if this aproach works as temporary solution.

cheers and i will inform if it worked...

Felix

Former Member
0 Kudos

Sorry to everybody here, the problem is solved - the OSS will be closed. Some other developer had made a msitake within the FM the archivetable is reading...

Realy so sorry...

Cheers and thanks a lot for your participation.

I changed all the FM to the original ARCHIVOBJECT_GET_TABLE ... STATUS_GET and it worked out fine.

Cheers

Felix

Message was edited by: Tom Felix Baumann

Some additional information:

The error can be produced by using the fm ARCHIVOBJECT_GET_BYTES instead of the fm ARCHIVEOBJECT_GET_TABLE

Bye

Felix

Tom Felix Baumann