After upgrading to Remote Engine 2.13.13, when enabling the option to execute a job from Studio on a remote engine, the process fails due to SSL and PKCS-related errors.

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Resolution

SSL Configuration for Talend Studio to Connect with Remote Engine

1. Retain the Keystore and Truststore Passwords Generated During Installation

   During the installation of Talend Remote Engine, SSL credentials are automatically generated. To retrieve the keystore password, execute the following command:

   cat /opt/TalendRemoteEngine/bin/sysenv

   and locate the line

   TMC_ENGINE_JOB_SERVER_SSL_KEY_STORE_PASSWORD=<PASSWORD>

2. Required Keystore and Truststore Files

   The following files are necessary for secure communication between Talend Studio and the Remote Engine:

   /opt/TalendRemoteEngine/etc/keystores/jobserver-client-keystore.p12
   /opt/TalendRemoteEngine/etc/keystores/jobserver-client-truststore.p12 (Truststore file added with RE 2.13.13)

   Transfer these files to your Talend Studio workstation and store them in a dedicated folder.

3. Configure Talend Studio to Use SSL

   Edit the Studio startup configuration file, depending on your operating system:

   • For Linux (x86_64): studio/Talend-Studio-linux-gtk-x86_64.ini
   • For ARM architecture: studio/Talend-Studio-gtk-aarch64.ini  
   • For Windows: Talend-Studio-win-x86_64.ini
4. Add the following JVM options to the configuration file, and adjust the file paths and password values accordingly:

       -Dorg.talend.remote.client.ssl.force=true
       -Dorg.talend.remote.client.ssl.keyStore=path_to_keystore/jobserver-client-keystore.p12
       -Dorg.talend.remote.client.ssl.keyStoreType=PKCS12
       -Dorg.talend.remote.client.ssl.keyStorePassword=<password_from_step_1>
       -Dorg.talend.remote.client.ssl.keyPassword=<password_from_step_1><
       -Dorg.talend.remote.client.ssl.trustStore=path_to_truststore/jobserver-client-truststore.p12
       -Dorg.talend.remote.client.ssl.trustStoreType=PKCS12
       -Dorg.talend.remote.client.ssl.trustStorePassword=<password_from_step_1>
       -Dorg.talend.remote.client.ssl.disablePeerTrust=false
       -Dorg.talend.remote.client.ssl.enabled.protocols=TLSv1.2,TLSv1.3
      

Cause 

Talend Remote Engine enforces SSL communication by default, ensuring that all interactions with the engine are encrypted. If Studio does not have the appropriate certificates installed, it will be unable to establish a secure connection with the Remote Engine.

Environment

• Talend Studio 
• Talend Cloud 

According to the Qlik Cloud Platform document, Qlik leverages our cloud providers for backups to maintain copies of content for 30 days.

Can I restore one of those backups?

No, those backups cannot be restored. They are kept for disaster recovery purposes (see Disaster recovery/backup and recovery) and encompass entire regions. 

It's therefore not possible to recover a tenant's previous stage.

It's the tenant admin's responsibility to make sure that copies of the content are regularly backed up on any platform of choice for easy restoration. See Qlik Cloud Administration: Backup Responsibilities for details. 

Environment

• Qlik Cloud Analytics

The purpose of this article is to provide details about enabling Full Load Passthru filter in Qlik Cloud Data Integration (QCDI) and get the selected data from the source during the initial load of the Landing or Replication Tasks.

Enable Passthrough filter in the Qlik Data Movement Gateway  server configuration

1. Navigate to the path /opt/qlik/gateway/movement/bin on the Qlik Data Movement Gateway Linux server
2. Edit the file repctl.cfg
3. Set the parameter enable_passthrough_filter to true and save the file
4. Restart the Gateway server using the service repagent restart command

Build the filter in the Qlik Cloud Data Integration tenant

1. Log in to our QCDI tenant
2. Open the Landing Task in the project.
3. Click on the filter button (top right corner above the table details)
   
   
   
   Syntax:
   
   --filter: filter_condition
   
   Example One:
   
   --filter: id > 2
   
   
   
   Example Two:
   
   --filter: id between 1 and 2
   
   
   
   
4. We can add any valid condition using the syntax supported by the source Database and the tool internally constructs the select statement using the condition to filter the data from the source.
5. Once the filter is added, prepare the landing task and then do a Reload of the table to validate the results
6. Please note that the filter is at the table level and every table can have its own filter condition for a column specific to that table.

The information in this article is provided as-is and will be used at your discretion. Depending on the tool(s) used, customization(s), and/or other factors, ongoing support on the solution below may not be provided by Qlik Support.

Environment

• Qlik Cloud Data Integration

Can a Talend Remote Engine be automatically unassigned from a cluster after a license change to convert it to a standalone Remote Engine?

No. Licensing and engine configurations operate on separate layers within Qlik Talend Cloud.  A change in licensing terms, conditions, or token balances will not automatically convert or modify a Talend Remote Engine Cluster into a single standalone Remote Engine.

The Remote Engine may have been removed following a user's action, which can be audited using the Talend Cloud Audit Logs.

Review the logs for the EventCategory - Remote Engine Cluster and the removeRemoteEngine operator. See Talend Cloud audit log contents | EventCategory - Remote Engine Cluster for details. 

Environment

• Qlik Talend Cloud

When connecting to Snowflake through PrivateLink, use the PrivateLink hostname returned by SYSTEM$GET_PRIVATELINK_COFIG() instead of the public Snowflake hostname.

If the Snowflake account was configured for PrivateLink with a different hostname, the following error will be logged:

Snowflake connection failed:-(java.lang.RuntimeException) net.snowflake.client.jdbc.SnowflakeSQLException: JDBC driver encountered communication error. Message: HTTP status=404.

The error is observed specifically after upgrading Qlik Talend Studio to patch R2026-01/02/03.

Cause

This is due to Enforcement of privatelink-only access, as documented in Enforcement of privatelink-only access | docs.snowflake.com.

Snowflake JDBC URLs require the region and privatelink components when connecting to a Snowflake account configured with PrivateLink (a private connectivity feature across AWS, Azure, or GCP), as this setup routes traffic through a secure, private endpoint through a proxy instead of the public internet.

Example: 

jdbc:snowflake://<account>,<region>.privatelink.snowflakecomputing.com/?warehouse=WH1&db=DB1&role=ROLE1

Talend Studio Metadata connection:

The PrivateLink URL: https://<account>.<region>.privatelink.snowflakecomputing.com resolved to a private endpoint IP via VPC DNS.

Snowflake changed PrivateLink endpoint-discovery behaviour in the 2023_04 behaviour change release by expanding the SYSTEM$GET_PRIVATELINK_CONFIG and SYSTEM$ALLOWLIST_PRIVATELINK output, and later highlighted simplified DNS management for AWS PrivateLink in the 8.3 release notes.

Refer to January 22-23, 2024 — 8.3 Release Notes | docs.snowflake.com for details. 

Environment

• Qlik Talend Studio

After the Talend Remote Engine goes down, the Remote Engine logs repeatedly show the same message in TalendRemoteEngine/data/log/karaf.log:

org.apache.karaf.main.lock.SimpleFileLock lock INFO: Lock failed

Resolution

To resolve this, verify ownership and permissions of the application files, remove stale lock files, and restart the Talend Remote Engine:

1. Ensure that the dedicated Talend user and group have full recursive ownership over the application files to prevent any permission-related runtime errors:
   

   sudo chown talenduser:talendgroup /opt/talend/TalendRemoteEngine -R

   Adjust the absolute path `/opt/talend/` if your installation directory differs.
   
   
2. Stop the Talend Remote Engine Service: 

   sudo systemctl stop talend-remote-engine.service

3. Manually purge the stale or unsynced lock file that is blocking the engine startup:

   rm /opt/talend/TalendRemoteEngine/lock

4. Restart the Talend Remote Engine Service. The engine will automatically generate a fresh, synced lock file upon a successful boot.

   sudo systemctl start talend-remote-engine.service

Cause

An unexpected downtime or sudden disconnection of the Talend Remote Engine (RE) left the application's file lock (TalendRemoteEngine/lock) in an unsynced or stale state. Because the container detected this pre-existing lock file upon recovery, it assumed another process was already running, subsequently blocking all other dependent modules and services from initializing.

Environment

• Talend Remote Engine

Qlik Talend Studio was successfully set up on a virtual machine (VM). After cloning the VM, opening Qlik Talend Studio fails to open projects, instead erroring out with:

An error occured:

'void org.talend.repository.gitprovider.core.GitBaseRepositoryFactory.updateLockStatus()'

Resolution

To fix the error, shut down Qlik Talend Studio first, then delete all .lock files found inside the .git directories.

The git lock files are found in the workspace for Qlik Talend Studio:

• <talend_workspace>/.git/index.lock
• <talend_workspace>/.git/refs/heads/<branch>.lock
• <talend_workspace>/.git/HEAD.lock
• <talend_workspace>/.git/config.lock
• Check nested project repositories for additional files

Cause

The GitBaseRepositoryFactory.updateLockStatus() error commonly occurs due to stale Git lock files that were copied along with the VM snapshot.

When the VM was snapshotted or copied, Qlik Talend (or its embedded Git) was likely mid-operation or simply had lock files present. These .lock Files are now orphaned on the cloned VM, and Git thinks a process is holding a lock, but no such process exists.

Related Content [can be removed if not necessary]

[Paragraph format. Link to related content, such as articles, community posts, Help articles, etc...]

Internal Investigation ID(s) [can be removed if not necessary]

[Paragraph format with internal investigation IDs (e.g Jira case ID(s)) ]

Environment

• Qlik Talend Studio

The Qlik Replicate Endpoint Server fails to start. The error may occur after an upgrade or initial installation and presents with the following error:

Failed to curl_easy_perform: curl status = 3, URL using bad/illegal format or missing URL ()

Resolution

To resolve this issue, redirect the Java temporary directory to an alternative location that allows execution:

1. Create a new temporary directory and ensure the Qlik Replicate user has full read/write/execute permissions:

   • mkdir -p /att_tmp

   • chmod 755 /att_tmp

   • chown attunity:attunity /att_tmp

2. Navigate to the Qlik Replicate bin directory:

   cd /opt/attunity/replicate/endpoint_srv/bin

3. Back up the original script before editing:

   cp rependctl.sh rependctl.sh.bak

4. Open the script with a text editor:

   vi rependctl.sh

5. Locate the Java execution line at the end of the file (starts with "${AT_JAVA}"). 
6. Add the -Djava.io.tmpdir=/<your_new_tmp_directory> parameter into the statement.
   
   Example after modification:
   

   "${AT_JAVA}" -XX:+UseG1GC -Djava.io.tmpdir=/att_tmp -Dfile.encoding=UTF-8 ${AT_JVM_OPT} -cp "${AT_CP}" "${AT_MAIN}" -d "${AT_DATA}" -plugins "${AT_PLUGIN_LIST}" "${@:1}"

7. Save the changes, exit the editor, and restart the Qlik Replicate services.

Cause

The Qlik Replicate Endpoint Server utilizes the default system /tmp directory to unpack and execute temporary binary files or scripts during startup. If the /tmp filesystem is mounted with the noexec parameter (typically for security hardening in /etc/fstab), or if there are restrictive permissions on the /tmp folder, the application will be blocked from executing these files, causing the initialization to fail.

Internal Investigation ID(s)

00397473

Environment

• Qlik Replicate

Qlik Replicate tasks fail to capture primary keys with a numeric value in a string datatype.

The problem occurs if the following criteria are met:

• Log based SAP Hana replication
• The column is part of the Primary Key with a CHAR datatype
• The column contains both alphanumeric and numeric records

This leads to numeric records missing inserts during CDC replication. An upgrade to a later patch is required to resolve this issue.

Environment

• Qlik Replicate 2024.11.0.641
• SAP Hana Source endpoint

Resolution

Patch Qlik Replicate to (at least) 2025.11 SP04. Download the patch from the Qlik download page.

Qlik Replicate patches can be made available before their official release. Contact Qlik Support for details.

Environment

• Qlik Replicate 2024.11.0.641
• SAP Hana Source endpoint

This article documents how to update the Qlik Talend Data Catalog repository password, which can be achieved either through the Talend Data Catalog user interface or the configuration files.

Changing the password in the user interface

1. Log in to Qlik Talend Data Catalog with a user assigned the global role Application Administration.
2. Navigate to Manage 
3. Go to System
4. Click Configure 
   
   
   
   
5. Set the new database credentials, then click SAVE 
   
   
   
   
6. Restart the Qlik Talend Data Catalog service

Changing the password in the configuration files

1. Stop the Talend Data Catalog Application Server

   The application must be stopped completely before making changes to configuration files.

   • Linux: Navigate to the software home directory and run the RestartServerApplication.sh script as follows:

     cd /opt/<TDC_HOME>/TalendDataCatalog sudo ./RestartServerApplication.sh exit

   • Windows: Go to the software home directory and run the RestartServerApplication.bat file to start the Talend Data Catalog Application Server. Alternatively, use the Windows Services applet. 
2. Navigate to the Talend Data Catalog configuration directory: <TDC_INSTALLATION_DIR>/conf
3. Locate the mm.conf.properties file
4. Open mm.conf.properties using a text editor and identify the database connection password parameter: 
   

   db.connection.password=  

5. Update this value with the new password

   Avoid extra spaces when updating the value.

   
    
6. Save the changes
7. Restart the Talend Data Catalog application to apply the updated configuration

Validation Steps 

• Verify the Database Connection
  After the application is up and running, validate that Talend Data Catalog successfully connects to the repository database. You can do this by checking the application logs or accessing the Talend Data Catalog interface.
• Password Encryption Confirmation
  After a successful restart, the password in the mm.conf.properties file should automatically be encrypted by the application. This confirms that the configuration has been applied correctly.

Environment

• Qlik Talend Data Catalog

Qlik Talend Data Catalog login fails with the following error written to the logs:

General error during service initialization: The Scheduler has been shut down.

A complete error stack trace:

(System) MIRWEB_F0004 General error during service initialization: The Scheduler has been shutdown.
(System) MIRWEB_E0115 Application Exception for request: MITI.web.mm.actions.auth.InitLicense.
Browser URL: 
Parameters:
   username: Administrator
   password: ********
MITI.web.common.exceptions.CommandFaultException: The Scheduler has been shutdown.
    at MITI.web.mm.actions.auth.InitLicense.runJsonCommand(InitLicense.java:81) ~[1-MM.war:?]
    at MITI.web.mm.actions.AbstractJsonAction.doExecute(AbstractJsonAction.java:27) ~[1-MM.war:?]

Resolution

Restart the Qlik Talend Data Catalog application server using the RestartServerApplication script. 

Linux:

Navigate to the software home directory and run the RestartServerApplication.sh script:

cd /opt/<TDC_HOME>/TalendDataCatalog sudo ./RestartServerApplication.sh exit

Windows:

Go to the software home directory and run the RestartServerApplication.bat file to start the Talend Data Catalog Application Server.

Alternatively, restart the service using the Windows Services applet.

Cause

The error indicates that the internal scheduler service (Quartz scheduler) is not running or has already been terminated when the web service tries to initialize. Because the application attempted to use the scheduler service, which had already been stopped when the server shut down due to license expiration. When the InitLicense request was executed, it attempted to access scheduled events, but the scheduler was not running or properly initialized.

Common root causes are:

• An expired license, leading to the scheduler service failing to start due to license expiration 
• The Talend Data Catalog Tomcat server did not shut down correctly

Environment

• Qlik Talend Data Catalog

This article documents an example of how to configure MAM control of the Qlik Analytics Mobile app. 

The example is provided as is. Qlik does not offer guidance on configuring Entra Conditional Access policies or broader Intune deployments. For those details, see Learn about Conditional Access and Intune in the Microsoft documentation.

As per Securing and configuring the Qlik Analytics mobile app with Microsoft Intune and the section titled Conditional Access scope considerations, the authentication flow for the mobile app follows the Qlik Cloud IDP OIDC progression.

The pattern and steps outlined in this article are the working example Qlik used in verification testing of the Conditional Access control for the Qlik Analytics mobile app policy deployment. Your own policy and configuration definitions may vary, and Microsoft documentation or support should be contacted for further help that is specific to your Entra and Intune environments.

1. Identify the IDP App Registration:
   
   
   1. Navigate to Entra ID → App registrations
   2. Locate the OIDC IDP app registration and note the Application (client) ID
   3. Confirm this is the client ID presenting itself during the OIDC browser redirect
      
      
2. Modify Existing All Cloud Apps Policy
   
   
   1. Navigate to Protection → Conditional Access → Policies
   2. Open the existing All Cloud Apps policy
   3. Go to Cloud apps or actions → Exclude and add the IDP app registration client ID
   4. In Conditions → Device platforms: Any device
   5. In Conditions → Client apps: Browser + Mobile apps and desktop clients
   6. Grant access: Require device to be marked as compliant
   7. Save and set to Report-only at first
      
      
3. Create a new Targeted Policy for IDP Registration
   
   
   1. Create a new CA policy
   2. Set Users to the same scope as the existing policy
   3. Set Cloud apps to include IDP app registration only
   4. In Conditions → Device platforms: iOS, Android, macOS, Linux
   5. In Conditions → Client apps: Browser + Mobile apps and desktop clients
   6. Grant access: Require multifactor authentication (MFA)
   7. Set to Report-only at first
      
      
4. Validate in Report-Only before enabling
   
   
   1. Navigate to Sign-in logs
   2. Attempt the auth flow on a test device
   3. Check the sign-in log entry for the OIDC redirect leg
   4. Confirm report-only shows that the existing policy (Step 2) would have passed for a compliant device excluded
   5. Confirm report-only shows that the new policy (Step 3) would have passed for MFA on Authentication via Authenticator
   6. Once both are confirmed, switch both policies to enabled

On the test device:

1. Clear app session state and OIDC tokens
2. Re-attempt the full auth flow end-to-end
3. Confirm OIDC leg completes → local token issued -> on Authentication via Authenticator
4. Confirm MSAL leg completes → MAM policy on device confirmed
5. Confirm Qlik Analytics loads successfully

Environment

• Qlik Cloud
• Qlik Analytics mobile with Intune

The HostInfo.xml file in Talend Data Catalog is used for license management. It contains your server's hardware and host identity information and is required whenever you need a new license generated by Qlik.

1. To download the HostInfo.xml file from your Talend Data Catalog, sign in as a user with the Application Administrator capability global role assignment.
2. Go to MANAGE > License.
3. Click DOWNLOAD LICENSE INFORMATION

4. Submit the HostInfo.xml file to the Qlik Customer Portal as part of your license request.
   
   Qlik will use the host information to generate a license file tied to your server.
   
   For active-passive cluster setups, you can get a license that works for both servers by providing two HostInfo.xml files, one for each server in your license request.

5. Once you have obtained your new .lic file, sign in as a user with the Application Administrator capability global role assignment.
6. Go to MANAGE > License.
7. Click UPDATE LICENSE
8. Confirm with Yes that you wish to continue.
9. Browse to the new license file and click Import.
10. Refresh your browser and log back in to see your new license.

Related Content

• Download License Information
• Update the License 
• Manage Users and Authentication 
• Manage Global Roles 

Environment

• Qlik Talend Data Catalog

Beginning on April 14, 2026, QlikView customers experienced outages and intermittent disruptions within their QlikView environments. These incidents coincided with the deployment of Microsoft’s April 2026 security patches to Domain Controllers, which affected QlikView Server Service (QVS) communications over port 4747.

The Microsoft patches introduced changes targeting Kerberos authentication and RC4 encryption. As a result, QlikView environments where RC4 remained enabled (such as at the domain account or Windows server level) became unstable or non-functional.

The impact on QlikView may include, but is not limited to:

• Failed QlikView Distribution Server distribution tasks with an error code indicating an Authentication Failure.
• "No Server" message on the QlikView AccessPoint with an error message in the Web server log indicating that the Web server cannot connect to the QlikView Server.
• Failed Qlik NPrinting distributions to QlikView using a QVP Connection.
• Problems accessing the QlikView Server settings from the QlikView Management Console, or failures for the QlikView Server to come online after a restart.

This article documents the steps to reconfigure the environment to comply with the RC4 cipher suite deprecation. 

Resolution

Information in this article is based on Microsoft's remediation steps and has been adjusted and expanded to include QlikView-specific instructions. For the original, see Detect and remediate RC4 usage in Kerberos | learn.microfot.com. 

There are three stages; not all may be required. Always start at the first one.

Reset the Computer Account

These steps require you to remove the computer from the domain and then re-add it. Before proceeding, ensure you have a Local Administrator account and its password for each of the QlikView servers.

1. Confirm the Domain Controllers and the QlikView server(s) have the Microsoft patch applied.
2. Reset the Active Directory Computer Account (not the Service Account) on the Domain Controller’s Active Directory Users and Computers interface.
3. Place the QlikView server(s) into a Workgroup:
   1. Log onto the local computer of the QlikView server
   2. Open the Server Manager
   3. Go to Local Server
   4. Go to Computer Name
   5. Place the server in a local group
   6. Reboot the QlikView server
   7. Repeat the step for all QlikView servers if you have additional nodes
4. Return the QlikView server(s) to the Domain:
   1. After the reboot, return to the Server Manager
   2. Go to Local Server
   3. Go to Computer Name
   4. Re-join the Domain and reboot the server
   5. Repeat the step for all QlikView servers if you have additional nodes
5. Test the QlikView environment to confirm this has resolved the interruptions.

Kerberos ticket reset

It may be necessary to clear the Kerberos ticket on the affected QlikView server(s).

1. Open PowerShell or a Command Prompt with elevated permissions
2. Run the command: Klist purge

Reset the Service Account

It may be necessary to reset the Domain password for the QlikView service account.

1. Verify that all server Domain Controllers and Windows Servers on which the QlikView Application is installed are patched.
2. Verify that RC4 encryption is disabled.
3. Reset the QlikView service account password.
4. Open the Services panel, then reapply the QlikView service account using the new password
5. Restart the QlikView services.

   If the QlikView service account was used for any data connection(s), they will need to be updated with the new password.

Related Content

• What Changed in RC4 with the January 2026 Windows Update and Why it is Important | techcommunity.microsoft.com 

Microsoft Patches:

• Windows Server 2022 (DC): KB5082142
• Windows Server 2019 (DC): KB5082123
• Windows Server 2016 (DC): KB508208

Environment

• QlikView

This article explains how to connect the Qlik MCP (Model Context Protocol) server to Snowflake Intelligence, enabling Snowflake Cortex Agents to query and interact with Qlik Cloud resources, such as apps, data assets, and analytics, directly from the Snowflake AI interface.

Content

• Prerequisites
• Setup Steps
• Create an OAuth2 Client in Qlik Cloud
• Register the Qlik MCP Server in Snowflake
• Connect to Qlik MCP in Snowflake Intelligence
• Test with a Cortex Agent
• Troubleshooting
• Related Content

Prerequisites

• Qlik Cloud: Tenant Administrator access to create OAuth clients in the Administration activity center
• Snowflake: ACCOUNTADMIN role (or a role with CREATE INTEGRATION and CREATE MCP SERVER privileges)
• Snowflake Intelligence access (Cortex Agents) enabled on your Snowflake account
• Your Qlik Cloud tenant hostname (example: your-tenant.us.qlikcloud.com)

Setup Steps

Create an OAuth2 Client in Qlik Cloud

The OAuth2 client provides Snowflake with the credentials it needs to authenticate against the Qlik MCP server on behalf of users. For details on creating OAuth clients, see Creating and managing OAuth clients.

Copy the Client ID and Client Secret immediately after creation. The secret cannot be retrieved later — if lost, you must generate a new one.

1. Log in to your Qlik Cloud tenant and navigate to the Administration activity center, or go directly to https://<your-tenant>/console.
2. Go to OAuth 
3. Click Create New
4. Fill in the following fields:
   
   
   • Name: A descriptive name
   • Client type: Web
   • Authentication method: Client secret
   • Redirect URL: https://identity.snowflake.com/oauth2/callback
   • Allowed origins (optional): https://identity.snowflake.com
   • Scopes: user_default, mcp:execute

     The mcp:execute scope is required to allow Snowflake to invoke tools on the Qlik MCP server. The user_default scope grants access to resources the authenticated user can already access in Qlik Cloud.

5. Click Create.
6. A dialog will display the Client ID and Client Secret. 
   
   Copy both values immediately and store them securely. The Client Secret will not be shown again.
   
   

Register the Qlik MCP Server in Snowflake

For details on the Qlik MCP server endpoint and supported tools, see Connecting to the Qlik MCP server.

Using the OAuth client credentials previously retrieved, run the following Snowflake SQL script to:

• Create an API Integration with OAuth2, pointing to your Qlik tenant
• Register an External MCP Server using that integration
• Grant usage to the appropriate role
  

  -- ============================================================
  -- Parameters — update these values before running
  -- ============================================================
  SET TENANT        = '<your-tenant>.us.qlikcloud.com'; -- Do not include https://
  SET CLIENT_ID     = '<your-oauth-client-id>';
  SET CLIENT_SECRET = '<your-oauth-client-secret>';
  SET ALLOWED_ROLE  = 'PUBLIC'; -- The Snowflake role that should have access.
                                -- ⚠️ PUBLIC grants access to all users in the account.
                                -- For production, replace with a more restrictive role.
  
  -- ============================================================
  -- Derived values — no changes needed below this point
  -- ============================================================
  SET MCP_URL = 'https://' || $TENANT || '/api/ai/mcp';
  
  -- Create the API Integration with OAuth2 configuration
  DROP API INTEGRATION IF EXISTS qlik_mcp_integration;
  
  EXECUTE IMMEDIATE
  $$
  DECLARE
      v_tenant        VARCHAR;
      v_client_id     VARCHAR;
      v_client_secret VARCHAR;
      v_mcp_url       VARCHAR;
      sql_stmt        VARCHAR;
  BEGIN
      SELECT GETVARIABLE('TENANT')        INTO v_tenant;
      SELECT GETVARIABLE('CLIENT_ID')     INTO v_client_id;
      SELECT GETVARIABLE('CLIENT_SECRET') INTO v_client_secret;
      v_mcp_url := 'https://' || v_tenant || '/api/ai/mcp';
  
      sql_stmt :=
          'CREATE API INTEGRATION qlik_mcp_integration'
          || ' API_PROVIDER = external_mcp'
          || ' API_ALLOWED_PREFIXES = (''' || v_mcp_url || ''')'
          || ' API_USER_AUTHENTICATION = ('
          || '   TYPE = OAUTH2'
          || '   OAUTH_CLIENT_ID = ''' || v_client_id || ''''
          || '   OAUTH_CLIENT_SECRET = ''' || v_client_secret || ''''
          || '   OAUTH_TOKEN_ENDPOINT = ''https://' || v_tenant || '/oauth/token'''
          || '   OAUTH_CLIENT_AUTH_METHOD = CLIENT_SECRET_POST'
          || '   OAUTH_AUTHORIZATION_ENDPOINT = ''https://' || v_tenant || '/oauth/authorize'''
          || '   OAUTH_REFRESH_TOKEN_VALIDITY = 86400'
          || '   OAUTH_ALLOWED_SCOPES = (''user_default'', ''mcp:execute'')'
          || ' )'
          || ' ENABLED = TRUE';
  
      EXECUTE IMMEDIATE sql_stmt;
  END;
  $$;
  
  SHOW API INTEGRATIONS LIKE '%qlik%';
  
  SET DISPLAY = 'Qlik MCP server ' || $TENANT;
  DROP EXTERNAL MCP SERVER IF EXISTS qlik_mcp_server;
  
  CREATE EXTERNAL MCP SERVER qlik_mcp_server
      WITH DISPLAY_NAME = $DISPLAY
      API_INTEGRATION  = qlik_mcp_integration;
  
  ALTER EXTERNAL MCP SERVER qlik_mcp_server
      SET URL = $MCP_URL;
  
  -- Grant access to the specified role
  GRANT USAGE ON INTEGRATION  qlik_mcp_integration TO ROLE IDENTIFIER($ALLOWED_ROLE);
  GRANT USAGE ON MCP SERVER   qlik_mcp_server       TO ROLE IDENTIFIER($ALLOWED_ROLE);
  
  -- ============================================================
  -- Verification queries
  -- ============================================================
  SHOW EXTERNAL MCP SERVERS;
  DESCRIBE EXTERNAL MCP SERVER qlik_mcp_server;
  SHOW API INTEGRATIONS LIKE '%qlik%';
  
  -- Initiate the user OAuth flow
  SELECT SYSTEM$START_USER_OAUTH_FLOW('qlik_mcp_integration');
  ​

  The SYSTEM$START_USER_OAUTH_FLOW call at the end generates a URL you can open in a browser to validate the OAuth handshake with Qlik Cloud before proceeding to Snowflake Intelligence.

Connect to Qlik MCP in Snowflake Intelligence

Once the MCP server is registered in Snowflake, you can authorize and use it directly from the Snowflake Intelligence UI.

1. Open Snowflake Intelligence. The URL follows the pattern https://ai.snowflake.com/<orgname>/<accountname>.
   
   For example, https://ai.snowflake.com/myorg/myaccount. If you are unsure of your URL, contact your Snowflake account administrator.
   
   
2. Click your profile icon (bottom left corner) to open your personal settings.
3. Navigate to the Connectors section. You will see Qlik MCP Server listed, pointing to your configured Qlik Cloud tenant.
4. Click the Connect button next to the Qlik MCP entry.
5. You will be redirected to Qlik Cloud to complete the OAuth2 authorization flow. Log in with your Qlik Cloud credentials if prompted, then approve the requested permissions (user_default, mcp:execute).
6. After authorization, you are returned to Snowflake Intelligence. The Qlik MCP connector will show a Connected status.
7. You can now ask Snowflake Intelligence questions that involve Qlik Cloud resources. The Cortex Agent will automatically invoke the appropriate Qlik MCP tools to retrieve data, apps, or analytics content.
   
   

Test with a Cortex Agent

To validate the full integration, create a test Cortex Agent that uses the Qlik MCP server.

Before running: Replace CORTEX_APP.PUBLIC with the database and schema where you want to create the agent in your Snowflake environment. The database must already exist.

-- Replace <YOUR_DATABASE> and <YOUR_SCHEMA> with your target database and schema
CREATE OR REPLACE AGENT <YOUR_DATABASE>.<YOUR_SCHEMA>.qlik_mcp_test_agent
  FROM SPECIFICATION $$
models:
  orchestration: auto
instructions:
  response: >
    You are a test agent that verifies connectivity to the Qlik MCP server.
    Use the available Qlik tools to answer the user's question.
  orchestration: "Use the Qlik MCP tools to answer questions about Qlik Cloud."
mcp_servers:
  - server_spec:
      name: "<YOUR_DATABASE>.<YOUR_SCHEMA>.QLIK_MCP_SERVER"
$$;

Once created, invoke the agent with a test prompt such as: What Qlik apps are available in my tenant?

A successful response confirms end-to-end connectivity between Snowflake Cortex and the Qlik MCP server.

Troubleshooting

OAuth redirect fails

Typically caused by a Redirect URL mismatch. Verify https://identity.snowflake.com/oauth2/callback is set in the Qlik OAuth client

mcp:execute scope error

The scope not enabled on OAuth client. Edit the OAuth client in Qlik Cloud Administration activity center and add the mcp:execute scope

Client Secret rejected

Secret was rotated or lost. Generate a new client secret and update $CLIENT_SECRET in the script

MCP Server not visible in Snowflake Intelligence

The correct role was not granted. Confirm GRANT USAGE ON MCP SERVER was executed for the user's active role.

Agent returns no results

The OAuth flow was not completed. Complete the steps in Connect to Qlik MCP in Snowflake Intelligence.

Related Content

• Connecting to the Qlik MCP server | Qlik Cloud Help
• Creating and managing OAuth clients | Qlik Cloud Help
• Snowflake External MCP Server documentation

Environment

• Qlik MCP
• Qlik Cloud

The information in this article is provided as-is and to be used at your own discretion. Depending on the tools used, customizations, and/or other factors, ongoing support on the solution described may not be provided by Qlik Support.

Qlik Cloud automatically places applications on compute engines based on calculated metrics that determine the required resources. This automatic placement works well for most apps, but some require manual intervention.

Apps with large chart objects that generate large hypercubes can consume all available memory and crash. By pinning an app to a specific engine size, you control the minimum compute resources available for interactive consumption.

For details, see Assigning engines to improve application performance and Pin applications to engine sizes.

This article aims to clarify how reloads are handled for an app pinned to an engine, since assigning an engine concerns only the opening and consumption of apps by end users, not app reloads.

How reloads are handled:

• The optimization concerning app reloads is based on a similar concept: Qlik Cloud still automatically places applications on engines based on calculated metrics that determine the required resources.
• As a rule, the app will initially be placed on an engine based on the metrics of the last successful reload.
• If that engine is not sufficiently large, the reload will at first fail and then be moved to a larger one, where it will restart from scratch.
• This process is not made obvious to end users and administrators. The initial failures won't be noticed in logs or alerts, although analyzing the details might show a later "start time" than expected since only the successful run will be shown.
• The next time the task is run, it will automatically start on the larger engine.
  In rare scenarios, the calculated metrics might not reflect the required resources, and the behaviour could be erratic. In case of issues, do not hesitate to contact support with all the necessary information (appIds, taskIds, reloadIds, timestamps). 

Environment

• Qlik Cloud

The Data Gateway Monitoring tool provides an additional layer of logging that Qlik's R&D team can use to troubleshoot Data Gateway issues for a Data Gateway that was successfully installed and running previously. 

This troubleshooting tool is not necessary for the day-by-day operation of the Data Gateway Direct Access deployment and can be disabled after troubleshooting has been completed.

For its full Qlik Data Gateway Monitor documentation, see Qlik Data Gateway Monitor | Qlik Products.

This article offers a brief overview of how to set up and begin using the monitor.

Deploying the Qlik Data Gateway Monitoring Tool

1. Download the Qlik.ConnectorAgent.Monitor.Installer-x.x.x.exe installer available at
   Installing Data Gateway Monitor Instructions and Download link
   
2. Install the Qlik Data Gateway Monitoring tool where you have the Qlik Data Gateway Direct Access deployed.
   
   The installation requirements are the same as for Qlik Data Gateway Direct Access. See Best practices. 
   
   A Windows Server service will be installed that can be set to manual when troubleshooting is completed.
   
   
3. Reproduce the issue and monitor logging will automatically collect/log data.
   
   
4. Zip and upload the logs from C:\ProgramData\Qlik\Gateway\Monitor\Logs to the Qlik Support case.
   
   If the zip is too large for the support site, ask your Qlik support engineer to provide you with the dedicated upload space for your specific case.
   

More details about this tool can be found here.

General Health Check and Monitoring of Qlik Data Gateway

1. To check overall Data Gateway health, access the following URL in a supported browser: http://localhost:5050/health
   
   A simple 'OK' will appear if Gateway is connected to the cloud instance and running normally.
   
   
   
2. To check Data Gateway connections status, access the following URL in a supported browser: http://localhost:5050/status
   
   Scroll to the bottom of the status page. Healthy Data Gateway status will be indicated by a Pass result.
   
   

The information in this article is provided as-is and to be used at one's own discretion. Depending on tool(s) used, customization(s), and/or other factors, ongoing support on the solution below may not be provided by Qlik Support.

To change the Talend Remote Engine wrapper port defaults, edit the Remote Engine's wrapper configuration file named RE_HOME/etc/talend-remote-engine-wrapper.conf. 

1. Stop the Remote Engine service on the target machine before editing configuration files.
2. If the engine was installed with the wrapper service, edit the following: 
   
   RemoteEngineInstallationDirectory/etc/talend-remote-engine-wrapper.conf
   
   
3. Adjust or add the JVM arguments and any wrapper-specific port settings.
   
   Example:
   
   =====================
   wrapper.jvm.port.min=61000
   wrapper.jvm.port.max=61999
   wrapper.port=62000
   ===================
   
   
4. Save the change.
5. Start the engine service.
6. Verify pairing and connection in Talend Management Console, and verify that the correct ports are used.
   
   Linux (use ps -ef | grep java):
   
   
   
   Windows (resource monitor):
   
   
   
   

For more information, see wrapper.jvm.port.

Environment

• Qlik Talend Cloud
• Remote Engine; Linux & Windows