Cube dependencies
- Apr. 04, 2014
Introduction
As time progresses, TM1 gets more and more additions. For example, StartupChores is a way to run 1 or more chores as the TM1 server is just about to have started up. For example, I use it to clear temporary objects like cube views and dimension subsets with a certain naming convention. Next to that, we can help TM1 in tracking the correct dependencies between cubes. A dependency relationship is established between two cubes when one cube refers to another: either in a business rule, either in a feeder. If you use attributes in rules or feeders, the dependency is set between the relevant }ElementAttribotes control cube. Obviously, TM1 can determine the dependencies on its own, yet not always perfectly well (it depends on the data and model at hand). In the end, giving a hand is always appreciated, isn’t it? We all appreciate that. Therefore, in this article, I will show you a way to automatically set the cube links / dependencies, to supplement TM1 in this area. Adding cube dependencies helps us to reduce the number of blocks in the model due to object locking.
Let us store the information in a plain text file (or a relational DB if you want, that does not change anything meaningful):
Here, we see a Tab-delimited text file. Column A is the base cube, column B is the dependent cube. For example, cube A could be a Sales cube, cube B a Profit & Loss cube. The P&L cube has rules to get the data from the sales cube, while the Sales cube contains feeders towards the P&L cube. Both rules and feeders will lead to a cube dependency.
Now, create a new TI process and connect to the text file as its Data source. Name the 2 variables BaseCube and DependentCube, respectively. The Data tab then sets the dependency:
# Wim Gielis # https://www.wimgielis.com##### # Adding cube dependencies # 04/04/14 #####If( CubeExists( BaseCube ) * CubeExists( DependentCube ) = 0); Itemreject( 'Please review your input on cube names' ); EndIf; AddCubeDependency( BaseCube, DependentCube );
That is all there is. Just a reminder: do not set too many dependencies, as it can impact performance. Hence, do not put all cube names in column B, split out by again all cube names in column B.
More fancy/advanced solutions
Yes, you can go further. You can extend the TI process logic to inspect the rules attached to cubes directly. These rules files are stored as *.rux files and can be edited in a text editor like Notepad++. Loop over all cubes in the model, and for each cube that contains rules, set the *.rux file as the data source of a TI process. In the Data tab you chop up the rules and feeders statements and look for cube names. Yes, I am with you, this is easily said but not simple to do. Yet it is possible :-) Good luck!
Running the process
It is a good practice to run that process to help TM1; if not, you should not have created it in the first place! Certainly after rules maintenance, it is advised to run the process when you made the necessary changes to the text file.
StartupChores
As with every TI process, running this little process can be scheduled. Anyhow you create your process and set up the logic, you can schedule the process to run automatically in a chore. No news there. But since TM1 10.1 you can add the StartupChores property to the TM1s.cfg configuration file for the TM1 server at hand:
StartupChores=SYS_CubeDependencies
The chore (and hence, the process contained within the chore) will be kicked off automatically at server startup. If you like this functionality (I do!) and you want to have more than 1 of those chores, add their names separated by colons:
StartupChores=SYS_CubeDependencies:SYS_DeleteTemporaryObjects
You must restart the TM1 server for this parameter to be picked up when changed.
That’s it for now, stay tuned!
