22 September 2008
Limiting User Sessions in InfoView: Part 1
To license BusinessObjects Enterprise, there are two types of licenses available for purchase, a CPU/Processor License or a Named User License.
A CPU/Processor License is a license that is purchased for every physical processor on the target machine BusinessObjects Enterprise will be deployed on. In essence, it allows you to create an unlimited number of user accounts, or at least as many as the target machine can actually handle assuming that they will all be logging in concurrently.
A Named User License is a license that is purchased for every user account that will be created – notice I said created – for a BusinessObjects Enterprise deployment. So for example, if an organization determines that they will need 100 user accounts, they will need to purchase 100 licenses. So in short, this is limited user license.
So what is the primary difference? If you guessed the price, give yourself a pat on the back. Other acceptable answers include money, Dollars, Euros, and argent for our French friends over at Business Objects – the company, hence the space between the two words – headquarters in France.
The most popular license type is the Named User License because of its attractive pricing options. So more often than not, organization will tend to select it over the CPU/Processor License. The problem with the Named User License is that while legally it requires one license for every user account, in practice it there is nothing to enforce that requirement.
As I have seen for myself, as I am sure others have seen or will see countless times, some organizations will usually buy a limited number of licenses, create a limited number of user accounts, and share them amongst a large number of users. For example, 500 licenses can be purchased to create 500 user accounts and those same 500 user accounts can be shared by 1000 or more users. Surprisingly, BusinessObjects Enterprise will not complain when the same user account is logged in more than once. Business Objects, bless their kind hearts, are sort of depending on organizations to be honest when purchasing a Named User License, but we know better don’t we! Given the rapid decline in modern business ethics lately, that assumption is simply not good enough.
So, is there something we can do about this problem? Is there a way to force BusinessObjects Enterprise to refuse log in attempts for a user account that is already logged in, in effect limiting each user account to one session? You bet there is; otherwise I would have titled this post something else. It requires a little bit of thinking and usage of BusinessObjects’ excellent SDK (Software Development Kit). I will get into the details on how to implement this in Part 2 of this post series.
Limiting User Sessions in InfoView: Part 1
For those of you that are not familiar with BusinessObjects Enterprise’s license types, here is a quick shocker: there is no way to limit the number of user sessions throughout BusinessObjects Enterprise! What does that mean? To find the answer, we need to quickly summarize the license types available.
To license BusinessObjects Enterprise, there are two types of licenses available for purchase, a CPU/Processor License or a Named User License.
A CPU/Processor License is a license that is purchased for every physical processor on the target machine BusinessObjects Enterprise will be deployed on. In essence, it allows you to create an unlimited number of user accounts, or at least as many as the target machine can actually handle assuming that they will all be logging in concurrently.
A Named User License is a license that is purchased for every user account that will be created – notice I said created – for a BusinessObjects Enterprise deployment. So for example, if an organization determines that they will need 100 user accounts, they will need to purchase 100 licenses. So in short, this is limited user license.
So what is the primary difference? If you guessed the price, give yourself a pat on the back. Other acceptable answers include money, Dollars, Euros, and argent for our French friends over at Business Objects – the company, hence the space between the two words – headquarters in France.
The most popular license type is the Named User License because of its attractive pricing options. So more often than not, organization will tend to select it over the CPU/Processor License. The problem with the Named User License is that while legally it requires one license for every user account, in practice it there is nothing to enforce that requirement.
As I have seen for myself, as I am sure others have seen or will see countless times, some organizations will usually buy a limited number of licenses, create a limited number of user accounts, and share them amongst a large number of users. For example, 500 licenses can be purchased to create 500 user accounts and those same 500 user accounts can be shared by 1000 or more users. Surprisingly, BusinessObjects Enterprise will not complain when the same user account is logged in more than once. Business Objects, bless their kind hearts, are sort of depending on organizations to be honest when purchasing a Named User License, but we know better don’t we! Given the rapid decline in modern business ethics lately, that assumption is simply not good enough.
So, is there something we can do about this problem? Is there a way to force BusinessObjects Enterprise to refuse log in attempts for a user account that is already logged in, in effect limiting each user account to one session? You bet there is; otherwise I would have titled this post something else. It requires a little bit of thinking and usage of BusinessObjects’ excellent SDK (Software Development Kit). I will get into the details on how to implement this in Part 2 of this post series.
Posted by Ahmed Elgarhy at 2:17 PM
Labels: BusinessObjects Enterprise
2 Comments:
- Vilas Bhosale said...
-
We are waiting for,
Limiting User Sessions in InfoView: Part 2... :) - October 27, 2009 at 3:31 PM
- Ahmed Elgarhy said...
-
Hehe I am glad that you are. I am hoping to get around to writing it soon. I just have to organize all the code samples correctly. I'll try to get to it soon :)
- October 30, 2009 at 2:39 AM
We are waiting for,
ReplyDeleteLimiting User Sessions in InfoView: Part 2... :)
Hehe I am glad that you are. I am hoping to get around to writing it soon. I just have to organize all the code samples correctly. I'll try to get to it soon :)
ReplyDelete