Product Feedback Forum
Help us make Sisense better by posting your product feedback here.
cancel
Showing results for 
Search instead for 
Did you mean: 

When replacing a server, or testing an upgrade, we often find our clients taking a backup of their Sisense database and restoring it to another server. After updating the server identity in the mongodb, it's pretty much ready to go. However, use dashboards all reference the old server and have to be updated. This is a manual process that the users themselves one dashboard and data source at time. An administrator cannot easily do that work on their behalf.

Acknowledging that there is a replace_datasource API call that allows you to apply a new server and data source to a single dashboard, I would love an easier a way to update just the server across all dashboards.

4 Comments
Status changed to: Needs Info

Hello @wallingfordce.

Thank you for your feedback! I would like to get this Idea over to the product team, but first I would like to get more information and head off any roadblocks to implementation.

Have you looked into the Connection Management feature, and would it address your use case? https://docs.sisense.com/main/SisenseLinux/about-connecting-sisense-with-data-sources.htm

Thank you for working with me to get this Idea fleshed out so it can be evaluated and scoped for effort.

Have a great day!

@wallingfordce 

Have you looked into the Connection Management feature, and would it address your use case? https://docs.sisense.com/main/SisenseLinux/about-connecting-sisense-with-data-sources.htm

Not really @DRay. Firstly, we're on Windows. Second, our issue is more about the connection logged within the dashboard that references an elasticube on a given server. When the elasticubes move to another server, the dashboard has to be updated to change the connection from the old to the new server within the dashboard definition. Connection Management seems to be more about the connections in the elasticubes. We worked around this issue by updating the dashboards in mongo directly.

1. In Studio2T we used these query criteria to firstly locate the widgets that had the Seats and Tickets source from HESTIA still in place:

db.getCollection('widgets').find({"datasource.title": "My Elasticube",
"datasource.address": "server.address",
"datasource.fullname": "server.address/My Elasticube",
"datasource.id": "aSERVERLgAaADDRESS_aMYIAAaELASTICUBE",
"datasource.database" : "aMyIAAaElasticube" })

2. And we then right clicked on one of the results and selected to 'Update Dialog...'

3. We changed the dropdown in the middle of that screen to "Apply the pre defined query" which means it will update all rows returned in the query in step 1.

4. Then In the update tab, within the $Set section, we pasted in the 5 rows that we needed to set for the Seats and Tickets cube, but with the testing server references:

{
$set : {
"datasource.title": "My Elasticube",
"datasource.address": "server.address",
"datasource.fullname": "server.address/My Elasticube",
"datasource.id": "aSERVERLgAaADDRESS_aMYIAAaELASTICUBE",
"datasource.database" : "aMyIAAaElasticube"
}
}

5. We carried out the same steps as above but with the relevant values passed for each data source.

6. We then corrected anything that was still hanging around in the dashboards collection using the same scripts but with 'dashboards' as the collection.

Thank you for the additional details @wallingfordce.

I will bring this to the product team and provide updates here as they are available.

We encourage people to continue to vote and comment. We use community interest as one of the ways we prioritize efforts, so every vote and comment can help turn a request into a reality.

Thank you again for sharing and being part of our community!