Global ElastiCube Builds Schedule Report
Currently there’s no way on the Sisense UI to have an overview of when the next ElastiCube Builds are set for. Having such info available would make it possible to easily select relevant time slots to run load testing scripts for instance, but also more broadly to help understand and finetune the current Builds orchestration. In order to do so, we would like for admin roles to have access to a single table-like page that would list all the Builds scheduled in the next 24 hours with the following columns: ElastiCube name Build start date Build theoretical end date* Last successful Build duration * Build theoretical end date = Build start date + Last successful Build duration * (or NULL in the rare event where the Build has never succeeded before) Additional features: CSV Export Sort option on column headers Pagination Note: a single Elasticube can have more than one entry (in the example below, we assume the admin user opens the page at 3:00 PM and the ElastiCube_B's Build is launched every 2 hours).
Here are some improvements looking for better usability
1. View all history of builds and its corresponding logs from the cubes. Because, I could not see the last build failure reason, if another build got started. I need to wait for another build to complete or fail. 2. View all history of changes and provide a way to revert as in Google docs for both the cubes and dashboards. Some times, if something went wrong, we should just be able to revert to the previous version and continue from there. 3. Provide a way to view the list of cubes in the queue waiting for the build. Also, allow remove or disable them for a period or rearrange the queue to build. This will help in prioritizing something manual on demand. 4. If a cube build fails due to the memory or other configurations issue, provide suggestions like what has to be changed and based on what before triggering another build. 5. Provide a page to derive the suggested the configurations like memory, cpu, timeouts etc by collecting details like 1. Number of cubes, 2. average cube size, max cube size, min cube size, or number of cubes by size range say <5g, <10G, <20G, <40G etc.., 3. Frequency of the build per cube etc.. 6. Provide a page to view all the slow running dashboards, slow running queries and some suggestions to improve it. 7. Some times, if a dashboard got changed and republished, it is not getting applied to all the users. Provide a way to view the version of the dashboard the user may view. 8. Between builds, if there is not much change in the data, Sisense build should go faster. Provide a way like one common place to build each table from other sources individually and keep it ready. From there, if we build say functional cubes, it should build in flashing fast using the locally stored data. I see the cubes are pulling the data faster from relational db but very slow from mongodb. Now, if we are pulling data from another sisense cube or from the source no big performance difference. 9. Also, I am not sure, if we are restarting the nodes, should we necessarily mark the cubes in queue as failed, instead adding back to the queue as it was before the restart and just marking the actual cube got failed should be good enough. More later .. Thanks, Muthusamy J
Different database connections on staging server vs production server
Hi, We have two cloud servers in Sisense: one for development (staging) and one for production. The staging server connects to our staging database. The production server connects to our production database. All cubes and dashboards are identical except for database connection strings and names. Our Git branching strategy follows these steps: Create a feature branch from staging. Make changes and push them to the feature branch. Open a pull request from the feature branch to staging. Test changes in staging. If approved, merge staging into master (production) to deploy changes. The Issue Git integration tracks database connection names, meaning both servers must either run on staging data or production data—this is not feasible for us. Proposed Solution We suggest implementing a decentralized environmental variable for storing database connections. For example: Use {database-server-name} as a placeholder in configurations. Set database-server-name = db_server_staging on staging. Set database-server-name = db_server_production on production. This would allow the same codebase to dynamically connect to the appropriate database without manual adjustments. Would love to hear your thoughts on this!
Easy way to change Sisense server IP address
When a Sisense server's IP address changes, you have to reinstall Sisense. I want a script or button that changes all the relevant settings. We need it because we're planning changes to our network. There are other reasons that an IP address might need to change, e.g. I might restore from a system image backup to a different location, or I might start a new server and, after testing, want to redirect my old server's IP address to it. We'll do it by reinstalling, but that feels like more work than it should be.Allow changes to be pushed from Private to Shared viewing
This really should already be an option within this feature but the fact that is not is quite maddening. When I am working on my private dashboards, there needs to be a button to push changes from the private view to the shared view to then republish the results. This should already be a feature and know that many of our clients have complained about this feature. Please please make this update sooner rather than later.
GIT Integration - Preserve Folders between environments
We use GIT Integration to promote our projects from our DEV environment to PROD. When we execute a Pull request in PROD, all the dashboards of the project are imported into the "ROOT" folder of PROD. Would it be possible to preserve the Folder structure of the dashboards as they were placed in the DEV environment
Quick way to update SSL certificate
It would have been great if there was a quicker way to update the SSL certificates on the Sisense server without having to run the update install. There are clients who do not wish to provide internet connection on the server once Sisense install is complete. As I understand it, if Sisense was installed with internet connection on, then we need to have internet connection in order to re-run the installer successfully. So we will have to make a request to the client to provide internet connection again to run the update install. It would have been good if there was an alternative way to update the SSL certificate.Simply Ask modified NLQ model import-export within a *.dash file
Current behavior of the Simply Ask feature doesn't support automatic saving of the modified NLQ model to the "*.dash" file. So you loose your development work after exporting the dashboard with already enabled and tuned "Simply Ask" to a "*.dash" file. After importing this dashboard back to Sisense the feature is automatically disabled. Also if a developer will enable it manually it starts running based on the "By Default" NLQ model. This forces to redo all the work on the model back again which is time consuming and not efficient. We expect Sisense to consider in the future the development work on making this more convenient for a BI engineer. If a "Simply Ask" feature will be automatically enabled on an imported dashboard with a corrected model, it would be beneficial for dashboard deploy automation and will reduce unneeded additional manual work on setting up this feature again and again for different working environments for the same dashboard.
