Understand shift changes

At its initial startup, the MES middleware that is currently handling the maintenance tasks checks whether it is time to change any shifts. If it is time, the middleware checks for the shift changes that are due (because the period, during which the MES middleware was off, might have exceeded the time for which future shifts had been projected). It also updates the shift_to_go table with the projected shift schedules for the next 7 days for each entity that has shifts. Finally, it creates a record in the dx_queue table to process SCC schedules against the shift change.

After the initial startup, the middleware handles the shift change process on a minutely basis (at the start of the minute) as follows:

• For each entity that is assigned to a shift pattern, the MES middleware checks if it is time to change shifts. If it is, then those shifts will be changed for the entity and any of its child entities that inherits those shifts. If there are many entities changing shifts at the same time, the MES middleware might take several seconds to complete the shift change process.

• If a shift ends on an entity and there is no following shift, then the MES middleware changes the entity's shift property to No Shift (which has a shift ID of 0).

The shift information for all the entities that have shifts assigned to them, either directly or inherited, is recorded in the shift_history table. This table is updated automatically as a part of the shift change process. If a shift pattern or schedule is changed, the MES middleware will change the shift information during the next minutely task execution.

The shift change process also does the following:

• If the entity did not have a shift start time after the supplied shift start time, the supplied (intended) shift start time is applied. Otherwise, the current datetime is used.

  For example, say the regular shift schedule is 6 am to 2 pm.

  • Scenario1:

    The middleware maintenance service was down between 6–11:30 am, so the shift change was not recorded in the database. At 11:30 am, the middleware is restarted. Since the entity did not have a shift change after 6 am, the shift change is processed and the shift start is set to 6 am for the entity. The last shift start time was prior to 6 am.

  • Scenario2:

    The middleware maintenance service was down between 6–11:30 am, so the shift change was not recorded in the database. However, client-side code called a stored procedure directly and not through the middleware (which is not recommended) to start the shift at 10 am and so the entity shift was changed at 10 am. The middleware starts again at 11:30 am and intends to put the shift start time at 6 am, but finds that the entity is in a 10 am shift (which is after 6 am). So the entity is put into an 11:30 am shift if the 6 am shift information is different than the 10 am shift that was processed directly in the database.

    In summary, if the shift start time is in the past and if there are shifts later, then the middleware won't go back in the past. Instead, the current datetime is set as the shift start.

• After the shift change transaction is completed successfully, any incorrect shift information in the item_prod, item_cons, data_log, and labor_usage tables is updated. This includes any transactions that happened during the shift change process that have the previous shift information recorded.

Projecting Future Shifts

On a daily basis, for each entity that has a shift schedule, the middleware creates projected shift records for the next 7 days in the shift_to_go table. Each record includes the start and end time of the projected shift.

If any shift pattern changes have caused existing projected future shifts to be out-of-date, those records are updated. But updates are made only to shift records for the next 7 days. Records for shifts that occurred prior to the current day are never updated.

These shift projections are performed only for compatibility with legacy Stateful and Stateless API methods. They are not used internally by the system to actually manage shifts.

Shift Changes and Utilization Events

• If an entity that captures utilization reasons is changing to a non-zero shift and there is a shift start reason code configured for the entity, then a new utilization event is generated for the entity. The new utilization event will use the configured shift start reason code and the shift start time as the event start time. The shift start reason code takes precedence over a shift end reason code.

• If an entity that captures utilization reasons has a shift end reason code configured, the shift end reason code is used in the following conditions when a new utilization event is created with the event timestamp equal to the shift start time:

  • The entity is changing to a non-zero shift and there is no shift start reason code configured.

  • The entity is changing to a zero shift (no shift).

• If a shift start or shift end reason code is not configured for an entity that captures utilization events, the utilization reason that was generated earlier is continued in the current shift. That is, a new utilization event is not generated for the change of shift.

Shift Changes and QM Samples

The middleware maintenance service generates new QM samples that are based on the shift, where either the sample plan frequency type is Shift or no value is specified for generating future samples. The shift change takes more time to allow samples to be generated up to 5 minutes in the past. This ensures that events scheduled at the beginning of the shift are generated before the shift change process is complete.

Shift Events That Cause an Entity's Shift Change Process to Terminate

The MES middleware terminates the shift change process for an entity and any child entities that inherit its shift patterns in the following cases. This is done because shift generation depends on correct shift information.

• If updating the entity's past shift fails.

• If the entity's normal shift change fails 15 times in a row.

• If there was a deadlock/timeout during the entity's shift change, then the middleware retries the transaction for up to 6 times (default configuration) before terminating the process. Any failed transactions other than deadlocks/timeouts will be terminated immediately (i.e., retries are not performed).

The shift changes for entities that are not affected by these failures will be attempted on a fresh shift change transaction.