Planning Analytics

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Hi Ardian,

The drill process should be a fairly simple one, or is on my side:

Prolog:

DataSourceType = 'CHARACTERDELIMITED';DataSourceNameForServer=pFilename;

Epliog;

ReturnCSVTableHandle;

pFilename in my case happens to be an element from a dimension containing TM1ProcessError logs.
Performing the drill then passes the element to the parameter and that is used as the data source.
I did remove the path statement I join as a prefix to pFilename to keep the example simple.
I also removed a lookup to a cell where the user can specify the DatasourceASCIIDelimiter, again to keep the example simple.

HTH

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Hi George,

I just tried to create a very simple Drill Process as per your case and I still get the same error.

As soon as I click on the Drill --> Open CSV File (as per screenshots attached) I get the error and the CSV File remains locked

Ardian

Hi Ardian,

The drill process should be a fairly simple one, or is on my side:

Prolog:

DataSourceType = 'CHARACTERDELIMITED';DataSourceNameForServer=pFilename;

Epliog;

ReturnCSVTableHandle;

pFilename in my case happens to be an element from a dimension containing TM1ProcessError logs.
Performing the drill then passes the element to the parameter and that is used as the data source.
I did remove the path statement I join as a prefix to pFilename to keep the example simple.
I also removed a lookup to a cell where the user can specify the DatasourceASCIIDelimiter, again to keep the example simple.

HTH

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Hi Ardian,

The drill process should be a fairly simple one, or is on my side:

Prolog:

DataSourceType = 'CHARACTERDELIMITED';DataSourceNameForServer=pFilename;

Epliog;

ReturnCSVTableHandle;

pFilename in my case happens to be an element from a dimension containing TM1ProcessError logs.
Performing the drill then passes the element to the parameter and that is used as the data source.
I did remove the path statement I join as a prefix to pFilename to keep the example simple.
I also removed a lookup to a cell where the user can specify the DatasourceASCIIDelimiter, again to keep the example simple.

HTH

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Hello George, 

is it possible to rename or to define the names of the cells in ASCII afterwards or does it stay unchanged? 
Thanks in advance. 

Hi Ardian,

The drill process should be a fairly simple one, or is on my side:

Prolog:

DataSourceType = 'CHARACTERDELIMITED';DataSourceNameForServer=pFilename;

Epliog;

ReturnCSVTableHandle;

pFilename in my case happens to be an element from a dimension containing TM1ProcessError logs.
Performing the drill then passes the element to the parameter and that is used as the data source.
I did remove the path statement I join as a prefix to pFilename to keep the example simple.
I also removed a lookup to a cell where the user can specify the DatasourceASCIIDelimiter, again to keep the example simple.

HTH

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Hi Vitalij, Not that I am aware of as the data is simply being represented in a grid.

Hello George, 

is it possible to rename or to define the names of the cells in ASCII afterwards or does it stay unchanged? 
Thanks in advance. 

Hi Ardian,

The drill process should be a fairly simple one, or is on my side:

Prolog:

DataSourceType = 'CHARACTERDELIMITED';DataSourceNameForServer=pFilename;

Epliog;

ReturnCSVTableHandle;

pFilename in my case happens to be an element from a dimension containing TM1ProcessError logs.
Performing the drill then passes the element to the parameter and that is used as the data source.
I did remove the path statement I join as a prefix to pFilename to keep the example simple.
I also removed a lookup to a cell where the user can specify the DatasourceASCIIDelimiter, again to keep the example simple.

HTH

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

maybe you are right, George. 
Do you think, it would be necessary, to have or to get the possibility of changing the column and row names? 

@Vlad Didenko, 
do you have this functionality already? 

Hi Vitalij, Not that I am aware of as the data is simply being represented in a grid.

Hello George, 

is it possible to rename or to define the names of the cells in ASCII afterwards or does it stay unchanged? 
Thanks in advance. 

Hi Ardian,

The drill process should be a fairly simple one, or is on my side:

Prolog:

DataSourceType = 'CHARACTERDELIMITED';DataSourceNameForServer=pFilename;

Epliog;

ReturnCSVTableHandle;

pFilename in my case happens to be an element from a dimension containing TM1ProcessError logs.
Performing the drill then passes the element to the parameter and that is used as the data source.
I did remove the path statement I join as a prefix to pFilename to keep the example simple.
I also removed a lookup to a cell where the user can specify the DatasourceASCIIDelimiter, again to keep the example simple.

HTH

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Hi @Vitalij Rusakovskij, 

Drill-through functionality is available via the TM1 REST API.
For files, the server returns both column headers and data.
If the TI process has access to the file, you can customize both the headers and the data as needed.
Re-reading the previous posts... @Edward Stuart's intention was to leverage the drill through functionality to automatically display the custom log file when the process finishes execution, but the UI does not open the drill through viewer if you simply call the drill process it through the REST API.

There are a few ways we could easily add this functionality to SPACE, for example:

1. A button to quickly display the contents of a custom log file located on the TM1 server.

2. A custom logging utility that TI processes can leverage (via an API call to the SPACE server), combined with an embedded log viewer embedded into PAW, offering features like filtering and search.

Let me know your thoughts or if you'd like to collaborate on a prototype!

maybe you are right, George. 
Do you think, it would be necessary, to have or to get the possibility of changing the column and row names? 

@Vlad Didenko, 
do you have this functionality already? 

Hi Vitalij, Not that I am aware of as the data is simply being represented in a grid.

Hello George, 

is it possible to rename or to define the names of the cells in ASCII afterwards or does it stay unchanged? 
Thanks in advance. 

Hi Ardian,

The drill process should be a fairly simple one, or is on my side:

Prolog:

DataSourceType = 'CHARACTERDELIMITED';DataSourceNameForServer=pFilename;

Epliog;

ReturnCSVTableHandle;

pFilename in my case happens to be an element from a dimension containing TM1ProcessError logs.
Performing the drill then passes the element to the parameter and that is used as the data source.
I did remove the path statement I join as a prefix to pFilename to keep the example simple.
I also removed a lookup to a cell where the user can specify the DatasourceASCIIDelimiter, again to keep the example simple.

HTH

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Hello Vlad, 
the 2 idea sound great!: 
button and custom logging utility. 

3: you can define your own output file with special column and row names. 

Is it technically possible?

Hi @Vitalij Rusakovskij, 

Drill-through functionality is available via the TM1 REST API.
For files, the server returns both column headers and data.
If the TI process has access to the file, you can customize both the headers and the data as needed.
Re-reading the previous posts... @Edward Stuart's intention was to leverage the drill through functionality to automatically display the custom log file when the process finishes execution, but the UI does not open the drill through viewer if you simply call the drill process it through the REST API.

There are a few ways we could easily add this functionality to SPACE, for example:

1. A button to quickly display the contents of a custom log file located on the TM1 server.

2. A custom logging utility that TI processes can leverage (via an API call to the SPACE server), combined with an embedded log viewer embedded into PAW, offering features like filtering and search.

Let me know your thoughts or if you'd like to collaborate on a prototype!

maybe you are right, George. 
Do you think, it would be necessary, to have or to get the possibility of changing the column and row names? 

@Vlad Didenko, 
do you have this functionality already? 

Hi Vitalij, Not that I am aware of as the data is simply being represented in a grid.

Hello George, 

is it possible to rename or to define the names of the cells in ASCII afterwards or does it stay unchanged? 
Thanks in advance. 

Hi Ardian,

The drill process should be a fairly simple one, or is on my side:

Prolog:

DataSourceType = 'CHARACTERDELIMITED';DataSourceNameForServer=pFilename;

Epliog;

ReturnCSVTableHandle;

pFilename in my case happens to be an element from a dimension containing TM1ProcessError logs.
Performing the drill then passes the element to the parameter and that is used as the data source.
I did remove the path statement I join as a prefix to pFilename to keep the example simple.
I also removed a lookup to a cell where the user can specify the DatasourceASCIIDelimiter, again to keep the example simple.

HTH

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Hi Vitalij,

I have added custom logging to the SPACE roadmap!

You can AsciiOutput to write custom headers and content to a text file in your Prolog, Metadata or Data section and use RETURNSQLTABLEHANDLE; in the Epilog, assuming you are using that file as an ODBC data source for your dill through process with a query like select * from YourFileName.csv

Hello Vlad, 
the 2 idea sound great!: 
button and custom logging utility. 

3: you can define your own output file with special column and row names. 

Is it technically possible?

Hi @Vitalij Rusakovskij, 

Drill-through functionality is available via the TM1 REST API.
For files, the server returns both column headers and data.
If the TI process has access to the file, you can customize both the headers and the data as needed.
Re-reading the previous posts... @Edward Stuart's intention was to leverage the drill through functionality to automatically display the custom log file when the process finishes execution, but the UI does not open the drill through viewer if you simply call the drill process it through the REST API.

There are a few ways we could easily add this functionality to SPACE, for example:

1. A button to quickly display the contents of a custom log file located on the TM1 server.

2. A custom logging utility that TI processes can leverage (via an API call to the SPACE server), combined with an embedded log viewer embedded into PAW, offering features like filtering and search.

Let me know your thoughts or if you'd like to collaborate on a prototype!

maybe you are right, George. 
Do you think, it would be necessary, to have or to get the possibility of changing the column and row names? 

@Vlad Didenko, 
do you have this functionality already? 

Hi Vitalij, Not that I am aware of as the data is simply being represented in a grid.

Hello George, 

is it possible to rename or to define the names of the cells in ASCII afterwards or does it stay unchanged? 
Thanks in advance. 

Hi Ardian,

The drill process should be a fairly simple one, or is on my side:

Prolog:

DataSourceType = 'CHARACTERDELIMITED';DataSourceNameForServer=pFilename;

Epliog;

ReturnCSVTableHandle;

pFilename in my case happens to be an element from a dimension containing TM1ProcessError logs.
Performing the drill then passes the element to the parameter and that is used as the data source.
I did remove the path statement I join as a prefix to pFilename to keep the example simple.
I also removed a lookup to a cell where the user can specify the DatasourceASCIIDelimiter, again to keep the example simple.

HTH

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Hello Vlad, 

it sounds great!
Is it also possible for JSON as Drill-result? 
To get JSON at the end, you need in Epilog the following command: 

ReturnTableHandle();

Hi Vitalij,

I have added custom logging to the SPACE roadmap!

You can AsciiOutput to write custom headers and content to a text file in your Prolog, Metadata or Data section and use RETURNSQLTABLEHANDLE; in the Epilog, assuming you are using that file as an ODBC data source for your dill through process with a query like select * from YourFileName.csv

Hello Vlad, 
the 2 idea sound great!: 
button and custom logging utility. 

3: you can define your own output file with special column and row names. 

Is it technically possible?

Hi @Vitalij Rusakovskij, 

Drill-through functionality is available via the TM1 REST API.
For files, the server returns both column headers and data.
If the TI process has access to the file, you can customize both the headers and the data as needed.
Re-reading the previous posts... @Edward Stuart's intention was to leverage the drill through functionality to automatically display the custom log file when the process finishes execution, but the UI does not open the drill through viewer if you simply call the drill process it through the REST API.

There are a few ways we could easily add this functionality to SPACE, for example:

1. A button to quickly display the contents of a custom log file located on the TM1 server.

2. A custom logging utility that TI processes can leverage (via an API call to the SPACE server), combined with an embedded log viewer embedded into PAW, offering features like filtering and search.

Let me know your thoughts or if you'd like to collaborate on a prototype!

maybe you are right, George. 
Do you think, it would be necessary, to have or to get the possibility of changing the column and row names? 

@Vlad Didenko, 
do you have this functionality already? 

Hi Vitalij, Not that I am aware of as the data is simply being represented in a grid.

Hello George, 

is it possible to rename or to define the names of the cells in ASCII afterwards or does it stay unchanged? 
Thanks in advance. 

Hi Ardian,

The drill process should be a fairly simple one, or is on my side:

Prolog:

DataSourceType = 'CHARACTERDELIMITED';DataSourceNameForServer=pFilename;

Epliog;

ReturnCSVTableHandle;

pFilename in my case happens to be an element from a dimension containing TM1ProcessError logs.
Performing the drill then passes the element to the parameter and that is used as the data source.
I did remove the path statement I join as a prefix to pFilename to keep the example simple.
I also removed a lookup to a cell where the user can specify the DatasourceASCIIDelimiter, again to keep the example simple.

HTH

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Hi Vitalij, Not that I am aware of as the data is simply being represented in a grid.

Hello George, 

is it possible to rename or to define the names of the cells in ASCII afterwards or does it stay unchanged? 
Thanks in advance. 

Hi Ardian,

The drill process should be a fairly simple one, or is on my side:

Prolog:

DataSourceType = 'CHARACTERDELIMITED';DataSourceNameForServer=pFilename;

Epliog;

ReturnCSVTableHandle;

pFilename in my case happens to be an element from a dimension containing TM1ProcessError logs.
Performing the drill then passes the element to the parameter and that is used as the data source.
I did remove the path statement I join as a prefix to pFilename to keep the example simple.
I also removed a lookup to a cell where the user can specify the DatasourceASCIIDelimiter, again to keep the example simple.

HTH

I tried using ReturnCSVTableHandle in a drill process, to allow end users to open an Audit file that gets created when they run an Action button that uploads data into a cube. The Audit file contains the lines that were skip and an error description so they can fix the data and load the file again.

When I use ReturnCSVTableHandle, to return the Audit File through a Drill Process, it throws an error as below:

Drill error

Success of sorts, jumped on a call with @George Tonkin and the drill through process was simple enough and worked as expected, I've not used "ReturnCSVTableHandle" before so it was a new one for me:

"To support drillthrough to CSV, the TI function ReturnCSVTableHandle returns the handle of the CSV datasource. The REST API reads the datasource and converts the data to drillthrough rows."

Drill.To.Debug.File Process:

#Section Prolog

DatasourceASCIIDelimiter = ',';

DataSourceType = 'CHARACTERDELIMITED';

DatasourceNameForServer = 'GetCubeDetails.txt';

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files

Over in the blogs section I have been slowly adding new content around the Planning Analytics Engine, in one of those posts @George Tonkin raised a good point that we could potentially Drill Through to AsciiOutput files as part of the Debugging process.

As many do, I tend to run a series of AsciiOutput statements into my TI Processes to test all manner of different conditions/ values/ logic etc..

In the Planning Analytics Engine, we no longer have access to the underlying folder structure and as such any debugging will default to the file manager. We can add folders at will to the file manager but fundamentally we need to download the debug file to check it's contents.

We could debug into a 'debug cube' but the point of AsciiOutput is it is quick and easy and flexible.

George mentioned that we could use 'ReturnCSVTableHandle' which in turn relates to 'ExecuteRelationalDrillThrough' which can operate on an ODBC data source or a csv table

The theory is that we could add an API call to the end of a development process to automatically pull up the details of an AsciiOutput file generated as part of the debugging process instead of continually accessing the file manager and downloading the files