The Linux operating system has established itself as an industry standard for enterprise applications. However, not all flavors of Linux are supported for running Business Objects Enterprise systems. Red Hat Enterprise Linux (more or less version 4 and 5 of the server) and SUSE Linux Enterprise Server (version 9 and 10) are supported as of XI 3.1 Service Pack 3. Given the cost of ownership and the robustness of the operating system, more businesses are looking to Linux as viable option when considering upgrading their servers. This article captures some of the concerns that a BOE system administrator might have when considering or planning a migration of their system from a Windows server to a Linux environment.
You Still Need Windows
If you are thinking you could liberate your office of all PCs after a successful Business Objects Linux migration, you are quite mistaken. Your universe development will still require the use of Designer. Any plans to migrate content between environments using Import Wizard will also
SQL Server Connections
When you are running Report Servers and/or Connection Servers on a Windows Server then you can get away with using the veryquick-to-configure OLE DB Microsoft SQL Server connection. These are the simplest connections to configure because they require no configuration on the client. If you are planning to move to Linux get ready for this simplicity to change.
Only ODBC or JDBC connections are supported for Linux servers (depending on version of BO and MS SQL Server database). This means that not only are you going to have to convert all of your OLE DB connections to ODBC/JDBC, but you are also going to have to start configuring any Windows machine that needs to run Designer (or Desktop Intelligence) with an appropriate and name-matching DSN. Yes, running on Linux now makes MS SQL Server connections just as difficult as Oracle connections (or maybe worse).
Unmanaged Disk File Destinations – Scheduling to File Shares
If you are familiar with Linux than you probably already thought of this one. When you are running job servers on Windows users can ad-hoc enter in any UNC File Share path as a destination for their scheduled job. They only need to be sure that the security of the file share is configured to allow the job server to write a file to it.
With Linux things are not so simple. In order for the BO job server to be able to write to a file share the file share needs to be mounted to the Linux server. Therefore, as user would have to communicate their file share first to a system administrator, who then needs to mount the file share and confirm to task completion to the user. After all of this is done the user can proceed to schedule a job to deliver a file to the file share; however, the user will need to know the exact name that was used to mount the file share. Yes, it just got a lot more complicated.
To make matters worse, the system administrator would need to have “root” access to be able to mount the file share. Samba will need to be installed as well on the server. The file share will have to mounted on all machines that are running the job servers int he cluster (unless server groups as used). Also the system administrator will need to make sure that the mount of the file share is persistent, so that it remains even if the server is rebooted.
File Repository Server on a File Share
In most cases production systems store the File Repository System on a separate file server. In Windows you don’t need to configure the machine running the Input/Output FRS servers to be able to connect to the file share. On a Linux server you would have to mount the file share first to the machines running FRS and then you would need to make sure that the mount was always present on the machine. I don’t think it would be a good idea to use a Windows files share here with Samba, perhaps it would not even be supported.
Kiss Your Windowed GUI Good-bye
CCM and all of its little attached tools are all either command-line driven or ASCII-based GUIs. None are too bad or difficult to deal with, but this is a change for sure.
Much Remains Unchanged
While the above discussed changes are unavoidable, it should be noted that most of the functionality of Business Objects XI Enterprise is unchanged when the servers are run on Linux machines. CMC still runs pretty much the same as does InfoView and Web Intelligence. The end user, report/universe developer, or CMC user would really not notice much of a difference in their interfaces.
Origin of a Cluttered FRS
Business Objects XI has a way of making more sub-folders than files. Seriously, take a close look at your Input and Output File Repository Servers, or rather your FRS on the disk. You will notice a crazy number of folders. As objects get deleted in Business Objects XI their corresponding files are removed from the FRS; however, their sub-folder is not. Since there is nearly a 1 to 1 ratio of files to folders this lack of folder clean-up leads to a lot of empty folders and an inefficient FRS (and any resulting file system back-up).
Keeping Your FRS House in Order
Since you see the most efficient system, you want to clean up this folder mess. Well, BO has a tool for that and you already own it. You can invoke it merely by putting the command-line parameter “-prune” on the Input FRS and the Output FRS.
Making -prune Work for You
I recommend that before you start you shut down your BOXI system’s web front-end. This will keep users from receiving errors or possibly impacting the prune activity. Yes, this requires downtime to do it properly and only experience will tell you how long it takes (depends on how much mess needs to be cleaned and how fast your servers are). Now in CCM shutdown your FRS servers.
Do the next steps one at a time unless you are in a rush. Modify the command-line parameters by appending the parameter “-prune”, be sure to include a space between it and the final parameter that was present before you started. Also you can add “-trace” as a switch to capture a log of the actions.
Completing your FRS Prune
Now start the FRS that you just modified and you will observe that it maintains a “starting” status until it finishes. You can watch it through your servers task manager, top, or other corresponding process manager. You could also watch it through the log file it creates with the included “-trace” parameter. When it finishes, remove the parameters you added and proceed to the next one. If both have completed the prune then you are done and as long as you removed the parameters that you added you are ready to roll.
I suggest counting sub-folders and files before and after. This will help you understand the impact of what you just did. Please keep in mind that the “PRUNE” command does not clean-up any dead pointers (objects in the CMS that lost the files the point to). Prune only cuts the dead branches and it doesn’t touch a single leaf or leafy branch. Enjoy the analogy
More FRS Prune Resources
Over at “let’s learn business intelligence” they have a good video walk-through of a real, live FRS prune on a BOXI system. Check it out: http://www.letslearnbi.com/2009/05/business-objects-prune-and-trace.html.
Lately I have been faced with the need to install a FixPack on one of my Business Objects Enterprise XI 3.1 systems. Doing so has reminded me of some key points and tips that I wanted to share with the Business Objects community. FixPacking BO 3.1 is truly a different experience:
Not Your Father’s BO FixPack
Like everything else in life, FixPacks have changed and evolved with the Business Objects product. Some of the notable changes for BO XI 3.1 FixPacks are:
- FixPacks are no longer suite wide. You need the FixPack for the specific Business Objects product you wish to patch (such as Enterprise, Live Office, Crystal Reports 2008, etc.)
- You must first install the patch on a node where a CMS server is located. According to some SAP-BO support engineers the safest choice in a distributed environment is to install the FixPack one node/machine at a time. So if you have multiple CMS nodes, install on those first one at a time, then install on the other servers one at a time. This makes for a VERY lengthy FixPack deployment, but it is the safest method. I have also had several senior support engineers confirm that the only requirement is to patch 1 node hosting a CMS first, then after that patch is completely started you can patch all of the rest, staggering them by 5-10 minutes each.
- Stop all BO servers except for a single CMS, Input/Output File Repository Servers, CMS database, and Server Intelligence Agent (SIA). If a CMS in the cluster is not up and running the install will not work properly or at all (this is true for all servers, regardless of their role). The SI Agent must also remain up on all nodes to be patched.
- Czech and Finnish Language Packs are now available (as of FP 1.3/1.4)
FixPack Installer Beware
Here are a few cautions/warnings that stand out to me:
- EVERY Business Objects component must be on the same version. If you patch a dedicated CMS server, you must also patch any other nodes that are a part of your cluster, such as processing servers or Live Office servers, etc. Also any clients, Designer and DeskI need to be patched as well. Another reason to use WebI exclusively, no client patches needed (unless we are talking about WebI Rich Client).
- Don’t forget to redeploy the patched BusinessObjects web components. The deployment method will vary based on your original web component deployment.
- Temp Directory: When working with the Windows Installer Package, be sure to either manually extract the installation files to a desired location, or to change your user’s “TEMP” environment variable to the true location to which you want these very large and many files extracted. Actually, on second thought, ALWAYS change your “TEMP” path environment variable to a location with enough space (a few GB); I have seen the installer, in the midst of installing fill up my C: drive with temporary files that it works with after all of the unpacking and hours into the patch installation. Be careful here, plan ahead.
These are just a few of my notes and pointers for now on the top of my head. I will update this article later with my more complete notes or with any of your suggestions offered through the comments below.