Hi everyone!

I’m back again to recommend a video by @marksouzacostafrom Data Voyagers about the Visual Task Chain Viewer in Qlik Cloud.

For anyone managing multiple chained reloads, this looks like a huge time-saver when it comes to diagnosing failures within those chains. It turned out to be the perfect solution for a project I’m currently working on that requires this type of management.

Check out the full step-by-step video from Data Voyagers here: https://www.datavoyagers.com

Youtube: https://www.youtube.com/watch?v=GvG_wqvMlZ0

Has anyone else been using this tool? 🙂

We are using qlik replicate to replicate the data from sql server to kafka and gcs targets. 

Currently we using the Import API's for replicate tasks to import the tasks into replicate server and we are using jinja templates to create the task json by passing the configuration and tablenames (List of table is not static and passed at the time of json creation) and import those json programmatically (Jenkins) and as we are creating the json task on the fly using templates, we are missing the traceability, which is really a challenging as changes are not being recorded. 

Ask here is, How can we make it more configurable manner with traceability / recoverability for each qlik task. Curious to know if someone has already done this using terraform. 

Can this be achieved using Terraform? or any other IaC technology which help us to the onboarding qlik tasks in more configurable and manageable way.

Consider a scenario of disaster recovery. If we are creating the json's on the file and we dont know the previous state of the task and recreating the task would be painful.

It’s Git O’clock for your Qlik Sense routine! 
Add Gitoqlok to your application development cycle and enjoy the Continuous Integration perks as well as tricks for easing your working routine.

Gitoqlok is an easy-to-use tool for version control and collaborative development in Qlik Sense. Via integration with several Git providers (GitHub, GitLab, BitBucket, etc.), the extension opens the gates to the world of version history. Any change made in the application by the user can be tracked and restored at any point in time - milestone your work and enjoy the visual time travel between different versions of your application - and don’t switch a single window.

Regardless of your team’s size, Gitoqlok is the remedy for the headache of conflicting changes - the git system inherited in Gitoqlok detects developers’ copies of applications, stores their changes in independent branches, and aids in detecting collisions for published applications.

Version control is not the only offering Gitoqlok has up its sleeve. In the favor of advancing your development process by reducing manual routine work, you can:

       ✔ Immediately find an application that generates a QVD file in Data Load Editor;
       ✔ Set covers for the sheets in just a few seconds;
       ✔ Use the AI capabilities to generate Sheets and Master Measures titles and descriptions;
       ✔ Migrate Qlik objects between different Qlik environments and backup restore, and many more!

Learn more about the whole spectrum of features on https://docs.gitoqlok.com/

Join our Slack community https://app.slack.com/client/T012RHLTWHL

Try Gitoqlok yourself https://chrome.google.com/webstore/detail/gitoqlok/kkgicbgpgfcbhcbmifmfagggnpkebdaj?hl=en

Every few months I go looking for things in my company that could run smoother, and this time I landed on Qlik Replicate. So I asked the engineers and consultants how they handle changes to tasks.

In short: tasks reuse is export, import, and hand-editing the JSON in between. Version control is a folder of exported files, if someone remembered to export. Transformations stay stuck in the task they were written in. And none of it ever settles, because new sources and targets keep arriving.

So we built a first version of Git versioning for Qlik Replicate Tasks. Here is how it works:

1. A browser extension (Gitoqlok, iykyk) grabs the list of Replicate tasks from the console links a Git repository to it (GitHub, GitLab, Bitbucket, Azure DevOps). The task definition goes in as the first commit.

1. Repository then contains the JSON that Replicate's Export button gives you: endpoints, table selection, transformations, task settings. Plus a README generated from it: source, target, endpoints, the table list.

1. Change and commit. Edit the task in the console as usual. Next time you open the popup it shows what changed, line by line. Here I added one transformation on a table, and it shows exactly the 28 lines it touched. Type a message, Commit & Push.

1. Go back. History dropdown, Restore button. Any version goes back into Replicate as a full replacement, deleted table selections included.

So the versioning and rollback part is done. My next idea was import: a task committed from DEV gets imported into TEST or PROD straight from Git, any saved version.

Then the sheer number of transformations inside a single task got me thinking: maybe transformations deserve versioning of their own... Imagine an import that pulls just one piece, a transformation or the logging levels, from another task you've already configured.

Some additional details: our install doesn't have EM, so this uses the console's API.

Would appreciate your thoughts, any feedback. If anyone's interested, I'd be happy to share the solution!

#QlikReplicate #Qlik #DataEngineering #CDC #DevOps 

Bonjour 

j ai une condition de date dans un where qui ne marche pas j'ai essayé plein de solutions rien n'aboutit  la voici 

where Date(Date#(CAPA_MOIS,'dd/mm/yyyy'))=Date(Date#('$(vMoisReport_Suivant)','dd/mm/yyyy'))

ma dernière tentative est sous cette forme avez vous des idées ?

Hello everyone,

I work at Dev Technosys, where we do HR management software development, building custom HRMS platforms for our clients. One of our clients' data teams uses Qlik Compose for their data warehouse, and they'd like HR data from our platform to feed into it. Before we finalise our database design, I'd like to understand how to make the source data as Compose-friendly as possible.

Scenario:

• Source: a relational HRMS database (PostgreSQL) with employees, departments, job titles, managers, locations, and compensation bands
• Data would land through Qlik Replicate (CDC)
• The client wants to report on employee history, for example, headcount by department at any point in time, promotion rates, and attrition

My questions:

1. Tracking employee history: From what I understand, attributes in the Compose model can be set to keep history (Type 2). For an employee entity, which attributes would you normally track historically (department, job title, manager, location), and which would you keep as Type 1?
2. Source design: Is it better for our HRMS to keep its own effective-dated history tables (for example, employee_job_history with valid_from and valid_to), or should we keep the source simple with current values only and let Compose build the history from CDC changes?
3. Backdated changes: HR data often includes backdated updates, such as a promotion entered today that was effective last month. How does Compose handle changes where the business effective date is different from the date the change was captured?
4. Manager hierarchy: What's the recommended way to model a reporting hierarchy (employee → manager) in Compose so that historical org charts can be reconstructed?
5. Sensitive data: Salary and personal details are sensitive. Is it better to exclude these columns at the Replicate level, or handle masking and access within the warehouse and data marts?

Any guidance, documentation links, or experience from similar HR data projects would be really appreciated.

Thank you!

Hi,

We're running Qlik Sense Enterprise on Windows, November 2025. Since IT enabled SSO (SAML) on the server, all monitoring apps (Content Monitor, License Monitor and Operations Monitor) fail to reload with the following errors.:

Content Monitoring --> Connection 'monitor_apps_REST_app' not found

License Monitor --> Connection 'monitor_apps_REST_license_user' not found

Operations Monitor --> Connection 'monitor_apps_REST_user_condensed

What we've already checked/tried, without success:

• The data connections (e.g. monitor_apps_REST_*) exist in the QMC, correctly named, no typo.
• No security rule has been added or modified since the SSO switch
• All apps have been exported and reimported but still failing identically on their respective monitor_apps_REST_* connections.
• Owner is INTERNAL\sa_repository (default, unchanged).
• Connection string uses the default pattern: provider=QvRestConnector.exe;url=https://localhost/qrs/license/useraccesstype/full;...;authSchema=ntlm;...
• Tested with an explicit port on the URL (:4243) — same error.
• Checked virtual proxies: we have Central Proxy (Default) (prefix mgmt, Authentication method = Ticket, Windows authentication pattern = Windows, this field is grayed out/system-managed) and Entra ID (SAML, no prefix). The default proxy already natively supports the Windows authentication pattern fallback, so it doesn't look like a virtual proxy/NTLM config issue.
• Temporarily created a dedicated virtual proxy (Windows-only, separate prefix) to isolate REST/API traffic from the SSO flow — same "Connection not found" error persisted, so we rolled it back.

Has anyone met this ? if you could help please

BR,

Hamid