| Oracle® Retail Active Retail Intelligence User Guide Release 15.0 E65706-01 |
|
 Previous |
 Next |
| Oracle® Retail Active Retail Intelligence User Guide Release 15.0 E65706-01 |
|
Previous |
Next |
From the Schedule dialog, you can add, edit, and delete schedules.
You can filter the view of schedules by using the filtering buttons and fields above the schedule list.
Filter Button
The Filter button applies the filter values specified in the filter fields and re-queries the list of schedules to restrict the view to those meeting the filtering criteria.
Clear Filter Button
The Clear Filter button clears the filtering criteria at the top of the column, and returns the view of schedules to the normal view.
Filter Fields
These fields allow you to enter filtering criteria for the view of schedules.
The Schedule List
Below the filtering buttons is a list of schedules currently defined in your Active Retail Intelligence system. This list has the following fields.
Schedule Name: The name of the schedule, such as "General batch scans."
Schedule Description: Tells what kind of schedule and its signal text, single occurrence time, or repeat frequency details.
Exclusion Window: Identifies the exclusion window during which the schedule will not execute. If the first time is greater than the second the exclusion is from the first time through midnight until the second time on the following day.
The button adds a schedule.
The button deletes the selected schedule, unless it cannot be deleted because it is associated with either an exception or an event.
A schedule can only be deleted if it is not currently in use by an active exception type definition or an event type definition. If the schedule you are attempting to delete is in use, an error message is displayed, listing the names of the event or exception definitions that are using the schedule. Once those definitions have had their schedules reassigned or cleared, the schedule can be deleted. Assigning and reassigning schedules to exceptions and events is performed in the mapping screens for the Exception Manager and Event Manager dialogs.
The bottom part of the dialog is used for adding schedules
Schedule Name
The name of the schedule.
Schedule Type
Repeating, Once or Signal Driven.
Execute-on Signal
For a Signal Driven schedule this is the text string that must be sent to the accept signal API to execute the schedule.
Execute Once At
Execute once at indicates the date and time when a schedule will execute. An exclusion window used with this type of schedule forces the schedule to wait until after the exclusion window. This may seem like something that would not apply to an execute-once schedule, but an exclusion window can act as a safeguard against delayed execution (due to the scheduler not being active) occurring at an undesirable time (such as during the RMS batch window, for example).
Repeat Every
Select a whole number of hours, days, weeks, or months. Depending on the interval selected additional fields for selecting the day of the week or month and the hour and minute of the day or minutes past the hour will become enabled for specification.
Exclusion Window
This window is available for load balancing of Active Retail Intelligence exceptions or simplifying otherwise complex scheduling processes. When incrementing to the next execution date, repeating schedules increment to the next valid date beyond the exclusion window. Signal driven and execute-once schedules that are supposed to execute immediately or during the exclusion window execute as soon as the exclusion window ends. Repeating schedules execute at the exclusion window end if they are delayed (due to an inactive schedule process, not typical in production) from their normal time until after the exclusion window begins.
OK
Commits changes and returns to the summary view, re-enabling the schedule dialog main buttons that had been disabled by adding a new schedule.
OK + Repeat
Posts the added schedule and begins the addition of a new one.
Cancel
Discards the schedule currently being added and re-enables the schedule dialog main buttons.
Schedules serve two purposes:
You can attach a schedule to a batch (periodic) exception type that governs when batch scanning of the exception type occurs. Note that exception scans can be done throughout the day so that the Active Retail Intelligence administrator can do some manual load balancing of Active Retail Intelligence processes.
You can attach a schedule to an event type that defines how frequently events of that type are automatically reevaluated by the system. Volatile events that use data that is changed often or by many users or components of the system may benefit from periodic reevaluation both to save users having to reevaluate manually and to reduce their alert inbox traffic by removing resolved events before the user even sees them. As a rule events shouldn't be terribly volatile, but there may be some applications for it.
Active Retail Intelligence has a schedule process that every few minutes checks all schedules and, for those that are due to execute (or past due if the Active Retail Intelligence schedule process has been inactive for a period of time). Active Retail Intelligence then finds the associated exceptions that need scanned and events that need reevaluated and executes the scans and reevaluations accordingly.
There are three types of schedules:
Recurring: This kind of schedule starts at a specified day and time, and then recurs every "x" hours, days, weeks or months. A schedule that occurs on the 29th, 30th, or 31st of the month will not execute in a month that does not have a day with that number. After execution the schedule is incremented according to the repeat interval until the next execution date is incremented to some date and time later than the current time. By using multiple recurring schedules together (because an exception or event can have multiple schedules) a sophisticated recurring schedule pattern can be created from these simple schedules.
Once: A schedule can be set up to be executed once at a specific day and time. Provided that the Active Retail Intelligence scheduler is running (it should run constantly in production) the schedule will be executed within a few minutes of the requested time. If the scheduler is not running when the schedule is due, it will execute as soon as the scheduler is restarted.
Signal Driven: A signal driven schedule accepts a signal by calling the PL/SQL application programmer interface "ARI_SCHEDULE_SQL.ACCEPT_SIGNAL" and sending the exact signal text that the schedule requires. This will cause the schedule to set the next execute date to "right now", and so, provided the scheduler is running it will run immediately, or as soon as the scheduler is restarted. This API allows linking of one process to another. Consider that you may want to monitor for a certain exception only after some daily or weekly process occurs, and always after it occurs. However, it may be that the process doesn't occur on a rigorous schedule, so you can modify the process to call this API when it completes and so thereby link Active Retail Intelligence to the other process.
In a schedule definition, a signal is simply a text field passed to a method defined in the scheduler package, such as "nightly batch run completed." Using a signal for a schedule, you can have a simple SQL*Plus command send the signal from a shell script as:
SQL>execute scheduler.send_signal('nightly batch run completed')
It is the responsibility of the business analyst to keep the signal text consistent between the external processes and the internal schedules, as well as to coordinate the text messages used in internal definitions. That is, if two exception scans are driven from the 'nightly batch run completed' signal, it is the analyst's responsibility to make sure the text strings are properly specified in the exception schedules.
Schedules have an option of setting an exclusion window. An exclusion window applies to the schedule and thus to exception and events using the schedule. For events, an exclusion window means that an event will not reevaluate, at least not based on the schedule, during that period. For an exception, it means an hourly scan, for example, will be hourly but not during the exclusion window. A signal sent during an exclusion window will set the next execution date to the end of the exclusion window, but will not execute immediately.
You can use an exclusion window to keep an event out of the way during periods of heavy processing on related data. For example, you could disable the reevaluation of existing low-inventory events during nightly point-of-sale updates. The reevaluation of the event is then forced when the event emerges from the exclusion window. Exclusion windows don't apply to reevaluations in response to user actions.
