Zip-Transfer-Unzip: Increase the performance of your Java-ABAP applications

Why compress ?

Often we need to transfer heavy files between Java and ABAP applications. This is a very common case when we have Frontend WebDynPro Java application and backend is ABAP (RFCs). Most types of computer files are fairly redundant — they have the same information listed over and over again.

For example in the following XML:

Aayush Dubey 1234567890 Praveen Pandey 2345678901 Rahul Jain 3456789012 Deepa Shankar 4567890123

Here the words “AddressBook”, “Contact”, “Name” and “PhoneNumber” are repeated many number of times. File-compression (ex. ZIP) code can help us to remove this redundancy.

How to do this in Java and ABAP?

I faced a similar issue in my application where there was a need to pass a heavy XML Strings as import parameter of an RFC function module. Another RFC FM returned a heavy XML String as an export parameter. Various compression APIs are available for Java and ABAP language. I worked with the classes in “java.util.zip” (Java side) and cl_abap_gzip (ABAP side). The zipped string from java side was passed and accepted as byte[] and at ABAP side it is of XSTRING data type.

Lets say we wish to transfer heavy XML String ABC from Java to ABAP, we can use the following methods:

Zip method for Java:

public static byte[] zipString(String abc) { byte[] abcZipped = null;ByteArrayInputStream bas = new ByteArrayInputStream(abc.getBytes()); ByteArrayOutputStream out = new ByteArrayOutputStream();ZipOutputStream zos = new ZipOutputStream(out); String entryName = “UniqueEntryName”;ZipEntry ze = new ZipEntry(entryName);try { zos.putNextEntry(ze); byte[] buf = new byte[1024]; int len;while ((len = bas.read(buf)) > 0) { zos.write(buf, 0, len); } zos.flush(); zos.closeEntry(); zos.close(); bas.close(); abcZipped = out.toByteArray(); } catch (IOException e) {System.out.println(“Unable to zip :” + e.getMessage()); } return abcZipped; }

Unzip method in ABAP:

> method ZIPTOSTRING.CALL METHOD CL_ABAP_GZIP=>DECOMPRESS_TEXT EXPORTING GZIP_IN = ZIPSTRING IMPORTING TEXT_OUT = VALUESTRING.endmethod.

Zip method in ABAP:

method STRINGTOZIP.CALL METHOD cl_abap_gzip=>compress_text EXPORTING text_in = VALUESTRING IMPORTING gzip_out = ZIPSTRING.endmethod.

Unzip method in Java:

public static String unzipByteArray(byte[] xyzZipped) { String xyz = null; byte[] zippedBytes = xyzZipped;ZipInputStream in = new ZipInputStream(new ByteArrayInputStream( zippedBytes)); try { ZipEntry entry = in.getNextEntry(); ByteArrayOutputStream out = new ByteArrayOutputStream();BufferedOutputStream bout = new BufferedOutputStream(out); byte[] buf = new byte[1024]; int len;while ((len = in.read(buf)) > 0) { bout.write(buf, 0, len); } bout.flush(); xyz = out.toString(“UTF-8”); out.close(); in.close(); } catch (IOException e) {System.out.println(“Unable to Unzip :” + e.getMessage()); } return xyz; }

6 Comments

You must be Logged on to comment or reply to a post.

Guillaume GARCIA October 10, 2007 at 1:06 am

Hi,

Useful blog !

Did you achieve to determine according to both data size, data compression factor (if it is XML, binary, …), and bandwith, what is the actual point from which using this mecanism represents a real benefit ?

Indeed, using ZIP comes at a price, it would be very interesting to know when you can expect payback ! 😉

Best regards,
Guillaume

like (0)
1. Aayush Dubey Post authorOctober 10, 2007 at 2:19 am
  
  Hello Guillaume, Harsh,
  
  Thanks a lot for your comments. Here are some performance stats (ABAP to java transfer) which i took for different XML strings of different sizes (in KBs) and with different number of tags (open and closed tags are counted as once).
  
  Size(KB) Tags   Time(ms) New Time(ms)
  2326     516345     135057     8122
  16     966     2163     1722
  10     200     1011     772
  26     1672     2174     991
  18     720     1622     811
  23     1296     1823     791
  1     16     421     451
  9     168     1001     440
  9     92     972     441
  2     27     791     771
  35     896     2724     1352
  2     30     420     411
  3     50     421     421
  3     56     921     400
  8     170     981     420
  2     24     441     431
  1     0     410     421
  2     24     411     390
  4     64     781     421
  I observed that more the meta deta (tags), more improvement in performance.
  
  @Harsh -For other file types also it depends on the redundency of the data. For example having not many colors in an image file #000000 will be best to compress :).
  
  like (0)
Harsh Chawla October 10, 2007 at 1:13 am

Hi Aayush,

Good to see you here! 🙂

As Guillaume put it, are there any size guidelines for the payload?
i.e. at what size of the payload, does the zip/unzip processing give better returns than transferring the payload directly?

Also, I assume the guidelines would be payload format(txt,csv,xml,doc,pdf etc) dependent?

Looking forward to many more interesting posts from you!

Thanks,
Harsh

like (0)
Tarun Telang October 10, 2007 at 4:12 am

Hi Aayush,

To me it also appears that this approach will also bring performance improvements incase of ABAP-ABAP or JAVA-JAVA communication.

Best Regards,
Tarun

like (0)
Timothy Wise October 10, 2007 at 5:29 am

Interesting blog!

I am writing a separate Java program and using JCo to call RFMs from an SAP system. Is there any way to get the zip-transfer-unzip to happen automatically in JCo?

—
Tim

like (0)
Thomas Jung October 10, 2007 at 6:00 am

This is interesting. There is some automatic compression within the RFC library, but I believe the parameter has to be larger than 8kb in order to trigger the compression to happen. However there is the parameter WAN_CONN that can be used to trigger compression much sooner (after only 250 bytes).
jco.client.wan_conn=1.

I wonder what would happen with your test results if you activated the WAN_CONN flag?

like (0)