Post on 30-May-2018
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.