Solutions to commonly found issues when setting up a new Sisense ComposeSDK project during beta
Solutions to commonly found issues when setting up a new Sisense ComposeSDK project during beta The first two solutions involve issues with installing ComposeSDK dependencies during the beta period while the ComposeSDK dependencies are hosted on GitHub, and GitHub is the preferred method for access. When ComposeSDK exits the beta period, the dependencies will be available on other sources that will not require a custom authentication token. Problem - Errors when installing Compose SDK dependencies from GitHub Solution - Make sure a GitHub token is active in your environment configuration, and that your GitHub account is fully active and accessible. If a custom GitHub token is used, ensure the custom token has "Read Repository" permission. Alternatively, you can use a standard full-access GitHub token. Make certain the entire token is included when copied into the terminal. Problem - SSL errors when downloading ComposeSDK dependencies from GitHub Solution - When downloading from a VPN network, you may experience this error. You can resolve this by making the following npm config change with this command: npm config set strict-ssl false In Yarn, the equivalent command is: yarn config set "strict-ssl" false -g Problem - CORS errors in the browser console when connecting to a Sisense server with ComposeSDK Solution - Add the hosting domain to the Admin > Security Settings page. Also, make sure CORS is enabled. A common issue is a trailing slash at the end of the URL when copied from the URL directly; these must be removed when setting CORS exemptions. Include the first part of a domain (the subdomain, such as subdomain.domain.com) as well as the port number if included. Anything in the URL after the first slash is not required and is not part of the domain. Problem - Sisense authentication errors when connecting to a Sisense server with ComposeSDK Solution - Do not include "Bearer" at the beginning of the token parameter; this is not required in ComposeSDK and is added automatically by ComposeSDK. When "Bearer" is present explicitly, it will be repeated twice in the header. Make sure the entire token is copied and test the token using a program such as Postman or Curl and any documented Sisense API if you are unsure if the token is valid.Performance Improvements On The Single-Node Linux Servers Under Heavy Usage
Symptoms Relevant for Linux Single-node Sisense In a default Sisense single-node deployment, there is one pod per service deployment. In cases of heavy usage, which is usually caused by parallel requests, the number of services processing the request could result in slowness or a delay when accessing dashboard objects, opening admin pages, etc. Diagnosis A good test would be to compare how the system behaves under heavy load and during non-working hours. If you see a difference in the time it takes to load the dashboard layout or access pages in admin, this could be caused by the amount of the load placed on the workers of each pod. This should not be an issue in multi-node environments as services are already scaled up, but in a single node environment, if there is enough RAM/CPU to handle the load, Sisense can scale services to boost the performance of parallel requests. Important services include: api-gateway - webserver service. Takes a request first and communicates with other requests. galaxy - service which serves the object of the dashboard, widgets, data security, shares, navigation panel, and alerts. identity - service which provides detail of users, groups, and authentification. configuration - service which provides system settings and configuration Solution If you have enough RAM/CPU resources on the server, you can scale services by running the commands below. Please note that each additional pod replica will consume up to 8.5 GB of RAM, so keep this in mind when scaling. Below is a command to double the amount of services. Remember to change the namespace and to set the amount of --replicas to the correct amount. kubectl -n <namespace> scale deployment identity --replicas=2 kubectl -n <namespace> scale deployment galaxy --replicas=2 kubectl -n <namespace> scale deployment api-gateway --replicas=2 kubectl -n <namespace> scale deployment configuration --replicas=2 The above steps can help if you notice common api-gateway restarts caused by the OOMemory. Sisense's RnD team is working on a solution to the problem, but in the interim, scaling the api-gateway can help prevent service disruptions.
[Linux] Resolving data model connection errors in Sisense after importing models
This article addresses an issue where data models in Sisense fail to open, producing a "Cannot read properties of undefined (reading 'datasets')" error message. The problem appears during the import of models from one environment to another, accompanied by difficulties in cleaning up datasets using APIs.How to update style sheets in the branding folder for dashboards
In this article, we will address the issue of updates made to style sheets within a branding folder not reflecting on dashboards. Users often encounter this problem due to browser caching, which prevents the most updated CSS files from loading. This guide provides solutions to ensure your dashboard reflects the latest version of your style sheets.Resolving "Internal Server Error" When Importing Model with Generic JDBC Connector [LINUX]
Resolving "Internal Server Error" When Importing Model with Generic JDBC Connector This article addresses the issue of encountering an "Internal Server Error" when importing a model from a local desktop to a production environment using the Generic JDBC connector in Sisense. This error often arises due to compatibility issues with older JDBC frameworks. Here, we provide a solution to resolve this error by updating the JDBC connector and connections. Step-by-Step Guide: Identify the Error: a. When importing the model, if you receive an error message resembling: Unexpected error value: { timestamp: {}, status: 500, error: "Internal Server Error", path: "/api/v1/internal/live_connectors/auth/GenericJDBC… } b. This error could indicate a problem with the outdated Generic JDBC connector. Understand the Cause: The error is due to the Generic JDBC connector using an older framework that is incompatible with the latest Sisense versions. Update the JDBC Connector: Deploy the JDBC connector using the new JDBC framework. Ensure all connections within the cube in the original environment where the model was exported are updated accordingly. Deploying the New Framework: Follow the step-by-step instructions detailed in the Sisense documentation for deploying a custom connector with the new JDBC framework. Access the documentation here: Deploying a Custom Connector - Sisense Documentation. Re-attempt the Model Import: Once the JDBC connector is updated, try importing the model again into the production environment. Conclusion: In conclusion, updating the Generic JDBC connector to align with the new JDBC framework and ensuring the connections are properly configured should resolve the "Internal Server Error" encountered during the import process. Following the above steps will help ensure a smooth and successful model import. References/Related Content: Deploying a Custom Connector - Sisense Documentation Sisense Community Support Forum Introduction to Data Sources Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this please let us know.
Resolving Build Failures Due to Memory Issues [Safe-Mode]
This is the guide of which settings should be checked and adjusted to resolve the problem and prevent future occurrences, in cases when cubes fail with the error ‘Safe-mode’. Please follow the steps below, and after that try to re-build the failed cubes.
Error in ingress-nginx-controller pod after upgrading Sisense to L2024.1
Error in ingress-nginx-controller pod after upgrading Sisense to L2024.1: main.go:64] port 80 is already in use. Please check the flag --http-port !NOTE! - this guide is relevant for non-cloud managed Sisense deployments i.e. installed with Sisense Kubernetes (RKE). After upgrading Sisense to version L2024.1 you might face the following error in ingress-nginx-controller pod’s logs (the default namespace): main.go:64] port 80 is already in use. Please check the flag --http-port Such an issue might be the result of incompatibility between the ingress-Nginx release version that was updated in Sisense L2024.1 and the Kubernetes version in case it is lower than v1.26. In case Sisense L2024.1 was freshly installed on the non-cloud instance (i.e. with Sisense RKE) as a fresh deployment (and was not upgraded from the previous version) this issue should not reveal since L2024.1 package already comes with v1.26 Kubernetes by default. However, if Sisense was upgraded to L2024.1 or it was deployed/installed on Kubernetes lower than v1.26 there will be an incompatibility between the ingress-Nginx release implemented in L2024.1 (4.10.0). To resolve the issue it is necessary to re-run the Sisense upgrade with the following parameters in the configuration yaml file: update: true update_k8s_version: true In case you are still facing the same issue after that, please open a ticket for Sisense Support. This article provides a brief explanation regarding possible Nginx<->Kubernetes compatibility issues in Sisense L2024.1. The article also provides the steps to resolve the issue described. Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this please let us know.
