SAP BusinessObjects BI 4 is (Mostly) 64-bit

There’s still some 32-bit code lurking in the BI 4 platform.

One of the marquee features of SAP BusinessObjects BI 4.0 and BI 4.1 is that is 64-bit. But is important to note that it is mostly 64-bit- not fully 64-bit. Certain portions of server code are still 32-bit, which is why SAP by default installs the software in the 32-bit program files directory C:Program Files (x86) instead of the 64-bit program files directory C:Program Files (and you should, too).

From section 10.14 (page 428) of the SAP BusinessObjects Business Intelligence 4.1 Administrators Guide.

BI platform servers are a combination of 32-bit and 64-bit processes. Some servers additionally launch 32-bit and 64-bit child processes. To use the correct version of third-party libraries (32-bit vs 64-bit) with BI platform processes, you must set separate environment variables for each version on the machine hosting BI platform. You must then set an additional environment variable that contains a comma-separated list of those environment variables that have 32-bit and 64-bit versions. When a process is launched by BI platform, it will select the appropriate variable depending on whether the process is 32-bit or 64-bit.

I wished that the documentation spelled out all the 32-bit scenarios explicitly instead of just saying “Some servers”. So here’s my attempt at filling in some of the 32-bit details.

Classic Crystal Reports 20xx

Crystal Reports on the BI 4 platform comes in two varieties. First, there is Crystal Reports for Enterprise, which is an Eclipse-based design tool for creating Crystal Reports. Although the designer is 32-bit, the server processes that support it are 64-bit. Second, there is “classic” Crystal Reports 2011 for BI 4.0 (and now Crystal Reports 2013 for BI 4.1 and Crystal Reports 2016 for BI 4.2). These versions are the successor of Crystal Reports 2008 that paired with the SAP BusinessObjects Enterprise XI 3.1 platform. Both the client tool and the server process are 32-bit. If you have legacy Crystal Reports, you’ll either want to migrate them to Crystal Reports for Enterprise or be sure to install 32-bit database middleware to support them.

Practically speaking, this means that you will need to install both 32-bit and 64-bit database drivers for data sources that power classic Crystal Reports. For SQL Server/ODBC, create 32-bit DSN’s that are identical to the 64-bit DSN’s. For Oracle, install both the 32-bit and 64-bit drivers, being sure to copy an identical tnsnames.ora to each. Oracle users will want to take a look at my related article, Installing Two Oracle Clients on One Server.

SAP BW via Classic UNV Universes

Another scenario where 32-bit code is used is when Web Intelligence reports use the classic UNV semantic layer to access SAP BW. In previous versions of the SAP BI platform, these requests were handled by the then-32-bit Web Intelligence Processing Server. However, a different workflow in BI 4.0 routes these requests through the 32-bit ConnectionServer32 server process. Because the connection server is 32-bit, it can only handle about 1.8 GB of RAM before things go pear-shaped. The scenario is described in SAP KB 1756239Classic universes that use a BAPI connection to SAP BW use the 32-bit Connection Server on BI 4.0 for Windows. As with legacy Crystal Reports, SAP recommends moving these Web Intelligence reports to a UNX universe on BW or a direct BICS connection. SAP BI 4.1 SP1 adds an additional wrinkle, as it includes a 64-bit SAP BW driver. However, it only gets installed with a BI 4.1 full installation. If you’re upgrading an existing BI 4.0 installation, you’ll want to do a “change” installation from the Windows Control Panel and add the SAPBW64 driver. SAP KB 1930558, How to utilize the 64-bit SAP BAPI driver with UNV universes in BI 4.x (Windows), has mostly correct instructions on how to do this. Take a moment to review the list as you may also want to add the new 64-bit Data Direct ODBC, Hadoop HIVE or OData drivers. Or go crazy and add the dBase driver, too.

Microsoft Access

I’ll mention Microsoft Access for sake of completeness. And because prior to BI 4.0 Feature Pack 3 it was impossible to get eFashion working. See my original eFashion on BI 4.0 rant, Converting eFashion from UNV to UNX, and Raphael Branger’s much more helpful article, BO 4.0 FP3: get eFashion and other Microsoft Access data sources working.

Hopefully this covers the key 32-bit exceptions of the mostly 64-bit SAP BI 4 platform. Let me know if I’ve missed any.

Create Popular Windows Desktop Shortcuts for All Users

Create public shortcuts to make everyone’s life easier.

When installing software on Microsoft Windows server operating systems like Microsoft Windows Server 2008, I like to create a small number of frequently used programs and folders such as the ODBC DSN panels (see related article, More Fun with 64-bit Windows and ODBC) as desktop shortcuts.  By default, these shortcuts are placed on my personal desktop, stored in a folder like C:Users\<username>\Desktop. But you can share these desktop shortcuts with your fellow administrators by using Windows Explorer to copy the shortcuts from your personal desktop to the public desktop, which is located at C:\Users\Public\Desktop. The public desktop is a hidden folder, so you’ll want to show hidden folders in your Windows Explorer.  Choose Organize from the Windows Explorer menu, then Folder and search options. Choose “Show hidden files, folders, and drives” from the “Hidden files and folders” option on the View tab, as shown below.

Microsoft Windows Show Hidden Files Folders and Drives

Don’t go overboard with too many shortcuts and annoy your coworkers, but here are some suggestions:

  • 32-bit ODBC DSN Panel
  • 64-bit ODBC DSN Panel
  • Tomcat Configuration
  • SAP BusinessObjects Central Configuration Manager (CCM)
  • SAP BusinessObjects BI Launchpad
  • SAP BusinessObjects Central Management Console
  • SAP BusinessObjects File Repository Server folders, if on remote server

What kinds of Microsoft Windows tricks do you use to make administering SAP BusinessObjects easier?

The Fun Never Ends with 64-bit Windows and ODBC

Still making fun of the Microsoft Windows ODBC panel.

The new Information Design Tool (IDT) in SAP BusinessObjects Business Intelligence 4.0, like the other client tools in the suite, is a 32-bit application. Even if the IDT is installed on a 64-bit version of Microsoft Windows, it wants to use 32-bit ODBC DSN’s created with the 32-bit ODBC panel, not 64-bit DSN’s. If you attempt to create a new universe connection and specify a 64-bit DSN name, the following error appears.

[Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application

To resolve the issue, make sure you’re using the 32-bit ODBC panel (see related article) at C:WindowsSysWoW64Odbcad32.exe. If you are running the client tools and server on the same platform, create a 32-bit ODBC DSN for the Information Design Tool and a 64-bit ODBC DSN for the server (BI Launchpad, Web Intelligence Processing Server, etc.). Make sure both DSN’s have identical names.

Remember that Crystal Reports 2011, Crystal Reports 2013, and Crystal Reports for Enterprise clients are also 32-bit. If they are installed on the BI4 server (which is supported, but oddly enough not recommended), they will also require 32-bit ODBC connections even though the Crystal Reports Processing Server requires 64-bit ODBC connections. Note that the legacy Crystal Reports 2011/2013 Processing Server will also require 32-bit ODBC connections.

Having fun with 64-bit Windows and ODBC?  You may find my other articles on ODBC helpful.

Still Having Fun with 64-bit Windows and ODBC

Copying ODBC DSN’s from XI 3.1 to BI4 need not be a tedious chore.

I’m still having fun with 64-bit Windows and ODBC. This time, I’m working with SAP BusinessObjects Business Intelligence 4.0 SP2 Patch 10 (BI4) instead of my previous exploits with SAP BusinessObjects Enterprise XI 3.1 (see related article, More Fun with 64-bit Windows and ODBC). My challenge was to easily copy ODBC DSN’s from a customer’s existing XI 3.1 environment to their new BI4 environment without hours of tedious typing in the Windows control panel.

The procedure is simple enough, as ODBC DSN’s are stored in the Microsoft Windows registry. Simply use the registry editor on the source machine to export the HKEY_LOCAL_MACHINE\SOFTWARE\ODBC tree. Move the generated registry file to the destination machine and load using the registry editor. But when moving between 32-bit Windows and 64-bit Windows, there’s a small catch.

In 64-bit Windows, HKEY_LOCAL_MACHINE\SOFTWARE\ODBC is where the 64-bit DSN’s are stored. 32-bit DSN’s are stored in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC.  This means that the 32-bit DSN’s that you import from the 32-bit XI 3.1  server automatically become 64-bit DSN’s on the BI4 server by virtue of their registry location.

SAP BusinessObjects BI4 is primarily 64-bit, so most services like the Web Intelligence Processing Server will be looking for 64-bit DSN’s. However, classic Crystal Reports 2011/2013/2016 are 32-bit (even on the BI4 server), so it will look for DSN’s in the second Wow6432Node. I ended up creating these 32-bit DSN’s manually using the ODBC panel on our BI4 staging server (see related article, SAP BusinessObjects BI4 is (Mostly) 64-bit).

However, once I have both 32-bit and 64-bit DSN’s created on the staging server, I can move them easily to other 64-bit Windows machines.  I just have to remember to export both the HKEY_LOCAL_MACHINE\SOFTWARE\ODBC and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC keys.

TIP: Remember that each set of DSN’s has its own control panel.  To avoid going insane during testing, take a moment to create separate desktop shortcuts to the 32-bit and 64-bit ODBC DSN panels on your 64-bit Windows server (see related article, More Fun with 64-bit Windows and ODBC).

Related Articles

For more information, check out this related thread on the BusinessObjects Board (BOB).

More Fun with 64-bit Windows and ODBC

All I can say is “SysWoW64! That’s really intuitive, Mr. Ballmer!”

This week, I helped a customer install SAP BusinessObjects XI 3.1 SP3 on Microsoft Windows Server 2008 64-bit using Microsoft SQL Server 2005 for the system (CMS) and audit databases.  And once again, I was tricked by Microsoft’s ODBC Data Sources panel into creating 64-bit ODBC connections that were rejected by the XI 3.1 installation program.  XI 3.1 is fully supported on 64-bit operating systems, but it’s still a 32-bit application that requires 32-bit database connectivity.  The whole experience felt like deja vu, and sure enough, I blogged about this topic over two years ago when it burned me the first time.  So let’s review (from Microsoft Support article 942976):

The 64-bit version of the Odbcad32.exe file is located in the C:WindowsSystem32 folder.  This 64-bit version appears on the Windows Start menu.

The 32-bit version of the Odbcad32.exe file is located in the C:WindowsSysWoW64 folder.  This version does not appear on the Windows Start menu.

Got that?  64-bit code is stored in a folder named “System32” and 32-bit code is stored in a folder named “SysWoW64”.  And both ODBC panels are identical in appearance – there’s no real clue to which one you’re using.  All I can say is “SysWoW64! That’s really intuitive, Mr. Ballmer!”

During the XI 3.1 installation, the dialog box for establishing the BusinessObjects system and audit databases for Microsoft SQL Server will have the “Consume DSN created under WOW64” box checked by default.  You should see your 32-bit DSNs on the list of available DSN’s.  If your DSNs refuse to apper until you uncheck the “Consume DSN created under WOW64” box, that’s your clue that you goofed up and created 64-bit DSNs.  Attempting to proceed further will cause the installation program to generate a humiliating STW00225 (Audit connection) and/or STW00226 (system/CMS connection) error message.

SAP tries to warn us with the following note in the supported platforms document:

BusinessObjects products use the 32-bit ODBC registry on all versions of Windows. To administer 32-bit ODBC DSNs on 64-bit versions of Windows, run the 32-bit ODBC Administrator, located here: C:WindowsSysWOW64odbcad32.exe

Thankfully, the upcoming release of SAP BusinessObjects Business Intelligence 4.0 is fully 64-bit, allowing the use of 64-bit DSN’s to Microsoft SQL Server.  So it won’t be long before we can all put this ODBC controversy behind us. Well, all of us except for Mr. Ballmer.

UPDATE: Although the SAP BusinessObjects Business Intelligence 4.0 platform is 64-bit, it is not fully 64-bit (see related article, SAP BusinessObjects BI 4 is (Mostly) 64-bit).  In particular, Crystal Reports 2011 still requires 32-bit database connectivity (see related article, Still Having Fun with 64-bit Windows and ODBC).

Best Practices for SAP BusinessObjects and ODBC

To minimize some of the confusion, create clearly labeled desktop shortcuts to the 32-bit ODBC panel (C:WindowsSysWoW64 folder) and the 64-bit ODBC panel  (C:WindowsSystem32 folder) before even attempting your SAP BusinessObjects installation.  Then create your DSNs via the appropriate shortcut (32-bit for XI 3.1 and lower, 64-bit for BI 4.0 and higher).  On Microsoft Windows 2008 Server, I move these shortcuts to the hidden folder C:UsersPublicDesktop so the rest of the administrative team can use them.

I used to recommend adding _32 as a suffix to your DSN names to remind everyone that they are 32-bit connections.  But then SAP BusinessObjects Business Intelligence 4.0 arrived. Crystal Reports 2011 is still 32-bit on the server, so I now prefer that the 32-bit DSN and 64-bit DSN share the same name.

Thank you, Mr. Ballmer.

Fun with 64-bit Windows and ODBC

Running 32-bit SAP BusinessObjects on 64-bit Windows OS

My current client is running Business Objects Enterprise XI 3.0 on Microsoft Windows 2003 R2 Standard 64-bit edition. This project is my first experience with a 64-bit Windows product.

Part of the project involves migrating Crystal Reports from Crystal Enterprise 10 to Business Objects Enterprise XI 3.0. Many of these reports use DataDirect ODBC drivers to the client’s Baan system. Business Objects provides free but limited versions of the DataDirect 5.3 drivers for Crystal Reports 2008, which we have installed on the Business Objects Enterprise server.

Windows 2003 Server 64-bit edition has two different ODBC data source administrators. The standard administrator via the Windows control panel only displays 64-bit system DSNs. This is not immediately obvious. Thankfully, somebody smarter than me pointed out that 32-bit system DSNs are accessed via a different version of the ODBC data source administrator.

The 32-bit version of the Odbcad32.exe file is located in the %systemdrive%WindowsSysWoW64 folder.
The 64-bit version of the Odbcad32.exe file is located in the %systemdrive%WindowsSystem32 folder.

I’m not aware of a standard shortcut to the 32-bit panel from the Windows Start menu, but of course you can easily create your own. For more information about this topic, read the Microsoft support knowledge base, article 942976.