TM1 Forum

Hi guys,
Pretty sure the answer to my question is "no there isn't!" before I even ask this, but going to ask anyway in slim hope I'm missing something.


Question In Brief:
Is there anyway to override TM1's default error-abort behavior when using the alias of an existing element (instead of principalName) in an ElementInsert or ComponentAdd function?



Context of Question
Unfortunately I have a situation where our datawarehouse have changed a primary key on me. The are changing a four digit Business Unit into a three digit business unit. (PLML becomes PLM). This business unit exists as a rollup in many dimensions, as well as a leaf in the business unit dimension. Thankfully it is not hard-coded into any rules, however, there is quite a LOT of code in a LOT of different places which could be performing ElementInsert and ComponentAdd (both Dimension and Hierarchy variants) in the existing code base, and it performs the inserts and adds without any pre-checks.

Merging the two existing elements into one isn't really an issue. I can migrate the data and I can use SwapPrincipalName to retire one element and then make it an alias of the other. In fact I have done all that already.

The problem arises when datasources continue to pass me the old four-digit key into a process performing an ElementInsert or ComponentAdd function. As you'd expect, I always get "element is an alias for another element in dimension" error of course and then everything aborts in spectacular fashion!

I know I can bypass these errors by:
- Performing a DIMIX and only doing the functions if DIMIX returns 0 (although can't really do that in the ComponentAdds else leaves will be orphans)
- Use vBU = DimensionElementPrincipalName( 'dimension', vBU ) in all the relevant spots. (Solution I'll probably use)
- Straight up IF vBU @= PLML THEN vBU = PLM.

However, what would be the ultimate would be if TM1 recognised that alias as an existing element and just skipped over the error and let me keep going. I sincerely doubt there is any setting which will let me do this (there's at least none that I know of). But I wanted to ask anyway before resigning myself to just sitting down and needing to examine the entire architecture and put all these pre-checks / nameSwaps everywhere.


Thanks in advance guys if anyone can help and/or verify that I'm just hard out of luck. (I'm leaning towards being out of luck).

Hello,

I don't think that exists. You will need to change the code.

I would also like some kind of "On Error Resume Next" as we have in VBA or "Try...Catch" in other programming languages. But in TM1 it does not exist.

Thanks for your response Wim.

Sadly it aligns with exactly what I think as well. I did bite the bullet and work late into the evening fully analyzing the server and putting DimensionElementSwapPrincipalName in all the spots my analysis showed it was needed. Was pretty laborious and I haven’t tested it all yet, but at least I’m future-proofed now if the datawarehouse ever does this to me again with more BUs down the road!

And at least I feel better knowing I didn’t pass over a smarter, simpler solution.

Would definitely be nice to have a resume-next or try-catch feature as you mention though. As great as TM1 is, there’s definitely some basic coding features you miss if you’ve spent too long in other languages. At my current workplace we use Arc as our TM1 IDE and now I don’t know how I could survive without TM1 debugging if they took it away from me. Crazy they don’t build debugging into TM1 directly when the debug hooks are there!

Anyway… that’s getting off topic.

Thanks again for your response!

rAzoR wrote: ↑Wed Sep 22, 2021 1:16 pmAt my current workplace we use Arc as our TM1 IDE and now I don’t know how I could survive without TM1 debugging if they took it away from me. Crazy they don’t build debugging into TM1 directly when the debug hooks are there!

Euh... you do know TI has a debugger, don't you ? It's called the TIDebugger and can be found online. It's a small Java application.

Wim Gielis wrote: ↑Wed Sep 22, 2021 1:25 pm Euh... you do know TI has a debugger, don't you ? It's called the TIDebugger and can be found online. It's a small Java application.

Well I do now!!

I knew when I typed that, I would be opening myself to showing my ignorance. I actually haven't checked in on whether TI's have any debugging for a couple of years now since the whole TM1 to PA movement. I've had other tools at some jobs, and then been on others where they lock access rights down so hard that even getting the ability the log into their systems at all is a battle, and installing anything additional was out of the question.

However, seems like it's been out for quite a while. I'm amazed I've never heard people talking of it or using it!

I have no use for it these days as have other tools, but I'm still going to go read up on it regardless. Thanks again!

I don't think the TIDebugger which IBM released on (the now defunct) DeveloperWorks can really be compared to what is available in Arc. The TIDebugger is an unfinished prototype.