QRS API Notification: Add event listener - Any examples out there?

[richbyard]

I'm trying to get a notification API call working but I'm seriously struggling with the lack of documentation around some of these APIs and no amount of guesswork is getting me to an answer...

The about APIs call allows me to see all of the parameters that could be entered.

"POST    /qrs/notification/?name={typename}&id={id}&filter={filter}&condition={condition}&changetype={changetype}&propertyname={propertyname}",

Here is my example attempt to get something working using Postman

https://nprintingrb/qrs/notification?xrfkey=DFtIXloHHm8gLqyQ&changetype=update&name=reloadTask&id=8f...

Does anyone have any info that would help identify where I'm going wrong?

Here is the help link... which isn't proving to be much help 😉

https://help.qlik.com/en-US/sense-developer/1.0/Subsystems/Qlik_Sense_Repository_Service_API/Content...

And a link to the only example I can find on Qlik Community but this is so old that this no longer works as far as I can tell

Using Sense API to get notification when scheduled task fails

ltu‌ - Levi, you seem to be a go to person here, any thoughts?

[Levi_Turner]

Hey Richard,

So as I am reading things, it looks like you're trying to create a Notification for task failures. The key elements of the API call are as follows:

• Name: ExecutionResult
  • Meaning, the QRS endpoint to monitor
• Filter: Status eq 8
  • Meaning: Status is FinishFail
  • GET /qrs/about/openapi/main returns this for the status mapping:

"status": {
                    "type": "integer",
                    "enum": [
                        0,
                        1,
                        2,
                        3,
                        4,
                        5,
                        6,
                        7,
                        8,
                        9,
                        10,
                        11,
                        12
                    ],
                    "x-enumNames": [
                        "NeverStarted",
                        "Triggered",
                        "Started",
                        "Queued",
                        "AbortInitiated",
                        "Aborting",
                        "Aborted",
                        "FinishedSuccess",
                        "FinishedFail",
                        "Skipped",
                        "Retry",
                        "Error",
                        "Reset"
                    ]
                }

• ChangeType: 2 (Update)
  • From the same endpoint as above:

        "ChangeType": {
            "type": "integer",
            "enum": [
                0,
                1,
                2,
                3
            ],
            "x-enumNames": [
                "Undefined",
                "Add",
                "Update",
                "Delete"
            ]
        }

As for the body, I have it pointing to a RESTful endpoint (body: "http://localhost:5000/notify")

This returns a handle ID:

{
    "value": "d121fdb3-d706-4a6a-9e06-ad25a4806c80"
}

which now is the handle of the notification.

Note:

• Notification Handles exist for the duration of the QRS session. A server reboot or service restart will clear these. The pro is you do not have build up of notifications to long dead endpoints. The con is that you will need to ensure that the notification is in the QRS, which isn't possible for a /qrs/notification/full style endpoint. In reality you will need to pool the QRS to do the POST to create since duplicate notifications will return the same handle.

Hope that helps.

[richbyard]

Hi Levi,

Thanks for the response.

So to clarify a few points:

1. on a QRS service restart all the notification post requests we have created (for the different status values for example) will be dropped and we will need to resend the API call(s). Is that correct, and if so I guess we'd need to poll the service to see when it's restarted.

2. If the post call is sent multiple times it will return the same handle value does this cause an issue with the notification returns it provides, will it return multiple times or just deal with the duplicates in QS and send once? for example, could we resend this API calls every 5 mins instead of polling to see the QRS service is up and running or will this cause problems?

We will do some testing on our side to see if we can get this working properly.

Cheers

Rich

[Levi_Turner]

1. on a QRS service restart all the notification post requests we have created (for the different status values for example) will be dropped and we will need to resend the API call(s). Is that correct, and if so I guess we'd need to poll the service to see when it's restarted.

Correct. There are multiple ways, some better than others, to handle this. But yes, some level of polling the QRS to ensure that it is up will be needed.

2. If the post call is sent multiple times it will return the same handle value does this cause an issue with the notification returns it provides, will it return multiple times or just deal with the duplicates in QS and send once?

So it returns the same handle and only makes 1 push to the notification endpoint.

for example, could we resend this API calls every 5 mins instead of polling to see the QRS service is up and running or will this cause problems?

That's a slightly harder question. From my end, on a small scale, there is no concern with excessive QRS impact but these servers have been relatively untaxed. Monitoring of QRS' resource consumption is strongly encouraged here (and generally monitoring the server is ideal).