Production scheduling API returns job conflict error when creating overlapping shifts

MES AVEVA MES
, , , , , , , ,
1

We’re getting job conflict errors from the Production Scheduling API in am-2023.1 when trying to create jobs that span multiple shifts. The API rejects any job where the scheduled end time extends beyond the current shift boundary, even though we have continuous operations running 24/7.


POST /api/production-scheduling/jobs
Payload: {"jobId":"JOB-8823","startTime":"2025-08-22T22:00:00Z","duration":240}
Response: 409 Conflict - "Resource allocation conflict detected"

The scheduling algorithm appears to validate resource availability only within single shift windows, not across shift transitions. This is causing significant scheduling delays as we have to manually split long-running jobs. How can we configure the job conflict detection to handle cross-shift operations?

2

The overlap approach seems like a temporary fix. I’m more concerned about the root cause - why does the default scheduling algorithm treat shifts as hard boundaries when many manufacturing operations are continuous? This feels like a fundamental design limitation.

3

The behavior you’re experiencing is actually by design for compliance and safety reasons, but it can be reconfigured for continuous operations. Let me address the three core areas:

Resource Allocation Across Shifts: The API validates resource availability using shift-based calendars by default. For 24/7 operations, you need to configure continuous resource pools:


PUT /api/production-scheduling/resources/{resourceId}/calendar
{
  "calendarType": "CONTINUOUS",
  "shiftTransitionMode": "SEAMLESS"
}

This tells the scheduler that resources can work across shift boundaries without reallocation. The SEAMLESS mode eliminates the hard boundary check that’s causing your conflicts.

Job Conflict Detection Logic: Modify the conflict resolution strategy to use calendar-based rather than shift-based validation:


scheduling.conflictResolution.mode=CALENDAR_BASED
scheduling.shiftBoundary.enforced=false
scheduling.crossShift.allowOverlap=true

The enforced=false setting is crucial - it disables the hard boundary validation that rejects your cross-shift jobs. However, be aware this also disables automatic shift change notifications, so you’ll need to implement those separately if required for labor tracking.

Scheduling Algorithm Configuration: The algorithm needs to know how to handle job splitting versus continuous scheduling:


// Pseudocode - Cross-shift job creation:
1. Calculate total job duration and required resources
2. Query resource availability across entire time window (not per-shift)
3. If continuous resources available:
   - Create single job with allowCrossShift=true flag
   - Set shiftTransitionHandling=CONTINUE
4. Else split job at shift boundaries and link as job sequence
// See Scheduling API Guide Section 8.2 for transition handling

Implementation Steps:

  1. Resource Reconfiguration: Update all 24/7 resources to use CONTINUOUS calendar type. This is a one-time setup change.

  2. API Call Modification: Include the allowCrossShift parameter in your job creation payload:


{"jobId":"JOB-8823","startTime":"2025-08-22T22:00:00Z","duration":240,"allowCrossShift":true}

  1. Conflict Resolution Tuning: The algorithm checks conflicts in this order: resource availability, capacity constraints, dependency chains, shift boundaries. By setting shiftBoundary.enforced=false, you move shift checks to the end of the validation chain where they become warnings rather than hard errors.

  2. Labor Tracking Consideration: If you need to track labor hours per shift for payroll, enable the job.trackShiftSegments=true option. This creates internal shift segments for reporting while maintaining the job as a single scheduling entity.

  3. Transition Buffer Configuration: Even with continuous scheduling, it’s good practice to define transition buffers for resource handoffs:


scheduling.shiftTransition.bufferMinutes=10

This adds a 10-minute buffer at shift changes for resource preparation, reducing the risk of actual operational conflicts.

With these changes, your 240-minute job starting at 22:00 will schedule successfully across the shift boundary. The scheduler will validate resource availability for the entire 4-hour window rather than failing at the midnight shift change.

4

There’s a constraint validation setting that defaults to shift-based in am-2023.1. You need to switch it to calendar-based validation mode. This changes the scheduling algorithm to evaluate resource conflicts across the entire planning horizon rather than per-shift segments. Check the scheduling.conflictResolution.mode configuration property.

5

Linda, our resource calendars show continuous availability across all shifts. The issue seems to be in how the API validates overlapping time windows. Even with available resources, it rejects jobs that cross the shift boundary timestamp. Is there a specific API parameter that enables cross-shift scheduling?