Posts Tagged ‘Report Server’

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.

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“.

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.

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


Assign BO Servers to the New Server Groups

3. 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.

4. 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.

5. 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).


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.