Configuring MR and OTS publish tasks
The MVS Publish Rotation Task performs the processing of MR and OTS schedules. One or more publishing tasks must be configured according to the business requirements for processing rotational schedules. For example, you can configure publishing task to ensure that schedules are always available to employees for a future period specified by a collective bargaining agreement. You can schedule multiple publishing tasks to support different publishing modes or types of rotations.
The publish mode specified for each publishing task determines its role in the rotation publishing process. These modes are available: short term, long term, and daily. After a user sends a rotation for processing, a short term task processes the immediate future schedule from the start of the publishing period. This processes the entire length of OTSs. MRs are processed for the number of days specified in the task configuration. A short term task is required for publishing MRs and OTSs.
The long term task picks up the processing of MRs after the last day processed by the short term task. The number of days processed by the long term task is specified in the task parameters. A long term task is not required for customers that are only using OTS.
The daily task ensures that full schedules are available as time progresses. When the daily task runs, it processes the next day after the last processed date for all processed MRs. A daily task is not required for customers that are only using OTS.
Example MR and OTS publishing periods
This table lists an example of publishing periods for MRs and OTSs using short term, long term, and daily publishing tasks:
| Task | Start of Publish Period | End of Publish Period | Task Frequency |
|---|---|---|---|
| Short Term | Current Date | Current Date + 55 days (8 weeks into future) | Every X minutes |
| Long Term | Current Date + 56 days | Current Date + 365 days | Every X minutes |
| Daily | Current Date + 366 days | 1 day | Daily |
All these publish tasks are configured as the MVS Publish Rotation Task, with different execution frequencies.
The parameters of each of the tasks are different. This table lists the configuration required to achieve the above publishing periods:
| Parameter | Short Term Task | Long Term Task | Daily Task |
|---|---|---|---|
| Schedule Type | MR, OTS Schedule | MR, OTS Schedule | MR, OTS Schedule |
| Publish Mode | Short Term Publish | Long Term Publish | Daily Publish |
| Publish From | Current Date | Current Date | Current Date |
| Offset | 0 | 56 | 365 |
| Offset Unit | Days | Days | Days |
| Value | 55 | 309 | 1 |
| Unit | Days | Days | Days |
| Success Status | Short Term Published | Published | Published |
| Failure Status | Error Publishing | Error Publishing | Error Publishing |
| Send Notification | Checked | Checked | Checked |
| Thread Count | 1 | 1 | 1 |
| Batch Size | 30 | 30 | 30 |
| Chunk Size | 56 | 56 | 1 |
| Suppress Publisher Notification | Unchecked | Unchecked | Unchecked |
| Team Role to Notify | <specified by user> | <specified by user> | <specified by user> |
| Backup User to Notify | <specified by user> | <specified by user> | <specified by user> |
Based on the client's operational needs, the short-term publish period can be longer or shorter than this typical 8-week period. This variation depends on the amount of future schedule information that the client wants to make available to users in the immediate future. For example, a certain organization may only require 6 weeks of schedule to be made available for scheduling transactions shortly after an MR is published. Thus, the Short Term Publishing task could end at the 6-week (42 day) mark, and the Long Term Publishing task resumes publishing after 42 days from the current date.
Registry parameters and configuration keys for rotation publishing
The registry parameter MVS_PUBLISH_LOCK_LENGTH determines the maximum number of days to lock the schedules of employees assigned in an MR. It also determines the length of time that an MR is checked for schedule compliance and shift overlaps before processing. The value of the registry parameter must be set to at least the same as the publishing length of the long-term publishing task, which is determined by adding the Value field to the Offset field. For example, if the Value is 309 and the Offset is 56, this registry parameter must be set to at least 365.
The registry parameters MR_PROCESS_VALIDATION_START_DATE and MR_PROCESS_VALIDATION_OFFSET_DAYS together determine the start date used to validate schedules for schedule compliance and shift overlaps. This start date must match the start date configured for the Short Term Publish task used to publish MRs. For example, if MR_PROCESS_VALIDATION_START_DATE is set to PAYGRP_CUTOFF_DATE, then the Publish From parameter for the Short Term Publish task must be set toPay Group Cut Off Date. Similarly, if MR_PROCESS_VALIDATION_OFFSET_DAYS is set to 0, then the Offset parameter in the Short Term Publish task must also be set to 0. This ensures the start dates are aligned for schedule validations and publishing.
Chunk Size
This parameter represents the number of days published in each rotation. It chunks the entire publishing period into manageable portions, releasing one segment at a time. If the chunk size is set to 10, each batch includes content for 10 days, ensuring a controlled and gradual rollout of the schedule.
Suppress Publisher Notification
Use this parameter to control whether the user or system process initiating the publish task receives a notification. When you select the check box, you must also consider the Send Notification parameter. Refer to this table for the behavior between the two parameters.
| Suppress Publisher Notification | Send Notification | Behavior |
|---|---|---|
| Checked | Checked | Success notifications are not sent to the user who published or processed the rotation. |
| Checked | Unchecked | Success notifications are not sent to any user.
Note: Only success notifications are suppressed when Send Notification is unchecked. Error notifications are still sent. The error notifications follow the fallback chain with the publisher excluded, unless the publisher belongs to a selected team role.
|
| Unchecked | Checked | Success notifications are sent to the user who published or processed the rotation. |
| Unchecked | Unchecked | Success notifications are suppressed for all users.
Note: Only success notifications are suppressed when Send Notification is unchecked. Error notifications are still sent. The error notifications follow the fallback chain with the publisher included.
|
This checkbox is hidden and not selected by default. To display the check box, click the Turn On Config Mode and configure the appropriate security settings.
Team Role to Notify
The Team Role to Notify list shows all the active roles for the team. Use this field to select one or more roles that will receive publish notifications. If a selected role is assigned to multiple employees, all employees assigned to that role will receive publish notifications. If Suppress Publish Notification is selected and there is no specified team role to notify, the publish notification is sent to the Backup User role. If there are no users assigned to the Backup User role, the publish notification is sent to the WORKBRAIN user.
Notifying backup users and fallback routing
Use the Backup User to Notify field to specify a backup user who receives publish notifications when the publisher is suppressed and no team role is selected. You can use backup users in cases where the original user who published an MR or OTS is no longer active or when publisher notifications are suppressed.
- Fallback logic: If you selected Suppress Publisher Notification and no team roles are specified in Team Role to Notify, notifications are sent to the user specified in Backup User to Notify. If no backup user is specified, the notifications are sent to the WORKBRAIN user.
- Explicit role precedence: If you selected Suppress Publisher, but a specified team role in Team Role to Notify includes a role held by the publisher, the publisher still receives the notification as a member of that role. Explicit team role selection takes precedence over publisher suppression.
- Notification de-duplication: The system always de-duplicates notification recipients. Any user who qualifies for notifications through multiple paths such as belonging to multiple selected roles or acting as both publisher and role member receives only one notification.
- Error notification routing: When you do not select Sent Notification, only success notifications are suppressed. Error notifications are still sent if task errors occur. Error notifications follow the standard recipient and fallback chain: publisher unless suppressed, selected team roles, backup user to notify, and WORKBRAIN. The error notifications are not sent directly to WORKBRAIN by default.