TM1 Tip 2: Custom Turbo Integrator Processes
A continuation of simplifying your rules within TM1. Our resident financial expert Mike Young this time looks at custom turbo integrator processes.
As a TM1 user or developer, you may already know that the main areas for complexity in TM1 are rules and Turbo Integrator Processes, commonly referred to as “TI”.
For the uninitiated, TI Processes are similar to Rules but differ in 3 important ways:
- Turbo Integrator has a different interface to the Rules Editor
- TI supports runtime Variables without them having to be Measures in a Dimension
- TI has to be run manually or actioned by a chore
Rule vs TI Process
The main advantage of Rules is that they update the model in real-time. Their main disadvantage is that they slow big cubes down.
As a general principle, unless the cubes are very small, Rules should only be used for relatively simple calculations. If you read my previous blog, you will have seen a technique for simplifying complex Rules using dummy Measures.
With TI Processes you can declare dummy variables without having to add them to your Measures dimension which further strengthens the case for TI for complex calculations.
As a relative newcomer to TM1, I was surprised by how little use is made of the native features of TI. In an effort to establish a standard for TI Processes I reviewed the designs of a number of TM1 consultants. It was clear from this exercise that each had their own individual styles. Just about the only thing I saw in common was the wholesale use of custom code.
I wondered why this was. Perhaps the answer lay in the fussy nature of the TI Interface? You pretty much have to get everything right first time or TI will just say “no”, sometimes without adequate explanation. Once you have made a mistake, TI can be unforgiving. There have been occasions where I have had to re-write a TI Process from scratch because the interface would not allow me to edit an error.
I can easily understand why a seasoned consultant would trust their own custom code especially if the standard options via the interface were not flexible enough, for example:
Initially, I was puzzled that the custom code fell between *** Begin Generated Statements *** and *** End Generated Statements *** until I realised snippets of code had been pasted into individual Measures in the Variables tab:
The ‘Generated Statements’ were thus merely a collation of custom code segments entered elsewhere plus a bit at the end actually generated by the interface.
So what’s the problem?
If you are an experienced TM1 developer of many years there is no problem. TM1 allows you to input custom code just about anywhere, so if your client does not prioritize adequate documentation, then you are pretty much guaranteed more work when something goes wrong. Not great for end clients though.
The Triangle TM1 philosophy
Confusing ,undocumented code is not part of the Triangle TM1 philosophy. We believe that the client should be in control of the software and not the other way around.
In this case, the solution is simple. Instead of trying to use TI as an ETL tool, why not use an ETL tool as an ETL tool? In this example, the base data just needs a bit of a tidy up to get it into the right format for TM1. Once the base data is clean, TI is perfect for importing it into TM1:
This time all the code is generated by the machine which means importing data into TM1 is now point-and-click on the User Interface and that can be done by the end client.
Sign up and never miss a blog post from Triangle