There are a few ways to tackle this problem. I'll outline a couple. If I had to do this myself and potentially do this multiple times, I'd go with the scripted method (option 2). But strictly speaking Qlik's underlying Repository API supports cron syntax which exposes this style of capability if you're comfortable making API calls.
Option 1 - Inside Qlik, Chained tasks
As @squeakie_pig pointed to, handling this in the script itself in a chain is one way. The pro of this is that it's easy to implement. I'd imagine you'd basically have a if/else check with the non specified hours using a syntactically invalid script to cause a failure. The con though is that you're going to have the parent task fail throughout the day. It's super easy to implement but ultimately a bit dirty.
Option 2 - Scripted Approach
Another method would be to externalize the task triggering. This can be easily accomplished in Windows PowerShell using Qlik-Cli (https://github.com/ahaydon/Qlik-Cli-Windows). Then use the Windows Task Scheduler to execute the PowerShell script every hour (see here for a pointer on the Task Scheduler bits). The pro here is that it's pretty darn easy to repeatedly use this. Example Script:
$hourBegin = '9' # Start Hour
$hourEnd = '15' # End hour
$taskId = '2749be11-f67e-4e1f-ad8c-b0037e9f72ff' # Target Task's ID
if ((Get-Date).hour -ge $hourBegin -and (Get-Date).hour -le $hourEnd) {
# True. Current hour is between $hourBegin and $hourEnd
Connect-Qlik | Out-Null # Connect to Qlik Sense
Start-QlikTask -id $taskId | Out-Null
} else {
# False. Current hour is not between $hourBegin and $hourEnd
}
Option 3 - Fully native interacting with the Repository API
So this will require some non-trivial API work but the Scheduling bits of the Repository API do allow for sophisticated schedules like you're after. At the outset, you're going to want to have a method for interacting with the Repository API. This (https://community.qlik.com/t5/Qlik-Support-Knowledge-Base/How-to-configure-Postman-desktop-app-to-co...) is a good walk through.
Like I mentioned above, the Scheduler allows for cron syntax. Reference https://crontab.guru/ if you want a guide on building this syntax.
The key bits to a time-based trigger (SchemaEvent) is the SchemaFilterDescription field. For an explainer:
Default: "* * - * * * *"
This is a list of SchemaFilterDescriptions used to filter when a SchemaEvent is allowed to trigger. An important thing to remember is that what is set as SchemaFilterDescriptions are when it is allowed to trigger and not the opposite.
For Minute, Hour, WeekDay (using numeric values), DayOfMonth and Month you can use syntax with hyphen to state “from - to”. For the others you must state each character to be used in the SchemaFilterDescription, this can of course also be used by Minute, Hour, WeekDay, DayOfMonth and Month as well. Example: You only want to allow the first 15 minutes each hour you can either put ‘1-15’ or ‘1,2,3,4,5,6,7,8,9,10,11,12,13,14,15’ in the first position. There should be no spaces in the SchemaFilterDescription other than between each position, the space character is used as a delimiter between the positions so inserting one would cause the SchemaFilterDescription to, at best, not work as intended or most likely to cause an error.
Starting from left to right (first position is 0) each position is explained below.
Position 0 - Minute
Legend: 1-60. ‘*’ = all
Which minute of an hour (0 - 60) when the SchemaEvent is allowed to trigger.
Position 1 - Hour
Legend: 1-24. ‘*’ = all
Which hour of a day (1-24) when the SchemaEvent is allowed to trigger.
Position 2 - WeekDayPrefix
Legend: 1-4. ‘¤’ = last. ‘-’ = none
WeekDayPrefix works together with WeekDay by adding a prefix. By means of this you can state that only the last (¤) friday in a given month or 1st (1) saturday in a given month is allowed.
Position 3 - WeekDay
Legend: 0-6 (where sunday is 0)
Which weekday the SchemaEvent is allowed to trigger. See also WeekDayPrefix for further information.
Position 4 - WeeklyInterval
Legend: An integer. ‘*’ = all
The SchemaEvent is allowed to trigger every n:th week, where n is the number set in this position.
Position 5 - DayOfMonth
Legend: 1-31. ‘*’ = all. ‘¤’ = last
Which day within a month when the SchemaEvent is allowed to trigger. Using last (¤) the Scheduler will only allow the SchemaEvent to trigger on the last day in a month which is checked dynamically depending on month (and leap year).
Position 6 - Month
Legend: 1-12. ‘*’ = all
Which month of the year when the SchemaEvent is allowed to trigger.
Examples:
Certain date in month
Case 1
Premise: Run the first every month.
SchemaFilterDescription: “* * - * * 1 *”
Explanation: Position 5 is set to ‘1’ which means the only day number 1 in any given month is allowed for this SchemaEvent.
This SchemaEvent should increment one day (ie. “0 0 1 0”).
Certain weekdays
Premise: Run monday and wednesday every week.
SchemaFilterDescription: “* * - 1,3 * * *”
Explanation: Position 4 is set to ‘1,3’ which means only monday and wednesday are allowed for this SchemaEvent (0 is sunday).
This SchemaEvent should increment one day (ie. “0 0 1 0”).
As for the practical steps:
Step 1: Get the Reload Task information
GET /qrs/reloadtask/7a1bce82-c8f1-438a-a0af-666e27b1553a
Example Response (I've chopped off bits from here which aren't relevant):
{
"id": "7a1bce82-c8f1-438a-a0af-666e27b1553a",
...
"app": {
"id": "5e34dbc8-bc07-4377-906d-bb370853d731",
"name": "Random Data",
"appId": "",
"publishTime": "2020-06-18T15:01:34.344Z",
"published": true,
"stream": {
"id": "aaec8d41-5201-43ab-809f-3063750dfafd",
"name": "Everyone",
"privileges": null
},
...
},
"isManuallyTriggered": false,
"operational": {
"id": "c1352446-f0b4-484c-a9a2-59bb0156ba03",
...
},
"nextExecution": "1753-01-01T00:00:00Z",
"privileges": null
},
"name": "Super Special Reload",
"taskType": 0,
"enabled": true,
"taskSessionTimeout": 1440,
"maxRetries": 0,
"tags": [],
"privileges": null,
"schemaPath": "ReloadTask"
}
- You will want the id and operational.id values
Step 2: Create a SchemaEventOperational. This is a handle for a SchemaEvent which is a time-based trigger.
POST /qrs/schemaeventoperational
Body: {}
Example Response:
{
"id": "16e321d5-a869-48bc-8e5e-0b03b9cd4a70",
"createdDate": "2020-07-29T21:14:40.46Z",
"modifiedDate": "2020-07-29T21:14:40.46Z",
"modifiedByUserName": "INTERNAL\\sa_repository",
"lastEventDate": "1753-01-01T00:00:00Z",
"nextExecution": "1753-01-01T00:00:00Z",
"timesTriggered": 0,
"privileges": null,
"schemaPath": "SchemaEventOperational"
}
Step 3: Create the SchemaEvent. This is the time-based trigger.
POST /qrs/schemaevent
Example Body:
{
"timeZone": "America/New_York",
"daylightSavingTime": 0,
"startDate": "2020-07-09T10:00:00",
"expirationDate": "9999-01-01T00:00:00",
"schemaFilterDescription": [
"* 9-15 - * * * * *"
],
"incrementDescription": "0 1 0 0",
"incrementOption": 1,
"operational": {
"id": "16e321d5-a869-48bc-8e5e-0b03b9cd4a70"
},
"name": "Hourly 9A-3P",
"enabled": true,
"eventType": 0,
"reloadTask": {
"id": "7a1bce82-c8f1-438a-a0af-666e27b1553a",
"operational": {
"id": "c1352446-f0b4-484c-a9a2-59bb0156ba03"
}
}
}
Notes:
- operational.id --> From Step 2
- reloadtask.id & reloadtask.operational --> From Step 1
- You may very well need to or want to change the timeZone and daylightSavingTime settings.
- Adjust the startDate value from 09:00:00 to some other minute and second if desired.
Hope that helps
