Cube view - Dynamic viewName with settings service

[Wei Wang]

We are trying to expose some more adhoc views to users in the form of the Apliqo cube viewer and want to set the initial views in a dynamic manner (i.e., based on user filter selection). Even though the settings service variables can be used to set both the “instance” and “cube” in Adv Options, we notice that the $<<>> variables doesn’t work in “viewName”. It would be great to have the “viewName” parameter also work with the settings service. Thanks!

‌

[Scott Wiltshire]

Just to clarrify what you want to achieve here.

1. viewName should also accept setting service variables
2. to pass a view name dynamically you would presumable want to pass a nested variable e.g.

“instance”: “$<<contentStore.}APQ UX Instance.}APQ UX Instance>>”,
“cube”: “$<<$<<contentStore.}APQ UX Instance.}APQ UX Instance>>.}Cubes.}Cubes>>”,
“viewName”: “$<<$<<contentStore.}APQ UX Instance.}APQ UX Instance>>.}Views_$<<$<<contentStore.}APQ UX Instance.}APQ UX Instance>>.}Cubes.}Cubes>>.}Views_$<<$<<contentStore.}APQ UX Instance.}APQ UX Instance>>.}Cubes.}Cubes>>>>“

If you don’t mind me saying, technically nesting setting service variables should work but it is getting a bit complicated to understand! If no view name has already been selected then this woudl result in a failure of the MDX upon landing on the page as the variable will be empty.

Another issue would most likelly be that there may be some limitations depending on how flexible you want to make the dashboard. Although dependent filters are supported by Apliqo UX where the selection of one filter can dynamically drive the hierarchy used for other filters, I am fairly certain that this works for only one level of dependency. E.g. instance selection coudl drive cube selection as the hierarchy for the cube selection woudl be defined as “$<<$<<contentStore.}APQ UX Instance.}APQ UX Instance>>.}Cubes.}Cubes>>”. But I believe the view selection filter would fail due to double-hop dependency. However, if you are prepared to accept instance as being hardcoded then the view selection should be no problem to define as dependent on the cube selection. This woudl also make the advanced options config of the cube viewer much more human readible.

“instance”: “UX_Demo”,
“cube”: “$<<UX_Demo.}Cubes.}Cubes>>”,
“viewName”: “$<<UX_Demo.}Views_$<<UX_Demo.}Cubes.}Cubes>>.}Views_$UX_Demo.}Cubes.}Cubes>>>>“