OlehChudiiovych
Sisense Employee
Joined 10-19-2021
User Profile
User Widgets
Contributions
How to plot locations on a Scatter map [Linux]
The scatter map widget provides a way to plot your data over the World’s map. This is done with the help of the 3rd party solution called Mapbox. Location data is sent to the Mapbox server to return matching coordinates for country/state/city. This is sent without any additional data from the widget or Elasticube/Live. This is applicable for any environment, such as hosted on Windows or Linux OS, Cloud Managed, or Self-hosted.Localization in Sisense, or How to Control Date and Numbers Format
Localization in Sisense, or How to Control Date and Numbers Format In Sisense, the format of data displayed, such as date and numbers in widgets or filters, is managed by localization. By default, localization is set to be automatically detected based on browser/device settings. This means two users with different settings can see the same widget differently. There are 2 ways to control the format of dates and numbers, aka the localization: Browser settings Language and location selected in browser settings is the easiest way to control the format of date and numbers in Sisense. In my case both my laptop and browser have English (UK) as the main language: The result on a dashboard: If the user is located in another country and therefore has different preferred language/localization selected, the data will appear differently/dynamically. Using Sisense REST API to define one specific localization It is also possible to disable the auto-selection of localization and define a specific one: This Sisense environment has English (US) selected as the default and only localization: To change this, the REST API endpoint can be triggered with the given payload: Where "autoDetectEnabled" is whether we take the localization from the browser (true) or specified default one (false). The list of most common localization can be found here (https://learn.microsoft.com/en-us/openspecs/office_standards/ms-oe376/6c085406-a698-4e12-9d4d-c3b0ee3dbc4a). After making the changes using REST API, the dashboard looks like this: Note, this means every user will see the data with the same format despite the country/browser settings.Branding/White Labeling with Sisense
What is Branding? Branding or white-labeling is a way to alter the visual part of an application to match your application's visual style. Sisense provides a list of options for rebranding the visual style of GUI, emails, and so on. Sisense provides the following branding options, including: Look and Feel Email strings customization Email logos customization Basic general branding Look and Feel Look and feel allows users to quickly and easily change things like font, panel color, text color, etc. For more information, read through Sisense's documentation on Customizing the Sisense User Interface (https://documentation.sisense.com/docs/customizing-the-sisense-user-interface). Email Strings Customization Sisense has a list of predefined email templates that are used to send reports on dashboards, builds, and so on. In some cases, the text in those emails can be customized. For example, users have the option to replace Sisense with their custom company name. Text(strings) used in email templates are translated to multiple languages and are saved locally. With this information, users can then alter the text in translation files to change the text in email reports. Translation files for emails can be found under the following path: Linux: /opt/sisense/storage/translations/{Language}/email-templates.js (Or {Server}/app/explore/files/translations/en-US/email-templates.js using Web File Manager) Windows: C:\Program Files\Sisense\app\translations\{Language}/email-templates.js In most cases, English is used for emails, therefore, the folder we need will be en-US. This file contains all the strings that are used in email reports in the following format: {Email type}: { {token}: '{String}', {token}: '{String}' } Where token is the variable that should not be removed from the file, new tokens should not be added as well. String is the actual text that will appear in our email, and is therefore the only thing that can be edited. Here is an example of how to change one of the strings under the test_email type: Once changes are complete, the Galaxy service/pod should be restarted (Restart Sisense.Galaxy service in Windows): This will trigger a test email where we will see the changes in the email body text. Before: After: Email Logos Customization Logos used in email reports can be changed by replacing the default logo files with custom ones. Default images are stored here: Linux: /opt/sisense/storage/emails/images/ (Or {Server}/app/explore/files/emails/images/ using Web File Manager) Windows: C:\Program Files\Sisense\app\galaxy-service\src\features\emails\templates\images\ Note, that if a custom location for a template is specified, the default images and templates will be ignored. The images are mapped using a name, therefore in order to replace the image, the new file should have an identical name. Below is an example of how this works. Below, is the same default recovery password email referenced earlier in the article: Let us replace recover-password.png file with a new one and restart the galaxy pod: Below is the result: Basic General Branding Sisense has a list of branding parameters that can be further adjusted to white label your application. It can be located and changed in 2 ways: Using REST API: Using Configuration Manager ({Host}/app/configuration/system in Linux or Localhost:3030 in Windows): From here, we can change the logos, strings, and toggle some parameters on or off. Saving should prompt relevant services to restart automatically. Pay additional importance to the "Emails Templates Directory" parameter as it will allow users to specify a custom path for email templates. Once specified and saved, emails will not use the default folder. Verify that the new path is correct, otherwise, no email will be sent due to no file being found. Why would you use a custom email template directory? As in most cases, the default template folder is overwritten during version upgrades, meaning changes will be reverted back to default. Users can avoid this issue by using a Custom Email templates folder since it will remain unchanged during the upgrade process. Note that some releases might introduce new logos or emails that will be missing from the custom folder. In this case, Sisense recommends either re-doing the folder content or copying over missing files. Below are additional resources from the Sisense Knowledge Base: Personalizing the Analytics User Experience with Sisense Themes (https://community.sisense.com/t5/sisense-community-blog/personalizing-the-analytics-user-experience-with-sisense-themes/ba-p/153) Replace the homepage with an embedded dashboard (https://community.sisense.com/t5/knowledge/replace-the-homepage-with-an-embedded-dashboard/ta-p/894) How to Disable Emails from Sisense (https://community.sisense.com/t5/knowledge/how-to-disable-emails-from-sisense/ta-p/181)Linux | ElastiCube Local Files System
Linux | ElastiCube Local files system Sisense application utilizes MonetDB to write raw data into Elasticubes (commonly referred to as EC or cube). Why does this happen? This allows Sisense to query the data from itself rather than sending a query back to the data source every time the dashboard is accessed. The process of importing raw data in Sisense Elasticube is called "build". On Linux, there are a few different types of build modes that exist in Sisense: Regular - shared storage Build on local Build on local with S3 https://documentation.sisense.com/docs/storing-elasticubes-on-s3 In each case, the build method will be different, which means the query will also be different too. 1. Regular - Shared Storage Regular builds put the data into a shared storage /opt/sisense/storage/farms while building. The name of the specific farm is composed of the elasticube name and the timestamp at which the build was started. For example, the directory for a Sample Ecommerce cube that started building on September 23rd may look like aSampleIAAaECommerce_2022.09.23.07.26.31.585 A new directory (composed of name + timestamp) is created for every build. Full Build: When a full build process starts, an empty directory is created, and the data is imported to that location. In the case of a failure, this newly created directory will be deleted. In the case of success, a new EC query pod will be loaded and attached to the new location. After a successful startup, the previous copy of the query pod of this cube (if it exists) will be terminated, and the directory attached to it will be deleted. These operations are done by the management service. Accumulative or Schema Changes Build: In cases involving accumulative or schema changes, the original directory will be copied before the build starts. Because of this, the first build after an accumulative behavior is selected will take more time. After the build finishes successfully, and the new cube is loaded, the original cube will get patched with the changes, so it is not necessary to copy the full data set each time. The new cube will be activated, and the old cube will become ready for the next build. The directory will be the same as the original but with "_next" added to the end. aSampleIAAaECommerce_2021.02.23.07.26.31.585_next When the next accumulative build starts, it will use the _next directory and will not need to copy the entire cube. Note: this will double the storage size since both directories will remain. Loading of the Cube When the cube loads, the farms point to /tmp/aSampleIAAaECommerce_2021.02.23.07.26.31.585/dbfarm inside the cube pod. The files are copied to /opt/sisense/storage/farms/aSampleIAAaECommerce_2021.02.23.07.26.31.585/ 2. Build on Local: Full Build, Accumulative, or Schema changes: Same as regular behavior, with a few modifications to farm locations: Builds put the data into local storage /opt/sisense/local_storage/ while building. Using the Sample Ecommerce Example: /opt/sisense/local_storage/aSampleIAAaECommerce After the build finishes, copy the cube into the shared storage: /opt/sisense/storage/farms/aSampleIAAaECommerce_2021.02.23.07.26.31.585 Delete the local folder /opt/sisense/local_storage/aSampleIAAaECommerce from the server. Additionally, you will need to create a compressed file dbfarm.tar.gz of all the files smaller than 65K and all the symbolic links that will be needed to operate. Symbolic links should point to the shared storage. This speeds up how fast the cube loads. Creating symbolic links takes time, and getting small files from the shared storage can create high IOPS that can overload the shared storage. It is more useful to open one tar.gz file that includes all links and small files. When the POD is terminated or killed, delete the temporary folder /opt/sisense/local_storage/aSampleIAAaECommerce. If we kill the pod with "kubectl delete pod ec-sample-ECommerce-bld-749dd924-45a0-4-5866b6c47d-nlsq7 --force --grace-period=0" the delete will not take place, and the farm will remain on the server. If the server reboots and /opt/sisense/local_storage is not ephemeral storage, the files will remain. In AWS, it is recommended to use local NVMe ephemeral storage that comes with r5d or m4d machines. Loading of the Cube: When cube load, the farm points to /opt/sisense/local_storage/aSampleIAAaECommerce_2021.02.23.07.26.31.585-bbe0/ All files from /opt/sisense/storage/farms/aSampleIAAaECommerce_2021.02.23.07.26.31.585/ will be copied there. Additionally, the dbfarm.tar.gz, which was generated during the build stage, and contains small files and links to large files, is copied and extracted into a local storage folder. Also, notice that the folders are under /opt/sisense/local_storage, which is a host map and not pod local storage. The name of the folder has a unique identifier (-bbe0) to prevent two EC instances on the same server from stepping on each other. When the POD is terminated or killed, we delete the temporary folder /opt/sisense/local_storage/aSampleIAAaECommerce_2021.02.23.07.26.31.585-bbe0/. If you kill the pod with "kubectl delete pod ec-sample-ECommerce-qry-749dd924-45a0-4-5866b6c47d-nlsq7 --force --grace-period=0" the delete will not occur, and the farm will remain on the server. If the server reboots and /opt/sisense/local_storage is not ephemeral storage, the files will remain. In AWS, it is recommended to use local NVMe ephemeral storage that comes with r5d or m4d machines. 3. Build on S3 This is the same as building on local, with a few additions. Building happens on the local path - /opt/sisense/local_storage/aSampleIAAaECommerce. At the end of the build, we pack all the folders as one big tar.gz file and copy it to s3. s3://sisensebucket/sisense/Default/aSampleIAAaECommerce_2021.02.23.07.26.31.585.tar.gz The path determined from s3://<management.S3bucket>/<management.S3path>/<DataGroupName>/<farms>.tar.gz To set the management.S3bucket and management.S3path use the CLI: si config set -key management.S3bucket -new-value sisensebucket si config set -key management.S3path -new-value sisense After the copy finishes, the local directory will be deleted, which is similar to building on local. Loading of the cube: When the cube loads to the farms point to /opt/sisense/local_storage/aSampleIAAaECommerce_2021.02.23.07.26.31.585-bbe0/ We download the farms from the s3 ( s3://sisensebucket/sisense/Default/aSampleIAAaECommerce_2021.02.23.07.26.31.585.tar.gz) and open it on the local file system. Since we do not delete the files from s3 and leave them to be deleted by the s3 lifecycle, you may have a cube pointing to a file that the life cycle deletes before you rebuild the cube. The following rule deletes the files after 14 days. cat <<EOF >expire-s3-rule.json { "Rules": [ { "Expiration": { "Days": 14 }, "ID": "deleteold", "Filter": { "Prefix": "*" }, "Status": "Enabled", "NoncurrentVersionExpiration": { "NoncurrentDays": 14 }, "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 1 } } ] } EOF aws s3api put-bucket-lifecycle-configuration --bucket sisense-shared-s3-storage --lifecycle-configuration file://expire-s3-rule.json In this case, the download will fail, and you will see that reflected in the log: download failed: s3://sisensebucket/sisense/Default/aSampleIAAaECommerce_2021.02.23.07.26.31.585.tar.gz to - An error occurred (404) when calling the HeadObject operation: Not Found The cube will not be loaded. To avoid this, make sure the lifecycle is longer than the building period of the cube. When the POD is terminated or killed, delete the temporary folder /opt/sisense/local_storage/aSampleIAAaECommerce_2021.02.23.07.26.31.585-bbe0/. If you kill the pod with "kubectl delete pod ec-sample-ECommerce-qry-749dd924-45a0-4-5866b6c47d-nlsq7 --force --grace-period=0" the delete will not occur, and the farm will remain on the server. If the server reboot and /opt/sisense/local_storage is not ephemeral storage, the files will remain. In AWS, it is recommended to use local NVMe ephemeral storage that comes with r5d or m4d machines. Conclusion This information can be used to understand the path to import row data, the purpose of having multiple folders, and help troubleshoot the build process itself. As always, if you need additional help, please contact Sisense Technical Support to get more in-depth assistance!Re: Using RSUM with with dashboard filters
Hi GSSC I don't think this is possible as RSUM specifically calculates the visible/available data in the same order, meaning if values are excluded from the widget with filter - those values cannot be used in RSUM calculation. I would suggest 2 ways around this: Switch the filter behavior from Slice to Highlight - this way selected months will be highlighted and RSUM will be calculated properly, however all months will still be displayed on a widget Calculate RSUM on the model level with help of a custom table and then display it as is in widgetHow to Reset Your License for Sisense Deployment
How to Reset Your License for Sisense Deployment Sisense is an application that requires a valid license to be used. Occasionally, there is a need to reset the license, for example when we want to change the license used and we do not have access to the old license. Windows OS For Sisense installed on Windows OS we can access the application "Sisense Activation" from the server. Please note, be sure you are running this command as an Administrator: From there, select "Sign Out": Note, the system will not function until it is activated again using the same Sisense Activation application. Linux OS For Sisense installed on Linux OS (single server only, for a cluster, see note below) we will need to make sure the file used for the license is not found by either removing it or (recommended) simply renaming it, using the command below: mv /opt/sisense/storage/licensing/sisense.oxy /opt/sisense/storage/licensing/sisense.oxy.bkp Restart to apply the change: kubectl delete po -n sisense -l app=oxygen && kubectl delete po -n sisense -l app=api-gateway && kubectl delete po -n sisense -l app=identity Once executed, wait for the pods to restart, browse the application using the default link (don't use the link with /app/account/login), and reactivate the license. For multi-node deployment, you will end up accessing shared storage so it is recommended to execute in the management pod by running the command below. Exec into management pod: kubectl -n sisense exec -it $(kubectl -n sisense get pods -l app=management -oname) -- bash Note, Sisense will be deactivated and will not function until it is activated again. We only recommend using this approach as a last resort. You also have the option to make changes to the license in Linux using the License Utilization page instead: In case of any technical issues with licenses feel free to contact Sisense Support. For questions relating to license expiration, email/package owner change, etc. feel free to contact your Account Manager directly instead.
