Understanding CMS Startup Procedures

by: Joe Roberts, Senior Consultant, BECP

Maintain system data and metadata

Before we can get into the internal details we have to define what the CMS (Central Management Server) does for us. First, and probably foremost in the eyes of most administrators, it creates and manages the Business Objects and Crystal Reports repository (system database). It maintains information on every object, published, imported or created within Business Objects Enterprise. These include:

· Documents (Crystal Reports, Web Intelligence, Desktop Intelligence, Adobe, Word, Excel etc.)

· Dashboard Analytics

· Dashboards

· Folder

· Groups

· Users

· Universes

· Business Views

· Crystal Reports shared objects (SQL Commands, Images, Text Objects, Custom Functions)

· Universe Connections

· Profiles

· Categories

· Inboxes

· Calendars

· Events

Well… you get the idea. Each of these object have numerous properties and attributes all of which are managed by the CMS. The CMS communicates with all applications, both Windows and web, (via the SDK) to deliver information about these objects. The persistence of these objects is maintained through the use of the system database to store and retrieve this information.

Enforce Security

Part of the metadata retained by the CMS would be the security rights for each user on each object. All applications must communicate with the CMS to be able to access any object in Enterprise. That communication includes the enforcement of security set by the system administrator(s). Each action performed by an application will first include a conversation with the CMS to determine if the logged on user has the right to perform that action. If not, the action will be denied. An application developer could produce a poorly written application but they can never obviate security.

Record Audit Information

If you have enabled Auditing, the CMS will be responsible for writing audited actions to the Auditing database. Most of the actions are monitored and recorded by services other than the CMS (Cache Server, Job Server, Web Intelligence Report Server, etc.) but all of them pass that information to the CMS at regular intervals to be written to the Auditing database.

CORBA Name Sever

The CMS is also designated as something called the CORBA Name Server. I’ll let you look up what COBRA stands for yourselves since it really isn’t important to this subject but what CORBA does is very important. CORBA is the heart of Business Objects Enterprise. Without CORBA everything we do in Enterprise would be significantly slow at best and impossible at worst. CORBA is the inter-application communication protocol. I usually explain CORBA as an application specific DNS.

DNS allows computers on a network to register their network information (name, IP address, etc.) then other computers can use DNS to find each other. CORBA allows services within an application to register their network and application specific information with something called the Name Server. The Name Server creates something called the Name Shell which is simply a list of all registered services and their information. It then passes that list, at regular intervals, to all registered services. Those services then use that list to find each other when they require the function that another server provides. If a Cache Server need a report page to send to a viewer it finds a Page Server on that list and communicates directly with that Page Server to get the page created. In Enterprise the Name Server is the CMS. Now remember this, it will be very important later and there will be a test!

CMS Startup

Each time a CMS starts it actually goes through several steps before it is ready for service. This is why, sometimes when you start up the CMS it will go from Red (stopped) to Yellow (setup) to Green (ready). If the CMS is part of a cluster the start up steps vary slightly. Below I have separated the startup procedures into “Single CMS” and “Clustered CMS” so that I can define the difference

Initial Startup

Single CMS

Contact the System Database

The first step in the process will be to establish a connection to the system database. If it can’t for any reason it will shut down immediately.

Create the Run Time Image

The Run Time Image (RTI) is an in memory representation of the system database. The CMS will load as much of the system database into memory as the amount of memory will allow. This setting is actually controlled with a registry setting but is based on the amount of available memory. Once completed it will run primarily using the Run Time Image and will, at regular intervals, write changes back to the system database.

Reconcile Delta Files

During the normal course of business, as changes occur, the CMS modifies the RTI and also writes delta files that represent those RTI changes to temporary disk space on the local hard drive. These files are a backup in case of failure. Should the CMS shutdown unexpectedly it would lose all of the changed information in the RTI; for that reason it records that information in physical delta files. On startup it will look in that temporary directory for delta files. If there are any, then it did not shut down in a controlled fashion. It will use those files to sync the RTI and write that information back to the database for safe keeping.

Establish the CORBA Name Shell list

Next, since it is the CORBA Name Server, it establishes the CORBA Name Shell list and is ready to receive registrations from other services. As those services register, it will add their information to the list. At regular intervals it will pass that list around to all registered services so they can communicate directly. It then established a “heartbeat” to each registered service. At regular intervals it will poll that service to make sure it is still alive. If it can’t communicate with the service it will remove them from the list and circulate an updated list to all other registered services.

If a service tries to register with the CORBA Name Shell before it is ready, the CMS will ignore the request. Don’t worry, the services will try again in a minute or so and again if need be until it is successful.

Ready for Action

Finally it is ready to really go to work.

Clustered CMS

Contact the System Database

The first step is the same in both scenarios. The CMS must establish a connection to the system database. If it cannot for any reason it will shutdown.

Establish communication with other CMS’s

If the CMS is part of a cluster it will then try to contact any other CMSs that are part of the cluster. If it is successful in finding one it will establish a communication thread with that CMS and establish its position in the cluster; if not it will establish itself in position 1 in the cluster. The first CMS to start will always be in position 1. Its position in the cluster isn’t important to you but it does determine the next step for this CMS.

A CMS in position 1

If this is the first CMS in the cluster to start the next steps are exactly the same as the single CMS environment.

Create the Run Time Image

Reconcile Delta Files

Establish the CORBA Name Shell list

Ready for action

Position 2 or later

If other CMS’s in the cluster are running then the steps are basically the same but where it retrieves information from is dramatically different.

Create the Run Time Image

Just like the CMS in position 1, this one must create a Run Time Image. The difference here is that it will not retrieve the data from the database. It will retrieve the Run Time Image from the CMS in position 1. This ensures that both Run Time Images are identical and eliminates errors due to in-transition files.

Reconcile Delta Files

Just like the CMS in position 1 it will look for delta files that have not yet been reconciled with the Run Time Image retrieved from the 1^st server. If it should find any it will update the Run Time Image, notify the other CMS of the changes and write those changes to the system database.

Retrieve the CORBA Name Shell list

Unlike most other communications involving the CMS only one CMS at a time can act as the CORBA Name Server. This CMS will retrieve the Name Shell list from the CMS in position 1. It will receive an updated list, just like all the other services, but will not act as the actual Name Server unless the CMS in position 1 goes down.

Ready for action

Now, finally, we are ready to work.

Now… don’t you have a little bit more respect for the CMS? So, using the information I’ve just given you, let’s examine some of the questions I typically get involving the CMS and see if our new knowledge helps us answer them.

Question: Is there an order I should follow when starting services? (remember how CORBA works?)

Answer: No not really. If the CMS is already up and running when the other services start they will become available sooner but either way all services will eventually register with the Name Shell and be available for services.

Question: I see lots of errors in the Windows Event Log saying several services couldn’t communicate with the CMS. Is this a problem I should be concerned about? (Again, remember how CORBA works?)

Answer: No, the services were ready to go before the Name Shell list was initialized. This is normal. They will keep trying until the can successfully register with the CMS running the Name Server.

Optional Answer: If your CMS has been running for a while, check the error log again. Is the name it shows for the CMS it is trying to contact correct? You might have miss typed the CMS name when creating the service. If you do that it will try again and again, futilely, to contact a non-existent CMS.

Question: I had to restart my Page Server and Cache Server for some maintenance; after I restarted them, I logged in and tried to run a report and an error “Cannot find a server of type Page/Cache Server”. Why is this? I just restarted them. (Ok, this time think about how the Name Shell list propagation works.)

Answer: Don’t worry. When you shut them down the Name Server removed them from the Name Shell list and redistributed that list to all services. Now that you have restarted them they are back on the list but the list just hasn’t been propagated to all services yet. Give it a few minutes and you should be good to go.

Now, see how knowledge is power! I bet you already knew the answers to each of those questions. Well, I’ve overstayed my welcome in this newsletter so maybe next time we can talk about how CMS communicate with each other during the normal course of business and how they protect their data from loss. Until then… thanks.

Go to Top | Return to Newsletter Contents