Einstein Analytics Dashboard MVC Design Pattern Introduction
In this “Part 1” post, I will introduce you to the concept and discuss how it works at a high level. In part 2, we’ll cover specific code and example.
For the last few years I have been using a little hack with SAQL bindings that I like to refer as using an MVC design pattern to overcome some limitations I have encountered. Primarily it involves using a saql step as the ‘controller.’ The use case is that I kept running into scenarios where I could not accomplish what I wanted using standard bindings. I wanted interactivity to:
- Swap out a custom calculated KPI (on the fly) as the measure
- Swap out the sort using different groupings
- Swap out the measures or time frames used in custom windowing functions – moving average, running total, etc.
For certain interaction changes you cannot just place a toggle and a value for that parameter (binding) and then replace it within the SAQL query. In these cases, I have used this MVC design. The first step is to create a ‘Controller’ step. This is a custom saql query that pulls a single row (limit 1) from a dataset that will always have results. You don’t care what dataset it is, the underlying data from that dataset does not matter. You are just using it to write your own logic. From here you can write case statements that reference your other static steps that are tied to your toggle widgets. For example:
- If toggle widget 1 == “Moving Average” && toggle widget 2 == “Dials per Rep” then … (place window function with moving average using the right measure column and referencing the right period step (15 day moving average, 30 day moving average, etc.)
Then, your primary SAQL step that provides the results for the visualizations would reference this ‘controller’ step.
All inputs are fed into the controller step and then the visualization steps/queries reference the controller.
More to come on this topic with specific examples but I hope this has piqued your interest and given you something to think about!