When it comes to enterprise software, it must involve proper planning, design, and implementation for its success. IBM Cognos is a similar software that has been divided into multiple components, where each component has its dedicated responsibility that makes it easy to handle. In this chapter we will go through all the Cognos components and the architecture of IBM Cognos. Load balancing will also be discussed at the end of this chapter along with certain benefits of having this sort of Cognos architecture.
The IBM Cognos 10.2 BI architecture is separated into the following three tiers:
The user starts a web session with Cognos to connect to the IBM Cognos Connection's web-based interface/application using the web browser (Internet Explorer and Mozilla Firefox are the currently supported browsers). This web request is sent to the web server where the Cognos gateway resides.
The gateway is a server-software program that works as an intermediate party between the web server and other servers, such as an application server. The following diagram shows the basic view of the three tiers of the Cognos BI architecture:
The Cognos gateway is the starting point from where a request is received and transferred to the BI Server. On receiving a request from the web server, the Cognos gateway applies encryption to the information received, adds necessary environment variables and authentication namespace, and transfers the information to the application server (or dispatcher).
Similarly, when the data has been processed and the presentation is ready, it is rendered towards the user's browser via the gateway and web server. The following diagram shows the Tier 1 layer in detail:
The gateways must be configured to communicate with the application component (dispatcher) in a distributed environment. To make a failover cluster, more than one BI Server may be configured.
The following types of web gateways are supported:
CGI
: This is also the default gateway. This is a basic gateway.ISAPI
: This is for the Windows environment. It is the best for Windows IIS (Internet Information Services).Servlet
: This gateway is the best for application servers that are supporting servlets.Apache_mod
: This gateway type may be used for the Apache server.The following diagram shows an environment in which the web server is load balanced by two server machines:
To improve performance, gateways (if more than one) must be installed and configured on separate machines.
The application tier comprises one or multiple BI Servers. A server's job is to run user requests, for example, queries, reports, and analysis that are received from a gateway.
The GUI environment (IBM Cognos Connection) that appears after logging in is also rendered and presented by Cognos BI Server. Another such example is the Metric Studio interface.
The BI Server must include the dispatcher and Content Manager (the Content Manager component may be separated from the dispatcher). The following diagram shows BI Server's Tier 2 in detail:
The dispatcher has static handlers to many services. Each request that is received is routed to the corresponding service for further processing.
The dispatcher is also responsible for starting all the Cognos services at startup. These services include the system service, report service, report data service, presentation service, Metric Studio service, log service, job service, event management service, Content Manager service, batch report service, delivery service, and many others.
When there are multiple dispatchers in a multitier architecture, a dispatcher may also send and route requests to another dispatcher. The URIs for all dispatchers must be known to the Cognos gateway(s).
All dispatchers are registered in Content Manager (CM), making it possible for all dispatchers to know each other. A dispatcher grid is formed in this way.
To improve the system performance, multiple dispatchers must be installed but on separate computers, and the Content Manager component must also be on a separate server. The following diagram shows how multiple dispatcher servers can be added.
Each dispatcher has a set of services, which are listed alphabetically in the following table. When the Cognos service is started from Cognos Configuration, all services are started one by one.
The following table shows the dispatcher services and their short descriptions:
Content Manager is responsible for managing report contents (customer application data, security, configurations, settings, report specifications, and report outputs). It also manages the scheduling info and other Cognos namespaces. The packages are also published with the help of Content Manager. All the information that is managed by Content Manager resides in the content-store database, which lies in the data tier.
There can be more than one Content Manager in a Cognos environment. However, the clustering of these Content Manager server deployments have to be in an active-passive mode. Only one Content Manager is active at a time, and all others are on standby. In the case of failover, the next available Content Manager becomes active. The initially, the active Content Manager will resume (when started) as the standby Content Manager. The following diagram shows how active and standby Content Managers work. The front Content Manager is the active Content Manager, and the boxes behind the front Content Manager serve as Standby Content Manager.
The information that Content Manager stores and manipulates includes:
Content Manager also performs general functions (cut, copy, paste, delete, update, query, refresh, add, and content import/export). Content Manager has an internal process called Access Manager, which is the security manager of Cognos. The typical features of Access Manager include encryption, authentication, and authorization.
Cognos uses the default certificate authority that may be overridden by any other third-party certificate authority. The following diagram shows the detailed scenario for a load balancer:
The third-tier (data tier) contains the following:
The content store database contains data that Cognos needs to function properly. This includes all the information discussed earlier in the Content Manager section, including report specifications, published packages, connection information for data sources, information about the external namespace, the Cognos namespace itself, and information about scheduling and bursting reports. For Cognos Mobile, the service may access the content store using a separate database client, if it is not using the Content Manager path.
The content store is the database for Content Manager. The content store database is configured via the Cognos Configuration window, and all the tables in the schema are initially almost blank.
Data sources that can be accessed through IBM Cognos BI include databases, dimensional or OLAP cubes, flat files, and other physical data stores. They also include connection information necessary for accessing the data. Basically these are the connection namespaces that contain all the information required to connect to the reporting databases.
If the content store was also selected during installation of the Cognos components, a DB2 content store is created and configured with default options. The Content store is an optional component during installation; if it is not selected, the administrator has to configure a content store explicitly after the installation of the Cognos components using the IBM Cognos BI configuration window. If the content store was selected during installation and the administrator wants to shift the content store to some other RDBMS, the current content store has to be removed first before adding a new content store.
A metric store database contains the content for metric packages. A metric store also contains Metric Studio settings, such as user preferences. Cognos BI uses RDBMS for its metric store, and can be configured to use the same database that the content store is using. The following diagram shows the typical architecture of the content and metric stores in the Cognos environments:
Data sources are used as namespaces that contain the connection strings, settings, and parameters required to connect to a data model, such as RDBMS, plain but flat and organized data files (such as CSV files), cubes, and other data models.
Data sources can be viewed or modified under IBM Cognos Administration under the Configurations section. The Framework Manager also has the capability to create data source connections on the Cognos BI environment that the framework manager configurations are pointing to.
Cognos BI 10.2, like its earlier versions, supports a vast range of connectivity with almost all relational databases. Cognos BI Server uses these data sources to connect to databases in order to query data. Most of the data sources require either clients or connectors to be installed on the Cognos BI application server.
Connectivity using JDBC connectors is also possible. Dynamic Query Mode is a new feature in Cognos 10.1 and is now the recommended method of connectivity.
Cognos BI may also be used with Enterprise Information Integration (EII) products, for example, Virtual View Manager, which provides reachability to some additional data sources such as JDBC, Open XML, WSDL, and LDAP. It is well optimized and gives a better performance.