We’ve already made some awesome progress on our CentOS 5.4 environment running SAP Business Objects XI 3.1. First, we constructed an environment and laid down the base install, and immediately followed that up by learning how to control services via the command line as well as pointing our CMS to use a new Oracle database. This post is going to dabble briefly in architecture strategy, then jumping head first into the technical stuff again.
If you are reading this, you are probably on the admin/architecture side of your BI team. If you aren’t already thinking it, you should be hating the fact right now that in our little test, the web tier lives on the same server as BOBJ. Using the magic of VMware, we are totally going to fix that so we have a distributed architecture for our test.
First, you have to make a big decision.
- Build a new CentOS 5.4 VM to do a clean install from.
- Duplicate the current VM, delete BOBJ, rename the server, and give it a new IP.
I actually opted for the latter. You decide, based on your experience with Linux in general, which you want to take on. This saved a few hours of my time really. I’ll also add (in a not-bragging-way) that I put this duplicate VM on another dual quad core Mac Pro I have so I could spread the resources a little more evenly.
If you chose to build a new VM, refer to the first post in this series on setting up the base environment and all dependencies to get started.
Fast forward….
You now have another machine ready to deploy a web tier on. All things being equal from the BOBJ server, run the install.sh script again.
Installing the Web Tier
Again, we won’t capture the details in each step, but will focus on the important ones.
- Choose language
- Accept license agreement
- Enter license key (I double checked this…any key DOES work)
- Enter path for install
- Select language(s)
- Do a system install
- Now it is time to mix it up! Do a Web Tier installation (3) at this step…
BusinessObjects Enterprise XI 3.1 Setup
Installation Type
1 – New (Install a new Enterprise system)
2 – Custom or Expand (Select which components you wish to install)
3 – Install Web Tier features
[X] – Enable servers after installation
- Not a lot of variety here. The default selection will be checked for you.
BusinessObjects Enterprise XI 3.1 Setup
Features
-[X]BusinessObjects Enterprise
+[X]Web Tier Components
- Now, point back to that other VM that is running our CMS cluster. I feel it is important to note that if you don’t have a properly configured DNS server on your domain and are using it from your CentOS box, you will need to edit your /etc/hosts file with the IP and hostname of your BOE XI server. ALSO, be sure to consult the firewall configuration portion of the XI admin guides to properly open the right ports on the firewall of the actual BOE server to let the incoming traffic come in from the web tier. I simplified and shut off the firewall on the BOE server to move this post along.
BusinessObjects Enterprise XI 3.1 Setup
You have chosen not to install a CMS. Please enter the name and port number of another CMS to use
CMS Hostname :
[evtech3 ] *
Port :
[6400 ] Defaults to 6400
Existing CMS Administrator Password :
[********* ] Defaults to blank password
* Required field
Potential Error Handling
Error logging onto CMS with credentials supplied. (STU00013)
This error actually wasn’t particularly helpful. I found it happens on invalid firewall definitions as well. Just know that it occurs regardless of what is happening when it tries to connect to the BOE server.
Continuing the Install
With the installer successfully communicating with the CMS on the specified port, the installer can continue.
- Use the default install if you wish on Tomcat (1).
- Specify the Tomcat port numbers for your deployment if non-standard.
- Confirm the install path.
- Commit the installer.
- At the very end, don’t forget to run the setup script as root!
Stopping the Web Tier on the BOE Server
With the install rolling, I don’t particularly need Tomcat to automatically start over on my CMS box. That said, edit the /etc/init.d/BobjEnterprise12
script on your BOE server with your root or sudoer. On my copy, around line 52, there is a portion of the script for Tomcat in an if statement. It reads like so:
if [ -d “$BOBJEDIR”/tomcat ]; then
$SU – “$BOBJEUSERNAME” -c “$BOBJEDIR”/tomcatstartup.sh
logger -p daemon.info -t bobj “Started Tomcat”
fi
Comment this out with # marks. Do it again at line 85 for the stop portion.
if [ -d “$BOBJEDIR”/tomcat ]; then
$SU – “$BOBJEUSERNAME” -c “$BOBJEDIR”/tomcatshutdown.sh
logger -p daemon.info -t bobj “Stopped Tomcat”
fi
So now I have separated my app tier from my web tier, but still have web tier components handy on my app tier box for troubleshooting/debugging if needed. I actually consider this a best practice and a great way to identify problems in my architecture.
Configuring Apache Tomcat
Tomcat is Tomcat. The difference here from Windows is the lack of the Tomcat configuration tool. However, you can still tweak the Tomcat config settings as needed with handy dandy vi. If you browse the file system, in the /app/bobj/bobje/setup
folder there is a file named env.sh. This is what sets all the environment variables for Tomcat to run. A few things before we wrap up:
- Heap: down around line 106 note the initial and max JVM sizes.
- Options: a few lines above that, there is a
JAVA_OPTS
variable with a long string in quotes. You’ll modify this just like you would have in Windows for AD authentication, for example.
Conclusion
I was trying to come up with something catchy here. It’s late. Not sure where I’m going next here…perhaps LDAP authentication. Until next time…
Read the rest of the SAP BusinessObjects Enterprise XI 3.1 on Linux series.