I’m going to start this post assuming you have already CREATED a model / library in Cognos Analyst and are familiar with Cognos Analyst models in terms of modeling and creating an application. Once the Analyst model / library is ready, the end users must be able to access the cubes, enter data, manipulate data and perform all manner of tasks. This is done via the web-based interface which is basically where contributor comes in. The Contributor Application is basically a published version of the Analyst model. As a published model, it is different or enhanced from the model / library in the following ways:
1. Provides a web-based front-end to the end users to access the application(s)
2. e.List creation and maintenance (Analyst can use a dummy placeholder for modeling purpose)
3. Allows user access and security settings
4. Data Validations
5. Translations (or Aliases in Hyperion Planning jargon as far as I know)
Essentially the model from analyst is copied into a contributor application so the underlying structure is the same. The other options like security, e.List, data validations, etc. which are not part of Analyst are managed here and the application is made available to the end users.
The modeler or designer can continue to work on Analyst without impacting the published application until the changes are synced to the contributor application. Even then the changes are not reflected until the Development version is migrated to the Production version (a process that is known as GTP – Go To Production).
I’m going to start this post assuming you have already CREATED a model / library in Cognos Analyst and are familiar with Cognos Analyst models in terms of modeling and creating an application. Once the Analyst model / library is ready, the end users must be able to access the cubes, enter data, manipulate data and perform all manner of tasks. This is done via the web-based interface which is basically where contributor comes in. The Contributor Application is basically a published version of the Analyst model. Continue reading →
I was trying to be creative and think up of ways to show the analytical capabilities of the Hyperion Planning system to demonstrate to a client (who had strongly suggested that these capabilities would play a very important role in their evaluation of a budgeting and planning solution) and came up with one approach that I’d like to share here. Continue reading →
IBM Cognos TM1 is enterprise planning software used to implement collaborative planning, budgeting and forecasting solutions, as well as analytical and reporting applications. Similar to Hyperion Essbase, TM1 is a multidimensional data store however it only supports data storage at the “leaf” level.
Having worked with Hyperion Planning solution, I decided to explore the Cognos TM1 offering. The latest version is 9.5 which came out February 9, 2010 and there has been some considerable improvements – the most visible being TM1 Contributor which is a web-based front end. Previously TM1 was basically managed through the Microsoft Excel interface and the TM1 Architect.
In the subsequent posts I will be taking a look at the Cognos TM1 version 9.5 offering starting with the installation.
For the ones who have started using BPMA to manage the outline in Hyperion Planning, there are two options to create the dimensions. Either make the .ads file or populate the Interface tables with the relevant information.
Maintaining and developing an .ads file is rather cumbersome and updating the Master version takes considerably more time as compared to pulling the data from the Interface tables.
After I figured out the issue with OpenLDAP, I recently saw a similar problem with my Essbase service. However many times I tried to start it, it would just shutdown immediately. This could have been a result of the improper shutdown I mentioned as a reason for the OpenLDAP database to get corrupted.
Fixing essbase is not without losses. I discovered that the security file had been corrupted and hence essbase shutdown soon after I started it.
I went to my application backup folder and copied the essbase.sec file back to the current deployment. The essbase.sec needs to be replaced with a working version. When I started the service again, it was back up and running.
Please note that if you don’t have a current backup, then a lot of the security information that has changed since you’re last backup will need to be done again. I had a very recent backup so I was saved from this hassle.
A server hosting Hyperion Planning – System 9 was started up. The OpenLDAP and Shared Services were set to start automatically. They didn’t start automatically. When they were started manually they gave an error and failed to start.
I discovered that the OpenLDAP service was the cause of the problem since it did not start. The server had been improperly shutdown because of a power outage. This sudden shutdown had caused the OpenLDAP database to crash and hence it was unable to restart.