The Scheduler user interface in Tech Toolkit enables users to adjust the timing and other settings of the currently defined tasks. End users cannot add new tasks to Scheduler at this time other than by doing do from Prism, e.g., by creating a new Markdown. The main use for the Scheduler UI in Tech Toolkit, is to provide an easy way for users to adjust the settings of existing scheduled tasks such as time of day to run, interval/how often (daily, every other day), or to turn a task off.
Key Uses of Scheduler UI in Tech Toolkit
- Adjust default settings of tasks to better match business hours, data loads, or other factors
- Check the success or status of specific scheduled tasks
- From time to time, delete once-only tasks that have successfully run
To access Scheduler: Click the Scheduler tab on the Tech Toolkit menu.You will see the list of default tasks:
The Tech Toolkit Scheduler is a user interface to the Retail Pro PrismSchedulingService. The PrismSchedulingService is a Windows service that runs in the background and executes tasks defined in Scheduler. Tasks are API processes, technically termed "actions," which perform specific functions.
|Customer History Daily Process||Generates Customer History records from POS transactions and customer orders. Repeats every 15 minutes.|
|Customer History Initialize Process||This is a one-time operation set to run during the night after the new CH feature is first installed. This process generates CH records from past transactions. After that, the CH Daily process is responsible for generating CH records as customer transactions are created.|
|Purge Scheduled Task Run records||This is a system housekeeping task that clears out past task run history records based on the value in DaysOfRunHistory field in each task record. A value of 0 means keep all task run records. A value greater than 0 means keep only the most recent
|Update Active Season||This task updates the Active Season, if needed, based on the date range for Seasons defined in Prism preferences. The Active Season is used for seasonal pricing and is displayed in Subsidiary and Store records.|
|Cleanup PI Sheet||1) PI Sheet results will show a 'Creation' status(to give info about creation of new PI Sheet only) column with these values : Completed, Failed, Pending(shows Spinner)
2) If there is pending PI Sheet to be created, that PI Sheet can't be selected in the grid and no further actions are possible unless the PI creation is completed or failed
3) Inactive PI Sheets can be deleted from UI, new 'Delete' button is added to button bar. [Only Inactive PI Sheets can be deleted - Behind the scene deletion process is actually handled by the scheduler-TTK, in UI it just filters out PI Sheets which are marked for deletion]
4) If the new PI Sheet creation is failed then it would be made inactive and shows the PI result grid
View Task Information
View Task Information
Click a task in the list to display details about the task. Note: There are restrictions on what fields can be edited and which tasks can be deleted. Below are sample task details for the Cleanup PI Sheet task.
|Start Date||Day and time the task will start.|
|End Date||Day and time the task will end, If null then no end date.|
|Start Time||Start time for the time frame that the task can be run.|
|End Time||End time for the time frame that the task can be run.|
|Active||True if the task should be run currently. Inactive tasks will not be run.|
|Task Run Interval||(OneTime, Daily, Weekly).|
|Recur Every||Recur Every is based on Frequency, For instance if set to Daily and Recur Every is 1 the task will run every day, If set to 2 the task will run every other day.|
|Repeat every n||Repeat every N Seconds or Minutes.|
|Timeout (seconds)||Number of seconds to wait for service to start. Default 60 seconds. 0 means wait forever, -1 means do not wait at all, Positive integer is how many seconds to wait.|
|Days of the Week||(weekly tasks only) Seven-character string of zero or one. specifying SMTWTFS zero being false and 1 being true. Only applicable to Weekly schedules.|
|Max Retries on Error||Tells the Scheduling service to set a task to not active if it throws consecutive < MaxRetries # > errors. User can re-set task to active and execution cycle will attempt again. If Max Retries is null or 0, it is ignored by Scheduling service.|
|Days of Run History||If > 0, it tells the Scheduling service to keep only
|Workstation||Must be populated only for some tasks whose action requires a workstation "sit", such as price manager actions. Otherwise, can be left blank. However, if populated for a task that does not require it, the workstation populated must be valid otherwise the task will not run.|
|Action URL||Action URL with parameters. This is the path to the resource in the Prism API and the type of action that will be performed
(e.g. /api/common/?action=updateseason )
Note: You should not edit the Action URL.
|Action Payload||If required, a JSON CLOB for the request payload. Note: You should not edit the Action Payload.|
|Task Edit/Delete||Default = OK Edit No Delete.|
|Task Type Code||Four-character alpha-numeric free-form field to allow users to group or filter tasks. For example: PM for price manager or PMM for price manager markdown. Or, SYS for system. Currently grouping and filtering has not been implemented in the UI but will be in later release as more tasks get added to the Scheduler.|
|Public flag||If selected, only Public schedules will be replicated.|
Adjust Customer History Daily Process for High Volume Environments
If you will be operating Prism in a high-volume environment in which all or most of the customers are defined customers in the database, special configuration is required to ensure that Customer History is processed more quickly than the default setting of once every 15 minutes. In a high-volume environment, when using the default Customer History settings, transactions will accumulate before the next processing. By setting the processing timer to a smaller value, e.g. two minutes or five minutes, customer history will be processed more quickly, preventing the build-up of unprocessed transactions. High Volume POS transactions for Customer History purposes means transactions with customers that have an account. If half of the transactions are to customers without an account with the store, Customer History processing ignores those when fetching documents to process - so no impact on memory. When setting RepeatEvery to a lower number, Days of Run History should be reduced to 2 or 3 so that Prism is not storing needless thousands of run history records. Default Start and EndTimes should be tweaked per store business hours. Otherwise Customer History will run needlessly and create task run records.