Allow API searching for dashboards by any data source used within it (filter or widget), and/or allow searching for widgets that use a provided data source across all dashboards (without providing a dashboardId)
Summary: Chris Wallingford discusses the challenges in maintaining clients' bespoke dashboards when data models are altered with breaking changes. Historically, an automated process updates dashboards by identifying and modifying 'old schema' references, but as the number of dashboards has increased, this process has become time-consuming. Chris Wallingford suggests the need for improved searching capabilities, such as filtering dashboards by both primary and non-primary data sources or searching widgets across all dashboards without the dashboard ID requirement. This would streamline the updating process and limit it to only relevant dashboards or widgets.
When we alter our data models with a breaking change, we don't want our clients' bespoke dashboards to break if we can avoid it. We have historically addressed this through an automated process that takes a "schema change" JSON file, and searches through dashboards for use of any "old schema" source/table/columns, updates then to the "new schema" source/table/column, and then imports the dashboard back into the system. This has worked well, but as time goes by, the process is taking longer and longer... due to there being so many more dashboards to investigate.
We would like to limit our dashboard search to only dashboards that use a given data source. This is somewhat possible now in that the admin/search allows providing a data source name to filter results, but this filters only based on the primary data source in the dashboard, and would not return dashboards for the provided source where that source was not the primary data source on the dashboard. Were we able to search on primary and non-primary data sources, we could limit our dashboard search to only the sources that have schema changes.
Alternatively, or in addition, we could accomplish something similar by scouring widgets instead of dashboards, updating only the widgets that use the provided data source, and posting them back to the environment. However, the widgets endpoint requires that a dashboardId be provided, see issue above.
Mia Isaacson
·4 months agoHey @Chris Wallingford
This is a problem we've seen come up often in environments with many dashboards and active schema changes. The native API's scoping limitations mean you end up doing a lot of unnecessary work just to find what's actually affected. While this is still an extremely valid product feedback item for Sisense, I wanted to at least let you know about a solution that would address this issue today.
The Asset Auditor is a plugin that maps the full relationship between data models, dashboards, and widgets across your Sisense environment, and it sounds like it lines up with what you are trying to do.
While the primary use case is viewing this data on a set of dashboards, the dashboards are built on an elasticube, which is queryable! The Widgets table in the underlying data model exposes DatasourceName, TableName, and ColumnName for every widget on every dashboard without requiring a dashboard ID as a starting point.
You should be able to use a JAQL query and the Sisense API to query by data source name and get back every widget referencing it, along with the dashboard it lives on. That gives you a pre-filtered list of affected dashboards and widgets before your migration process even starts, rather than iterating across everything. And you can feed the results right back into your existing automated process.
Here is just an example of a pivot that shows the relationships between all the different assets from the Data Model, down the line, all the way to the individual widget. And everything in between!
For your specific workflow, the columns most relevant are probably:
DatasourceName — filter to the data source with the schema change
DashboardID — the dashboards you actually need to process
SchemaName — the name of the schema in the source connection
TableName and ColumnName — the old schema references to find and replace
WidgetLink — direct URL to the widget for verification
The Asset Auditor does so much more than just this. But if the primary goal is to reduce the blast radius of your schema migration scans, Asset Auditor can help close that gap.
Feel free to check out our product page and our documentation. And reach out if you have any questions, or want a demo/deeper dive. We would love to work with you to see if the Asset Auditor can alleviate this problem once and for all!
Mia from QBeeQ, a Sisense Gold Implementation Partner
www.qbeeq.io