The Cognos Dashboard Building Blocks
The “IBM Accelerator Catalog” contains many Cognos Dashboard extensions. Some add new widgets that an author can use in the dashboard; others add new behaviour to existing content.
Imagine you can write your custom extension and take advantage of the existing public Dashboard javascript API. But before we get into this, it is essential to understand the various building blocks in the Cognos Dashboard application.

What is a feature?
Features are the primary building blocks that compose the dashboard application. They provide every single capability that exists today in the dashboard application. Think of features as self encapsulated components, each of them has a specific purpose, can depend on and be consumed by other features.
Features are registered in the system using a well-defined interface. A “feature” must provide a public interface to be consumed by other features.
There are two types of features, a dashboard level feature and a content level feature.
Dashboard features
A dashboard feature defines a class with a specification that registers with the dashboard instance.
The dashboard application will create an instance of the feature class as part of its life cycle. Only one instance of this feature will exist per dashboard instance in a given browser session.
A feature can depend on other dashboard features, and the system will pass the required features APIs in the constructor of the newly defined component.
Example of existing dashboard features:
CanvasThe canvas gives access to the content of a dashboard. Canvas content is any content that is added to the dashboard by the author. It can be a tab control, page, group, widget, etc. The Canvas API is used to read, update and create new content in the dashboard.The canvas gives access to the content API. A content API represents content like a widget inside a dashboard. A consumer can use this API to manipulate the content instance and access its features.You can find the public interface here.UserProfileThis feature gives access to the various user properties like the user account, capabilities, etc.You can find the public interface here.TransactionDevelopers use this feature to create a transaction when performing various operations in the dashboard.The transaction API creates a transaction token that the developer can provide when calling other features' APIs.A transaction will bundle the operations together. For example, the system will treat all actions done under one transaction as one undo/redo entry. The transaction also affects how the user interface will react to specific changes. Typically, the UI will wait for a transaction to be complete before updating.You can find the public interface here.
Dashboard Content features
As the name implies, these are features associated with the individual content instances like a page or a widget in a dashboard.
A content feature defines a class with a specification that registers it with the dashboard. The dashboard will create an instance of the content feature for each “content” in the dashboard canvas.
For example, if I have a dashboard with five widgets and a content feature registered with these widgets, the system will create five instances, one per widget.
Content features can declare which content type they are associated with or decide to be associated with any kind.
A content feature can define a list of required features that it depends on, either a dashboard or a content feature. The feature constructor will receive all the needed features and the main content API representing that content instance.
Example of existing content features:
StateDevelopers use this feature to access the status or error state of a given content (i.e. widget).
This feature is available for contents of any type.You can find the public interface here.
VisualizationThis feature is only available when the content is of type visualization.It is the main API to read and update the visualization slots and the data items. You can use it to change the visualization slots, add filters, sort, format data items, etc.You can find the public interface here.DataQueryExecutionThis feature is only available when the content is of type visualization. It gives access to the query results associated with the visualization.You can find the public interface here.DataPointSelectionsThis feature is only available when the content is of type visualization. It gives access to the API used to monitor and change the data point selections in the visualization.You can find the public interface here.
Dashboard Content
Dashboard “Contents” are the 3rd and last building block that I will discuss in this article. A dashboard content defines the content type that an author can add to the dashboard. An example of content is a dashboard page, image, shape or visualization, etc.
The content definition defines the type and the renderer class that will render the content. It also describes the properties and the list of features that the renderer requires.
Extending the application
The following diagram summarizes the three mains building blocks that we have used to build the dashboard application.

An extension can add one or more building blocks that work together to provide a given functionality. These building blocks can depend on existing blocks and can build more blocks in the future.
For example, I can have an extension that:
- Adds a new dashboard feature called “MyFeature”.
- Adds a new content of type “MyContent” that will be available as a custom widget.
- Adds a new content feature called “MyContentFeature”.
These components can work together to add a new widget or behaviour to the dashboard application.

Final thoughts
I hope you find this article helpful. If you have any comments or questions, please drop me a line, and I will be more than happy to answer.
You can find more information about the feature interfaces and extension points here.
To go over a step by step guide for adding a sample extension, please read my other article here: