Builds fail because libraries used in Custom Code tables are not installed
Use case You have specific libraries in Notebooks that have to be installed to run Custom code tables. However, these libraries can be uninstalled automatically (during upgrade or other system changes). Solution Add the following Python code into the first cell of each Custom Table Notebook to check if necessary libraries exist and install them if not, before executing the code: Adjust 'libraries' values to the libraries you need to check. import importlib import pandas as pd # List the libraries you want to check libraries = ['numpy', 'pandas', 'matplotlib', 'openpyxl', 'scipy', 'pyarrow'] # Initialize an empty list to store results results = [] for library in libraries: lib_found = importlib.util.find_spec(library) if lib_found is not None: results.append({"library": library, "status": "Previously Installed"}) else: results.append({"library": library, "status": "Newly Installed"}) print(f"{library} NOT FOUND. Installing now...") !pip install {library} Related Content: Sisense Docs: https://docs.sisense.com/main/SisenseLinux/transforming-data-with-custom-code.htm Sisense Academy: https://academy.sisense.com/notebooks-course
Resolving Elasticube(s) not starting the build process issue
Resolving Elasticube(s) not starting to build process issue Summary This article addresses the issue where Elasticubes are not properly starting the build process and fail to produce a build error (before the initialization process can begin). Step-by-Step Instructions to Resolve the Issue 1. Identify the Problematic Elasticube: Open the Sisense application and open the data model from the Data tab. Attempt to manually trigger a build for a specific Elasticube to confirm build process does not show starting. If the build does not start, note the specific Elasticube name. Check for the existence of the build pod via the command line: Open the command line from SSH access to your Sisense server. Run this command to see a list of current cube build pods: kubectl -n sisense get pods | grep bld If a build pod exists, it will look like ec-cubename-bld. If this pod DOES exist: - verify this pod is up and in running status - verify build and management pods are up and running - recycle build and management pods together: kubectl -n sisense rollout restart deployment build management If ec-bld pod does NOT exist for your cube, there is likely a pod issue with the build or management service. - if your deployment is a single node, verify only one pod of each build and management exists (and is in up-and-running status) - likely, you have an older (build or management) pod that is stuck in a terminating or similar status - run force delete command for older (build or management) pod which does not kill itself: kubectl -n sisense delete pod <name of build or management pod> --grace-period 0 --force Monitor Logs: Review the logs for both the build and management pods to identify any errors that could provide more info on why the management service is unable to create ec-bld pod for your cube; kubectl -n sisense logs <name of management pod> | grep ERROR, kubectl -n sisense logs <name of build pod> | grep ERROR Look for patterns or recurring issues that might indicate a deeper problem. Supplementary Information Contact Support: If the issue persists after following the above steps, contact Sisense Support for further assistance. Provide detailed information about Elasticube and logs from the previous section Check out this related content: Academy DocumentationResolving Issues with Updating EC2EC Passwords in Elasticube Connections
This article addresses the issue of updating EC2EC (Elasticube to Elasticube) passwords in the context of employee off-boarding or password changes. Specifically, it covers the scenario where tables do not appear in the source cube after updating the password, preventing the completion of the update.Troubleshooting "BBP Error 1551" in Sisense ElastiCube Builds
Troubleshooting "BBP Error 1551" in Sisense ElastiCube Builds Summary This article provides a comprehensive guide to troubleshooting the "BBP error 1551" that occurs during the build process of ElastiCubes in the Sisense Windows environment. The error typically indicates a discrepancy between the logical schema and the actual result of the ElastiCube, leading to build failures. Main Content Step-by-Step Instructions to Resolve the Issue Identify the Error: The BBP error '1551' indicates a mismatch between the logical schema and the actual data/indexes in the ElastiCube. This is done to prevent inconsistencies. Initial Troubleshooting Steps: Run Build Schema Changes: After creating a Custom Table, run Build Schema Changes. Add the Relationship and run Build Schema Changes again. Run Full Build: Perform a Full Build (Replace All) to ensure all data and indexes are correctly aligned. Check Logs for Detailed Error Information: Build Process Logs: %ProgramData%\SiSense\PrismServer\ElastiCubeProcessLogs\ ElastiCube Server Logs: %ProgramData%\Sisense\PrismServer\PrismServerLogs\ Review these logs to identify any specific issues or patterns that may be causing the build failure. Frequency and Environment Check: Determine how often the scheduled build runs and how frequently it fails with this error. If possible, duplicate the ElastiCube or create a new one for testing purposes and set its schedule to be more frequent. Observe if the issue's frequency increases. Accumulative Build Check: If the error occurs during an accumulative build, consider running a Full Build (Replace All) to reset the schema and data alignment. Troubleshooting Tips and Alternative Solutions No Recent Changes: If no changes have been made to the ElastiCube and the error persists, it may be necessary to investigate any underlying system or environmental changes that could affect the build process. Monitor and Report: Continuously monitor the build process after implementing the above steps. If the issue reoccurs, provide detailed logs and error messages to the support team for further analysis. Check out this related content: Academy Course Sisense Documentation
Does A Dashboard Try To Execute All Views At Once Upon Loading?
Question Is there any way to get the views to execute sequentially instead of simultaneously? How does the dashboard in Sisense execute the queries? Answer The Sisense client application does attempt to send out all queries (one per widget) at once, but in reality, they are not executed all at once. This is due to the inherent limitations of browsers and HTTP1.1 protocol - so in reality, there is actually a queue of queries to be sent to the server. Then, on the ElastiCube server level, there's a configuration for a number of concurrent queries to be processed and a maximum number of threads per query, which can be accessed through the Sisense Server Console application (locally on the machine hosting your ElastiCubes). By default, when Sisense is installed this setting is dynamically configured according to the number of logical CPU cores available, in a ratio that works for most cases and rarely needs to be reconfigured. Please note that before changing this configuration you will need to consult with the Sisense Support team, and the change will cause the ElastiCube server to restart, resulting in a few moments of downtime. Was this article helpful?
