Saving @Selection_Ex() result

Etienne CAUSSE · 2025-04-17T09:59:38+00:00

There was an error rendering this rich post.

Hi all,

We are working on new functionalities for cost allocations, where we will need to store the explicit selection made by the user. This selection can be done on 1, 2 or 3 different trees, containing up to 30 entities each.

I don't want to store the resulting selection at the lowest level of the allocation driver cube, but I want to keep the selection as it was made, independently from any change that might occur in the hierarchies (such as new members).

The simplest way to do this would be to store in a text cube the result of the 'Selection_Ex(Display="Code")' formula, as it shows up in a label.

Unfortunately it seems @selection works but not @selection_ex in dataflows ?

Any ideas ?

Thanks for your inputs,
Etienne

Find more posts tagged with

Dataflow

Procedures

Layout

Selector

Selection

Accepted answers

All comments

Nicolas CHIGROS

For a different use case and a while back, I had the same result as you do when @selection_ex in dataflow: it wasn't working. So I'm not surprise if it's still the cases.

In fact, I don't think @Selection_ex(Display="Code",Entity="Year") work in a layout, even in for a dataview.

Your goal is to store the selection on a set of entities. So that in the even if a member is deleted, moved or create, you still able to view the exact selection that has been applied for the allocation at the time it was run?

If so my only idea at the moment would be to store the selection into temporaries cubes for each of your entities to "save", extract this cubes using a dataview extraction where the entity is in a column and then reloading them while "cheating" on the column separator so you have everything in cell.

That's not pretty and maybe you can do better now with API.

PS: I once used a bluk insert into a DB to do something similar but either way it's quite an involved workaround.

Etienne CAUSSE

Hi Nicolas,

thanks for the suggestion. Indeed I have the API idea in my notes to try, but I don't have the necessary setup to do that yet.

Regarding your idea with temporary cubes, I'm not sure it would work because I would need one cube per entity (means somewhere around 70 I think) and if I export a flag in each cube, I still don't know if the selection was made at the level of that cube or if it was made at a higher or lower level of the hierarchy.

So far I managed to put @Selection in a text cube, and if I change all the entities to have a default display by Code, then my text cube only has codes ; so it's honestly not so bad. Regarding the objective, yes I need to store the exact rule intended by the user, and not its consequences on the result, because the hierarchies and values will move but the rule should not.

My idea downstream is to use the stored rule and to transform it into a WHERE clause to run the allocations in the datawarehouse.

Another idea I had was to ask the user to flag (through a dedicated cube with a meta-entity listing the entities where selection is possible) before asking him to do the selection itself; then using this initial cube to define the rule, but it seems awfully complicated to maintain…

Nicolas CHIGROS

I see

If the diagnotstic_YYYYMMDD_tsv.log so filled with other information than the dataentry and rolling over so clickly with ~700users or if the dataentry_YYYYMMDD.log wasn't missing the screen name, the database name and some other key information, you may have been able to get away by parsing the logs to get the selection.

Etienne CAUSSE

I see your point with the logs, but as you say, it seems a bit risky :)

Nicolas CHIGROS

I had a quick look and even diagnotsticYYYYMMDD_tsv.log is incomplet. Maybe you can change the option but by default, when the line in the log gets too long it gets truncate… Which is even out of you context is less than ideal…