Data Sources | Sisense Community

Community Feedback
Chapters
Events
Forums
Blogs
KB Docs
Support
Learning
Use Case Gallery

All Posts Discussions Blogs Ideas Questions

Categories

Data Sources | Sisense Community

Knowledge Base Docs

Data Sources

Created Apr 15, 2026

3 members

40 discussions

Guides for how to connect to and manage Data Sources

Data Sources
Migrating Connections from Connection Manager Between Tenants on the Same Instance
Overview When running multiple tenants on the same Sisense instance (self-contained multitenancy), you may need to migrate data source connections from one tenant to another. The Connection Manager stores connections in MongoDB, and each connection is scoped to a specific tenant. Sisense does not provide a built-in UI-based migration for connections between tenants, so migration must be performed via the REST API or directly at the MongoDB level. This article covers the recommended approaches for migrating connections between tenants on the same instance. Prerequisites Admin or Data Admin role on both the source and target tenants. Access to the Sisense REST API (bearer token with appropriate permissions). For MongoDB-level migration: SSH access to the Sisense server and familiarity with MongoDB commands. Sisense version L2023.1 or later (Connection Manager GA). Approach 1: REST API (Recommended) This is the safest and most maintainable approach. It uses the Sisense v2 Connections API to read connections from one tenant and recreate them on another. Step 1 - List connections on the source tenant Generate an API token for a user on the source tenant and retrieve all connections: curl -X GET "https://<your-instance>/api/v2/connections" \ -H "Authorization: Bearer <SOURCE_TENANT_TOKEN>" \ -H "Content-Type: application/json" This returns a JSON array of all connections visible to the authenticated user on that tenant, including their oid , name , provider , and encrypted parameters . Step 2 - Decrypt connection parameters (if needed) Connection parameters (including passwords) are stored encrypted. To retrieve the plaintext values for recreation on the target tenant, use the decryption endpoint: curl -X GET "https://<your-instance>/api/v1/encryption/decrypt?value=<ENCRYPTED_PARAMETERS>" \ -H "Authorization: Bearer <SOURCE_TENANT_TOKEN>" Note: The first decryption call returns all parameters except the password (still encrypted). Run a second decryption call with just the encrypted password value to fully decrypt it. Step 3 - Create connections on the target tenant Generate an API token for a user on the target tenant and create each connection: curl -X POST "https://<your-instance>/api/v2/connections" \ -H "Authorization: Bearer <TARGET_TENANT_TOKEN>" \ -H "Content-Type: application/json" \ -d '{ "name": "My Connection Name", "provider": "PostgreSQL", "parameters": { "Server": "<server-address>", "Database": "<database-name>", "UserName": "<username>", "Password": "<password>" }, "schema": "public", "timeout": 300 }' Repeat for each connection you need to migrate. Step 4 - Update data models to use the new connections After importing data models (via .smodel export/import or API), update each model's datasource to point to the newly created connection on the target tenant: curl -X PATCH "https://<your-instance>/api/v2/datamodels/<MODEL_ID>/datasources/<DATASOURCE_ID>" \ -H "Authorization: Bearer <TARGET_TENANT_TOKEN>" \ -H "Content-Type: application/json" \ -d '{ "connection": "<NEW_CONNECTION_OID>" }' Approach 2: MongoDB collection-level migration For bulk migrations or when API access is impractical, you can export and import the connections collection directly in MongoDB. Step 1 - Access the MongoDB container # Single-node deployment kubectl -n sisense exec sisense-mongod-0 -c mongod-container -it -- bash # Multi-node deployment kubectl -n sisense exec sisense-mongodb-replicaset-0 -c mongod-container -it -- bash Step 2 - Export connections from the source tenant mongoexport --db prismWebDB --collection connections \ --query '{"tenantId": "<SOURCE_TENANT_ID>"}' \ --out /tmp/connections_export.json Step 3 - Modify the exported data Before importing into the target tenant, update the following fields: tenantId - Replace the source tenant ID with the target tenant ID. _id - Remove so MongoDB generates new unique IDs. oid - Remove or regenerate to prevent collisions. cat /tmp/connections_export.json | jq 'del(._id) | del(.oid) | .tenantId = "<TARGET_TENANT_ID>"' > /tmp/connections_import.json Step 4 - Import connections into the target tenant mongoimport --db prismWebDB --collection connections \ /tmp/connections_import.json Step 5 - Restart services kubectl -n sisense rollout restart deployment sisense-management Approach 3: Data model export/import with connection re-mapping This approach is best when migrating complete data models along with their connections. Overview of the workflow Export the data model from the source tenant. Import the data model into the target tenant. Update connection references on the target tenant. Build (ElastiCube) or publish (Live model). Optionally, migrate associated dashboards. Step 1 - Export the data model from the source tenant Option A: Via the UI Log into the source tenant. Navigate to Data page. Click three-dot menu > Export Model. The .smodel file downloads. Option B: Via the REST API GET {{URL}}/api/v2/datamodel-exports/stream/schema?datamodelId=<MODEL_ID> Authorization: Bearer <SOURCE_TENANT_TOKEN> Option C: Via Sisense CLI si elasticubes export -name "Model Name" # Output: /opt/sisense/storage/backups/ Step 2 - Import the data model into the target tenant Option A: Via the UI Log into the target tenant. Navigate to Data page. Click Import Model. Select the .smodel file. Option B: Via the REST API POST {{URL}}/api/v2/datamodel-imports/stream/full Authorization: Bearer <TARGET_TENANT_TOKEN> Content-Type: multipart/form-data # Attach the .smodel file Option C: Via Sisense CLI si elasticubes import -path "/opt/sisense/storage/backups/Model.sdata" -start false Step 3 - Update connection settings on the target tenant Method A: UI (Change Connection) Open the imported model on the Data page. Click on a datasource table. Click three-dot menu > Connection Settings > Change Connection. Select existing connection or create new one with target parameters. Click Test Connection to verify. Click Next, verify table mapping. Repeat for each datasource. Method B: REST API (post-import patching) Step 3B.1 - Get the model schema: GET {{URL}}/api/v2/datamodels/<DATAMODEL_ID>/schema Authorization: Bearer <TARGET_TENANT_TOKEN> Step 3B.2 - Create a connection on target: POST {{URL}}/api/v2/connections Authorization: Bearer <TARGET_TENANT_TOKEN> Content-Type: application/json { "name": "Production PostgreSQL", "provider": "PostgreSQL", "parameters": { "Server": "prod-db.example.com", "Port": "5432", "Database": "analytics", "UserName": "sisense_user", "Password": "your_password" }, "schema": "public", "timeout": 300 } Step 3B.3 - Update each dataset: PATCH {{URL}}/api/v2/datamodels/<DATAMODEL_ID>/schema/datasets/<DATASET_ID> Authorization: Bearer <TARGET_TENANT_TOKEN> Content-Type: application/json { "connection": "<NEW_CONNECTION_OID>" } Method C: Pre-import .smodel modification Before importing, modify the .smodel JSON file. Original (encrypted): "connection": { "id": "507f1f77bcf86cd799439011", "provider": "PostgreSQL", "parameters": "qkSH7Ktg...(encrypted)...", "schema": "public", "timeout": 300, "protectedParameters": ["Password"] } Modified (plaintext): "connection": { "id": "", "provider": "PostgreSQL", "Parameters": { "Server": "prod-db.example.com", "Port": "5432", "Database": "analytics", "UserName": "sisense_user", "Password": "your_password" }, "schema": "public", "timeout": 300, "protectedParameters": [] } Key changes: empty id, uppercase Parameters with plaintext, empty protectedParameters. Step 4 - Build or publish the model For ElastiCubes: POST {{URL}}/api/v2/builds Authorization: Bearer <TARGET_TENANT_TOKEN> {"datamodelId": "<ID>", "buildType": "full", "rowLimit": 0} For Live models: POST {{URL}}/api/v2/builds Authorization: Bearer <TARGET_TENANT_TOKEN> {"datamodelId": "<ID>", "buildType": "publish", "rowLimit": 0} Step 5 - Migrate associated dashboards (optional) # Export GET {{URL}}/api/v1/dashboards/<DASHBOARD_ID>/export/dash # Import POST {{URL}}/api/v1/dashboards/import End-to-End Example: Migrating "Sales Analytics" from dev to prod tenant Environment: Sisense instance at https://bi.acme.com. Source tenant: acme-dev. Target tenant: acme-prod. Model: Sales Analytics (PostgreSQL, 3 tables). Example: Method A (UI) Export from acme-dev: Data page > Sales Analytics > Export Model > downloads .smodel file. Import to acme-prod: Data page > Import Model > select file. Open model - see red connection errors on orders, customers, products tables. Click orders table > Connection Settings > Change Connection. Enter: Server=prod-db.internal.acme.com, User=sisense_etl, Password=Pr0d_S3cur3_P@ss!, Database=sales_dwh. Click Test Connection - success. Click Next - verify tables. Apply to all tables from same source - Yes. Click Build > Full Build. Build completes in ~4 minutes. Done. Example: Method B (REST API) Step 1 - Get model ID: curl -s -X GET "https://bi.acme.com/api/v2/datamodels/schema" \ -H "Authorization: Bearer <DEV_TOKEN>" | jq '.[] | select(.title == "Sales Analytics") | .oid' # Returns: "64b2c3d4e5f6a7b8c9d0e1f2" Step 2 - Export model: curl -s -X GET "https://bi.acme.com/api/v2/datamodel-exports/stream/schema?datamodelId=64b2c3d4e5f6a7b8c9d0e1f2" \ -H "Authorization: Bearer <DEV_TOKEN>" -o "Sales_Analytics.smodel" Step 3 - Import to prod: curl -s -X POST "https://bi.acme.com/api/v2/datamodel-imports/stream/full" \ -H "Authorization: Bearer <PROD_TOKEN>" -F "file=@Sales_Analytics.smodel" # Returns: {"oid": "65c3d4e5f6a7b8c9d0e1f2a3", "title": "Sales Analytics"} Step 4 - Create prod connection: curl -s -X POST "https://bi.acme.com/api/v2/connections" \ -H "Authorization: Bearer <PROD_TOKEN>" \ -H "Content-Type: application/json" \ -d '{"name":"Prod PostgreSQL - Sales","provider":"PostgreSQL","parameters":{"Server":"prod-db.internal.acme.com","Port":"5432","Database":"sales_dwh","UserName":"sisense_etl","Password":"Pr0d_S3cur3_P@ss!"},"schema":"public","timeout":300}' # Returns: {"oid": "conn_new_prod_pg_67890", ...} Step 5 - Update all datasets: for DS in ds_001_orders ds_002_customers ds_003_products; do curl -s -X PATCH "https://bi.acme.com/api/v2/datamodels/65c3d4e5f6a7b8c9d0e1f2a3/schema/datasets/$DS" \ -H "Authorization: Bearer <PROD_TOKEN>" \ -H "Content-Type: application/json" \ -d '{"connection":"conn_new_prod_pg_67890"}' done Step 6 - Build: curl -s -X POST "https://bi.acme.com/api/v2/builds" \ -H "Authorization: Bearer <PROD_TOKEN>" \ -H "Content-Type: application/json" \ -d '{"datamodelId":"65c3d4e5f6a7b8c9d0e1f2a3","buildType":"full","rowLimit":0}' # Returns: {"status": "building"} Step 7 - Verify build: curl -s -X GET "https://bi.acme.com/api/v2/builds?datamodelId=65c3d4e5f6a7b8c9d0e1f2a3&sort=-startTime&limit=1" \ -H "Authorization: Bearer <PROD_TOKEN>" # Returns: [{"status": "done", "rowCount": 1458293}] Example: Method C (Pre-import modification) Step 1 - Export from dev (same as Method B Step 2). Step 2 - Run transformation script: import json with open("Sales_Analytics.smodel", "r") as f: model = json.load(f) PROD_CONN = {"Server":"prod-db.internal.acme.com","Port":"5432", "Database":"sales_dwh","UserName":"sisense_etl", "Password":"Pr0d_S3cur3_P@ss!"} for ds in model.get("datasets", []): if "connection" in ds: ds["connection"] = { "id": "", "provider": ds["connection"]["provider"], "Parameters": PROD_CONN, "schema": ds["connection"].get("schema","public"), "timeout": 300, "protectedParameters": [], "uiParams": {}, "globalTableConfigOptions": {} } with open("Sales_Analytics_prod.smodel", "w") as f: json.dump(model, f, indent=2) Step 3 - Import modified file: curl -s -X POST "https://bi.acme.com/api/v2/datamodel-imports/stream/full" \ -H "Authorization: Bearer <PROD_TOKEN>" -F "file=@Sales_Analytics_prod.smodel" # Connection auto-created, model imported with correct prod settings Step 4 - Build: curl -s -X POST "https://bi.acme.com/api/v2/builds" \ -H "Authorization: Bearer <PROD_TOKEN>" \ -H "Content-Type: application/json" \ -d '{"datamodelId":"65c3d4e5f6a7b8c9d0e1f2a3","buildType":"full","rowLimit":0}' Step 5 - Delete the modified file (contains plaintext password): rm Sales_Analytics_prod.smodel Important Considerations Connections are scoped per tenant - Tenant A connections are not visible from Tenant B. Starting with L2025.1, Connection Manager supports shared/deduplicated connections. Passwords are encrypted with instance-level keys - valid when moving between tenants on same server. OAuth connections (BigQuery, Salesforce) may require re-authentication on target tenant. SSH tunnel configs are instance-level and shared across tenants. Use GET /api/v2/connections/{id}/getAllDependencies to check before deleting source connections. Verification Log into target tenant > Data > Connection Manager to confirm connections appear. Test each connection or run a build. Verify dashboards load data correctly. Troubleshooting Connection not visible: tenantId not updated in MongoDB migration. Cannot establish connection: credentials not properly handled - recreate via UI. Duplicate names: rename before/after import. Models pointing to old connections: use Change Connection or PATCH via API. Related Resources Sisense REST API - Connections: https://sisense.dev/guides/restApi/ Exporting and Importing Data Models: https://docs.sisense.com/win/SisenseWin/exporting-and-importing-models.htm Data Source Connection Management: https://docs.sisense.com/main/SisenseLinux/data-source-connection-management.htm Sisense Multitenancy Overview: https://docs.sisense.com/main/SisenseLinux/sisense-multitenancy.htm
Anton DyachenkoPosted 1 month ago
0
Data Sources
Windows | MySQL 8.4 Connection Failures in Desktop ElastiCube Manager
Problem When attempting to connect to or build an existing ElastiCube using MySQL version 8.4 within the legacy Desktop ElastiCube Manager (ECM) , the process fails. Users may experience symptoms such as: The initial database schema list loads successfully, but clicking 'OK' triggers an error. Partial builds where the first table succeeds, but subsequent tables fail with an "Authentication failed" error. Cause The root cause is a technology mismatch between the legacy desktop application and newer database security standards: Connector Limitations: The Desktop ElastiCube Manager relies entirely on legacy CLR (.NET) data connectors . The built-in CLR connector framework does not support the authentication requirements and updates introduced in MySQL 8.4. Because the MySQL CLR connector is deprecated and will no longer receive updates, it cannot be patched to support MySQL 8.4. Authentication Protocol Clashes: MySQL 8.4 disables legacy native password mechanisms by default, shifting entirely to modern, secure authentication. The legacy CLR framework natively expects older behaviors, resulting in a failure to communicate. Desktop Limitations: Desktop ECM natively lacks support for modern Java (JDBC) connectors. Solution: Migrate to Web ElastiCube Manager To resolve this issue and preserve your MySQL 8.4 architecture, your data models must be migrated to the Web ElastiCube Manager (Web ECM) , which actively leverages modern, Java-based connectors capable of handling modern MySQL protocol requirements. Step-by-Step Migration Guide Follow these steps in the Web ElastiCube Manager (accessible via your browser under the Data tab) to migrate your dataset connections from legacy CLR to Java/JDBC connectors: Log into the Sisense Web Application and navigate to the Data tab. Open the affected ElastiCube model. Locate the MySQL dataset you need to update, open its three-dot menu , and select Change Connection . Update Connection Parameters: If your connection parameters are already visible, simply verify them. If the fields are blank, re-enter your MySQL 8.4 server credentials, hostname, and database configurations to re-initialize the connection via the Java driver. Re-select or re-add the existing tables and click Next . Save your changes and initiate an ElastiCube build to verify that data ingestion completes without authentication failures. Recommendation: Always test this connection migration workflow on a test data model or lower environment before applying changes to business-critical production dashboards. Conclusion To successfully resolve this blocker and ensure long-term stability, workflows must be transitioned to the Web ElastiCube Manager (Web ECM). Web ECM is designed to utilize modern, Java-based (JDBC) connectors that natively support MySQL 8.4, allowing datasets to connect, retrieve tables, and build successfully.
Anton DyachenkoPosted 2 months ago
0
Data Sources
Quickbooks Online: Customizing Table Schemas
Connecting to Quickbooks online. Begin with downloading the connector. Create an app in Quickbooks online environment Creating an App You can follow the steps below to create an app and obtain the OAuth client credentials, the consumer key and consumer secret. You will need to create an Intuit developer account if you do not already have one. Log in to http://developer.intuit.com . Click My Apps > Create New App > Select APIs . Select the Accounting API . On the Settings tab, define the Launch URL.If you are making a desktop application, set Launch URL to http://localhost/.For a Web application, set Launch URL to a page you would like the user to be returned to after they have granted your application permissions. Once you have created the app, you will be redirected to a page with information about your app. The Development tab contains your Sandbox credentials and the Production tab contains credentials for use with a production account. The consumer key and consumer secret are displayed on the Keys tab . Make sure in the app you set the call back string in the Quickbooks online app to local host. You should be able to do this on the tab next to 'Keys' Connecting from Sisense. Open the connector and enter the following connection string jdbc:quickbooksonline:CompanyId=xxxxxxxxxxxxxx;CallbackURL= http://localhost/;InitiateOAuth=GETANDREFRESH;Timeout=0 ; **** To get the company ID, log into your Quickbooks online instance and press the following Keys. PC: CTRL + ALT + ? MAC: CTRL + Option + ? This will load a pop up screen with your company ID. Make sure to delete all the spaces in the ID when putting it into the Connection String. **** Then click connect. This should open a browser window for the user to verify credentials for the connection. Once complete you should see all the available tables. Now if the tables you are looking for are not coming up, then you need to create the schema files for those tables. Begin by downloading DB visualizer (download the version for your operating system with Java VM). Before using DB Visualizer, you will need to modify the connection string to work in DB Visualizer by adding the RTK Key. The RTK is the key used for the Cdata connector. To get the RPK key, Go to the following file directory C:\ProgramData\Sisense\DataConnectors\QuickBooks Online\Sisense.QuickBooksOnline.JVM.1.0.17114.53.0.0 Open up the description file and grab the RTK key. You are going to need this to add to the connection string in DB Visualizer. Once DB Visualizer is installed, begin by going to tools>Driver Manager. Select the plus sign in the top left corner. A new driver will pop up in the list with no name and the driver settings will be blank. Name the driver Quickbooks Online and add the following connection string into the URL Format box. jdbc :quickbooksonline : CompanyId =xxxxxxxxxxxxxx; CallbackURL = http://localhost/ ; InitiateOAuth =GETANDREFRESH; Timeout =0; RTK=XXXXXXXXXXXXXXXXXXXXXX; Location=C:\LocationFolder The parameters of the Connection string are outlined below. Company ID - The QBO company ID. Follow the instructions CallbackURL- The OAuth callback URL to return to when authenticating. This value must match the callback URL you specify in your app settings. InitiateOAuth-Set this property to initiate the process to obtain or refresh the OAuth access token when you connect. Timeout - The value in seconds until the timeout error is thrown, canceling the operation. RTK- Needed to use the Cdata Connector Location - Where DB visualizer will save and look for schema files Once the connection string has been created, you must add the driver file to the driver manager. Click on the folder icon on the right hand side and select the JAR file for Cdata in the following directory. C:\Program Files\Sisense\DataConnectors\JVMContainer\Connectors\QuickBooksOnline\lib The driver should autopopulate the class and you should see a check mark appear next to the driver name. Once you are connected, you should be able to access the stored procedures under quickbooks online connector. In the left hand menu, expand the Quicbooks connector untill you see tables, views and procedures, then expand procedures. You need to run the procedure that responds to the table you want. Open the SQL tab (SQL Commander> New SQL Commander) and type the syntax exec <ProcedureName> . Once you run it, it creates a schema file that is added to the folder you specified in the Location parameter in the connection string. Best practices dictates placing the .rsd file into the lib folder of the connector. This folder can be found in the following directory. C:\Program Files\Sisense\DataConnectors\JVMContainer\Connectors\QuickBooksOnline\lib When you run a Stored procedure, it will create only a single schema file. Run each of the stored procedures you need. Then, move all the resulting schema files to the lib folder for the Quick books directory. **** ONLY RUN SCHEMA FILES THAT CREATE A REPORT. DO NOT RUN PROCEDURES THAT DO NOT CREATE A TABLE AS ONE DEAUTHENTICATES THE AUTH TOKEN. *** Next, restart the JVM service, when the connector appears for Quickbooks you will need to change the connection string to include the final location of the RSD files. jdbc :quickbooksonline : CompanyId =xxxxxxxxxxxxxx; CallbackURL = http://localhost/ ; InitiateOAuth =GETANDREFRESH; Timeout =0; Location= C:\Program Files\Sisense\DataConnectors\JVMContainer\Connectors\QuickBooksOnline\lib Finally, when you connect you will see the new table(s) along with the original tables when adding data. Customizing the Schema Table Range Once you have your New schema file added and have added and built the table in Sisense, you may notice that the table does not have all the information you need. For example, it can be limited to a specific date range where it is only receiving data from the current year. To correct this, you can specify parameter values when executing the Procedure in DB Visualizer. Simply list them after the Procedure name and specify the values. Separate the column names by a comma. In this example we set the start date and end date to capture data from 2016 and always grab future dates. The year 2030 was picked as this is not dynamic and will not have to be changed for a long time. To see which parameter values you can pass in to the table schema, click on the procedure and look the column names. Finally, run the Procedure which will create a new schema that needs to replace the previous schema in the location of the RSD files. You'll notice when you open the RSD file in notepad, there is a default value added to the specified parameters.
intapiuserPosted 3 years ago • Last reply 9 months ago
1
Data Sources
How to Set Up a Custom Generic JDBC Connector to Imp
Sisense provides a native connector for MongoDB, which uses Insightsoftware’s Simba MongoDB JDBC Driver. However, this driver does not officially support Amazon DocumentDB, and using it may result in compatibility issues. Amazon DocumentDB is not a fully compatible MongoDB implementation—it supports only a subset of MongoDB APIs and features. As a result, the Simba driver may rely on commands or behaviors that DocumentDB does not implement. To address this, Sisense offers a certified connector: the CData JDBC Driver for MongoDB, which supports Amazon DocumentDB. This article explains how to configure a custom Generic JDBC connector in Sisense using the CData JDBC Driver for MongoDB. Step-by-Step Guide: Download the Driver Download the CData JDBC Driver for MongoDB from Sisense Certified Connectors site Install the Driver on Your Local Machine Extract the downloaded .zip file. Run "java -jar setup.jar" or "java -jar setup.jar -console" . If Java is not installed, please install the Java Runtime Environment (JRE), or run the installer on a machine where JRE or JDK is already available. The default installation path of version 2025 in the Windows environment is: C:\Program Files\CData\CData JDBC Driver for MongoDB 2025”. Configure the Connector in Sisense Log in to Sisense as a user with Admin privileges. Open Configuration Manager: Admin > Server & Hardware > System Management > Configuration Scroll to the bottom and click Manage Connectors. In the left pane, click +JDBC Connector. Fill in the required fields on the Create JDBC Connector page: Connector ID: CData_MongoDB Display Name: CData MongoDB Class Name: cdata.jdbc.mongodb.MongoDBDriver Upload JAR File: Upload cdata.jdbc.mongodb.jar from the /lib directory of the installed driver, e.g.: C:\Program Files\CData\CData JDBC Driver for MongoDB 2025\lib\cdata.jdbc.mongodb.jar Click Create to register the connector. Conclusion Once these steps are completed, the CData MongoDB connector will be available in your Sisense environment. To establish a connection to Amazon DocumentDB, include the following parameters in your connection string: UseSSL=true;UseFindAPI=true For additional details and connection instructions, refer to the official CData documentation: Connecting to an Amazon DocumentDB Cluster If your Sisense server is hosted in our managed cloud, please review the SSH Tunnel section in our documentation: Cloud Connectivity . References/Related Content https://www.cdata.com/solutions/bi/sisense/ https://cdn.cdata.com/help/DGM/jdbc/pg_connectionj.htm#connecting-to-an-amazon-documentdb-cluster https://cdn.cdata.com/help/DGM/jdbc/RSBMongodb_p_UseFindAPI.htm https://docs.sisense.com/main/SisenseLinux/cloud-connectivity.htm
Eiji OzawaPosted 10 months ago
0
Data Sources
SharePoint Online Excel to Sisense Linux ElastiCube via Custom JDBC
The CData JDBC Driver for Microsoft SharePoint Excel supports retrieving Excel data from SharePoint On-Premises via the REST API and the OData API introduced in SharePoint 2013. It is compatible with Microsoft SharePoint 2013 and 2016. For newer environments such as Microsoft SharePoint Online, the appropriate driver is the CData JDBC Driver for Microsoft Excel Online. Step-by-Step Guide: Download the Driver Download the CData JDBC Driver for Microsoft Excel Online from Sisense Certified Connectors site Install the Driver on Your Local Machine Extract the downloaded .zip file. Run "java -jar setup.jar" or "java -jar setup.jar -console" . If Java is not installed, please install the Java Runtime Environment (JRE), or run the installer on a machine where JRE or JDK is already available. The default installation path of version 2025 in the Windows environment is: C:\Program Files\CData\CData JDBC Driver for Microsoft Excel Online 2025 Configure the Connector in Sisense Log in to Sisense as a user with Admin privileges. Open Configuration Manager: Admin > Server & Hardware > System Management > Configuration Scroll to the bottom and click Manage Connectors . In the left pane, click +JDBC Connector . Fill in the required fields on the Create JDBC Connector page: Connector ID : Excel_Online Display Name : Excel Online Class Name : cdata.jdbc.excelonline.ExcelOnlineDriver Upload JAR File : Upload cdata.jdbc.excelonline.jar from the /lib directory of the installed driver, e.g.: C:\Program Files\CData\CData JDBC Driver for Microsoft Excel Online 2025\lib\cdata.jdbc.excelonline.jar Click "create" to register the connector. Conclusion Once these steps are completed, the Excel Online connector will be available in your Sisense environment. To establish a connection, you must include the following parameter in your connection string: SharepointURL =https://mysite.sharepoint.com/ For additional required parameters and configuration details, please refer to the official CData JDBC Driver documentation: CData JDBC Driver for Microsoft Excel Online: Establishing a Connection . References/Related Content https://www.cdata.com/solutions/bi/sisense/ https://docs.sisense.com/main/SisenseLinux/connecting-to-sharepoint-excel-services.htm https://docs.sisense.com/main/SisenseLinux/deploying-a-custom-connector.htm
Eiji OzawaPosted 10 months ago
0
Data Sources
Snowflake key-pair authentication fails when private key is owned by root [Linux]
Step-by-Step Guide Verify ownership and permissions: sudo ls -l /opt/sisense/storage/ssh_key Example incorrect output - root user is owner: -rw-r--r-- 1 root root 1785 Jun 5 23:24 rsa_key.privsisense Change the file owner and group to the Sisense installation user (with UID 1000 by default): sudo chown sisense:sisense /opt/sisense/storage/ssh_key/keyfile Adjust permissions to allow Sisense read access: sudo chmod 644 /opt/sisense/storage/ssh_key/rsa_key.privsisense - 640 permissions are also acceptable if your security policy is stricter. Restart the Query Service: kubectl -n sisense rollout restart deployment query Re-test the Snowflake connectio n In the Sisense data model → Connection Settings → Change Connection → leave existing settings and click Done. - A successful validation confirms the fix. Conclusion The Snowflake key-pair workflow depends on the Sisense services being able to read the private key. Ensuring that the key file is owned by the Sisense installation user—and not root—with readable permissions resolves the authentication failure without regenerating keys. Related Content Sisense Docs → Connecting to Snowflake | Key Pair Authentication
CKenningtonPosted 1 year ago
0
Data Sources
How to resolve build failure due to timeout with CData JDBC Driver for REST [Linux]
Step-by-Step Guide: The build error due to a timeout of the REST connector occurs when the executed REST API does not return any response within the configured timeout. It can be set in the connection string. If the timeout option is not set in the connection string, the default value is 60 seconds. You can set the default timeout value in the created Generic JDBC connector of the CData JDBC Driver for REST with the following steps. Log in to Sisense with an Admin role user Open Configuration Manager, click Admin > Server & Hardware > System Management > Configuration In the Configuration Manager, click the Manage Connectors link at the bottom of the page Select your Generic JDBC REST connector in the left pane Expand the Advanced Configuration in the right pane Add the timeout parameter in the Connection string parameters in the right pane : Example: timeout=300; Click the Update button If you don’t want to extend the default timeout value, you can add the timeout option in the connection string of each connection. Note: To set the timeout value, please use a third-party tool to execute the request and set a sufficient time based on how long it takes to perform the REST request. Conclusion: By setting the timeout value to a sufficient amount of time for getting a result from the configured REST request, it prevents the build failure due to the timeout error. References/Related Content https://cdn.cdata.com/help/DWK/jdbc/RSBREST_p_Timeout.htm 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.
Eiji OzawaPosted 1 year ago
0
Data Sources
How to resolve when the build fails with "Execution Timeout Expired"
Introduction: This article provides guidance for extending the execution timeout value in the DotNet SQL Server connector configuration to resolve the build failure with "Execution Timeout Expired. The timeout period elapsed prior to completion of the operation, or the server is not responding." Step-by-Step Guide: The “Execution Timeout Expired” error occurs when a query takes too long to execute on the data source side. The DotNet SQL Server connector sets the timeout value to 300 seconds as the default. Old releases such as Sisense 7.4 set the timeout value to 60 seconds as the default. You can extend the timeout value with the following steps. Stop Sisense.CLRConnectorsContainer Windows Service Open “C:\Program Files\Sisense\DataConnectors\DotNetContainer\Connectors\MS-SQL\Sisense.Connectors.MsSqlConnector.dll.config” with a text editor such as Notepad Find the Timeout parameter like the one below in the file: <add key="Timeout" value="300" / > Update the value to a sufficient amount of time for executing the failed query Save the file Start Sisense.CLRConnectorsContainer Windows Service Conclusion: By setting the timeout value to a sufficient amount of time for the query to be executed on SQL Server and receive results, it prevents the build failure due to the "Execution Timeout Expired” error. 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.
Eiji OzawaPosted 1 year ago
0
Data Sources
Resolving model export limitations in Sisense [Linux]
Step-by-Step Guide: Starting soon, Snowflake will require Key Pair authentication for connections, and there's an important distinction in how Sisense and Snowflake currently recommend generating these keys. Discrepancy in Key Pair Recommendations Sisense Recommendation (Legacy) Sisense has traditionally supported v1 key pairs : openssl genrsa 2048 | openssl pkcs8 -topk8 -v1 'V1_ALGORITHM' -inform PEM -out rsa_key_1.p8 Snowflake Recommendation (Preferred) Snowflake recommends using v2 key pairs : openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 des3 -inform PEM -out rsa_key.p8 ---------------------------------------------------------- Solution: Use v2 Keys with Sisense 2025.2+ Good news: Sisense version 2025.2 introduces support for v2 key pairs , aligning with Snowflake’s preferred authentication mechanism. Step-by-Step Migration Guide Upgrade to Sisense 2025.2 or Later Ensure your environment is running version 2025.2 or newer . Check out the Sisense 2025.2 Release Notes (link to be added) for detailed compatibility and feature info. Generate v2 Key Pairs Run this command using openssl: openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 des3 -inform PEM -out rsa_key.p8 This will create a secure v2-compatible private key file (rsa_key.p8). Configure Your Snowflake Connection in Sisense In Sisense, go to Admin > Data > Connections . Edit or create your Snowflake connection. Upload the rsa_key.p8 file when setting up Key Pair authentication . Ensure that the public key has been registered in Snowflake under the corresponding user account. Troubleshooting Tips Issue with Key Pair Authentication: Ensure your version of Sisense is 2025.2 or later. Reverting to v1 key pairs is a temporary solution if your current version is below 2025.2. Error Messages during Setup: Verify that the key pair was generated following the exact command syntax and options as per Snowflake's recommendation. Additional Information It's advised to periodically check the Sisense documentation for any updates or changes in key pair authentication support. References/Related Content: Sisense release notes Snowflake documentation 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.
Ihor YokhymPosted 1 year ago
0
Data Sources
How to connect to database directly from Sisense server using SQLLine

Symptoms You need to connect to database, however connection is not going through. You have already check the hostname, username, password and everything seems to be correct. You have whitelisted the database address, hostname, etc. however not sure if the the rules are working properly. Diagnosis In order to check if the necessary database can be reached from Sisense server you may connect to it using jdbc .jar file directly from Sisense server (omitting UI). This was you will be able to make sure the whitelisting works properly and the issue is with connector itself. Solution 1)Download jdbc .jar file for database in question from https://www.cdata.com/solutions/bi/sisense/ (we will use Redshift in this example) 2)Put the .jar file into folder in File Manager. We have create a new 'redshift' folder inside 'data' folder 3)Login to Sisense server 4)Make sure java and SQLLine are installed on Sisense server. If you are doing this for the first time you will need to install them. You may use 'wget' commands for this 5)Connect to SQLLine by using the following command: java -cp <sqlline-jar-file>:<jdbc-driver-jar-file> sqlline.SqlLine Replace <sqlline-jar-file> with the path to the SQLLine JAR file and <jdbc-driver-jar-file> with the path to your JDBC driver JAR file. In our example, we have downloaded SQLLine to the folder we were in. The path to the File manager in Sisense is '/opt/sisense/storage'. Therefore, the connection string for us looked like this: java -cp sqlline.jar:/opt/sisense/storage/data/redshift/cdata.jdbc.redshift.jar sqlline.SqlLine 6)Once SQLLine is running, connect to your database using the !connect command. General syntax is the following: !connect jdbc:<database-url> <username> <password> Following CDATA redshift connection string requirements, in our example the syntax looked like: !connect jdbc:redshift://database_url:port_number/database_name user_name user_password When you are downloading the CDATA jdbc connector, please open the docs section for that connector to check the right connection string format. If connection is established you will be able to use SQL queries to return the data. If connection is refused, please check the database address whitelisting again and make sure all the necessary outbound/inbound rules are setup.
nataliia_khPosted 1 year ago
0
Data Sources
How to create JDBC connector on a new Framework

Previously in Linux, Sisense were using so called "Old Framework" for connectors - this means connectors from Windows that were ported to Linux environment. However now Sisense developing the connector designed for Linux specifically. Some portion of connectors already using the new framework i.e if the connector is enabled - this means the New Framework, disabling the connector will enable the Old Framework, BTW switching the connector framework is the technique to troubleshoot the issue. But the JDBC connectors still using the Old connectors framework. Starting from version L2022.0 you can create the JDBC connector on a New Framework. Important to note! The provided solution is not an official feature yet, and currently in BETA, thus, might have issues. The solution will require maintenance and proper testing on your side, we also highly recommend running on a staging environment before upgrading or implementing it on production environments. To create the connector: 1. Download the needed connector from CDATA (Sisense official partner) https://www.cdata.com/solutions/bi/sisense/ 2. Install the connector on your local PC (not on Sisense server) 3. The connector will be installed into C:\Program Files\CData\DRIVER_NAME 4. Open Configuration Manager 5. Scroll down to the bottom of the page 6. Click on Manage Connectors 7. Create JDBC connector 8. Enable connector 9. Give it the required name in the Display name (this will be the name of the connector in the list of connectors) 10. Upload the connector that you installed in the Step 2. Needed *.jar file located in the lib older of your driver C:\Program Files\CData\DRIVER_NAME\ lib 11. Provide the class name (which can be found in the documentation of a connector on the CDATA page) 12. Save settings. Now the connector is available in the list of connectors
intapiuserPosted 3 years ago
0
Data Sources
Developing Custom REST Connectors

Sisense lets you import data from multiple sources using built-in connectors or by a customized connector. Sisense custom REST connectors framework enable you to program your own connectors to popular data sources which support REST services, to import data directly into the ElastiCube Manager. Custom REST connectors provide Sisense with the end points and authentication information that allows Sisense to return the requested data. To do so, you create a connector configuration file in JSON for each unique source. Data connectors overview – Native vs. Custom REST, when to use each kind? Creating a Custom REST connector workflow: Retrieving RESTful Credentials, Creating configuration files and defining them. Troubleshooting common issues. Additional resources: Example of a connector that uses CSV results as part of the connector The Sisense connections list
intapiuserPosted 3 years ago
0