We’re encountering a serious issue where generating CAD variants through the part management module creates duplicate part numbers in the system. Our process uses the Import API to create variant parts based on a master CAD assembly, but the uniqueness validation isn’t working as expected. We end up with multiple parts having the same number, which causes BOM errors downstream.
The variant creation code attempts to check for existing parts before creation:
IItem existingPart = session.getItem("P-12345");
if (existingPart == null) {
// Create new part
}
But we’re still getting duplicates, especially when multiple variant jobs run concurrently. Our part numbering scheme uses a prefix plus sequential number (P-12345), and we’ve configured Agile to use autonumbering, but it seems the Import API bypasses some of the standard validation. How do we enforce part number uniqueness rules properly when using the Import API for variant creation? We need reliable pre-import duplicate checks that work even under concurrent load.
I’ve seen this exact problem in multiple implementations. The issue is that the Import API doesn’t always respect the same uniqueness constraints as interactive part creation. You have two options: either switch to using autonumbering exclusively and let Agile generate the part numbers, or implement your own robust duplicate checking with proper transaction isolation. For the second option, you’ll need to query for existing parts within the same database transaction that creates the new part, and handle constraint violation exceptions gracefully.
The Import API has different validation behavior than the standard UI. You need to explicitly enable duplicate checking in your import configuration. There’s a validation flag that controls whether the import process checks for existing part numbers before creating new ones.
Consider using Agile’s built-in variant management capabilities instead of the Import API for this use case. The standard variant creation methods have proper uniqueness checking built in. If you must use the Import API, implement a centralized part number reservation system. Before creating a variant, your code should reserve the part number in a tracking table, create the part, then release the reservation. This prevents concurrent processes from trying to use the same number.
Also check your autonumbering configuration. If you have autonumbering enabled but your Import API code is explicitly setting part numbers, the autonumber service isn’t being used at all. You need to either let Agile generate the numbers automatically, or if you need specific numbering logic, disable autonumbering and implement comprehensive validation in your import code.
Your check for existing parts has a race condition. Between the time you check if a part exists and when you create it, another concurrent process could create the same part. You need to use a database-level unique constraint or implement a locking mechanism to prevent concurrent creation of parts with the same number. In Agile, the autonumbering service provides this locking, but if you’re specifying part numbers explicitly via the Import API, you’re bypassing that protection.