Cognos BI Simple Architecture Overview
IBM Cognos 10
Cognos BI Simple Architecture Overview
Please note that the high level architecture between versions 8.x to 10.x is pretty much the same, and the concepts within this article can apply across 8.x to 10.x
Whilst most people who use Cognos are used to accessing it through either a web browser to develop or run reports, or a client tool like Framework Manager, naturally there are a number of components under the hood that reside on servers which manage and run the Cognos service.
The purpose of this article is to give you a basic appreciation of the architecture of Cognos. We are literally just skimming the surface here because it is very easy to get into a great level of detail when discussing Cognos architecture and infrastructure, and more often than not there are deep infrastructure experts who specifically manage these areas. However having a basic level of understanding of how it all works is obviously very valuable
Any Cognos implementation requires the following three components, which can be installed on a single server, or distributed over multiple servers in a production environment (for obvious reasons such as performance, failover etc). In a basic distributed install, you would install one component per server. These are also the same three components that you can select from during the installation process of Cognos BI (i.e. install one, more or all of these components onto a particular server)
- Cognos BI Application Server / Application Tier
The descriptions of the above and the simple diagram below detail these different components and how they interact together.
This is the first component that is accessed (invisible to the user) when a user accesses Cognos. This component can reside on a Web Server, and is used to communicate to the other Cognos server components such as passing requests to the Dispatcher (see below) to process.
Cognos BI Application Server / Application Tier
On this server we would have:
includes the various Cognos studios such as Report Studio.
The dispatcher manages a number of different Cognos services such as the report service (which runs the reports), log service (which records log information generated by the various services) and many other services such as the batch report service and delivery service (which delivers reports via email). The dispatcher manages all the requests to each of these services.
Each server install has one dispatcher by default, and in a large distributed install you can have a number of dispatchers over a number of machines, for performance or failover purposes. In a distributed install the dispatcher also acts as a load balancer when processing all user requests for services.
This is a Cognos BI service which manages the Cognos Content DB, all requests to access information from the Content DB is done through the Content Manager.
For example when publishing a Framework Manager/Model the Content Manager processes this request and writes the package and model to the Content DB. In addition when you create a new user security group, the Content Manager would store the full details and contents of this group within the Content DB, and when required would read from the Content DB to access this information.
Cognos Content DB (Content Store)
All Cognos related metadata such as report specs, user security information, report schedule data, packages, models etc are stored within this database which is wholly managed by the Content Manager. The Cognos Content DB can be created with most major Databases such as DB2, SQL Server, Oracle.
This is simply your Data Mart, Data Warehouse or any other collection of Database tables that your reports are reading from. Cognos supports most major Database vendors.
Cognos Architecture Overview
For further reading you can reference the Cognos BI Architecture and Deployment guide that is freely available on the IBM website or as a PDF file which is included with your Cognos BI installation files.