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

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