Server

BO XI Patching, An Introductory Deep Discussion

Patching your Business Objects XI Enterprise system can be a daunting and confusing endeavor. I hope that this little article can help dispel some of the confusion surrounding the topic.

For your reference all Business Objects XI base version and patch installation files can be found here:
http://service.sap.com/bosap-downloads/

Let me first establish some fundamentals to be sure that there is no confusion. First let’s define the terminology of base, patch, service pack, fix pack, ADAPT, MHF, CHF, and LA Fix:

Business Objects Patch Glossary

Base: This is the full install of the base version of the Business Objects Enterprise product. For example, the installation package for Business Objects XI 3.1, without any patches included.

Patch: This is a generic word used to describe any install package that is not the base install package. It may be used to describe full install packages which are occasionally created for Service Packs.

Service Pack: These are large groupings of bug fixes that may also include some new functionality of performance enhancements. Usually a new Service Pack (SP) is released once the current version reaches a Fix Pack level around X.5 and they seem to be released every 8 – 14 months (depending on the stability of the release). SP are numbered, such as SP1, SP2, SP3, etc.

Fix Pack or FixPack: These are smaller groupings bug fixes that are released every few months or so. FixPacks (FP) are associated with particular Service Packs and therefore any given FP can only installed against the SP for which it was released. Fix Packs are numbered after the decimal and share their parent ServicePack’s number before the decimal. For example, FP 2.6 is the 6th FixPack released against Service Pack 2.

Limited Availability Fix or LA Fix: This is the lowest level of patch. These are usually obtained by large customers of SAP Business Objects or by customers who pay a premium to obtain a fix for a single bug. LA Fixes are used by BO customers to fix bugs either as soon as possible without having to wait for the fixes inclusion in a Fix Pack or, in special cases, they may fix a bug that is also fixed in a FP or SP, but the BO customer can’t install the FP or SP due to some restriction on the customer’s side. PLEASE NOTE, LA Fixes do not go through the strenuous QA testing cycles that are applied to FP and SP. LA Fixes often do not come with an installer, but rather they are a few binaries and some instructions on how to “install” these binaries. It should be noted that LA Fixes are made to be applied only to a certain patch level (that of the requesting customer). This means that once an LA Fix is installed, an administrator should not install any patches until it receives confirmation that the bug which the LA Fix corrects has been fixed in desired patch. One can expect that new bug fixes released through LA Fix, may not be included in the next fix pack to be released, or possibly not even in the FP after that. This will depend on the severity and priority assigned to the bug.

ADAPT: Business Objects tracks their bugs through “ADAPTs”. The following describes the birth of an ADAPT: Customers or BO personnel bring a bug to BO support. The issue gets escalated through support and through a technical escalation. Passing these, the bug is verified and an ADAPT is initiated to track that bug and pass it on to the product development teams who will determine its priority and eventually its inclusion in planned FP and/or SP.
MHF or CHF: These are old acronyms and terms (monthly hot fix and critical hot fix) that were used prior to BO XI. They more or less correlate with FixPacks.

Interesting BOE Patch Details

The following are a few interesting aspects of Business Objects Enterprise patches.

  • Usually when at about the fifth Fix Pack associated with the current Service Pack the next service pack is released. If you are keeping current with patches this is a good time to move to the new SP. All future FP released on the old SP will continue to fix newly reported bugs, but upgrading to the next SP will give you some scary errors if you install these FP’s. My best recommendation is to jump to the newest SP once it has its first FP. Let others discover the bugs and suffer the pain for you.
  • Most patches are incremental, meaning that they require that you install the preceding level of the product. For example, incremental Service Packs will require the installation of the base version, Fix Packs require that you install their associated Service Pack.
  • FP are cumulative, so if you are on FP 1.1 and you want to get your system up to FP 1.5 you only need to install FP 1.5. SP are similarly
  • Full installs are patches that do not require the installation of the base version or any other patches. They are standalone Service Pack patches. These are usually large in size, but smaller than the sum of the incremental patches that would get you to the same level. It is recommended by most admins and by SAP Business Objects that one should always install the highest available full install, and one should not install the base version with incremental patches when a full, standalone patch install is available. By leveraging the full install one can expect a cleaner install directory, with a lighter foot print.
  • Full Standalone Service Pack Installs are not released with each new SP. In Business Objects XI R2 full installs were made available on even-numbered Service Packs, such as SP2 and SP4 (it should be noted that SP6 was an incremental upgrade). For XI 3.1 it appears that full installs will be released on odd-numbered Service Packs (SP3 has a full install, but I don’t recall one for SP1).
  • Patches will write a large number of “backup” files to the “/setup/backup” folder. Since these folders are located in the same parent folder as “bobje” one must take care that they do not “steal” away too much free disk space from your Business Objects application. By the way, these files are only used to uninstall patches and therefore they can be relocated if necessary.
  • All BO XI 3.X patches require that you first install the patch on a single CMS machine (running only CMS and Input/Output FRS, with all other machines in the cluster NOT running their BO servers), and then after this a successful installation one can proceed to install the patch on all other machines in the cluster. Therefore your total patching time will be at a minimum the time it take to install on a CMS machine plus the longest duration taken to install on the rest of the machines.
  • Language Packs can lengthen the duration of base and patch installation considerably. Choose your language packs carefully as they will lengthen your downtime for patching in the future. For example, make sure your user(s) will actually make use of the Finnish language pack before you just decide to throw it in to be safe. Everything has a cost. There is no such thing as a free lunch. Also, please note, that new language packs may be made available with new Service Packs; however, you may need to take special steps to be able to install these as language pack selections are often only done with full installations.
  • In a multi-machine cluster plan out which servers will take which roles. If, for example, a machine/box will always only run WebI Processing Servers and nothing else, there is no need to install CMS, Crystal, FRS, DeskI, etc. on the server. By limiting the installation you can expect future patching and initial installation to run more quickly.
  • A huge oversight is to forget to patch your Windows client tools. Do not make the mistake of failing to patch your Designer, Import Wizard, Desktop Intelligence, and WebI Rich Client applications. BO does not always stop lower patch version of client tools from connecting to higher patch level BO systems, but the ramifications of such uses could be quite severe. DO NOT FORGET to patch your administrative client tools and have your users install the patches as well.

If you have any comments, questions, or thoughts to share on this topic please do so below.

For your reference all Business Objects XI base version and patch installation files can be found here:
http://service.sap.com/bosap-downloads/


Login Taking Long? Blame Java’s DNS Look-up

The other day I answered a different article’s comment with a very brief mention of what I’ve been told by SAP-BO was a common tweak. The potential benefit of this simple tweak is large enough to merit its own article. Thank you MarcV for making this apparent. I would like to answer his questions here.

First of all, what tweak are we talking about?

Place entries in the hosts file on all web application servers/hosts/machines/boxes for each of the machines/hosts/servers/boxes running CMS. This tweak is a workaround to resolve Java’s poor, inefficient implementation of DNS look-up.

The computer’s hosts file lists hosts (meaning computers identifiable on the network) that are to be resolved locally and not through the computer’s DNS (domain name server). New hosts are added by listing the IP address of the new host first, followed by at least one space, then the new host’s fully qualified server name, then optionally one could add at least one space and the new host’s short name. Here are some links to a good tutorial of hosts files and a good discussion of hosts files.

Here is what MarcV said:
Julian,

Can you expand on the last comment? I would love to know more about it, as common tweaks should be… common? I have never seen that tweak mentioned anywhere.

Currently, we host everything on one server (yeah, I know). Should we enter the server’s name and IP in the hosts file as if it were on a separate machine? Using Tomcat for the app server, that would affect pretty much everything that gets served up (logins, screen renders, WebI, Web Services…)

I’m all for speeding things up. What aspects would this affect? WebI/C Reports/LOV/???

Do you know of any consolidated source of “common tweaks”? I usually find one there here, one thing there… which means, you only know about the things that you might be researching if you’re noticing problems. Not knowing about Java having a poor implementation for DNS look-up, we might never have touched on that for our BOXI issues.

I agree, it seems that the use of the word common here was unwarranted. I did not use this tweak until it was mentioned to me by a BO support engineer after working through some deployment issues. He and others after him told me this was a common tweak for Java Application Servers and I took them at their word.

To the best of my knowledge the biggest performance improvement that one can expect from this tweak is to speed up initial login; however, it seems to me that some over operations run a little faster after the tweak is implemented.

In the case you have a one-stop-shop and you are running everything on one server, I believe that you may still see a performance improvement with this tweak. However, you may find that there is already an entry for your server in your server’s hosts file.

Repository of Common Tweaks

I wish there were a single location listing tweaks that one implement on their Business Objects XI system. Perhaps there is none, because those with the knowledge either don’t make the time to document and publish them or they don’t wish to give away for free very valuable information. Nevertheless, we can try to build one here if there is interest. I could start a “tweaks” page and through comments we could communicate our known tweaks which I would then incorporate in the main article.


Common BO-WebLogic Issues

Oracle-BEA WebLogic is not a technology I want to dive deeply into with this web site; however, it is often the Java Application Server of choice for many Business Objects XI environments because of its scalability and it tends to be preferred by other business technologists within companies. I personally work/struggle with it a lot and so I thought it a good idea to share a few issues and their resolutions in this article. I also would welcome anyone else to share their war stories as well. Be warned, I am writing this article to those who are already familiar with configuring/deploying BOXI on WebLogic.

Node Manager Service Won’t Start

This issue may be specific to Windows operating systems or it might apply to others as well. The symptoms are that you can run Node Manager from the command prompt but you cannot run it as a service.
CAUSE: If you have encountered this issue, look immediately at your “Path” environment variable. Is the final character a backslash ( \ )? If so this could be causing the script run by the service to fail due to some faulty programming. Most likely someone or some automated script/patch altered the “Path” variable and the problem did not occur until WebLogic was restarted. This issue actaully has nothing to do with Business Objects.
FIX: Just remove the backslash ( \ ) as the final character. If you really want you could also append a final semi-colon ( ; ) at the end.

Installing/Deploying Applications Fails

This may be a Unix/Linux only issue. When deploying Business Objects XI applications such as InfoViewApp, CmcApp, PlaformServices, or AnalyticalReporting you notice that you can never get them all successfully installed or started. Individually they may work just fine, but with all of them installed you suddenly start seeing infinite down apps and “Start running” status messages when you start them up. If WebLogic starts to feel like the twighlight zone you should start to question if it is hitting limits imposed by the OS.
CAUSE: There is an OS level setting that limits how many open files a single session/instance can have. In Linux this is stored in the “ulimit” under the setting “open files”. If this setting is too small (less than about 2048) you can expect issues. This is due to the fact that Business Objects applications/deployments have a very large number of files and WebLogic “opens” them all during deployment and application serving.
FIX: Increase the ulimit for “open files”, a.k.a. “nofiles” to 4000 or 4096 if you like. This should not impose any security threat to your system; however, after running the command “ulimit -a” you may discover that the limit imposed by your OS is too low to allow this increase. In such case, get it increased (see “etc/security/limits” or SAS has a good web page on this, too bad BO has no official comment on the topic). Keep in mind that you will need to also tell WebLogic to use more of these open files. The best way is to do so by appending a line in the “commEnv” file located in the “/weblogic/common/bin” folder.

The Admin Server Won’t Start

This is one of the most perplexing issues because there are not errors to point you in any direction. In short, the Admin Server cannot be started successfully via a service or via the command prompt. If watched closely you see that it progresses fine for a couple seconds and then it freezes. If you look closely at running it through the command prompt you will see that the last entries (“”) are related to security; this is your only helpful clue.
CAUSE: The “ldap” directory has become locked or corrupted by some errant process.
FIX: Stop all WL processes. Rename the “ldap” directory or compress it and delete it. Start the Admin Server. Viola! You just fixed it. WL will recreate the “ldap” directory. If you don’t even use WebLogic’s LDAP functionality then just move on, if you do use it, you may have some work still left to do. Alternatively you could look for the “lock” file (*.lck) and delete it.

Please feel free to share your own BO-WebLogic issues and their solutions. I hope this article becomes a place to share some successful resolutions and not a place to ask for help with WebLogic. There are better qualified web sites for that.


Java App Server and CMS On Different Machines, Edit “hosts” File Now

If you have deployed your Business Objects XI Central Management Server(s) and your Java Web Application Servers are on the same single machine then this article does not apply to you. If your Java Web Application Server ever needs to run applications (such as InfoView or CMC) that will connect to any CMS that is not running on the Java Web Application Server’s machine then you and your system will benefit from reading this article.

The Java Implementation of DNS Look-up

I’ve been told by a few very knowledgeable folks that either Java as a technology or Business Objects Enterprise’s use of Java results in a situation where if the CMS is not hosted on the same machine as the the Java Application Server then the look-up of the IP address of the CMS machine(s) is very inefficient and is the cause of much lag in the case of such actions as logging in. For example, an InfoView log in action may take up to 10 seconds extra due to iterative inefficient resolution of the CMS machine’s IP address from the host name.

Building a Short-Cut

One way to put an end to this inefficiency is to place hard coded entries in the hosts file of the machine hosting the Java Application Server. If your server is configured to first check the hosts file before hitting the network’s DNS server then you will see a huge boost in the performance of log in actions. This is simply due to the fact that the poor implementation of DNS look-up that BO’s Java call is doing is bypassed by the hosts file entry for that host name. I have seen log in actions for InfoView and CMC reduced from 8 seconds to less than 1 second by this change alone.

Making the Change

This is one of those changes that won’t cost you much to test, but there is a price. The truth is that there is a very big issue with hard-coding a server name and IP address in your hosts file. On the very rare occasion that your server is assigned a different IP address your application will be broken until you update the hosts file accordingly.

To make the change you need only locate the machine’s hosts file. On Windows this is usually in “\WINDOWS\system32\drivers\etc” and on Linux it will be in the “/etc/” directory. Once you locate the file I suggest creating a backup of it first. New lines are added to the file merely by adding first the IP address, then at least one space, then the fully-qualified domain name, and optionally you can add at least one more space and put in the simple short name of the machine. For example:

12.232.131.121 myserver.mydomain.com myserver

I am not an expert on editing hosts files, but I can tell you that it is worth trying out on your system in you are running at least one CMS on a machine different from the one that is running your Java Web Application Server. Give it a try and report your results by leaving a comment please. To the best of my knowledge you don't even need to restart your deployment for the change to take effect. Just make the change and test the results. Good luck.


BO XI Distributed Environment: The Standalone Java Application Server

When you are building a small sandbox it is great to put everything all in one place and create a Business Objects solution that is a one-stop shop (a.k.a. putting all of your eggs in one basket). This works for lots of small-to-medium sized BO systems, but sometimes you want to do a little more. Sometimes you want some fault-tolerance, high-availability, and/or fault-tolerance. In any of these cases you might decide to build something really cool: a distributed Business Objects Enterprise XI 3.X Environment.

In this article, I would like to talk about putting your Java Web Application Server on a separate dedicated machine. You could chose Apache Tomcat, or your could get a little more crazy and go with Oracle’s WebLogic. Either way, the principles are the same.

Does BO Support Mixed Mode?

Perhaps your BO CMS, job, and reporting servers are all running on Windows machines. Perhaps you are thinking that you would like to run your Java applications on a Linux server. No problem. Business Objects has documented that it is acceptable to mix different Operating Systems in your BO environment as long as all servers running a particular component are of the same Operating System. What does this mean? It means that you would be running in a unsupported mode if you ran one CMS in your cluster on Windows and another CMS in the cluster on Linux. But if you put all of your web applications on Linux you should have no problems getting support and you should not expect any unusual issues. In fact, in my opinion, if your web application servers are not clustered, you could get away with running Apache on one Windows server and WebLogic on a Linux server, since they do not communicate with each other.

How Do I Create a Dedicated BO Web Application Server?

The hardest part is setting up your Java Web Application Server. I won’t help you here, but there is plenty of help out there in the great Internet to guide you in configuring Tomcat or even setting up WebLogic. Once this is setup all that you have to do is copy the WAR files over to the server (or you can even upload them from your client machine using the WebLogic Administration Console). Yes, this is all you have to do for Business Objects XI 3.0 and later.

Don’t I Need to Install BO on the Server?

No, do not believe the documentation. You do not need to install BO on the server as long as you can generate the WAR files from some other server. It is true! The documentation would have you believe that regardless you need to copy over at least the “deployment” folder and a “java” folder, but this is not true. These are ONLY needed if you are needing to run “wdeploy” on the Java Web Application Server. In my case, I can always use a CMS machine to generate my WebLogic and Tomcat WAR files so why would I want to put BO software on another server? If I put some of the BO binaries on my Java Web Application Server then I have to worry about maintaining/patching the software on that server as well. I don’t know about you, but I don’t need more work and more things to forget to do.

Where Do I Get the WAR Files From?

As I said, go look at the CMS machine. Follow the documentation* to help you find the “wdeploy” application (it is a command-line driven application, probably found here /deployment/wdeploy.*). Since you are probably running a CMS cluster and you would like your web applications to be aware of this cluster I would recommend using wdeploy with the “predeployall” option. So basically, all you need to do is to run the command “> wdeploy weblogic10 predeployall“. You do not need to configure any “config.*” files for your Java Application Server as these are ignored when running with the option “predeployall”. After you run the command successfully, take about 4 to 7 minutes, then you will be told where your WAR files will be located, for example: /deployment/workdir/weblogic10/application/. You will then need to make your changes to these WAR files (cluster, authentication, single sign-on, enable path queries, etc.) and then get them somewhere that your Java Application Server can reach them. Then you just need to deploy them properly and you are done. Congratulations!

What About XI R2, Do I Need to Put BO on the Web App Server?

All java deployments/application except for the “webcompadapter” are standalone applications that require nothing more than a supported JVM to be installed on the Java Web Application Server. The only application that uses the “webcompadapter” is CMC, so if you are intending to provide CMC access through some other method (such as a small unadvertised Tomcat instance installed on a CMS server) then you do not need to install any Business Objects binaries or libraries on the Java Web Application Server. The issue here is that the XIR2 still has some JNI calls in CMC, it was not fully converted from COM to Java and so the “Web Component Adapter” is required by the CMC and it requires that certain binaries of Business Objects Enterprise XI R2 be installed on the server.

————-
* Recommended published BO documentation is the “BusinessObjects Enterprise XI 3.1 SP2 Web Application Deployment Guide” or if not running Service Pack 2 then use the “Web Application Deployment Guide” for your OS (hint: Unix applies to both Unix and Linux). Of course, the file names will look more like the following: xi3-1_deployconfig_unix_en.pdf or plugin-xi31_sp2_webappd_unix_en.pdf (for example)
Note: I have not played enough with IIS and .NET to know much about deploying the different application there. I am sure the process is quite different, so I would not try to use this article as a guideline for any .NET BO web applications.


The Over-Credited Destination Job Server

Would you get a little upset if someone else kept taking all the credit for the work you do. Would you get down right furious when that person couldn’t fix any issues relating to their ill-earned reputation when a real problem came along and then you had to come along and save the day without even getting an ounce of credit. You would have to be a saint not to get upset about that, wouldn’t you, or perhaps you would just have to be a Business Objects Reporting/Adaptive Job Server?

The truth of that matter is that the Destination Job Server is not really at fault. He was born with a very bad and confusing name. Then over time IT folk got confused with the name, fixed an issue by configuring destinations on every server and then credited the “Destination Job Server” with being the key solution. While one can learn a lot from forum discussions, some BO forums are ripe with incorrect advice to fix job destination errors by configuring the Destination Job Server’s destinations. So this little article is written in hopes of dispelling a myth and giving credit were credit is due.

Destination Job Server, What Is It Good For?

First of all, let it be known that the Business Objects XI Destination Job Server is only responsible for handling the requests submitted through the “Send To” command within InfoView. Yes, that is right. When you are in InfoView and you select a document (check the box next to it) and then proceed to select to send it to an inbox, email, or other destination. In Business Objects XI InfoView it looks like this:
BO XI 3.1 InfoView 'Send To' Menu
When you use this InfoView “Send To” functionality you are in effect creating a job that only has the purpose of delivering a file to a destination. This, my friends, is what a Business Objects Enterprise XI Destination Job Server does; nothing more and nothing less.

So what about the “destination DLL disabled. CrystalEnterprise.Smtp:”error I get on my jobs server?

If you have this question still please read the above paragraph one more time and then read my previous article titled “Fixing the Business Objects XI “destination DLL disabled. CrystalEnterprise.Smtp:” Error” and now log in to CMC and configure your destination on all job servers in the cluster. Now you know, and knowing is half the battle.


To Split Mode or Not to Split Mode, That is the Question?

Wishlist Item: A Distributed Business Objects Enterprise Environment

We all want our BOE environment to perform to the best of its ability. We want to be certain that no particular component of our environment’s architecture is a weak point or bottleneck. As a result, given the time and the hardware, most of us would love to deploy a distributed, well-balanced Business Objects Enterprise environment. In many cases this would include putting each tier or group of services on their own machine/node: the Intelligence Tier (CMS, FRS, etc.), the Processing Tier (Report/Processing, Job, etc.), Web Application Tier (where InfoView and CMC are deployed), and Web Tier (HTTP/HTTPS services). Aside for using multiple servers for each tier, if you read the documentation closely, you could be tempted to take your distribution to the next level.

What is “Split Mode”, “Split-Web”, “Split Deployment”?

The SAP Business Objects “Web Application Deployment Guide” explains that “you can deploy all web application resources on a single web application server (standalone mode), or to separate dynamic and static content for deployment to de-paired web and web application servers (split mode).” The dynamic content, the part requiring actual processing would be deployed to the dedicated Web Application Server and the static content (images and client side scripts, I believe) would be deployed to a dedicated Web Server. The reason behind creating a split mode web deployment would be to better distribute the load of Web Application Server, giving the otherwise under utilized Web Server a little more responsibility.

The following is a list of WDEPLOY supported split mode server combinations:
• Tomcat 5.5 (web app) with Apache 2.x (web)
• WebSphere 6.1 (web app) with IBM IHS (web)
• WebLogic (web app) with Apache 2.x
• Sun Java Application Server 8.1 and secondary web server

Ideals and Reality, Same or Different

My mother used to play a game with us (when we were children) that we called “same or different”. It quickly became and inside joke, a way of indirectly making a comment on something, for example, I would ask my mother something like “Business Objects, a simple/stable/scalable out-of-the-box experience; same or different”. Now I didn’t say that all of them were witty gems.

The truth of the matter is that even if you are successful at deploying Split Mode you won’t find that it makes your life, or that of your servers any easier. It is extremely difficult to get Split Mode working. The guides would have you believe that it is a simple matter of using different parameters with the WDEPLOY application. This may be true for creating the packages to deploy, but actually deploying them and getting them to function is quite a different task.

Benefits Outweighed by Costs

If you are able to get split web working then you have joined the ranks of a very select few and you have also probably burned through at least 3 or 4 of your SAP Business Objects Support Customer Message allocations. So what did all of that work get you? Not much, in fact, even if you are monitoring the servers closely you may not see any change in the actual load on the Web Application Server, even with a large user base. Not to mention, each time you install a FixPack or Service Pack you will have to recreate the magic all over again and ask yourself, was it really worth it?

These are not just my personal experiences and observations. Seasoned Business Objects consultants have expressed similar discontent with this feature. My limited Internet research (forums, mostly) also confirms my findings. I would love for anyone to share their own experience with split deployments in the comments.


Tips for Installing FixPacks in Business Objects XI 3.1

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.
  • Setting the Environment Variable "Temp"

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.


Fixing the Business Objects XI “destination DLL disabled. CrystalEnterprise.Smtp:” Error

One of the most helpful error messages (sad very sarcastically) in Business Objects XI is “destination DLL disabled. CrystalEnterprise.Smtp:”. You get this one usually after recently configuring a new job server or setting up your first scheduled job in a Business Objects XI environment. This error exists in XI R2 and it is definitely present in XI 3. So what does it mean and how do you fix it?

What is the “destination DLL disabled. CrystalEnterprise.Smtp:” Error?

This error essentially means that you do not have an SMTP/Email destination configured on the job server that your job or action is attempting to use. In some cases, your job may not even being trying to send email to anyone and you will still get this error if you have not configured an SMTP/Email destination for the job server being used. In XI R2 you need to be sure that the destination is enabled as well as configured. In XI 3 your will need to add it as it is not there by default and this will also enable it. Don’t forget the “Destination Job Server” as well as this one handles non-scheduled job, such as distributions straight from InfoView (I think). Also since jobs are assigned seemingly on a random basis, if your cluster has multiple job servers check them (or the specific job error) to pinpoint to trouble-maker.

How do I fix this error?

Easy, just configure an SMTP or Email destination on the job server (CMC > Servers > Job Server > Destinations). I highly recommend that you configure the SMTP/Email destination on all reporting job server (WebI, DeskI, Crystal), adaptive jobs servers (XI 3), and destination job servers. The only information that you must enter is domain, server name and port; however, your email admins might require the user id and password fields as well. Make certain that in XI R2 the destination is enabled too. This should stop the error; however, you might want to add more default information for the From/To email fields to prevent errors caused by users who will accept the defaults. I usually use the variable for the users email ID in both fields.


Cleanly Stopping and Starting Business Objects Servers

I really cannot explain why it is that I have NEVER seen any documentation that advises Business Objects XI administrators on how to stop and start Business Objects properly. For those of us running part of our business on BO XI we are very concerned about minimizing errors for users and scheduled jobs while we are restarting Business Objects.

The Cleanest Method to Stop a Business Objects Environment

I have discussed this topic with my senior engineers and the following is based on the input I received from them and from my own experience and knowledge. I will label optional steps that will make your stop and start as graceful as possible; these are optional, but they are the best method to follow if you have the time to do so. Also when following the steps make certain that the step is complete and the server is completely stopped/started before proceeding to the next step. Additionally if you have a clustered environment, and you should if at all possible, then you can stop all servers of the same kind in any order or even simultaneously.:

  1. Please first make note of any pre-existing disabled servers to be sure that you do not enable them mistakenly later on. Screenshots are useful and fast, just be sure to save them.
  2. Shutdown your web/application layer. This will stop your users from launching new jobs and from getting strange errors as you are in the midst of your shutdown. You could just disable a proxy server (if you use one to cut off the access, but (Graceful Option) you may want to completely flush the system by completely stopping the web server.
  3. (Graceful Option) Through the Central Management Console (CMC) or through the Central Configuration Manager (CCM) Disable all BO servers except for the CMS, Input FRS, Output FRS, and Destination servers.
  4. (Graceful Option) Wait as long as reasonable/acceptable or until all user sessions/requests have cleared the disabled servers before proceeding to the next step. Usually 30 to 60 minutes is sufficient for any valid threads being processed.
  5. Shutdown the Event Servers (use CCM or CMC). This would stop any related scheduled jobs from launching.
  6. Shutdown all Job Servers (WebI, DeskI, Program…).
  7. Shutdown the Destination Servers.
  8. Shutdown all Report Servers (WebI, DeskI, Crystal…).
  9. Shutdown any other non-CMS Servers that are still up and running.
  10. Shutdown CMS. CMS should always be last. This is essential and it will make your CMS shutdown go much faster and more smoothly. It may also help reveal any problems that your CMS may be having (for example, if it won’t shutdown you’ll know it is not because of any other lingering servers in the cluster).
  11. With the CMS completely shutdown you are official and completely down.

The Cleanest Method to Start a Business Objects Environment

It is assumed that EVERYTHING is down prior to beginning these steps. If your environment is only partially down we strongly recommend that you first shut it down completely before attempting a start/restart. You want to have a clean environment so do yourself and your users this favor. When starting groups of the same kind of server you can start them one by one or simultaneously, jsut be sure that all are started before proceeding to the next step. (Graceful Option) If you disabled any servers prior to the shutdown (as part of a graceful shutdown) then you should enable them immediately after they have been started:

  1. Start the CMS servers. This will take a little while depending mostly on the number of objects in your environment.
  2. Start Destination Servers, Input FRS, and Output FRS.
  3. Start Event Servers. Also as a side note, please be aware that Event Servers must always be restarted following the restart of any CMS in the cluster.
  4. Start all Report Servers.
  5. Start all Job Servers.
  6. Start any other servers that have not yet been started.
  7. Start your web/application layer.
  8. The Value of the (Graceful Stop/Start Method)

    Disabling Business Objects XI servers allows the servers to retain and complete their current threads/work, but it stops it from accepting any new work. Nevertheless, this requires caution. If users retain access to the environment (web and application layer are up) while you are disabling servers and you disable ALL servers, or most of them to a point below capacity demands, then you will cause errors for users! Therefore, if the users do retain access to the environment disabling servers would only be done partially to the collection of similar servers (with reason). Also do not forget to enable the servers after the servers are restarted!!!

    Please also see the article “The Best Way to Stop a Business Objects Server“.


CMS Cluster Summary and the CMSClusterMembers Registry Key

A “CMS Cluster” is a group of Business Objects XI Central Management Servers (abbreviated CMS, which is a BO service\daemon) that are interrelated and connected so that they may work in conjunction to manage the various other BO servers and provide most of the basic functionality of Business Objects. Clustering them allows for greater capacity management (each Central Management Server can generally support about 500 to 600 concurrent users, based on usage) and fail-over capability. In other words, having a CMS cluster consisting of at least 2 CMS is a VERY intelligent design decision for any Business Objects XI environment requiring any fault tolerance.

Creating a CMS cluster is not too complicated, but for now outside the scope of this article. You should understand that pretty much every other BO service will benefit by being aware of this CMS Cluster. The cluster name is defined in the specifications of each server’s CCM configuration (BusinessObjects XI R2) or that of its Server Intelligence Agent (Business Objects XI 3.X). The way that the BO server is aware of the members of the CMS cluster is through server operating system registry key. The name and path of this key on the Windows OS is:

HKEY_LOCAL_MACHINE\SOFTWARE\\Business Objects\Suite 11.5\Enterprise\CMSClusterMembers

One thing important to note about this key is that it is self-maintained. If a CMS is joined or removed from the CMS Cluster than the other BO servers running on a node will communicate with the CMS Cluster and update the registry key to reflect the valid members of the CMS Cluster. Now this is not exactly real-time updating, but rather it occurs at start-up of the BO server (I mean a service, such as Web Intelligence Report Server) or even at enabling of a disabled server.

Reflecting on what I’ve just written I a reminded that it is a good thing to create a CMS Cluster that only contains one CMS. There are no negative impacts that I know of and this allows for scalability as you can easily add in a CMS to the cluster with this already configured.


Sizing Limits to Web Intelligence Report Server Maximum Simultaneous Connections

In Business Objects XI R2 newly created Web Intelligence Report Servers default to 50 “Maximum Simultaneous Connections” (editable in the Central Management Console, or CMC). In Business Objects XI 3.X the “Maximum Simultaneous Connections” setting is defaulted to 100! Can we read anything in to these changes in default settings? Do the default settings mean anything at all with regards to the settings you should have on your system?

Sizing Limits to Maximum Simultaneous Connections

General consensus of our sources tell us that XI 3.X is better coded and can handle more connections than XIR2, with regards to WebI Report Servers. Nevertheless, it would be quite a leap to say that all other things as equal as possible that XI 3.X WebI Report Servers can handle twice as much traffic. Seriously, don’t count on it.

I feel I should add personal experience and best practice here. I see the default setting for “Maximum Simultaneous Connections” on the WebI Report Server as a maximum setting. I have personally never exceeded it nor witness it exceeded by anyone. It is generally held that if you need more Simultaneous Connections then you ought to add another WebI Report Server to your environment. Of course, keep in mind that SAP Business Objects’ general guideline is that you have no more than 1 Web Intelligence Report Server per available CPU core (for example, a server with 4 quad-core CPUs has 16 CPU cores); so there is a limit there too.

Real-World Web Intelligence Report Server Sizing

A production system will generally run better having more Web Intelligence Report Servers with lower Maximum Simultaneous Connections. For example, a server with 4 dual-core CPUs would run better having 8 WebI Rpt Servers each set at 30 Maximum Simultaneous Connections than it would having 4 WebI Rpt Servers each set at 60 Maximum Simultaneous Connections in CMC. In the real-world tuning and balancing usually are based on observed performance within configuration guidelines.

To get your sizing in the right place you should know what you maximum concurrent users are (logged-in users plus concurrent schedule jobs). This number is essentially how many Maximum Simultaneous Connections you will need. So let’s say you never have more than 100 concurrent users, but you can at those peak times also have 25 scheduled jobs. Keep in mind that most users will only do one process at a time, but some like me will be refreshing one report while editing another simultaneously. A scheduled job will always only be one connection. So you can safely say that you require only 150 simultaneous connections (with some wiggle room).

Now your server had only 4 CPU cores in it. So this one is easy 150 divided by 4 will give you 37.5. Round that up, because I suggest you have at least 150 and that you keep the same number on each WebI Report Server. So you can set each one’s “Maximum Simultaneous Connections” to 38 using the CMC. In XIR2 this might be pushing the limits, but in Business Objects XI 3.X this should be a comfortable setting.


TRUTH: Business Objects Does Not Create an Excel File, Help!

A couple weeks ago we received the best email question so far. Not only did it ask for more details with regards to one of the articles, but it provided insights worthy of making it its very own standalone article. Truthfully, I would like to publish it here to share the knowledge contained inside (this is always the best way to answer questions sent to us), but also to hopefully bring visibility to a very worthy question that you may be able to answer. Please read this one, it is good, and provide any comments or questions you might had in the comments below.

Our Guest Author wrote the following [minimal edits for context clarification from Julian are in brackets]:

Subject: [Excel] Format issues when Schedule a DESKI report in BOXIR2 SP3

We are trying to schedule a DESKI Report 3 times a week in Excel format to our clients. DESKI report has 1 data provider and 1 report tab only. We are on BOXIR2 SP3.

[A client] has an automated process, which reads the files we send and save it somewhere. They have a problem in reading Excel file which we send it through our BO scheduler. I tried to schedule DESKI document through InfoView using both SMTP and FTP [delivery] options.

From the InfoView -> scheduler
1. Excel format is generating Excel readable file — but they want exact Excel file.
2. Text file format is generating ‘Tab’ delimiter file
3. There is no option for CSV from scheduler [link to related article]

I am really kind of stuck in the middle (between clients, business users, and my manager). Clients want either an Exact Excel file or CSV file on a schedule basis. As there is no other way to schedule a report in CSV Format [link to related article], we have to write macros/scripts to do this. Which I am ready to do, [but] our management and team don’t want to do this workaround. [They want to] avoid macros as it will increase maintenance and users have to depend on IT for this.

New Knowledge Alert – Business Objects Cannot Create True Excel Files, only Excel Readable Files

I have opened a ticket with BO support and this is the answer I got from them.

Business Objects uses its own dll files for exporting a report to an excel format. The file created is not a native excel file and is simply excel readable.

Any file converted to excel using a tool other than excel will always create excel readable file which would be different (but not too much) from the native one created in Microsoft Excel.

Business Objects does not require Microsoft to be installed for this conversion to take place as it relies on its internal files for the conversion. BusinessObjects is designed only for creating the reports, though it can export the reports to the other formats.

But since all the exported files contain similar information such that Microsoft Excel can interpret and render the files, your module should be able to access it. The files exported from Business Objects would not differ greatly from an excel file created in Microsoft. I am not sure what these internal differences would be.

[The following response captures the client's requirement/comments]:

I think we are stuck in this issue now because [BO] was intended to create an “Excel-readable” file, not create an Excel file. My Java module [is] trying to read an Excel file, not an Excel readable file. There [is] nothing wrong at both ends.

Unfortunately, the data file just cannot serve the purpose that I am looking for. We would need to find some other options now.
I am not sure if [BO] is able to create a “CSV” file? This is a general purpose type of file format and would not have any format issue in reading. Also, you did provide a TEXT file for my testing, but it’s not a fixed length TEXT file. Seems that tab was used as a delimiter in that text file. I wonder if you are able to create a text file without delimiter?

I know that we can save a report in CSV format also in a fixed length text format – through DESKTOP Intelligence
but is there a way to schedule this.

Is a schedule CSV option available in BOXIR3.1???

Please let me know if there is a way to schedule a DESKI report in CSV format.

Responses from BusinessObjectsTips.com’s Julian

The more I think about this I have to say that macros are the only solution that will meet the needs client, unless they can somehow do SDK integration of some sort and pull the data right off the report.

Another solution might be to create an Excel “converter” application. This could be a standalone Excel file with a macro in it that loads BO’s native Excel readable format and outputs a true Excel format file. Perhaps a standalone executable would be better because it would allow for scheduling (perhaps using a BO Program Object). I don’t really know how to create such an application, but this actually would not require any BO skills.

To the author, please share your progress with us all. To the rest of our audience please share your ideas and comments. Thanks!


Can I Connect/Use Oracle 11g Database with Business Objects XI?

The answer is “Yes”, but it depends on which version of BOXI you are running.

Business Objects Enterprise XI Release 2

Any version of BOXI R2 equal to or greater than Business Objects XI R2 Service Pack 5 includes an Oracle 11g driver. However, if you find your instance is still lurking below SP5 you are not without hope. According to Oracle, 10g drivers can successfully be used to connect to Oracle 11g databases. Business Objects does not support using R2 SP4, or lower, to connect to and Oracle 11g database, but that doesn’t mean that you can’t do it. It only means they won’t take any “Customer Messages” on any issues related to such connections, unless the issues can be recreated on database supported for your BO XI service pack level.

Be sure to check your service pack’s “Support Platforms” for the particular supported implementation of Oracle 11g middleware. For example, XI 3.1 SP2 states clearly for Linux/Unix machines running CMS you must install Oracle 10.2 middleware to connect to your Oracle 11.1 database. :-)

Business Objects Enterprise XI 3.X

Starting with Business Objects XI Release 3.1 Business Objects has included an Oracle 11g driver. Now if you are on XI 3.0 and you can’t jump to 3.1 just yet, you might want to borrow a trick from Administrator’s of XIR2 systems lower than XI R2 SP5 and use an Oracle 10g driver to connect to that cutting edge 11g database. Just don’t expect BO to support you on that venture.


Querying the Busines Objects XI CMS InfoStore Database Tables

The question has come to my mind many times over the years and this month it has come to my inbox.
Thanks to Pluto for inspiring me to write this article.

The question: Is it possible to peer into the Business Objects XI CMS InfoStore (a.k.a. database repository) without Query Builder or the BOXI SDK????

The answer: No

All of my research and experience tells me the following:
Much of the meta data, the useful part especially, is stored in the CMS InfoStore in an encrypted binary format. No one has been able to decrypt this format yet, but I can’t really say that anyone has tried very hard. I certainly haven’t.

Some Things You Can Do with the CMS InfoStore’s Database Tables

The CMS InfoStore is mostly held in the database table named “CMS_INFOOBJECTS5″. Some other less significant data is held in the following tables: CMS_RELATIONS5, CMS_IDNUMBERS5, CMS_ALIASES5, and CMS_VERSION_INFO.

The structure of the CMS_INFOOBJECTS5 table in Oracle is as follows:

OBJECTID INTEGER NOT NULL,
PARENTID INTEGER NOT NULL,
TYPEID INTEGER NOT NULL,
OWNERID INTEGER NOT NULL,
LASTMODIFYTIME VARCHAR2(32 BYTE) NOT NULL,
OBJFLAGS INTEGER NOT NULL,
USERFLAGS INTEGER,
SCHEDULESTATUS INTEGER,
NEXTRUNTIME VARCHAR2(32 BYTE),
ALIASES RAW(255),
CRC VARCHAR2(32 BYTE) NOT NULL,
PROPERTIES BLOB NOT NULL,
SI_GUID VARCHAR2(56 BYTE),
SI_CUID VARCHAR2(56 BYTE),
SI_RUID VARCHAR2(56 BYTE),
SI_INSTANCE_OBJECT INTEGER,
SI_PLUGIN_OBJECT INTEGER,
SI_TABLE INTEGER,
SI_HIDDEN_OBJECT INTEGER,
SI_NAMEDUSER INTEGER,
SI_RECURRING INTEGER,
SI_RUNNABLE_OBJECT INTEGER,
SI_TYPEID_MACHINE INTEGER,
SI_KEYWORD VARCHAR2(255 BYTE),
SI_KEYWORDISTRUNCATED INTEGER,
LOV_KEY VARCHAR2(18 BYTE),
OBJNAME VARCHAR2(255 BYTE),
OBJNAMEISTRUNCATED INTEGER

The “properties”, “aliases”, and “objname” fields are where most of the goodies are to be found and these are the fields that are encrypted or in some way pretty much unusable to us without the SDK or Query Builder.

A New Hope for CMS_INFOOBJECTS5

Don’t completely give up on querying this table directly. There are still quite a few valuable data that can be retrieved from the table. Firstly, you should know that the following fields are indexed and there for with a large CMS InfoStore database you will want to use these for filtering your query:

PARENTID
OWNERID
TYPEID
LASTMODIFYTIME
NEXTRUNTIME
SCHEDULESTATUS
OBJECTID
SI_GUID
SI_CUID
SI_RUID
SI_INSTANCE_OBJECT
SI_PLUGIN_OBJECT
SI_TABLE
SI_HIDDEN_OBJECT
SI_NAMEDUSER
SI_RECURRING
SI_RUNNABLE_OBJECT
SI_TYPEID_MACHINE
SI_KEYWORD
SI_KEYWORDISTRUNCATED
LOV_KEY
OBJNAME (this is encrypted though)
OBJNAMEISTRUNCATED

Not all of these fields will have data, but some will and those that sporadically have data might meet your needs perfectly. I don’t really have a strong background in querying this table directly. So we are going to have to crack this nut together. Hopefully we can share our progress in the comments of this post and through updates from me to this article.

A Sample Use of a Direct Query on the CMS InfoStore

For example, I may want to extract a list of all si_cuid (the most unique identifier of an object) and objectid for objects that were created or modified on January 24th. To do this I would use the following query:

SELECT
objectid,
si_cuid
FROM
CMS_INFOOBJECTS5
WHERE
lastmodifytime LIKE ('2009 01 24%')

If you look to the table structure you will see that the field lastmodifytime is of a character type and therefore it can be queried as presented above.

Why would you want to do this query directly on the database and not in Business Objects’ Query Builder?

Short answer: performance and possibility. What I mean to say is that you can control more precisely the performance of the query you write against the table. In fact, a similar query done through Query Builder might perform so slow that you it would not be possible except if you ran it directly against the database table. The truth is that many valid reasons to directly query the database will still end up with you taking the output of that query and then running it through the SDK or Query Builder to obtain all of the properties corresponding to that output.

What other database tables can I query?

CMS_RELATIONS5 and CMS_VERISON_INFO seem to have the only other bit of useful data. CMS_VERSION_INFO has a single row with the repositories version info; I am not certain that you can detect service pack or fix pack level here, in fact, I think you cannot. The CMS_RELATIONS5 table seems to be interesting, but I have not come up with a useful reason to query it beyond tinkering.

For your reference the CMS_RELATIONS5 table has the following structure in Oracle:

PARENTID INTEGER NOT NULL,
CHILDID INTEGER NOT NULL,
ISMEMBER INTEGER NOT NULL,
ORDINAL INTEGER,
RELATIONSHIPID INTEGER NOT NULL

None of the data appears to be encrypted. It also appears to have almost a 1-to-1 ratio between its record count and the count of the objects in the repository as reported in Business Objects Central Management Console. The value of this table might increase if we were to discover the meaning of different relationshipid values.

Conclusion: Where do we go from here?

I feel that I have only given you enough information to advance your tinkering on the true back-end. Honestly, this is a new frontier for me. I hope to post more information here as I find the time to experiment with directly with the database or if I hear from anyone else that has experience they would like to share. I invite you to share your findings as you play with querying the database. Use BO Query Builder concurrently to help you understand more about what you are seeing. If you find you need some help with Query Builder then I do recommend that you take a look at our Business Objects Query Builder Guide


Business Objects Classic Logging and Standard Tracing

If you have ever had a serious issue with your Business Objects environment that wasn’t easily fixed by a service pack, fix pack, or limited availability fix then you probably have had to enable logging on some or even all of your BusinessObjects servers. This is also frequently referred to as “tracing”. I’d like to discuss this briefly, but I want to say up-front that this article is not intended to replace any instructions you receive from SAP BO. Hopefully, it will just confirm information you receive from them, give you something to experiment with, or even prompt some deeper discussion between you and your BO Support engineer.

-Trace, or Dash Trace

I believe that -Trace is new to BO with the roll-out of BOXI, or Business Objects XI. My sources say that it comes from the “Crystal” technology and their for it has its own features and limitations. For this reason it may be especially useful on a BO WebI Report Server server with a particular issue, but on a different environment with a different Web Intelligence Report Server problem it may be useless. In my experience “-trace” can drastically impact performance depending on usage of the BO server and the limiters placed on the “-trace“.

It is called “-trace” because that is the name of the parameter that is used in the BO server’s command line to enable the tracing or logging. By the way, the command line parameters of BO servers/services are edited through CCM on the server. The parameter itself accepts no settings, but I believe that additional parameters can place configurations and limits on the trace logging (for example, “-maxlogfilesize“).

All of the tracing log files will be placed in the “\Program Files\Business Objects\BusinessObjects Enterprise 11.5\Logging” directory. So this can be a problem if the hard drive to which BO is installed does not have much room on it. It seems that by default BO servers are always doing some light tracing/logging to this folder. Once you begin “-trace” logging, you should see a huge spike in the file sizes and the file names should correspond to their servers more or less.

Business Objects Classic Logging, BO Classic Logging

Although BO was migrated to the Crystal platform we know that some fundamentals and tools remained virtually unchanged (for example Designer). Apparently under the hood there are still some things that can only be examined with what is now called “BO Classic Logging”. Apparently this is usually only for servers such as WebI Report Servers.

BO Classic Trace Logging is enabled through a collection of manual configurations on the server. The settings below are representative of possible settings, an example. If you are testing this out you could use these settings, but I would not place them in your “production” environment without consulting BO or some additional authority.


Create the following environment variables on the server:

  1. BO_TRACE_CONFIGFILE
    Set this variable equal to the complete path to a file on your server, such as C:\Logs\BO_Trace.ini
  2. BO_TRACE_LOGDIR
    Set this variable equal to the complete path to a folder on your server, such as C:\Logs





Create the following environment variables on the server:

  1. Create a file named “BO_Trace.ini”. I think it can have any name that corresponds to the environment variable value and it must be placed in the location specified by the environment vairable value as well.
  2. In the file place the following code:
    if (name == "busobj") {
    active = true;
    size = 100 * 1000;
    keep = true;
    importance = xs;
    }

With either flavor of tracing or logging you will need to stop and start the affected BO servers in order to have the tracing take effect. In fact, to “-trace” logging you will need to stop the service first to make the command line parameter addition. You will need to monitor disk space constantly so that this doesn’t bring down your Business Objects environment. Since these are text files, the files compress rather well. Expect many similar sized files that have the start time/date stamp in the file name. Keep in mind that these will be on the server’s timezone and a file dated in the file name as Jan 19th can easily have data for Jan 19th, 20th, and 21st depending on your environment’s activity.

Note: Watch the sub-directory that is created with the name “wicdztrace”. This directory fills up with lots and lots of small files. They are a mess and will need to me deleted often.

Conclusions

Remember, now you know enough to be dangerous. I can’t support you if you crash your system with this. Test it out and engage BO and demand that they help you configure your logging to meet their needs and yours.


How Do I Run a Report Against a Specific Job or Report Server? Easy!

There will come a time when for some unforeseeable reason you will want to run a particular report against a particular report server or job server, or both. When that time comes I hope you know how to make it happen or that you can easily find this article.

Why Would You Want to Run a Report Against a Specific Job or Report Server?

Usually for debugging purposes this topic comes up. For example you have logging configured on a certain WebI Report Server and now you want to force reports to run on it. You could also want to do this because that Report Server has a particular configuration you want to test. Perhaps you want to direct certain reports to certain report and job servers in order to do your own load balancing in scheduling some intense reports. One of these reasons might be part of the reason, but I would love to hear your comments on other good reasons.

How do you force a report to run of a Business Objects report server or job server?

This is rather easy once you know where to configure it and you have some Server Groups set up.

  1. Log in to the Central Management Console (CMC): this is where many things start and in this case InfoView will not help you to set any part of this up, you need CMC access.
  2. Create a Server Group: Go to the Server Groups section of CMC and create a new SG. After you create the SG you need to assign your targeted servers to it by clicking the “Servers” tab and clicking the “Add/Remove Servers…” button
  3. Assign BO Servers to the New Server Groups

    Assign BO Servers to the New Server Groups

  4. Locate the Desired Report:: The easiest way is to use the “Folders” section to navigate to the report in CMC, or use the “Objects” section to search for it. Once located click on the report.
  5. find BO report through \"Folders\" section
  6. Click on the “Process” tab: yeah, do that and then you will see where the power of this often ignored tab comes from. This is where the magic happens. Remember we are still using the Central Management Console.
  7. The \"Processes\" tab
  8. Make Your Selections: You will want to almost always use the “Only use servers belonging to the selected group” option, for obvious reasons. In the corresponding drop-down box, locate the server group that you want to use. Only one server group is permitted here, but a server group can have pretty much any number of servers in it. The top setting is for scheduling only; I suggest you set this even if you don’t plan on scheduling, but your requirements may dictate otherwise. The bottom setting is for both interactive refresh and report editing (such as the JAva Report Panel for WebI Reports).
  9. Set your server groups here

    Set your server groups here

Now to Test it Out!

Ok, now you are cooking with gas! Give it a try. If you get errors, go back and check the Server Group or the assignments to the server group. If the SG is empty you WILL get errors. Sometimes errors tell you that the something is wrong with the server, such as it is not started. If a schedule stays in “Pending” status for very long this may mean that you have not added both a Job Server and a Report Server to the server group. It all depends. Experiment, observe, and learn.


The Best Way to Stop a Business Objects Server

Minimal Impact of Administrative Actions on BOXI

I would like to think that I am unique in many ways, but I think that I am very similar to others when it comes to my desire to minimize the impact of my administrative actions on my Business Objects XI instances. One way that I accomplish this is to carefully shutdown Business Objects servers in a very particular and simple manner.

Changes to Web Intelligence Report Server Require Restart

From time to time we all make changes to our Business Objects environment. Frequently I find myself making changes to the the Web Intelligence Report Servers (WIRS). Whether it is tweaking command-line parameters, CMC properties, logging status, making some obscure registry setting, or even patching DLLs; I am changing my WIRS and I need to restart it in order for the change to take effect. In some cases, my client runs 24/7 and has no real downtime and in other cases I need to make the change immediately and I need them to take effect yesterday. ;-)

The Cleanest Restart You Can Ever Perform

In most cases the changes I make will not take effect without a restart. However, if I go directly to the Central Configuration Manager (CCM) and just stop the server(s) and then restart it, any reports (edits, paging, refreshes, etc.) will fail on the user’s side (or for the scheduled job). So what can I do to guarantee this does not happen??? Disable the server. Wait. Stop server. Restart Server. Enable the server.

Detailed Cleanest BO Server Stopping Procedure

  1. Disable the server: do this either in the Central Management Console (CMC) or in CCM, which ever you prefer, but I think that internally BO engineers prefer to use the CCM (its the icon with the cylinder and check mark).
  2. Wait: there is no golden rule on how long to wait, any amount of waiting is still better than none. During this period the server is finishing whatever work it was assigned and the CMS is not assigning it any new requests. You can observe this on the metrics tab of the CMC page for the server (if your server has metrics). I generally wait 30 minutes and I watch the CPU utilization (CPU time) of the WIRS’s process (yes, in Windows) to see that it is dormant.
  3. Stop the server: this one is easy. Just go to the CCM and stop the server you are targeting. You can do this from any server in the cluster. You should watch the executable to be certain that it goes away, disappears, or dies.
  4. Restart the server: Again stay in CCM, allow for at least 15 seconds from the stop, but this will depend a lot on how long you waited since the disabling of the server, I mean if it still has any active threads it will take longer to stop (see previous step for proper shutdown before restart). Allow the server to get fully started and registered with the CMS.
  5. Enable the server: again use CCM or CMC to do this. I suggest you make sure the server is started for a period of 30 seconds before you enable it and let the CMS have it back for abuse.

Note: I believe this same technique should work well for all Business Objects server, not just Web Intelligence Report Servers.

Please let us all know if you have any comments, suggestions, or anything else on your mind loosely related to this topic by leaving a comment.


BO InfoView WebI Session Timeout = Developer’s Worst Enemy

Business Objects has been encouraging report writers/developers to stop using the “full-client” and start using WebI. There are quite a few obstacles to overcome to be able to make the switch to WebI (training, functionality adjustment, server capacity planning, etc.), but perhaps the most difficult adjustment is learning to development under a timed session.

For many reasons Business Objects administrators configure their systems to timeout a web session and an InfoView session after a certain period of inactivity. With finite resources, which we all definitely have, this is always a good idea. However, this limiting concept has two problems. The first issue is that “full-client”, ZABO, or Desktop Intelligence developers are used to working in a virtually limitless development environment: their own desktop PC. The second problem is that system administrators need to find just the right balance between flexible the valid and acceptable dormant session limits and the obvious session abandonment.

Business Objects Administrator Settings

When Business Objects system admins find that magical median, which will be different for every user community, they need to set it at a few different places:

  1. The web server “connection timeout” setting should be increased first. This one is usually stored in seconds, not minutes.
  2. The InfoView application within the web server should also have its “Session Timeout” value increased.
  3. The web.config file also needs an update to the “” section, setting “” (using the number of seconds in place of the “#” character.

BusinessObjects Report Developer Adjustments

Report developers or writers, including ad-hoc report writers, will need to adjust their methods and habits. Initially, business objects report developers will assume that as long as they save before any periods of inactivity they are safe. However, they will face the harsh facts of this assumption if they are working on the query the whole time.

In BO XIR2 editing the query of a Web Intelligence report does not reset the session timeout timer. Therefore it is entirely possible for a developer to be actively developing a report’s query and find that their session is lost, along with all of their work. In fact, in the WebI java editor panel there are many actions that are registered only on the client and they are not communicated to the server until a logging action takes place such as saving a document. Among these actions you may find general formatting, query editing, and even adding fields to a report.

The safest bet is to require all of your report developers to develop a habit of saving their report every 5 minutes. This will certainly reset the timeout timer and it will ensure that no report development work is lost. From my own personal experience I would say that I have probably lost about 10 to 20 hours of work because of lost session.

Enhancement Request for Business Objects XI R2

To be honest, I would like to see BO add some functionality to the report editor and even InfoView that would help avoid this issue. They could implement an auto-save function. Or perhaps a pop-up box prompt which warns the report developer that they are about to lose their session. Either one would be a wonderful improvement and would probably save BO users thousands of lost hours of work. Until then save every 5 minutes!


Business Objects XIR2 SP4 Bug: Schedules Pending, Job Server Scheduling Dead

Breaking News

I have some breaking news, a scoop perhaps, on a new bug that may only impact some (not all) innocent Business Objects XIR2 SP4 shops. Apparently, my contacts tell me that within the last week, Business Objects has internally identified and even resolved a bug that can wreak havoc on the unknowing BO XIR2 users out there who make the leap to Service Pack 4 (SP4).

Symptoms of the Bug: All Schedules Pending

It seems that the bug causes a loss of communication between the BO XIR2 CMS server(s) and the job server(s). The strange part is that the only detectable error or problem is that suddenly no scheduled jobs process; they all go to an eternal “Pending” status. Every Job Server’s scheduling function ceases to function. Even stranger is that fact that this bug does not effect all Business Objects XIR2 SP4 installations. Some experience the issue and others do not. Some assume that the SP4 install may have changed their configuration or their security and caused the issue; however, it seems that all settings stayed unchanged (good!), but the job servers just ceased to do their job (very bad!).

No Fix Until Fix Pack 4.5

BO just released Fix Pack 4.3 for SP4 and the fix to this issue was not included. My resources tell me that it is planned for inclusion in BO XIR2 Fix Pack 4.5. I am not certain what the due date is for FP4.5, but I would imagine that is not going to be available until after Columbus Day and probably not until after Halloween.

Rethink Your Planned BO XIR2 SP4 Upgrade

If you are thinking about installing SP4 on your Business Objects XIR2 system I would encourage you to rethink this plan. Could your users accept the new functionality of completely disabled scheduling? I doubt it. Of course, there may be fixes to other functionality in the SP4 upgrade for which you cannot wait. If this is true then you might want to test out the fixed DLL on a test environment. Yes, BusinessObjects has already corrected the issue and released a Limited Availability patch. I have managed to get my hands on the patch info and the patch that BO’s product development group has developed.

Download the BO XIR2 SP4 XIR2.LAFix4.3.3 patch directly from Business Objects

Get the Fix for the BO XIR2 SP4 Bug

On September 24th, BO released a Limited Availability patch. In truth the fix is still considered a “beta” fix and so it comes with the standard disclaimer. Basically the LA Fix hasn’t been through full regression testing and it may inadvertently introduce other issues. BO Customer Assurance still needs to confirm the issue is fixed by this patch.” That is a pretty big disclaimer, but it is the standard one on such “hot-off-the-press” fixes. If you need this fix then test it yourself.

Regardless, I recommend that you immediately contact your BusinessObjects Account Rep and/or BO Support. The more attention this issue gets the more likely it will be officially fixed sooner.

Download the BO XIR2 SP4 XIR2.LAFix4.3.3 patch directly from Business Objects

My disclaimer: I provide no guarantees or warranties with this patch, just take it as it is. I tested it and it seems to be fine. Others have claimed that it corrected their issue. That is all I can tell you. Good luck. Oh and one last thing… PLEASE backup your SchedulerSubsystem.dll before you install the patch!


Business Objects Enterprise: Java or .NET?

There are a lot of factors that will come into play in deciding how to deploy your Business Objects XI R2 application, that is to say in the decision whether to deploy InfoView in the Java (Apache Tomcat, WebLogic) or .NET (IIS) flavor. There will be many reasons such as available skillsets, technical familiarity, web server restrictions, etc. However, there may be one factor you are not considering… future functionality support!

Another Win for Java

At one point in time Business Objects, the company that is, announced that they would maintain all future released functionality of Business Objects XI in both the .NET and the Java flavor. However, sometime in 2007 it appears that BusinessObjects went back on this commitment. Probably due to the less-than-booming economy BO was faced to make a difficult choice and because of the overwhelming popularity of Java among BO’s customers, the decision was made to focus all of the product roadmap’s enhancements first on Java.

BO’s Stepchild: .NET and IIS

Therefore I suggest you consider this point carefully when making a decision to deploy InfoView on .NET. If you choose to do so you are ignoring the fact that Business Objects is playing favorites. If you select .NET you are selecting the stepchild. Don’t expect enhancements and fixes to be as readily available for your .NET platform as they are and will be for Java. You don’t believe me? Well go ahead and try to install Business Objects XI 3.0 on IIS and .NET. Not going to happen, at least supposedly not until sometime in the second half on 2008. That’s my point and it is just the beginning.

Business Objects XI R2 Java AND .NET?

With Business Objects XI R2 it is possible to actually run both platforms at the same time on IIS and Apache Tomcat, although most BO administrators would probably want to avoid this. However, if you require and SDK interface and you have no Java developers then do you really have a choice? Honestly, many BO administrators are doing this with BOXI R2 and so I would not want to discourage you if you have no other choice.

In the end this is your decision. We just want to be sure that you have this little bit of extra input. We would hate to hear of anyone else having to spend hundreds of person hours moving from the .NET platform to the Java platform because they didn’t know what they were getting in to. Its not that much work to switch you say? The rework can range from SDK rewrites to OpenDocument.aspx updates across every single report that uses OpenDocument. Make your choice wisely, what more can we say?