PAW Synchronise Action Button parameters with Sheet Selections

[paulsimon]

Hi

As far as I am aware there is no way to synchronise the parameters to a TI Process on an Action Button with selections made in PAW (short of embedding a Web Sheet which for me anyone defeats the purpose of PAW).

For us this is absolutely critical. Without this, we will not be able to do most of the things that we currently do in TM1 Web, in PAW.

Our users typically make selections on a Web Sheet, review numbers in a table, and then click an Action Button which will carry out various actions, typically validating data, updating Workflow cubes, moving data from one cube to another, building dimensions, etc. The selections that they make on the web sheet are the ones that get passed to the TI process as parameters. There does not appear to be a way to do this in PAW. Users instead get prompted to re-select values for the parameters when they click the Action Button, which would not be acceptable.

I suspect that this is fairly important to a number of other people. If you think it is important too, then please vote for the IBM Idea that we raised using the link below

https://ibm-data-and-ai.ideas.aha.io/id ... itted_idea

If I have misunderstood PAW, or if you have some way around this, other than those ruled out in the request, then please let me know.

Regards

Paul Simon

[declanr]

There are a number of things that you can’t quite do with the synchronisation- such as what you have highlighted and another common one of selecting an element in 1 dimension; such as a Country Code in a country dimension and seeing its corresponding element selected in another dimension e.g all Stores for that Country in the Store dimension.

Or even selecting version x may mean you want version X in most of your views; but 1 or 2 views should be a subset of version X and the equivalent version from last year etc.

As such I tend to not use the selector widgets at all and instead have picklists for selections in a cube containing the }client dim.
Then you have full control with MDX subsets and CellGetS in TIs being used instead of parameters.
It does the job well as a workaround; it would be nice out of the box but I imagine it would be a very big development for the widgets and sync settings to give all of the functionality that we would like.

[ykud]

There are a number of things that you can’t quite do with the synchronisation- such as what you have highlighted and another common one of selecting an element in 1 dimension; such as a Country Code in a country dimension and seeing its corresponding element selected in another dimension e.g all Stores for that Country in the Store dimension.

Or even selecting version x may mean you want version X in most of your views; but 1 or 2 views should be a subset of version X and the equivalent version from last year etc.

As such I tend to not use the selector widgets at all and instead have picklists for selections in a cube containing the }client dim.
Then you have full control with MDX subsets and CellGetS in TIs being used instead of parameters.
It does the job well as a workaround; it would be nice out of the box but I imagine it would be a very big development for the widgets and sync settings to give all of the functionality that we would like.

This is a very interesting idea! So do I understand correctly that you then have to rebuild the 'synchronisation' bit of the selector widgets by making cube views refer to this }clients param dim with MDX subsets (i.e.filter the country list to whatever is in that cube for this user)?

[ykud]

So do I understand correctly that you then have to rebuild the 'synchronisation' bit of the selector widgets by making cube views refer to this }clients param dim with MDX subsets (i.e.filter the country list to whatever is in that cube for this user)?

Yup, just saw the video. I love this approach, but can't help thinking about the MDX-related overhead I'd be bringing in the server (as each of these MDX subsets would have to be reevaluated on the flight, none of them could be cached, etc).
But surely beats the current 'embed the websheets for anything useful' approach, thanks a lot! Now to convince everyone to embark on the MDX journey

[MarenC]

Hi ykud,

what video?

Maren

[PlanningDev]

You can upload a worksheet that has nothing but an action button on it with hidden subnm's. Just synchronize the sheet and minimize the size of the sheet widget to only the width of the button. The sheet subnm's will be the same as your PAW selectors which in my opinion or much better than the TM1Web Subnm Selectors.

As an FYI you can right click the sheet in architect and tell it to not show the subnm's so you don't have to find a way to make them not show in the websheet. They will still be synchronizable however

Assuming you only need the subnm values this is a fairly easy workaround and wouldn't require the overhead of building out the selection cubes with the }ClientDim.

[ykud]

Hi ykud,

what video?

Maren

My bad should've linked from the beginning.
This one: video

[ykud]

You can upload a worksheet that has nothing but an action button on it with hidden subnm's. Just synchronize the sheet and minimize the size of the sheet widget to only the width of the button. The sheet subnm's will be the same as your PAW selectors which in my opinion or much better than the TM1Web Subnm Selectors.

Assuming you only need the subnm values this is a fairly easy workaround and wouldn't require the overhead of building out the selection cubes with the }ClientDim.

This is exactly what we're doing now and as PAW's integration with TM1web is, how do I put it, sub-optimal:
* every websheet on the book opens up a new session in tm1web (and it's by design), so 10 people opening a book with 3 websheets will generate 30 TM1 sessions. Each session requires memory in the server and 'allocated thread', so you end up with 1000s of sessions during the day. We see this on integratedmode 1, maybe CAM is better.
* if tm1web session times out, it's not reprompted on the PAW book, so you can lose the connection to embedded worksheet without user's seeing anything. In the end, you need to sync the timeouts between PAW and tm1web and it means more sessions on the server
* this login and rendering of websheet takes a bit of time, so you can get cube views show data and websheets still 'coming up' that contributes to the 'strange' overall page experience. And yeah, the fonts in websheets and the PaW book & sizes are out of sync all the time, so you end up with visible seams on the page.

[declanr]

So do I understand correctly that you then have to rebuild the 'synchronisation' bit of the selector widgets by making cube views refer to this }clients param dim with MDX subsets (i.e.filter the country list to whatever is in that cube for this user)?

Yup, just saw the video. I love this approach, but can't help thinking about the MDX-related overhead I'd be bringing in the server (as each of these MDX subsets would have to be reevaluated on the flight, none of them could be cached, etc).
But surely beats the current 'embed the websheets for anything useful' approach, thanks a lot! Now to convince everyone to embark on the MDX journey

I've implemented this in a few different models now; a couple of them having multiple applications and user bases. I haven't experienced any negative performance issues on the MDX side - I would say that one of the applications has some very large data sets that are getting evaluated as well.
That being said I do it this way because I enjoy working with MDX and I have a couple of instances where the subsets would be MDX anyway because they are reliant on other data entry from the users.

However the same logic of making your selections in a cube could be applied to static users by having the users execute a TI process; you could pass the parameters using the Workspace TI parameter prompts (which I think are a really nice addition) and then hold them in a cube until the next time they run the process. At the same time the process could create static subsets with the users name forming part of the subsetname.

The views could all then be set up with MDX subsets that just do a simple reference to the executing users static subset. You then only have a small part of it being dynamic with all the real work done in the TI.
This would of course end up with a lot of subsets left hanging around for each user in the application.

With every interface in TM1 since day-dot we have needed to do workarounds to get applications to work nicely and how we want them to. Workspace will be no different - its just different workarounds we have to create/learn. But based on user feedback I have received so far - I am happy to do those workarounds to let users have all the benefits that they enjoy about Workspace.

And this sort of approach is just being used for the standard application that lets the average user do what they need to. When it comes to people who truly adopt the "Analyst" mindset, I just give them a little training and let them go off and do their own thing.
I'm starting to see a lot of things that Analysts are building themselves (charts etc) that I would never have thought of or could ever have known would be beneficial to them - but because that Analyst can just go off and easily create them - I can then incorporate it into the wider application for everyone else to see.