Qlik Community

Qlik Sense Deployment & Management

Discussion board where members learn more about Qlik Sense Installation, Deployment and Management.

Announcements
Coming your way, the Qlik Data Revolution Virtual Summit. October 27-29. REGISTER
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Specialist
Specialist

Task Reloads: How to restrict task reloads to only load between 9am and 3pm daily every hour?

Hello,

In our Swedish team we want to create a task that only reloads on from 9am to 3pm daily every hour?

So every day it would reload at 9, 10, 11, 12, 13, 14, and finally at 15:00 for the final load.

Labels (1)
2 Replies
Highlighted
Creator II
Creator II

Is this for qlik Sense Enterprise or Saas?

I don't have access to Enterprise QMC right now, but pretty sure they still don't have only run during "business hours" functionality. 

You've got a few options

1. Set your task to reload hourly and have a condition or sub routine in your script that will only run when the hour is between 9-15.  Benefit of this, it is still all self contained and everything is in one place with one task.

2. Leave your current script as is.  Create a new qvf and task with few lines of script checking the hour.  Have this scheduled to reload hourly. Chain the other QVF after this one.  If this script loads, then success, if not, you'll get an annoying fail flag that lingers for hours until the next time it successfully reloads.  The benefit of this is at a glance you can tell if it has reloaded or not without going into the dashboard and checking, because of the big red fail flag on the prior task.

3. Set up multiple daily reloads on the one tasks to run for each of the hours you want.

This is a fairly old issue so there are quite a few solutions lurking in community:

https://community.qlik.com/t5/Qlik-Sense-Deployment-Management/QlikSense-reload-only-during-business...

https://community.qlik.com/t5/New-to-Qlik-Sense/Task-Reload-Load-every-3-hours-between-0600-and-1800...

 

Employee
Employee

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