It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

HI AG,

Tm1DisplayName and NOW are generally fine BUT depends on the use case. In an allocation model with RunProcess I hit clashes as I was creating multiple objects in the same second.

That is where I stumbled upon MilliTime which gives and nice "unique" timestamp down to milli-second precision.

The main issue is that this is not documented and as such not officially supported so should not be used until then.

I am advocating for its inclusion in the list of supported TI functions as it is really useful as much better that trying to do things like NOW() * RAND()...

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Thanks George - good insights!

For my current use case this will not be a problem (VERY few users) BUT as a general principle it sounds like MilliTime (in honor of Robert!!) would be very useful to have! If there is a feature request I can vote for, I'd be happy to!

HI AG,

Tm1DisplayName and NOW are generally fine BUT depends on the use case. In an allocation model with RunProcess I hit clashes as I was creating multiple objects in the same second.

That is where I stumbled upon MilliTime which gives and nice "unique" timestamp down to milli-second precision.

The main issue is that this is not documented and as such not officially supported so should not be used until then.

I am advocating for its inclusion in the list of supported TI functions as it is really useful as much better that trying to do things like NOW() * RAND()...

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Hi AG, the Idea is loaded here: Official Support for the | IBM Data and AI Ideas Portal for Customers

Please vote if you think this may be useful in future cases.

Thanks George - good insights!

For my current use case this will not be a problem (VERY few users) BUT as a general principle it sounds like MilliTime (in honor of Robert!!) would be very useful to have! If there is a feature request I can vote for, I'd be happy to!

HI AG,

Tm1DisplayName and NOW are generally fine BUT depends on the use case. In an allocation model with RunProcess I hit clashes as I was creating multiple objects in the same second.

That is where I stumbled upon MilliTime which gives and nice "unique" timestamp down to milli-second precision.

The main issue is that this is not documented and as such not officially supported so should not be used until then.

I am advocating for its inclusion in the list of supported TI functions as it is really useful as much better that trying to do things like NOW() * RAND()...

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Hey George,

Any reason why we wouldn't just extend Now to include milli seconds (under the covers all our time structures already have milli seconds but they don't get set by Now) instead and add support in the various time functions to even include it in for example the formatted value etc?

Hi AG, the Idea is loaded here: Official Support for the | IBM Data and AI Ideas Portal for Customers

Please vote if you think this may be useful in future cases.

Thanks George - good insights!

For my current use case this will not be a problem (VERY few users) BUT as a general principle it sounds like MilliTime (in honor of Robert!!) would be very useful to have! If there is a feature request I can vote for, I'd be happy to!

HI AG,

Tm1DisplayName and NOW are generally fine BUT depends on the use case. In an allocation model with RunProcess I hit clashes as I was creating multiple objects in the same second.

That is where I stumbled upon MilliTime which gives and nice "unique" timestamp down to milli-second precision.

The main issue is that this is not documented and as such not officially supported so should not be used until then.

I am advocating for its inclusion in the list of supported TI functions as it is really useful as much better that trying to do things like NOW() * RAND()...

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Hi Hubert,

That would actually be far better and simpler with the existing installed client base.

MilliTime also seems to reset with server restarts i.e. will be unique during the "session". Not an issue but mentioning for others to be aware.

NOW() would presumably just return more decimals and a simple NumberToString(NOW()) would be good enough to make a unique string - it will have a decimal point but won't be a problem for TM1 or the OS in handling this if writing to disk etc.

Next you will be asked to extend TIMST() to support milliseconds.

Would this enhancement be a "v12" only enhancement or is there any chance that it would be implemented in v11 too?

Hey George,

Any reason why we wouldn't just extend Now to include milli seconds (under the covers all our time structures already have milli seconds but they don't get set by Now) instead and add support in the various time functions to even include it in for example the formatted value etc?

Hi AG, the Idea is loaded here: Official Support for the | IBM Data and AI Ideas Portal for Customers

Please vote if you think this may be useful in future cases.

Thanks George - good insights!

For my current use case this will not be a problem (VERY few users) BUT as a general principle it sounds like MilliTime (in honor of Robert!!) would be very useful to have! If there is a feature request I can vote for, I'd be happy to!

HI AG,

Tm1DisplayName and NOW are generally fine BUT depends on the use case. In an allocation model with RunProcess I hit clashes as I was creating multiple objects in the same second.

That is where I stumbled upon MilliTime which gives and nice "unique" timestamp down to milli-second precision.

The main issue is that this is not documented and as such not officially supported so should not be used until then.

I am advocating for its inclusion in the list of supported TI functions as it is really useful as much better that trying to do things like NOW() * RAND()...

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Hi George,

I had in the meantime already added a comment to the idea you referenced above confirming that MilliTime isn't real time but rather the number of milliseconds since first called, and as such indeed being reset every time the server restarts as well indeed. And I had also already presumed that if we did include thousands of a second that any function that returns a string representation of [date-]time should, optionally,  be able to include the thousands of a second as well.

v12 is always the first target for anything but, whilst we don't like porting things back, things like these should be trivial to do so a case could most certainly be made as such ;-) 

Hi Hubert,

That would actually be far better and simpler with the existing installed client base.

MilliTime also seems to reset with server restarts i.e. will be unique during the "session". Not an issue but mentioning for others to be aware.

NOW() would presumably just return more decimals and a simple NumberToString(NOW()) would be good enough to make a unique string - it will have a decimal point but won't be a problem for TM1 or the OS in handling this if writing to disk etc.

Next you will be asked to extend TIMST() to support milliseconds.

Would this enhancement be a "v12" only enhancement or is there any chance that it would be implemented in v11 too?

Hey George,

Any reason why we wouldn't just extend Now to include milli seconds (under the covers all our time structures already have milli seconds but they don't get set by Now) instead and add support in the various time functions to even include it in for example the formatted value etc?

Hi AG, the Idea is loaded here: Official Support for the | IBM Data and AI Ideas Portal for Customers

Please vote if you think this may be useful in future cases.

Thanks George - good insights!

For my current use case this will not be a problem (VERY few users) BUT as a general principle it sounds like MilliTime (in honor of Robert!!) would be very useful to have! If there is a feature request I can vote for, I'd be happy to!

HI AG,

Tm1DisplayName and NOW are generally fine BUT depends on the use case. In an allocation model with RunProcess I hit clashes as I was creating multiple objects in the same second.

That is where I stumbled upon MilliTime which gives and nice "unique" timestamp down to milli-second precision.

The main issue is that this is not documented and as such not officially supported so should not be used until then.

I am advocating for its inclusion in the list of supported TI functions as it is really useful as much better that trying to do things like NOW() * RAND()...

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Thanks Hubert! Saw the comment on the Idea and the suggestions make perfect sense.

Thanks AG for starting the topic that got us here.

Hi George,

I had in the meantime already added a comment to the idea you referenced above confirming that MilliTime isn't real time but rather the number of milliseconds since first called, and as such indeed being reset every time the server restarts as well indeed. And I had also already presumed that if we did include thousands of a second that any function that returns a string representation of [date-]time should, optionally,  be able to include the thousands of a second as well.

v12 is always the first target for anything but, whilst we don't like porting things back, things like these should be trivial to do so a case could most certainly be made as such ;-) 

Hi Hubert,

That would actually be far better and simpler with the existing installed client base.

MilliTime also seems to reset with server restarts i.e. will be unique during the "session". Not an issue but mentioning for others to be aware.

NOW() would presumably just return more decimals and a simple NumberToString(NOW()) would be good enough to make a unique string - it will have a decimal point but won't be a problem for TM1 or the OS in handling this if writing to disk etc.

Next you will be asked to extend TIMST() to support milliseconds.

Would this enhancement be a "v12" only enhancement or is there any chance that it would be implemented in v11 too?

Hey George,

Any reason why we wouldn't just extend Now to include milli seconds (under the covers all our time structures already have milli seconds but they don't get set by Now) instead and add support in the various time functions to even include it in for example the formatted value etc?

Hi AG, the Idea is loaded here: Official Support for the | IBM Data and AI Ideas Portal for Customers

Please vote if you think this may be useful in future cases.

Thanks George - good insights!

For my current use case this will not be a problem (VERY few users) BUT as a general principle it sounds like MilliTime (in honor of Robert!!) would be very useful to have! If there is a feature request I can vote for, I'd be happy to!

HI AG,

Tm1DisplayName and NOW are generally fine BUT depends on the use case. In an allocation model with RunProcess I hit clashes as I was creating multiple objects in the same second.

That is where I stumbled upon MilliTime which gives and nice "unique" timestamp down to milli-second precision.

The main issue is that this is not documented and as such not officially supported so should not be used until then.

I am advocating for its inclusion in the list of supported TI functions as it is really useful as much better that trying to do things like NOW() * RAND()...

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

You should be aware that the Views / Subsets cannot be temporary objects, and they cannot be deleted in Epilog, so the number of objects will increase a lot if you use the TimeStamp as part of View / Subset Names

We just concatenate the Process Name with User's Display Name, and then we remove any special character and use this in order to uniquely name the objects

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

That's an excellent point. Thank you for highlighting it! 

You should be aware that the Views / Subsets cannot be temporary objects, and they cannot be deleted in Epilog, so the number of objects will increase a lot if you use the TimeStamp as part of View / Subset Names

We just concatenate the Process Name with User's Display Name, and then we remove any special character and use this in order to uniquely name the objects

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

I'm guessing that if we allowed the use of temporary subsets/views etc, which you obviously shouldn't delete in the epilog either, this would make it all to easy then not?

Kidding aside, already raised this internally as to why we wouldn't allow the use of temporary objects as effectively any view one uses in these is already a 'copy' of the view being referenced, which essentially is not far from a temporary view anyway (read: we'll fix that).

That's an excellent point. Thank you for highlighting it! 

You should be aware that the Views / Subsets cannot be temporary objects, and they cannot be deleted in Epilog, so the number of objects will increase a lot if you use the TimeStamp as part of View / Subset Names

We just concatenate the Process Name with User's Display Name, and then we remove any special character and use this in order to uniquely name the objects

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Hubert:

When I first started this thread I wasn't even thinking about the multi-user case, so it's been great to see all the posts about it!

So (just to summarize) here are the two things I think came up so far:

• ensuring the drill view names are unique, in case two individuals request the same drill at the same time, and also to minimize risks of locking and any kind of object contention
• cleaning up these objects at the end (making them truly temporary) - they need to persist until they are rendered at which point (perhaps) the user can save them if they like, but once they are rendered they no longer need to exist
  • All that said, it's handy to be able to look at them afterwards when you are troubleshooting so perhaps we are talking about another flag on ReturnViewHandle to control that?

I am sure that doesn't cover everything, but it's cool to learn how this feature is being used!

One thing I was thrilled to discover was that we can now assign our own parameter variables: at one time (many, many years ago) the parameters were hardcoded to the dimension name which was a problem when people created dimensions whose names included characters (like -) that could not be used in a TI variable. Then you were stuck!

Thanks!

AG

I'm guessing that if we allowed the use of temporary subsets/views etc, which you obviously shouldn't delete in the epilog either, this would make it all to easy then not?

Kidding aside, already raised this internally as to why we wouldn't allow the use of temporary objects as effectively any view one uses in these is already a 'copy' of the view being referenced, which essentially is not far from a temporary view anyway (read: we'll fix that).

That's an excellent point. Thank you for highlighting it! 

You should be aware that the Views / Subsets cannot be temporary objects, and they cannot be deleted in Epilog, so the number of objects will increase a lot if you use the TimeStamp as part of View / Subset Names

We just concatenate the Process Name with User's Display Name, and then we remove any special character and use this in order to uniquely name the objects

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

As mentioned above, allowing temporary views would solve uniqueness and cleanup/live-span. The temporary view would in that case live as long as the returned Cellset (read: until DELETE is called on that cellset or the session closes). If you needed the view longer then that then you'd have to use registered/name view and/or SaveAs the view on the cellset. 

So we have two issues to fix now; 1) support drill-through to MDX view and 2) allow the use of temporary views. 

And to be honest, reading the rest of the thread and the reference to the, undocumented, MilliTime function, why we wouldn't simply include milliseconds in the time returned by the Now function. Thoughts?

Hubert:

When I first started this thread I wasn't even thinking about the multi-user case, so it's been great to see all the posts about it!

So (just to summarize) here are the two things I think came up so far:

• ensuring the drill view names are unique, in case two individuals request the same drill at the same time, and also to minimize risks of locking and any kind of object contention
• cleaning up these objects at the end (making them truly temporary) - they need to persist until they are rendered at which point (perhaps) the user can save them if they like, but once they are rendered they no longer need to exist
  • All that said, it's handy to be able to look at them afterwards when you are troubleshooting so perhaps we are talking about another flag on ReturnViewHandle to control that?

I am sure that doesn't cover everything, but it's cool to learn how this feature is being used!

One thing I was thrilled to discover was that we can now assign our own parameter variables: at one time (many, many years ago) the parameters were hardcoded to the dimension name which was a problem when people created dimensions whose names included characters (like -) that could not be used in a TI variable. Then you were stuck!

Thanks!

AG

I'm guessing that if we allowed the use of temporary subsets/views etc, which you obviously shouldn't delete in the epilog either, this would make it all to easy then not?

Kidding aside, already raised this internally as to why we wouldn't allow the use of temporary objects as effectively any view one uses in these is already a 'copy' of the view being referenced, which essentially is not far from a temporary view anyway (read: we'll fix that).

That's an excellent point. Thank you for highlighting it! 

You should be aware that the Views / Subsets cannot be temporary objects, and they cannot be deleted in Epilog, so the number of objects will increase a lot if you use the TimeStamp as part of View / Subset Names

We just concatenate the Process Name with User's Display Name, and then we remove any special character and use this in order to uniquely name the objects

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Hubert:

THREE things please:

1) Support drill-through to MDX view

2) Allow the use of temporary views (assuming you think this also solves the multi-user access situation)

3) Allow the TI script writer developer to override the runtime instantiation of Title parameters (example below).

THANK YOU!

AG

TITLE PARAMETERS example: My original question with screenshot is pasted in below for your convenience :-)

I have been thinking about this and have come to the conclusion that the current behavior is a FEATURE, and a useful one. It allows you to create a useful context-dependent cube to cube drill-through without writing any TI script code. To make this work it appears that ReturnViewHandle automatically matches the context from the starting point (the originating cell, which instantiates the drill process parameter values) to the title dimensions of the result view (which is the data source of the drill process).

But the cool thing that we TI developers figured out is that you can edit the drill process and customize the result view on the fly. The screenshot below (hopefully self-explanatory) shows a simple example where we are drilling from CUBE1 to CUBE2. The "wrinkle" in this example is that we want to do a mapping based on an attribute, so if we drill on Prod3, we want to pull up the assumptions (from CUBE2) on Prod2 and not Prod3. The screenshot shows what I WANT to have happen, not what actually happens.

But when I write TI script to build this view I find I can customize rows and columns all I want, but the Title selection is stubborn. When I open the view directly after doing the drill from Prod3 I can see the CUBE2 view was built correctly as I wanted it (with Prod2 in the title selection), but when I execute the drill I always get Prod 3.

ALL THAT SAID - I think this is the correct behavior BECAUSE we need it to work the way it currently works for all the times these are built without coding (I think Architect used to auto-generate the drill processes for you - haven't seen how to do that in PAW yet :-)

So I think what I really want is an optional parameter on ReturnViewHandle() that let's me take over responsibility for setting the title settings as runtime (or basically stop instantiating them and just display the view). The default would be the current behavior.

As mentioned above, allowing temporary views would solve uniqueness and cleanup/live-span. The temporary view would in that case live as long as the returned Cellset (read: until DELETE is called on that cellset or the session closes). If you needed the view longer then that then you'd have to use registered/name view and/or SaveAs the view on the cellset. 

So we have two issues to fix now; 1) support drill-through to MDX view and 2) allow the use of temporary views. 

And to be honest, reading the rest of the thread and the reference to the, undocumented, MilliTime function, why we wouldn't simply include milliseconds in the time returned by the Now function. Thoughts?

Hubert:

When I first started this thread I wasn't even thinking about the multi-user case, so it's been great to see all the posts about it!

So (just to summarize) here are the two things I think came up so far:

• ensuring the drill view names are unique, in case two individuals request the same drill at the same time, and also to minimize risks of locking and any kind of object contention
• cleaning up these objects at the end (making them truly temporary) - they need to persist until they are rendered at which point (perhaps) the user can save them if they like, but once they are rendered they no longer need to exist
  • All that said, it's handy to be able to look at them afterwards when you are troubleshooting so perhaps we are talking about another flag on ReturnViewHandle to control that?

I am sure that doesn't cover everything, but it's cool to learn how this feature is being used!

One thing I was thrilled to discover was that we can now assign our own parameter variables: at one time (many, many years ago) the parameters were hardcoded to the dimension name which was a problem when people created dimensions whose names included characters (like -) that could not be used in a TI variable. Then you were stuck!

Thanks!

AG

I'm guessing that if we allowed the use of temporary subsets/views etc, which you obviously shouldn't delete in the epilog either, this would make it all to easy then not?

Kidding aside, already raised this internally as to why we wouldn't allow the use of temporary objects as effectively any view one uses in these is already a 'copy' of the view being referenced, which essentially is not far from a temporary view anyway (read: we'll fix that).

That's an excellent point. Thank you for highlighting it! 

You should be aware that the Views / Subsets cannot be temporary objects, and they cannot be deleted in Epilog, so the number of objects will increase a lot if you use the TimeStamp as part of View / Subset Names

We just concatenate the Process Name with User's Display Name, and then we remove any special character and use this in order to uniquely name the objects

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Hi AG,

Sorry, forgot to mention, whilst it might be somewhat odd that that mapping happens as a result of the ReturnViewHandle, effectively even after the process has finished by the way, but that doesn't preclude you from changing the value for the PARAMETER that drives the element for that dimension not? You mentioned yourself already you can specify your own names for the parameters (and I should figure out why the drill process, when being created, has effectively same named variables as well, so just make sure those parameter names differ!), if you change the value set for the parameter, like in your example substitute it with the attribute value of such element (as long as it is an element name once again), that should work already not? 

Hubert:

THREE things please:

1) Support drill-through to MDX view

2) Allow the use of temporary views (assuming you think this also solves the multi-user access situation)

3) Allow the TI script writer developer to override the runtime instantiation of Title parameters (example below).

THANK YOU!

AG

TITLE PARAMETERS example: My original question with screenshot is pasted in below for your convenience :-)

I have been thinking about this and have come to the conclusion that the current behavior is a FEATURE, and a useful one. It allows you to create a useful context-dependent cube to cube drill-through without writing any TI script code. To make this work it appears that ReturnViewHandle automatically matches the context from the starting point (the originating cell, which instantiates the drill process parameter values) to the title dimensions of the result view (which is the data source of the drill process).

But the cool thing that we TI developers figured out is that you can edit the drill process and customize the result view on the fly. The screenshot below (hopefully self-explanatory) shows a simple example where we are drilling from CUBE1 to CUBE2. The "wrinkle" in this example is that we want to do a mapping based on an attribute, so if we drill on Prod3, we want to pull up the assumptions (from CUBE2) on Prod2 and not Prod3. The screenshot shows what I WANT to have happen, not what actually happens.

But when I write TI script to build this view I find I can customize rows and columns all I want, but the Title selection is stubborn. When I open the view directly after doing the drill from Prod3 I can see the CUBE2 view was built correctly as I wanted it (with Prod2 in the title selection), but when I execute the drill I always get Prod 3.

ALL THAT SAID - I think this is the correct behavior BECAUSE we need it to work the way it currently works for all the times these are built without coding (I think Architect used to auto-generate the drill processes for you - haven't seen how to do that in PAW yet :-)

So I think what I really want is an optional parameter on ReturnViewHandle() that let's me take over responsibility for setting the title settings as runtime (or basically stop instantiating them and just display the view). The default would be the current behavior.

As mentioned above, allowing temporary views would solve uniqueness and cleanup/live-span. The temporary view would in that case live as long as the returned Cellset (read: until DELETE is called on that cellset or the session closes). If you needed the view longer then that then you'd have to use registered/name view and/or SaveAs the view on the cellset. 

So we have two issues to fix now; 1) support drill-through to MDX view and 2) allow the use of temporary views. 

And to be honest, reading the rest of the thread and the reference to the, undocumented, MilliTime function, why we wouldn't simply include milliseconds in the time returned by the Now function. Thoughts?

Hubert:

When I first started this thread I wasn't even thinking about the multi-user case, so it's been great to see all the posts about it!

So (just to summarize) here are the two things I think came up so far:

• ensuring the drill view names are unique, in case two individuals request the same drill at the same time, and also to minimize risks of locking and any kind of object contention
• cleaning up these objects at the end (making them truly temporary) - they need to persist until they are rendered at which point (perhaps) the user can save them if they like, but once they are rendered they no longer need to exist
  • All that said, it's handy to be able to look at them afterwards when you are troubleshooting so perhaps we are talking about another flag on ReturnViewHandle to control that?

I am sure that doesn't cover everything, but it's cool to learn how this feature is being used!

One thing I was thrilled to discover was that we can now assign our own parameter variables: at one time (many, many years ago) the parameters were hardcoded to the dimension name which was a problem when people created dimensions whose names included characters (like -) that could not be used in a TI variable. Then you were stuck!

Thanks!

AG

I'm guessing that if we allowed the use of temporary subsets/views etc, which you obviously shouldn't delete in the epilog either, this would make it all to easy then not?

Kidding aside, already raised this internally as to why we wouldn't allow the use of temporary objects as effectively any view one uses in these is already a 'copy' of the view being referenced, which essentially is not far from a temporary view anyway (read: we'll fix that).

That's an excellent point. Thank you for highlighting it! 

You should be aware that the Views / Subsets cannot be temporary objects, and they cannot be deleted in Epilog, so the number of objects will increase a lot if you use the TimeStamp as part of View / Subset Names

We just concatenate the Process Name with User's Display Name, and then we remove any special character and use this in order to uniquely name the objects

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

I'm guessing that if we allowed the use of temporary subsets/views etc, which you obviously shouldn't delete in the epilog either, this would make it all to easy then not?

Kidding aside, already raised this internally as to why we wouldn't allow the use of temporary objects as effectively any view one uses in these is already a 'copy' of the view being referenced, which essentially is not far from a temporary view anyway (read: we'll fix that).

That's an excellent point. Thank you for highlighting it! 

You should be aware that the Views / Subsets cannot be temporary objects, and they cannot be deleted in Epilog, so the number of objects will increase a lot if you use the TimeStamp as part of View / Subset Names

We just concatenate the Process Name with User's Display Name, and then we remove any special character and use this in order to uniquely name the objects

Thanks George!

As I wrote in my earlier response to John, I haven't reached as far as contemplating uniqueness of views for multi-user usage. But when I do, based on your suggestion, I am thinking that a combination of the Tm1DisplayName alias (on CAM) and a timestamp (NOW) should be sufficient for most needs.

Any concerns about doing it this way?

Thanks!

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

for v12 I have to test it with the username, however, yes, it is better to use the display name value or other attributes for the user. 

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Keeping the view name unique is definitely recommended, however just a caution in using TM1User to get the user name.

Got caught out recently where TM1User was working flawlessly in Dev as security mode 1 was configured.
Switching to Prod with CAM created havoc as views could not be created using the CAM ID which TM1User was returning - you need to use the display value or some other attribute that does not contain characters that the filesystem reserves. V12 mileage may differ...

Unique View names is another reason I am hoping that IBM will officially support MilliTime - You can be pretty certain of getting a unique view...

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

It's a bit limited. There are several posting about the need for MDX views. What you will also find is that you should incorporate the users name in the cube view, otherwise you will get issues if multiple users are drilling. I recall there was a good posting on that on one of the forums. I have implemented that technique in a prior solution.

Hi AG,

First up I'd like to understand the issue you describe a bit better, are you saying you want to overwrite whatever is passed in for a title when doing the drill but you cannot? Can you elaborate a bit on how you are trying to do that?

As for MDX views, they are indeed not supported as a drill target YET. The idea here is that we 1) introduce templated MDX (not just for drill-through but generically) and then 2) define how to use a templated MDX when used as a target of a drill-through (which by itself then becomes pretty straightforward presumably, you use the parameters to have their values injected in the WHERE clause and in the case of MDX we'll be passing in MUNs presumably instead of element names - TBD). 

Hello AG, 

I think, for now, there was a kind of "official" message that the drill is only supported with "native" views. 
They want to bring the mdx-views also, however, it has not been the case so far. 

Hi Vitalij,

As per my initial apply to AG, MDX views are indeed not supported YET, but high on the list of things to be added shortly. My proposal for this is to 1) introduce templated MDX (not just for drill-through but generically) and then 2) define how to use a templated MDX when used as a target of a drill-through (which by itself then becomes pretty straightforward presumably, you use the parameters to have their values injected in the WHERE clause and in the case of MDX we'll be passing in MUNs presumably instead of element names - TBD). 

Hello AG, 

I think, for now, there was a kind of "official" message that the drill is only supported with "native" views. 
They want to bring the mdx-views also, however, it has not been the case so far. 

Hi Vitalij,

As per my initial apply to AG, MDX views are indeed not supported YET, but high on the list of things to be added shortly. My proposal for this is to 1) introduce templated MDX (not just for drill-through but generically) and then 2) define how to use a templated MDX when used as a target of a drill-through (which by itself then becomes pretty straightforward presumably, you use the parameters to have their values injected in the WHERE clause and in the case of MDX we'll be passing in MUNs presumably instead of element names - TBD). 

Hello AG, 

I think, for now, there was a kind of "official" message that the drill is only supported with "native" views. 
They want to bring the mdx-views also, however, it has not been the case so far. 

Coincidentally, I am putting together some Drill processes for the first time in a long time.  This is part of a Perspectives to PAW/PAFE conversion.  I expected the Perspectives drills to work without issue in PAW and PAFE.

Please see below what I am experiencing.   If anyone has solutions for my issues please provide.  

Situation - This is part of a multi-step drill process.

Step 1: User viewing a  report or view at the consolidated level of a 15 dimension cube model.  First drill allows the user to Drill to the same cube to different dimensions to get to the Input Element level of the model.  They are allowed to Drill by:

     - three primary dimensions Company, Cost Center or Account: Showing the selected drills dimension on the rows with DESCENDANTS of the element they drilled.

     - or a stacked view of the three accounts showing all there accounts N-Level elements only to see all the input combinations of the dimensions as row elements

Step 2:  Allows the user to DRILL to the SQL GL transactions when they are on an N-Level cell (N-Level for Company, Coot Center, Account dimensions)

===============================================================

The Step 1 processes are a typical DRILL script that:

• builds a VIEW using all the old VIEW functions: ViewCreate, ViewDestroy, ViewExists, ViewTitleDimensionSet, ViewTitleElementSet, ViewRowDimensionSet, ViewRowSuppressZeroesSet, ViewColumnDimensionSet, ViewSubsetAssign
• create unique VIEW based on <Process called> and the USER

The results are different across environments:

This is the SAME drill in each environment.

NOTE - The TI Script assigns SUBSETS and ALIASES to all dimensions.

PAFE - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element from drilled value BUT no alias set
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

PAW - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!
• NOTE - In this interface user has no control over formatting of values etc.

Perspectives - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

NOTE: Also would be great to have control over the default formatting of the values show in the view as part of the script.

===============================================================

I do not expect updates/changes to the old style VIEW functions to be updated by IBM.  But my hope is when the support to assign MDX views to the drill processes are implemented:

• ALL interfaces:  PAW-Reports, PAW-Workbench, PAW/TM1Web-Websheets, PAFE have a consistent result displayed to the user
• Support Title element subset assignments
• Support ability to control default formatting of values

Hi Vitalij,

As per my initial apply to AG, MDX views are indeed not supported YET, but high on the list of things to be added shortly. My proposal for this is to 1) introduce templated MDX (not just for drill-through but generically) and then 2) define how to use a templated MDX when used as a target of a drill-through (which by itself then becomes pretty straightforward presumably, you use the parameters to have their values injected in the WHERE clause and in the case of MDX we'll be passing in MUNs presumably instead of element names - TBD). 

Hello AG, 

I think, for now, there was a kind of "official" message that the drill is only supported with "native" views. 
They want to bring the mdx-views also, however, it has not been the case so far. 

Hi Daniel,

I'm just the TM1 guy but understand you expecting all interfaces to behave consistently. That said, and I'm kind of 'happy' that none of the existing interfaces carry the subset on the title dimensions, MDX, and therefore MDX views (which are nothing more and nothing less then named MDX queries), do not carry set definitions to hint a consumer/front-end/interface as to what elements, members if MDX set, a user ought to be choosing from.

There is an easy work around for that but, as it stands - prototype to fix that too is in the works, you currently can't apply that work around when creating these MDX views in TI (you could through the REST API and therefore any client/interface could do so too.

As for formatting, my understanding is that ability to control formats is expanding in PAW, but either way it is the interfaces choice to adhere to any format specified in TM1 itself or not.

Coincidentally, I am putting together some Drill processes for the first time in a long time.  This is part of a Perspectives to PAW/PAFE conversion.  I expected the Perspectives drills to work without issue in PAW and PAFE.

Please see below what I am experiencing.   If anyone has solutions for my issues please provide.  

Situation - This is part of a multi-step drill process.

Step 1: User viewing a  report or view at the consolidated level of a 15 dimension cube model.  First drill allows the user to Drill to the same cube to different dimensions to get to the Input Element level of the model.  They are allowed to Drill by:

     - three primary dimensions Company, Cost Center or Account: Showing the selected drills dimension on the rows with DESCENDANTS of the element they drilled.

     - or a stacked view of the three accounts showing all there accounts N-Level elements only to see all the input combinations of the dimensions as row elements

Step 2:  Allows the user to DRILL to the SQL GL transactions when they are on an N-Level cell (N-Level for Company, Coot Center, Account dimensions)

===============================================================

The Step 1 processes are a typical DRILL script that:

• builds a VIEW using all the old VIEW functions: ViewCreate, ViewDestroy, ViewExists, ViewTitleDimensionSet, ViewTitleElementSet, ViewRowDimensionSet, ViewRowSuppressZeroesSet, ViewColumnDimensionSet, ViewSubsetAssign
• create unique VIEW based on <Process called> and the USER

The results are different across environments:

This is the SAME drill in each environment.

NOTE - The TI Script assigns SUBSETS and ALIASES to all dimensions.

PAFE - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element from drilled value BUT no alias set
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

PAW - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!
• NOTE - In this interface user has no control over formatting of values etc.

Perspectives - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

NOTE: Also would be great to have control over the default formatting of the values show in the view as part of the script.

===============================================================

I do not expect updates/changes to the old style VIEW functions to be updated by IBM.  But my hope is when the support to assign MDX views to the drill processes are implemented:

• ALL interfaces:  PAW-Reports, PAW-Workbench, PAW/TM1Web-Websheets, PAFE have a consistent result displayed to the user
• Support Title element subset assignments
• Support ability to control default formatting of values

Hi Vitalij,

As per my initial apply to AG, MDX views are indeed not supported YET, but high on the list of things to be added shortly. My proposal for this is to 1) introduce templated MDX (not just for drill-through but generically) and then 2) define how to use a templated MDX when used as a target of a drill-through (which by itself then becomes pretty straightforward presumably, you use the parameters to have their values injected in the WHERE clause and in the case of MDX we'll be passing in MUNs presumably instead of element names - TBD). 

Hello AG, 

I think, for now, there was a kind of "official" message that the drill is only supported with "native" views. 
They want to bring the mdx-views also, however, it has not been the case so far. 

Hubert:

I understand that the look and feel of the VIEWERS do not fall under your responsibility.  That I believe would fall under  Stuart's or Svetlana's domain.   I hope they take my prior email into account so the user has a consistent experience across interfaces.

But how the overall Drill experience works is a combination of Server side and User interface:

• creating the MDX view that the resulting view displays (your responsibility)
• the configuration of the resulting view the user experiences (Stuarts responsibility)

As a developer what I want to do is:

• Create a template VIEW using the PAW/PAFE VIEWER as the starting point for the TI process this:
  • Defines the initial MDX for the VIEW 
  • Allows the use of all the PAW viewer capabilities to create a greater user experience:
    • Title element assigned subsets etc..
    • Hide dimensions I do not want the user to see
    • Number formatting, Sorting etc.
• In the TI Process all I want to do is:
  • Use the template VIEW as a starting point 
  • Change the elements displayed for each dimension / hierarchy  (Title elements - simple [dimension].[hierarchy].[element], Row/Col - more complicated MDX expression to generate multiple elements (i.e DESCENDANTS() )

I see that the above request would need TI functions changes:

• How to use a current VIEW as the starting point of the view returned keeping all the related visual settings.
• How to return the VIEW with all these settings as part of the DRILL process

==================================================================================

The current design (all TI script to build VIEW and use RETURNVIEWHANDLE())  is greatly limited since all it does create a simple VIEW with no other visual capabilities. 

==================================================================================

I think this is an important conversation since I believe the DRILL capabilities in the past has been a differentiator for TM1. 

A more enhanced DRILL is needed in today's competitive environment to:

• Make it easier to implement
• Greatly enhance the user (demo :-)) experience

- 

Hi Daniel,

I'm just the TM1 guy but understand you expecting all interfaces to behave consistently. That said, and I'm kind of 'happy' that none of the existing interfaces carry the subset on the title dimensions, MDX, and therefore MDX views (which are nothing more and nothing less then named MDX queries), do not carry set definitions to hint a consumer/front-end/interface as to what elements, members if MDX set, a user ought to be choosing from.

There is an easy work around for that but, as it stands - prototype to fix that too is in the works, you currently can't apply that work around when creating these MDX views in TI (you could through the REST API and therefore any client/interface could do so too.

As for formatting, my understanding is that ability to control formats is expanding in PAW, but either way it is the interfaces choice to adhere to any format specified in TM1 itself or not.

Coincidentally, I am putting together some Drill processes for the first time in a long time.  This is part of a Perspectives to PAW/PAFE conversion.  I expected the Perspectives drills to work without issue in PAW and PAFE.

Please see below what I am experiencing.   If anyone has solutions for my issues please provide.  

Situation - This is part of a multi-step drill process.

Step 1: User viewing a  report or view at the consolidated level of a 15 dimension cube model.  First drill allows the user to Drill to the same cube to different dimensions to get to the Input Element level of the model.  They are allowed to Drill by:

     - three primary dimensions Company, Cost Center or Account: Showing the selected drills dimension on the rows with DESCENDANTS of the element they drilled.

     - or a stacked view of the three accounts showing all there accounts N-Level elements only to see all the input combinations of the dimensions as row elements

Step 2:  Allows the user to DRILL to the SQL GL transactions when they are on an N-Level cell (N-Level for Company, Coot Center, Account dimensions)

===============================================================

The Step 1 processes are a typical DRILL script that:

• builds a VIEW using all the old VIEW functions: ViewCreate, ViewDestroy, ViewExists, ViewTitleDimensionSet, ViewTitleElementSet, ViewRowDimensionSet, ViewRowSuppressZeroesSet, ViewColumnDimensionSet, ViewSubsetAssign
• create unique VIEW based on <Process called> and the USER

The results are different across environments:

This is the SAME drill in each environment.

NOTE - The TI Script assigns SUBSETS and ALIASES to all dimensions.

PAFE - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element from drilled value BUT no alias set
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

PAW - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!
• NOTE - In this interface user has no control over formatting of values etc.

Perspectives - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

NOTE: Also would be great to have control over the default formatting of the values show in the view as part of the script.

===============================================================

I do not expect updates/changes to the old style VIEW functions to be updated by IBM.  But my hope is when the support to assign MDX views to the drill processes are implemented:

• ALL interfaces:  PAW-Reports, PAW-Workbench, PAW/TM1Web-Websheets, PAFE have a consistent result displayed to the user
• Support Title element subset assignments
• Support ability to control default formatting of values

Hi Vitalij,

As per my initial apply to AG, MDX views are indeed not supported YET, but high on the list of things to be added shortly. My proposal for this is to 1) introduce templated MDX (not just for drill-through but generically) and then 2) define how to use a templated MDX when used as a target of a drill-through (which by itself then becomes pretty straightforward presumably, you use the parameters to have their values injected in the WHERE clause and in the case of MDX we'll be passing in MUNs presumably instead of element names - TBD). 

Hello AG, 

I think, for now, there was a kind of "official" message that the drill is only supported with "native" views. 
They want to bring the mdx-views also, however, it has not been the case so far. 

Hi Daniel,

I strongly agree that the drill through configuration should be much more visual and intuitive.  We will consider improving the drill through creation experience in Workspace after we have support for drill through to MDX views in TM1.  

We are currently working on a similar feature for picklist cells.  A modeler can right click on a cell in the cube viewer and turn that cell into a picklist.  This is probably much more intuitive for users that creating a picklist rule or adding a picklist attribute to a dimension.

After clicking the 'Set picklist' option...

There are other options (e.g static list, range of numbers) depending on the cell type you are setting the picklist on.

Hubert:

I understand that the look and feel of the VIEWERS do not fall under your responsibility.  That I believe would fall under  Stuart's or Svetlana's domain.   I hope they take my prior email into account so the user has a consistent experience across interfaces.

But how the overall Drill experience works is a combination of Server side and User interface:

• creating the MDX view that the resulting view displays (your responsibility)
• the configuration of the resulting view the user experiences (Stuarts responsibility)

As a developer what I want to do is:

• Create a template VIEW using the PAW/PAFE VIEWER as the starting point for the TI process this:
  • Defines the initial MDX for the VIEW 
  • Allows the use of all the PAW viewer capabilities to create a greater user experience:
    • Title element assigned subsets etc..
    • Hide dimensions I do not want the user to see
    • Number formatting, Sorting etc.
• In the TI Process all I want to do is:
  • Use the template VIEW as a starting point 
  • Change the elements displayed for each dimension / hierarchy  (Title elements - simple [dimension].[hierarchy].[element], Row/Col - more complicated MDX expression to generate multiple elements (i.e DESCENDANTS() )

I see that the above request would need TI functions changes:

• How to use a current VIEW as the starting point of the view returned keeping all the related visual settings.
• How to return the VIEW with all these settings as part of the DRILL process

==================================================================================

The current design (all TI script to build VIEW and use RETURNVIEWHANDLE())  is greatly limited since all it does create a simple VIEW with no other visual capabilities. 

==================================================================================

I think this is an important conversation since I believe the DRILL capabilities in the past has been a differentiator for TM1. 

A more enhanced DRILL is needed in today's competitive environment to:

• Make it easier to implement
• Greatly enhance the user (demo :-)) experience

- 

Hi Daniel,

I'm just the TM1 guy but understand you expecting all interfaces to behave consistently. That said, and I'm kind of 'happy' that none of the existing interfaces carry the subset on the title dimensions, MDX, and therefore MDX views (which are nothing more and nothing less then named MDX queries), do not carry set definitions to hint a consumer/front-end/interface as to what elements, members if MDX set, a user ought to be choosing from.

There is an easy work around for that but, as it stands - prototype to fix that too is in the works, you currently can't apply that work around when creating these MDX views in TI (you could through the REST API and therefore any client/interface could do so too.

As for formatting, my understanding is that ability to control formats is expanding in PAW, but either way it is the interfaces choice to adhere to any format specified in TM1 itself or not.

Coincidentally, I am putting together some Drill processes for the first time in a long time.  This is part of a Perspectives to PAW/PAFE conversion.  I expected the Perspectives drills to work without issue in PAW and PAFE.

Please see below what I am experiencing.   If anyone has solutions for my issues please provide.  

Situation - This is part of a multi-step drill process.

Step 1: User viewing a  report or view at the consolidated level of a 15 dimension cube model.  First drill allows the user to Drill to the same cube to different dimensions to get to the Input Element level of the model.  They are allowed to Drill by:

     - three primary dimensions Company, Cost Center or Account: Showing the selected drills dimension on the rows with DESCENDANTS of the element they drilled.

     - or a stacked view of the three accounts showing all there accounts N-Level elements only to see all the input combinations of the dimensions as row elements

Step 2:  Allows the user to DRILL to the SQL GL transactions when they are on an N-Level cell (N-Level for Company, Coot Center, Account dimensions)

===============================================================

The Step 1 processes are a typical DRILL script that:

• builds a VIEW using all the old VIEW functions: ViewCreate, ViewDestroy, ViewExists, ViewTitleDimensionSet, ViewTitleElementSet, ViewRowDimensionSet, ViewRowSuppressZeroesSet, ViewColumnDimensionSet, ViewSubsetAssign
• create unique VIEW based on <Process called> and the USER

The results are different across environments:

This is the SAME drill in each environment.

NOTE - The TI Script assigns SUBSETS and ALIASES to all dimensions.

PAFE - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element from drilled value BUT no alias set
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

PAW - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!
• NOTE - In this interface user has no control over formatting of values etc.

Perspectives - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

NOTE: Also would be great to have control over the default formatting of the values show in the view as part of the script.

===============================================================

I do not expect updates/changes to the old style VIEW functions to be updated by IBM.  But my hope is when the support to assign MDX views to the drill processes are implemented:

• ALL interfaces:  PAW-Reports, PAW-Workbench, PAW/TM1Web-Websheets, PAFE have a consistent result displayed to the user
• Support Title element subset assignments
• Support ability to control default formatting of values

Hi Vitalij,

As per my initial apply to AG, MDX views are indeed not supported YET, but high on the list of things to be added shortly. My proposal for this is to 1) introduce templated MDX (not just for drill-through but generically) and then 2) define how to use a templated MDX when used as a target of a drill-through (which by itself then becomes pretty straightforward presumably, you use the parameters to have their values injected in the WHERE clause and in the case of MDX we'll be passing in MUNs presumably instead of element names - TBD). 

Hello AG, 

I think, for now, there was a kind of "official" message that the drill is only supported with "native" views. 
They want to bring the mdx-views also, however, it has not been the case so far. 

Stuart:

Glad to hear we are in agreement on this.  

In the interim of enhancing the experience once MDX Views are available: Can the current experience be consistent:  Please see my email above where the PAW viewer shows the Title Aliases but the PAFE Viewer does not.

Thanks.

Hi Daniel,

I strongly agree that the drill through configuration should be much more visual and intuitive.  We will consider improving the drill through creation experience in Workspace after we have support for drill through to MDX views in TM1.  

We are currently working on a similar feature for picklist cells.  A modeler can right click on a cell in the cube viewer and turn that cell into a picklist.  This is probably much more intuitive for users that creating a picklist rule or adding a picklist attribute to a dimension.

After clicking the 'Set picklist' option...

There are other options (e.g static list, range of numbers) depending on the cell type you are setting the picklist on.

Hubert:

I understand that the look and feel of the VIEWERS do not fall under your responsibility.  That I believe would fall under  Stuart's or Svetlana's domain.   I hope they take my prior email into account so the user has a consistent experience across interfaces.

But how the overall Drill experience works is a combination of Server side and User interface:

• creating the MDX view that the resulting view displays (your responsibility)
• the configuration of the resulting view the user experiences (Stuarts responsibility)

As a developer what I want to do is:

• Create a template VIEW using the PAW/PAFE VIEWER as the starting point for the TI process this:
  • Defines the initial MDX for the VIEW 
  • Allows the use of all the PAW viewer capabilities to create a greater user experience:
    • Title element assigned subsets etc..
    • Hide dimensions I do not want the user to see
    • Number formatting, Sorting etc.
• In the TI Process all I want to do is:
  • Use the template VIEW as a starting point 
  • Change the elements displayed for each dimension / hierarchy  (Title elements - simple [dimension].[hierarchy].[element], Row/Col - more complicated MDX expression to generate multiple elements (i.e DESCENDANTS() )

I see that the above request would need TI functions changes:

• How to use a current VIEW as the starting point of the view returned keeping all the related visual settings.
• How to return the VIEW with all these settings as part of the DRILL process

==================================================================================

The current design (all TI script to build VIEW and use RETURNVIEWHANDLE())  is greatly limited since all it does create a simple VIEW with no other visual capabilities. 

==================================================================================

I think this is an important conversation since I believe the DRILL capabilities in the past has been a differentiator for TM1. 

A more enhanced DRILL is needed in today's competitive environment to:

• Make it easier to implement
• Greatly enhance the user (demo :-)) experience

- 

Hi Daniel,

I'm just the TM1 guy but understand you expecting all interfaces to behave consistently. That said, and I'm kind of 'happy' that none of the existing interfaces carry the subset on the title dimensions, MDX, and therefore MDX views (which are nothing more and nothing less then named MDX queries), do not carry set definitions to hint a consumer/front-end/interface as to what elements, members if MDX set, a user ought to be choosing from.

There is an easy work around for that but, as it stands - prototype to fix that too is in the works, you currently can't apply that work around when creating these MDX views in TI (you could through the REST API and therefore any client/interface could do so too.

As for formatting, my understanding is that ability to control formats is expanding in PAW, but either way it is the interfaces choice to adhere to any format specified in TM1 itself or not.

Coincidentally, I am putting together some Drill processes for the first time in a long time.  This is part of a Perspectives to PAW/PAFE conversion.  I expected the Perspectives drills to work without issue in PAW and PAFE.

Please see below what I am experiencing.   If anyone has solutions for my issues please provide.  

Situation - This is part of a multi-step drill process.

Step 1: User viewing a  report or view at the consolidated level of a 15 dimension cube model.  First drill allows the user to Drill to the same cube to different dimensions to get to the Input Element level of the model.  They are allowed to Drill by:

     - three primary dimensions Company, Cost Center or Account: Showing the selected drills dimension on the rows with DESCENDANTS of the element they drilled.

     - or a stacked view of the three accounts showing all there accounts N-Level elements only to see all the input combinations of the dimensions as row elements

Step 2:  Allows the user to DRILL to the SQL GL transactions when they are on an N-Level cell (N-Level for Company, Coot Center, Account dimensions)

===============================================================

The Step 1 processes are a typical DRILL script that:

• builds a VIEW using all the old VIEW functions: ViewCreate, ViewDestroy, ViewExists, ViewTitleDimensionSet, ViewTitleElementSet, ViewRowDimensionSet, ViewRowSuppressZeroesSet, ViewColumnDimensionSet, ViewSubsetAssign
• create unique VIEW based on <Process called> and the USER

The results are different across environments:

This is the SAME drill in each environment.

NOTE - The TI Script assigns SUBSETS and ALIASES to all dimensions.

PAFE - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element from drilled value BUT no alias set
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

PAW - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!
• NOTE - In this interface user has no control over formatting of values etc.

Perspectives - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

NOTE: Also would be great to have control over the default formatting of the values show in the view as part of the script.

===============================================================

I do not expect updates/changes to the old style VIEW functions to be updated by IBM.  But my hope is when the support to assign MDX views to the drill processes are implemented:

• ALL interfaces:  PAW-Reports, PAW-Workbench, PAW/TM1Web-Websheets, PAFE have a consistent result displayed to the user
• Support Title element subset assignments
• Support ability to control default formatting of values

Hi Vitalij,

As per my initial apply to AG, MDX views are indeed not supported YET, but high on the list of things to be added shortly. My proposal for this is to 1) introduce templated MDX (not just for drill-through but generically) and then 2) define how to use a templated MDX when used as a target of a drill-through (which by itself then becomes pretty straightforward presumably, you use the parameters to have their values injected in the WHERE clause and in the case of MDX we'll be passing in MUNs presumably instead of element names - TBD). 

Hello AG, 

I think, for now, there was a kind of "official" message that the drill is only supported with "native" views. 
They want to bring the mdx-views also, however, it has not been the case so far. 

Hubert: 

Hi Hubert,

I came across this discussion again while looking into the current status of MilliTime() and millisecond precision in TM1.

It is interesting to see how one of the topics discussed here has evolved since 2024: MDX-based drill-through is now officially supported, including MDX templates and persistent MDX views. This is a nice example of how an idea discussed in the community can eventually make its way into the product.

That made me wonder about the other topic discussed here.

Back in November 2024, you mentioned that the underlying time structures already support milliseconds and suggested that extending NOW() to include milliseconds might be a cleaner solution than exposing MilliTime() as a separate function.

Do you know if there has been any progress on this since then?

From my perspective, millisecond precision would also be very useful for measuring the runtime of relatively short-running TI processes. With NOW() providing only second-level precision, it can be difficult to reliably compare and optimize processes that run within a few hundred milliseconds or a couple of seconds.

I would therefore be very interested to know whether extending NOW() and the related time functions to support milliseconds is still being considered, or whether there is another direction planned for this.

Thanks!

Stuart:

Glad to hear we are in agreement on this.  

In the interim of enhancing the experience once MDX Views are available: Can the current experience be consistent:  Please see my email above where the PAW viewer shows the Title Aliases but the PAFE Viewer does not.

Thanks.

Hi Daniel,

I strongly agree that the drill through configuration should be much more visual and intuitive.  We will consider improving the drill through creation experience in Workspace after we have support for drill through to MDX views in TM1.  

We are currently working on a similar feature for picklist cells.  A modeler can right click on a cell in the cube viewer and turn that cell into a picklist.  This is probably much more intuitive for users that creating a picklist rule or adding a picklist attribute to a dimension.

After clicking the 'Set picklist' option...

There are other options (e.g static list, range of numbers) depending on the cell type you are setting the picklist on.

Hubert:

I understand that the look and feel of the VIEWERS do not fall under your responsibility.  That I believe would fall under  Stuart's or Svetlana's domain.   I hope they take my prior email into account so the user has a consistent experience across interfaces.

But how the overall Drill experience works is a combination of Server side and User interface:

• creating the MDX view that the resulting view displays (your responsibility)
• the configuration of the resulting view the user experiences (Stuarts responsibility)

As a developer what I want to do is:

• Create a template VIEW using the PAW/PAFE VIEWER as the starting point for the TI process this:
  • Defines the initial MDX for the VIEW 
  • Allows the use of all the PAW viewer capabilities to create a greater user experience:
    • Title element assigned subsets etc..
    • Hide dimensions I do not want the user to see
    • Number formatting, Sorting etc.
• In the TI Process all I want to do is:
  • Use the template VIEW as a starting point 
  • Change the elements displayed for each dimension / hierarchy  (Title elements - simple [dimension].[hierarchy].[element], Row/Col - more complicated MDX expression to generate multiple elements (i.e DESCENDANTS() )

I see that the above request would need TI functions changes:

• How to use a current VIEW as the starting point of the view returned keeping all the related visual settings.
• How to return the VIEW with all these settings as part of the DRILL process

==================================================================================

The current design (all TI script to build VIEW and use RETURNVIEWHANDLE())  is greatly limited since all it does create a simple VIEW with no other visual capabilities. 

==================================================================================

I think this is an important conversation since I believe the DRILL capabilities in the past has been a differentiator for TM1. 

A more enhanced DRILL is needed in today's competitive environment to:

• Make it easier to implement
• Greatly enhance the user (demo :-)) experience

- 

Hi Daniel,

I'm just the TM1 guy but understand you expecting all interfaces to behave consistently. That said, and I'm kind of 'happy' that none of the existing interfaces carry the subset on the title dimensions, MDX, and therefore MDX views (which are nothing more and nothing less then named MDX queries), do not carry set definitions to hint a consumer/front-end/interface as to what elements, members if MDX set, a user ought to be choosing from.

There is an easy work around for that but, as it stands - prototype to fix that too is in the works, you currently can't apply that work around when creating these MDX views in TI (you could through the REST API and therefore any client/interface could do so too.

As for formatting, my understanding is that ability to control formats is expanding in PAW, but either way it is the interfaces choice to adhere to any format specified in TM1 itself or not.

Coincidentally, I am putting together some Drill processes for the first time in a long time.  This is part of a Perspectives to PAW/PAFE conversion.  I expected the Perspectives drills to work without issue in PAW and PAFE.

Please see below what I am experiencing.   If anyone has solutions for my issues please provide.  

Situation - This is part of a multi-step drill process.

Step 1: User viewing a  report or view at the consolidated level of a 15 dimension cube model.  First drill allows the user to Drill to the same cube to different dimensions to get to the Input Element level of the model.  They are allowed to Drill by:

     - three primary dimensions Company, Cost Center or Account: Showing the selected drills dimension on the rows with DESCENDANTS of the element they drilled.

     - or a stacked view of the three accounts showing all there accounts N-Level elements only to see all the input combinations of the dimensions as row elements

Step 2:  Allows the user to DRILL to the SQL GL transactions when they are on an N-Level cell (N-Level for Company, Coot Center, Account dimensions)

===============================================================

The Step 1 processes are a typical DRILL script that:

• builds a VIEW using all the old VIEW functions: ViewCreate, ViewDestroy, ViewExists, ViewTitleDimensionSet, ViewTitleElementSet, ViewRowDimensionSet, ViewRowSuppressZeroesSet, ViewColumnDimensionSet, ViewSubsetAssign
• create unique VIEW based on <Process called> and the USER

The results are different across environments:

This is the SAME drill in each environment.

NOTE - The TI Script assigns SUBSETS and ALIASES to all dimensions.

PAFE - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element from drilled value BUT no alias set
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

PAW - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!
• NOTE - In this interface user has no control over formatting of values etc.

Perspectives - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

NOTE: Also would be great to have control over the default formatting of the values show in the view as part of the script.

===============================================================

I do not expect updates/changes to the old style VIEW functions to be updated by IBM.  But my hope is when the support to assign MDX views to the drill processes are implemented:

• ALL interfaces:  PAW-Reports, PAW-Workbench, PAW/TM1Web-Websheets, PAFE have a consistent result displayed to the user
• Support Title element subset assignments
• Support ability to control default formatting of values

Hi Vitalij,

As per my initial apply to AG, MDX views are indeed not supported YET, but high on the list of things to be added shortly. My proposal for this is to 1) introduce templated MDX (not just for drill-through but generically) and then 2) define how to use a templated MDX when used as a target of a drill-through (which by itself then becomes pretty straightforward presumably, you use the parameters to have their values injected in the WHERE clause and in the case of MDX we'll be passing in MUNs presumably instead of element names - TBD). 

Hello AG, 

I think, for now, there was a kind of "official" message that the drill is only supported with "native" views. 
They want to bring the mdx-views also, however, it has not been the case so far. 

Hi Vitalij,

I actually started working on this one but got ambitious thinking I can fix/streamline everything time related in TM1, which turned out to be a bit of a challenge. Not because technically it's hard to do, it actually cleans things up nicely (that part I've got done), but I'm afraid people might have stored the floating point representation of points in time, or the milliseconds number in case of MilliTime, for which I might, not in the last place because of some time related configurations in TM1 as well, end up changing the base (all points in time are relative to a data. String representations are fine, just the numeric values representing point in time might be impacted.

Good news, worst case, I can make MilliTime be Now with milliseconds as that number used to be relative to the server start and therefore can never have served as a point in time representation. Changing that to the same offset as Now as opposed to server start time would not change it behavior or how it can be used.

To be continued... <got bigger fish to fry right now I'm afraid;->

Hubert: 

Hi Hubert,

I came across this discussion again while looking into the current status of MilliTime() and millisecond precision in TM1.

It is interesting to see how one of the topics discussed here has evolved since 2024: MDX-based drill-through is now officially supported, including MDX templates and persistent MDX views. This is a nice example of how an idea discussed in the community can eventually make its way into the product.

That made me wonder about the other topic discussed here.

Back in November 2024, you mentioned that the underlying time structures already support milliseconds and suggested that extending NOW() to include milliseconds might be a cleaner solution than exposing MilliTime() as a separate function.

Do you know if there has been any progress on this since then?

From my perspective, millisecond precision would also be very useful for measuring the runtime of relatively short-running TI processes. With NOW() providing only second-level precision, it can be difficult to reliably compare and optimize processes that run within a few hundred milliseconds or a couple of seconds.

I would therefore be very interested to know whether extending NOW() and the related time functions to support milliseconds is still being considered, or whether there is another direction planned for this.

Thanks!

Stuart:

Glad to hear we are in agreement on this.  

In the interim of enhancing the experience once MDX Views are available: Can the current experience be consistent:  Please see my email above where the PAW viewer shows the Title Aliases but the PAFE Viewer does not.

Thanks.

Hi Daniel,

I strongly agree that the drill through configuration should be much more visual and intuitive.  We will consider improving the drill through creation experience in Workspace after we have support for drill through to MDX views in TM1.  

We are currently working on a similar feature for picklist cells.  A modeler can right click on a cell in the cube viewer and turn that cell into a picklist.  This is probably much more intuitive for users that creating a picklist rule or adding a picklist attribute to a dimension.

After clicking the 'Set picklist' option...

There are other options (e.g static list, range of numbers) depending on the cell type you are setting the picklist on.

Hubert:

I understand that the look and feel of the VIEWERS do not fall under your responsibility.  That I believe would fall under  Stuart's or Svetlana's domain.   I hope they take my prior email into account so the user has a consistent experience across interfaces.

But how the overall Drill experience works is a combination of Server side and User interface:

• creating the MDX view that the resulting view displays (your responsibility)
• the configuration of the resulting view the user experiences (Stuarts responsibility)

As a developer what I want to do is:

• Create a template VIEW using the PAW/PAFE VIEWER as the starting point for the TI process this:
  • Defines the initial MDX for the VIEW 
  • Allows the use of all the PAW viewer capabilities to create a greater user experience:
    • Title element assigned subsets etc..
    • Hide dimensions I do not want the user to see
    • Number formatting, Sorting etc.
• In the TI Process all I want to do is:
  • Use the template VIEW as a starting point 
  • Change the elements displayed for each dimension / hierarchy  (Title elements - simple [dimension].[hierarchy].[element], Row/Col - more complicated MDX expression to generate multiple elements (i.e DESCENDANTS() )

I see that the above request would need TI functions changes:

• How to use a current VIEW as the starting point of the view returned keeping all the related visual settings.
• How to return the VIEW with all these settings as part of the DRILL process

==================================================================================

The current design (all TI script to build VIEW and use RETURNVIEWHANDLE())  is greatly limited since all it does create a simple VIEW with no other visual capabilities. 

==================================================================================

I think this is an important conversation since I believe the DRILL capabilities in the past has been a differentiator for TM1. 

A more enhanced DRILL is needed in today's competitive environment to:

• Make it easier to implement
• Greatly enhance the user (demo :-)) experience

- 

Hi Daniel,

I'm just the TM1 guy but understand you expecting all interfaces to behave consistently. That said, and I'm kind of 'happy' that none of the existing interfaces carry the subset on the title dimensions, MDX, and therefore MDX views (which are nothing more and nothing less then named MDX queries), do not carry set definitions to hint a consumer/front-end/interface as to what elements, members if MDX set, a user ought to be choosing from.

There is an easy work around for that but, as it stands - prototype to fix that too is in the works, you currently can't apply that work around when creating these MDX views in TI (you could through the REST API and therefore any client/interface could do so too.

As for formatting, my understanding is that ability to control formats is expanding in PAW, but either way it is the interfaces choice to adhere to any format specified in TM1 itself or not.

Coincidentally, I am putting together some Drill processes for the first time in a long time.  This is part of a Perspectives to PAW/PAFE conversion.  I expected the Perspectives drills to work without issue in PAW and PAFE.

Please see below what I am experiencing.   If anyone has solutions for my issues please provide.  

Situation - This is part of a multi-step drill process.

Step 1: User viewing a  report or view at the consolidated level of a 15 dimension cube model.  First drill allows the user to Drill to the same cube to different dimensions to get to the Input Element level of the model.  They are allowed to Drill by:

     - three primary dimensions Company, Cost Center or Account: Showing the selected drills dimension on the rows with DESCENDANTS of the element they drilled.

     - or a stacked view of the three accounts showing all there accounts N-Level elements only to see all the input combinations of the dimensions as row elements

Step 2:  Allows the user to DRILL to the SQL GL transactions when they are on an N-Level cell (N-Level for Company, Coot Center, Account dimensions)

===============================================================

The Step 1 processes are a typical DRILL script that:

• builds a VIEW using all the old VIEW functions: ViewCreate, ViewDestroy, ViewExists, ViewTitleDimensionSet, ViewTitleElementSet, ViewRowDimensionSet, ViewRowSuppressZeroesSet, ViewColumnDimensionSet, ViewSubsetAssign
• create unique VIEW based on <Process called> and the USER

The results are different across environments:

This is the SAME drill in each environment.

NOTE - The TI Script assigns SUBSETS and ALIASES to all dimensions.

PAFE - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element from drilled value BUT no alias set
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

PAW - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!
• NOTE - In this interface user has no control over formatting of values etc.

Perspectives - 

- Drill works shows the ROW assigned dimension with alias and DESCENDANTS of drill value.

• YELLOW - all title elements correct element and alias CORRECTLY set 
• BLUE - Subset not assigned to the VIEW so user needs to open Editor to change title elements!

NOTE: Also would be great to have control over the default formatting of the values show in the view as part of the script.

===============================================================

I do not expect updates/changes to the old style VIEW functions to be updated by IBM.  But my hope is when the support to assign MDX views to the drill processes are implemented:

• ALL interfaces:  PAW-Reports, PAW-Workbench, PAW/TM1Web-Websheets, PAFE have a consistent result displayed to the user
• Support Title element subset assignments
• Support ability to control default formatting of values

Hi Vitalij,

As per my initial apply to AG, MDX views are indeed not supported YET, but high on the list of things to be added shortly. My proposal for this is to 1) introduce templated MDX (not just for drill-through but generically) and then 2) define how to use a templated MDX when used as a target of a drill-through (which by itself then becomes pretty straightforward presumably, you use the parameters to have their values injected in the WHERE clause and in the case of MDX we'll be passing in MUNs presumably instead of element names - TBD). 

Hello AG, 

I think, for now, there was a kind of "official" message that the drill is only supported with "native" views. 
They want to bring the mdx-views also, however, it has not been the case so far.