TM1py upload of different cubes

123 views Asked by At

Im very new to Tm1 and have to implement a new function in my code. Is there any way to undo your last action?

For better understanding ill write an example: I have 8 different cubes and i will upload one after one. If one cube is not able to be uploaded all the others shouldnt be uploaded too. Every cube which is already being uploaded should get a reset to the previous state.

Is there a way to implement it?

2

There are 2 answers

0
Wuzardor On

You have to inbriquate your 8 loading process in a master (others are slaves). If you have a condition that make one or your cube unuploadable you use the ProcessError function. In the master process, you fetch the result of the execution of each slave process. If one is in error, you use the processerror function (in the master). All the chain won't be commited.

1
mrfrogger On

The answer above from Wuzardor provides an approach using TI processes but your question seems to suggest you're using TM1py/Python to do the upload to TM1, either directly, or by triggering TI processes through the REST API.

In general, there's no easy way to roll back changes to cube data. However, it should be simple enough to structure your Python code such that the existence and validity of all the load files is established before you push anything to any of your cubes. It's difficult to suggest the best approach without more details about what you're trying to achieve and how.

Updated in response to OP comment:

OK, while it's not clear what IT isn't cooperating with, but if you are unable to verify the source prior to extracting it, you can always load it first to a staging cube, where the data can be checked, before copying anything to your main cubes. Depending on what issues you tend to face with the data, you might be able to automate this check or might need to rely on a human looking at it. Either way, just donĀ“t overwrite your historic data until you've checked the new data.

Furthermore, you might want to think about your overall design. Might it make sense to retain a copy of the previous data in the cubes anyway? Why not build your cubes such that you can keep the history, rather than re-overwriting each time? Finding a sensible design really depends on the details of your application but you might benefit from looking at it with fresh eyes.

Cheers Alex