We’re experiencing failures when pushing Manufacturing Change Orders (MCOs) to our downstream MES and ERP systems. The MCO metadata transfers successfully, but file attachments consistently fail during the connector handoff.
Our integration uses a custom Java connector that reads MCO datasets and pushes them through our middleware. The attachment mapping appears correct in the configuration, but files aren’t reaching the target storage location. We’re getting intermittent errors:
ERROR: FileTransferException - Unable to locate source file
at ConnectorFileHandler.transferAttachment(line 234)
Source path: /tc_vault/mco_attachments/
Target configured: /mes_staging/incoming/
The connector supports both FTP and direct file system transfer. Storage location configuration points to our network share, but I’m wondering if there’s a permission issue or if the attachment reference isn’t being resolved correctly before transfer. Has anyone dealt with similar attachment transfer problems in MCO integrations?
Your issue stems from incomplete attachment mapping and premature transfer attempts. Let me address all three critical areas:
Attachment Mapping Resolution:
The connector must properly resolve dataset references before transfer. Modify your connector to use the Teamcenter DataManagementService to get the actual file ticket:
Connector File Transfer Support:
Implement proper availability checking before initiating transfer. Don’t rely on events alone - verify the file state:
while (!isFileReady(dataset) && retries < maxRetries) {
Thread.sleep(30000);
retries++;
}
Storage Location Configuration:
Your error shows the source path is correct but verify the target configuration includes proper credentials. In your connector properties file, ensure you have:
The intermittent nature suggests a race condition between MCO release and file vault commit. Add transaction boundaries around your attachment handling to ensure atomicity. Also enable detailed logging in your connector to track the exact sequence: event trigger → dataset query → file resolution → transfer initiation. This will help identify where the breakdown occurs.
For production stability, implement a dead letter queue for failed transfers with automated retry logic. Configure your middleware to capture the full file metadata on first attempt, then retry with exponentially increasing intervals. This prevents data loss while handling timing issues gracefully.
This draft is based on general Teamcenter knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen this pattern before. The error suggests the connector is trying to access the physical file before Teamcenter has fully staged it. Check your connector timing - you might be initiating the transfer too quickly after the MCO creation event. Also verify that your service account has read permissions on the vault directory path shown in the error.
The attachment mapping configuration is critical here. In your connector properties, ensure you’re using the correct dataset reference method. We had a similar issue where we were trying to transfer files using the logical name instead of resolving the physical vault path first. The middleware needs to call the Teamcenter API to get the actual file location before attempting transfer. Also check if your storage location configuration includes the proper volume credentials.
Thanks for the suggestions. I checked the service account permissions and they look correct - full read access to the vault. The timing aspect is interesting though. Our connector triggers immediately on the MCO release event. Should we be adding a delay or checking file availability first?
Rather than adding arbitrary delays, implement a file availability check in your connector logic. Query the dataset to confirm the file is checked in and available before attempting transfer. We use a retry mechanism with exponential backoff - checks every 30 seconds up to 5 minutes. This handles cases where large files are still being committed to the vault when the release event fires.
I’d also verify your connector’s file transfer support configuration. Some connectors have separate settings for metadata vs attachment handling. Check if the FTP credentials are correctly configured and test the connection independently. We discovered our firewall was blocking the data channel for FTP passive mode, which caused similar intermittent failures. Switching to SFTP resolved it for us.