Matching generated Number on Save As
Version: Windchill 12.1
Use Case: Matching WTPart and EPMDocument numbers when using Save As
Description:
Hi all,
We currently have WTPart and EPMDocument subtypes which receive auto generated numbers, snips of the OIRs below...
WTPart:
<!-- Set the number to M01234567 format -->
<AttrValue id="number" algorithm="com.ptc.windchill.enterprise.revisionControlled.server.impl.NumberGenerator">
<Arg>M</Arg>
<Arg>{GEN:wt.enterprise.SequenceGenerator:BOM_GROUP_seq:7:0}</Arg>
</AttrValue>
<AttrConstraint id="number" algorithm="com.ptc.core.rule.server.impl.GatherAttributeConstraints">
<Value algorithm="com.ptc.core.rule.server.impl.GetServerAssignedConstraint"/> <!-- Get the server to generate a number -->
<Value algorithm="com.ptc.core.rule.server.impl.GetHiddenConstraint"/> <!-- Hide from the user (have to leave it modifiable so that auto associate works correctly) -->
</AttrConstraint>
EPMDocument:
<!-- Set the number to M01234567 format -->
<AttrValue id="number" algorithm="com.ptc.windchill.enterprise.revisionControlled.server.impl.NumberGenerator">
<Arg>M</Arg>
<Arg>{GEN:wt.enterprise.SequenceGenerator:BOM_GROUP_seq:7:0}</Arg>
</AttrValue>
<AttrConstraint id="number" algorithm="com.ptc.core.rule.server.impl.GatherAttributeConstraints">
<Value algorithm="com.ptc.core.rule.server.impl.GetServerAssignedConstraint"/>
<Value algorithm="com.ptc.core.rule.server.impl.GetImmutableConstraint"/>
</AttrConstraint>
The intention with these is that the WTPart and EPMDocument have the same number, usually a user will achieve this by either:
- Creating a WTPart of the above subtype, ticking 'Create CAD Document' to create an EPM Document at the same time, which will inherit the auto generated number from the WTPart
- Creating a EPMDocument, which will auto generate a number, and then use Auto Associate which creates a WTPart with the same number
This breaks however when a user tries to duplicate an existing WTPart and associated EPMDocument through Save As, as they each get a unique number (e.g. M0001001 & M0001002), requiring some tedious manual renumbering of objects, and we just have to accept that every alternate number won't be used.
It makes sense why OIR gives them different numbers, as it's considering each new object in isolation, and doesn't know there's another object being duplicated at the same time. I've had a look at writing a new RuleAlgorithm to try and capture this, but it seems the only arguments it receives is those that are provided through the OIR XML, and the container, no reference to the other objects that are part of the Save As collection.
A few possible options:
- Just duplicate the EPMDocuments, then use Auto Associate - this loses WTPart based information like expressions and usage attributes, requiring manual re-entry
- Just duplicate the WTParts, then manually create and associate EPMDocuments - more work than just renumbering
- Use an event listener to catch creation events and adjust the numbers - this would work, but we're trying to avoid using event listeners unless absolutely necessary for performance reasons
Any other ideas?
Thanks in advance.

