Java App Server and CMS On Different Machines, Edit “hosts” File Now
If you have deployed your Business Objects XI Central Management Server(s) and your Java Web Application Servers are on the same single machine then this article does not apply to you. If your Java Web Application Server ever needs to run applications (such as InfoView or CMC) that will connect to any CMS that is not running on the Java Web Application Server’s machine then you and your system will benefit from reading this article.
The Java Implementation of DNS Look-up
I’ve been told by a few very knowledgeable folks that either Java as a technology or Business Objects Enterprise’s use of Java results in a situation where if the CMS is not hosted on the same machine as the the Java Application Server then the look-up of the IP address of the CMS machine(s) is very inefficient and is the cause of much lag in the case of such actions as logging in. For example, an InfoView log in action may take up to 10 seconds extra due to iterative inefficient resolution of the CMS machine’s IP address from the host name.
Building a Short-Cut
One way to put an end to this inefficiency is to place hard coded entries in the hosts file of the machine hosting the Java Application Server. If your server is configured to first check the hosts file before hitting the network’s DNS server then you will see a huge boost in the performance of log in actions. This is simply due to the fact that the poor implementation of DNS look-up that BO’s Java call is doing is bypassed by the hosts file entry for that host name. I have seen log in actions for InfoView and CMC reduced from 8 seconds to less than 1 second by this change alone.
Making the Change
This is one of those changes that won’t cost you much to test, but there is a price. The truth is that there is a very big issue with hard-coding a server name and IP address in your hosts file. On the very rare occasion that your server is assigned a different IP address your application will be broken until you update the hosts file accordingly.
To make the change you need only locate the machine’s hosts file. On Windows this is usually in “\WINDOWS\system32\drivers\etc” and on Linux it will be in the “/etc/” directory. Once you locate the file I suggest creating a backup of it first. New lines are added to the file merely by adding first the IP address, then at least one space, then the fully-qualified domain name, and optionally you can add at least one more space and put in the simple short name of the machine. For example:
12.232.131.121 myserver.mydomain.com myserver
I am not an expert on editing hosts files, but I can tell you that it is worth trying out on your system in you are running at least one CMS on a machine different from the one that is running your Java Web Application Server. Give it a try and report your results by leaving a comment please. To the best of my knowledge you don't even need to restart your deployment for the change to take effect. Just make the change and test the results. Good luck.
BO XI Distributed Environment: The Standalone Java Application Server
When you are building a small sandbox it is great to put everything all in one place and create a Business Objects solution that is a one-stop shop (a.k.a. putting all of your eggs in one basket). This works for lots of small-to-medium sized BO systems, but sometimes you want to do a little more. Sometimes you want some fault-tolerance, high-availability, and/or fault-tolerance. In any of these cases you might decide to build something really cool: a distributed Business Objects Enterprise XI 3.X Environment.
In this article, I would like to talk about putting your Java Web Application Server on a separate dedicated machine. You could chose Apache Tomcat, or your could get a little more crazy and go with Oracle’s WebLogic. Either way, the principles are the same.
Does BO Support Mixed Mode?
Perhaps your BO CMS, job, and reporting servers are all running on Windows machines. Perhaps you are thinking that you would like to run your Java applications on a Linux server. No problem. Business Objects has documented that it is acceptable to mix different Operating Systems in your BO environment as long as all servers running a particular component are of the same Operating System. What does this mean? It means that you would be running in a unsupported mode if you ran one CMS in your cluster on Windows and another CMS in the cluster on Linux. But if you put all of your web applications on Linux you should have no problems getting support and you should not expect any unusual issues. In fact, in my opinion, if your web application servers are not clustered, you could get away with running Apache on one Windows server and WebLogic on a Linux server, since they do not communicate with each other.
How Do I Create a Dedicated BO Web Application Server?
The hardest part is setting up your Java Web Application Server. I won’t help you here, but there is plenty of help out there in the great Internet to guide you in configuring Tomcat or even setting up WebLogic. Once this is setup all that you have to do is copy the WAR files over to the server (or you can even upload them from your client machine using the WebLogic Administration Console). Yes, this is all you have to do for Business Objects XI 3.0 and later.
Don’t I Need to Install BO on the Server?
No, do not believe the documentation. You do not need to install BO on the server as long as you can generate the WAR files from some other server. It is true! The documentation would have you believe that regardless you need to copy over at least the “deployment” folder and a “java” folder, but this is not true. These are ONLY needed if you are needing to run “wdeploy” on the Java Web Application Server. In my case, I can always use a CMS machine to generate my WebLogic and Tomcat WAR files so why would I want to put BO software on another server? If I put some of the BO binaries on my Java Web Application Server then I have to worry about maintaining/patching the software on that server as well. I don’t know about you, but I don’t need more work and more things to forget to do.
Where Do I Get the WAR Files From?
As I said, go look at the CMS machine. Follow the documentation* to help you find the “wdeploy” application (it is a command-line driven application, probably found here > wdeploy weblogic10 predeployall“. You do not need to configure any “config.*” files for your Java Application Server as these are ignored when running with the option “predeployall”. After you run the command successfully, take about 4 to 7 minutes, then you will be told where your WAR files will be located, for example:
What About XI R2, Do I Need to Put BO on the Web App Server?
All java deployments/application except for the “webcompadapter” are standalone applications that require nothing more than a supported JVM to be installed on the Java Web Application Server. The only application that uses the “webcompadapter” is CMC, so if you are intending to provide CMC access through some other method (such as a small unadvertised Tomcat instance installed on a CMS server) then you do not need to install any Business Objects binaries or libraries on the Java Web Application Server. The issue here is that the XIR2 still has some JNI calls in CMC, it was not fully converted from COM to Java and so the “Web Component Adapter” is required by the CMC and it requires that certain binaries of Business Objects Enterprise XI R2 be installed on the server.
————-
* Recommended published BO documentation is the “BusinessObjects Enterprise XI 3.1 SP2 Web Application Deployment Guide” or if not running Service Pack 2 then use the “Web Application Deployment Guide” for your OS (hint: Unix applies to both Unix and Linux). Of course, the file names will look more like the following: xi3-1_deployconfig_unix_en.pdf or plugin-xi31_sp2_webappd_unix_en.pdf (for example)
Note: I have not played enough with IIS and .NET to know much about deploying the different application there. I am sure the process is quite different, so I would not try to use this article as a guideline for any .NET BO web applications.
Web Intelligence Hangs, Allocate More Memory to Java
Myth: Business Objects XI Web Intelligence Requires No Software Install
Business Objects IX’s Web Intelligence is a light client. You may think that it does not require you to install anything on your PC, but then you would be wrong. Firstly, obviously WebI requires that your PC have a browser. Secondly, Web Intelligence Java Report Panel requires that your client PC has a Java Runtime Environment (JRE) installation (1.5 and 1.6 are good to go).
Third, your client will need to download the WebI Java Report Panel application (in the form of temporary Internet files stored usually in your JRE installation folder). If you ever dump these (for example, as discussed in the article “Clearing the Browser and Java Cache: Do This First!“) then you will notice that your subsequent visit to the Java Report Panel (create new or modify a document) will result in a longer load time while your web client downloads the BO WebI java application.
Java Runtime Environment Installs with a Wimpy Configuration
By default I believe that the default Sun JRE’s will almost always install themselves with a very conservative (small) heap/memory consumption size. These settings can be managed on your client PC by going to “Control Panel” and double-clicking on “Java”. Once there click on the “Java” tab and then click on the “View…” button:
Java Control Panel Parameters
In here, you may have multiple JRE version installed as I do. I think you can figure out which one is being used by your WebI Java Report Panel by clicking on the toolbar icon when you are running the WebI JRP. Otherwise, you will have to disable some and see what happens, process of elimination. When you find the correct one you will see the memory configurations in the “Runtime Parameters” column.
Web Intelligence Power User? Put Your Memory Where Your Mouth Is
Once you know which one to tweak and you focus on the “Runtime Parameters” you will see that there is an “Xms” and an “Xmx” parameter here. “Xms” is the minimum starting size of the heap or memory allocated to the process. “Xmx” is the maximum or limit of the heap/memory allocation. A good starting point here is: -Xms128m -Xmx256m, but you can go higher if you feel you and your PC are up for it. This link points to a great article on the topic of mistakes to avoid when configuring these parameters. Most importantly, always include “m” or “g” at the end of the number, never exceed your machines physical memory, and I read some where else that the effective limit here is 1 gigabyte on Windows XP/Vista (-Xms1g -Xmx1g). Sun has a good guide on this topic too(link).
Making the Change
I would first back-up your current settings, email them to yourself or something like that. Make the change and follow the syntax. Change the setting(s), then click “OK”, then click “Apply” then click “View” to confirm your changes were saved. If you do not click “Apply” and you click “View” right after clicking OK your changes will be wiped out. Of course, you should probably not be using your JRE while making these changes, or at least close everything down and restart your WebI Java Report Panel after the changes are made. I don’t think rebooting your PC is necessary. Be sure to test your changes by launching Web Intelligence Java Report Panel and keep your eye on your system’s memory to see the impact there while testing your wonderful WebI skills to test the potential improvements you just made.
Why Would I Do This?
I have seen this change both improve performance and stability of the Business Objects XI WebI client machine. Truthfully, many support engineers recommend this change anytime a user reports that WebI is hanging or sluggish. I recommend increasing these settings. Now, I wonder if by increasing them I can reliably run to Java Report Panel sessions at the same time. Hmm… I wonder.
Clearing the Browser and Java Cache: Do This First!
There are certain rules, tried and true practices, that you always try first before you call someone. In IT the first one is restarting an application and the second one is rebooting the computer. After those two, the order becomes debatable. Unfortunately, many of us know folks that call us before even trying one and two.
The Third One
I present to the world of Business Objects and in fact, the world of most web based applications, a third practice that you will always want to try before calling someone (or have your users try before they call you): clearing the browser cache and the java cache.
How do I clear the browser cache?
In Mozilla FireFox follow these instructions:
In the drop-down top menu navigate as follows:
Tools > Options > Privacy (tab) > Clear Now (button)
or just
Tools > Clear Private Data
Make certain that "Cache" and "Authenticated Sessions" are selected, the other options are up to you if you want to include them. You may want to add "Offline Website Data" too.
Clear the Cache for Mozilla FireFox
For Internet Explore follow these instructions:
In the drop-down top menu navigate as follows:
Tools > Internet Options > Delete Files (button)
I usually select to delete off-line content too.
Clear the Cache for Internet Explorer
Sometimes You Need to Dump the Java Cache Too
There are times when the Java Query Panel won’t load or it misbehaves on the client. Instead of wasting time debugging or wishing you had “Full Client” back, just dump the Java Cache. Here is how to do it in my current Java version:
Open the Java Control Panel by looking in your PC's control panel or by double clicking the Java icon in your system tray.
On the "General" tab click the "Settings" button. Click "Delete Files". You could also click the "View" button and then hand pick the BO related applications, resources, or deleted applications that you want to dump. Be aware that the next time you access java web components, such as the java query panel, expect the initiation to take some time.
Clear the Java Cache
Errors that Indicate Issues Resolved by Clearing the Cache
My favorite error is “Internal Error: the value of parameter lang is invalid”. It is perhaps one of the least helpful in a sea of un-descriptive errors. This error is a client-side error and can be quickly resolved with just a clearing of the browser cache in many cases.
Business Objects Enterprise: Java or .NET?
There are a lot of factors that will come into play in deciding how to deploy your Business Objects XI R2 application, that is to say in the decision whether to deploy InfoView in the Java (Apache Tomcat, WebLogic) or .NET (IIS) flavor. There will be many reasons such as available skillsets, technical familiarity, web server restrictions, etc. However, there may be one factor you are not considering… future functionality support!
Another Win for Java
At one point in time Business Objects, the company that is, announced that they would maintain all future released functionality of Business Objects XI in both the .NET and the Java flavor. However, sometime in 2007 it appears that BusinessObjects went back on this commitment. Probably due to the less-than-booming economy BO was faced to make a difficult choice and because of the overwhelming popularity of Java among BO’s customers, the decision was made to focus all of the product roadmap’s enhancements first on Java.
BO’s Stepchild: .NET and IIS
Therefore I suggest you consider this point carefully when making a decision to deploy InfoView on .NET. If you choose to do so you are ignoring the fact that Business Objects is playing favorites. If you select .NET you are selecting the stepchild. Don’t expect enhancements and fixes to be as readily available for your .NET platform as they are and will be for Java. You don’t believe me? Well go ahead and try to install Business Objects XI 3.0 on IIS and .NET. Not going to happen, at least supposedly not until sometime in the second half on 2008. That’s my point and it is just the beginning.
Business Objects XI R2 Java AND .NET?
With Business Objects XI R2 it is possible to actually run both platforms at the same time on IIS and Apache Tomcat, although most BO administrators would probably want to avoid this. However, if you require and SDK interface and you have no Java developers then do you really have a choice? Honestly, many BO administrators are doing this with BOXI R2 and so I would not want to discourage you if you have no other choice.
In the end this is your decision. We just want to be sure that you have this little bit of extra input. We would hate to hear of anyone else having to spend hundreds of person hours moving from the .NET platform to the Java platform because they didn’t know what they were getting in to. Its not that much work to switch you say? The rework can range from SDK rewrites to OpenDocument.aspx updates across every single report that uses OpenDocument. Make your choice wisely, what more can we say?
