Home DevShare Designing BIRT Reports

Creating a ReportDocument without file access

Share

by Jan Kohner

DevShare - 1 post
Posted 14 Jun 2012 - 12:09 AM

(1)  (0)   (290 views)

By downloading this item, you are agreeing to the Terms of Use for the site.

Using a MemoryArchive to create a ReportDocument without file access.

Birt Version:-3.7

When creating a ReportDocument for example to extract data from a report or to store the documents bytes somewhere, BIRT API provides two ways. First is running 'ReportEngine.openReportDocument(String string)' with a string containing a file path. Second is running the method with A IDocArchiveReader object. Both ways are using files in the background. If however any file access is unwanted there is currently no simple way provided by API to do so.
I've written a MemoryArchive Class  (implements IDocArchiveWriter and IDocArchiveReader) that may be used for this purpose.
I wrote an IDocArchiveReader and IDocArchiveWriter implementation that uses memory byte fields only to create a document. It passed all my tests. However, I cannot assure that everything works with it! Especially the listStreams:relativePath. String method remains untested since all my tests return an empty list here (also when using FolderArchive). So at this point I only return any stream that contains the relativePath without knowing if this is a correct behavior.
The call is done like this:

MemoryArchive memoryArchive = new MemoryArchive();
runTask.run(memoryArchive);
Map<?, ?> properties = new HashMap<Object, Object>();
IReportDocument reportDocument = getReportEngine().openReportDocument(memoryArchive.getName(), memoryArchive, properties);

With this attached the source code. Do with it whatever you like. If you run into problems using it, or if it is just running fine, I would appreciate you feedback. Thank you!

Download (6.47 KB)

By downloading this item, you are agreeing to the Terms of Use for the site.



Forum - 500 postsLeaderboard - 10 timesDevShare - 1 postCommunity Advisor

cbrell

Posted: 14 Jun 2012 - 04:01 AM

This extension sounds awesome. So it does not include a single harddisc access? Did you know that Run and the Render is faster then RunAndRender if there is only a small amount of data? Using your extension it just could be much faster in general.

DevShare - 1 post

Jan Kohner

Posted: 14 Jun 2012 - 06:58 AM

Yes, it does not include a single hard disc access :) It runs with memory only. I did not know about the performance differences between both methods. Do you have a measurement scenario? Unfortunately I don't have one out of the box.

Forum - 500 postsLeaderboard - 10 timesDevShare - 1 postCommunity Advisor

cbrell

Posted: 15 Jun 2012 - 11:54 PM

I have done some measurements in the past. I m sure that i have some on my Box. I ll Run them and tell you about the results.
 
Filter More