2020 has been an interesting year for us !
In Realtime Scenarios, sometimes we get the requirement to correct/update the Principal element name(s) in a Dimension. This would relatively be easy if the dimension is being used in one cube. In case where the dimension is used in multiple cubes, updating element name(s) without affecting the data of all the cubes, is a bit challenging. Either we export data of the cube and change the element name(s), then import the data and validate cube before and after the element change. Or deploy the Bedrock process, which requires the reboot of Instance.
Many Developers like to stay away from the topic call Feeders in TM1 / Planning Analytics world but on the other side we cannot avoid Feeders as it plays the most crucial role while Modelling the data flow.
Sometimes, dealing with Feeders may result in 2 major issues:
1. Over Feeding
- Performance issue.
- RAM consumption.
2. Under Feeding
- Totalling issue
To avoid this there is a small concept called Feeder-Less Feeding where we can avoid writing Feeders and Feeder related issues.
Feeder-Less Feeding is a Concept of Modelling the data in such a way where you write a Rule in TM1 Rule file but you don’t need to write feeders for it, still using ‘Skipchecks’ (By having the sparse consolidation algorithm on).
To show the concept of feeder-less feeding we will proceed with an example where we are computing Travel Cost with Headcount and Rate.
Travel Cost = Headcount * Travel Rate
Here we can say Headcount is the Driver of Travel Cost and if we want to feed, we would have fed the Travel Cost with Headcount.
So, element Travel Cost and Driver: Headcount should be in same dimension and Driver should be the child of its Rule Driven element as below,
The Rule element should be the Parent (Consolidation) of its Driver to get fed automatically.
Now we have inputted some filled values in the Headcount and Travel Rate.
Here we have kept the Rates in the Same Cube to keep it simple.
You can have the Rates from the same Cube as well as from another Rate Cube depends on your way of Modelling.
The simple Cube Rule we can have for current formula and the resulted Value as below.
DataFusion is a TM1 connector developed by Octane. It was borne out of the frustration clients were facing extracting data out of their IBM Planning Analytics application into other enterprise Reporting tools like Power BI, Tableau and Qlik. Typically this was set up as a manual task that required an IT or Finance person to drop a csv and upload into Reporting tools. This created a number of issues. Firstly it required the operator to ensure that the correct slab of data has been captured and uploaded. It also created a risk as end users would have to rely on operator to perform this task on as regular basis as required. This created a single person dependency and if he or she is on leave the data may not get refreshed as teams scramble to find out how to do this task.
REST stands for REpresentational State Transfer. It is web standard-based architecture and uses HTTP Protocol. TM1 REST API is a type of web service which can be used to perform create, read, update, and delete operations on TM1 objects or data. Therefore, we can maintain a TM1 model, manage TI processes, chores, dimensions and query data that is stored in the model.
I recently came across a problem statement at a client site and thought it would make good content to share for my blog article so without further ado here it goes...
In this article I would like to share a very useful tip on how we can use different methods to adding images in Planning Analytics Workspace; one that is very well known, one that is lesser-known and one that is relatively unknown. I intend to touch base on the first two methods while focusing more on the latter one.
In light of the heightened level of concern related to the spread of Coronavirus (COVIS-19) we want to provide an update on the actions Octane is taking to safeguard the health-being of our clients, our associates and their families.
Gone days, where we had no control/alerts mechanism on the TM1 database, CPU/memory it consumes, react at the nick of the moment before TM1 server crashes.