Our BOM synchronization workflow is consistently stalling when initiated from CAD integration with our external PDM system. The workflow starts normally but gets stuck at the BOM comparison stage, never progressing to the approval step. This is blocking our entire engineering change process as we can’t sync updated BOMs from CAD to Agile.
The PDM Connector logs show the connection is established successfully, but there’s no clear error message indicating why the workflow stops. We’ve verified connector permissions and network connectivity seems stable. The issue started after we upgraded to 9.3.5 last month. We’re particularly concerned about debug logging - we’ve enabled verbose logging on the connector but still can’t pinpoint where the workflow is hanging. Anyone experienced similar BOM sync workflow issues with PDM connectors?
I’ll address all three focus areas systematically based on 9.3.5 specific behaviors:
Connector Permissions:
The 9.3.5 upgrade changed permission inheritance for integration service accounts. Your PDM connector account needs:
Workflow.Execute privilege on the BOM sync workflow template
Change.Create and Change.Modify on the target change class
BOM.Compare privilege (new in 9.3.5) for BOM comparison operations
System.IntegrationCallback privilege to receive workflow status updates
Verify these in Admin > User Management > Roles & Privileges. The connector account should be in a role with “External Integration” privileges enabled. Critical: Check if the workflow has “Allow System Execution” flag set in the workflow properties - this was made mandatory for connector-initiated workflows in 9.3.5.
Network Connectivity:
The stall at BOM comparison suggests a bidirectional communication issue. In 9.3.5, BOM sync workflows use a callback mechanism:
Connector sends BOM data to Agile (outbound)
Agile processes comparison and sends results back (inbound callback)
Connector acknowledges and workflow proceeds
If the callback channel is blocked, the workflow waits indefinitely. Check:
Firewall rules allow inbound connections on the callback port (default 8080 or custom port set in connector config)
DNS resolution works both ways (Agile server can resolve PDM connector hostname)
No proxy interference on the callback channel
Network timeout settings in connector.properties: set connector.callback.timeout=300000 (5 minutes) to prevent premature disconnection
Debug Logging:
Enable comprehensive logging to identify the exact stall point:
On Agile server side, edit agile.properties:
log4j.logger.com.agile.integration=DEBUG
log4j.logger.com.agile.pc.workflow=DEBUG
On PDM connector side, set in connector-log4j.xml:
Enable workflow audit trail: Admin > Workflow > Settings > Enable Detailed Audit (this logs each workflow step execution time and status)
Most importantly for BOM sync issues, enable BOM comparison logging:
log4j.logger.com.agile.pc.bom.comparison=TRACE
This will log each BOM line item comparison result, showing where the process stalls. Look for log entries like “BOM comparison initiated” followed by “BOM comparison completed” - if you see the former but not the latter, the comparison itself is hanging.
Check thread pool status: The workflow may be starved for threads. In agile.properties, verify:
workflow.external.maxThreads=20 (increase from default 10)
workflow.queue.maxSize=500
After enabling these logs, reproduce the issue and examine both Agile server logs and connector logs simultaneously. The stall point will be visible as the last logged operation before the hang. Common culprits in 9.3.5: large BOM comparisons exceeding memory limits, orphaned workflow instances holding thread resources, or database lock contention during BOM insert operations.
If logs show BOM comparison completes but workflow still stalls, check the workflow transition conditions - 9.3.5 added stricter validation for transition criteria, and invalid conditions cause silent workflow stops rather than errors.
This draft is based on general Oracle Agile PLM knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check if the connector service account has execute permissions on the workflow itself, not just read/write on BOM objects. We had a similar issue where the connector could create BOM changes but couldn’t trigger the associated workflows due to missing workflow execution rights.
Jennifer, the 9.3.5 upgrade introduced stricter validation for BOM structure during sync operations. If your PDM system sends BOM data with invalid references or missing required fields, the workflow will stall silently instead of throwing an error. Enable database-level logging to see if there are constraint violations during the BOM insert phase. Also check if your PDM connector timeout settings are sufficient for large BOM transfers.
I’ve dealt with this exact scenario. The workflow stall is usually caused by the connector waiting for a callback from Agile that never arrives. This happens when the BOM comparison process times out but doesn’t fail gracefully. Check your network firewall rules - some configurations block the response channel from Agile back to the PDM connector, causing the workflow to hang indefinitely waiting for acknowledgment.
Look at the workflow queue status in the Agile server logs, not just the connector logs. The workflow might be stuck in the queue waiting for resources. After the 9.3.5 upgrade, there were changes to how workflow threads are allocated for external integrations. You may need to increase the workflow.external.maxThreads parameter in your Agile configuration. Also verify that the BOM sync workflow has the correct privileges set for system-initiated workflows - user-initiated and system-initiated workflows have different permission requirements in 9.3.5.
We found that the connector service account was missing workflow execution permissions. After granting those, the workflow progressed further but now stalls at a different point. We’re investigating the thread allocation settings Kim mentioned.