Business Objects XI 3.X’s Server Intelligence Agent (SIA)
Business Objects XI 3.0 introduced us to an entirely new architectural concept called the Server Intelligence Agent (SIA). The SIA takes over Business Objects service/server management from the Central Configuration Manager of XI Release 2. When you start a SIA you can configure all, some, or none of the servers contained in/managed by the SIA to also be started. All BO servers in a SIA must belong to the same cluster. A BOXI SIA is much more than a server group, in fact, aside from also providing a grouping of BO servers in CMC it does not behave like a Server Group because you cannot schedule to it or any other such process assignment.
Sorting Through the Confusing Naming Conventions
Business Objects terminology can be a little confusing to those who equate “node” with “server”, “machine”, “host”, or “machine”. In the world of Business Objects XI 3.0 and 3.1 SIA and node have a 1-to-1 relationship. SIA and node even share the same name, so for all intents and purposes they are synonymous. Machine and host are also synonymous; however, in general “host” will be used in CMC. “Server” still refers to a single instance of the Business Objects service run on a host/machine which is a member of a SIA/node. Got it? Good.
Note of PronunciationBy the way, within SAP Business Objects it seems that most people say the word “see-ah” when they speak of Service Intelligence Agents or SIAs. Get used to it, people will pause to think when you say “S-I-A” spelled out (and we don’t want anyone pausing and thinking, do we?).
Managing Your SIA
The Server Intelligence Agent does not have its one graphical use interface (GUI), but parts of it can be managed through CCM, Central Management Console (CMC), and the utility called “ServerConfig” (Unix/Linux only, utility built in CCM for Windows). In the CMC, you should look under “Servers” and you will find the SIA called “Nodes” here.
Naming Your SIA
There is a character limit but I cannot tell you exactly what it is yet. The BO installer does have a 15 character limit, but this is a limit enforced by the installer only and you can always create longer named SIA later. You cannot use spaces, dashes, or periods in your SIAs name. You also cannot start the SIA with a number, but you can use numbers after the first character. I try to name my SIA by its main purpose and I include the short host name as well, such as “cms_myserver”. SIA names will default to the host name or even the host’s fully-qualified domain name.
Porting Your SIA
The default port for a SIA is 6410. In most cases you would want to use this one first. Then if you must add more SIA to the host/machine I suggest following some incremental like 6510, 6610, 6710 or perhaps 7410, 8410, 9410. It really will depend mostly on your hosts available ports. Sticking to tens will make it easier for you to remember in the future and easier for your successors to guess what is going on.
Can 2 SIA Run on the Same Host???
Yes, in fact, you can run many different SIA on the same host and each SIA can either point to the same cluster or possibly to an entirely different cluster. Think about this. It means that if you only had enough machines to stand up one environment, you could put 3 SIA on each machine and point each SIA to a different CMS database and Viola! you have 3 distinct BO XI 3.x environments running on the same hardware. How cool is that? Not so cool if your host doesn’t have enough RAM and CPU, but very cool otherwise.
SIA Warnings
Here are some things to look out for working with Server Intelligence Agents:
- You cannot rename a SIA, but you can create a new one with the name you want, and delete the old one with the name you no longer want.
- When you are installing the BO software for the first time be sure to give a name to the SIA that you want to stick with. If you later delete this SIA and have no SIA with this name present it will cause you trouble when patching the Business Objects Enterprise software. You can later workaround this trouble by updating your “ccm.config” file, but better to prevent than to cure.
- It is always best to shutdown all BO servers/services/executables running on the machine on which you intend to setup a new SIA.
- If you do not have a valid license key loaded (see CMC) then you cannot create more than one SIA in the cluster.
- A SIA can be effectively reinitialized or even redirected to a new cluster if you create a new SIA on the same host with the same SIA name.
- In order to completely delete a SIA from a cluster and from the host you must: (1) stop the SIA and all of its servers on the host, (2) have a SIA with the same name present on both host and CMS
- The easiest way to clean-up orphaned/phantom SIA in the cluster (which have no host) is to add a new SIA to the cluster/CMS and select “noservers” as the kind of SIA you want to create
- Although CMC permits you to manage the servers in your SIA without the SIA running, it is recommended that you do not attempt to add any servers to your SIA unless it is started. Cloning servers to a down SIA can really create a mess.
- If you are creating a SIA that will have a CMS then you will need to enter in the database credentials for the CMS InfoStore database.
- If you are create a SIA that does not include a CMS then you will need to have a CMS running in the cluster where you intend to create the SIA and you will need to be able to provide a BO Administrator user’s login information.
- You cannot delete a SIA that is running. Shut it down completely, make sure all of its servers are stopped, and then try to delete it.
- I do not recommend removing all SIA from a Business Objects host machine. If you want to delete all
- If you use CCM or cmsdbsetup.sh (Linux/UNIX) to copy a CMS to a new database then it will copy all SIA. You will want to be very careful here and leave the source system down until you have deleted all of those copied SIA. How do you delete the SIA??? See above.
Hint: if you need to delete a SIA from a CMS, you can create a noservers SIA of exactly the same on any host machine and that host machine will take over that SIA.
BOXI SIA, the One and Only
Most SAP Business Objects documentation states clearly that the acronym SIA stands for Server Intelligence Agent, but I have seen it also referred to as a “Software Intelligence Agent” in at least one BO document. For example, the Service Pack 3 release notes say, “After installing Service Pack 3 on a system where the Software Intelligence Agent (SIA) node has been removed…” I only mention this in hopes of clarifying any confusion. We can take away at least 3 points from this: (1) There is no such thing as a Software Intelligence Agent. (2) SAP Business Objects documentation is fallible (also it does omit a lot of things too, such as registry information and “Repo Scan”, but I digress). (3) It is not a good idea to delete all SIA from a host machine.
CMS Tuning: ndbqthreads or Number of Requested Database Connections
If you are interested in maximizing the performance of your system please review this article and also its companion: CMS Tuning: maxobjectsincache and MaximumObjectsToKeepInMemory.
Observing/Measuring Tuning Impacts
The parameter discussed in this article requires more tuning and closer observation than other CMS Tuning technique may require. I highly suggest that you do a load test and that you have a serious discussion with your DBA on tuning this parameter.
CMS Database Connections, a.k.a. ndbqthreads
The number of requested database connections is another place you might improve performance. This setting is one that will only improve performance at times of high load on the CMS. It prevents your CMS’s number of connections to its database (a.k.a. CMS InfoStore, metadata repository; don’t confuse this with report data source connections) from becoming a bottleneck to your system. It opens more conduits between the CMS and the CMS’s database. This setting will be limited by the number of connections that your CMS’s database accepts, so be careful not to exceed that number (this is something that a DBA or DBA tools can help determine. This setting is controlled by different parameters depending on your version of Business Objects Enterprise:
BO XI 3.1: System Database Connections Requested (CMC Property)
In Business Objects XI 3.1 you will find in the properties of the CMS (CMC > Servers > Your_CMS > Properties) a parameter/setting named “System Database Connections Requested“. This setting is set to “14″ by default. I have heard that 99 might be the maximum, but your database’s configuration will probably restrict you before you reach 99.
A Quick CMS DB Thread Sizing Calculation
A recommended baseline is to have one connection for every 20 expected peak concurrent users. I am not speaking of the “Concurrent User” versus “Named User” user type, but I am speaking of the max number of users that you expect to access the system concurrently at any one point in time. Take this number and divide it by 20. Now take that number a divide it by the number of CMS that your cluster is running. The final number is the value that you should put in the “System Database Connections Requested” parameter value of each CMS in the cluster. This a good baseline for you to begin testing (testing this one can be elusive and will certainly require DBA skills to detect the activity on all open connections). If the per CMS number you calculated is less than the default 14 then you could reduce this setting and test for any effects; you consume less database connections which other applications or processes might appreciate.
XI R2: ndbqthreads (CMS Command-Line Parameter)
In XIR2 there is this thing called NDBQ threads. According to the Administrator’s Guide the setting exists in BO XI 3.1 as well (although I don’t understand how it plays/conflicts with the “System Database Connections Requested” setting there). The setting is made in the CCM on the command line for the CMS. That parameter is specifically “-ndbqthreads #“. I believe that “2″ is the default setting and I know that “10″ is the maximum (even in XI 3.1 go figure). This can be sized with the same calculation given above, but your limit will still be 10. Given this limit, some Business Objects administrators will choose to add a CMS to the cluster just to be able to add more CMS DB Connections to the cluster. It is possible that the limit of “10″ does not apply to Business Objects XI 3.1 as the Administrator’s Guide states. It certainly would not be the first error/omission in the guide.
CMS Tuning: maxobjectsincache and MaximumObjectsToKeepInMemory
I think all Business Objects administrators and developers share at least one goal; they all want their XI system to perform at the best of its ability to realize its full potential. If you have this goal keep reading and please share any comments you might have as well.
Observing/Measuring Tuning Impacts
Tuning is a very delicate process. We all wish it were easier and more straightforward, but one truth stands in the way of this: the only way to know for certain the impact of any tuning change is to compare the system’s performance before and after the change. This fact present problems on live production systems because the use of the system constantly varies in load volume and the kind of work being done. Formal load testing attempts to overcome this problem using virtual users with tools such as Load Runner; however, while providing consistency these tools often fail to replicate real world usage. In the end, the best a Business Objects administrator can do is to run load tests and also observe live/organic system performance over time.
CMS Parameters Good For Everyone
The truth is that there are some Central Management Server (CMS) settings which given adequate hardware and database configurations, will almost always benefit all Business Objects XI systems. The following is the first one that comes to mind:
Playing With the CMS Cache
The cache is the first place you should focus. No CMS running on average server hardware will be harmed by pushing the memory cache parameter to the maximum and most systems will benefit. The only caveat here is that if your system has limited memory (you will know by watching RAM utilization) you may steal away your BOXI server’s scarce memory which is being used by the CMS to process its very MANY queries. Increasing the maximum number of objects allowed in the CMS memory cache will reduce the number of database calls required and according to the “BusinessObjects Enterprise Adminstrator’s Guide” for BOE XI 3.1 (page 656), this will greatly improve performance! There are two places to configure this setting:
Changing the Business Objects Registry Parameter: MaximumObjectsToKeepInMemory
The registry is one place where the change can be made cleanly and hidden. It is more difficult for someone to change this setting, but it is also more likely to be forgotten and taken for granted when it is placed in the registry. Also, keep in mind, if you recreate a Server Intelligence Agent (SIA) then all registry values will be reset to default settings.
The key to change is under the CMS’s instance and it is named “MaximumObjectsToKeepInMemory“. It is set to 40000 by default. The upper limit, which you should shoot for, is 100000. My server’s underutilized RAM and I wish it were higher.
The CMS Command Line parameter: maxobjectsincache
The other place to enable this parameter is in the CMS server’s command line. This is a less conspicuous place to make the change and I believe that any change made here overrides the corresponding registry parameter. The parameter is called “-maxobjectsincache #” (the admin guide shows it in all lower caps but letter case does not seem to matter). You invoke this by adding in CMC to the command line (or in XIR2 in CCM) the text ” -maxobjectsincache 100000″. Just be sure to place a space between this and any other parameters you might find there already.
Please Note: The command line parameter will override the corresponding registry setting.
Please share any related experiences with this parameter and any comments or questions you may have.
Recommend Reading: CMS Tuning: ndbqthreads or Number of Requested Database Connections
BOXI Grooming: Prune Your Input and Output FRS
Origin of a Cluttered FRS
Business Objects XI has a way of making more sub-folders than files. Seriously, take a close look at your Input and Output File Repository Servers, or rather your FRS on the disk. You will notice a crazy number of folders. As objects get deleted in Business Objects XI their corresponding files are removed from the FRS; however, their sub-folder is not. Since there is nearly a 1 to 1 ratio of files to folders this lack of folder clean-up leads to a lot of empty folders and an inefficient FRS (and any resulting file system back-up).
Keeping Your FRS House in Order
Since you see the most efficient system, you want to clean up this folder mess. Well, BO has a tool for that and you already own it. You can invoke it merely by putting the command-line parameter “-prune” on the Input FRS and the Output FRS.
Making -prune Work for You
I recommend that before you start you shut down your BOXI system’s web front-end. This will keep users from receiving errors or possibly impacting the prune activity. Yes, this requires downtime to do it properly and only experience will tell you how long it takes (depends on how much mess needs to be cleaned and how fast your servers are). Now in CCM shutdown your FRS servers.
Do the next steps one at a time unless you are in a rush. Modify the command-line parameters by appending the parameter “-prune”, be sure to include a space between it and the final parameter that was present before you started. Also you can add “-trace” as a switch to capture a log of the actions.
Completing your FRS Prune
Now start the FRS that you just modified and you will observe that it maintains a “starting” status until it finishes. You can watch it through your servers task manager, top, or other corresponding process manager. You could also watch it through the log file it creates with the included “-trace” parameter. When it finishes, remove the parameters you added and proceed to the next one. If both have completed the prune then you are done and as long as you removed the parameters that you added you are ready to roll.
Additional Information
I suggest counting sub-folders and files before and after. This will help you understand the impact of what you just did. Please keep in mind that the “PRUNE” command does not clean-up any dead pointers (objects in the CMS that lost the files the point to). Prune only cuts the dead branches and it doesn’t touch a single leaf or leafy branch. Enjoy the analogy 
More FRS Prune Resources
Over at “let’s learn business intelligence” they have a good video walk-through of a real, live FRS prune on a BOXI system. Check it out: http://www.letslearnbi.com/2009/05/business-objects-prune-and-trace.html.
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.:
- 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.
- 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.
- (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.
- (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.
- Shutdown the Event Servers (use CCM or CMC). This would stop any related scheduled jobs from launching.
- Shutdown all Job Servers (WebI, DeskI, Program…).
- Shutdown the Destination Servers.
- Shutdown all Report Servers (WebI, DeskI, Crystal…).
- Shutdown any other non-CMS Servers that are still up and running.
- 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).
- 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:
- Start the CMS servers. This will take a little while depending mostly on the number of objects in your environment.
- Start Destination Servers, Input FRS, and Output FRS.
- 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.
- Start all Report Servers.
- Start all Job Servers.
- Start any other servers that have not yet been started.
- 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“.
