Simulation results not syncing to external PLM after integration setup complete

PLM Aras Innovator
, , , , , , , ,
1

We recently completed integration setup between Aras Innovator 13.0 and our external PLM system for simulation data management. The connector appears to be working - no errors in the logs - but simulation results generated in Aras are not appearing in the external system.

We’ve verified that the simulation files are being created correctly in Aras and the metadata is complete. The integration connector shows successful execution status, but when we check the target PLM system, the simulation results are simply missing. We need to understand if this is a connector mapping issue, a file transfer permissions problem, or something else entirely. Has anyone encountered similar silent failures with simulation data integration?

system 2

Let me provide a comprehensive troubleshooting approach that addresses all three key areas: connector mapping, file transfer permissions, and debug logging.

Step 1: Enable Debug Logging for Payload Analysis Modify your InnovatorServerConfig.xml to enable detailed integration logging:

<log level="TRACE" category="Integration.Connector" />

Restart the application pool and trigger a sync. Review the logs at [InstallDir]\Innovator\Server\Logs for the actual payload being transmitted. Look for entries showing the REST/SOAP calls to the external system.

Step 2: Verify Connector Mapping Configuration Open the integration connector item in Aras and review the field mapping configuration. Simulation results require specific mappings:

  • Simulation metadata (solver type, analysis parameters)
  • Result file references (mesh files, result datasets)
  • Related item associations (source CAD model, analysis setup)

Most importantly, check if the connector is configured to handle file attachments. Simulation results aren’t just metadata - they include binary result files that need separate handling.

Step 3: File Transfer Permissions Validation Verify the service account permissions:

  1. Check the Windows service account running the Aras application pool
  2. Verify this account has write access to the external PLM’s file vault
  3. Test file creation manually using the same credentials
  4. Review firewall rules if the external system is on a different network segment

Step 4: Payload Structure Validation Use the debug logs to capture the actual JSON/XML payload being sent. Compare it against the external PLM’s API documentation. Simulation data often requires nested structures that don’t map automatically.

Step 5: Asynchronous Processing Check If simulation results are generated asynchronously, implement a workflow event that triggers the integration connector only after file generation is confirmed complete. Don’t rely on immediate synchronization.

Testing Protocol: Create a minimal test case - a simple simulation with a small result file. Walk through each integration step manually using API testing tools like Postman to isolate where the failure occurs. This will definitively show whether it’s a mapping issue, permissions problem, or timing conflict.

In 90% of cases I’ve seen, it’s either incomplete field mapping (missing file attachment configuration) or service account permissions on the target file system.

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

3

Silent failures like this usually point to mapping configuration issues. Check your connector’s field mapping configuration - simulation results often have complex metadata structures that don’t map cleanly to external systems. The connector might be succeeding at the connection level but failing to properly transform the data payload.

4

I’d start by enabling debug logging for the integration connector. In Aras 13.0, you can set the log level to TRACE for the integration service, which will show you exactly what payload is being sent to the external system. This will quickly reveal whether the data is actually being transmitted or if it’s failing silently before transmission. Check both the Aras logs and any logs available on the external PLM side.

6

File transfer permissions are often overlooked in integration scenarios. Simulation results typically include large binary files (mesh data, result sets) that need to be transferred separately from the metadata. Verify that the service account used by the connector has write permissions to the target file repository in the external PLM system. Also check if there are file size limits or allowed file type restrictions that might be blocking the transfer.

7

Have you checked the connector’s transformation scripts? Simulation data often requires custom transformation logic to match the external system’s schema. The default mappings might not handle all the required fields, especially for complex simulation metadata like boundary conditions, solver parameters, or result timesteps.

9

We had this exact problem last year. The issue was that our connector was configured for synchronous operation, but simulation result files were being generated asynchronously. By the time the connector tried to transfer the files, they weren’t fully written yet. Switching to an event-driven approach where the connector triggers after file generation completes solved it completely. Check your timing configuration.