HTTP compression for the Integrated ITS
Until the Integrated ITS 7.01 (Kernel 7.01, SAP_BASIS SAPKB701xx), the HTTP compression for ITS-related services could be achieved by setting a flag in the service node via transaction code SICF. How to achieve the same result in the new Integrated ITS 7.02 (Kernel 7.20 and higher, SAP_BASIS SAPKB702xx) or higher releases?
“Old” days
The HTTP compression for the Integrated ITS 7.01 (and predecessors) could be achieved by simply setting the “Compression” item in the service data to “Yes”. For the WEBGUI, two services should be changed:
/default_host/sap/bc/gui/sap/its/webgui:
And /default_host/sap/public/bc/its/mimes:
An HttpWatch trace would reveal the HTTP compression enabled:
If you note that there is no HTTP compression for a given file extension type, e.g. *.js, then you might think that this is a case of checking SAP note 1037677. Are the settings are being used (e.g. parameter ict/exclude_compression)?
ITS based on Kernel 7.20 and higher
As of this new release, the ITS started to use the Unified Rendering technology: it offers a HTML rendering kit for different runtimes (e.g. Web Dynpro for ABAP, Web Dynpro for Java, BSP, HTMLB). This new UR technology was founded to reduce the amount of HTML frameworks and to minimize the effort for style adjustments (now the look and feel is the same as other runtimes, then the integration with the Portal is better, i.e. there is no disruption in the way the users see the pages).
This new technology has two variants: Classic and LightSpeed. The first is already deprecated, so the ITS uses the LightSpeed one, which uses a complete new AJAX based JavaScript framework.
The MIMEs from the new ITS are delivered as part of the kernel (the ICM process extracts the ITS.SAR file when the instance is -tarting – if the content of the ITS.SAR is newer than the existing in the file system).
With this change, the ICF no longer process the MIMEs from the ITS, i.e. the “Compression” setting in the /default_host/sap/public/bc/its/mimes node at SICF has no effect.
The ICM does not have the ability to compress HTTP data, so the MIMEs from the Integrated ITS are delivered as they are.
The solution for the time being is installing a reverse proxy (Apache) between the web application server and the web browser (actually this depends on the current landscape).
The Apache configuration should be similar as this:
“…
# For the reverse proxy:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_scgi_module modules/mod_proxy_scgi.so
<IfModule proxy_module>
ProxyRequests Off
# Enable/disable the handling of HTTP/1.1 #Via:# headers.
# (#Full# adds the server version; #Block# removes all outgoing Via: headers)
# Set to one of: Off On Full Block
ProxyVia On
# XXX system: replace <FQDN> for the actual FQDN and <PORT> for the
# HTTP ICM port
ProxyPass / http://<FQDN>:<PORT>/
ProxyPassReverse / http://<FQDN>:<PORT>/
</IfModule>
# Replace the URLs of ProxyPass and ProxyPassReverse.
# This example forwards everything through the proxy.
…
# For the compression:
LoadModule deflate_module modules/mod_deflate.so
<IfModule mod_deflate.c>
DeflateCompressionLevel 9
# Logging
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat ‘”%r” %{outstream}n/%{instream}n (%{ratio}n%%)’ deflate
CustomLog logs/deflate.log deflate
<Location “/sap/public/icmandir/its/”>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
</Location>
</IfModule>
# This enables compression for a certain “Location” only.
# Adjust the path to the icmandir folder. The Logging can be used
# to verify which pages have been compressed and with what rate.
# For production use it should be disabled.
…”
The excerpt above was used in an Apache 2.2. Other reverse proxies can be used in order to have the same effect, but the configuration for them is out of scope in this blog.
Of course, compression happens only in the first time. The second time the same MIME file is requested, the web browser cache is used instead. The bottom line is that you need to assess whether having a third party tool for compression will bring gain to your landscape – or you might be adding only another point of failure.
Hello Cristiano,
Thank you very much for your blog, really eye-opening document.
We are running S/4 HANA 1511, our users access the system only through Fiori Applications , and performance is our main issue right now, especially for the Fiori applicationsĀ using the ITS.
We are considering deploying a reverse proxy to compress the HTTTP data and see if it makes any difference. We are not familiar with Apache . Do you know if HTTP compression could be done using the SAP Webdispatcher ?
Thank you