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:
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:
Unzip method in ABAP:
>
Zip method in ABAP:
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
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 :).
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
To me it also appears that this approach will also bring performance improvements incase of ABAP-ABAP or JAVA-JAVA communication.
Best Regards,
Tarun
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
jco.client.wan_conn=1.
I wonder what would happen with your test results if you activated the WAN_CONN flag?