Qlik Cloud Monitoring Apps Workflow Guide

[Sonja_Bauernfeind]

Installing, upgrading, and managing the Qlik Cloud Monitoring Apps has just gotten a whole lot easier! With two new Qlik Application Automation templates coupled with Qlik Data Alerts, you can now: 

1. Install/update the apps with a fully guided, click-through installer using an out-of-the-box Qlik Application Automation template. 
2. Programmatically rotate the API key required for the data connection on a schedule using an out-of-the-box Qlik Application Automation template. This ensures the data connection is always operational. 
3. Get alerted whenever a new version of a monitoring app is available using Qlik Data Alerts. Repeat Step 1 to complete the update. 

The above allows you to deploy the monitoring apps to your tenant with a hands-off approach. Dive into the individual components below. 

Content:

• Part One: 'Qlik Cloud Monitoring Apps Installer' template overview
• Part Two: 'Qlik Cloud Monitoring Apps API Key Rotator' template overview
• Part Three: How to setup a Qlik Alert to know when an app is out of date
• A Qlik Cloud Monitoring Apps Workflow Demo (Video)
• FAQ

Part One: 'Qlik Cloud Monitoring Apps Installer' template overview

This automation template is a fully guided installer/updater for the Qlik Cloud Monitoring Applications, including but not limited to the App Analyzer, Entitlement Analyzer, Reload Analyzer, and Access Evaluator applications. Leverage this automation template to quickly and easily install and update these or a subset of these applications with all their dependencies. The applications themselves are community-supported; and, they are provided through Qlik's Open-Source Software GitHub and thus are subject to Qlik's open-source guidelines and policies.

For more information, refer to the GitHub repository.

Features

• Can install/upgrade all or select apps.
• Can create or leverage existing spaces.
• Programmatically handles pre-requisite settings, roles, and entitlements.
• Installs latest versions from Qlik’s OSS GitHub.
• Creates required API key.
• Creates required analytics data connection.
• Can create custom reload schedules.
• Can reload post-install.
• Tags apps appropriately to track which are installed and their respective versions.
• Supports both user and capacity-based subscriptions

Click-through installer:

Flow:

Note that if the monitoring applications have been installed manually (i.e., not through this automation) then they will not be detected as existing. The automation will install new copies side-by-side. Any subsequent executions of the automation will detect the newly installed monitoring applications and check their versions, etc. This is due to the fact that the applications are tagged with "QCMA - {appName}" and "QCMA - {version}" during the installation process through the automation. Manually installed applications will not have these tags and therefore will not be detected.

Part Two: 'Qlik Cloud Monitoring Apps API Key Rotator' template overview

This template is intended to be used alongside the Qlik Cloud Monitoring Apps for user-based subscriptions template. This automation provides the ability to keep the API key and associated data connection used for the Qlik Cloud Monitoring Apps up to date on a scheduled basis. Simply input the space Id where the monitoring_apps_REST data connection should reside, and the automation will recreate both the API key and data connection regularly. Ensure that the cadence of the automation’s schedule is less than the expiry of the API key.

Configuration

Enter in the Id of the space where the monitoring_apps_REST data connection should reside.

Ensure that this automation is run off-hours from your scheduled monitoring application reloads so it does not disrupt the reload process.

Part Three: How to setup a Qlik Alert to know when an app is out of date

Each Qlik Cloud Monitoring App has the following two variables:

• vLatestVersion: the latest version of the app released on Qlik’s OSS GitHub.
• vIsLatestVersion: a Boolean of whether the app’s current version is equal to the latest version of the app released on Qlik’s OSS GitHub (1 if true, 0 if false).

With these variables, we can create a new Qlik Data Alert on a per-app basis. For each monitoring app that you want to be notified on if it falls out of date:

1. Right-click on a chart in the app, select Alerts and then Create new alert.
2. Clear out the defaults and provide the alert with a name such as <Monitoring App Name> is Out of Date.
3. Select Add measure and select the fx icon to enter a custom expression. Enter the expression ’$(vLatestVersion)'. Ensure it is wrapped in single quotes, then provide the label for the expression Latest Version.
4. Select Add measure and select the fx icon to enter a custom expression. Enter the expression $(vIsLatestVersion), then provide the label for the expression Is Latest Version.
5. Confirm the Details & data tab resembles the following:
   
   
   
   
6. Navigate to the next tab, Conditions.
7. Set the Measure to Is Latest Version, the Operator to Equal to, and the Value to 0. This way, if the app is not the latest version (0), it will trigger the alert.
8. Confirm that the Conditions tab resembles the following:
   
   
   
   
9. Navigate to the Distribution tab and confirm that the alert is evaluated When data is refreshed.

Here is an example of an alert received for the App Analyzer, showing that at this point in time, the latest version of the application is 5.1.3 and that the app is out of date:

A Qlik Cloud Monitoring Apps Workflow Demo (Video)

 

FAQ

Q: Can I re-run the installer to check if any of the monitoring applications are able to be upgraded to a later version?

A: Yes. Run the installer, select which applications should be checked and select the space that they reside in. If any of the selected applications are not installed or are upgradeable, a prompt will appear to continue to install/upgrade for the relevant applications.

Q: What if multiple people install monitoring applications in different spaces?

A: The template scopes the applications install process to a “target” space, i.e., a shared space (if not published) or a managed space. It will scope the API key name to `QCMA – {spaceId}` of that target space. This allows the template to install/update the monitoring applications across spaces and across users. If one user installs an application to “Space A” and then another user installs a different monitoring application to “Space A”, the template will see that a data connection and associated API key (in this case from another user) exists for that space already and it will install the application leveraging those pre-existing assets.

Q: What if a new monitoring application is released? Will the template provide the ability to install that application as well?

A: Yes. The template receives the list of applications dynamically from GitHub. If a new monitoring application is released, it will become available immediately through the template.

Q: I would like to be notified whenever a new version of a monitoring applications is released. Can this template do that?

A: As per the article above, the automation templates are not responsible for notifications of whether the applications are out of date. This is achieved using Qlik Alerting on a per-application basis as described in Part 3.

Q:I have updated my application, but I noticed that it did not preserve the history. Why is that?

A: The history is preserved in the prior versions of the application’s QVDs so the data is never deleted and can be loaded into the older version. Each upgrade will generate a new set of QVDs as the data models for the applications sometimes change due to bug fixes, updates, new features, etc. If you want to preserve the history when updating, the application can be upgraded with the “Publish side-by-side” method so that the older version of the application will remain as an archival application. However note that the Qlik Alert (from Part 3) will need to be recreated and any community content that was created on the older application will not be transferred to the new application.

[jda_bryan]

This is fantastic functionality.  These apps are so important to tenant administration and leveraging the automation process to enable and manage them is such a useful lift.  The video help was absolutely spot on.  Thank you!!

[luizcdepaula]

Hi @Sonja_Bauernfeind ,

This is fantastic and a great step towards automating the updates of the monitoring apps. I found it was extremely easy to use the automation. I just have  some feedback.

1. It would be fantastic if instead of setting up the alerts and running on demand, we could have it scheduled to run every month automatically, looking for updates. So, being able to save the current selections of the settings would be great.

2. We have the API Key with expiration in 3 years. The max  window to be scheduled is 30 days. We will run it on demand, but being able to schedule with more custom window would be nice.

Thank you!

Luiz DP

[Daniel_Pilla]

Hi @jda_bryan , thank you so much for the feedback. I am glad you find the applications and resources so useful! We here at Qlik also use and depend on them, and agree 🙂

Hi @luizcdepaula , thank you for the feedback as well! 

1. I thought about this quite a bit and actually almost built that. After speaking internally with colleagues, we decided that three automations might be too much, and in addition, polling the apps on a regular basis incurs automation runs, so we did not want to have people run up their quotas by checking frequently when we could do it with no impact with Qlik Data Alerts. In addition, the automation would have to be customizable as you might only want to check for certain apps, or you might want to snooze certain updates. It also requires SMTP for emails, while Qlik Data Alerting does not as they can be received in the client. For those reasons we opted not to, but you could very easily write an automation that loops over the apps, checks their respective versions, and then compares them to the version found in the manifest here. That is the same source that the installer uses.
2. I will defer this one over to @Emile_Koslowski for any updates to the scheduling capabilities. That said, you can use any RESTful method of triggering the automation programmatically on any custom schedule that you'd like using another scheduling mechanism. For example, you could use an Qlik app with load script to trigger the automation to start using the REST connector, then set that script on a yearly schedule.

I hope this helps!

Cheers,

[Shohamgg]

Wow, what a wonderful resource.
you clearly put a lot of work into this and it shows.
Thank you

I have two small comments 🙂
1) Sunday is a working day for me but it is not available for selection.
2) App Analyzer failed to load but the Automation declared "Success!"

Thank you for this tool. it helps a lot!
Also I learned more about Application Automations capabilities 

[Daniel_Pilla]

Hi @Shohamgg ,

Thanks for the kind words! Glad you like it.

1. You can edit the reload schedule to add on Sunday for each application in the Managed space (or Shared/Personal if you did not publish). You can just tick on Sunday there for each. We did not include it in the installer by default so we are not reloading 7 days a week unnecessarily.

2. The automation is responsible for importing the selected applications, setting them up, and optionally triggering their reloads. The automation completes before the reloads finish and does not wait for success/failure there. If you are having an issue with the App Analyzer, please create an issue on the GitHub page here with details and I will take a look.

Cheers!

[luizcdepaula]

Hi @Daniel_Pilla ,

Thank you for your response.

1. I can see now the reason of the alerts and not scheduling. Still having the option would be great. Just too many alerts 🙂 . I will definitely take you up on the automation looping over the apps. If you have already something built I would highly appreciate.

2. Using an app as trigger is doable, I just don't like the fact that I need to add another app just for scheduling, adding another layer of liability. 

This is great though! I know it is hard to accommodate every need, and this is great. 

Thanks,

Luiz DP 

[petrus]

Hi @Daniel_Pilla , I really like that solution. It simplifies the whole process of deploying the apps over time. But what happens if we have some additional sheets as private/community during the upgrade process? The old app is removed and new one is published as a new copy or this works the way of republishing existing app by new one?

Btw qvd's are removed during the upgrade process too?

Thanks

PR

[Daniel_Pilla]

Hi @petrus ,

If the application is published to a managed space, the installer will offer you the option of publishing a new copy side-by-side or publishing and replacing the older version. If you choose to publish and replace, all of the community/private content will be preserved, else, that content will only reside on the archived (branded Legacy) older version.

Regarding QVDs, all of the original QVDs will remain but they are suffixed with a version number. Each version of the app reloads from its respective version numbered QVDs. This is to safeguard against data model changes etc. This really only impacts the Reload Analyzer and Entitlement Analyzer heavily. I'd advise checking the release notes for each latest release to see if it is for a major bug fix or if its just an enhancement etc to see if its worth jumping to the latest version if you really require the history. The older versions of the applications will also still be operational against the historical QVDs, so if history is needed for reference it can be viewed in the older versions, as the newer versions will generate their own QVDs.

I hope this helps!

Cheers,

[AlexOmetis]

Hi,

We love this automation - it saves so much time when setting up a new tenant!

Are there plans to make it work with tenants with Capacity licensing? I know there's the capacity monitoring for data/automations etc but it doesn't cover many of the areas that these apps do. 

[Daniel_Pilla]

Hey @AlexOmetis,

Good to hear from you and glad you like it!

The reason the automation was scoped to user-based tenants initially was primarily because the App Analyzer and the Reload Analyzer needed to be adjusted to operate correctly on a Capacity-based tenant. In addition, the Entitlement Analyzer is largely irrelevant for a Capacity tenant and there are no plans of supporting/migrating it to Capacity-based tenants. Rather than write in the logic to exclude certain apps, adjust pre-requisite checks depending on license, and modify the other apps before releasing the template, we chose to get it out the door faster and release it for user-based tenants first as Capacity is still quite new.

That said, it is on my agenda for next month to modify the automation to support both license types now that the App Analyzer and Reload Analyzer apps have been adjusted to work on Capacity-based tenants. There will have to be a number of modifications done to the automation, however the net is that you will not see the Entitlement Analyzer available to install if you are on a capacity-based tenant with the new automation. I can't provide a projected release date, but work will begin likely next week.

Cheers!