What exactly does FM reference when publishing a TM1 package?

[JGirl]

Hi All,

I'm new to using TM1 cubes as a C8 datasource (although not new to Cognos)

I've published a package from FM that exposes the TM1 cubes and it all works well up to a point where the TM1 dimensional data changes.  I'm getting the error message below when trying to create a NEW analysis in AS (ie. not opening an existing report with hard-coded MUNs etc, but trying to create a new blank analysis from scratch).

I try to expand one of the dimensions in the cube, and get the error message below:
OP-ERR-0181 At least one invalid member reference was encountered in the query.'[Activity].[Cost Element].[Cost Element]->:[TM].[Cost Element].[Cost Element].[@MEMBER].[All Cost Elements]'

So - it looks like the 'All Cost Elements' root member in the dimension has changed in TM1, which is OK, but I don't understand why Cognos would be hanging onto this MUN when I'm trying to create a new analysis.  I've tried clearing the cache, closing the browser, rebooting etc, but the issue for me is only resolved by republishing the package.

I'd always imagined that publishing the package was a one-off thing, then it would always retrieve the latest structure of the cube.  Is this assumption correct or not? 

It seems unreasonable to me that if the data in TM1 is potentially changing on a daily basis, that I would need to republish the package on a daily basis as well?  Surely the package definition itself wouldnt hang onto MUNs, right??!!

Cheers,
J

[cognostechie]

I'd always imagined that publishing the package was a one-off thing, then it would always retrieve the latest structure of the cube.  Is this assumption correct or not? 

The package is a run-time version of the metadata (in this case the TM1 metadata, not the TM1 cube). The TM1 cube contains the data and the package contains reference to the metadata. Hence, if there is any change in the cube metadata, that will require re-publishing the package.

When the cube gets refreshed every day/night, you do not need to re-publish the package because the metadata did not change.

[JGirl]

Yes - That is what I would have expected, except it was only the MUNs of the data items in the dimension that changed (from the root member all the way down), not the metadata structure of the dimension.  Yet I had to republish to stop the error message appearing.

I was wondering that if because the dimension's hierarchy is ragged (and in this case it doesnt make sense to expose the levels from TM1 - only the member tree) it is treated slightly differently when published to a dimension with defined levels?

Anyone?

[cognostechie]

Keep in mind that MUNs are considered part of the package. Data is not part of the package. I don't know whether you did this in Turbo Integrator or in Perspectives but since the MUNs changed, the package needs to be re-published regardless of how the dimesion is structured. The same applies to Transformer and FM packages as well.   

[JGirl]

Interesting.  I'm dont have much to do with TM1 (apart from accessing the cubes to write reports in RS & AS)

How does this work in the real world?  Obviously the ideal scenario is to have MUNs never change.  But that isn't always possible when they are data-driven, and quite often the report authors wouldn't know if the source data has changed triggering an update to MUNs, and requiring a republish of the package.

Although it is possible that my memory is a little dusty, I actually don't recall having the same problems with transformer cubes.

[cognostechie]

First of all, I am not sure if the MUNs changing is actually your problem. Can't say much without looking at your FM Model and the TM1 cube.

Since you are not involved in modelling, it will be hard to explain. This is a whole chapter but in brief, there is a way to tell the OLAP modelling tools how to generate the MUNs which takes care of this problem. This is mainly used in case of slowly changing dimensions.

That being said, since you are making a new report in AS, I don't think MUNs are actually your problem. In AS, you use only the levels when you make a report, not the data inside those levels so even if the data moved from one level to another, it shouldn't be a problem particularly when you are making a NEW report.

There is something that changed in your TM1 model that needs re-publishing.

[JGirl]

"That being said, since you are making a new report in AS, I don't think MUNs are actually your problem. In AS, you use only the levels when you make a report, not the data inside those levels so even if the data moved from one level to another, it shouldn't be a problem particularly when you are making a NEW report."

Im pretty sure the MUNs are the problem.  I'm thinking that maybe the issues are because there are not levels exposed in the package for all of the dimensions - Those that are ragged only show the member folder and the member tree, and a handful of TM1 attributes, but no levels in RS) .  The balanced dimensions like time have levels such as year and month published, but the unbalanced (ie. ragged) dimensions do not (and i'm not sure it makes sense to publish levels to be honest).

Any more thoughts?  I guess what I'm looking to understand is not so much how things are controlled from TM1, but what FM is actually publishing in the package (so then I can figure out how to work around it!)

[cognostechie]

Technically, FM is supposed to be a run-time version of the FM Model. So, it will publish the full path of the objects in the layer that is being published whether the Model is relational or OLAP. As you know, the full path of an object becomes the MUN in the report. 

[Arsenal]

I have no experience in TM1 but have Power Cube experience and it was always the same issue then too - if the "dimensional structure" changes then the package must be republished to see the new changes and it's also possible that reports will need to be updated if you have filters (in RS for example) or analysis reports (in AS) that reference the unique values in this dimension...or MUN as the fancy name goes.

If you let Transformer (or TM1 in your case) decide these source values or MUN's then there are higher chances of these values changing with fresh cube builds. If the source values are from a dimension lookup table then those values will be much more stabler and change infrequently, so that is one way to avoid this scenario - have your dimensional source coming from tables. With this solution, the problem of SCD's still remain and you can't really avoid breakges from time to time but it won't be as frequent as when Transformer/TM1 is deciding the source or MUN values

[cognostechie]

I take back part of my statement about Transformer. It depends on the version.

In 8.4 and 10, you do NOT have to re-publish the package if you made changes to the dimensional structure. The pcactivate utility automatically updates and points to the newer version of the cube.
If you made changes to MUNs, you would probably need to re-publish.

This presumes that the Powercube was published using Transformer, not Framework Manager.