Skip to Content

How to capture selection of Design Studio InfoChart populated by a BYOD datasource

Jun 28, 2017 at 09:24 PM


avatar image

In Design Studio 1.6, I have an InfoChart that is dynamically populated by the Design Studio SDK BYOD Data-Source component.

A major drawback is that I am unable to obtain the selection of the InfoChart when a user selects a bar in the chart, e.g. the following returns an empty string:

var selection = UA_PIECHART_INFOCHART.getSelectedMember("User Attribute").text;

I have opened a GitHub issue to the SDK community to address this issue, but I have not received a response.

Any insight would be greatly appreciated.

Thank you in advance.

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Mustafa Bensan Jun 29, 2017 at 02:31 AM

Hi Knoa Support,

My comments are as follows:

1) I have been able to replicate your issue for getSelectedMember() in the case where you explicitly specify the dimension as a parameter. The ".text" extension returns null and the ".internalKey" extension returns "(ALL_MEMBERS)";

2) The issue you have raised in github is not directly related to the InfoChart selection at all. The issue there is that a call to DATA_SOURCE.getDimensions()[0] results in the error you have documented, independently of the InfoChart.

In both cases, this would appear to be a bug with the BYOD Datasource component. Since the Community SDK Components are maintained on a voluntary basis, the issue on github may get reviewed and resolved if and when an SDK Community member has time.

What is the business use case you are trying to implement? Perhaps we can suggest alternatives. The BYOD Datasource is mainly intended for prototyping purposes.



Show 4 Share
10 |10000 characters needed characters left characters exceeded

In general, the use of the BYOD Datasource appears to be useful in that it gives an application designer flexibility in designing a data-source that can be visualized in a chart, without having to conform to the constraints of a conventional data-source, such a universe or a BEx query.

In the world of Design Studio, this is closest item that resembles a mutable collection object used in higher-level programming languages such as Java and Python.

In terms of the particular use-case in which this would be helpful, I am constructing a pie-chart, where I want the top-N results, plus another section in the pie-chart that represents "all other values" than are below the top-N results. Ideally I could have created two queries: one to return the aggregate measure for all values, and another for the top-N results. Computing the difference of these two queries returns the value for the "all other values" record. I could then feed the top-N results, plus the "all others" result into the BYOD Datasource - to then be visualized in a chart.

I may still be able to achieve the desired behavior using some clever querying, such as having one query to return the top-N records; and then another query which uses the top-N records as a filter for unioning two results together: one for records which are in the top-N results, and another for all of those which are not in the top-N results.


Thanks for the detailed response. My comments:

1) The recommended approach is to perform such calculations in the backend as per your last example. For BEx data sources the following post describes the technique:

2) The use case you have described would be best visualised with a sorted bar chart for easy comparison of relative magnitudes, instead of a pie chart.


Hello Mustafa:
1. In my use-case, a pie-chart is more appropriate, as we are looking to visualize the contribution/proportion of each dimension-record to the overall metric. Also, the dimension has many records, which would be visualized in a bar-chart in almost endless tail. Having an "All Others" option allows use to summarize this tail into a single value.
2. We are using BusinessObjects universes (built in Information Design Tool).



1. For the bar chart I was actually suggesting to still construct it as a Top N bars plus a single "Others" bar, so you wouldn't end up with an endless tail;

2. If you are using universes you should be able to create a union query consisting of the Top N plus Others.