Hi
I am surprised at the number of replies to my aside on the TI Button issue. It wasn't my intention to hijack the original thread. Although possibly if it came to a vote on backing a fix to the Lock element issue for which there is a work around, or a fix to the TI button issue, I would vote for the latter. If an Admin wants to separate this to a different thread please go ahead.
I probably should have said 'or a facility equivalent to the Excel range facility that currently exists in TM1 Web'. I would agree that a more web based alternative would be preferable, and if it was not currently already under investigation, I would be happy to raise an enhancement request for that since it is a genuine enhancement.
I did click the earlier link to new features that Paul Glennon provided but just encountered an error message telling me that I didn't have rights to access that content. It is possibly referring to the latest new features guide?
We haven't as yet got PAW working fully. You can see my post on the independent tm1forum for the reasons why. The upgrade from 10.1.1 to PA 2.0.5 has been the most painful we have ever had to go through and has involved re-writing large sections of the application. There are still some port and certificate issues that need to be resolved. We therefore haven't had much time to experiment with it yet. Can you confirm that a TM1 Web sheet embedded in PAW which has a TI Button that references an Excel range will work? We have tried upgrading some of our existing Perspectives sheets in PAX but have found that the TI Button Converter does not work. We have raised a PMR for that.
We would probably want to move to a web based TI button at some point but we cannot simply abandon our existing apps which have been developed over several years. Therefore we need to be able to transition over gradually. We cannot simply rebuild everything in PAW, particularly as PAW does not yet have the necessary functionality.
The typical use case is that a user selects a Cost Centre, and the grid then displays data related to that Cost Centre, and the user then updates that data and clicks a button to Submit that data for approval. (I have been developing with TM1 for 20 years and I have yet to encounter a case where a customer wants to use the built-in workflow, so this is typically what we build). Having a TI button that only prompts them to select the Cost Centre at the time they click the Submit button won't work. The selection needs to be independent of the TI process.
Certainly using a small cube with dimensions of }Clients and }dimensions to store the last selected element for each user for each dimension and being able to reference that as a parameter in a PAW TI Button would be a partial alternative. I don't believe that is currently possible so I am assuming that Cyrus means that you would need to have a TI process with no parameters and use a CellGetS in the TI process to get the parameter value? If so that does not appeal to me as it is then not clear just by looking at the TI what parameters it will accept. However, I believe that Cyrus was only suggesting that as a stop gap solution.
Our existing TM1 Web sheets already use a similar technique to make a SUBNM function default to the value that the user last selected, but also having the ability to change that value, and pass that value into a TI process.
I would want the result of the Set selection widget to be something that could be referenced in a PAW TI Button, either by the synchronisation feature, or by being able to name them and reference that name.
I would want the ability to optionally set the initial value for the Set selection widget to :
a) The last value that the user selected, even if in a previous session, eg defaulting the selection in a list to the Cost Centre that the user last selected on the basis that many users will only ever work on one Cost Centre.
b) The value from a reference cube, eg most systems have a cube that holds the current period. We would want the period selection to default to that, rather than simply the last period the user selected, as the period would typically be updated in a month end rollover process, and when the user next went in, they would want the default selection to be the new period.
c) No initial value. We typically handle this by adding eg a z_Select Comparison element to the dimension and selecting that as standard.
d) A value from a named Set, so, taking the current period example in (c), it is sometimes better to default the initial period to the current period by referencing a named Set which is updated by the month end rollover process, rather than referencing the value stored in a control cube, since that then makes it easier for the user to select a different period if that is appropriate for them. For example, they might want the sheet to default to the current period but have the ability to select a prior period.
e) A calculated value, typically something like string splicing, or attribute lookup.
The above are just some examples. Other developers probably have additional use cases. Overall my gut feeling is with Ryan. I don't believe that all the possible approaches can be handled by a simple synchronisation model, and the current approach of picking at the time you click the button won't do. There needs to be some sort of programmatic approach. I would certainly not suggest that everyone should have to learn the REST API to use PAW. However, the ability to name widgets and reference them is the approach used in rival tools such as Tableau. They also have macro language similar to that in Cognos Analytics. However, the use case for Tableau is much simpler. It is purely a reporting tool. We should not be trying to emulate that. TM1/PA is typically used for Budgeting, Planning and Forecasting with real time re-consolidation, recalculation and Reporting. This is a much more complex ask. It is not just about running a report and retrieving data. It must be possible to build an application that will lead a user through their month end data contribution tasks and which will manage workflow, review and sign offs, none of which are required in a pure reporting tool like Tableau. I don't think that IBM should concentrate on trying to emulate Tableau with Planning Analytics. They have Cognos Analytics for that. The value proposition for Planning Analytics is quite different.
If the aim is to provide an alternative to Excel, ie one that responds faster and does not limit you to having columns the same width all the way down, then one question I would pose is how it will be possible to generate a pack of Excel workbooks or other offline content for auditors. With our Excel based sheets, we typically automate this using VBA. However, this will not be possible in a Web based PAW book. I am sure that there is basic bursting functionality, but having some sort of programmatic access might be needed in some cases, eg only burst those that have a status of Finalised. VBA is not going to be an option to interface with PAW, and your average accountant is not going to master JavaScript even if PAW did expose an interface for this. Therefore, how can something like that be done?
Having been a bit negative, I would like to say some positive things. IBM have done an excellent job with the core Server components. The new hierarchy approach gives the flexibility of a Data Warehouse to add new splits, and possibly more so, while still retaining the speed of MOLAP. We have converted all existing processes to use Temp Views and Subsets and that has brought about dramatic reductions in locking with consequent improvements in query response times at peak month end periods. Improvements such as Parallel Interaction, and Multi-Threaded Queries have dramatically improved performance, particularly around the ability to update cubes with forecasts and see the results of that in real-time - something that query only reporting tools cannot do. Asymmetric Rows and Columns show a lot of promise. Having made such progress at the back end, they now need to move faster to make the front-end development deliver on that.
Regards
Paul Simon
------------------------------
Paul Simon
------------------------------
Original Message:
Sent: 03-14-2019 01:45 PM
From: Ryan Clapp
Subject: Putting a lock on element in PAW?
Agree totally. There is a lot of power there, that when exposed could make some amazing TM1 UI experiences
------------------------------
Ryan Clapp
Original Message:
Sent: 03-14-2019 01:22 PM
From: PAUL GLENNON
Subject: Putting a lock on element in PAW?
Hi Ryan,
I think I'm largely in agreement with you that the synchronization model has room to grow. It could benefit from listening not just to other selector widgets, but user clicks within widgets. I think the example you've described above is a master-detail synchronization. I can see building a dashboard where users click on a row in one table and it changes the context of another table or chart.
I think we might also want to think about multiple channels for synchronization. Currently a widget is either listening or not. I've seen the requirement for groups of widgets to communicate
So, I think I get the requirement for a more flexible synchronization system. It's just a matter of priorities. Hooking the Button parameters up to synchronization is step one.
Paul
------------------------------
PAUL GLENNON
Original Message:
Sent: 03-14-2019 12:54 PM
From: Ryan Clapp
Subject: Putting a lock on element in PAW?
It is not about API access, I don't want to write complicated code to get PAW to do things. I want PAW to support common TM1 report design patterns (without excel), and was only suggesting a way to do so.
If PAW is primarily a data exploration and modeling platform, then it is doing a good job. If it is a tool to design custom UIs to interact with your TM1 models, it has a long way to go.
When a tool has always prided itself on ultimate flexibility, excel and TM1, adding components that do not maintain that standard can be frustrating for users.
Ryan D Clapp
Sr. Manager
IT Application Dev Eng | AWS Business Systems
rdclapp@amazon.com
O: 206-266-2611
M: 518-821-8367
Original Message------
While I think we all agree that PAW development has been slower than we hoped, I'm sure there are many factors at play. As developers, having a more open and programmatic access to PAW's capabilities would make our lives easier, but IBM also needs to satisfy the average users that don't want to always "customize TM1 with APIs."
We know that TM1Server at its core is a legacy system going through a major transition. From Day 1, it was not originally "born on the Cloud," fully REST-compliant, vanilla MDX, etc., so it takes time for TM1 to be modernized. Staying positive and providing constructive and continuous feedback will ensure a positive outcome for all parties involved.
And we should always remember that, "Ultimate flexibility leads to infinite complexity."
------------------------------
Cyrus Rashedi
------------------------------
#PlanningAnalyticswithWatson