Note: subscriptions created using the Notification API are transient. They will not exist after the Qlik Sense Repository Service restarts. For production integrations, a methodology for polling the Repository to determine whether it has restarted / has the handle will need to be created. In the Qlik Sense Event Driven Cross Site App Promoter project, a NotificationCreator service is used to ensure that the subscription is always present in the Repository Service.
Note: In this post we will use screenshots from Postman since it does a good job of visually displaying the elements of an API call. These calls can be made using any scripting / programming language which can issue RESTful API calls.
Overview of the Repository Notification API
When creating a notification handle, there are 3 key params:
The Nameparam refers to the Repository entity that a change subscription should be configured for. This can be ExecutionResult(when monitoring task progress), App(when monitoring changes to an App), or any path where there is a Repository API (/qrs/path/..).
For a full listing of endpoints which are exposed on your version of Qlik Sense, issue aGET /qrs/about/api/descriptionAPI call.
The changeTypeparam refers to the numeric value of the change. The current values as of Qlik Sense September 2018, which were discernible via aGET /qrs/about/openapi/maincall, are:
The filter param is optional, but generally encouraged. For the specific value, a close inspection of the spec for the Name which will be monitored is needed. Since this example is focusing on tasks, the ExecutionResult spec, which is discernible via a GET /qrs/about/openapi/main call, is as follows:
If we want to monitor on a task which fails due to a script related problem, then the status value that we are interested in is FinishedFail which has a numeric value of 8.
The PropertyNameparam is also optional. Much like the filterparam, you are doing further drill downs. But instead of doing a filter on the entity specified in the Name, you are monitoring changes on the property of the entity without specifying a known value. For example, if you wanted monitor for when an app is published, you can create a subscription with this config:
This will provoke a response when:
An app is published
Any published App changes (e.g. it’s renamed)
For the use of monitoring the pure publish operation, there are other scenarios where you want covered:
When an app is published via publish and replace
When an app is moved to a new stream
To allow for coverage of those scenarios, we can create a subscription with the following config:
A clean distinction between PropertyNameand Filteris that PropertyNameis a reduction in the monitoring space but without unknown values. In the above scenario, we do not know what the publishTimewill be, but merely that we want to monitor for changes in that element of the App’s entity. Filters, on the other hand, require known values.
The conditionparam likewise is optional. This param allows a script / API call to be issued and handle created only if the conditionis fulfilled. When the conditional is not, fulfilled, a null GUID for the handle will be returned:
Reload failure specific work-flow
To continue with the specific work-flow on task failures, for the params section of the POST that we will construct to create the subscription is: