Hi Hubert

Thanks for the reply.

We are currently evaluating 2.0.9 but other work has delayed progress on that. The Finance Dept decided they would rather have a Non Trial Balance collection system which a colleague has built, and a chart of accounts change request system which I have built. This uses a JavaScript Framework (Vue & Node) front end, a SQL Server backend, and various TI processes to update the PA 2.0.5 dimensions.

Finance Depts are risk adverse. At present we are using 2.0.5 in pretty much the same way that we used TM1. We are still using TM1 Web in Production. TM1 Web is important for us as many users are in partner organisations outside of our network.

We are not using PAW. Until it is possible to synchronise selections with TI buttons, we can't use PAW.

We are not using PAX, although we are getting close to resolving some of the SSL certificate issues, and hope to be using it soon. At present only developers can use it.

I have built the Chart of Accounts system to support Named Hierarchies. However, we cannot simply change several years of development or retrain 300 users who are used to TM1 Web. At present, until issues with PAW are fixed there is not, in any case, a viable alternative. Therefore all the TI that I have written to build dimensions from the SQL database that holds the Chart of Accounts information, all replicate the structure of each Named Hierarchy, as an alternate hierarchy in the default hierarchy. I have stuck to the standard that alternate hierarchies only exist in the default hierarchy, and any Named Hierarchy only has a single hierarchy. However, we do need to generate some alternate hierarchies to support existing development and systems.

When you say

"I wouldn't expect users that are starting to use alternate hierarchies to mix the old, deprecated, Dimension functions with the new Hierarchy based functions"

I think that the reality is that there will be continued use of both functions, because a lot of people will need to update existing dimensions that are accessed by tools that don't support named hierarchies.

There are some areas where there is not an equivalent hierarchy function. When writing in attribute values if I want to check whether the cell is updateable or if a rule applies to it, I need to use CellIsUpdateable on the Element Attributes Cube, and specify Hierarchy colon Element , then the Attribute, as there is no equivalent of this function with a hierarchy parameter.

Reading from attribute cubes with named hierarchies is a problem, as you can only do this using an MDX View, and TI does not read text from MDX Views correctly. I reported this bug a year or so ago and as far as I know it has still not been resolved.

I may be wrong but I cannot see that many people converting from TI to using the Rest API. I would guess that the majority of all TM1 developers come from an Accountancy rather than IT background. I would guess that they will struggle to get to grips with the Rest API. I am from an IT background and the design of the Rest API is very computer science oriented. It is probably more of a tool for partners than end-users. I also suspect that there will also be cases where TI runs faster than eg Python or JavaScript calling the RestAPI simply because it runs in process.

If you look at the TM1 Reference guide on the IBM Knowledge centre, which should reflect the latest version, and then look at the Hierarchy Rules Functions, which contain things that would be useful in TI to allow a process to loop around all hierarchies in a dimension, all of them say "cannot be used in TurboIntegrator processes. The presence of this function in a process will prevent the process from compiling. ".

Pretty much any other Rules Function can be used in a TI Process.

Regards

Paul

Paul Simon

Success Cubed Ltd

Tel: +44 7941 506 197

www.successcubed.co.uk

Skype Name: paulsimongb

Skype Tel: +44 20 3287 4616

Hi Hubert

Thanks for the reply.

We are currently evaluating 2.0.9 but other work has delayed progress on that. The Finance Dept decided they would rather have a Non Trial Balance collection system which a colleague has built, and a chart of accounts change request system which I have built. This uses a JavaScript Framework (Vue & Node) front end, a SQL Server backend, and various TI processes to update the PA 2.0.5 dimensions.

Finance Depts are risk adverse. At present we are using 2.0.5 in pretty much the same way that we used TM1. We are still using TM1 Web in Production. TM1 Web is important for us as many users are in partner organisations outside of our network.

We are not using PAW. Until it is possible to synchronise selections with TI buttons, we can't use PAW.

We are not using PAX, although we are getting close to resolving some of the SSL certificate issues, and hope to be using it soon. At present only developers can use it.

I have built the Chart of Accounts system to support Named Hierarchies. However, we cannot simply change several years of development or retrain 300 users who are used to TM1 Web. At present, until issues with PAW are fixed there is not, in any case, a viable alternative. Therefore all the TI that I have written to build dimensions from the SQL database that holds the Chart of Accounts information, all replicate the structure of each Named Hierarchy, as an alternate hierarchy in the default hierarchy. I have stuck to the standard that alternate hierarchies only exist in the default hierarchy, and any Named Hierarchy only has a single hierarchy. However, we do need to generate some alternate hierarchies to support existing development and systems.

When you say

"I wouldn't expect users that are starting to use alternate hierarchies to mix the old, deprecated, Dimension functions with the new Hierarchy based functions"

I think that the reality is that there will be continued use of both functions, because a lot of people will need to update existing dimensions that are accessed by tools that don't support named hierarchies.

There are some areas where there is not an equivalent hierarchy function. When writing in attribute values if I want to check whether the cell is updateable or if a rule applies to it, I need to use CellIsUpdateable on the Element Attributes Cube, and specify Hierarchy colon Element , then the Attribute, as there is no equivalent of this function with a hierarchy parameter.

Reading from attribute cubes with named hierarchies is a problem, as you can only do this using an MDX View, and TI does not read text from MDX Views correctly. I reported this bug a year or so ago and as far as I know it has still not been resolved.

I may be wrong but I cannot see that many people converting from TI to using the Rest API. I would guess that the majority of all TM1 developers come from an Accountancy rather than IT background. I would guess that they will struggle to get to grips with the Rest API. I am from an IT background and the design of the Rest API is very computer science oriented. It is probably more of a tool for partners than end-users. I also suspect that there will also be cases where TI runs faster than eg Python or JavaScript calling the RestAPI simply because it runs in process.

If you look at the TM1 Reference guide on the IBM Knowledge centre, which should reflect the latest version, and then look at the Hierarchy Rules Functions, which contain things that would be useful in TI to allow a process to loop around all hierarchies in a dimension, all of them say "cannot be used in TurboIntegrator processes. The presence of this function in a process will prevent the process from compiling. ".

Pretty much any other Rules Function can be used in a TI Process.

Regards

Paul

Paul Simon

Success Cubed Ltd

Tel: +44 7941 506 197

www.successcubed.co.uk

Skype Name: paulsimongb

Skype Tel: +44 20 3287 4616

Hi Hubert

Many thanks for your reply.

One thing that I find very confusing about IBM with Planning Analytics is its version numbering. We have 2.0.5 in production but you are talking about 11.8. To a certain extent 11.8 makes more sense in terms of the logical progression of TM1 version numbers. I have been using TM1 since version 6. However, for some reason when IBM changed the name to Planning Analytics they decided to revert to version 2.0.0.

Actually identifying what version number you are on, is actually very difficult, particularly when IBM have two version numbering systems for the core server, and another version numbering scheme for PAW and PAX.

Can I make a plea that IBM sticks to one version numbering system.

How do I actually find out what version number in the 11 series I am actually on? Is it by looking at the version number on the tm1sd.exe reliable?

On a server with version number 2.0.8 installed this is showing 11.6. Therefore it is presumably 2.0.9.3 or something like that which is version 11.8? If it was just a matter of swapping the 2 for an 11 it would be easier but the minor version numbering is not even in step.

If I go to download PA the version numbering still shows 2.0.9.3, you have to click a couple of times into the detail to find that it contains TM1 Server version 11.8.2. However, with PAW and PAX now being on different release schedules to the server, what actually is in a Planning Analytics version apart the server? Can IBM please revert to and standardise on 11 series numbering for the server. If PAW and PAX are numbered differently that is fine, since they potentially have a different update cycle to the server.

Anyway good to know that the issue with TI handling Text from MDX Views is fixed as at present the work around of looping round attributes is considerably slowing down dimension updates.

I don't understand what "not in the last place due to a case raised by Hallbjorn" means? Is this a code word for a new version or another customer?

You asked for a use case for Hierarchy Functions in TI as opposed to rules. There are numerous cases where I have functions that loop over all hierarchies in a dimension. If I could use these hierarchy functions in TI then this would be possible, but without them, the only way of doing this is to maintain my own cubes of the hierarchies in each dimension. I have built a dimension where there are consolidations for each dimension expanding to leaf level elements of the dimension:hierarchy combinations in the dimension to allow me to do this. I use this in a cube to hold information on the hierarchy such as its top level element, the name of its base level, etc. However, not everyone wants to build their own cubes for this.

One example is the difficulty of deleting an element. In general, it must be deleted from the classic default hierarchy, one or more Named Hierarchies, and possibly also the leaf hierarchy. Unless you delete it from all cases, it is likely to work its way back in at the next dimension update. If you can write a TI that loops around all named hierarchies in a dimension, then this is relatively easy, but this ability is not currently supported by native TI functions.

If the hierarchy functions where available in TI instead of just rules I could write a generic TI process that takes a parameter of the Dim and Element to be deleted from all hierarchies.

IF( Dimix( vDim , vElem ) > 0 ) ;

  DimensionElementDelete( vDim , vElem ) ;

ENDIF ;

# Also delete from all Named Hierarchies, if the dimension has Named Hierarchies

IF( Hierarchy( vDim ) = 1 ) ;

  vNumHiers = HierarchyCount( vDim ) ;

  vHierNum = 0 ;

  WHILE( vHierNum < vNumHiers ) ;

    vHierNum = vHierNum + 1 ;

    vHier = HierarchyN( vDim, vHierNum ) ;

    IF( HierarchyElementExists( vDim , vHIer, vElem ) = 1 ) ;

      HierarchyElementDelete( vDim , vHier , vElem ) ;

    ENDIF ;

   END ;

ENDIF ;

And at some point HierarchyIndex could be of use.

Another example is that we have a set of standard subsets that we want to create for each hierarchy. If we want to add another subset to this standard we need a way to loop around all dimensions and all hierarchies within those dimensions. At present we create subsets for base level elements, consolidations, full hierarchy and a default subset being the top level element. In }ElementAttributes cubes, we also want to be able to create a default view for each hierarchy, which again requires the ability to loop for each hierarchy in a dimension.

So I think that these functions do have a context in a TI process.

The new Named Hierarchies do add a lot of functionality to TM1, and they are definitely a good thing. However, like anything new it is difficult to think of every possible ramification in advance.

Regards

Paul Simon

Hi Hubert

Thanks for the reply.

We are currently evaluating 2.0.9 but other work has delayed progress on that. The Finance Dept decided they would rather have a Non Trial Balance collection system which a colleague has built, and a chart of accounts change request system which I have built. This uses a JavaScript Framework (Vue & Node) front end, a SQL Server backend, and various TI processes to update the PA 2.0.5 dimensions.

Finance Depts are risk adverse. At present we are using 2.0.5 in pretty much the same way that we used TM1. We are still using TM1 Web in Production. TM1 Web is important for us as many users are in partner organisations outside of our network.

We are not using PAW. Until it is possible to synchronise selections with TI buttons, we can't use PAW.

We are not using PAX, although we are getting close to resolving some of the SSL certificate issues, and hope to be using it soon. At present only developers can use it.

I have built the Chart of Accounts system to support Named Hierarchies. However, we cannot simply change several years of development or retrain 300 users who are used to TM1 Web. At present, until issues with PAW are fixed there is not, in any case, a viable alternative. Therefore all the TI that I have written to build dimensions from the SQL database that holds the Chart of Accounts information, all replicate the structure of each Named Hierarchy, as an alternate hierarchy in the default hierarchy. I have stuck to the standard that alternate hierarchies only exist in the default hierarchy, and any Named Hierarchy only has a single hierarchy. However, we do need to generate some alternate hierarchies to support existing development and systems.

When you say

"I wouldn't expect users that are starting to use alternate hierarchies to mix the old, deprecated, Dimension functions with the new Hierarchy based functions"

I think that the reality is that there will be continued use of both functions, because a lot of people will need to update existing dimensions that are accessed by tools that don't support named hierarchies.

There are some areas where there is not an equivalent hierarchy function. When writing in attribute values if I want to check whether the cell is updateable or if a rule applies to it, I need to use CellIsUpdateable on the Element Attributes Cube, and specify Hierarchy colon Element , then the Attribute, as there is no equivalent of this function with a hierarchy parameter.

Reading from attribute cubes with named hierarchies is a problem, as you can only do this using an MDX View, and TI does not read text from MDX Views correctly. I reported this bug a year or so ago and as far as I know it has still not been resolved.

I may be wrong but I cannot see that many people converting from TI to using the Rest API. I would guess that the majority of all TM1 developers come from an Accountancy rather than IT background. I would guess that they will struggle to get to grips with the Rest API. I am from an IT background and the design of the Rest API is very computer science oriented. It is probably more of a tool for partners than end-users. I also suspect that there will also be cases where TI runs faster than eg Python or JavaScript calling the RestAPI simply because it runs in process.

If you look at the TM1 Reference guide on the IBM Knowledge centre, which should reflect the latest version, and then look at the Hierarchy Rules Functions, which contain things that would be useful in TI to allow a process to loop around all hierarchies in a dimension, all of them say "cannot be used in TurboIntegrator processes. The presence of this function in a process will prevent the process from compiling. ".

Pretty much any other Rules Function can be used in a TI Process.

Regards

Paul

Paul Simon

Success Cubed Ltd

Tel: +44 7941 506 197

www.successcubed.co.uk

Skype Name: paulsimongb

Skype Tel: +44 20 3287 4616

Hi Hubert

Many thanks for your reply.

One thing that I find very confusing about IBM with Planning Analytics is its version numbering. We have 2.0.5 in production but you are talking about 11.8. To a certain extent 11.8 makes more sense in terms of the logical progression of TM1 version numbers. I have been using TM1 since version 6. However, for some reason when IBM changed the name to Planning Analytics they decided to revert to version 2.0.0.

Actually identifying what version number you are on, is actually very difficult, particularly when IBM have two version numbering systems for the core server, and another version numbering scheme for PAW and PAX.

Can I make a plea that IBM sticks to one version numbering system.

How do I actually find out what version number in the 11 series I am actually on? Is it by looking at the version number on the tm1sd.exe reliable?

On a server with version number 2.0.8 installed this is showing 11.6. Therefore it is presumably 2.0.9.3 or something like that which is version 11.8? If it was just a matter of swapping the 2 for an 11 it would be easier but the minor version numbering is not even in step.

If I go to download PA the version numbering still shows 2.0.9.3, you have to click a couple of times into the detail to find that it contains TM1 Server version 11.8.2. However, with PAW and PAX now being on different release schedules to the server, what actually is in a Planning Analytics version apart the server? Can IBM please revert to and standardise on 11 series numbering for the server. If PAW and PAX are numbered differently that is fine, since they potentially have a different update cycle to the server.

Anyway good to know that the issue with TI handling Text from MDX Views is fixed as at present the work around of looping round attributes is considerably slowing down dimension updates.

I don't understand what "not in the last place due to a case raised by Hallbjorn" means? Is this a code word for a new version or another customer?

You asked for a use case for Hierarchy Functions in TI as opposed to rules. There are numerous cases where I have functions that loop over all hierarchies in a dimension. If I could use these hierarchy functions in TI then this would be possible, but without them, the only way of doing this is to maintain my own cubes of the hierarchies in each dimension. I have built a dimension where there are consolidations for each dimension expanding to leaf level elements of the dimension:hierarchy combinations in the dimension to allow me to do this. I use this in a cube to hold information on the hierarchy such as its top level element, the name of its base level, etc. However, not everyone wants to build their own cubes for this.

One example is the difficulty of deleting an element. In general, it must be deleted from the classic default hierarchy, one or more Named Hierarchies, and possibly also the leaf hierarchy. Unless you delete it from all cases, it is likely to work its way back in at the next dimension update. If you can write a TI that loops around all named hierarchies in a dimension, then this is relatively easy, but this ability is not currently supported by native TI functions.

If the hierarchy functions where available in TI instead of just rules I could write a generic TI process that takes a parameter of the Dim and Element to be deleted from all hierarchies.

IF( Dimix( vDim , vElem ) > 0 ) ;

  DimensionElementDelete( vDim , vElem ) ;

ENDIF ;

# Also delete from all Named Hierarchies, if the dimension has Named Hierarchies

IF( Hierarchy( vDim ) = 1 ) ;

  vNumHiers = HierarchyCount( vDim ) ;

  vHierNum = 0 ;

  WHILE( vHierNum < vNumHiers ) ;

    vHierNum = vHierNum + 1 ;

    vHier = HierarchyN( vDim, vHierNum ) ;

    IF( HierarchyElementExists( vDim , vHIer, vElem ) = 1 ) ;

      HierarchyElementDelete( vDim , vHier , vElem ) ;

    ENDIF ;

   END ;

ENDIF ;

And at some point HierarchyIndex could be of use.

Another example is that we have a set of standard subsets that we want to create for each hierarchy. If we want to add another subset to this standard we need a way to loop around all dimensions and all hierarchies within those dimensions. At present we create subsets for base level elements, consolidations, full hierarchy and a default subset being the top level element. In }ElementAttributes cubes, we also want to be able to create a default view for each hierarchy, which again requires the ability to loop for each hierarchy in a dimension.

So I think that these functions do have a context in a TI process.

The new Named Hierarchies do add a lot of functionality to TM1, and they are definitely a good thing. However, like anything new it is difficult to think of every possible ramification in advance.

Regards

Paul Simon

Hi Hubert

Thanks for the reply.

We are currently evaluating 2.0.9 but other work has delayed progress on that. The Finance Dept decided they would rather have a Non Trial Balance collection system which a colleague has built, and a chart of accounts change request system which I have built. This uses a JavaScript Framework (Vue & Node) front end, a SQL Server backend, and various TI processes to update the PA 2.0.5 dimensions.

Finance Depts are risk adverse. At present we are using 2.0.5 in pretty much the same way that we used TM1. We are still using TM1 Web in Production. TM1 Web is important for us as many users are in partner organisations outside of our network.

We are not using PAW. Until it is possible to synchronise selections with TI buttons, we can't use PAW.

We are not using PAX, although we are getting close to resolving some of the SSL certificate issues, and hope to be using it soon. At present only developers can use it.

I have built the Chart of Accounts system to support Named Hierarchies. However, we cannot simply change several years of development or retrain 300 users who are used to TM1 Web. At present, until issues with PAW are fixed there is not, in any case, a viable alternative. Therefore all the TI that I have written to build dimensions from the SQL database that holds the Chart of Accounts information, all replicate the structure of each Named Hierarchy, as an alternate hierarchy in the default hierarchy. I have stuck to the standard that alternate hierarchies only exist in the default hierarchy, and any Named Hierarchy only has a single hierarchy. However, we do need to generate some alternate hierarchies to support existing development and systems.

When you say

"I wouldn't expect users that are starting to use alternate hierarchies to mix the old, deprecated, Dimension functions with the new Hierarchy based functions"

I think that the reality is that there will be continued use of both functions, because a lot of people will need to update existing dimensions that are accessed by tools that don't support named hierarchies.

There are some areas where there is not an equivalent hierarchy function. When writing in attribute values if I want to check whether the cell is updateable or if a rule applies to it, I need to use CellIsUpdateable on the Element Attributes Cube, and specify Hierarchy colon Element , then the Attribute, as there is no equivalent of this function with a hierarchy parameter.

Reading from attribute cubes with named hierarchies is a problem, as you can only do this using an MDX View, and TI does not read text from MDX Views correctly. I reported this bug a year or so ago and as far as I know it has still not been resolved.

I may be wrong but I cannot see that many people converting from TI to using the Rest API. I would guess that the majority of all TM1 developers come from an Accountancy rather than IT background. I would guess that they will struggle to get to grips with the Rest API. I am from an IT background and the design of the Rest API is very computer science oriented. It is probably more of a tool for partners than end-users. I also suspect that there will also be cases where TI runs faster than eg Python or JavaScript calling the RestAPI simply because it runs in process.

If you look at the TM1 Reference guide on the IBM Knowledge centre, which should reflect the latest version, and then look at the Hierarchy Rules Functions, which contain things that would be useful in TI to allow a process to loop around all hierarchies in a dimension, all of them say "cannot be used in TurboIntegrator processes. The presence of this function in a process will prevent the process from compiling. ".

Pretty much any other Rules Function can be used in a TI Process.

Regards

Paul

Paul Simon

Success Cubed Ltd

Tel: +44 7941 506 197

www.successcubed.co.uk

Skype Name: paulsimongb

Skype Tel: +44 20 3287 4616

Hi Hubert

Having to use a WHILE loop to iterate is not too bad. A FOR loop might be nicer or even a FOR EACH, but it can be done with a WHILE. I spend half my time these days programming in JavaScript and sometimes too many options is not a good thing. I accept that TI is a scripting language not a full programming language so I lower my expectations. The only feature I really miss is the ability to call a function and get a return value. Other than that TI has the basics of any programming language sequence, selection and iteration.

I don't think IBM have made it any harder to iterate over dimensions. I have been doing this for years to iterate over elements in Dimensions, and Dimension Subsets, components of consolidations, parents or elements, etc.

However, at present iterating over the Hierarchies within a Dimension is impossible in native TI. You have to build work around cubes and dimensions to do it.

You can ignore the Hierarchy() function. As a bare minimum I would just need:

HierarchyCount() to return the number of hierarchies in the dimension. The documentation would need to specify whether this included the Classic Default Hierarchy and / or the Leaf Hierarchy.

HierarchyN() to return the Name of the Hierarchy of the given dimension at the given Nth position.

Please have a word with someone at IBM about versioning. When we log a support call we actually have to wait for instructions on how to tell them what version we are on, and it generally involves delving into the file system and sending over a bunch of files. What is so difficult about having one number for TM1 and one for PAW/PAX/TM1 Web? IBM needs to learn to become a more customer centric company.

Regards

Paul Simon

Hi Hubert

Many thanks for your reply.

One thing that I find very confusing about IBM with Planning Analytics is its version numbering. We have 2.0.5 in production but you are talking about 11.8. To a certain extent 11.8 makes more sense in terms of the logical progression of TM1 version numbers. I have been using TM1 since version 6. However, for some reason when IBM changed the name to Planning Analytics they decided to revert to version 2.0.0.

Actually identifying what version number you are on, is actually very difficult, particularly when IBM have two version numbering systems for the core server, and another version numbering scheme for PAW and PAX.

Can I make a plea that IBM sticks to one version numbering system.

How do I actually find out what version number in the 11 series I am actually on? Is it by looking at the version number on the tm1sd.exe reliable?

On a server with version number 2.0.8 installed this is showing 11.6. Therefore it is presumably 2.0.9.3 or something like that which is version 11.8? If it was just a matter of swapping the 2 for an 11 it would be easier but the minor version numbering is not even in step.

If I go to download PA the version numbering still shows 2.0.9.3, you have to click a couple of times into the detail to find that it contains TM1 Server version 11.8.2. However, with PAW and PAX now being on different release schedules to the server, what actually is in a Planning Analytics version apart the server? Can IBM please revert to and standardise on 11 series numbering for the server. If PAW and PAX are numbered differently that is fine, since they potentially have a different update cycle to the server.

Anyway good to know that the issue with TI handling Text from MDX Views is fixed as at present the work around of looping round attributes is considerably slowing down dimension updates.

I don't understand what "not in the last place due to a case raised by Hallbjorn" means? Is this a code word for a new version or another customer?

You asked for a use case for Hierarchy Functions in TI as opposed to rules. There are numerous cases where I have functions that loop over all hierarchies in a dimension. If I could use these hierarchy functions in TI then this would be possible, but without them, the only way of doing this is to maintain my own cubes of the hierarchies in each dimension. I have built a dimension where there are consolidations for each dimension expanding to leaf level elements of the dimension:hierarchy combinations in the dimension to allow me to do this. I use this in a cube to hold information on the hierarchy such as its top level element, the name of its base level, etc. However, not everyone wants to build their own cubes for this.

One example is the difficulty of deleting an element. In general, it must be deleted from the classic default hierarchy, one or more Named Hierarchies, and possibly also the leaf hierarchy. Unless you delete it from all cases, it is likely to work its way back in at the next dimension update. If you can write a TI that loops around all named hierarchies in a dimension, then this is relatively easy, but this ability is not currently supported by native TI functions.

If the hierarchy functions where available in TI instead of just rules I could write a generic TI process that takes a parameter of the Dim and Element to be deleted from all hierarchies.

IF( Dimix( vDim , vElem ) > 0 ) ;

  DimensionElementDelete( vDim , vElem ) ;

ENDIF ;

# Also delete from all Named Hierarchies, if the dimension has Named Hierarchies

IF( Hierarchy( vDim ) = 1 ) ;

  vNumHiers = HierarchyCount( vDim ) ;

  vHierNum = 0 ;

  WHILE( vHierNum < vNumHiers ) ;

    vHierNum = vHierNum + 1 ;

    vHier = HierarchyN( vDim, vHierNum ) ;

    IF( HierarchyElementExists( vDim , vHIer, vElem ) = 1 ) ;

      HierarchyElementDelete( vDim , vHier , vElem ) ;

    ENDIF ;

   END ;

ENDIF ;

And at some point HierarchyIndex could be of use.

Another example is that we have a set of standard subsets that we want to create for each hierarchy. If we want to add another subset to this standard we need a way to loop around all dimensions and all hierarchies within those dimensions. At present we create subsets for base level elements, consolidations, full hierarchy and a default subset being the top level element. In }ElementAttributes cubes, we also want to be able to create a default view for each hierarchy, which again requires the ability to loop for each hierarchy in a dimension.

So I think that these functions do have a context in a TI process.

The new Named Hierarchies do add a lot of functionality to TM1, and they are definitely a good thing. However, like anything new it is difficult to think of every possible ramification in advance.

Regards

Paul Simon

Hi Hubert

Thanks for the reply.

We are currently evaluating 2.0.9 but other work has delayed progress on that. The Finance Dept decided they would rather have a Non Trial Balance collection system which a colleague has built, and a chart of accounts change request system which I have built. This uses a JavaScript Framework (Vue & Node) front end, a SQL Server backend, and various TI processes to update the PA 2.0.5 dimensions.

Finance Depts are risk adverse. At present we are using 2.0.5 in pretty much the same way that we used TM1. We are still using TM1 Web in Production. TM1 Web is important for us as many users are in partner organisations outside of our network.

We are not using PAW. Until it is possible to synchronise selections with TI buttons, we can't use PAW.

We are not using PAX, although we are getting close to resolving some of the SSL certificate issues, and hope to be using it soon. At present only developers can use it.

I have built the Chart of Accounts system to support Named Hierarchies. However, we cannot simply change several years of development or retrain 300 users who are used to TM1 Web. At present, until issues with PAW are fixed there is not, in any case, a viable alternative. Therefore all the TI that I have written to build dimensions from the SQL database that holds the Chart of Accounts information, all replicate the structure of each Named Hierarchy, as an alternate hierarchy in the default hierarchy. I have stuck to the standard that alternate hierarchies only exist in the default hierarchy, and any Named Hierarchy only has a single hierarchy. However, we do need to generate some alternate hierarchies to support existing development and systems.

When you say

"I wouldn't expect users that are starting to use alternate hierarchies to mix the old, deprecated, Dimension functions with the new Hierarchy based functions"

I think that the reality is that there will be continued use of both functions, because a lot of people will need to update existing dimensions that are accessed by tools that don't support named hierarchies.

There are some areas where there is not an equivalent hierarchy function. When writing in attribute values if I want to check whether the cell is updateable or if a rule applies to it, I need to use CellIsUpdateable on the Element Attributes Cube, and specify Hierarchy colon Element , then the Attribute, as there is no equivalent of this function with a hierarchy parameter.

Reading from attribute cubes with named hierarchies is a problem, as you can only do this using an MDX View, and TI does not read text from MDX Views correctly. I reported this bug a year or so ago and as far as I know it has still not been resolved.

I may be wrong but I cannot see that many people converting from TI to using the Rest API. I would guess that the majority of all TM1 developers come from an Accountancy rather than IT background. I would guess that they will struggle to get to grips with the Rest API. I am from an IT background and the design of the Rest API is very computer science oriented. It is probably more of a tool for partners than end-users. I also suspect that there will also be cases where TI runs faster than eg Python or JavaScript calling the RestAPI simply because it runs in process.

If you look at the TM1 Reference guide on the IBM Knowledge centre, which should reflect the latest version, and then look at the Hierarchy Rules Functions, which contain things that would be useful in TI to allow a process to loop around all hierarchies in a dimension, all of them say "cannot be used in TurboIntegrator processes. The presence of this function in a process will prevent the process from compiling. ".

Pretty much any other Rules Function can be used in a TI Process.

Regards

Paul

Paul Simon

Success Cubed Ltd

Tel: +44 7941 506 197

www.successcubed.co.uk

Skype Name: paulsimongb

Skype Tel: +44 20 3287 4616

Hi Hubert

Having to use a WHILE loop to iterate is not too bad. A FOR loop might be nicer or even a FOR EACH, but it can be done with a WHILE. I spend half my time these days programming in JavaScript and sometimes too many options is not a good thing. I accept that TI is a scripting language not a full programming language so I lower my expectations. The only feature I really miss is the ability to call a function and get a return value. Other than that TI has the basics of any programming language sequence, selection and iteration.

I don't think IBM have made it any harder to iterate over dimensions. I have been doing this for years to iterate over elements in Dimensions, and Dimension Subsets, components of consolidations, parents or elements, etc.

However, at present iterating over the Hierarchies within a Dimension is impossible in native TI. You have to build work around cubes and dimensions to do it.

You can ignore the Hierarchy() function. As a bare minimum I would just need:

HierarchyCount() to return the number of hierarchies in the dimension. The documentation would need to specify whether this included the Classic Default Hierarchy and / or the Leaf Hierarchy.

HierarchyN() to return the Name of the Hierarchy of the given dimension at the given Nth position.

Please have a word with someone at IBM about versioning. When we log a support call we actually have to wait for instructions on how to tell them what version we are on, and it generally involves delving into the file system and sending over a bunch of files. What is so difficult about having one number for TM1 and one for PAW/PAX/TM1 Web? IBM needs to learn to become a more customer centric company.

Regards

Paul Simon

Hi Hubert

Many thanks for your reply.

One thing that I find very confusing about IBM with Planning Analytics is its version numbering. We have 2.0.5 in production but you are talking about 11.8. To a certain extent 11.8 makes more sense in terms of the logical progression of TM1 version numbers. I have been using TM1 since version 6. However, for some reason when IBM changed the name to Planning Analytics they decided to revert to version 2.0.0.

Actually identifying what version number you are on, is actually very difficult, particularly when IBM have two version numbering systems for the core server, and another version numbering scheme for PAW and PAX.

Can I make a plea that IBM sticks to one version numbering system.

How do I actually find out what version number in the 11 series I am actually on? Is it by looking at the version number on the tm1sd.exe reliable?

On a server with version number 2.0.8 installed this is showing 11.6. Therefore it is presumably 2.0.9.3 or something like that which is version 11.8? If it was just a matter of swapping the 2 for an 11 it would be easier but the minor version numbering is not even in step.

If I go to download PA the version numbering still shows 2.0.9.3, you have to click a couple of times into the detail to find that it contains TM1 Server version 11.8.2. However, with PAW and PAX now being on different release schedules to the server, what actually is in a Planning Analytics version apart the server? Can IBM please revert to and standardise on 11 series numbering for the server. If PAW and PAX are numbered differently that is fine, since they potentially have a different update cycle to the server.

Anyway good to know that the issue with TI handling Text from MDX Views is fixed as at present the work around of looping round attributes is considerably slowing down dimension updates.

I don't understand what "not in the last place due to a case raised by Hallbjorn" means? Is this a code word for a new version or another customer?

You asked for a use case for Hierarchy Functions in TI as opposed to rules. There are numerous cases where I have functions that loop over all hierarchies in a dimension. If I could use these hierarchy functions in TI then this would be possible, but without them, the only way of doing this is to maintain my own cubes of the hierarchies in each dimension. I have built a dimension where there are consolidations for each dimension expanding to leaf level elements of the dimension:hierarchy combinations in the dimension to allow me to do this. I use this in a cube to hold information on the hierarchy such as its top level element, the name of its base level, etc. However, not everyone wants to build their own cubes for this.

One example is the difficulty of deleting an element. In general, it must be deleted from the classic default hierarchy, one or more Named Hierarchies, and possibly also the leaf hierarchy. Unless you delete it from all cases, it is likely to work its way back in at the next dimension update. If you can write a TI that loops around all named hierarchies in a dimension, then this is relatively easy, but this ability is not currently supported by native TI functions.

If the hierarchy functions where available in TI instead of just rules I could write a generic TI process that takes a parameter of the Dim and Element to be deleted from all hierarchies.

IF( Dimix( vDim , vElem ) > 0 ) ;

  DimensionElementDelete( vDim , vElem ) ;

ENDIF ;

# Also delete from all Named Hierarchies, if the dimension has Named Hierarchies

IF( Hierarchy( vDim ) = 1 ) ;

  vNumHiers = HierarchyCount( vDim ) ;

  vHierNum = 0 ;

  WHILE( vHierNum < vNumHiers ) ;

    vHierNum = vHierNum + 1 ;

    vHier = HierarchyN( vDim, vHierNum ) ;

    IF( HierarchyElementExists( vDim , vHIer, vElem ) = 1 ) ;

      HierarchyElementDelete( vDim , vHier , vElem ) ;

    ENDIF ;

   END ;

ENDIF ;

And at some point HierarchyIndex could be of use.

Another example is that we have a set of standard subsets that we want to create for each hierarchy. If we want to add another subset to this standard we need a way to loop around all dimensions and all hierarchies within those dimensions. At present we create subsets for base level elements, consolidations, full hierarchy and a default subset being the top level element. In }ElementAttributes cubes, we also want to be able to create a default view for each hierarchy, which again requires the ability to loop for each hierarchy in a dimension.

So I think that these functions do have a context in a TI process.

The new Named Hierarchies do add a lot of functionality to TM1, and they are definitely a good thing. However, like anything new it is difficult to think of every possible ramification in advance.

Regards

Paul Simon

Hi Hubert

Thanks for the reply.

We are currently evaluating 2.0.9 but other work has delayed progress on that. The Finance Dept decided they would rather have a Non Trial Balance collection system which a colleague has built, and a chart of accounts change request system which I have built. This uses a JavaScript Framework (Vue & Node) front end, a SQL Server backend, and various TI processes to update the PA 2.0.5 dimensions.

Finance Depts are risk adverse. At present we are using 2.0.5 in pretty much the same way that we used TM1. We are still using TM1 Web in Production. TM1 Web is important for us as many users are in partner organisations outside of our network.

We are not using PAW. Until it is possible to synchronise selections with TI buttons, we can't use PAW.

We are not using PAX, although we are getting close to resolving some of the SSL certificate issues, and hope to be using it soon. At present only developers can use it.

I have built the Chart of Accounts system to support Named Hierarchies. However, we cannot simply change several years of development or retrain 300 users who are used to TM1 Web. At present, until issues with PAW are fixed there is not, in any case, a viable alternative. Therefore all the TI that I have written to build dimensions from the SQL database that holds the Chart of Accounts information, all replicate the structure of each Named Hierarchy, as an alternate hierarchy in the default hierarchy. I have stuck to the standard that alternate hierarchies only exist in the default hierarchy, and any Named Hierarchy only has a single hierarchy. However, we do need to generate some alternate hierarchies to support existing development and systems.

When you say

"I wouldn't expect users that are starting to use alternate hierarchies to mix the old, deprecated, Dimension functions with the new Hierarchy based functions"

I think that the reality is that there will be continued use of both functions, because a lot of people will need to update existing dimensions that are accessed by tools that don't support named hierarchies.

There are some areas where there is not an equivalent hierarchy function. When writing in attribute values if I want to check whether the cell is updateable or if a rule applies to it, I need to use CellIsUpdateable on the Element Attributes Cube, and specify Hierarchy colon Element , then the Attribute, as there is no equivalent of this function with a hierarchy parameter.

Reading from attribute cubes with named hierarchies is a problem, as you can only do this using an MDX View, and TI does not read text from MDX Views correctly. I reported this bug a year or so ago and as far as I know it has still not been resolved.

I may be wrong but I cannot see that many people converting from TI to using the Rest API. I would guess that the majority of all TM1 developers come from an Accountancy rather than IT background. I would guess that they will struggle to get to grips with the Rest API. I am from an IT background and the design of the Rest API is very computer science oriented. It is probably more of a tool for partners than end-users. I also suspect that there will also be cases where TI runs faster than eg Python or JavaScript calling the RestAPI simply because it runs in process.

If you look at the TM1 Reference guide on the IBM Knowledge centre, which should reflect the latest version, and then look at the Hierarchy Rules Functions, which contain things that would be useful in TI to allow a process to loop around all hierarchies in a dimension, all of them say "cannot be used in TurboIntegrator processes. The presence of this function in a process will prevent the process from compiling. ".

Pretty much any other Rules Function can be used in a TI Process.

Regards

Paul

Paul Simon

Success Cubed Ltd

Tel: +44 7941 506 197

www.successcubed.co.uk

Skype Name: paulsimongb

Skype Tel: +44 20 3287 4616

Hi Steve

The problem is that IBM have said that all these extra curly bracket dimensions that they have put in for hierarchies, subsets, views, etc, might not all be staying, so I have deliberately not used any of them.

Regards

Paul Simon

Hi Hubert

Having to use a WHILE loop to iterate is not too bad. A FOR loop might be nicer or even a FOR EACH, but it can be done with a WHILE. I spend half my time these days programming in JavaScript and sometimes too many options is not a good thing. I accept that TI is a scripting language not a full programming language so I lower my expectations. The only feature I really miss is the ability to call a function and get a return value. Other than that TI has the basics of any programming language sequence, selection and iteration.

I don't think IBM have made it any harder to iterate over dimensions. I have been doing this for years to iterate over elements in Dimensions, and Dimension Subsets, components of consolidations, parents or elements, etc.

However, at present iterating over the Hierarchies within a Dimension is impossible in native TI. You have to build work around cubes and dimensions to do it.

You can ignore the Hierarchy() function. As a bare minimum I would just need:

HierarchyCount() to return the number of hierarchies in the dimension. The documentation would need to specify whether this included the Classic Default Hierarchy and / or the Leaf Hierarchy.

HierarchyN() to return the Name of the Hierarchy of the given dimension at the given Nth position.

Please have a word with someone at IBM about versioning. When we log a support call we actually have to wait for instructions on how to tell them what version we are on, and it generally involves delving into the file system and sending over a bunch of files. What is so difficult about having one number for TM1 and one for PAW/PAX/TM1 Web? IBM needs to learn to become a more customer centric company.

Regards

Paul Simon

Hi Hubert

Many thanks for your reply.

One thing that I find very confusing about IBM with Planning Analytics is its version numbering. We have 2.0.5 in production but you are talking about 11.8. To a certain extent 11.8 makes more sense in terms of the logical progression of TM1 version numbers. I have been using TM1 since version 6. However, for some reason when IBM changed the name to Planning Analytics they decided to revert to version 2.0.0.

Actually identifying what version number you are on, is actually very difficult, particularly when IBM have two version numbering systems for the core server, and another version numbering scheme for PAW and PAX.

Can I make a plea that IBM sticks to one version numbering system.

How do I actually find out what version number in the 11 series I am actually on? Is it by looking at the version number on the tm1sd.exe reliable?

On a server with version number 2.0.8 installed this is showing 11.6. Therefore it is presumably 2.0.9.3 or something like that which is version 11.8? If it was just a matter of swapping the 2 for an 11 it would be easier but the minor version numbering is not even in step.

If I go to download PA the version numbering still shows 2.0.9.3, you have to click a couple of times into the detail to find that it contains TM1 Server version 11.8.2. However, with PAW and PAX now being on different release schedules to the server, what actually is in a Planning Analytics version apart the server? Can IBM please revert to and standardise on 11 series numbering for the server. If PAW and PAX are numbered differently that is fine, since they potentially have a different update cycle to the server.

Anyway good to know that the issue with TI handling Text from MDX Views is fixed as at present the work around of looping round attributes is considerably slowing down dimension updates.

I don't understand what "not in the last place due to a case raised by Hallbjorn" means? Is this a code word for a new version or another customer?

You asked for a use case for Hierarchy Functions in TI as opposed to rules. There are numerous cases where I have functions that loop over all hierarchies in a dimension. If I could use these hierarchy functions in TI then this would be possible, but without them, the only way of doing this is to maintain my own cubes of the hierarchies in each dimension. I have built a dimension where there are consolidations for each dimension expanding to leaf level elements of the dimension:hierarchy combinations in the dimension to allow me to do this. I use this in a cube to hold information on the hierarchy such as its top level element, the name of its base level, etc. However, not everyone wants to build their own cubes for this.

One example is the difficulty of deleting an element. In general, it must be deleted from the classic default hierarchy, one or more Named Hierarchies, and possibly also the leaf hierarchy. Unless you delete it from all cases, it is likely to work its way back in at the next dimension update. If you can write a TI that loops around all named hierarchies in a dimension, then this is relatively easy, but this ability is not currently supported by native TI functions.

If the hierarchy functions where available in TI instead of just rules I could write a generic TI process that takes a parameter of the Dim and Element to be deleted from all hierarchies.

IF( Dimix( vDim , vElem ) > 0 ) ;

  DimensionElementDelete( vDim , vElem ) ;

ENDIF ;

# Also delete from all Named Hierarchies, if the dimension has Named Hierarchies

IF( Hierarchy( vDim ) = 1 ) ;

  vNumHiers = HierarchyCount( vDim ) ;

  vHierNum = 0 ;

  WHILE( vHierNum < vNumHiers ) ;

    vHierNum = vHierNum + 1 ;

    vHier = HierarchyN( vDim, vHierNum ) ;

    IF( HierarchyElementExists( vDim , vHIer, vElem ) = 1 ) ;

      HierarchyElementDelete( vDim , vHier , vElem ) ;

    ENDIF ;

   END ;

ENDIF ;

And at some point HierarchyIndex could be of use.

Another example is that we have a set of standard subsets that we want to create for each hierarchy. If we want to add another subset to this standard we need a way to loop around all dimensions and all hierarchies within those dimensions. At present we create subsets for base level elements, consolidations, full hierarchy and a default subset being the top level element. In }ElementAttributes cubes, we also want to be able to create a default view for each hierarchy, which again requires the ability to loop for each hierarchy in a dimension.

So I think that these functions do have a context in a TI process.

The new Named Hierarchies do add a lot of functionality to TM1, and they are definitely a good thing. However, like anything new it is difficult to think of every possible ramification in advance.

Regards

Paul Simon

Hi Hubert

Thanks for the reply.

We are currently evaluating 2.0.9 but other work has delayed progress on that. The Finance Dept decided they would rather have a Non Trial Balance collection system which a colleague has built, and a chart of accounts change request system which I have built. This uses a JavaScript Framework (Vue & Node) front end, a SQL Server backend, and various TI processes to update the PA 2.0.5 dimensions.

Finance Depts are risk adverse. At present we are using 2.0.5 in pretty much the same way that we used TM1. We are still using TM1 Web in Production. TM1 Web is important for us as many users are in partner organisations outside of our network.

We are not using PAW. Until it is possible to synchronise selections with TI buttons, we can't use PAW.

We are not using PAX, although we are getting close to resolving some of the SSL certificate issues, and hope to be using it soon. At present only developers can use it.

I have built the Chart of Accounts system to support Named Hierarchies. However, we cannot simply change several years of development or retrain 300 users who are used to TM1 Web. At present, until issues with PAW are fixed there is not, in any case, a viable alternative. Therefore all the TI that I have written to build dimensions from the SQL database that holds the Chart of Accounts information, all replicate the structure of each Named Hierarchy, as an alternate hierarchy in the default hierarchy. I have stuck to the standard that alternate hierarchies only exist in the default hierarchy, and any Named Hierarchy only has a single hierarchy. However, we do need to generate some alternate hierarchies to support existing development and systems.

When you say

"I wouldn't expect users that are starting to use alternate hierarchies to mix the old, deprecated, Dimension functions with the new Hierarchy based functions"

I think that the reality is that there will be continued use of both functions, because a lot of people will need to update existing dimensions that are accessed by tools that don't support named hierarchies.

There are some areas where there is not an equivalent hierarchy function. When writing in attribute values if I want to check whether the cell is updateable or if a rule applies to it, I need to use CellIsUpdateable on the Element Attributes Cube, and specify Hierarchy colon Element , then the Attribute, as there is no equivalent of this function with a hierarchy parameter.

Reading from attribute cubes with named hierarchies is a problem, as you can only do this using an MDX View, and TI does not read text from MDX Views correctly. I reported this bug a year or so ago and as far as I know it has still not been resolved.

I may be wrong but I cannot see that many people converting from TI to using the Rest API. I would guess that the majority of all TM1 developers come from an Accountancy rather than IT background. I would guess that they will struggle to get to grips with the Rest API. I am from an IT background and the design of the Rest API is very computer science oriented. It is probably more of a tool for partners than end-users. I also suspect that there will also be cases where TI runs faster than eg Python or JavaScript calling the RestAPI simply because it runs in process.

If you look at the TM1 Reference guide on the IBM Knowledge centre, which should reflect the latest version, and then look at the Hierarchy Rules Functions, which contain things that would be useful in TI to allow a process to loop around all hierarchies in a dimension, all of them say "cannot be used in TurboIntegrator processes. The presence of this function in a process will prevent the process from compiling. ".

Pretty much any other Rules Function can be used in a TI Process.

Regards

Paul

Paul Simon

Success Cubed Ltd

Tel: +44 7941 506 197

www.successcubed.co.uk

Skype Name: paulsimongb

Skype Tel: +44 20 3287 4616

Hi Steve

The problem is that IBM have said that all these extra curly bracket dimensions that they have put in for hierarchies, subsets, views, etc, might not all be staying, so I have deliberately not used any of them.

Regards

Paul Simon

Hi Hubert

Having to use a WHILE loop to iterate is not too bad. A FOR loop might be nicer or even a FOR EACH, but it can be done with a WHILE. I spend half my time these days programming in JavaScript and sometimes too many options is not a good thing. I accept that TI is a scripting language not a full programming language so I lower my expectations. The only feature I really miss is the ability to call a function and get a return value. Other than that TI has the basics of any programming language sequence, selection and iteration.

I don't think IBM have made it any harder to iterate over dimensions. I have been doing this for years to iterate over elements in Dimensions, and Dimension Subsets, components of consolidations, parents or elements, etc.

However, at present iterating over the Hierarchies within a Dimension is impossible in native TI. You have to build work around cubes and dimensions to do it.

You can ignore the Hierarchy() function. As a bare minimum I would just need:

HierarchyCount() to return the number of hierarchies in the dimension. The documentation would need to specify whether this included the Classic Default Hierarchy and / or the Leaf Hierarchy.

HierarchyN() to return the Name of the Hierarchy of the given dimension at the given Nth position.

Please have a word with someone at IBM about versioning. When we log a support call we actually have to wait for instructions on how to tell them what version we are on, and it generally involves delving into the file system and sending over a bunch of files. What is so difficult about having one number for TM1 and one for PAW/PAX/TM1 Web? IBM needs to learn to become a more customer centric company.

Regards

Paul Simon

Hi Hubert

Many thanks for your reply.

One thing that I find very confusing about IBM with Planning Analytics is its version numbering. We have 2.0.5 in production but you are talking about 11.8. To a certain extent 11.8 makes more sense in terms of the logical progression of TM1 version numbers. I have been using TM1 since version 6. However, for some reason when IBM changed the name to Planning Analytics they decided to revert to version 2.0.0.

Actually identifying what version number you are on, is actually very difficult, particularly when IBM have two version numbering systems for the core server, and another version numbering scheme for PAW and PAX.

Can I make a plea that IBM sticks to one version numbering system.

How do I actually find out what version number in the 11 series I am actually on? Is it by looking at the version number on the tm1sd.exe reliable?

On a server with version number 2.0.8 installed this is showing 11.6. Therefore it is presumably 2.0.9.3 or something like that which is version 11.8? If it was just a matter of swapping the 2 for an 11 it would be easier but the minor version numbering is not even in step.

If I go to download PA the version numbering still shows 2.0.9.3, you have to click a couple of times into the detail to find that it contains TM1 Server version 11.8.2. However, with PAW and PAX now being on different release schedules to the server, what actually is in a Planning Analytics version apart the server? Can IBM please revert to and standardise on 11 series numbering for the server. If PAW and PAX are numbered differently that is fine, since they potentially have a different update cycle to the server.

Anyway good to know that the issue with TI handling Text from MDX Views is fixed as at present the work around of looping round attributes is considerably slowing down dimension updates.

I don't understand what "not in the last place due to a case raised by Hallbjorn" means? Is this a code word for a new version or another customer?

You asked for a use case for Hierarchy Functions in TI as opposed to rules. There are numerous cases where I have functions that loop over all hierarchies in a dimension. If I could use these hierarchy functions in TI then this would be possible, but without them, the only way of doing this is to maintain my own cubes of the hierarchies in each dimension. I have built a dimension where there are consolidations for each dimension expanding to leaf level elements of the dimension:hierarchy combinations in the dimension to allow me to do this. I use this in a cube to hold information on the hierarchy such as its top level element, the name of its base level, etc. However, not everyone wants to build their own cubes for this.

One example is the difficulty of deleting an element. In general, it must be deleted from the classic default hierarchy, one or more Named Hierarchies, and possibly also the leaf hierarchy. Unless you delete it from all cases, it is likely to work its way back in at the next dimension update. If you can write a TI that loops around all named hierarchies in a dimension, then this is relatively easy, but this ability is not currently supported by native TI functions.

If the hierarchy functions where available in TI instead of just rules I could write a generic TI process that takes a parameter of the Dim and Element to be deleted from all hierarchies.

IF( Dimix( vDim , vElem ) > 0 ) ;

  DimensionElementDelete( vDim , vElem ) ;

ENDIF ;

# Also delete from all Named Hierarchies, if the dimension has Named Hierarchies

IF( Hierarchy( vDim ) = 1 ) ;

  vNumHiers = HierarchyCount( vDim ) ;

  vHierNum = 0 ;

  WHILE( vHierNum < vNumHiers ) ;

    vHierNum = vHierNum + 1 ;

    vHier = HierarchyN( vDim, vHierNum ) ;

    IF( HierarchyElementExists( vDim , vHIer, vElem ) = 1 ) ;

      HierarchyElementDelete( vDim , vHier , vElem ) ;

    ENDIF ;

   END ;

ENDIF ;

And at some point HierarchyIndex could be of use.

Another example is that we have a set of standard subsets that we want to create for each hierarchy. If we want to add another subset to this standard we need a way to loop around all dimensions and all hierarchies within those dimensions. At present we create subsets for base level elements, consolidations, full hierarchy and a default subset being the top level element. In }ElementAttributes cubes, we also want to be able to create a default view for each hierarchy, which again requires the ability to loop for each hierarchy in a dimension.

So I think that these functions do have a context in a TI process.

The new Named Hierarchies do add a lot of functionality to TM1, and they are definitely a good thing. However, like anything new it is difficult to think of every possible ramification in advance.

Regards

Paul Simon

Hi Hubert

Thanks for the reply.

We are currently evaluating 2.0.9 but other work has delayed progress on that. The Finance Dept decided they would rather have a Non Trial Balance collection system which a colleague has built, and a chart of accounts change request system which I have built. This uses a JavaScript Framework (Vue & Node) front end, a SQL Server backend, and various TI processes to update the PA 2.0.5 dimensions.

Finance Depts are risk adverse. At present we are using 2.0.5 in pretty much the same way that we used TM1. We are still using TM1 Web in Production. TM1 Web is important for us as many users are in partner organisations outside of our network.

We are not using PAW. Until it is possible to synchronise selections with TI buttons, we can't use PAW.

We are not using PAX, although we are getting close to resolving some of the SSL certificate issues, and hope to be using it soon. At present only developers can use it.

I have built the Chart of Accounts system to support Named Hierarchies. However, we cannot simply change several years of development or retrain 300 users who are used to TM1 Web. At present, until issues with PAW are fixed there is not, in any case, a viable alternative. Therefore all the TI that I have written to build dimensions from the SQL database that holds the Chart of Accounts information, all replicate the structure of each Named Hierarchy, as an alternate hierarchy in the default hierarchy. I have stuck to the standard that alternate hierarchies only exist in the default hierarchy, and any Named Hierarchy only has a single hierarchy. However, we do need to generate some alternate hierarchies to support existing development and systems.

When you say

"I wouldn't expect users that are starting to use alternate hierarchies to mix the old, deprecated, Dimension functions with the new Hierarchy based functions"

I think that the reality is that there will be continued use of both functions, because a lot of people will need to update existing dimensions that are accessed by tools that don't support named hierarchies.

There are some areas where there is not an equivalent hierarchy function. When writing in attribute values if I want to check whether the cell is updateable or if a rule applies to it, I need to use CellIsUpdateable on the Element Attributes Cube, and specify Hierarchy colon Element , then the Attribute, as there is no equivalent of this function with a hierarchy parameter.

Reading from attribute cubes with named hierarchies is a problem, as you can only do this using an MDX View, and TI does not read text from MDX Views correctly. I reported this bug a year or so ago and as far as I know it has still not been resolved.

I may be wrong but I cannot see that many people converting from TI to using the Rest API. I would guess that the majority of all TM1 developers come from an Accountancy rather than IT background. I would guess that they will struggle to get to grips with the Rest API. I am from an IT background and the design of the Rest API is very computer science oriented. It is probably more of a tool for partners than end-users. I also suspect that there will also be cases where TI runs faster than eg Python or JavaScript calling the RestAPI simply because it runs in process.

If you look at the TM1 Reference guide on the IBM Knowledge centre, which should reflect the latest version, and then look at the Hierarchy Rules Functions, which contain things that would be useful in TI to allow a process to loop around all hierarchies in a dimension, all of them say "cannot be used in TurboIntegrator processes. The presence of this function in a process will prevent the process from compiling. ".

Pretty much any other Rules Function can be used in a TI Process.

Regards

Paul

Paul Simon

Success Cubed Ltd

Tel: +44 7941 506 197

www.successcubed.co.uk

Skype Name: paulsimongb

Skype Tel: +44 20 3287 4616

Hi Steve

The problem is that IBM have said that all these extra curly bracket dimensions that they have put in for hierarchies, subsets, views, etc, might not all be staying, so I have deliberately not used any of them.

Regards

Paul Simon

Hi Hubert

Having to use a WHILE loop to iterate is not too bad. A FOR loop might be nicer or even a FOR EACH, but it can be done with a WHILE. I spend half my time these days programming in JavaScript and sometimes too many options is not a good thing. I accept that TI is a scripting language not a full programming language so I lower my expectations. The only feature I really miss is the ability to call a function and get a return value. Other than that TI has the basics of any programming language sequence, selection and iteration.

I don't think IBM have made it any harder to iterate over dimensions. I have been doing this for years to iterate over elements in Dimensions, and Dimension Subsets, components of consolidations, parents or elements, etc.

However, at present iterating over the Hierarchies within a Dimension is impossible in native TI. You have to build work around cubes and dimensions to do it.

You can ignore the Hierarchy() function. As a bare minimum I would just need:

HierarchyCount() to return the number of hierarchies in the dimension. The documentation would need to specify whether this included the Classic Default Hierarchy and / or the Leaf Hierarchy.

HierarchyN() to return the Name of the Hierarchy of the given dimension at the given Nth position.

Please have a word with someone at IBM about versioning. When we log a support call we actually have to wait for instructions on how to tell them what version we are on, and it generally involves delving into the file system and sending over a bunch of files. What is so difficult about having one number for TM1 and one for PAW/PAX/TM1 Web? IBM needs to learn to become a more customer centric company.

Regards

Paul Simon

Hi Hubert

Many thanks for your reply.

One thing that I find very confusing about IBM with Planning Analytics is its version numbering. We have 2.0.5 in production but you are talking about 11.8. To a certain extent 11.8 makes more sense in terms of the logical progression of TM1 version numbers. I have been using TM1 since version 6. However, for some reason when IBM changed the name to Planning Analytics they decided to revert to version 2.0.0.

Actually identifying what version number you are on, is actually very difficult, particularly when IBM have two version numbering systems for the core server, and another version numbering scheme for PAW and PAX.

Can I make a plea that IBM sticks to one version numbering system.

How do I actually find out what version number in the 11 series I am actually on? Is it by looking at the version number on the tm1sd.exe reliable?

On a server with version number 2.0.8 installed this is showing 11.6. Therefore it is presumably 2.0.9.3 or something like that which is version 11.8? If it was just a matter of swapping the 2 for an 11 it would be easier but the minor version numbering is not even in step.

If I go to download PA the version numbering still shows 2.0.9.3, you have to click a couple of times into the detail to find that it contains TM1 Server version 11.8.2. However, with PAW and PAX now being on different release schedules to the server, what actually is in a Planning Analytics version apart the server? Can IBM please revert to and standardise on 11 series numbering for the server. If PAW and PAX are numbered differently that is fine, since they potentially have a different update cycle to the server.

Anyway good to know that the issue with TI handling Text from MDX Views is fixed as at present the work around of looping round attributes is considerably slowing down dimension updates.

I don't understand what "not in the last place due to a case raised by Hallbjorn" means? Is this a code word for a new version or another customer?

You asked for a use case for Hierarchy Functions in TI as opposed to rules. There are numerous cases where I have functions that loop over all hierarchies in a dimension. If I could use these hierarchy functions in TI then this would be possible, but without them, the only way of doing this is to maintain my own cubes of the hierarchies in each dimension. I have built a dimension where there are consolidations for each dimension expanding to leaf level elements of the dimension:hierarchy combinations in the dimension to allow me to do this. I use this in a cube to hold information on the hierarchy such as its top level element, the name of its base level, etc. However, not everyone wants to build their own cubes for this.

One example is the difficulty of deleting an element. In general, it must be deleted from the classic default hierarchy, one or more Named Hierarchies, and possibly also the leaf hierarchy. Unless you delete it from all cases, it is likely to work its way back in at the next dimension update. If you can write a TI that loops around all named hierarchies in a dimension, then this is relatively easy, but this ability is not currently supported by native TI functions.

If the hierarchy functions where available in TI instead of just rules I could write a generic TI process that takes a parameter of the Dim and Element to be deleted from all hierarchies.

IF( Dimix( vDim , vElem ) > 0 ) ;

  DimensionElementDelete( vDim , vElem ) ;

ENDIF ;

# Also delete from all Named Hierarchies, if the dimension has Named Hierarchies

IF( Hierarchy( vDim ) = 1 ) ;

  vNumHiers = HierarchyCount( vDim ) ;

  vHierNum = 0 ;

  WHILE( vHierNum < vNumHiers ) ;

    vHierNum = vHierNum + 1 ;

    vHier = HierarchyN( vDim, vHierNum ) ;

    IF( HierarchyElementExists( vDim , vHIer, vElem ) = 1 ) ;

      HierarchyElementDelete( vDim , vHier , vElem ) ;

    ENDIF ;

   END ;

ENDIF ;

And at some point HierarchyIndex could be of use.

Another example is that we have a set of standard subsets that we want to create for each hierarchy. If we want to add another subset to this standard we need a way to loop around all dimensions and all hierarchies within those dimensions. At present we create subsets for base level elements, consolidations, full hierarchy and a default subset being the top level element. In }ElementAttributes cubes, we also want to be able to create a default view for each hierarchy, which again requires the ability to loop for each hierarchy in a dimension.

So I think that these functions do have a context in a TI process.

The new Named Hierarchies do add a lot of functionality to TM1, and they are definitely a good thing. However, like anything new it is difficult to think of every possible ramification in advance.

Regards

Paul Simon

Hi Hubert

Thanks for the reply.

We are currently evaluating 2.0.9 but other work has delayed progress on that. The Finance Dept decided they would rather have a Non Trial Balance collection system which a colleague has built, and a chart of accounts change request system which I have built. This uses a JavaScript Framework (Vue & Node) front end, a SQL Server backend, and various TI processes to update the PA 2.0.5 dimensions.

Finance Depts are risk adverse. At present we are using 2.0.5 in pretty much the same way that we used TM1. We are still using TM1 Web in Production. TM1 Web is important for us as many users are in partner organisations outside of our network.

We are not using PAW. Until it is possible to synchronise selections with TI buttons, we can't use PAW.

We are not using PAX, although we are getting close to resolving some of the SSL certificate issues, and hope to be using it soon. At present only developers can use it.

I have built the Chart of Accounts system to support Named Hierarchies. However, we cannot simply change several years of development or retrain 300 users who are used to TM1 Web. At present, until issues with PAW are fixed there is not, in any case, a viable alternative. Therefore all the TI that I have written to build dimensions from the SQL database that holds the Chart of Accounts information, all replicate the structure of each Named Hierarchy, as an alternate hierarchy in the default hierarchy. I have stuck to the standard that alternate hierarchies only exist in the default hierarchy, and any Named Hierarchy only has a single hierarchy. However, we do need to generate some alternate hierarchies to support existing development and systems.

When you say

"I wouldn't expect users that are starting to use alternate hierarchies to mix the old, deprecated, Dimension functions with the new Hierarchy based functions"

I think that the reality is that there will be continued use of both functions, because a lot of people will need to update existing dimensions that are accessed by tools that don't support named hierarchies.

There are some areas where there is not an equivalent hierarchy function. When writing in attribute values if I want to check whether the cell is updateable or if a rule applies to it, I need to use CellIsUpdateable on the Element Attributes Cube, and specify Hierarchy colon Element , then the Attribute, as there is no equivalent of this function with a hierarchy parameter.

Reading from attribute cubes with named hierarchies is a problem, as you can only do this using an MDX View, and TI does not read text from MDX Views correctly. I reported this bug a year or so ago and as far as I know it has still not been resolved.

I may be wrong but I cannot see that many people converting from TI to using the Rest API. I would guess that the majority of all TM1 developers come from an Accountancy rather than IT background. I would guess that they will struggle to get to grips with the Rest API. I am from an IT background and the design of the Rest API is very computer science oriented. It is probably more of a tool for partners than end-users. I also suspect that there will also be cases where TI runs faster than eg Python or JavaScript calling the RestAPI simply because it runs in process.

If you look at the TM1 Reference guide on the IBM Knowledge centre, which should reflect the latest version, and then look at the Hierarchy Rules Functions, which contain things that would be useful in TI to allow a process to loop around all hierarchies in a dimension, all of them say "cannot be used in TurboIntegrator processes. The presence of this function in a process will prevent the process from compiling. ".

Pretty much any other Rules Function can be used in a TI Process.

Regards

Paul

Paul Simon

Success Cubed Ltd

Tel: +44 7941 506 197

www.successcubed.co.uk

Skype Name: paulsimongb

Skype Tel: +44 20 3287 4616