REST API update to engineering change order fails with 409 Conflict when ECO is in review state

PLM Windchill
, , , , , , , ,
1

Attempting to update an ECO via REST API returns 409 Conflict error, but the same update works perfectly through the UI. The ECO is in ‘In Work’ state and our service account has Change Administrator privileges.

The error message mentions “object state conflict” but doesn’t specify what’s actually conflicting. We’re trying to add affected items to an existing ECO as part of our automated change workflow. The REST API update restrictions seem stricter than UI operations, but I can’t find documentation on what’s different.


PATCH /Windchill/servlet/odata/ChangeMgmt/EngineeringChanges('12345')
Response: 409 Conflict
{"error": "Cannot modify object in current state"}

Is there special lifecycle state permission handling for ECO updates via API?

2

I’ve seen this where the ECO has pending change tasks that must be completed before modifications are allowed. Even in ‘In Work’ state, if there are open tasks assigned, the object is effectively locked from external updates.

3

Good point about checkout. I verified the ECO isn’t checked out to anyone. But when I try to check it out via API first, I get the same 409 error. Could this be related to ECO workflow configuration preventing programmatic modifications during certain lifecycle states?

4

Let me provide a complete solution covering all three focus areas:

Lifecycle State Permissions: The 409 error indicates state-based restrictions that differ between UI and API access. Here’s how to diagnose and fix:

  1. Check State Permissions:

    • Navigate to Type and Attribute Management > Change Objects > ECO
    • Review lifecycle template and state transition rules
    • Verify your service account has MODIFY permission for ‘In Work’ state
    • Key difference: UI users get implicit permissions through active session context, API accounts need explicit grants

  2. Verify Workflow Gates:

    • ECO workflows often have conditional gates that check request source
    • Look for expressions like “if (requestSource != ‘API’) allow modification”
    • Update workflow template to permit API modifications in appropriate states

REST API Update Restrictions: API updates require explicit handling that UI does automatically:


// Step 1: GET current ECO with ETag
GET /Windchill/servlet/odata/ChangeMgmt/EngineeringChanges('12345')
Response Headers: ETag: "abc123xyz"

// Step 2: Check out if needed
POST /ChangeMgmt/EngineeringChanges('12345')/CheckOut

// Step 3: PATCH with ETag for optimistic locking
PATCH /ChangeMgmt/EngineeringChanges('12345')
Headers: If-Match: "abc123xyz"
Body: {"affectedItems": [{"id": "OR:wt.part.WTPart:67890"}]}

Critical requirements:

  • Always include If-Match header with current ETag
  • Check out object first if checkout is required by lifecycle
  • Use working copy ID in PATCH if object is versioned
  • Check in after modifications complete

ECO Workflow Configuration: Workflow-specific restrictions causing 409:

// Pseudocode - Workflow gate modification:

  1. Open ECO lifecycle template in Workflow Administrator
  2. Locate ‘In Work’ state and associated activities
  3. Check for workflow variables: allowAPIModification, requireApproval
  4. Add condition: IF (modificationSource == ‘REST_API’ AND changeType == ‘AFFECTED_ITEMS’) THEN allow
  5. Ensure no pending tasks block modifications - query task status before PATCH // Common blocker: open review tasks prevent affected item changes

Common 409 Causes:

  1. Concurrent Modification: Another process modified ECO since your GET - solution: retry with fresh ETag
  2. Workflow Lock: Pending approval/review task - solution: complete task first or modify workflow to allow parallel updates
  3. Missing Checkout: Object requires working copy - solution: explicit CheckOut before PATCH
  4. State Restriction: Lifecycle forbids modifications in current state - solution: transition to editable state first
  5. Related Object Lock: Affected item is locked - solution: check referenced objects aren’t checked out elsewhere

Validation Steps: Before PATCH, programmatically verify:

  • ECO checkout status (GET CheckOutStatus)
  • Active workflow tasks (GET /WorkflowTasks?eco=12345)
  • Current lifecycle state allows modifications
  • All referenced affected items are accessible
  • ETag matches current version

Implement retry logic with exponential backoff for transient conflicts. Enable detailed logging: wt.change.api.debug=true to see exact conflict reason.