Register now to learn Fabric in free live sessions led by the best Microsoft experts. From Apr 16 to May 9, in English and Spanish.
Hello all !
I am trying to get the aggregation methodology for the measure:
By researching the dataView, I have found at the measure's related dataview.table.column (which is a powerbi.data.ISQExpr) the "func" field which has unique numbers for each type of aggregation :
The problem is , the attribute func is not able to reach from code
it is mentioned as not part of the public API:
So , any help to obtain the mentioned field or another way to get the aggregation of the measure is very welcome !
Thanks in advance !
Solved! Go to Solution.
- how could the aggregation be hacked out of the implicit ones? the only thing we saw that changes, as the selected summarization does, is the "column.expr" field, which isn't reachable from the API...
If you're attempting this, then your assumptions of having to parse the queryName for an implicit measure and extract the aggregation type (probably using a RegEx), or get confirmation from the team around if the func enum is safe to use or not.
I have just tested with a simple explicit measure and this property is not exposed, so would not be a suitable approach for all use cases - using explicit measures is the recommended approach if people do any kind of guided Power BI learning so you cannot guarantee all users will use an implicit measure, unless your use case is very specific and you can control this type of usage within your user base.
- for the explicit ones, isn't the underlying DAX accessible from the "column.queryName" field?
No, and you can verify this really easily. If you add an explicit measure to a data role, the dataView will just show its expression. For example, I have this measure:
$ Sales = SUM(Financials[Sales])
The queryName for this measure is as follows:
As you'll observe, this is essentially a string pointer to table and measure name (and that's all the implicit measure is doing too). This is all that is required for any data-bound features, such as selection, as Power BI will use this queryName expression to reconcile against the data model, so the DAX is not required and therefore not exposed.
From this point, if you need further assistance on this approach, I have a few suggestions. I appreciate that some developers may have a degree of commercial sensitivity around their work so may not be willing to divulge too much detail, but as custom visual development is so open-ended it is hard to provide targeted assistance without more data to go on.
From experience, I think that if you are committed to your approach, then #1 & #2 are where you could focus your attention at present. As previously mentioned, the visuals team do not monitor the forums so you are unlikely to get an official response without contacting them.
Hopefully this provides some possible ways forward for you.
Regards,
Daniel
Proud to be a Super User!
My course: Introduction to Developing Power BI Visuals
On how to ask a technical question, if you really want an answer (courtesy of SQLBI)
If you want an official answer as to why this isn't in the API, or if it could be added, the team don't monitor the forums - they used to but I don't know why they stopped. Either email them at pbicvsupport@microsoft.com, or open an issue in the GitHub repo for any offical support requests.
Proud to be a Super User!
My course: Introduction to Developing Power BI Visuals
On how to ask a technical question, if you really want an answer (courtesy of SQLBI)
Also: note that whilst this might be hackable for implicit measures, if someone provides an explicit measure to your visual, you won't know the aggregation type as the underlying DAX is not exposed to custom visuals.
Proud to be a Super User!
My course: Introduction to Developing Power BI Visuals
On how to ask a technical question, if you really want an answer (courtesy of SQLBI)
thanks a lot for your reply. The distinction between implicit and explicit measures has cleared things up for us. A couple follow-ups:
- how could the aggregation be hacked out of the implicit ones? the only thing we saw that changes, as the selected summarization does, is the "column.expr" field, which isn't reachable from the API...
If you're attempting this, then your assumptions of having to parse the queryName for an implicit measure and extract the aggregation type (probably using a RegEx), or get confirmation from the team around if the func enum is safe to use or not.
I have just tested with a simple explicit measure and this property is not exposed, so would not be a suitable approach for all use cases - using explicit measures is the recommended approach if people do any kind of guided Power BI learning so you cannot guarantee all users will use an implicit measure, unless your use case is very specific and you can control this type of usage within your user base.
- for the explicit ones, isn't the underlying DAX accessible from the "column.queryName" field?
No, and you can verify this really easily. If you add an explicit measure to a data role, the dataView will just show its expression. For example, I have this measure:
$ Sales = SUM(Financials[Sales])
The queryName for this measure is as follows:
As you'll observe, this is essentially a string pointer to table and measure name (and that's all the implicit measure is doing too). This is all that is required for any data-bound features, such as selection, as Power BI will use this queryName expression to reconcile against the data model, so the DAX is not required and therefore not exposed.
From this point, if you need further assistance on this approach, I have a few suggestions. I appreciate that some developers may have a degree of commercial sensitivity around their work so may not be willing to divulge too much detail, but as custom visual development is so open-ended it is hard to provide targeted assistance without more data to go on.
From experience, I think that if you are committed to your approach, then #1 & #2 are where you could focus your attention at present. As previously mentioned, the visuals team do not monitor the forums so you are unlikely to get an official response without contacting them.
Hopefully this provides some possible ways forward for you.
Regards,
Daniel
Proud to be a Super User!
My course: Introduction to Developing Power BI Visuals
On how to ask a technical question, if you really want an answer (courtesy of SQLBI)
Hi @dm-p
I also troubled that things,
because if I use "table"(capabilities.json -> dataviewmappings) I can't get query name...
https://community.powerbi.com/t5/Custom-Visuals-Development/Table-columns-queryName-property-not-upd...
I want to get query name... how can i get query name?
thanks
mariya
You still haven't described what you are doing this for. You don't want to precompute stuff for fun, right? That's what OLAP cubes and (to a lesser extent) calculation groups are for.
What are you planning to do with that information? maybe there is another way of achieving that goal.
Thanks @lbendlin
What we're trying to achieve is to calculate the aggregated value across dimension members, assuming it is not provided by the API (we asked about this possibility in this post). In order to do so, we need to know the aggregation method of the measure (ex.: sum, min, max, avg, etc.) so that we perform the right calculation. Is this aggregation method provided somewhere in the custom visuals API? we think our best shot at getting it is to parse it out of the field "column.queryName", but we'd like to get official confirmation.
Thanks in advance
Covering the world! 9:00-10:30 AM Sydney, 4:00-5:30 PM CET (Paris/Berlin), 7:00-8:30 PM Mexico City
Check out the April 2024 Power BI update to learn about new features.
User | Count |
---|---|
15 | |
3 | |
1 | |
1 | |
1 |
User | Count |
---|---|
26 | |
3 | |
2 | |
2 | |
2 |