intapiuser
Admin
Joined 3 years ago
User Profile
User Widgets
Contributions
Share Sisense web application externally (Windows only)
Sisense dashboards can be shared easily within the same private network, but the Sisense web application is not configured to be publicly accessible by default. This page details the steps and best practices to make your Sisense instance accessible to anyone on the internet, so that dashboards can be shared with users outside of your organization and Sisense can be accessed by users not on the same local network as the Sisense server. * Note: These settings make your Sisense web application publicly accessible. Users will still need to authenticate and be shared on a dashboard to access Sisense content. Implementation Steps To access Sisense using the Sisense server's IP address (for example, "192.0.2.0"), confirm that the server has a static public IP address. Consult your IT professional, internet service provider (ISP), or hosting service for more details. To access Sisense using a subdomain/domain name (for example, "analytics.example.com"), update your DNS to point to the machine's IP. You must own and control the domain name you wish to use. Sisense does not manage or assist with domain names or their configuration. Open the inbound TCP port in your firewall. This port is 8081 by default but configurable in the installation process (https://docs.sisense.com/win/SisenseWin/installing-sisense.htm#CustomizingtheInstallation). Nominally, this can be controlled in Windows Firewall with Advanced Security, but many customers have superseding rules from their organization or hosting service. If Sisense is still not accessible over your port after opening it in Windows Firewall, confirm with your IT department whether firewall rules may be in place elsewhere. Implement a security layer using SSL to ensure that all network traffic between your Sisense server and client machines is encrypted. For steps to do so, see here: https://docs.sisense.com/win/SisenseWin/setting-up-ssl-for-sisense-windows.htm. After implementing SSL, ensure the port used (typically 443) is also open for inbound TCP connections. Once these settings are implemented, external users will be able to access Sisense by entering the Sisense DNS/IP address and port (for example, "192.0.2.0:8081" or "analytics.example.com:8081"). * Note: If you don't want users to have to enter a port (for example, "192.0.2.0" or "analytics.example"), use port 80 for http communication and 443 for https communication, as these ports will be hidden from the URL. Troubleshooting If a user is unable to connect remotely after the settings were applied, you can test the communication between the machines to understand the source of the connectivity failure by doing the following: Confirm the Sisense web application is running and accessible locally on the server Use the 'nslookup' command in the Windows Command Prompt (cmd.exe) to confirm your domain/subdomain points to the correct IP address for your Sisense server. For example, 'nslookup example.com'. Try pinging the machine's IP address in the command prompt. This will show if there is communication available between both machines. For example, 'ping 192.0.2.0'. If you are able to ping the machine, use the telnet command to ensure you are able to communicate through the required port. For example, 'telnet 192.0.2.0 8081' Further troubleshooting or review may require your IT team's assistance. Further Reading More information is available here: https://docs.sisense.com/win/SisenseWin/setting-up-your-production-environment.htm. Helpful general information about web applications and security is available from Mozilla: https://developer.mozilla.org/en-US/Apps https://developer.mozilla.org/en-US/docs/Web/SecurityHow 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.Host a New Webpage on IIS (Windows only)
It some situations, it may be useful to be able to use IIS to host website that work with Sisense. A common example would be hosting a webpage that contains the code for an embedded dashboard. Additionally, it could be useful in scenarios when you want to host a web page to be used as your custom home page during rebranding, or when hosting a webpage for the iframe widget This article shows a simple way to host your own webpages using IIS. 1. Add a New Directory to IIS The directory we will add to IIS needs to exist like any other file path, and needs to contain the webpage we want to use. We will create a reference to this directory in IIS so it can be accessed by other users, and parsed correctly by a browser. To do this, open IIS, right click on SiSenseWeb, and go to Add Virtual Directory For this example, I created a new folder to hold all of my webpages at C:\embedded, and I gave it the alias of 'testpages' in IIS. Since I used the default installation settings (localhost:8081), the file C:\embedded\adventure_works.html will be accessible at localhost:8081/testpages/embedded/adventure_works.html. After this, right click the new virtual directory you've created, go to Edit Permissions..., go to the Sharing tab, and click share. From here, use the drop down list to find Everyone, and give them Read access permissions. If a popup appears asking if you like to turn on network discovery, click Yes. In this example, I'm going to host a simple html web page that uses an iframe to display an embedded dashboard. This webpage can be created with notepad. Just be sure to save it with a .html file extension. If you are unfamiliar with embedding dashboards, you can find more information about them here: https://docs.sisense.com/main/SisenseLinux/embedding-dashboards-and-widgets.htm In the example from the documentation, the basic iframe code to embed a dashboard will look something like this: <iframe id=”ifm” name=”ifm” width=”100%” height=”100%” frameborder=”0″ src=“http://mysite.com/app/main#/dashboards/536f3a54d093e26c28000114/widgets/536f3a54d093e26c2800011b?embed=true″ scrolling=”auto”></iframe> However, you'll need to wrap this code in some standard html tags, so it gets parsed correctly by the browser. These tags will give you the format of: <html> <head> </head> <body> <iframe id=”ifm” name=”ifm” width=”100%” height=”100%” frameborder=”0″ src=“http://mysite.com/app/main#/dashboards/536f3a54d093e26c28000114/widgets/536f3a54d093e26c2800011b?embed=true″ scrolling=”auto”></iframe> </body> <html> Now, save the this file in the physical directory you created to be used by IIS. (In my case its C:\embedded). Now we can access this embedded dashboard, with the html code that's attached to this post.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:Additional Data Chart Tooltip Plugin
This script was created for Sisense v5.7.5 and is no longer supported. It may not work correctly on modern versions. Download: Additional Info Tooltip Introduction The Additional Data Chart Tooltip Plugin allows users to display additional measures in a chart's tooltip without adding them as visible series, such as bars, lines, or columns. This allows users to include related metrics in tooltips for deeper insights while keeping the chart itself uncluttered. Steps The Additional Data Chart Tooltip Plugin can be used with Pie, Column, Bar, Line, Area, and Polar charts. In order to add an Additional Data Chart Tooltip Plugin to a chart, please follow the listed steps below: STEP 1: Install the plugin Download and extract the enclosed folder into the plugins folder: For Linux: /opt/sisense/storage/plugins For Windows: C:\Program Files\Sisense\PrismWeb\plugins\AdditionalInfoTooltip, if the "plugins" folder is not there, please create it. If you are using version 7.2 and higher unzip the contents into your C:\Program Files\Sisense\app\plugins\ folder. STEP 2: Configure the widget Open the widget (or create a new one). For Pie charts: In the Values panel, add the measure you want to display in the chart. In the Tooltip panel, add all the measures you want to include as additional information in the tooltip. Save the widget. This is the last step for Pie charts. For other charts: In the values add both the data you want to display in the chart and the data you want to include as additional information in the tooltip. If this is a new widget, save the widget first (so that Sisense can assign a widget ID), then open it again. Open the widget script editor. STEP 3: Configure the widget script (only for non-Pie charts) Script example: prism.additionalInfoTooltip(widget, {seriesIndexes: [1,2] ,displayCurrentSelection:true }); In order to use the plugin, copy the script above and adjust the range [startIndex,endIndexstartIndex] to specify which measures should appear in the tooltip. These indexes correspond to the position of the measures in the widget's Values panel, starting from 0. For example, if your widget has three measures and you want to display only the first measure in the chart while showing the other two in the tooltip, set startIndex to 1 and endIndex to 2, i.e., [1,2]. By default, both the main and additional measures appear in the tooltip, with the main ones listed first, followed by the additional ones. To hide the main measures from the tooltip, set displayCurrentSelection to false. Lastly, save the widget script, save the widget, and reload the page. Examples: Pie chart: Cartesian chart:Sort Both Axes In Scatter Chart
In order to sort both axes in the Scatter chart you might need to use the following script under the "Widget Script" level var xOrder = 'asc' //also, this value can be desc var yOrder = 'asc' widget.on('beforeviewloaded', function(scope, args) { var shouldBeExecuted = (order === 'desc' || order === 'asc' ) if (args.widget.type !== 'chart/scatter' || !shouldBeExecuted) { return } var daysOrder = args.options.xAxis.categories.sort(); if (xOrder === 'desc') { daysOrder.reverse() } if (daysOrder.length === args.options.xAxis.categories.length) { args.options.xAxis.categories = daysOrder for (i=0; i<daysOrder.length; i++) { for (k=0; k<args.options.series.length; k++) { for (j=0; j<args.options.series[k].data.length; j++) { if (args.options.series[k].data[j].selectionData[0] === daysOrder[i]) { args.options.series[k].data[j].x = i; } } } } } }) widget.on('beforequery', function(se, ev) { ev.query.metadata.forEach(function(m) { if (m.wpanel && m.wpanel === 'y-axis') { m.jaql.sort = yOrder } }) })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!Automatically Backup Sisense Web Data
Sisense uses MongoDB for storing your Sisense web environment information. This information includes how dashboard and widgets are configured, your system's users and groups, and many other configurations. Since the web environment can regularly change, and may need to be restored, it's useful to keep regular backups of this data. This article shows how to use a program that will perform daily backups of this data: **This article is only relevant Sisense Windows versions 6.7 and above. For Sisense Linux versions, please see Backing Up and Restoring Sisense Download the attached .bat files The MongoBackup.bat file is used for backing up your MongoDB, and the MongoRestore.bat file is used in case you need to restore the backed up information. You can find both of these files here: MongoBackup.bat MongoRestore.bat Create a WriteUser In order to be able to use these scripts, you need to have a WriteUser to your MongoDB. For more information on how to do so, check out our documentation. Change the credentials You can open each of these files in notepad. It will look like this: Change the credentials to those you've just created. Schedule the script The only script you should schedule is the MongoBackup.bat, Since you'll only use MongoRestore.bat in case you need to restore your data. The easiest way to do so is to use the Windows program Task Scheduler. Information on how to schedule a task can be found here: https://support.microsoft.com/en-us/office/create-edit-delete-and-restore-tasks-30346281-30d4-4d6b-a6fa-55beca8d38a3Setting 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.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.
