Auto associate doesn't apply WTPart subtype defaults

[Dobi]

Version: Windchill 13.0

Use Case: Autoassociate preference is turned on and a custom class that extends DefaultAutoAssociatePartFinderCreator implements AutoAssociatePartFinderCreator runs to select the correct subtype based on Product context. Autoassociate created WTParts don't have the particular subtype defaults.

Description:

I customized the AutoAssociatePartFinderCreator class to look at the product context a CAD document is being checked into and based on the context selects the appropriate subtype of WTPart to auto associate. 

This works as expected and the correct WTPart subtype is associated on check in based on context name. 

However, the subtype defaults and cascading attribution I set up for that particular subtype doesn't carry over. Instead, it looks as though the WTPart subtype is created based on the default parent WTPart. 

When I create a new part in the context, it follows the WTPart subtype attributes and defaults I set up. 

Is there a way to have the auto-associated part use the defaults for that WTPart subtype??

[Catalina]

Hi @Dobi 

Thank you for your question. 

Your post appears well documented but has not yet received any response. I am replying to raise awareness. Hopefully, another community member will be able to help.

Also, feel free to add any additional information you think might be relevant.

Best regards,

[MTH]

Hi Dobi,

There should be an issue with your custom code as the propagation of the com.ptc.windchill.uwgm.common.autoassociate.DefaultAutoAssociatePartFinderCreator#createNewWTPart is using com.ptc.windchill.uwgm.common.autoassociate.WTPartUtilities#createNewPart, which does the copy, is carrying the subtype attributes.

[Dobi]

@MTH I'm happy to admit that this is an issue with my code.

I followed this: CS135305.

I define some call outs for my particular subtypes as called out in Type and Attribute Management.

// WCTypeIdentifier defaultWCType = (WCTypeIdentifier) defaultType;
public static final String ONE_WTPART_TYPE = "com.something.www.oneWTPart";
public static final String TWO_WTPART_TYPE = "com.something.www.twoWTPart";

I then override the `createNewPart` bit:

// Set the appropriate part type based on product context
try {			
   if (containerName.contains("one")) {
      part.setTypeDefinitionReference(TypedUtilityServiceHelper.service.getTypeDefinitionReference(ONE_WTPART_TYPE));
			} else {
	part.setTypeDefinitionReference(TypedUtilityServiceHelper.service.getTypeDefinitionReference(TWO_WTPART_TYPE));
			}

Am I wrong in assuming that by specifying the subtype in this way would pull the parent WTPart template? 

[Dobi]

PTC tech support suggests this:

"Creating a WTPart using the API may not automatically apply the default attribute values defined in Type and Attribute Management. However, you can use the PersistableAdapter API to set these values manually, as described in CS135663".

I have a number of cascading attributes in this subtype and it seems kind of blah to have to redo all of that in the API... at the very least it renders the autoassociate customization moot because the end result is a different part type but all the same attribution as the part type I can create on autoassociate anyways without the customization. So I'm not convinced this is the way.

[Dobi]

I'm still discussing with PTC Tech support but what is turning out to be true is:

• Autoassociate (CS135305) DOESN'T FOLLOW DEFAULTS set in either Type and Attribute manager or OIRs (they suggested CS389217)
• Suggestion was to add a PersistableAdapter bit of code in the autoassociate class as specified here - CS135663. However, it appears as though the point in which this would get added doesn't YET have the WTPart created and associated to the CAD that is triggering the autoassociation. This results in a null pointer exception.

// create part with super class
WTPart part = super.createNewWTPart(partDescriptor);

// Set the appropriate part type based on product context
try {			
   if (containerName.contains("one")) {
   part.setTypeDefinitionReference(TypedUtilityServiceHelper.service.getTypeDefinitionReference(ONE_WTPART_TYPE));

Folder folder = WorkInProgressHelper.service.getCheckoutFolder();
System.out.println("Part is: " + part);
part = (WTPart) WorkInProgressHelper.service.checkout(part, folder, "").getWorkingCopy();
PersistableAdapter obj = new PersistableAdapter(part, null, Locale.US ,new UpdateOperationIdentifier());
				obj.load("myAttribute");
				obj.set("myAttribute", "value");
				part = (WTPart) obj.apply();
				part = (WTPart) PersistenceHelper.manager.modify(part);
				WorkInProgressHelper.service.checkin(part, "");
				

The point at which the PersistableAdapter is trying to edit the value, there's not yet a part:

Are there any other approaches?

[Dobi]

PTC tech support to the rescue (thank you Sandeep!)

For the persistableAdapter to work, the OperationIdentifier and OperationIdentifierConstants.<PROTOCOL> are needed for defaults to be set on autoassociate. 

// create part with super class
WTPart part = super.createNewWTPart(partDescriptor);
		
// Set the appropriate part type based on product context
try {			
    if (containerName.contains("one")) { part.setTypeDefinitionReference(TypedUtilityServiceHelper.service.getTypeDefinitionReference(ONE_WTPART_TYPE));
    OperationIdentifier oi = OperationIdentifier.newOperationIdentifier(OperationIdentifierConstants.CREATE_SKIP_OIRS);
     PersistableAdapter obj = new PersistableAdapter(part, null, Locale.US, oi);
     obj.load("myAtr1", "myAtr2");
     obj.set("myAtr1", "value1");
     obj.set("myAtr2","value2");
     obj.apply();
}