Introduction
In my blog post Making a Case for a Larger SDK Result Set, I described the scenario of a scorecard component as a real-world example of situations where a larger result set may be needed for SDK components than currently permitted. This follow-on post is inspired by feedback from jeroenvandera Rather than reiterating the SDK result set limit issue, the intent here is to focus on design considerations for developing an SDK scorecard component. Although a scorecard component is on the latest Design Studio Roadmap, I thought it could make for some interesting discussion to see how we might approach implementing this as an SDK component, since such a component seems to be a common question and request on the SCN.
I will make a disclaimer though that this post will not conclude with a link to a fully functional SDK scorecard component (forgive me :smile: ), since the scope is only to evaluate the design considerations and engage the community in discussion and feedback as such.
Setting the Scene
Rather than starting completely from scratch, I came across a good example from HighCharts that could be adapted for reference purposes. I have edited the HighCharts example with my own sample data set as shown below:
A live preview is available here and for those who like to tinker the complete code is here.
Design Considerations
In my view the main design consideration is how to define the layout of the result set to cater for the following scorecard requirements:
1) Columns with a single value
In the scorecard above Scheduled Flights (CY), Delayed Flights (CY) and Average Delay (min) represent examples of such columns.
2) Columns with a sparkline chart which specifies a fixed set of dimension members
In the scorecard above the Delay Groups Column Chart is based on 4 Delay Groups across the horizontal axis: Delay 0 to 14 mins, Delay 15 to 29 mins, Delay 30 -44 mins, Delay 45 - 59 mins.
3) Columns with a sparkline chart which specifies a dynamic set of dimension members
In the scorecard above the Daily Delays Line Chart is based on up to 31 days representing each day of the month.
So how do we best represent this in the underlying data source definition and initial view? Two possibilities are shown below:
a) Each dimension member is defined as an individual measure in the columns:
Under this approach we would map each of the measure columns in the result set to the corresponding scorecard column with a column index, either individually or by specifying a range. It has the benefit of a compact result set. No issues for the single value columns or the Delay Group sparkline column chart with a small fixed number of x-axis dimension members. However, we need to create individual measures for each of the 31 possible individual time dimension members for the Daily Delays Line Chart column, which is not a typical approach.
Now how do we handle the scenario where the number of days in the month varies so that the sparkline chart displays correctly?:
i) Specify an "Ignore zeros at end" option but then how do we know if the zero value is due to the day not existing or genuinely has a zero value? Or maybe this distinction doesn't matter in context?
ii) Dynamically filter out the redundant day measures at the end based on the days in the month.
b) Dimension members are listed in rows with a corresponding single measure in the columns:
Under this approach, since the dimension members are listed in the result set rows, the issue of dynamic number of items for the Daily Delays Line Chart is taken care of but at the expense of a significantly larger result set. Additionally, because we have more then one dimension across the two sparkline charts (Delay Group and Day of Month), client-side aggregation would be required for each of the charts, which is not ideal as such aggregation should preferably be left to the OLAP engine.
So there's some food for thought. I'd be interested in any feedback about the above options and ideas for any other possible approaches.
Blog Series Index: Design Studio Innovation Series - Welcome
- SAP Managed Tags:
6 Comments
