Sap Tomcat

Posted onby admin
  1. Sap Tomcat Version
  2. Sap Tomcat Download
  3. Sap Tomcat 8
  4. Sap Tomcat Login
  5. Tomcat Sap Bo
  6. Sap Tomcat Login


Apache Tomcat Versions

The Apache Tomcat serves as a “gateway” between the client (web browser) and the bi platform on a server. If a user tries to login the BI Launchpad, the process is as follows: The browser (web client) sends the login request via the web server to the web application server, where the web application is running. SAP BusinessObjects is built on J2EE framework that use Tomcat services for security, messaging, transaction coordination. All HTTP requests and returning web pages and other static or dynamic content. Below are some common problems that our clients experience with Tomcat: Session Time out in BI Launchpad.

Apache Tomcat® is an open source software implementation of asubset of the Jakarta EE (formally Java EE) technologies. Different versions ofApache Tomcat are available for different versions of the specifications. Themapping betweenthespecifications and the respective Apache Tomcat versions is:

Servlet SpecJSP SpecEL SpecWebSocket SpecAuthentication (JASIC) SpecApache Tomcat VersionLatest Released VersionSupported Java Versions and later and later and later (superseded)8.0.53 (superseded)7 and later and later
(7 and later for WebSocket) (archived)6.0.53 (archived)5 and later
2.42.0N/AN/AN/A5.5.x (archived)5.5.36 (archived)1.4 and later
2.31.2N/AN/AN/A4.1.x (archived)4.1.40 (archived)1.3 and later
2.21.1N/AN/AN/A3.3.x (archived)3.3.2 (archived)1.1 and later

Each version of Tomcat is supported for any stable Java release that meetsthe requirements of the final column in the table above.

Tomcat should also work on any Java early access build that meets therequirements of the final column in the table above. For example, users weresuccessfully running Tomcat 8 on Java 8 many months before the first stable Java8 release. However, users of early access builds should be aware of thefollowing:

  • It is not unusual for the initial early access builds to contain bugs that can cause problems for web applications running on Tomcat.
  • If the new Java version introduces new language features then the default JSP compiler may not support them immediately. Switching the JSP compiler to javac may enable these new language features to be used in JSPs.
  • If you do discover an problem using a Java early access build, please ask for help. The Tomcat user's mailing list is probably the best place to start.

The releases are described in more detail below to help you determinewhich one is right for you. More details about each release can be found inthe associated release notes.

Please note that although we offer downloads and documentation of olderreleases, such as Apache Tomcat 7.x, we strongly encourage users to use thelatest stable version of Apache Tomcat whenever possible. We recognize thatupgrading across major versions may not be a trivial task, and some support isstill offered on the mailing list for users of old versions. However, becauseof the community-driven support approach, the older your version, fewer peoplewill be interested or able to support you.

Alpha / Beta / Stable

When voting for a release, reviewers specify the stability level that theyconsider the release has reached. Initial releases of a new major versiontypically process from Alpha, through Beta to Stable over a period of severalmonths. However, the Stable level is only available once the Java specificationsthe release implements have been finalised. This means a release that in allother respects is considered stable, may still be labelled as Beta if thespecifications are not final.

The download pages will always show the latest stable release and any newerAlpha or Beta release if one exists. Alpha and beta releases are always clearlymarked on the download pages.

Stability is a subjective judgement and you should always read carefully therelease notes for any version you intend to make use of. If you are an earlyadopter of a release, we would love to hear your opinion about its stability aspart of the vote: it takes place on the development mailinglist.

Alpha releases may contain large amounts of untested/missingfunctionality required by the specification and/or significant bugs and are notexpected to run stably for any length of time.

Beta releases may contain some untested functionality and/ora number of relatively minor bugs. Beta releases are not expected to run stably.

Stable releases may contain a small number of relativelyminor bugs. Stable releases are intended for production use and are expected torun stably for extended periods of time.

Apache Tomcat 10.x

Apache Tomcat 10.x is the current focus of development. Itbuilds on Tomcat 9.0.x and implements the Servlet5.0, JSP 3.0, EL 4.0, WebSocket 2.0 and Authentication 2.0 specifications (the versions required byJakarta EE 9 platform).

Apache Tomcat 9.x


Apache Tomcat 9.x is the current focus of development. Itbuilds on Tomcat 8.0.x and 8.5.x and implements the Servlet4.0, JSP 2.3, EL 3.0, WebSocket 1.1 and JASPIC 1.1 specifications (the versions required byJava EE 8 platform). In addition to this, it includesthe following significant improvements:

  • Adds support for HTTP/2 (requires either running on Java 9 (since Apache Tomcat 9.0.0.M18) or the Tomcat Native library being installed)
  • Adds support for using OpenSSL for TLS support with the JSSE connectors (NIO and NIO2)
  • Adds support for TLS virtual hosting (SNI)

Apache Tomcat 8.x

Apache Tomcat 8.0.x builds on Tomcat 7.0.x and implements theServlet 3.1, JSP 2.3, EL 3.0and WebSocket 1.1 specifications. In additionto that, it includes the following significant improvements:

  • A single, common resources implementation to replace the multiple resource extension features provided in earlier versions.

Apache Tomcat 8.5.x supports the same Servlet, JSP, EL, andWebSocket Specification versions as Apache Tomcat 8.0.x. In addition to that,it also implements the JASPIC 1.1 specification.

It was created in March 2016 as a fork from Tomcat 9.0.0.M4 (alpha)milestone release. It provides HTTP/2 support and other features fromTomcat 9.x codebase, while being compatible with Tomcat 8.0 runtime andspecification requirements. (A stable release of Tomcat 9.0 could not becreated at that time, as Java EE specifications targeted by Tomcat 9 werefinalized only a few years later).

Tomcat 8.5 is thought as a replacement for Tomcat 8.0. Please refer toMigration guide for guidance on migrating toTomcat 8.5.

Apache Tomcat 8.5.x includes the following significant improvements:

  • Adds support for HTTP/2 (requires the Tomcat Native library)
  • Adds support for using OpenSSL for TLS support with the JSSE connectors (NIO and NIO2)
  • Adds support for TLS virtual hosting (SNI)

The following technologies were removed in Apache Tomcat 8.5.x:

  • BIO implementation of HTTP and AJP connectors
  • Support for Comet API

There are significant changes in many areas under the hood, resulting inimproved performance, stability, and total cost of ownership. Please referto the Apache Tomcat 8.5 Changelog for details.

Users of Tomcat 8.0 should be aware that Tomcat 8.0 has now reachedend of life. Users of Tomcat 8.0.x shouldupgrade to Tomcat 8.5.x or later.

Sap Tomcat Version

Apache Tomcat 7.x

Apache Tomcat 7.x builds upon the improvements made inTomcat 6.0.x and implements the Servlet 3.0,JSP 2.2, EL 2.2 andWebSocket 1.1 specifications. In additionto that, it includes the following improvements:

  • Web application memory leak detection and prevention
  • Improved security for the Manager and Host Manager applications
  • Generic CSRF protection
  • Support for including external content directly in a web application
  • Refactoring (connectors, lifecycle) and lots of internal code clean-up

Users of Tomcat 7 should be aware thatend of life has been announced for Tomcat 7.Users of Tomcat 7.x should upgrade to Tomcat 8.5.x or later.

Apache Tomcat 6.x

Apache Tomcat 6.x builds upon the improvements made inTomcat 5.5.x and implements the Servlet 2.5 andJSP 2.1 specifications. In addition to that, it includes thefollowing improvements:

  • Memory usage optimizations
  • Advanced IO capabilities
  • Refactored clustering

Users of Tomcat 6 should be aware that Tomcat 6 has now reachedend of life. Users of Tomcat 6.x shouldupgrade to Tomcat 7.x or later.

Apache Tomcat 5.x

Apache Tomcat 5.x is available for download from thearchives.

Apache Tomcat 5.5.x supports the same Servlet and JSPSpecification versions as Apache Tomcat 5.0.x. There are significant changesin many areas under the hood, resulting in improved performance, stability,and total cost of ownership. Please refer to the Apache Tomcat 5.5 Changelogfor details.

Apache Tomcat 5.0.x improves on Apache Tomcat 4.1 in manyways, including:

  • Performance optimizations and reduced garbage collection
  • Refactored application deployer, with an optional standalone deployerallowing validation and compilation of a web application before puttingit in production
  • Complete server monitoring using JMX and the manager web application
  • Scalability and reliability enhancements
  • Improved Taglibs handling, including advanced pooling and tag plugins
  • Improved platform integration, with native Windows and Unix wrappers
  • Embedding using JMX
  • Enhanced Security Manager support
  • Integrated session clustering
  • Expanded documentation

Users of Tomcat 5 should be aware that Tomcat 5 has now reachedend of life. Users of Tomcat 5.x shouldupgrade to Tomcat 7.x or later.

Apache Tomcat 4.x

Apache Tomcat 4.x is available for download from thearchives.

Apache Tomcat 4.x implements a new servlet container (calledCatalina) that is based on completely new architecture. The 4.x releasesimplement the Servlet 2.3 and JSP 1.2specifications.

Apache Tomcat 4.1.x is a refactoringof Apache Tomcat 4.0.x, and contains significant enhancements, including:

  • JMX based administration features
  • JSP and Struts based administration web application
  • New Coyote connector (HTTP/1.1, AJP 1.3 and JNI support)
  • Rewritten Jasper JSP page compiler
  • Performance and memory efficiency improvements
  • Enhanced manager application support for integration with developmenttools
  • Custom Ant tasks to interact with the manager application directlyfrom build.xml scripts

Apache Tomcat 4.0.x. Apache Tomcat 4.0.6 is the old productionquality release. The 4.0 servletcontainer (Catalina) has been developed from the ground up for flexibility andperformance. Version 4.0 implements the final released versions of the Servlet2.3 and JSP 1.2 specifications. As required by the specifications, Apache Tomcat 4.0also supports web applications built for the Servlet 2.2 and JSP 1.1specifications with no changes.

Users of Tomcat 4 should be aware that Tomcat 4 has now reachedend of life. Users of Tomcat 4.x should upgrade to Tomcat 7.x orlater.

Apache Tomcat 3.x

Apache Tomcat 3.x is available for download from thearchives.

  • Version 3.3 is the current production quality release forthe Servlet 2.2 and JSP 1.1 specifications. Apache Tomcat 3.3 is the latestcontinuation of the Apache Tomcat 3.x architecture; it is more advanced then 3.2.4,which is the 'old' production quality release.
  • Version 3.2.4 is the 'old' production quality release and is now inmaintenance only mode.
  • Version 3.1.1 is a legacy release.

All Apache Tomcat 3.x releases trace their heritage back to theoriginal Servlet and JSP implementations that Sun donated to the ApacheSoftware Foundation. The 3.x versions all implement the Servlet2.2 and JSP 1.1 specifications.

Apache Tomcat 3.3.x. Version 3.3.2 is the current productionquality release. It continues the refactoring that was begun in version 3.2 andcarries it to its logical conclusion. Version 3.3 provides a much more modulardesign and allows the servlet container to be customized by adding and removingmodules that control the processing of servlet requests. This version alsocontains many performance improvements.

Apache Tomcat 3.2.x. Version 3.2 added few new featuressince 3.1; the major effort was a refactoring of the internals to improveperformance and stability. The 3.2.1 release, like 3.1.1, was a securitypatch. Version 3.2.2 fixed a large number of bugs and all knownspecification compliance issues. Version 3.2.3 was a security update thatcloses a serious security hole. Version 3.2.4 is a minor bug fix release.All users of Apache Tomcat versions prior to 3.2.3 should upgrade as soon aspossible. With the exception of fixes for critical security related bugs,development on the Apache Tomcat 3.2.x branch has stopped.

Apache Tomcat 3.1.x. The 3.1 release contained severalimprovements over Apache Tomcat 3.0, including servlet reloading, WAR filesupport and added connectors for the IIS and Netscape web servers. Thelatest maintenance release, 3.1.1, contained fixes for security problems.There is no active development ongoing for Apache Tomcat 3.1.x. Users of Apache Tomcat3.1 should update to 3.1.1 to close the security holes and they arestrongly encouraged to migrate to the current production release, Apache Tomcat3.3.

Apache Tomcat 3.0.x. Initial Apache Tomcat release.

Users of Tomcat 3 should be aware that Tomcat 3 has now reachedend of life. Users of Tomcat 3.x should upgrade to Tomcat 7.x orlater.

Note: This document is a supplement to the SCN Document Improving the User Experience in SAP BI Platform 4.0 with Apache and WDeploy. There are functional and configuration changes needed to deploy the solution successfully using the latest versions of SAP BusinessObjects BI Platform and Apache HTTPD. The core concepts covered in the previous document remain unchanged unless otherwise mentioned.

Downloading Apache 2.4 for Windows and supporting prerequisites

Since the release of the last document on this subject, generation of Windows binaries for Apache HTTPD has become a hot topic on the Apache users list. For a period of time only source code was available (as is the case with Linux/Unix versions) and, as of the time of writing, only 32-bit Windows binaries were available.

Due to these uncertainties, it is recommended that Windows users download Apache 2.4 from Apache Lounge, a website dedicated to supporting the HTTPD server project (i.e. Apache). Apache Lounge also provides supporting modules, such as mod_jk, and 64-bit binaries for comprehensive Windows support. For Linux/Unix implementations, it is recommended that you follow the instructions outlined in the BI4 Linux Pattern Book to build the server, and then follow the concepts in this document for configuration.

On Windows, it is also necessary to install the Visual C++ 2010 SP1 Redistributable Package x64 as these components are used to build the Apache server.

The following steps outline the required downloads for Apache 2.4:

  1. Download the Apache 2.4 64-bit package from
    • At the time of writing, the latest version was 2.4.7
  2. Download and Install the Visual C++ 2010 SP1 Redistributable Package x64 from
  3. Download the mod_jk connector binary from
    • At the time of writing, the latest version was 1.2.37
    • Extract the included and place it in E:Apache24modules (or whichever directory you extract Apache to) after you have completed the next section

Once these 3 items have been downloaded, and the VC++ dependency installed, you are ready to proceed to the next step.

Installation of Apache 2.4 as a Windows Service

The archive for Apache 2.4 contains the zipped directory structure of the web server and does not have a standard Windows installer. As such, it is necessary to extract the archive to a location of your choice, modify the configuration files to match your installation path, and install a Windows service. The structure of the archive is as follows:

By default, the zipped configuration expects to find the installation in C:Apache24. If you're able to extract it there you won't need to make any path based changes to the config files. In this document, however, I will extract the install to E:Apache24 to demonstrate what you will need to do to install Apache in a non-standard path or drive.

After extracting the installation to E:Apache24 the next step is to modify the httpd.conf file to reflect the new path. For a production environment it is likely you will need to modify permissions, configure SSL, and add modules for maintenance and support. Please refer to the Apache HTTPD 2.4 documentation for a comprehensive list of configuration options. Open the file E:Apache24confhttpd.conf in a text editor such as Notepad and locate the following lines:

Modify the paths to match the location of your installation, in this case E:/Apache24. Note that the file uses a Linux style path structure containing forward slashes instead of back slashes. BI 4.1 does not require use of CGI scripting so it may be disabled completely if desired. Save the file and exit.

The next step is to install Apache as a Windows service. This is done from the command line with a special directive to the httpd.exe executable. The following steps outline the process:

  1. Launch a Windows command prompt by running Start > Run > cmd
  2. Navigate to the Apache bin directory, in this case E:Apache24bin using a command like cdApache24bin (you may need to change drives first)
  3. Install a Windows service that shows up in the Central Configuration Manager by executing the command:
    httpd -k install -n BOEXI40Apache
    • Note that the CCM is configured to render any services labeled with a prefix of BOEXI40. By doing this we allow it to appear in the CCM for ease of management.
  4. Change the display name of the service to include the version of Apache:
    sc config BOEXI40Apache displayname= 'Apache HTTPD 2.4.7'
    The command should return successfully as below:
  5. Confirm that the CCM now shows the Apache HTTPD 2.4.7 service and that it can be started successfully:

Note that if you have the World Wide Publishing Service (IIS) on the server, it is required that you stop/disable it or ensure it runs on a port other than 80. You may test that Apache is running properly by accessing http://localhost. If the server is up and running you should get a simple HTML page with the text, 'It works!'

Running WDeploy in split mode

Now that Apache is installed and running, it is possible to split the static content and deploy it to your web server. It is recommended that you stop your application server, specifically if you're running Tomcat, as there can be file locking problems during the deploy phase of WDeploy. Furthermore, you should temporarily disable your virus scan software during the WDeploy phase, as there are thousands of files being written and an active virus scan can increase the time needed to complete the process by a large number of hours. In my case, running WDeploy with the virus scan disabled took ~25 minutes, while running it with the virus scan enabled took ~6 hours.

First, it is necessary to configure the WDeploy files so that the tool knows where to find your Apache distribution. Browse to the location C:Program Files (x86)SAP BusinessObjectsSAP BusinessObjects Enterprise XI 4.0wdeployconf and open the file config.apache in a text editor such as Notepad.

Locate and update the following lines:

Where ws_dir is the location of your Apache installation and connector_type is the application server in use. If you are using the default BI 4.1 installation the value of connector_type will be tomcat7. Save and exit the file.

Sap Tomcat Download

Next step is to run the WDeploy tool with certain parameters instructing it to split static and dynamic content. I'll cover a couple of scenarios here, primarily using a separate work directory of your choice to build the web applications, as well as the workaround for MOBIServer outlined in SAP Note 1900589. We'll break the WDeploy process into two steps, the first being the predeploy action. This action instructs the WDeploy tool to build the web applications from the source files provided with the installation, taking into account any custom properties files or branding that you have implemented.

Run the following commands to invoke the predeploy action:

  1. Start > Run > cmd
  2. Change to the WDeploy directory (in my case that is E:Program Files (x86)SAP BusinessObjectsSAP BusinessObjects Enterprise XI 4.0wdeploy)
  3. wdeploy tomcat7 -Das_mode=split -Dws_type=apache -Dwork_dir=e:temp predeployall
    • The parameters are as follows:
    • tomcat7 >> the target application server, in this case Tomcat 7
    • -Das_mode=split >> instructs WDeploy to create zip files containing static content such as JavaScript and Cascading Style Sheets as well as dynamic content packaged in war files.
    • -Dws_type=apache >> the target web server, in this case Apache. This instructs WDeploy to read the config.apache file we configured earlier.
    • -Dwork_dir=e:temp >> instructs WDeploy to write temporary files to the specified directory. This can be especially helpful if your install drive is running low on space. It is also helpful to find the predeployed files and make the adjustment noted in SAP Note 1900589.
    • predeployall >> WDeploy builds the application files but does not deploy them to Apache and Tomcat. We need to make an adjustment prior to deploying them.
  4. Upon completion of the predeploy action the work directory should look something like this:
    Note the zip files located in ${work_dir}temptomcat7resources. We can see that the BOE static resources file contains ~1.8GB of static content! In this example I also have Explorer installed, which as you can see from above is also supported for split deployment.

Now that the predeploy phase is complete, we will implement a workaround for the MOBIServer and deploy the previously built files to our web and application server pair. The reason for this step is that there are no static resource files associate with the MOBIServer ... everything is dynamic. We can see in the output of the previous action:

However, in the deploy phase WDeploy will still look for a file called and if it doesn't exist, the process will fail and throw an error. Fortunately there is an easy workaround documented in SAP Note 1900589 and for the sake of propriety I will cover it here.

Sap Tomcat

To implement the workaround, perform the following steps:

  1. Navigate to the WDeploy static resource directory, in this case E:temptomcat7resources
  2. Right-click somewhere on the empty canvas > New > Compressed (zipped) folder
  3. Name the file MOBIServer (Windows should automatically handle the file extension so the full name should be
  4. This will create an empty zip file that WDeploy can use to create a placeholder directory within Apache.

After this step is complete, we can run the deployonly action which will deploy our web applications without building them again. From the command line, run the following commands:

cd E:Program Files (x86)SAP BusinessObjectsSAP BusinessObjects Enterprise XI 4.0wdeploy

wdeploy tomcat7 -Das_mode=split -Dws_type=apache -Dwork_dir=e:temp deployonlyall

Once completed, the output should look something like this:

At this point, we want to confirm that the files were correctly deployed to Apache and Tomcat. Start by opening the htdocs directory within Apache24 and look for the following folder structure:

Next, navigate to the Tomcat webapps directory (in my case, E:Program Files (x86)SAP BusinessObjectstomcatwebapps) and verify the folder structure looks something like this:

Now we can perform the post-configuration steps necessary to ensure our split deployment is working as expected.

Configuration of httpd.conf and httpd-bi41.conf

It is time to configure the Apache web server to accelerate static content and provide the best overall BI user experience. These topics are covered in the Configuration chapter on Page 17 of Improving the User Experience in SAP BI Platform 4.0 with Apache and WDeployso I will only cover the areas that are different here. The document describes creation of a file called httpd-bi40.conf but since we are now using BI 4.1, we will call the resultant file httpd-bi41.conf.

Sap Tomcat 8

Once you have loaded the appropriate modules and enabled the AJP connector in Tomcat's server.xml there are 3 changes from Apache 2.2 that must be implemented. They deal with mod_deflate which handles HTTP compression, mod_cache which provides a disk based caching mechanism for static content, and mod_headers, which let's us set fine-grained cache control headers on static content.

Update the httpd-bi41.conf file as follows:

The difference from Apache 2.2 is that we no longer compress by MIME type, but rather enable compression globally and disable based on specific file extensions. Therefore, this section sets the output filter to DEFLATE which represents compressed content, and disables it for images which are already compressed.

The other change is a small one, but if you don't make it your Apache server won't start. Apache has changed the naming syntax of mod_cache to be consistent in convention. Therefore, mod_disk_cache has been renamed to mod_cache_disk.

Sap Tomcat Login

Update httpd-bi41.conf as follows:

Then, update the mod_cache section as follows:

Make sure the paths are correct for your environment. In mine, the cacheroot directory is at the root of the E drive. Save and exit the httpd-bi41.conf file.

Now update mod_headers:

This change was determined to ensure the Webi Java Report Panel can still be deployed to client devices. Recent versions of Java, above 1.7 u45 showed the missing Last-Modified timestamp causing problems with certificate revocation checks.

Next, navigate to E:Apache24conf and open the httpd.conf file in a text editor such as Notepad. Navigate to the bottom of this file and add the text:

Include conf/extra/httpd-bi41.conf

Immediately preceding the entries added by WDeploy. The resultant file should look something like this:

Save and exit the httpd.conf. The environment is now ready to test, so restart Apache and Tomcat and ensure your BI servers are running and available. If either Apache or Tomcat fail to start, check the syntax of your configuration files, and leverage the Troubleshooting section on Page 29 of Improving the User Experience in SAP BI Platform 4.0 with Apache and WDeploy. You should now be able to access the BI Launch Pad logon page at http://localhost/BOE/BI.

Deploying both static content and fully formed war files on Tomcat for supportability

Although your environment will now be functional, the war files deployed to Tomcat no longer contain static content. This means that you will no longer be able to interact with the BI applications on port 8080. End users shouldn't be accessing Tomcat directly anyway, since that undermines the value proposition of the split deploy scenario, but it can be helpful for administrators in case of troubleshooting. A couple of examples might be:

  • A user receives a 404 error when accessing the BI Launch Pad through Apache. There have been cases where SAP misses one or more JkMount commands from our predefined configuration files, and in order to troubleshoot, you may want to bypass Apache and see if the problem is resolved. Once you confirm the file exists on Tomcat, it is simple to add an additional JkMount command and resolve the problem.
  • Users experience occasional timeouts when performing certain actions (long-running interactive reports for example). It can be helpful to run the report against Tomcat directly and determine if the timeout is related to Apache/mod_jk or not.

To enable this scenario, it is desirable to deploy fully formed war files to Tomcat, as well as static content to Apache. At the cost of a few GB of disk space, you ensure that administrators can properly troubleshoot the environment. We will run the WDeploy process again, but this time specify a simpler set of command line parameters. You are welcome to use the command line version of WDeploy, or the GUI for ease of use. Make sure you stop Tomcat before running WDeploy. The command line syntax is as follows:

  1. Start > Run > cmd
  2. Change to the WDeploy directory (in my case that is E:Program Files (x86)SAP BusinessObjectsSAP BusinessObjects Enterprise XI 4.0wdeploy)
  3. wdeploy tomcat7 deployall
  4. Once the command completes the fully formed war files will have been deployed to your Tomcat server and the output should look something like this:

Tomcat Sap Bo

Now that WDeploy has completed, you would expect to restart Tomcat and be able to access BI Launch Pad again. However, due to an architectural nuance introduced in BI 4.0 this is not the case. Below I will demonstrate the change and explain how to address it.

In BI 4.0 SAP changed the BOE web applications to an Eclipse based framework that allows us to make certain changes without restarting the application server. Part of this new framework introduced a date/time stamp component on the directory containing the web applications. For Tomcat, this date/time stamp component has no effect on URL requests, and any value should still find its way to the BOE web application (this is handled internally by Tomcat).

With Apache, however, we create a physical folder structure containing the date/time stamp in the htdocs directory. This means that when we ran the previous step, the timestamp on the folder changed within Tomcat, but remained the same in Apache, and now the two are out of synch. We can see an example of this by using an HTTP proxy like Fiddler:

Note the 404 errors for static content, such as utils.js. The date/time stamp that Tomcat is directing Apache to look for is:


Which represents December 18, 2013 at 10:30 am.

You can also find this information in the access.log for Apache that is located in E:Apache24logsaccess.log as below:

If I browse to E:Apache24htdocsBOEportal I see a folder called 1312161455 (or December 16, 2013 at 2:55 pm) as below:

Therefore, the solution is to rename this folder, and any other ones that use the same date/time stamp configuration, to match what Tomcat expects. To do this:

  1. Stop Apache from the CCM
  2. Rename the folder in E:Apache24htdocsBOEportal to match the value returned by Fiddler or found in the Apache access.log
  3. Make the same change to the folders in E:Apache24htdocsBOEOpenDocument and E:Apache24htdocsBOECMC

    Since the BOE web application is the only one that uses this naming convention the remaining htdocs folders do not need to be modified.
  4. The resultant folder structure should now look something like this:
  5. Restart Apache

Now if we access the BI Launch Pad we can see that the static files are appropriately found within the Apache server:

The environment is now configured with BI Platform 4.1 SP2 and Apache 2.4.

Sap Tomcat Login