Out of the box, the icCube Web Reporting application is hosted within the embedded HTTP server of icCube. This setup is well suited for “simple” production usages that do not require an instensive usage of the HTTP server. For a more intensive reporting usage (e.g., reports publicly available to a large audience) we advise hosting the Web Reporting application within an enterprise Web server (e.g., Apache) and let icCube process the analytical (i.e., MDX) requests only.

This article will focus on the first use case and describes how to cache Web Reporting application files (i.e., HTML/CSS, Javascript) and how to hide icCube behind a proxy as well as using a friendly URL to start the Web Reporting on a given report acting as an entry point for the available dashboards.

To illustrate the different use cases, Apache is going to be used but this should work with other Web servers adapting the configuration settings.


There are several reasons to hide icCube behind a proxy (e.g., security, URL mapping, integration within an existing Web application, etc…).

For example, lately one of our customers could not access icCube using its installation URL because of enterprise firewall constraint. The solution was to configure the enterprise Web server (Apache in that case) to act as a reverse proxy to icCube. The following VirtualHost configuration was enough to forward all HTTP requests for to an internal location and different port:

<VirtualHost *:80>
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
ProxyPass        /icCube
ProxyPassReverse /icCube<

This way the Web Reporting URL becomes availabe as which is accepted by the firewall.

Friendly URL

The same customer has created a report acting as an entry point where users could select one of the available dashboards and wanted to have a friendly URL pointing to this report instead of an icCube permaLINK (i.e., something The solution was to add an URL rewrite rule in Apache (RewriteRule). This rewrite rule is mapping the friendly URL into that permaLINK URL. Note that a RewriteRule contrary to a Redirect does not change the URL in the browser. The following was added to the previously described VirtualHost:

RewriteEngine On
RewriteRule ^/dashboard /icCube/doc/ic3report?id=100a0ebf&menu=off&mode=reporting [PT,E=_ic3_rewritten:1]
# required in case /dashboard hit a login form (redirected on the server)
RequestHeader set _ic3_rewritten "" env=_ic3_rewritten
# the initial HTML file contains paths that are wrong due to /dashboard rewriting
# this proxy is fixing them
ProxyPass        /ic3-report
ProxyPassReverse /ic3-report


The Web Reporting application is made of HTML, CSS and Javascript files. Thoses files are hosted within the Docs application. Those files are served using the embedded HTTP server (i.e. Jetty). Since icCube 5.1.7, it is possible to configure the HTTP headers added to the HTTP responses for these files. The configuration of the headers is done by adding an <app-headers> section withn the <reportingComponentConfiguration> section within the icCube.xml file. The following example is adding the Cache-Control header with a max-age of one year:

 <app-header-value>public, max-age=31536000</app-header-value>

Note that existing icCube.xml files are not automatically migrated so when migrating to icCube 5.1.7 onwards, existing icCube.xml files must be manually updated if required.

Final Words

This short article introduced basic icCube Web Reporting configuration and integration into Web Application which is quite a large subject. So stay tuned for more configuration/integration articles on this subject or ask your questions (tags: iccube, iccube-reporting).

By David Alvarez