Setting the Java Virtual Machine (JVM) in Cognos

There are a few settings in Cognos BI that can dramatically improve performance in Cognos BI when using TM1 as a data source. The first of these is to stop Cognos from using the old Bluenose method of querying TM1 and force it to use the native TM1 engine. The next setting that we need to configure is the Java Virtual Machine, or JVM.

Wikipedia defines a Java Virtual Machine  as an abstract computing machine that enables a computer to run a Java program. Cognos BI runs inside a Java Virtual Machine and the JVM needs to be set large enough to satisfy the requirements of Cognos.

How to Set the JVM in Cognos BI

These settings are written for Cognos 10.2.2 where Dynamic Cubes are not deployed.

  • In Cognos BI, open Cognos Administration
  • Go to the Configuration tab
  • Scroll down to the Query Service and click Properties
  • Select the Settings tab
  • Scroll down to find the two Java Virtual Machine settings.
  • Change the “Initial JVM heap size for the query service” to at least 4096 (megabytes)
  • Change the “JVM heap size limit for the query service” to at least 8192 (megabytes)

This information was sourced from our experience and referenced in this page from IBM.

Click here for more information on tuning Cognos and TM1 to work together.

Tuning Cognos BI and TM1 for Maximum Performance

Cognos Business Intelligence and TM1 now work well together, however performance can be dramatically improved by changing the out of the box settings. These tuning changes are not difficult and can significantly enhance both the speed and usability of both tools.

How can BI and TM1 be Integrated

When used together we can use Framework Manager to prepare data from a database before it is loaded into TM1, we can use TM1 cubes as data sources for Cognos BI, we can present TM1 cube Cognos in Cognos Workspace for dashboards and enter data there and we can publish CAFE based reports to Cognos Connection for others to be able to use.

How to Tune Cognos BI and TM1 to Increase Performance

There are a few settings in Cognos BI and TM1 that are not defined out of the box that make the environment work better and deliver the environment outlined above. For BI and TM1 10.2.2 these include the following tuning:

  • Forcing Cognos BI to use the TM1 engine to get maximum performance.
  • Setting the Java Virtual Machine to use enough memory.
  • Setting the Maximum View Size in TM1 so TM1 can grow large enough to return the data needed by BI.
  • Configuring the atom files so TM1 cubes and Perspectives reports can be used directly in BI, including write back.
  • Configuring the TM1 Package Connector to enable the use of Framework Manager packages as data sources.
  • Enable Multi Threaded Queries in TM1 will allow TM1 to use more than one thread (or core) to process a query (or view).

We will go through each of these in different posts. Please click through to see the relevant information on each.

The Pick List – How to Create and Use Picklists in TM1

Picklists in TM1 are a great way for you to ensure that users only “enter” (or in this case select) a value from a standard list of options. For example, you might want a user to enter a three character month like Jan, Feb, Mar etc. You could design your cube to have a text element and then ask users to enter periods in that format. This will work perfectly until someone enters “July” rather than “Jul”. It you then have Rules that are driven off those values, then you’re screwed!

The Solution: Picklists!

To overcome this problem we use Pick lists, or dropdowns as some people call them. These allow us to define a standard list of possible selections, say Jan to Dec, and force the user to select from it.

Methods of using Pick lists

There are a few methods to choose from to create dropdowns in TM1, namely:

  • Static Picklist – hard coded values
  • Dimension Picklist – all values from a dimension are avaialble in the picklist
  • Subset Picklist – only elements in a subset are available in the picklist

Examples of Picklists

The creation of a Picklist is the same, no matter which method you choose. All are entries in an attribute on a specific element. What is entered though, is different:

  • Static: enter “static:option1:option2:option3”, eg “static:Jan:Feb:Mar”
  • Dimension: define a dimension for use, say the Month dimension and then enter “dimension:Dimension_Name”, eg “dimension:Month”.
  • Subset: define a dimension for use and add a subset, say the Month dimension with an “nLevel” subset and then enter “subset:Dimension_Name:Subset_Name”, eg “dimension:Month:nLevel”.

Why would you use each method?

That’s easy. If it a list that will never change, like months of the year, just go with Static. If it might change and your are ok with all elements being available for selection, go with Dimension. If you want a limited group, use the Subset option.

If your list will be dynamic, use a Subset with MDX in it.

Further, if you want to display an Alias rather than the element ID in the pick list, then use a Subset and enable the Alias in the subset.

Use of Null (or Blank) Elements

In TM1 we can’t have an element that is blank. So how do we make a blank option available in a pick list?

Well for the static option, it’s easy. Just insert an additional : before the first option. So in our example above, we would enter “static::Jan:Feb:Mar”.

For dimension or subset based pick lists it is harder. Here we need to create an element with something like “—-” entered and then manage the use of it with downstream rules or TI statements.

Updating Picklist Dimensions

If your TI that updates the source dimension for your picklist deletes and recreates, rather than appends, you could run into data problems. Just be aware of it.

Security

Finally, make sure your users can see the dimension that is used for the pick list values! Otherwise (assuming they have rights to the cube) the report or view will display but the dropdown will not display.

The definitive guide to TM1 Security with examples

Security in TM1 is one of those things that can make a TM1 administrator go crazy over new requirements or over setting up a new user. Things do not get better with reading the documentation, which does not cover all aspects or the security inner workings. In the following post, the TM1 security is peeled layer-by-layer starting from the very basics of cube security and finished with multi-layer multi-group security setup. Continue reading