Question

Creating a Proof of Concept Embedded Dashboard (Powered by Looker)

  • 13 May 2015
  • 0 replies
  • 593 views

Userlevel 3

If you’re interested in testing out Looker’s Powered by Looker embedded analytics functionality you can do so as an existing customer by following these proof of concept instructions. If you run into any trouble reach out to us on in-app chat or by visiting help.looker.com and we’d be more than happy to help!


In the example below we are using a fictitious e-commerce store that has many brands(suppliers) where we want to surface analytics to each supplier(will need to restrict data access based on the brand name tied to transactional data).


Create New LookML Model File


Create a new LookML model file called ‘embed’ in your current LookML project. There should be no need to create a new project.



Copy Existing Explore


Copy an existing explore from your standard model file in order to test with - we will use one that explores the transactions that will be used to power queries to be used in Dashboards and Looks.



Provision Your User Account With Wildcard Access


Go to the admin panel and create a new user attribute named brand. You can learn more about user attributes on this page in docs. In this example you will see the default value is set to % - the wildcard for string type user attributes.



Create Test User Account


Create a ‘fake user’ that has the brand user attribute set to some value that isn’t a wild card. You will sudo as this user to test out how the filters are applied. To set the user attribute to something other than the default, you can either go to edit the user after creation, or set user values on the user attribute page (shown below).



In this example the test account will only have access to data where products.brand = ‘Allegra K’



Add Access Filters to the Explore


Now that the user attribute is created and you have different attribute values applied to different users (your user vs the fake user), add the ‘access_filter’ parameter to the explore in your new model. For the field parameter, you will include the view.field model reference that the access filter should use for all SQL generated from this explore. This should be a field that is defined in the explore’s view file, or one of the views that have been joined to the explore.


In this example it must be a LookML field defined in either order_items, inventory_items, users or products view files. In this example, we apply an access filter to all queries sourced from the order_items explore applied to the brand field from the products view.



Notice above that we also included the user attribute name in the access filter. This will equate a users brand user attribute value to the products.brand field.


Test User Account


You can start exploring and testing out queries as the embed user to see if the filters are applied as specified. There should be an addition to all SQL that’s generated that includes a WHERE statement limiting the query based on the field and associated filter value. You can view this by clicking the SQL tab in the Explore window after running a query:


Admin SQL: User attribute to Wildcard(% symbol):



Fake User: User attribute sent to Allegra K



Create or Test With Copy of Existing Dashboard


If you’re interested in testing a dashboard that uses Looks based on this explore you can create a copy just for this embed purpose. If you want to create a new dashboard I would do so first as the admin user. Create looks, add them to the dashboard, then sudo as the embed user and view the dashboard from their context. It should be filtered just for their data. View our docs for more information on creating dashboards.


References


Dashboard View


Here’s the view from our embed.looker.com application for the logged in embedded user, in this case the user is representing the brand Allegra K:



Embedded Demo Links


Note: Anytime you would like to see what the embedded version of a dashboard looks like you can add /embed just before the ‘dashboards’ portion of the URL in your Looker instance.


For example:

“https://[your Looker endpoint]/dashboards/thelook/1_business_pulse”

becomes:

“https://[your Looker endpoint]/embed/dashboards/thelook/1_business_pulse”


Visiting the embed/dashboards link will load the dashboard as an embedded dashboard.


SSO Embedding and Authentication


Use of Looker’s SSO embedding option can allow embedding of dashboards to a set of specified external users. Your application would manage the creation and permissioning users in a programatic and scalable way, removing the requirement of creating and maintaining these users in Looker.


If you require a more advanced or customizable embedded solution (SSO with passive login), please contact your Looker account manager for more details, or visit help.looker.com.


You can find example code to use the Ruby Embed SSO API in various languages here.


0 replies

Be the first to reply!

Reply