We have a number of customers that are using multiple TM1 Server to support their models, mainly due to model size and other complexity, splitting them into different smaller TM1 models would allow them more flexibility.
We are planning to talk to them on C3 UX, but one of the very key feature they will definitely ask is if C3 UX would’ve support multi server, so could be the following scenario:
Same Admin Host, Different TM1 Server.
Different Admin Host, Different TM1 Server.
I know Canvas is possible, but since C3 UX require to inject Apliqode to the model in order for it to work, so that gives me a doubt so I am asking here.
This is a really good question. Yes the Apliqo UX does require some injection of Apliqode Framework into the model (it’s actually a small subset of the overall framework) and also some own components of Apliqo UX objects. This is all pretty lightweight and easy to manage.
The real issue is that for the UX we are using TM1 as a content store and at the moment we have some intelligence from the framework built into the content store model to be aware from within the TM1 cube which dimensions to prompt for which cube, which subsets for dimensions and some options to automatically generate predefined MDX via logic in rules. All this logic only works within a single TM1 instance.
So it is true that for the current 1.3 release and the planned 2.0 release Apliqo UX is designed to support a single TM1 instance (which may have several applications).
It is planned to support multiple instances in a future release but exactly how we plan to achieve this isn’t yet worked out. An intermediate solution of central homepage and directing out to instance-based applications should be pretty easy to achieve in the meantime.
Ok, so that means at the moment this is not supported, but most likely will be in future release, got your message.
But please try make this as one of the higher priority feature, and since you are using REST API behind the scene already, so in theory most of the stuff can in theory be able to communicate each other, of course I understand the complexity and the risk of making such a change, but I guess, the earlier having this feature, the less headache we might get when upgrading to a full REST API when this is finally pushing out to many customers.