Introduction

Purpose

This document is meant to supplement the Security and Administration Guide and Architecture

and Deployment Guide which are part of the IBM Cognos BI product documentation. It will

explain the concept of Dispatcher routing including load balancing and Advanced Routing.

Applicability

The concepts described herein apply to all versions of IBM Cognos 8 BI and IBM Cognos 10 BI.

Exclusions and Exceptions

This document is restricted to Dispatcher based routing and does not touch on Service routing.

The reader is expected to be familiar with the concepts described in the Architecture and

Deployment Guide.

Back to top

Routing in IBM Cognos BI

Routing ? Why ?

IBM Cognos BI is based on a Service Oriented Architecture (SOA). This implies the product

consists of a set of independent services which communicate via SOAP over a network. There

are many different services which all implement different features of the product. Each service

can only serve a certain type of request. This is one of the routing challenges in an SOA, to route

a request to a service which can serve this type of request.

Another aspect of the routing challenges in an SOA is load balancing and/or fail-over. There can

be multiple instances of the same type of service in an overall system. If there are multiple

instances, then either load balancing (each instances get's assigned a configurable percentage of

the requests of that type) or fail-over (requests for a certain type of service get re-routed to an

active instance because another one failed) can happen.

The Dispatcher

Both routing challenges are addressed by a software component called the Dispatcher. The

Dispatcher, technically, is a servlet which handles HTML input and generates HTML output. In

the case of IBM Cognos BI, the input and output payload will actually be SOAP (XML via

HTTP).

Each Dispatcher hosts a set of services which are determined by the system components installed

in this instance of IBM Cognos BI. The services are registered to the Dispatcher and its the

Dispatcher which controls them. At the same time the Dispatcher “knows” which service

instances it hosts and hence which types of requests it can serve locally.

When a 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 “knows” 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 nodes, each running a Dispatcher with it's 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 as this document will explain.

Client requests, either users via their browsers or SDK programs, send requests to a Dispatcher

to get them served. The Dispatchers of a system will ensure the request is routed to a service

instance of the right service type which will handle the request and relay back the result to the

client.

Entry Point Considerations

Because the Dispatcher is a servlet, it must be deployed to a Servlet Container/Java Application

Server, which implies it is located in the Application tier of a classical 3-tier architecture. It's is

considered a potential risk to expose the application tier to end users, so usually as a best

practice, some other component in the web tier like a web server is used to handle the

communication with the external clients.

In the IBM Cognos BI architecture, this is done by the IBM Cognos BI Gateway which exists in

6 different implementations (CGI, MOD, MOD2, MOD2_2, ISAPI) and an additional servlet

implementation. Typical installations use single or multiple Gateways to act as the entry point to

the IBM Cognos BI system. The Gateway component, though, does nothing to the request but

relay it to the first available Dispatcher in it's configured list of dispatchers. The Gateway does

not route, it's a static link which only changes if the configured Dispatcher is not reachable. Only

in this case the Gateway will try to forward the request to the second dispatcher in its list and so

forth. That being said, routing only starts whenever a request reaches a dispatcher for the first

time. The Dispatcher which first receives a request is called the FRONT Dispatcher. This is

important for several specific request flows involved with authentication (refer Appendix A).

Technically though, it doesn't make a difference what the entry point is: a Dispatcher or a

Gateway. This is remarkable because it implies that one can use application server features like

web server plug-ins which proxy requests received in the web tier to the application tier in the

same manner as the IBM Cognos BI Gateway does.

For the rest of the document no differentiation between Dispatcher or Gateway is made,

whenever required it will reference to an entry point to simplify things.

Back to top

Routing Concepts

The following section will explain the main concepts of IBM Cognos BI routing.

Server Groups

The first concept to be described is the one of Server Groups.

A Server Group (SG) is a set of Dispatchers. Each Dispatcher is assigned to exactly one Server

Group at a time.

By default when the system is installed, no explicit Server Group setting is defined for

Dispatchers. This automatically makes them a member of the “default Server Group”. An

Administrator can however assign a Dispatcher to an SG explicitly by specifying a string value

for the Server Group property of the Dispatcher object in IBM Cognos Administration. The

value implicitly defines a new Server Group of that name if it doesn't exist already. If it does, it

adds the Dispatcher to the Server Group.

Figure 1 - Dispatcher which was assigned to SG "Endor"

Server Groups are important because they define the scope for load balancing and service

allocation in general.

Whenever Dispatchers look for an active instance of a particular service, the scope of that

look-up will be a Server Group.

Whenever Dispatchers consider Load Balancing, they will do so only for services within

the same SG the Dispatcher is in.

Those are two very important facts to remember.

Finally Server Groups are the prerequisite to use Advanced Routing, which will be discussed

later.

Server Groups get stored in the Content Store and only CM can supply information of Dispatcher

assignment to a Server Group. They get managed implicitly only by supplying values to the

Server Group property of Dispatchers, that is, if a new value is entered which didn't exist before

a new Server Group is implicitly defined. If there is no Dispatcher which uses a value of X

anymore, then the Server Group X will be deleted. The list of Server Groups could be perceived

as a “SELECT DISTINCT” on the Server Group Property of all Dispatchers in a system.

IBM Cognos Administration offers the possibility to group Dispatchers in folders. This however

does not imply a Server Group. This is an organisational grouping only. By using folders one can

apply properties to multiple Dispatchers at once. Dispatchers will inherit property values from

the parent object, like a folder, by default.

Dispatcher Cluster Information

To be able to assign requests to the right services and to route them correctly, a Dispatcher must

have comprehensive information about

which Dispatchers are up and running in the IBM Cognos BI system

the Server Groups those Dispatchers belong to

the services associated with each Dispatcher

the running state of each service

This information is called the “Dispatcher Cluster Information””.

As mentioned briefly in Section 2.2, each Dispatcher will register itself with Content Manager

Service upon start-up. During this registration process the Dispatcher will inform CM about the

services it hosts and their running state (enabled/disabled). CM will add this information to the

Dispatcher Cluster Information which has been gathered so far. Next the Dispatcher will then

query CM for a copy of the Dispatcher Cluster Information which contains all services and the

dispatchers they are associated with so that eventually each Dispatcher has information about all

other Dispatchers and their associated services.

The Dispatcher Cluster Information is updated only when a special call (reconfigure) is used

which triggers the Dispatcher to request updated information from CM. This call will be made by

Content Manager when some Dispatcher in the IBM Cognos BI system changes it's running state

either intentionally (it was stopped or started by an Administrator) or unintentionally (aka it

crashed). This leads to updated Dispatcher Cluster Information in the CM which then must be

distributed to each Dispatcher in the system. This is done by sending the reconfigure call to each

Dispatcher. After an update of the cluster information in CM, it can take up to 1 minute for all

other Dispatchers to pick up the changes and apply them. This is because each dispatcher has a

keep-alive ping of 30s, which means every 30s they report back to CM that they are still alive. At

the same time, CM will realize a certain Dispatcher is unavailable after a 30s maximum.

There is a need to update the Dispatcher Cluster Information on each Dispatcher with the

running states of the services. This however only happens when some administrator changes the

running state of a service. In that case the Dispatcher hosting that particular service instance will

inform CM about the change and CM will inform the other Dispatchers.

The Dispatcher Cluster Information of a specific Dispatcher can be viewed by using the

following URL:

http://<INTERNAL_DISPATCHER_URI>/p2plbDiag

The user accessing this URL requires the “canUseAdministrationPortal” capability.

Figure 2 - Cluster View output of /p2plbDiag URL

Load Balancing

Load Balancing is a concept which can be applied whenever there are multiple instances of the

same IBM Cognos BI service available within a Server Group. Instances of the same service in

different server groups are not eligible for load balancing.

Not all services are subject to load-balancing though, the following sections will have more on

this.

Load-Balancing is controlled by the “Load Balancing Mode” setting of a dispatcher (refer to

Figure 1). It can be set to either “Weighted Round Robin” or “Cluster Compatible”. It's

important to note that ALL Dispatchers in a system must use the same mode otherwise routing

might conflict and the product won't work as expected.

A mode of “weighted Round Robin” implies that IBM Cognos BI shall route applicable requests.

The routing will facilitate a variant of the Round Robin method to distribute requests among

multiple instances of the the service. While Round Robin is a simple straight forward assignment

of requests, it doesn't respect possible differences between the service instances. Since IBM

Cognos BI uses an SOA, those instances could, and likely are, located on different physical

boxes, which could have very different resources available to them (amount of heap, number of

CPUs). This leads to the understanding that not all instances of a service are equal in their

potential capacity. A service running on a multi-core CPU box with lots of RAM available might

be able to handle more load than a service running on a single CPU box with 2GB of RAM. To

account for this, a weight has been added to the Round Robin fashion of assigning requests. This

weight impacts how many requests an instance will obtain. Actually, the weight is assigned to

the dispatcher and not at the service level, so it applies to all services hosted by the dispatcher,

which makes sense as they all share the same hardware. The weight is defined in the property

Processing Capacity (refer to Figure 1) of a dispatcher. With this capacity taken into account

Round Robin works like this:

Example:

4 Dispatchers with different Processing Capacity's defined.

Dispatcher A, Weight 1

Dispatcher B: Weight 2

Dispatcher C: Weight 1

Dispatcher D: Weight 4

Requests will be assigned to Dispatchers in this order: A, B, B, C, D, D, D, D, A, B, B, C, D, D,

D, D, ...

The second possible value for load balancing mode is “cluster compatible”.

In “cluster compatible” mode the load balancing is trumped by local (to the Dispatcher which is

currently handling the request) instances of the requested service. Whenever a request for service

X arrives, the Dispatcher will try to assign it to a local instance of that service first. Only if that

fails, the fall-back of weighted round robin will be used. Therefore this setting gives priority to

local instances and ignores capacity which is only evaluated in a later step.

One would want to enable this mode when using external load balancing by either hardware or

software to distribute the load between nodes (Dispatchers).

For example this is recommended when deploying IBM Cognos BI in an IBM WebSphere

cluster. In that case IBM WebSphere software components decide to which node/Dispatcher a

request is routed. However, that routing is not based on IBM Cognos BI service availability or

load but simply based on Dispatcher availability and load. Since in a cluster all nodes are

expected to be identical they should all run the same services and hence it would be

counterproductive to re-route the request again. Never the less, if a service doesn't exist locally

the fall-back of weighted round robin is still applied.

Request Affinity

It has been mentioned before that not all requests are subject to load-balancing. This is because

there is another concept which defines a measure for how important it is, that a certain request is

processed by an IBM Cognos BI service instance on a specific Dispatcher. This measure is called

request affinity. If a request is affine it cannot be load balanced.

A request's affinity depends on the Service it's for and the type of operation. It is set implicitly by

the IBM Cognos BI system when the request is created and cannot be controlled or changed. The

affinity is stored in a value which is part of the SOAP action header of a request. There are 5

different values of affinity in IBM Cognos BI.

1. (none) – Non affine. Request can be routed to any running instance of the targeted IBM Cognos BI service.

2. high – High affinity. The request should be routed to the Dispatcher that is specified in the nodeID parameter

which is mandatory for high affinity requests and hence will be set in the request's SOAP

header. If the requested Dispatcher is not available then the request will be treated as

being non-affine.

3. session – Session affinity. This is the same as high affinity except the nodeID is optional. If no nodeID is specified,

it is treated as non-affine.

4. absolute – Absolute affinity. The Dispatcher must route the request to the Dispatcher specified by the nodeID. If the

specified Dispatcher is not available, the request will fail and a SOAP Fault is returned.

5. control – Control affinity. Same as absolute affinity, however this is reserved for system operations involved with

executing reports such as cancelling a report.

The point to remember is, that only non-affine requests can be load-balanced.

Advanced Routing

When the concept of Server Groups was introduced it wasn't entirely obvious what the

application of Server Groups would be. This last concept discussed here will reveal it.

Every Dispatcher is part of a Server Group at any point of time. By default there's only a single

Server Group to which all Dispatcher in a IBM Cognos BI system belong. IBM Cognos BI Load

Balancing only happens within the Server Group, which means that under normal circumstances,

once a request has logically been assigned to a Server Group, there is no way it's going to leave

that Server Group.

For example in regards to interactive report execution this would imply that all Dispatchers

running the ReportService are equal in the resources they offer and share the same data base

connectivity. This however may not be sufficient for all use cases.

One might want to ensure that certain report executions get processed by specific Dispatchers

,this could be because

Reports executed by executives should be processed on dedicated hardware.

Reports from users in one location should be processed by geographically local servers

while the overall system might geographically distributed.

A certain type of database connectivity only exists/doesn't exist on specific Dispatchers.

For example, if the overall system has Dispatchers running on Windows and UNIX

Microsoft SQL Server has no database client for SQL Server on UNIX. One has to ensure

that reports run against SQL Server get processed by an instance of ReportService hosted

by a Dispatcher running on Windows.

Reports against IBM Cognos PowerCubes require the cube files to be available locally.

Instead of copying them to multiple machines one would desire to process all reports

based on those cubes on machines which have the file.

Those are just some use cases which can be supported by implementing Server Groups and

Advanced Routing.

Advanced Routing allows you to route non-affine requests for query executing services like

(Batch-)ReportService, PowerPlay Service, Metadata Service and Query Service (IBM Cognos

10 only) to specific Server Groups based on so called Routing Rules. Once they are assigned to a

Server Group they are subject to Load-Balancing in that Server Group.

Routing Rules map so called Routing Sets to Server Groups. Routing Rules get defined globally

for the overall IBM Cognos BI system. They get stored in a single list and are managed by

Content Manager through Cognos Administration.

Figure 3 - "Specify Routing Rules" Button in Cognos Administration

Matching of report execution requests against the Routing Rules is handled by CM (not

Dispatcher).The rules are parsed in sequence and the first match fires and stops further

evaluation of the rules. To emphasize, although a request may match rule #1 and #3, it will

always be treated according to rule #1 as the first match fires.

The IBM Cognos BI service sending a request for a query executing service is responsible for

calling CM to evaluate Routing Rules and put the Server Group Information into the request

passed to a Dispatcher. For example, if a report is called interactively via Cognos Connection it

will be the Presentation Service (XTS) which queries CM to learn whether the report destined for

execution is subject to any routing rules. If it is, CM Service will have responded with a Server

Group name which Presentation Service will then add to the request it passes to its local

Dispatcher for processing. For scheduled reports that would be handled by the Job and

Monitoring Service (JMS).

Figure 4 - Definition of Routing Rules in Cognos Administration

Finally, the definition of which query executions to apply Advanced Routing to is defined by

Routing Sets. A Routing Set is a name, a label applied to a set of objects of a certain type. There

are three types of Routing Sets, distinguished by the type of objects in the set:

Package Routing Set:

Is composed of Packages. Report executions based on data from the defined packages

will be routed to a specified Server Group.

Group Routing Set:

Is composed of security Groups. Report executions run by a user who is a member of one

of the groups in the set will be routed to the specified Server Group.

Role Routing Set:

Is composed of security Roles. Report executions run by a user who is a member of one

of the Roles in the set will be routed to the specified Server Group.

A Routing Set can contain elements of a single type only. Iit is not possible to define a set

containing a package, two groups and a role for example. These would have to be three different

sets.

An Administrator adds objects to a set by specifying the name of the set in the respective section

of the objects properties. If a set of this name does not exist already it will be automatically

created.Refer to product documentation for details on how to assign Groups, Roles or Packages

to a routing set.

Eventually a query execution request will be checked against the defined Routing Rules. If it

matches a rule it will be routed to a Dispatcher in that target Server Group. In the target Server

Group, Load-Balancing may take place and finally the request is assigned to an instance of the

required service. If there is no matching IBM Cognos BI service available, the request will fail

with an error stating that there is no service available to handle that type of request.

Advanced Routing is very versatile and can greatly improve overall load handling or traffic

shaping by routing to dedicated resources.

Back to top

The Routing Process

Finally, now that we introduced all the required concepts, we can define the routing process. It

roughly consists of five steps.

Note: This description is conceptual and does not necessarily describe the exact rundown of

steps for each action. To comprehend the concepts discussed herein, however, is sufficient.

Identify Operation

Dispatcher has a static list of so called handlers. Each handler is queried to find out whether it

can handle the request in question. There are handlers for handling authentication, load

balancing, etc. Without going into detail, it's sufficient to comprehend that each handler will

have it's own sequence of steps which it will use to handle the request.

For example, one of the first operations Dispatcher runs when it receives a request is to verify

whether the session this request is a part of is already authenticated. If it isn't then the

authentication handler will be used, which runs through a number of steps and only after

successful authentication will re-issue the original request for further processing.

For the next steps it's safe to assume that the session has been authenticated.

Identify Target Service

The next step will be to identify the target service which can handle the request. The targeted

service is identified based on the following information in the order presented.

The SOAPAction HTTP header E.g. http://developer.cognos.com/schemas/reportService/1

In this case the SOAPAction header will contain references to specific schemas which

imply the service to use.

Service Mappings Each dispatcher has a static list of SOAPAction -> Service mappings from which to

derive the target Service.

The “b_action” URL parameter The HTTP GET or POST command to the Dispatcher can contain the b_action parameter

who's value will indicate the target service.

E.g. b_action=xts.run targets the Presentation Service (XTS)

The PATH_INFO for the request Some URLs path indicate a target service

E.g. /cgi-bin/cognosisapi.dll/gd/… indicates a specific action (retrieving a pre-rendered

chart or Diagram) which is handled by a specific handler/service.

If the request specifies none of the above, the request is forwarded to the IBM Cognos

Connection home page.

At this point, the request is authenticated and the target service is identified.

Handle Content Manager Requests

If the target service is Content Manager Service, the request is routed to the active Content

Manager, regardless of any Advanced Routing, Server Groups or Load-Balancing. This is crucial

for the product to work.

Handle Absolute Affinity Requests

In case the submitted request has absolute affinity it's obsolete to perform any advanced routing

or load balancing. The request is forwarded to the Dispatcher indicated in the NodeID of the

request. If that fails, the request fails and an error is written to the log and possibly pushed back

to the client.

Deduce Cluster View

In this step the Dispatcher constructs a set of potential target Dispatchers for the request to serve.

This set is called “Cluster View”.

If the actual request specifies a target Server Group the Cluster View will contain only

Dispatchers from that Server Group. This is the case for Advanced Routing. If no target Server

Group is defined the Cluster View will potentially contain all available Dispatchers from the

Default Server Group.

Respect affinity

In the next step, the Dispatcher will try to respect affinity. The absolute affinity requests were

handled in step 4.4 so here it's only about “normal” affinity. The Dispatcher will forward to the

requested Dispatcher if it's within the Cluster View. If this fails, because either the requested

Dispatcher is not in the Cluster View (unlikely) or the requested Service is not available on that

Dispatcher due to load or Service is disabled, then the request is simply switched to non-affine.

Processing continues.

Process Load-Balancing

Now that the Cluster View has been established and only non-affine requests remain to be

assigned Load-Balancing is evaluated. First of all, the load-balancing mode is checked.

If that is set to “cluster compatible” the Dispatcher will try to assign the request to a local

instance of the requested service, which however must be within the Cluster View, thus ignoring

load balancing. This means, that although the request could get load balanced a local instance

would be given priority. This still respects Server Groups. The Cluster View only contains the

Dispatchers form the desired Server Group. If the Dispatcher processing the request is not within

the Cluster View the assignment will fail, same is true if the local Dispatcher doesn't offer the

requested service. In case of failure to adhere to cluster compatible, the fall-back is used, which

is process it according to weighted round robin like any other request.

Note: Using Server Groups when the load balancing mode is set to “cluster compatible” is

counterproductive though. Clustering expects the nodes of a cluster to be identical. Server

Groups are a concept to model the exact opposite, technically this will work though.

Eventually, if load balancing mode is set to “weighted round robin” or the assignment due to

“cluster compatible” failed, the request is load-balanced amongst the instances of the requested

service offered by Dispatchers within the Cluster View.

If there is no instance of the target service available at all, the request will fail and an error

message is returned to the client indicating that there's no target service available in the

configured Server Group.

Back to top

Appendix A – Known Challenges

FRONT Dispatcher requirements

There is a quite infamous behavior which is quite often is perceived as wrong or being an

issue/defect in setups where single Sign-On has been configured and clients access Dispatchers

directly without a Gateway.

Typical examples of setup where the Gateway component is omitted are those where IBM

Cognos BI is deployed to an application server like IBM WebSphere and web tier application

server plug-ins are used. Another example is when for reasons of product conformance (no

suitable Gateway available like lack of 64bit MOD implementations) or infrastructure

requirements hitting the Dispatcher for entry point is reasonable. Often external solutions take

over the load balancing task which balances the client requests between multiple Cognos entry

points either.

In those setups on every n-th access or even sporadically the SSO fails and instead XML is

returned to the client. This is however the result of current product design and solvable by a

simple configuration change.What happens is (assuming default configuration values for

Dispatcher Servlet Context-Root).

All access to IBM Cognos BI is through FRONT Dispatchers only. A FRONT Dispatcher though

must provide certain Services for Sso to work.

1. Request to http(s)://<host>:<port>/<context_root>/servlet/dispatch" hits the Dispatcher.

This would be the arbitrary URL being used by an initial request of a new client session.

The Dispatcher accessed is therefore the FRONT Dispatcher.

2. Since there is no other indication of which service is being called, this request is assigned

to XTS (Presentation service).

3. This is a primary request (not a secondary in a conversation) with no affinity which is

therefore subject to load balancing.

4. Assuming default configuration, “round robin” is set for load balancing mode.

Now if there is more than one instance of Presentation Service available in the current

Server Group (by default all Dispatchers are members of the default Server Group), the

request might be sent to any of the Dispatchers in that very Server Group hosting one of

the available instances of Presentation Service. This explicitly means it can be send to a

different Dispatcher!

5. The handling Dispatcher (the one which hosts the instance of XTS which the request got

assigned to) checks for an authenticated session. The client session is yet not

authenticated therefore the authentication sequence is triggered which includes passing

the request to Content Manager Service. The original request is saved (like pushed to

stack).

6. The request plus some extra info is sent to CAMAAAsyncService (next to CMService).

7. CAM-AAA determines which authentication provider to pass the request to. Either based

on an URL parameter (CAMNamespace) or based on the fact that there is only a single

active authentication provider available for authentication.

8. The request is assigned to the authentication provider identified to handle the

authentication in the previous step. The provider checks for the presence of logon data

sufficient to process the authentication request with the configured provider. This will

come out negative, otherwise the issue wouldn't be visible.

9. The authentication provider now triggers SSO which means it has to throw a

"SystemRevoverableException" which technically is a response using HTTP status code

599 and some specific data.

10. The response is returned to the sender, which is the handling Dispatcher from step 5.

NOW: If the handling Dispatcher is not the same as the FRONT Dispatcher being accessed (in

1.) what happens is

11. The handling Dispatcher deduces it is not the FRONT Dispatcher for this session which

received the original request. Therefore it is not responsible for handling the response

received from the authentication provider (step 9.). Instead it will transform/leave the

response in it's original format (SOAP, which is XML) and pass it over to the actual

FRONT Dispatcher for this session.

12. The FRONT Dispatcher considers the response received from his fellow Dispatcher to be

a normal request response which it therefore is supposed to pass to the client; which it

does.

This is what makes the XML appear in the browser client (because they know how to render it)

or being returned to other client types (clients like Framework Manager).

The desired behavior is only achieved if the handling Dispatcher (that is the one hosting the

instance of Presentation Service which handles the request) is the same as the one being

accessed (the FRONT for this session) in 1. In that case what happens is

13. The handling Dispatcher deduces it is the FRONT Dispatcher for this session and

therefore responsible for handling the response.

14. The Dispatcher investigates the response code for anything special. It finds response code

HTTP 599 which triggers special SSO handling code to be run.

15. The SSO code investigates the SOAP (XML syntax) request and finds the

SystemRecoverableFault in here. This will invoke the matching handler to act on this.

(will only do that for XTS and CM Service requests).

Within this handler, Disp will react to the SystemRecoverableException by retrieving a

HTTP environment variable value from it's local CGI environment and re-sending the

authentication request back to the authentication provider with that retrieved HTTP

variable value added.

16. Once the authentication provider receives that 2nd request with the variable value in it

authentication will be run and either a success response including the cam_passport

cookie and session identifiers will be returned or an UnrecoverableException which will

"bubble up" like the first response as described below.

If SSO succeeded, the original request is retrieved (pop stack) and processed normally

which in this case means rendering the Cognos Connection default location. If SSO

failed, the Unrecoverable Exception will have lead to an Error message and the log-in

page being displayed.

From above explanation it evolves that to prevent the XML responses to be send back to the

client one has to ensure that initial requests for an unauthenticated session get handled by

Presentation Service instances on the FRONT Dispatcher for the session only. Or in other words

Presentation Service must be run on a FRONT Dispatcher.

Initial requests of a session must be processed by a local instance of Presentation Service

on the FRONT Dispatcher of that very session. They must not be routed “away”.

This can be achieved through either of these two configurations

Ensure there is only a single FRONT Dispatcher in a particular Server Group which runs

the only instance of Presentation Service in that Server Group.

This approach can easily be adopted to define additional Server Groups explicitly in

which a single Dispatcher is put which adheres to the above requirement. That way, one

can point out specific entry points for specific types of clients as well, e.g. one entry point

Dispatcher for Framework Manager clients, a particular set for browser clients etc.

Implicitly this means, that if no Server Groups have been defined, and multiple instances

of Presentation Service exist, the issue will surface without the required configuration

change because all Dispatchers are pooled in a single Server Group.

In case of multiple FRONT Dispatchers in a Server Group, configure the load balancing

mode to be “cluster compatible” on those FRONT Dispatchers.

Mind that if any additional Services to Dispatcher Service, Presentation Service and

Monitor Service which make the minimal set of Services a FRONT Dispatcher should

run, are configured, the cluster compatible mode applies to those as well, which means

local processing trumps load balancing when possible.

Dispatcher Services instances

When Server Groups get defined it's important to ensure that each Server Group runs at least one

instance of Dispatcher Service.

Otherwise requests may not be routed correctly. This can happen if, for example, a Server Group

is defined which only contains a single node which is an install of a Content Manager component

only. By default a CM only install does not run the Dispatcher Service.

The best practice is to define Server Groups in such a way that only nodes which run report

executing services like (Batch-)ReportService and PowerPlay Service get added to explicitly

defined Server Groups and all other nodes remain in the default Server Group.

64bit Report Server Execution Mode

As of IBM Cognos BI version 10.1. Refresh Pack 1 (10.1.1) there is a new feature which allows

to configure the Report Server execution mode to either 32bit mode or 64bit mode. This

basically determines, whether executions for reports based on relational data sources packages

are handled by the compatible query mode (legacy, as in 10.1, C++ 32bit executable) or the new

dynamic query mode (DQM) (64bit, Java engine).

Regarding routing it's important to remember, that although DQM is configured, request routing

is based on the availability of the (Batch)ReportService and not the Query Service. The latter is

not a target Service for load balancing but rather a secondary Service to the

(Batch)ReportService. Only if a local instance of ReportService is available, a co-located Query

Service will be employed.

Scheduling

For all background processing the central Service is the Monitoring Service. Opposed to active

load-balancing by Dispatcher the mechanism for background processing is called “auto-load-

balancing” and works in a “pull” fashion.

An instance of Monitoring Service will investigate the system global task queue and match items

in there to the locally available so called “target services”. Only if a matching target service is

available on the very same Dispatcher (locally) the Monitoring Service will probe if that instance

of target Service has yet capacity to take on another task. This is determined by the number of

unallocated affinity connections for that service. Their number can be configured in Cognos

Administration on a per service level. If there is yet a free connection the Monitoring Service

will pull the task from the queue, set up the controls to overlook the execution and pass it to the

target service for processing.

That is, only if the Monitoring Service is co-located on the same Dispatcher as for example an

instance of Agent Service that very instance of Monitoring Service will take the task item from

the global task queue and engage to run it. Implicitly that means, that the Monitoring Service is

required to run on a Dispatcher so that the so called target Services can get assigned work. Target

Services are

Batch Report Service

PowerPlay Service

Agent Service

ContentManager Service

Job Service

Index Update Service

Delivery Service

...

If they run on a Dispatcher which doesn't run Monitoring Service, they won't participate in

working on the tasks. Another crucial task of the Monitoring Service is to provide data for the

Presentation Service when rendering the lists of tasks actually executing, pending etc. Yet,

Monitoring Service is accessed through conversations like other services as well and it is subject

to load balancing.

For that reason the best practice is to have Monitoring Service enabled on basically every

Dispatcher. It won't take away noticeable resources unless it's actually controlling the execution

of background processing which it can only do if there are active instances of target services

hosted on the very same Dispatcher. This for example implies that running Monitoring Service

on a “routing” Dispatcher which only runs the minimal Services like Dispatcher Services and

Presentation Service won't do any harm. At the same time Monitoring Service is required on a

Content Manager install component only install. To feed the Content Manager Service

background tasks like Deployments. If the Monitoring Service , which is enabled on those

installs by default, is disabled, deployments will fail.

Regarding routing, the Monitoring Service should only be disabled on a Dispatcher if there is no

target Service and no Presentation Service on this Dispatcher.