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.

Enjoyed this post? Share it!


2 thoughts on “Migrating Business Objects Enterprise from Windows to Linux

  1. I agree that migrating BOE from windows to Linux should not taken lightly, and in general I would only recommend installing BOE on linux if the organization is comfortable with linux. However, at least at this point in time, when it comes to data services (data integrator), the only way to benefit from large amounts of memory on the machine is installing it on Linux. So at least for this BOE related product I would recommend linux as the first choice. Thanks – Ron

  2. As a former BO product developer I can say with authority that all BOBJ server code is written with MS Visual Studio C++ and Windows Standard Template Libaries. Once code was finished it used to be (pre-2006 when I left the company) sent offshore to be converted for use on UNIX platforms for the 5% of the user base (at that time) that insisted on using some flavour of UNIX/Linux; it was done only because there was enough money involved to make it worhwhile for the company. The most unstable BOBJ deployments I have witnessed are all on some flavour of UNIX/Linux.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.