<< Click to Display Table of Contents >> Navigation:  Scheduler > Understanding requests, request groups and schedule periods

A Schedule is a 7-day time period which repeats automatically until it is specifically stopped or altered. The schedule contains a freely defined number of schedule periods.

Schedule period is a time period in the weekly calendar. It has a start and an end; they can be within the same day or they can span over to multiple days. For example, a library is likely to be closed from evening to the next morning; this would mean a period that starts in evening and ends the following morning. The period can also run over the end of week to beginning of next week; a library can be closed from sunday evening to monday morning.

Each schedule period has a type. There are three types of periods: Open (also referred to as Manned), Closed and Self operated. This indicates in which mode the library is on. These are pre-defined and can not be altered. It is however possible to define several request groups that are of the same type but have different request; thus, the library can be open in different ways. This is controlled by request groups, which in turn are made of requests.

A Request in this context is a request made by the system to other components in the system. A request can be an IO-request to turn on lights or open a door, an audio request to play an audio announcement, or a workstation request to start or shut down computers running self service software. These requests are grouped together to form request groups so that controlling all that happens when a library opens is tied together.

Request group is simply a group of requests that happen together. The requests are connected to schedule periods; either the start or end of a period. A time delta value can be given in minutes, for example to turn on lights 15 minutes before the period "Open" begins.

Grouping requests and connecting them to periods means that altering a period in a calendar will "take with it" all the requests, and their timing. This makes it extremely easy to change any period in a schedule. If a request is tied to "Open" period saying the lights should be turned on 15 minutes before the period starts, then changing the time when the "Open" period begins - dragging the period in the calendar - will make the lights turn on 15 minutes before that time, regardless of what that time eventually is.

IMPORTANT NOTE: With this flexibility comes also some complexity. It is possible to create request groups that lead to unintended results. For example, if you make a request to turn on lights 15 minutes before "Open" period, and another one to turn off lights half an hour after "Closed" period ends, this will cause a problem if you create a short, half an hour closed period like a lunch break. Because, say that

 At 12:00, Closed period ends and Open period begins

 At 15:00, the library closes for half an hour

 At 15:30 the library opens again.

 This means, that at 11:45 the request connected to Open period turns the lights on. All is well so far.

 At 15:00 the library closes. Lights are set to turn off half an hour later, at 15:30

 At 15:15, the lights will be turned on because the Open period requests it to happen 15 minutes before starting.

 At 15:30 the library opens - and at the same time, the lights go out! This is because the Closed request is now half an hour ago, and it closes the lights.

It is important to be carefull. We recommend only using period start as the anchor of events if at all possible. There is also a "Preview" button available the SOL Administrator software which displays all requests as they happen, making it easier to see possible conflicts.