The Smart Label
Download: Smart Label Introduction The following article describes steps needed to add to create smart text widget to present ElastiCube fields as text. Implementaion Steps Extract the folder in the attached zip file into \...\Sisense\PrismWeb\plugins. If you are using version 7.2 and higher unzip the contents into your C:\Program Files\Sisense\app\plugins\ folder. Create new widget and chose the smart label icon from the list Choose a field to present, set a design and hit "Apply" [Please note, that in case you have multiple values, it will present the first one. Therefore, it is always better to change the type of the filter to single value only, like in the given example] This plug in works on Version: L8.0.5.156. Only drop the plug in folder contained in the download folder into the plug ins folder in Sisense.Ensuring Accurate PDF Export Headers When Programmatically Modifying Dashboard Filters in Sisense
When working with Sisense dashboards, programmatically modifying filters upon dashboard load via dashboard scripts for a specific user or circumstance is possible. However, an issue can sometimes occur when exporting these dashboards to PDF immediately after such modifications: the filter header displayed at the top of the exported PDF displaying the current dashboard filter state may not accurately reflect the current state of the dashboard filters. This article explains the cause of this issue and presents a solution to ensure that PDF exports display the correct filter information in the header.How to Export a Certificate using the Certificate Export Wizard (Windows only)
How to Export a Certificate using the Certificate Export Wizard In Sisense version 7.2 and later, SSL (Secure Sockets Layer) settings have moved from Microsoft IIS into the Sisense Configuration Manager. For organizations moving to Sisense 7.2 and above from an earlier version that would like to continue using SSL, it is necessary to obtain the certificate to make SSL work. See the steps below to attempt to obtain the certificate from the server's certificate store if your organization previously had SSL set up on the Sisense web server. Organizations can also opt to contact their Certificate Authority (CA) to obtain an up-to-date copy of your site's .pfx or .crt and .key files. This explanation utilizes mmc (Microsoft Management Console) to export the certificate. On your webserver, search programs for mmc and select mmc.exe In the window that appears, click on "Add/Remove Snap-in..." In the "Available snap-ins" column, click on Certificates then click "Add >" to add it to the "Selected snap-ins" column In the resulting pop-up, select "Computer account" then click 'Next' Leave the settings as is on the next screen and click Finish Click on OK to add the Certificate snap-in On the left-hand side of the screen, expand Certificate (Local Computer) > Personal > Certificates Right-click on your certificate, go to All Tasks > Export The Certificate Export Wizard will appear which will assist you in exporting your organization's certificate to the appropriate format. Select the Next button. On the Export Private Key screen, select "Yes, export the private key". The private key is necessary for SSL to work in Sisense 7.2 and higher. Then select the Next button. On the Export File Format screen, select the Personal Information Exchange (.PFX) file option and hit the check boxes that correspond to the options below, then select the Next button. ☐ Include all certificates in the certification path if possible ☐ Export all extended properties ☐ Enable certificate privacy On the Security screen, select the Password checkbox and enter a password. Make sure the encryption setting is TripleDES-SHA1. Then select the Next button. Select the file location in which to save the exported certificate. Then select the Next Button. On the last screen select the Finish button to complete the setup. Complete the setup in this guide to set up SSL in Sisense.How To Find Your Sisense Version? (Windows only)
Question: How can I find the exact version and build of my Sisense environment? Solution: There are 3 easy ways to find the exact version of your environment: On the web application Open your Sisense web application On the top toolbar, click on the person icon. The version will be the last item on the menu which pops up: On the Desktop ECM Note: Not relevant for Sisense Linux Open the desktop Elasticube Manager Click the Help & How-To's button on the top scroll bar Click the About button The version will be here: On the web application Open dev tools - console (F12) Copy this and press enter: prism.version The version will be displayed as output:Resizing System Volume Information (SVI) Windows only
Question: Sometimes your server might run out of space on because the SVI (System Volume Information) is eating up all memory. The system volume information is used in windows in order to save information related to system restore which is used when a restoration of the system is performed. The problem is that if there is no size limit to this feature, it might take a significant amount of the system memory, without ability to directly delete it. Answer: There are two ways to resize the SVI: Through the system properties - follow these instructions: http://www.pcadvisor.co.uk/how-to/windows/how-make-system-volume-information-folder-smaller-3613911/ Through the command line - if you don't see the system protection tab according to the above method, you can resize it through the command line: https://indrajitc.wordpress.com/2008/03/25/reclaiming-disk-space-from-system-volume-information/Pulse Troubleshooting (Windows)
Sisense Pulse allows you to stay on top of your most important KPIs across all your dashboards and your ElastiCube builds status. If you face any issues with Sisense Pulse, the first step is to identify if none of the alerts are working, or whether it's an issue for specific notifications such as email reports or push notifications created by the system. If no alerts are created (meaning you see no notifications in the notification icon), this could indicate that Pulse communication is either blocked or isn't running successfully. No Alerts are Created If you do not receive any alerts, verify that the following services are running: In Windows Services Manager for Sisense V7.2 and later, verify that Sisense.Broker is running: 2. In Task Manager, under Details, verify that Sisense.AlertingMQ.exe and erl.exe are running. 3. Verify that port 5672 is open on the Sisense server for the RabbitMQ system to have open communication. When Pulse is not running as expected, we strongly suggest trying and restarting the Sisense.Broker service and follow Steps 1 and 2 again to see if the issue is resolved. If after restarting the services Pulse is still not running as expected, the next step is to verify that the ElastiCube Manager is creating the proper notifications. You can verify this by navigating to %ProgramData%\Sisense\PrismServer\PrismServerLogs\ECS.log and search for ‘EventsPublishManager’ in the log. If there are no messages with ‘EventsPublishManager’, it means that Pulse was not triggered or some error message could be logged that describes the cause of the issue. In rare cases there might be an issue with RabbitMQ database. Make sure the following folder exists in your environment C:\Program Files\Sisense\Infra\Rabbitmq. Specific Notifications are not Received If the notifications are displayed in Sisense in your Notifications Feed, but you do not receive emails or push notifications in the mobile app, make sure you have checked these options under the Alert settings when you created the alert: Regarding push notifications in Sisense Mobile, make sure that all users that are supposed to get push notifications are logged in to the mobile application and have the proper application permission for popups. If some users do not receive email notifications, check if they can receive any system emails like ‘forgot password’ or when a dashboard is shared. In case no emails are sent from the system, review the email troubleshooting guide. Another useful test to conduct is to try running the Pulse on a different widget in order to make sure this is not a widget related issue. *Note* for Split Deployment Models Prior to Sisense 7.4 If you are not receiving pulse alerts and have a split deployment set up (High Availability, one cube server and one web server, etc) please follows the steps below to see if this resolves the issue you are facing. On the cube server, open "C:\ProgramData\Sisense\PrismServer\ElastiCubeConfiguration.xml" and edit the RabbitMQ IP address to be the IP (or name) of the app/web server Restart the Elasticube Management service (ElastiCubeManagementService -or- Sisense.ECMS and Sisense.ECMServer) On the app server, check to make sure ERL.exe and Sisense.Alerting.MQ.exe is running and 5672 is open from build to app server Restart Sisense.Pulse (or Sisense.Broker) Do a test build that you expect to receive pulse alerts for Still Not Receiving Pulse Alerts? If you are still not able to resolve the issue with the above information, please make sure to submit a ticket with screenshots and results of the above steps and we’ll happily assist!Update and add new Highcharts modules for use in Sisense plugins
Update and add new Highcharts modules for use in Sisense plugins The JavaScript library framework Highcharts is natively included in Sisense and is utilized in many native Sisense widgets as well as in numerous Sisense plugins. Although Sisense typically does not alter the Sisense Highcharts library version with every release, the versions of Highcharts included in Sisense may change when upgrading to a new major version release. Highcharts can load additional chart types and other types of functionality via JS module files that contain code-adding features such as additional chart types, which can be used within plugins along with additional code to create additional widget types. If a plugin utilizes a Highcharts module, you can source the module directly in the "plugin.json" file's source parameter, as shown in this example: "source": [ "HighchartModule.js", ], To determine the current Highcharts version being used in your Sisense version, you can use the "Highcharts" command in the web console while viewing any page on your Sisense server. After identifying the current Highcharts version, you can find the corresponding module hosted on the Highcharts code hosting website using the following URL format: https://code.highcharts.com/${Highcharts_Version}/modules/${module_name}.js For example: https://code.highcharts.com/6.0.4/modules/heatmap.js You can save this module and upload it to the plugin folder or replace the older module JS file simply by copying and pasting the code directly. Be sure to update the "plugin.json" file to point to the new module file if the file name has changed or if this is the first time the module is included. Simply sourcing the module file in the "plugin.json" file is sufficient to load the module into Highcharts; no further code is required to load the module.Setting Up SSO SAML 2.0 With Keycloak
Keycloak supports applications that support SAML 2.0, such as Sisense. This page describes how to add Sisense to Keycloak and configure SSO-support with SAML 2.0 by creating a Keycloak client and connecting it to Sisense. This article assumes you have a Keycloak IdP Server configured. Note: This page reflects a 3rd party’s application which may change. If the steps described here do not match what you see in your Keycloak account, you can use the generic Sisense SAML documentation, along with the IdP’s documentation. Connecting Sisense To Keycloak To connect Sisense to Keycloak: Download sisense_client_config.json to your PC. Log in to your Keycloak's admin console (http://localhost:8080/auth/admin/) Select Clients from the left menu. Click Create. In the Add Client window click Select File. From the file explorer popup window locate the file downloaded in Step 1 and click Open. Back in the Add Client Window click Save. In the Settings tab of the opened Sisense client page expand the Fine Grain SAML Endpoint Configuration section. In the Assertion Consumer Service Redirect Binding URL filed replace "localhost:8081" with your domain name. If using secure connection, replace "http" with "https". Updated value of the Assertion Consumer Service Redirect Binding URL to match the value of the Assertion Consumer Service Redirect Binding URL (from the previous step.) Click Save. Click on the Installation tab. From the Format Option, select Mod Auth Mellon Files and click Download. Extract the downloaded keycloak-mod-auth-mellon-sp-config.zip. Open the idp-metadata.xml file from the extracted folder. Open your Sisense web application. Go to the Admin tab and click on the Single Sign On menu item. Select SAML 2.0 as the Method option. In the idp-metadata.xml file locate the following element. <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://localhost:8080/auth/realms/Sisense/protocol/saml" /> <SingleSignOnService> 20. Copy the value of the Location attribute to the Remote Login URL field in Sisense. 21. In the idp-metadata.xml file locate <dsig:X509Certificate>. 22. Copy the value of the X509 certificate to the Public X.509 Certificate filed in Sisense. 23. Enable Single Sign On by clicking the switch button. 24. Click Save.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.Overview to Interpreting Sisense 7.2+ Logs
In Sisense Version 7.2 and beyond, we replaced many components of the IIS web hosting with a NodeJS framework, as well as making many new structural changes to the software. This allowed us to categorize the key components of the application to categories of microservices. Each microservice performs some essential functionality in the software, and each one also has it's own logging file path associated with it. While this certainly isn't an all inclusive guide, this article is intended to shed light on the logging processes of the software. In order to interpret the logs for a particular issue, a user will need to first narrow down exactly which service is being affected. This can best be done by understanding the services list at the following article: Identifying Sisense Services Once we identify where exactly the issue is, we can find most logs for each individual service at the corresponding file path in: C:\ProgramData\Sisense\application-logs The main exception of logs that would not be found in the individual service logs, are the following: Build Logs (which detail each individual build error and successes, and often times contains better error reporting than the GUI in the elasticube managers): C:\ProgramData\SiSense\PrismServer\ElastiCubeProcessLogs<YourElastCubeName> Prism Server logs: C:\ProgramData\SiSense\PrismServer\PrismServerLogs Sisense Web log: C:\ProgramData\Sisense\PrismWeb\Logs ElastCube build logs: C:\ProgramData\SiSense\PrismServer\ElastiCubeProcessLogs<YourElastCubeName> MongoDB: C:\ProgramData\Sisense\PrismWeb\Repository\DB iisnode (web server) logs: C:\Program Files\Sisense\PrismWeb\vnext\iisnode Many log paths include an "error" log and then a general log name that does not include "errors" or "stderr". This is done as a way to simplify the troubleshooting process by filtering out all of the errors into their own log file, this is not always the case for each log, though, and sometimes it can be beneficial to look at the log file that doesn't include errors to see the process flow of the application leading up to, during, and after an issue has been noticed. All of the logs contain single instruction level data, meaning that, while they can be rather large, each instruction is associated with a particular timestamp, so it is important to know the date and time that the error occurred beforehand. Once you are able to narrow down the individual service and time stamp that the error occurred with, you can go to that section of logs and begin your digging. As multiple processes can occur in a very small window of time, most users find it beneficial to search for the term "fail", "failure", or "error" to narrow down exactly which line might be relevant to their search. Once a user has found the particular error that they feel could be responsible for the particular issue they are having, there are a few key elements to look for. While some errors are simple to understand, such as a build failing from needing more space on the hard drive, others could be more challenging since they are often written at the software developer level, and may even include a stack trace of where exactly in the program code the issue occurred. For errors of this later type, it is best to document the error, and open a service ticket with the support team for further analysis. Users should also note that these microservices often call API endpoints and other pieces from other microservices, which may require them to do some further troubleshooting in those particular set of logs. For example, a user may notice that an API call in the API-Gateway logs is calling an API that has the term "Galaxy" in it, and this call is returning a 500 code (an internal service error code which could have many different causes, and is considered to be a very generic error), the user should be able to go into the galaxy logs for that particular time stamp, and see the call being made, and find out more specifically what caused it to fail. All of the logs contain single instruction level data, meaning that, while they can be rather large, each instruction is associated with a particular timestamp, so it is important to know the date and time that the error occurred beforehand. Once you are able to narrow down the individual service and time stamp that the error occurred with, you can go to that section of logs and begin your digging. As multiple processes can occur in a very small window of time, most users find it beneficial to search for the term "fail", "failure", or "error" to narrow down exactly which line might be relevant to their search. Once a user has found the particular error that they feel could be responsible for the particular issue they are having, there are a few key elements to look for. While some errors are simple to understand, such as a build failing from needing more space on the hard drive, others could be more challenging since they are often written at the software developer level, and may even include a stack trace of where exactly in the program code the issue occurred. For errors of this later type, it is best to document the error, and open a service ticket with the support team for further analysis. Users should also note that these microservices often call API endpoints and other pieces from other microservices, which may require them to do some further troubleshooting in those particular set of logs. For example, a user may notice that an API call in the API-Gateway logs is calling an API that has the term "Galaxy" in it, and this call is returning a 500 code (an internal service error code which could have many different causes, and is considered to be a very generic error), the user should be able to go into the galaxy logs for that particular time stamp, and see the call being made, and find out more specifically what caused it to fail.
