Chapter 3. Managing IBM Cognos BI Server Components

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.

Cognos BI architecture

The IBM Cognos 10.2 BI architecture is separated into the following three tiers:

  • Web server (gateways)
  • Applications (dispatcher and Content Manager)
  • Data (reporting/querying the database, content store, metric store)

Web server – gateways

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:

Web server – gateways

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:

Web server – gateways

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:

Web server – gateways

To improve performance, gateways (if more than one) must be installed and configured on separate machines.

The application tier – Cognos BI Server

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 application tier – Cognos BI Server

Dispatcher

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.

Dispatcher

Services for the BI Server (dispatcher)

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:

Service

Description

Agent service

Runs the agent.

Annotation service

Adds comments to reports.

Batch report service

Handles background report requests.

Content Manager cache service

Handles the cache for frequent queries to enhance performance of Content Manager.

Content Manager service

Performs DML in content store db. Cognos deployment is another task for this service.

Delivery service

Sends e-mails.

Event management service

Manages the event objects (creation, scheduling, and so on)

Graphics service

Renders graphics for other services such as the report service.

Human task service

Manages human tasks.

Index data service

For basic full-text functions for the storage and retrieval of terms and indexed summary documents.

Index search service

For search and drill-through functions, including lists of aliases and examples.

Index update service

For write, update, delete, and administration-related functions.

Job service

Runs jobs in coordination with the monitor service.

Log service

For extensive logging of the Cognos environment (file, database, remote-log server, event viewer, and system log).

Metadata service

Displays data lineage information (data source, and calculation expressions) for the Cognos studios and viewer.

Metric Studio service

This service is used for providing a user interface to the Metric Studio to monitor and manipulate system KPIs.

Migration service

Used for migration from old versions to new versions, especially series 7.

Monitor service

Works as a timer service—it manages the monitoring and running of tasks that were scheduled or marked as background tasks. Helps in failover and recovery for running tasks.

Presentation service

This service prepares and displays the presentation layer by converting the XML data to HTML or any other format view. IBM Cognos Connection is also prepared by this service.

Query service

Manages dynamic query requests.

Report data service

This service prepares data for other applications; for example, mobile devices, Microsoft Office, and so on.

Report service

Manages report requests. The output is displayed in IBM Cognos Connection.

System service

This service defines the BI-Bus API compliant service. It gives users more data on the BI configuration parameters.

Content Manager

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.

Content Manager

The information that Content Manager stores and manipulates includes:

  • Data related to the server configuration, for example, directory information, namespaces, contacts, DLs, data sources, and other namespaces such as printers
  • Information related to reports (report properties, permissions, outputs, and report specifications)
  • Packages (information related to reports, dimensional packages, and metric packages)
  • Agents (schedules, events, conditions, and e-mail delivery info)
  • User information (personal information, and the My Folder and My Pages areas)
  • Workspace information
  • Language-related information (for multilingual capabilities)

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:

Content Manager

Data tier – the content store, query/reporting database, and metric store

The third-tier (data tier) contains the following:

  • Content store (single instance)
  • Metric store (multiple instances)
  • Data sources (for variety of RDBMS)

The content store

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.

The metric 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:

The metric store

Data sources

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset