Working with private objects

I am trying to come up with a reliable and good solution for the common problem: how do you migrate private objects from 1 TM1 model to another. There is V11 and V12 support that should be feasible.

We are currently migrating several on-premise customers to the IBM cloud, but the idea/shortcomings here goes broader than this situation.

The subject is about syncing/migrating the:

- private subsets

- private views

- private application entries

The private objects can be found scattered around in the TM1 database directory. When it's only private subsets and views, you could rename a set of folders (even though with hundreds of users to migrate, this isn't obvious either). Each user has such a folder for him/her, even when it's empty we are renaming folders for little benefit). Namespaces need to be taken into account, aliases on the }Clients dimension, etc.

For migrating the application entries it's even harder. They can be found anywhere in the }Applications folder of the TM1 data directory. The dimension }ApplicationEntries only contains public objects, no private objects.

Shall we really go through all folders to rename hundreds of folder names ? Shall we write non-trivial PowerShell code and use ExecuteCommand() in Turbo Integrator ? It's not future proof since V12 will take away that option.

What about the TM1 REST API ? It allows to gather information about private objects like application entries, but only on a folder by folder case. I don't seem to be able to say: 'give me all private application entries, their owner, and the type of reference (document)'. When I write loops and issue 1000's of impersonated REST API calls, in a model containing 1000's of application folders, then I could potentially retrieve the information. It takes forever to execute.

Retrieving private subsets and views for all users of a model on all cubes and views, using Impersonation, takes ages to run. I used TM1py to speed up the programming work but the many REST API calls account for a very long runtime.

Impersonation will be out in V12, and also we cannot impersonate an admin user. These and other issues prevent this approach from being successful, despite the fact that the TM1 REST API is presented as the future.

I did not look at Git and lifecycle manager but I am not sure if it will be any good for this exercise.

A move to cloud operation goes in multiple iterations, meaning that this work (or part of the work) can be redone multiple times with lost time as a consequence.

When thinking about this, any migration where the alias of the user or the namespace/IntegratedSecurityMode changes, can pose challenges. In V11 we can still copy/paste files for objects, this will not be possible anymore in V12. The problem will become even bigger in my opinion.

What would be the idea/solution ? A REST API endpoint that lists (loosely speaking):

- object ID

- object name

- path in the applications tree

- object type (subset, view, document/blob, link to process/chore/view/dimension/subset/view/...)

- }externals link in case it's a blob

- object owner (based on how it is saved in the TM1 data directory to be able to make the link

- object size

- ...

Being able to reference the object and migrate easily from TM1 model A to B. User will refresh and can access all of his private objects.

Impersonation or a different way of working should be part of this solution as impersonation is lost in V12.

Thanks !