Separating Authorized User from PVU Users

​Separating Authorized User from PVU Users using Cognos Dispatchers

Many clients have a mix of Cognos BI licenses where they have power users as authorized users that are not restricted by server size and end users that are based on PVU’s which restricts the number of core processors they can leverage. But the question arises, “Is separating authorized user from PVU users difficult?  Can it even be done?  How do I separate my users so the power users can use 32 cores of processing power without exposing me to purchasing PVU licensing for 32 cores for my end users?” Reason being, clients may want to give more power to the “power users” while avoiding extra licensing fees for the end users that are PVU based.  Below I discuss Separating Authorized User from PVU users!

One option is to leverage the Cognos Dispatcher with Routing Rules. The dispatcher serves as the traffic cop to direct requests to the correct server. This would allow you to direct your BI PVU user’s requests to the server that only has the cores for which you own PVU licenses. You can have the dispatcher route the power users that have authorized user rights, therefore are unrestricted in PVUs, to another box that has all the power you need. The result being the “power” users have power, the end users are leveraging the appropriate box and you save money on software or at least reduce the risk of failing an audit. Don’t forget if you have PVU’s and are virtualizing, you may need to have the ILMT tool installed too. (See blog post  about ILMT here.)

Details on the IBM Cognos Dispatcher for the techies in the crowd:

Separating Authorized User from PVU users

“IBM Cognos BI addresses both routing challenges by a software component called the Cognos Dispatcher. The Dispatcher, technically, is a Java Servlet which implies it handles HTML input and generates HTML output. In the case of IBM Cognos BI, the input and output payload is actually using the Simple Object Assess Protocol (SOAP) which again, technically, is XML payload transported over the HTTP protocol.

Each Dispatcher hosts a set of services which are determined by the system components installed in this instance of IBM Cognos BI. The services get registered to the Dispatcher and it's the Dispatcher which controls them. At the same time, the Cognos Dispatcher “knows” which service instances it hosts, hence which types of requests it can serve locally.

When a Cognos Dispatcher is started up, it will register itself with the active Content Manager (CM). It will report the services it hosts and will obtain information about the system from CM. Through this process, each Dispatcher gathers information about all other Dispatchers in the system and the services they host.

While a simple single server environment may be sufficient for testing, production systems usually consist of several installed instances (sometimes called nodes) each running a Dispatcher with its own set of services registered. With multiple nodes, load-balancing and fail-over become possible. The IBM Cognos BI architecture implements this by a logical bus which exists between the Dispatchers on each node. On this logical bus, requests get passed/routed between Dispatchers in a system and eventually to a specific service instance registered with one of the Dispatchers. This process will acknowledge load balancing and service availability.

Clients send requests destined for a certain service to a Dispatcher to get them served. The Dispatchers of a system will ensure the request is routed to an available instance of the requested service which will handle the request and relay back the result to the client.”

Thanks for taking the time to read about Separating Authorized User from PVU users.  Check out this blog on calculating PVU's by clicking here

Note: The information in this blog is for reference purposes and subject to change. Clients may have a unique agreement with IBM; therefore, refer to you IBM Contract for more information.

Leave a Comment

Send this to a friend