Planning Analytics

Does anyone know of a way to enable ExecuteHTTPRequest to use the same session (or named user) as the TI process that is calling it?  I am looking for an option that can reuse the current credentials, or an internal route that allows access to the TM1 Rest API directly. I want to avoid having to pass or manage credentials, especially if a REST call is being made to the same host database.

The use case I am specifically targeting is cache management. Since ViewConstruct does not support MDX views, there is no direct way to force TM1 to create a stargate(s) for an MDX view, without executing the MDX query directly. However, there are a number of other use cases where you may want to interact with the API via TI.

I have not tried but have you looked at grabbing the Cookie/ Session from HttpResponseGetHeader and re-using that?

For PAaaS I store the token in a Client cube and schedule a chore to clear the token after 60 minutes - each subsequent call to the API then checks if the token exists and if it doesn't then fires a request for another token.

The Multi Cloud Service Platform PAaaS now uses Base64 encoded string of "apikey:<APIKey generated within Workspace>" which is a set and forget operation.

I've not checked if multiple requests triggers multiple sessions as yet

Does anyone know of a way to enable ExecuteHTTPRequest to use the same session (or named user) as the TI process that is calling it?  I am looking for an option that can reuse the current credentials, or an internal route that allows access to the TM1 Rest API directly. I want to avoid having to pass or manage credentials, especially if a REST call is being made to the same host database.

The use case I am specifically targeting is cache management. Since ViewConstruct does not support MDX views, there is no direct way to force TM1 to create a stargate(s) for an MDX view, without executing the MDX query directly. However, there are a number of other use cases where you may want to interact with the API via TI.

I believe that @Ryan Clapp wants to reuse the current TI process session instead of the last HTTP request.

AFAIK it is not possible, unless you find a way to get the current TM1SessionId.

Adding such functionality would be incredibly useful and I'd like to know the PA development team's thoughts on the matter.

I have not tried but have you looked at grabbing the Cookie/ Session from HttpResponseGetHeader and re-using that?

For PAaaS I store the token in a Client cube and schedule a chore to clear the token after 60 minutes - each subsequent call to the API then checks if the token exists and if it doesn't then fires a request for another token.

The Multi Cloud Service Platform PAaaS now uses Base64 encoded string of "apikey:<APIKey generated within Workspace>" which is a set and forget operation.

I've not checked if multiple requests triggers multiple sessions as yet

Does anyone know of a way to enable ExecuteHTTPRequest to use the same session (or named user) as the TI process that is calling it?  I am looking for an option that can reuse the current credentials, or an internal route that allows access to the TM1 Rest API directly. I want to avoid having to pass or manage credentials, especially if a REST call is being made to the same host database.

The use case I am specifically targeting is cache management. Since ViewConstruct does not support MDX views, there is no direct way to force TM1 to create a stargate(s) for an MDX view, without executing the MDX query directly. However, there are a number of other use cases where you may want to interact with the API via TI.

Another function with a similar signature would be super helpful. Something like this

ExecuteAPIRequest('POST', '/tm1.ExecuteMDX', ...);

I believe that @Ryan Clapp wants to reuse the current TI process session instead of the last HTTP request.

AFAIK it is not possible, unless you find a way to get the current TM1SessionId.

Adding such functionality would be incredibly useful and I'd like to know the PA development team's thoughts on the matter.

I have not tried but have you looked at grabbing the Cookie/ Session from HttpResponseGetHeader and re-using that?

For PAaaS I store the token in a Client cube and schedule a chore to clear the token after 60 minutes - each subsequent call to the API then checks if the token exists and if it doesn't then fires a request for another token.

The Multi Cloud Service Platform PAaaS now uses Base64 encoded string of "apikey:<APIKey generated within Workspace>" which is a set and forget operation.

I've not checked if multiple requests triggers multiple sessions as yet

Does anyone know of a way to enable ExecuteHTTPRequest to use the same session (or named user) as the TI process that is calling it?  I am looking for an option that can reuse the current credentials, or an internal route that allows access to the TM1 Rest API directly. I want to avoid having to pass or manage credentials, especially if a REST call is being made to the same host database.

The use case I am specifically targeting is cache management. Since ViewConstruct does not support MDX views, there is no direct way to force TM1 to create a stargate(s) for an MDX view, without executing the MDX query directly. However, there are a number of other use cases where you may want to interact with the API via TI.

Hold that thought, that's the world backwards not;-?

I admire all your creativity but isn't what you are really saying that TI is simply to limited in functionality for what people ended up using it for (for a long time already) and what you'd really want is effectively be able to do in TI what you can do when using the REST API as well?

And I'll argue the same is true for the REST API where there are still things you probably can do using REST but where TI is the tool of choice because it is designed specifically for the task and in, especially data load and extract scenarios therefore, it performs better? 

We've had plans for improving the REST API in this area, so what if, hypothetically, we could bring the TI 'language' to a new level and expose it to the same 'model' that is exposed in the REST API but without the overhead of it being a REST request (read: dealing with HTTP requests and JSON)?

To me the 'secrets management' is a separate topic and an issue we have already with people getting creative with using ExecuteHttpRequest. TM1 does not want to be in the business of secrets management, albeit I can never, nor would I try to, stop people from storing secrets in TM1. Instead we have are in the process in providing means to enable the passing of 'secrets', or more generically session variables (think of them as environment variables), which can represent things like tokens, API-keys etc., which will be available for use in TI. 

Depending on the environment you'd be running TM1 v12 in, either as part of a PAaaS installation, directly as a service on CPD or, shortly, the stand-alone version running natively on Windows or Linux, the application interacting with TM1 could then pass a token or an API key that would then allow some TI script to gain access to a proper secrets management service which could provide the required secrets for individual service such TI might want to interact with (or you'd pass any and all you need as variables directly but that's typically not presumed to be safe and not best practice).   

 Thought;-?

Another function with a similar signature would be super helpful. Something like this

ExecuteAPIRequest('POST', '/tm1.ExecuteMDX', ...);

I believe that @Ryan Clapp wants to reuse the current TI process session instead of the last HTTP request.

AFAIK it is not possible, unless you find a way to get the current TM1SessionId.

Adding such functionality would be incredibly useful and I'd like to know the PA development team's thoughts on the matter.

I have not tried but have you looked at grabbing the Cookie/ Session from HttpResponseGetHeader and re-using that?

For PAaaS I store the token in a Client cube and schedule a chore to clear the token after 60 minutes - each subsequent call to the API then checks if the token exists and if it doesn't then fires a request for another token.

The Multi Cloud Service Platform PAaaS now uses Base64 encoded string of "apikey:<APIKey generated within Workspace>" which is a set and forget operation.

I've not checked if multiple requests triggers multiple sessions as yet

Does anyone know of a way to enable ExecuteHTTPRequest to use the same session (or named user) as the TI process that is calling it?  I am looking for an option that can reuse the current credentials, or an internal route that allows access to the TM1 Rest API directly. I want to avoid having to pass or manage credentials, especially if a REST call is being made to the same host database.

The use case I am specifically targeting is cache management. Since ViewConstruct does not support MDX views, there is no direct way to force TM1 to create a stargate(s) for an MDX view, without executing the MDX query directly. However, there are a number of other use cases where you may want to interact with the API via TI.

Hold that thought, that's the world backwards not;-?

I admire all your creativity but isn't what you are really saying that TI is simply to limited in functionality for what people ended up using it for (for a long time already) and what you'd really want is effectively be able to do in TI what you can do when using the REST API as well?

And I'll argue the same is true for the REST API where there are still things you probably can do using REST but where TI is the tool of choice because it is designed specifically for the task and in, especially data load and extract scenarios therefore, it performs better? 

We've had plans for improving the REST API in this area, so what if, hypothetically, we could bring the TI 'language' to a new level and expose it to the same 'model' that is exposed in the REST API but without the overhead of it being a REST request (read: dealing with HTTP requests and JSON)?

To me the 'secrets management' is a separate topic and an issue we have already with people getting creative with using ExecuteHttpRequest. TM1 does not want to be in the business of secrets management, albeit I can never, nor would I try to, stop people from storing secrets in TM1. Instead we have are in the process in providing means to enable the passing of 'secrets', or more generically session variables (think of them as environment variables), which can represent things like tokens, API-keys etc., which will be available for use in TI. 

Depending on the environment you'd be running TM1 v12 in, either as part of a PAaaS installation, directly as a service on CPD or, shortly, the stand-alone version running natively on Windows or Linux, the application interacting with TM1 could then pass a token or an API key that would then allow some TI script to gain access to a proper secrets management service which could provide the required secrets for individual service such TI might want to interact with (or you'd pass any and all you need as variables directly but that's typically not presumed to be safe and not best practice).   

 Thought;-?

Another function with a similar signature would be super helpful. Something like this

ExecuteAPIRequest('POST', '/tm1.ExecuteMDX', ...);

I believe that @Ryan Clapp wants to reuse the current TI process session instead of the last HTTP request.

AFAIK it is not possible, unless you find a way to get the current TM1SessionId.

Adding such functionality would be incredibly useful and I'd like to know the PA development team's thoughts on the matter.

I have not tried but have you looked at grabbing the Cookie/ Session from HttpResponseGetHeader and re-using that?

For PAaaS I store the token in a Client cube and schedule a chore to clear the token after 60 minutes - each subsequent call to the API then checks if the token exists and if it doesn't then fires a request for another token.

The Multi Cloud Service Platform PAaaS now uses Base64 encoded string of "apikey:<APIKey generated within Workspace>" which is a set and forget operation.

I've not checked if multiple requests triggers multiple sessions as yet

Does anyone know of a way to enable ExecuteHTTPRequest to use the same session (or named user) as the TI process that is calling it?  I am looking for an option that can reuse the current credentials, or an internal route that allows access to the TM1 Rest API directly. I want to avoid having to pass or manage credentials, especially if a REST call is being made to the same host database.

The use case I am specifically targeting is cache management. Since ViewConstruct does not support MDX views, there is no direct way to force TM1 to create a stargate(s) for an MDX view, without executing the MDX query directly. However, there are a number of other use cases where you may want to interact with the API via TI.

More powerful TI would be my preference, but on the subject of wants then I start thinking about:

• ExecutePython()
• ExecuteJavascript()
• ExecuteGo()
• etc..

For now I'm champing at the bit for JSON TI Datasource/ Functions which are tagged for Q1 release!

Hold that thought, that's the world backwards not;-?

I admire all your creativity but isn't what you are really saying that TI is simply to limited in functionality for what people ended up using it for (for a long time already) and what you'd really want is effectively be able to do in TI what you can do when using the REST API as well?

And I'll argue the same is true for the REST API where there are still things you probably can do using REST but where TI is the tool of choice because it is designed specifically for the task and in, especially data load and extract scenarios therefore, it performs better? 

We've had plans for improving the REST API in this area, so what if, hypothetically, we could bring the TI 'language' to a new level and expose it to the same 'model' that is exposed in the REST API but without the overhead of it being a REST request (read: dealing with HTTP requests and JSON)?

To me the 'secrets management' is a separate topic and an issue we have already with people getting creative with using ExecuteHttpRequest. TM1 does not want to be in the business of secrets management, albeit I can never, nor would I try to, stop people from storing secrets in TM1. Instead we have are in the process in providing means to enable the passing of 'secrets', or more generically session variables (think of them as environment variables), which can represent things like tokens, API-keys etc., which will be available for use in TI. 

Depending on the environment you'd be running TM1 v12 in, either as part of a PAaaS installation, directly as a service on CPD or, shortly, the stand-alone version running natively on Windows or Linux, the application interacting with TM1 could then pass a token or an API key that would then allow some TI script to gain access to a proper secrets management service which could provide the required secrets for individual service such TI might want to interact with (or you'd pass any and all you need as variables directly but that's typically not presumed to be safe and not best practice).   

 Thought;-?

Another function with a similar signature would be super helpful. Something like this

ExecuteAPIRequest('POST', '/tm1.ExecuteMDX', ...);

I believe that @Ryan Clapp wants to reuse the current TI process session instead of the last HTTP request.

AFAIK it is not possible, unless you find a way to get the current TM1SessionId.

Adding such functionality would be incredibly useful and I'd like to know the PA development team's thoughts on the matter.

I have not tried but have you looked at grabbing the Cookie/ Session from HttpResponseGetHeader and re-using that?

For PAaaS I store the token in a Client cube and schedule a chore to clear the token after 60 minutes - each subsequent call to the API then checks if the token exists and if it doesn't then fires a request for another token.

The Multi Cloud Service Platform PAaaS now uses Base64 encoded string of "apikey:<APIKey generated within Workspace>" which is a set and forget operation.

I've not checked if multiple requests triggers multiple sessions as yet

Does anyone know of a way to enable ExecuteHTTPRequest to use the same session (or named user) as the TI process that is calling it?  I am looking for an option that can reuse the current credentials, or an internal route that allows access to the TM1 Rest API directly. I want to avoid having to pass or manage credentials, especially if a REST call is being made to the same host database.

The use case I am specifically targeting is cache management. Since ViewConstruct does not support MDX views, there is no direct way to force TM1 to create a stargate(s) for an MDX view, without executing the MDX query directly. However, there are a number of other use cases where you may want to interact with the API via TI.