REST callbacks not triggered on ECO approval in engineering change workflow

PLM Windchill
, , , , , , , ,
1

We have REST callbacks configured to notify our downstream systems when ECOs are approved in Windchill 12.0. The event subscription is set up correctly in the admin console and points to our middleware endpoint. The callback URL is reachable - we can hit it directly with curl and get proper responses.

The strange part is that no UI errors appear during the ECO approval process. The workflow completes successfully, the ECO state changes to Approved, but our external system never receives the notification. We’ve checked the method server logs and can’t find any failed HTTP requests or exceptions related to the callback.

The subscription filter is configured for PromotionNotice with state=APPROVED. We’ve tested with both POST and PUT methods. Has anyone encountered callbacks silently failing without generating errors? What diagnostic steps should we take to trace why the event isn’t triggering the REST call?

system 2

Based on your symptoms, here’s the complete diagnostic and resolution path:

Event Subscription Verification: The subscription setup needs three critical elements working together. First, confirm in Event Management that your subscription is truly active with the correct event type. For ECO approvals, subscribe to wt.change2.PromotionNotice with a filter on state.state=APPROVED. The event type must match exactly - case-sensitive.

Callback URL Reachability: The fact that you can curl the endpoint directly doesn’t guarantee Windchill can reach it. The method server process runs under a specific system account that might have different network permissions. Test from the method server host itself using the same account that runs the Windchill services. Check firewall rules, proxy settings in wt.properties (wt.httpgw.http.proxyHost and wt.httpgw.http.proxyPort), and verify DNS resolution from that server.

Gateway Configuration Deep Dive: You’ve enabled the EventGateway, but several related properties need alignment:


wt.eventgw.EventGateway.enable=true
wt.eventgw.EventGateway.threadPoolSize=20
wt.eventgw.EventGateway.queueSize=1000
wt.eventgw.EventGateway.retryAttempts=3

The missing piece is often the event publisher configuration. Verify that wt.events.default.publisher.enable=true is set. Without this, events are captured but never published to the gateway.

No UI Errors Explanation: Event callbacks are asynchronous and fire post-transaction. Even if they fail, the ECO approval transaction commits successfully. Errors only appear in MethodServer logs, not the UI. Enable DEBUG logging for wt.eventgw to see detailed gateway activity:


log4j.logger.wt.eventgw=DEBUG

Verification Steps:

  1. Create a simple test subscription to a basic event type (like WTPart creation) with a public webhook testing service (webhook.site) to isolate whether the issue is ECO-specific or gateway-wide
  2. Monitor MethodServer logs during ECO approval with DEBUG enabled - you should see event capture, gateway processing, and HTTP request attempts
  3. Check the EventQueue table in the database - if events are piling up there, the gateway isn’t processing them
  4. Verify the callback payload template in your subscription includes all required fields for your endpoint

The most likely root cause given your symptoms is either the event publisher being disabled or a network connectivity issue from the method server that’s different from your local curl test environment. Start with enabling the publisher and checking those specific log entries.

This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

First thing to verify - is the subscription actually active? Sometimes subscriptions get disabled during system updates. Check the Event Management console and confirm the subscription shows as enabled with a valid start date. Also verify the event type matches exactly - PromotionNotice events for ECOs can be tricky because they fire at different lifecycle stages.

4

Good catch - I verified the subscription is active and the event type matches. The start date is set to a month ago, well before our testing. I also confirmed in the database that the subscription record exists in the EventSubscription table with isEnabled=true. Still no callbacks firing though. Could there be a permissions issue preventing the system account from making outbound HTTP calls?

5

Check your method server’s xconfmanager settings. There’s a property wt.eventgw.EventGateway.enable that must be set to true for event callbacks to work. Also verify wt.eventgw.EventGateway.threadPoolSize is adequate - if it’s too low, callbacks might queue indefinitely. We had this exact issue where events were being captured but the gateway wasn’t processing them because the thread pool was exhausted by other operations. Restart the method server after making changes to these properties.

steven_func 6

Tested this on Windchill 12.1 — switching the subscription filter to wt.change2.PromotionNotice with state.state=APPROVED immediately triggered our REST callbacks on ECO approval.

7

Checked the xconfmanager and found wt.eventgw.EventGateway.enable was actually set to false! That would definitely explain why nothing was firing. I’ve enabled it and increased the thread pool size from 5 to 20. After restarting the method server, I’m still not seeing callbacks. Are there any other gateway-related properties that need to be configured? Should I be seeing specific log entries when the gateway processes events?

8

You should see entries in MethodServer-*.log with ‘EventGateway’ in them when events are processed. If you’re not seeing those, the events might not be reaching the gateway at all. Double-check your subscription’s event filter - for ECO approvals, you might need to subscribe to WorkflowProcess completion events rather than PromotionNotice state changes, depending on how your approval workflow is configured. The event type mapping can be counterintuitive.

9

The event subscription filter is actually more nuanced than it appears. Try creating a test subscription with broader criteria first to confirm the gateway is working at all. Remove the state filter temporarily and just subscribe to all PromotionNotice events to see if any callbacks fire.

Also verify your callback URL configuration includes the proper authentication headers if your endpoint requires them. In the subscription definition, you can specify custom headers in the payload template. Another common issue is SSL certificate validation - if your callback endpoint uses HTTPS with a self-signed cert, you’ll need to import that cert into the Windchill JVM’s truststore or the gateway will silently reject the connection.