Migrating Business Objects Enterprise from Windows to Linux

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.