Requirement linking fails with 'CAD object not found' when attaching to parts in Windchill

PLM Windchill
, , , , , , , ,
1

Our requirements management workflow is broken - we can’t link requirements to CAD objects. When users try to create requirement-to-CAD links through the Requirements Linking interface, they get ‘CAD object not found’ errors even though the parts clearly exist in Windchill.

The error appears consistently:


ERROR: Failed to create link - CAD object not found
Object ID: OR:wt.part.WTPart:12345678
at wt.requirement.RequirementLink.createLink()

We can see the parts in search results and open them directly, so they’re definitely in the system. The object reference validation seems to be failing during the linking process. This is blocking our design traceability workflows. The indexing might be out of sync, but I’m not sure how to verify. Anyone dealt with requirement-to-CAD linking issues?

system 2

You’re encountering a classic requirement-to-CAD linking issue that involves all three focus areas: linking mechanism, indexing, and object reference validation. Here’s the comprehensive solution:

Requirement-to-CAD Linking Configuration: The linking service uses a separate object registry that must be synchronized with your CAD objects. First, verify the linking registry is properly configured:

LinkRegistry registry = RequirementLinkHelper.getRegistry();
boolean isRegistered = registry.isRegistered("wt.part.WTPart");
// Should return true

If false, you need to register the WTPart type with the linking service.

Indexing Issues Resolution: The problem isn’t just the search index - it’s the linking service’s internal index. The requirement linking service maintains its own object cache that needs synchronization:


windchill ext.requirement.RequirementLinkService -reindex
windchill ext.requirement.RequirementLinkService -syncRegistry

Run both commands to rebuild the linking service’s object registry and synchronize it with the current CAD object database.

Object Reference Validation Fix: The critical issue is the object reference format mismatch. Your error shows ‘OR:’ format (Object Reference) but Windchill 11.2 M030 should use ‘VR:’ format (Versioned Reference) for parts. Update the linking service configuration:

// In RequirementLinkConfig.xml
<objectReferenceResolver class="wt.vc.VersionedReferenceResolver">
    <supportedTypes>
        <type>wt.part.WTPart</type>
    </supportedTypes>
</objectReferenceResolver>

The linking service was using the legacy ObjectReferenceResolver instead of VersionedReferenceResolver, causing it to generate incorrect object references that the validation step couldn’t resolve.

Complete Implementation:

  1. Stop the Windchill method server
  2. Update RequirementLinkConfig.xml to use VersionedReferenceResolver
  3. Register WTPart type with the linking service if not already registered
  4. Restart the method server
  5. Run the reindex and syncRegistry commands
  6. Clear the linking service cache: `windchill ext.requirement.RequirementLinkService -clearCache
  7. Test linking on a few parts to verify resolution

Verification Steps: After implementing the fix, verify each component:

  • Check that new links use VR: format in the database
  • Confirm the linking registry shows WTPart as registered
  • Verify the object reference resolver is using the versioned resolver
  • Test linking with both newly created and existing CAD objects

The root cause is that the requirement linking service wasn’t updated to use the correct object reference format for your Windchill version. Once you switch to the VersionedReferenceResolver and synchronize the linking registry, your requirement-to-CAD traceability should work correctly.

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

The ‘CAD object not found’ error usually indicates an indexing problem. Your search results are coming from the search index, but the requirement linking uses direct object references from the database. Try reindexing your CAD objects - go to Site > Utilities > Index Management and run a full reindex on WTPart objects.

4

I’ve seen this when there’s a version mismatch between the requirement management module and the CAD data management module. Check your Windchill 11.2 M030 installation to ensure both modules are at the same patch level. Also verify that the requirement linking service has proper access permissions to the CAD object database tables.

7

We ran a reindex on WTPart objects but still getting the same error. Both modules show the same version in the system info page. The permissions look correct - the requirement service account has read access to all part tables. Could this be related to how the object references are being resolved?

8

Check if your CAD objects have proper OIDs (Object Identifiers) registered in the requirement linking registry. The linking service maintains a separate registry of linkable objects. If CAD objects weren’t properly registered when they were created or imported, the linking service won’t find them even though they exist in the main database. You might need to run a registration script to populate the linking registry with existing CAD objects.

9

The object reference format in your error message looks suspicious. The ‘OR:wt.part.WTPart:12345678’ format suggests the linking service is trying to use a legacy object reference format. Windchill 11.2 should be using the newer VR format for versioned objects. This could explain why the validation fails - it’s looking for objects using the wrong reference scheme.

10

We had this exact problem after upgrading from 11.1 to 11.2. The issue was that the requirement linking configuration still had the old object reference resolver configured. You need to update the linking service configuration to use the current object reference format for your version.