Waiting too long for Web Dynpro with FileDownload UI

[Former Member]

Hi,

in my application I use a FileDownload-UI to open different kinds of documents,

like PDF, JPEG etc.. But if I use this UI for a big Document with for example 50

MB, I had to wait a long time before the Web Dynpro appears. I couldn't find my

mistake, please help me.

  public void getByteArrayOutput( int num, java.lang.String url, java.lang.String file_size )
  {
		URL u = new java.net.URL(url);
		URLConnection c = u.openConnection();
		InputStream is = c.getInputStream();
		ByteArrayOutputStream out = new ByteArrayOutputStream();
		int length;
		int size = Integer.parseInt(file_size); 
		byte[] part = new byte[size];
		while ((length = is.read(part)) != -1) {
			out.write(part, 0, length);
		}
		is.close();						
		wdContext.currentContextElement().setAttributeValue("FileResource"+num, out.toByteArray());
}


  public void showUI(){

	final IEt_Doc_LinksNode node = wdContext.nodeEt_Doc_Links();	

	for (int i = 0; i < node.size(); i++)
	{			  			
		IEt_Doc_LinksElement e = node.getEt_Doc_LinksElementAt(i);	

		IWDAttributeInfo attributeInfo = wdContext.getNodeInfo().
			addAttribute("FileResource"+i,"com.sap.dictionary.binary");	
							
		IWDModifiableBinaryType binaryType =
			(IWDModifiableBinaryType) attributeInfo.getModifiableSimpleType();			

		wdThis.getByteArrayOutput(i,e.getUrl(),e.getFile_Size());

		binaryType.setFileName(e.getFile_Name());

		binaryType.setMimeType( new WDWebResourceType(e.getDoc_Type(),"application", true) );
		...
	}
}			

regards,

sharam

[Sigiswald]

Hi Sharam,

First, I see you load the file for all elements in your node at once. This may seriously impact performance, depending on the number of elements and the size of the files.

In case you're using NW04s, you can lazy-load the file, i.e. load it when the user clicks on the FileDownload UI element. See <a href="http://help.sap.com/saphelp_nw2004s/helpdata/en/42/f6ec5a09321bc7e10000000a11466f/frameset.htm">Loading the InputStream at FileDownload on Demand</a>. This won't work in NW04, but you could create some (ugly) workaround, e.g. when the user clicks once, load the file and populate the FileDownload element, after which the user has to click a 2nd time to download the file.

The code you use can be a little bit optimized. It's quite useless to create a byte[] buffer the size of the file since the file is read over the network in relatively small chunks anyway. Personally, I wouldn't rely too much on the file_size property too. Second, be sure to close the InputStream using a finally block.

private static final int DEFAULT_BUFFER_SIZE = 1024 * 4;

public static byte[] toByteArray(InputStream input) throws IOException {
  ByteArrayOutputStream output = new ByteArrayOutputStream();
  byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
  int n = 0;

  while (-1 != (n = input.read(buffer))) {
    output.write(buffer, 0, n);
  }

  return output.toByteArray();
}

public static byte[] toByteArray(String url) throws IOException {
  URL source = new URL(url);
  InputStream input = source.openStream();

  try {
    return toByteArray(input);
  } finally {
    try {
      if (input != null) {
        input.close();
      }
    } catch (IOException e) {
      // ignore
    }
  }
}

Either way, it does take time for your application to read a 50MB file from the network, especially when you read multiple files (multiple elements in the context). And maybe nice to know is that when you store a binary value in the context, the Web Dynpro framework won't keep it in memory but store it to a (disk based) cache. That too takes some time. In case you have the virus scanner enabled, it will also scan the file while writing it to the cache.

Maybe in your specific case it's better to use a LinkToURL UI element? Then the client can download the file directly, instead of via the Web Dynpro application (WD app uploads file from web sevrer, client downloads file from WD app)? The disadvantage is that the client must be able to access the web server where the files are stored. This might raise some security challenges.

Kind regards,

Sigiswald