Everyday is a new day: Framework Manager Introduction

What is Framework Manager?

Framework Manager is a tool that allows you to make data sources known for use within the various Cognos suites and allows you to add additional logic and details. Within a logical Cognos architecture a Framework Manager model contains the logic and information required for one of the Cognos tools to use a data source. This means things like the database name, the links and logic between the data, user-friendly naming, field formatting, languages, security, etc. That’s why a Framework Manager model is sometimes called a “meta” layer, as it adds meta data to data.

The final extract of a Framework Manager model is called a package that appears in Cognos Connection where you can actually use it. The physical files of a Framework Manager model are therefore not used by Cognos, only the published package made available and stored in the Cognos Content Store database.

Usually you will have multiple Framework Manager models and 1 or more packages for each Framework Manager model. How many of each will depend on your development style and the scale of the environment. In general I prefer multiple smaller and simpler models compared to a single contains-all model.

If you are starting with Framework Manager it is important to know that although it seems you are using the Cognos environment to extract the data source information from, you still need a connection to the data source accessible from your client machine.

Framework Manager Key Concepts

The purpose of this post is not to discuss each single detail of Framework Manager, but it is important that you understand some key concepts.

Apart from situations where Framework Manager is just used to publish some definitions to the Cognos Content Store (e.g. PowerPlay and TM1 cubes), you can choose between 2 modelling techniques for more or less standard relational data sources. The first is the easiest and will be used in the sample below, a multidimensional relational model. This is basically a fact table linking to a set of dimension tables. When you use a multidimensionally modelled relational data warehouse, this method is very straightforward. The result is more oriented towards report builders. The other approach is to use the same base for an OLAP style model. In most cases this is more user-friendly for analyst style end-users. However in such a case it is often advisable to use an OLAP style source as well.

Ok, if the gibberish above still makes a bit of sense then these are the key concepts to remember;namespaces, query subjects, folders and relationships. A query subject can be compared with a table and usually combines data items (query items) of a certain topic. These query subjects are then organized within a namespace. Folders don’t have a real function, they are only there to organize other objects. They have no impact when changed. When a query subject or namespace changes, it is possible that you end up with broken reports. Relationships then define the link logic between different query items and subjects.

Next to these key concepts you also have parameters, filters, calculations, dimensions and lots more, but that will not be covered in this post.

Constructing a simple Framework Manager model

1. Before you start, make sure you have a data source available. If you don’t have one, or you can’t access one, take this post Prepare an Excel file as ODBC source.

2. Open Framework Manager and click “Create a new project…”

3. Give the project a meaningful name, preferably with some versioning info in the name and place it somewhere you can find it again.

4. Choose the language you are going to use to design the model. It is best practise to take a different language for designing the model and another one (or more) as the display language. That way you can keep the technical database names in your design language version and the business names in each of the display languages. For this sample I’m not going to make the distinction as the model is really simple. Just remember to switch to the proper language if you use more than one language.

5. Select the type of data source. If you select “Data Sources”, Framework Manager will consult the IBM Cognos Content Store database and list the data sources already available. You can check this as an administrator via Cognos Connection.

6. Select the data source (or create a new one).

7. And select the constructs you want to import from that data source. Usually you are only going to import tables. Remember dat this is the meta information, not the data itself.

8. You can choose to make Framework Manager give some suggestions based on the meta data already contained in the data source. In 99,99% of the cases I deselect this as I usually have to redo it anyway.

9. Ok, so now we imported the meta data of some tables of a data source.

10. Framework Manager will put the tables as Query Subjects (1 for each table) in a top-level Namespace.

11. The first thing you want to do, is to bring a bit more structure into the Framework Manager model. There are as many options as there are Cognos developers, so here is my flavor:

SOURCE: A Namespace that only contains the source Query Subjects, no logic or changes.
RELATION: A Namespace that contains all the relationships between the Query Subjects and all added logic.
NAMING: A Namespace that contains no additional logic, only the technical labels are changed in business labels.
PACKAGE: A Namespace that contains no additional logic, only a selection, possibly organized differently, of objects that we want to publish as a package.

You can pick your own method, just make sure that you add logic only in a single place and preferably as early as possible. So now create these additional Namespaces. Also note that I already renamed the top-level Namespace.

12. Move the imported Query Subjects from the top-level Namespace into the SOURCE Namespace. Select all Query Items and set “Usage” to attribute. This is just so we make sure we will individually set the correct usages later on.

13. We are now going to fill the RELATION Namespace. In order to do so, we are first going to create new Query Subjects (so no copies) similar to those in the SOURCE Namespace. For each Query Subject in the SOURCE Namespace, we are going to create a Query Subject in the RELATION Namespace. Instead of importing the Query Subjects again, we are going to use the Query Subjects from the SOURCE Namespace as eh .. a source.

Repeat this for each Query Subject.

14. Next is to set the relationships between the Query Subjects, so Cognos understands how they are linked. To do this, click the corresponding keys in each Query Subject in the RELATION Namespace and set the correct cardinality. Make sure that you always validate this step to be sure.

Repeat this for all key combinations.

15. Set the correct usage for each Query Item in the RELATION Namespace.

16. As we previously did for the RELATION Namespace, we will now recreate the Query Subjects again in the NAMING Namespace. Now make sure that you base these Query Subjects on the Query Subjects from the RELATION Namespace, thus including the relationship logic, not the SOURCE Namespace. Do this for each Query Subject.

17. Start renaming all the labels into something normal people understand and delete all Query Items you are not going to use (for end-users).

18. Now repeat the Query Item recreation steps one last time, but for the PACKAGE Namespace. Preferably you create a sub Namespace per package you are going to create as well.

19. Finally we can now create the package. Remember that the model or project is just a bunch of files containing all the logic that you see in Framework Manager. A package is a set of entries in the IBM Cognos Content Store representing the model logic for actual use. So if you change a model, you should republish the package as well. Give your package a name, make it meaningful and understandable.

20. Include only those items you want end-users to see. According to the logic above, this is only the sub Namespace under the PACKAGE Namespace.

21. Select whatever source you are using. This will allow advanced users to use the corresponding database or other functions.

22. Select the location where the package should reside in Cognos Connection.

23. And publish the package.

24. Apply security if required (this is a whole other topic in itself).

25. No need to generate externalized query subjects unless you want to use the definitions in another tool. Verify the package is probably a good idea.