Cognos Dispatcher 6j4x61

Introduction Purpose This document is meant to supplement the Security and istration 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 ed 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 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 ed. 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 ed/routed between Dispatchers in a system and eventually to a specific service instance ed with one of the Dispatchers. This process will acknowledge load balancing and service availability as this document will explain. Client requests, either s 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 s, 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 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 istration. 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 . 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 istration 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 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 ) 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 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:// /p2plbDiag The accessing this URL requires the “canUseistrationPortal” 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 Us). 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 U box with lots of RAM available might be able to handle more load than a service running on a single U box with 2GB of RAM. To for this, a weight has been added to the Round Robin fashion of asg 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 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 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 s 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 ed 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 istration.

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

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 ed 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 es 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 istration

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 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 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 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 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):// :<port>/ /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 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 ing 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 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 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 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_port 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 , 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-loadbalancing” 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 istration 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 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.