First Things First: Installation
I've recently installed ABAP2XLSX on a BI server (NetWeaver 7.3). My login language is German. Installation with the current SAPLink build went smoothly with some glitches:
- The DDIC objects loose their description. Interestingly the descriptions show in the tree view of SE80 but not on the DDIC editor pane. I cannot change any DDIC objects unless I update the description field. (This is probably more of a SAPLink issue). OTH, activation of the DDIC objects went without problems. It looks like the texts are stored somewhere but cannot be correctly mapped by the DDIC editor. Strange...
- I was unable to directly import the package into a DEVC package. There were problems writing the objects (any type, not just DDIC or code) to a transport request. (This is probably more of a SAPLink issue, too). I fixed this by importing into $TMP first and migrating everything to my development package after the SAPLink import.
- Activation is, to say the least, tricky. Is it really necessary to define all structured types and tables as global DDIC objects? I'd prefer type definitions in the global section of some class. I know that this will change the signature of some functions which refer to objects of the types in question, but it would save the hassle with the circular references between classes and structures. I hope that my transport request to the QA system gets through without problems.
Performance of ZCL_EXCEL_WRITER_2007
Some simple modifications do improve the performance of said class significantly. Background: I'm creating large (huge) files with a large amount of rows. These come from a BI query. We are talking about several hundreds of thousands or even millions of rows. The time required to write such a monster seems to grow quadratically with the number of rows in the output. It all boils down to s single cause: table access in ZCL_EXCEL_WORSHEET.
Take for example the attribute ROW_DIMENSIONS of type ZEXCEL_T_WORKSHEET_ROWDIMENSIO. The table type is defined a STANDARD TABLE WITH DEFAULT KEY. Access is through the field ROW with READ TABLE ME->ROW_DIMENSIONS WITH KEY ROW. I get much improved throughput with some simple changes:
- Change the table type to HASHED.
- Define ROW as the primary key
- Access the row with READ TABLE ME->ROW_DIMENSIONS WITH TABLE KEY ROW
- Replace APPEND INITIAL LINE TO ME->ROW_DIMENSIONS by:
DATA: l_s_row_dimension LIKE LINE OF row_dimensions.
" ...
l_s_row_dimension-row = ip_row.
l_s_row_dimension-row_dimension = r_row_dimension.
INSERT l_s_row_dimension INTO TABLE me->row_dimensions.
All code changes are in GET_ROW_DIMENSION.
There are more internal tables with similar access paths. As soon as such a table grows large, performance degrades. I've seen a post (and could locate the related code changes) which deals with the SHARED_STRINGS table in ZCL_EXCEL_WRITER_2007. As a result of this discussion the table is now SORTED and ACCESS is WITH BINARY SEARCH. I'm sure a HASHED table with a primary key is the better solution here, too.
Automatic Column Width
This is a nice feature, but don't use it for large worksheets! When writing the output, ZCL_EXCEL_WRITER_2007 tries to determine the correct column width by testing all cells in the worksheet. This takes a considerable amount of time. Just leave this kind of work to Excel! It's only a few clicks away.
Summary
ABAP2XLSX is a huge effort and well designed (from an OO programmer's standpoint 
). I'm pretty sure my customer will accept its installation in his production environment. At the moment, performance is an issue to be solved. I hope my comments help to improve ABAP2XLSX. I'm waiting for comments.
Marcus von Cube