Question

We have a BusinessObjects Enterprise XI server which I believe is similar (if not the same) to Crystal Reports Server 2008.

We have a small number of concurrent licenses, and is has never been a problem before (that we’ve noticed), but lately it seems that the server isn’t getting rid of dead sessions, and is counting them as active still (which is counting against our licensing).

We did not use the Tomcat server for the web presence, so this may be affecting it as well (we are using the web server that comes internally with the server — not sure what it is. Can you tell I inherited this project?)

The only solution I’ve been able to utilize so far is restarting the BoE servers (they are a number of separate applications but I can’t find which manages sessions and so all must be restarted. Gross.

Any idea on where I could start to dig into this? I’ve searched through all manner of documentation but have yet to find the solution.

Thanks in advance for any help you can give!

Answer 1

The license is released when the EnterpriseSession is terminated. However, the EnterpriseSession isn’t terminated when the browser is closed; the user needs to explicitly ‘logoff’ (in ePortfolio/InfoView) to end the session.

You could also shorten length of the default session.

From the BusinessObjects Enterprise XI 3.1 Administrator’s Guide (page 444-445):

Enterprise systems dedicated to serving a large number of users
typically require some form of distributed security. An enterprise
system may require distributed security to support features such the
transfer of trust (the ability to allow another component to act on
behalf of the user) BusinessObjects Enterprise addresses distributed
security by implementing a ticket mechanism (one that is similar to
the Kerberos ticket mechanism). The CMS grants tickets that authorize
components to perform actions on behalf of a particular user. In
BusinessObjects Enterprise, the ticket is referred to as the logon
token.

This logon token is most commonly used over the Web. When a user is
first authenticated by BusinessObjects Enterprise, he or she receives
a logon token from the CMS. The user’s web browser caches this logon
token. When the user makes a new request, other BusinessObjects
Enterprise components can read the logon token from the user’s web
browser.

In general, a session is a client-server connection that enables the
exchange of information between the two computers. A session’s state
is a set of data that describes the session’s attributes, its
configuration, or its content. When you establish a client-server
connection over the Web, the nature of HTTP limits the duration of
each session to a single page of information; thus, your web browser
retains the state of each session in memory only for as long as any
single Web page is displayed. As soon as you move from one web page to
another, the state of the first session is discarded and replaced with
the state of the next session. Consequently, Web sites and Web
applications must somehow store the state of one session if they need
to reuse its information in another.

BusinessObjects Enterprise uses two common methods to store session
state:

• Cookies—A cookie is a small text file that stores session
state on the client side: the user’s web browser caches the cookie for
later use. The BusinessObjects Enterprise logon token is an example of
this method.

• Session variables—A session variable is a portion of memory that
stores session state on the server side. When BusinessObjects
Enterprise grants a user an active identity on the system, information
such as the user’s authentication type is stored in a session
variable. So long as the session is maintained, the system neither has
to prompt the user for the information a second time nor has to repeat
any task that is necessary for the completion of the next request. For
Java deployments, the session is used to handle .jsp requests; for
.NET deployments, the session is used to handle .aspx requests.

Note:

Ideally, the system should preserve the session variable while the
user is active on the system. And, to ensure security and to minimize
resource usage, the system should destroy the session variable as soon
as the user has finished working on the system. However, because the
interaction between a web browser and a web server can be stateless,
it can be difficult to know when users leave the system, if they do
not log off explicitly. To address this issue, BusinessObjects
Enterprise implements session tracking.

The CMS implements a simple tracking algorithm. When a user logs on,
the user is granted a CMS session, which the CMS preserves until the
user logs off, or until the web application server session variable is
released.

The web application server session is designed to notify the CMS on a
recurring basis that it is still active, so the CMS session is
retained so long as the web application server session exists. If the
web application server session fails to communicate with the CMS for a
ten-minute time period, the CMS destroys the CMS session. This handles
scenarios where client-side components shut down irregularly.