SAP BusinessObjects Explorer – What IT Needs to Know

Just like a political talk show on cable, the truth about SAP BusinessObjects Explorer is somewhere in the middle.

I’ve been busy talking about SAP BusinessObjects Explorer and helping customers deploy it.  I’m really excited about next month’s release of SAP BusinessObjects Explorer 4.0 as part of the BI 4.0 suite, but there’s lots of reasons to start using the current release, SAP BusinessObjects Explorer XI 3.2.  Explorer is a unique business intelligence application aimed at the casual business user.  People generally have two reactions to it.  The first is that it’s a silver bullet that will magically solve all of their organization’s information delivery challenges.  The second reaction generally comes shortly after the second.  “Oh, it’s just a toy” or  “Our users would never use that”.

Both of these reactions are the extremes.  Just like a political talk show on cable, the truth is somewhere in the middle.

Explorer brings business intelligence to an audience that desperately needs it but isn’t willing to sacrifice the time to access it.  I frequently hear from IT that “Explorer needs to add XYZ feature,” but remember- its beauty is in its simplicity.  SAP BusinessObjects Explorer requires almost no training.  Adding new features cannot come at the expense of complexity, and I appreciate that Explorer’s product managers carefully guard which features go into the product.

Explorer is great because it addresses the “I don’t know exactly what I’m looking for” business requirement.  Giving key users access to corporate data via Explorer helps them discover new insights.  These insights will lead to more specific business requirements to address specific business problems.  That’s where the more traditional tools for dashboards, ad-hoc query, and enterprise reporting come into play.  Explorer augments these tools.  It doesn’t replace them.

Explorer allows you to start small with your existing universes, then grow into in-memory analytics with either SAP BW Accelerator or HANA.  You don’t have to begin with a large investment.  Many customers are already licensed for Explorer, they just haven’t deployed it because it’s a separate install.

I challenge you to give Explorer a try.  Remember, it helps users find what they didn’t realize they were looking for.  Therefore, they’re not going to come asking you to deploy a tool that they don’t realize they need.  Take the first step and put Explorer in front of them, either on their desktops or their mobile devices.  Then step back and see what happens.

My 2011 SAP BusinessObjects Explorer Tour (so far)

April 29, 2011
ASUG Ohio Chapter Meeting
Cleveland, Ohio

June 24, 2011
ASUG Kentucky Chapter Meeting
Northern Kentucky University
Highland Heights, KY

July 14, 2011
St. Louis BusinessObjects User Group
St. Louis, MO

Your hometown???

Have you deployed Explorer in your organization?  Share your thoughts below.

SAP BusinessObjects Enterprise XI 3.1 SP4 Released!

Microsoft Office 2010, mobile Web Intelligence, and more.

IMPORTANT: SAP BusinessObjects Enterprise XI 3.1 Service Pack 5 (SP5) was released on December 8, 2011. Be sure to review the SAP BusinessObjects Maintenance Schedule and its associated Forward Fit Plan to make sure that any Service Pack or Fix Pack contains the fixes you expect it to. Also keep in mind that some of the latest features in the SAP BusinessObjects Mobile BI app only work if the latest Fix Pack is applied to the server.

Today, SAP released SAP BusinessObjects Enterprise XI 3.1 Service Pack 4 (SP4). This service pack includes the Microsoft Office 2010 compatibility that was introduced in SAP BusinessObjects Enterprise XI 3.1 SP3 Fix Pack 3.4. For most customers, service packs are more palatable than fix packs, so the release of SP4 is really good news. Mobility fans should note that there is also a separate download for SAP BusinessObjects Mobile XI 3.1 Service Pack 4. Service Pack 4 is a prerequisite for the forthcoming release of BI Mobile for the Apple iPad, which was demonstrated at the recent SAP SAPPHIRE conference and is expected by the end of June 2011. As usual, there are separate SP4 downloads for apps such as Crystal Reports 2008, Lifecycle Manager, and Live Office. And as usual, expect multiple tries before getting a complete and uncorrupted download from the SAP Support Portal. As of this writing I did not see any new service packs for Xcelsius 2008 or Explorer XI 3.2 (currently on SP2).

As with any service pack, always review the release notes and deploy first to a non-critical sandbox (a virtual machine is really good for this) before upgrading a production environment. Remember that for most customers, development is really a production environment for developers. So find a non-critical sandbox. I’ll be doing the same over the next few days so I can articulate clear upgrade plans.

To all of the developers at SAP – thank you for getting this service pack out. We know you’ve been extremely busy (and stressed) getting BI4 ready for general availability (GA).

Service Pack 4 is available from the SAP Support Portal with a valid S-ID.

UPDATE: Thanks to my good friend and Diversified Semantic Layer host Eric Vallo (follow him on Twitter here) for pointing out the following link to SAP Knowledge Base article 1596293 (S-ID required). It’s one-stop-shopping for SP4 with links to other SP4-related knowledge base articles. And thanks to ASUG volunteer Tammy Powlas (follow her on Twitter here) for pointing out that release notes of all varieties can be found on the SAP Support Portal at (S-ID required).

Will your organization deploy SP4 and Web Intelligence on the Apple iPad? Or go straight to BI4? Share your thoughts in the comments section below.

Quiet update for SAP BusinessObjects Explorer for iOS

SAP BusinessObjects Explorer 1.02 for iOS

In preparation for this week’s SAP SAPPHIRE event in Orlando, SAP has quietly updated the SAP BusinessObjects Explorer app in the Apple iTunes App Store.  The previous version (which, thankfully, does not get overwritten by the update) only required a link to the Explorer server, such as http://[servername]:[port]/polestar.  The new version has some additional requirements that are ruffling feathers at customer sites.

Note: To use SAP BusinessObjects Explorer app with your business data, you must have installed SAP BusinessObjects 3.2 SP2 release of SAP Business Explorer and SAP BusinessObjects Enterprise XI 3.1 FP 3.4 including the SAP BusinessObjects Mobile Server.

In BI4, SAP has integrated the mobile servers into the Central Configuration Manager (CCM) and installs them by default.  However, in XI 3.1, the mobile servers aren’t as well-integrated.  Plus, requiring customers to embrace a Fix Pack for new functionality instead of a Service Pack is an interesting move, as conventional wisdom is to only install Fix Packs to correct problems.

Thankfully, SAP has released Explorer 1.02 which has a new “Connect via Mobile Server” switch on the Settings screen. Simply leave it in the default position (OFF) and enter the Explorer Server URL, http://[servername]:[port]/polestar.


Explorer using Explorer (polestar) URL

If Mobile BI is in use, simply flick the switch and enter the URL for the mobile server.
Explorer using Mobile URL

If you have configured BI Mobile, the URL for the Mobile Server is brain-dead simple.  Just http://[servername]:[port number] and the Explorer app does the rest of the work to find the mobile directory on the web application server.

SAP BusinessObjects Explorer is a great application that extends your organization’s BI to casual users and mobile devices.  It’s ready to deploy on the XI 3.1 platform today and will soon be available with the rest of the BI 4.0 suite.  I’m anxious to learn more about mobile BI at this week’s SAPPHIRE conference.  And I hope to report in a future post how to install and configure the BI Mobile XI 3.1 servers for Explorer on iOS.

Whacking the WACS

How to remove the WACS server if you’re not using it.

I’m currently architecting a two-tier solution using with two Tomcat web application servers and two SAP BusinessObjects Enterprise XI 3.1 SP3 servers. We’re using Microsoft Windows Server 2008 R2 Standard as our operating system and using the SAP Integration Kit (aka Integration for SAP Solutions). We first built sandbox and development environments using a single-server configuration.  Our QA/UAT and production environments each have four servers (two WAS and two BI). When doing a “new” install without the web components on the BI server, the Web Application Container Server, or WACS, secretly installs.  The WACS server is handy, because when you finish the SAP BI installation, there isn’t a “real” Tomcat server to test everything out yet. The WACS server allows you to log into the Central Management Console (CMC) immediately after installation to verify the installation. However, the SAP Integration Kit and the WACS server do not play nice together.  You’ll actually receive the following fatal error when installing the integration kit:

The installation of SAP BusinessObjects XI 3.1 Integration, version for SAP solutions applications SP3 cannot continue because the Web Application Container Server has been installed with SAP BusinessObjects Enterprise.

This is confirmed in the SAP BusinessObjects Enterprise Integration for SAP Solutions Installation and Administration Guide (S-ID required for link):

The Web Application Container Server (WACS) is not a supported application server for the Business Objects XI Integration for SAP Solutions. To use .NET InfoView on IIS together with BusinessObjects XI Integration for SAP Solutions, you are still required to install backend applications such as CMC or Web Services on a supported Java application server.

As with Osama Bin Laden, we must whack the WACS server. Unlike Osama Bin Laden, we do not need a covert operation with Navy SEALs to find the Windows Server Control Panel. To remove the WACS server from Windows Server, open the Windows Control Panel and choose Programs->Uninstall a Program. Find SAP BusinessObjects Enterprise XI 3.1 SP3 in the list of installed programs and click the Change button. You’ll find the Web Application Container Server listed in the Server Components section. Choose to uninstall the feature. You will (sigh) need the original installation files, so if you already whacked those after the previous installation, you’ll have to put them back.

Here’s another perspective on the SAP Integration + WACS issue.

After this experience, I’m looking forward to the improved SAP business suite integration promised by SAP BusinessObjects Business Intelligence 4.0 (which uses the WACS for its new RESTful SDKs, which may make the WACS mandatory in your BI4 deployment). But the next time I need to combine XI 3.1 and SAP Integration, I’ll begin with a custom instead of new install and insure that WACS is not being installed.

Missing SAP BusinessObjects Explorer Servers

Find missing servers with AddNode.bat

After the adrenaline rush of presenting on SAP BusinessObjects Explorer XI 3.2 SP2 on an Apple iPad2 at last Friday’s ASUG Ohio chapter meeting, I was greeted this morning with the following installation issue.  Bin Laden may no longer be missing, but my Explorer servers were nowhere to be found.  Fortunately, I resolved the issue without assistance from SAP Support or U.S. Navy SEALs.

I’ve never seen the issue occur when all Explorer components are installed on a single server.  But I recently installed the Explorer web application on a separate physical server (using Tomcat) than the rest of the SAP BusinessObjects environment (where the Explorer servers and the Explorer CMS add-on go).  The software was clearly installed, but the Explorer folder (and the Explorer servers) did not show up in the Central Management Console.  Nor were the servers secretly running in the Windows Task Manager.  A similar issue has been previously documented by Andrew Koller regarding the Xcelsius Cache and Processing servers and the Life Cycle Manager (LCM) job server.  So I crossed my fingers, ran AddNode.bat, and resolved the problem.  The syntax for AddNode.bat is as follows:

[BOE_install location]win32_x86scriptsaddnode.bat -name [NODENAME] -siaport [Port Number] -cms [CMS Name] -user [User Name] -password [Password] -authentication [Type] -platform win32_x86 -update


C:Program Files (x86)Business ObjectsBusiness Objects Enterprise 12.0win32_x86scriptsaddnode.bat -name alqaeda_prod -siaport 6410 -cms alqaeda_prod:6400 -user Usama -password NeverFindMe -authentication secEnterprise -platform win32_x86 -update

Once the script completes, the four Explorer servers appeared as expected in the server management area of the Central Management Console (CMC).

This installation is using SAP BusinessObjects Enterprise XI 3.1 SP3 on Windows Server 2008 64-bit.  So I’m wondering if SAP hard-coded the location of AddNode.bat in the “Program Files” instead of also looking in the “Program Files (x86)” directory?

Anybody else experience this issue?

Don’t Fluster the Cluster

An improperly designed architecture may cause your cluster to become fluffed.

Ben and Jerry’s recently introduced a new flavor called Clusterfluff (now rebranded as the more politically correct What a Cluster), described as “peanut butter ice cream with caramel cluster pieces, peanut butter and marshmallow swirls”. Yummy. But today, let’s talk about a different cluster: SAP BusinessObjects Business Intelligence, also known as SAP BusinessObjects Enterprise.

Ben and Jerry's Clusterfluff Ice CreamA cluster in SAP BusinessObjects Enterprise is defined as a system with multiple Central Management Servers (CMS) that work together by sharing a common system, or CMS, database. Each CMS is typically on its own physical device, known as a node. SAP BusinessObjects enthusiasts who take the BOE330 training class, Designing and Deploying a Solution, get to team up with their fellow students and create clusters in class. Let’s discuss using Microsoft Windows; however, the same principles apply to Linux/Unix.

I recently encountered a BI system with a poorly devised cluster. It was the second time that I’ve seen this ill-advised configuration on the XI platform, so it seemed worth writing about. Especially since SAP BusinessObjects Business Intelligence 4 continues the server architecture of the past few versions. In both of my situations, each physical server, or node, was built with a “new” install.  Once the installation was completed, the second CMS was stopped and reconfigured to point to the same system database as the first CMS, as shown in the illustration below (click image to enlarge).

How to Cluster SAP BI - Bad

Each node has an identical configuration. There’s two of everything. Two Central Management Servers. Two Crystal Reports Processing Servers.  Two Web Intelligence Processing Servers. And, sigh, two Input File Repository Servers, or iFRS. There are two Output File Repository Servers, or oFRS, as well. Each file repository server points to local storage on the node, which is a significant flaw that could lead to corruption of the cluster.

In a SAP BusinessObjects cluster, only one FRS is actively working even when all FRS in the cluster are enabled. Just like many of your coworkers, the rest of the FRS sit around doing nothing in a passive state waiting for the active FRS to fail. All FRS connect with the CMS upon startup. The active FRS is the one that contacts the CMS first.

So how can the cluster become corrupted? Let’s assume that the iFRS on node 1 becomes active. When a report is published to the system, it is stored on the iFRS default location, which is the C: drive on node 1. The CMS database contains an InfoObject containing the physical path to the report.

Next, let’s assume that the iFRS on node 1 fails. The iFRS on node 2 becomes active. When Wanda in accounting logs into InfoView to view a month-end report, the processing server will fetch the report from the active iFRS on node 2. However, because the report was originally written to the C: drive on node 1, Wanda will receive an error and call the Business Intelligence help desk.

The cluster, sadly, has become fluffed.

A better solution would be to disable the iFRS and oFRS on node 2, guaranteeing that the iFRS and oFRS on node 1 are always active and that all documents are stored locally on node 1. This configuration is shown in the following illustration (click image to enlarge).

How to Cluster SAP BI - Better

You might argue that this configuration is not fault tolerant. And it isn’t. However, neither was the first configuration. Disabling the second iFRS and oFRS is the first step to preventing additional corruption.

The best solution is to create a file system that both nodes can share, as shown in the illustration below (click image to enlarge).

How to Cluster SAP BI - BestEach FRS is configured in the Central Management Console (CMC) to use the shared space, typically by specifying a UNC path. Since the shared space is on a different device, the File Repository Servers will need to run using a domain account rather than the default Microsoft Windows Local System account. This account is specified in the Central Configuration Manager (CCM), either directly on the File Repository Server (XI R2) or vicariously through the SIA (XI 3.x, BI 4.0, BI 4.1). Be sure that separate directories are created to distinguish the Input File Repository from the Output File Repository; however, both can share a common parent directory, as they do in the default out-of-the-box configuration.

There are other design considerations for a truly fault-tolerant BI architecture, such as failover in the web application server tier. But that will have to wait until a future discussion. In the meantime, I hope you will enjoy a pint of Ben and Jerry’s Clusterfluff ice cream. And inspect your BI system to insure proper configuration.


SAP KB 1378753 – How to configure the File Repository Server (FRS) to point to the Network Attached Storage (NAS)?

What are your experiences with SAP BusinessObjects clustering? Share your thoughts (and favorite bookmarks).



Getting the most out of your Web Intelligence Processing Servers

Matthew Shaw helps us get the most out of our Web Intelligence Processing Servers

Matthew Shaw, a Business Intelligence Architect at SAP, has posted this tremendously helpful article entitled “Performance Tips: Getting the most out of your Web Intelligence Processing Servers” on the SAP Community Network. I frequently get into religious arguments over number of server instances vs. maximum connections per server, which he has elegantly demystified.

I’m sure to be reading it over and over, so I’m putting up this article for easy reference.

Thanks, Matthew!

Follow Matthew Shaw on Twitter

New Xcelsius Servers in SAP BusinessObjects Enterprise XI 3.1 SP3

The debut of the Dashboard Cache Server and Dashboard Processing Server

Patrice Le Bihan has recently (October 2010) posted a nice set of articles to the SAP Community Network wiki regarding the Xcelsius Cache Server and Xcelsius Processing Server added to SAP BusinessObjects Enterprise XI 3.1 SP3 (UPDATE: These servers have carried over to the BI 4.0 platform as the Dashboard Cache Server and Dashboard Processing Server). He covers why these new servers were added to the SAP BI architecture, how to enable them, how Xcelsius/QaaWS caching works, available tuning options, and sizing these new servers into your architecture.

Patrice, thanks for putting together this information.

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.

Shouldn’t we all stop looking at Desktop Intelligence?

We should stop looking at Desktop Intelligence.

Today I attended an interesting SAP webinar entitled “BI 4.0 – Did you think about your upgrade?” by David Francois Gonzalez with the SAP Technology RIG Americas (the very useful slide deck can be downloaded from the SAP Community Network).  Afterward, I tweeted:


To which Pieter Hendrikx responded:

@ericvallo @oswaldxxl @dallasmarks shouldn’t we all stop looking at Deski? That’s what my [Diversified Semantic Layer] conclusion was. Better invest in #WebI

And of course, Pieter is absolutely correct.  We should stop looking at Desktop Intelligence.  But Desktop Intelligence is like a gruesome automobile accident during rush hour- some of us can’t stop looking (see related discussion on the BusinessObjects Board).  But the SAP BI roadmap is clear- Web Intelligence is the future, Desktop Intelligence is the past.  Desktop Intelligence is not supported by SAP BusinessObjects Business Intelligence 4.0.  It’s gone.  Really.  Crystal Reports 2011 and Web Intelligence 4.0 represent the future of reporting for SAP.

Some organizations already use Crystal Reports and Web Intelligence exclusively.  For them, the path to SAP BusinessObjects Business Intelligence 4.0 is relatively straightforward.  Other organizations, particularly those who have used “classic” BusinessObjects releases prior to XI Release 2 (XI R2), still may have an investment in Desktop Intelligence that has to be managed.  But the good news is you can take proactive steps today from either XI Release 2 or XI 3.1 – you don’t have to wait for BI 4.0.

Organizations on both XI R2 and XI 3.1 should immediately begin phasing out the creation of new Desktop Intelligence reports by revoking Deski application rights and retraining users to use Web Intelligence.  Some reports cannot yet be converted to Web Intelligence (I plan to address Desktop Intelligence phase out strategies in the coming weeks).  These reports may have to wait for the BI 4.0 Report Conversion Tool.  But many can be converted today with your current platform.  Organizations on XI R2 have fewer conversion options than XI 3.1 (and therefore much incentive to upgrade to XI 3.1 in the near term).  In addition, Desktop Intelligence reports are audited by the XI 3.x platform (sadly not in XI R2), so it is possible to identify obsolete reports and retire them rather than expend effort to convert them.

Any organizations still on “classic” BusinessObjects 5 or 6 (I know you’re still out there) cannot go directly to BI 4.0 as the upgrade tools only support XI R2 and higher.  These organizations should plan a migration to XI 3.1 so they are poised for the future.

For long-time Business Objects users, it’s the end of the world as we know it.  But SAP BusinessObjects Business Intelligence 4.0 will be available early next year.  And I feel fine.