Production scheduling API fails to detect resource conflicts during routing updates

MES Honeywell MES
, , , , , , , ,
1

I’m updating production job routings via the REST API in the production-scheduling module. The API accepts routing changes without validating resource availability, leading to double-booked equipment and scheduling conflicts that only appear later in the UI.

When I POST updated routing steps that assign a machine already scheduled for another job during the same time window, the API returns 200 success without any conflict warnings. The schedule constraints should prevent this, but the real-time availability checking seems to be bypassed in API calls.

{
  "jobId": "JOB-5678",
  "routingSteps": [{
    "stepId": "STEP-01",
    "resourceId": "MACHINE-A",
    "scheduledStart": "2025-01-06T08:00:00Z",
    "duration": 240
  }]
}

The routing validation should catch conflicts before committing changes. Has anyone implemented proper resource conflict detection when updating schedules programmatically?

2

Here’s a comprehensive approach to implementing proper resource conflict detection for API-based routing updates:

Resource Conflict Detection: Implement a multi-step validation process before submitting routing changes:

  1. Check existing job schedules:

GET /api/v1/resources/MACHINE-A/availability
  ?startDate=2025-01-06T08:00:00Z
  &endDate=2025-01-06T12:00:00Z
// Returns list of scheduled jobs in that window

  1. Verify maintenance windows: Query the maintenance calendar to identify planned downtime that would conflict with your proposed schedule.

  2. Validate shift schedules: Ensure the scheduled time falls within active shift hours for the work center.

  3. Apply buffer times: Add setup/teardown buffers (typically 15-30 minutes) before and after your operation to prevent tight coupling.

Routing Validation with API: Use the validateConflicts flag in your routing update payload:

{
  "jobId": "JOB-5678",
  "validateConflicts": true,
  "routingSteps": [{
    "stepId": "STEP-01",
    "resourceId": "MACHINE-A",
    "scheduledStart": "2025-01-06T08:00:00Z",
    "duration": 240,
    "setupTime": 15,
    "teardownTime": 15
  }]
}

With validateConflicts enabled, the API returns:

  • 200 Success: No conflicts detected, routing updated
  • 409 Conflict: Response includes conflicting job details and overlap time ranges
  • 400 Bad Request: Invalid resource ID or scheduling parameters

Schedule Constraints Enforcement: The API validates these constraints when validateConflicts=true:

  • Resource capacity (no double-booking)
  • Sequence dependencies (predecessor steps must complete first)
  • Lead time requirements (minimum time between operations)
  • Maximum queue time (WIP time limits between steps)

It does NOT automatically validate:

  • Maintenance windows (query separately)
  • Shift calendar compliance (validate client-side)
  • Operator skill requirements (check resource capabilities)

Real-time Availability Checking Best Practices: Build a pre-validation function that runs before every routing update:


function validateScheduleUpdate(jobId, routingSteps) {
  for each step in routingSteps:
    // Check resource availability
    availability = getResourceAvailability(step.resourceId, step.scheduledStart, step.duration)
    if availability.isBooked: return conflict error

    // Check maintenance windows
    maintenance = getMaintenanceWindows(step.resourceId, step.scheduledStart, step.duration)
    if maintenance.overlaps: return maintenance conflict

    // Validate shift schedule
    shifts = getWorkCenterShifts(step.workCenter, step.scheduledStart)
    if not shifts.isActiveTime: return shift violation

  // All checks passed, proceed with API call
  return submitRoutingUpdate(jobId, routingSteps, validateConflicts=true)
}

Implement pessimistic locking: when your validation passes and you submit the routing update, there’s still a race condition window. Use transaction-level locking or implement an optimistic concurrency pattern where you include the resource’s lastModified timestamp in your request. If another process updated the schedule between your validation and submission, the API will reject with 412 Precondition Failed.

Monitor for conflicts that slip through: even with proper validation, schedule drift can cause conflicts to emerge later (jobs running longer than planned, early starts, etc.). Implement periodic schedule validation jobs that scan for conflicts and alert planners to resolve them before they impact production.

This multi-layered approach ensures routing updates maintain schedule integrity whether submitted through UI or API.

3

That validateConflicts flag is exactly what I needed - I didn’t see it documented in the API reference I was using. Is this flag available for all scheduling endpoints or just routing updates? Also, does the conflict detection consider maintenance windows and scheduled downtime, or do I need to check those separately before submitting routing changes?

4

The validateConflicts flag works on routing updates, job scheduling, and resource assignment endpoints. However, it only checks for overlapping job schedules - it does NOT automatically factor in maintenance windows. You need to query the maintenance calendar separately using the GET /api/v1/resources/{resourceId}/maintenance endpoint and cross-reference those windows against your proposed schedule. We built a pre-validation function that combines availability, maintenance, and shift schedule checks before any API call.

5

I’ve seen this behavior in HM 2023.2. The API validation is less strict than UI validation by design - it assumes you’re handling conflict checking in your integration layer. You need to query resource availability before submitting routing updates. Use the GET /api/v1/resources/{resourceId}/availability endpoint with your desired time window to check for existing bookings, then only proceed with the POST if the resource is free.

6

Don’t forget about shift schedule constraints too. A resource might be technically available but outside of operating hours for that work center. The API won’t reject scheduling during non-shift hours unless you explicitly check shift calendars first. Query the work center shift schedule and validate that your scheduledStart time falls within an active shift period. Otherwise you’ll create schedules that can’t be executed.