Managing on-demand apps

On-demand apps are generated in the Qlik Sense hub from navigation links that connect selection apps to template apps. The On-demand app service must be enabled to generate on-demand apps. You can create and publish selection and template apps to streams from the Qlik Sense hub, if you have the appropriate access rights. Selection and template apps can also be published to streams from the QMC, which is a part of Qlik Sense. Generated on-demand apps can also be published from the QMC or the Qlik Sense hub, if you have the appropriate access rights.

To publish an on-demand app that is generated in a Qlik Sense Desktop installation, you must first import it, by using the QMC

The security rules applied to the app, stream, or user, determine who can access the content and what the user is allowed to do. The app is locked when published. Content can be added to a published app through the Qlik Sense hub in a server deployment, but content that was published with the original app cannot be edited.

On-demand app service properties

Selection and template apps can be created without the On-demand app service being enabled, but the service must be enabled to create navigation links and generate on-demand apps. The On-demand app service is managed in the QMC. The following properties of the On-demand app service can be managed:

Property Description
Enable on-demand app service

Enables and disables the On-demand app service. The service is disabled by default.

When the service is switched from enabled to disabled, any pending requests to generate on-demand apps are allowed to finish. But once the service has been disabled, no new requests to generate apps will be accepted.

Logging level Specifies the level of detail written to the service log file.
Number of apps that can be generated at one time

Specifies the number of apps the service can generate at one time. The default is 1 and the maximum is 10.

This setting affects the response time for an app generation, but the amount of data loaded must also be considered when setting the number of apps that can be generated at one time. When the data load sizes are moderate, a higher number of apps generated at one time will improve response time for each app. But when load sizes are large, the response can be slower than if the setting were lower and apps had to wait in queue to be generated.

In a multi-node environment, the setting for the number of apps that can be generated at one time applies to all instances of the On-demand app services running in that environment. If multiple services use the same Qlik Associative Engine, the load on that Qlik Associative Engine could be the cumulative number of apps to generate at one time from the multiple instances of the service.

Number of days before purging historical data

Specifies the number of days certain historical data about on-demand apps is kept before the data is removed. Values can be 0-365. A setting of 0 means the data is never deleted. The default value is 90 days.

The On-demand app service keeps data about navigation links and about requests to generate and reload on-demand apps.

When an on-demand app navigation link is deleted, it is retained in a decommissioned state. When the number of days specified before purging is reached, data about the navigation link is removed.

The On-demand app service also retains information about requests to generate and reload on-demand apps. When on-demand apps are deleted, the information about their reload requests is retained for the number of days specified before purging.

Allow anonymous user to generate apps

Allows anonymous users to generate on-demand apps from navigation points on published selection apps. This setting applies only on Qlik Sense systems that have set anonymous authentication.

Anonymous authentication

An anonymous user can generate apps only from navigation links that are published automatically. If the generated app is not published automatically, the anonymous user would not have access to it.

The proxy user that will be used for generating apps on behalf of the anonymous users

Select a user to serve as a proxy user for anonymous users. Choose any registered user who can create on-demand app requests. The proxy user must also have read permission on the on-demand selection apps that are accessible to anonymous users. Do not select an administrative user (INTERNAL\sa-xxx) as the proxy or any user who has root admin privileges.

When creating streams that will contain on-demand selection apps that can be used by anonymous users, you must set the security rule to permit read access to the on-demand app proxy user. Failure to include read access to the proxy user will cause all of the links in the app navigation bar to show as "Invalid".

Although a single user serves as the proxy for all anonymous users, each anonymous user is identified and distinguished by the On-Demand App Service. This allows each anonymous user access to the his generated apps but prevents other anonymous users from accessing those apps. Each anonymous user can access only apps she has generated.

Number of minutes to keep apps generated by anonymous users

Specifies the amount of time an app generated by an anonymous is kept before it is deleted. The default setting is 60 minutes.

The time is measured from the last data load.

There is also a retention time setting on navigation links. For an app generated by an anonymous user, the shorter of the two retention time settings is used.

For example, when a navigation link with a retention time setting of 24 hours is used by an anonymous user and the setting for the Number of minutes to keep apps generated by anonymous users is set to 60 minutes, the app would be deleted 60 minutes after its last data load. If however the navigation link setting for retention time is 30 minutes, then the app generated by the anonymous user would be deleted 30 minutes after the last data load.

If Number of minutes to keep apps generated by anonymous users is set to zero (0), then the apps are kept for the longest time possible, which is 365 days.

Shutting down the On-demand app service

The On-demand app service is only turned off when Qlik Sense is shut down. To avoid turning off the service while requests are pending, you should notify users of the service that it will be turned off. To by sure you do not accidentally interrupt any app requests, you should disable the service and wait several minutes for any pending requests to finish before shutting down.

To find out if there are pending requests, a user with RootAdmin privileges can enter the following URL in a web browser's URL field:

https://yourhost.yourdomain.com/api/odag/v1/requests?state=qvhl&createdOnOrAfter=YYYY-MM-DDTHH:MI:SS.sssZ

where:

yourhost.yourdomain.com is the URL for your Qlik Sense proxy.

and

YYY-MM-DDTHH:MI:SS.sssZ is the timestamp of the first record in the most recent On-demand app service log file, which is the last time the service was started.

This will return an array of generating on-demand apps in JSON format. These are requests that have been started since the last time the On-demand app service was started but have not yet completed. If there are no pending requests, the response in the browser will appear as open and close square brackets:

[ ]

When the service is restarted after the shutdown, it comes up in the state it was in when the shutdown occurred. If you disabled the service before shutting it down, you must enable it again after the service is restarted.

If pending requests are cancelled because the On-demand app service has been forcibly shut down, those requests are lost and cannot be retrieved. They would have to be manually reentered when the service is restarted and enabled.

On-demand app retention times

Retention times can be set for on-demand apps when a navigation link is created. See Creating an on-demand app.

Retention times can be specified in hours or days, or they be set to never expire. All on-demand apps generated from the navigation link will be retained according to that setting. The age of a generated on-demand app is the difference between the current time and the time of the last data load. This calculation of an on-demand app's age is the same for published and unpublished apps. And if an on-demand app is published manually after it has been generated, the age calculation remains the same: it is based on the last data load of the generated app.

The retention time for apps generated by anonymous users is set in the On-Demand App Service. That setting overrides the retention time set on an on-demand app's navigation link. See the On-Demand App Service property Number of minutes to keep apps generated by anonymous users property above.

The On-demand app service runs a sweep every ten minutes to remove on-demand apps whose retention period has expired. Because the sweep runs at 10-minute intervals, an on-demand app can remain active up to ten minutes longer than its retention setting. For example, if an app has a one-hour retention setting, and its retention period ends shortly after a sweep has run, it will remain active until the next sweep.

While the retention time is based on the navigation link's setting, the retention time does not change after the app is generated. If the owner of the navigation link changes the retention time, that change does not affect on-demand apps that have already been generated.

Ownership of on-demand apps

The owner of an on-demand app is the user who generated the app. However, that user does not become the owner until the app generation has completed. While an on-demand app is in the process of loading data, the owner is INTERNAL\sa-api. That is because the user normally does not have access to the data connection used by the template app. Access to that data connection is restricted for security reasons.

If the on-demand app fails to generate completely, the QMC will show the owner of the app as INTERNAL\sa-api.

The ownership of generated apps changes when they are published. When a generated app is published, the owner of the app is the owner of the navigation link.

Anonymous users do not own generated apps because all apps generated by anonymous users must be published. An anonymous user cannot have access to an unpublished app. Apps generated by anonymous users are, however, tagged with identifiers associated with the anonymous user who generated them. That prevents an anonymous user from using apps generated by another anonymous user.

Automatically publishing on-demand apps

Navigation links have a property that allows the link creator to specify a stream to which apps generated from the link are published automatically. The user creating the navigation links must have permission to publish to the target stream, and the user who generates the app must have read permission on the stream. If either permission is missing, the on-demand app will not generate.

Anonymous users can only use published apps, and they cannot publish the apps themselves. For those reasons, anonymous users can only generate apps from navigation links that publish apps automatically.

A user who generates an on-demand app that is published to a stream cannot delete the app. Only the owner of the navigation link can delete the on-demand app from the stream.

Controlling reloads in a multi-node environment

Administrators can control where on-demand apps are reloaded in a multi-node environment. Load balancing rules are set by custom properties on the individual nodes. Custom properties can then be set on apps to direct them to use specific reload servers.

By default, on-demand apps are loaded on the reload nodes configured by the load balancing rules for the environment. However, custom properties can be set on template apps to control where apps linked to that template app are loaded.

Custom properties can also be applied to generated apps to direct them to specific reload nodes. The custom properties on generated apps can direct the apps to reload from different nodes than that which is specified for the template app from which they were generated. Custom properties are set for on-demand apps after they have been generated.

Creating load balancing rules

Creating load balancing rules with custom properties

See also: