Re: Windchill Listener Events - Get Rename Values

TomU · ‎Nov 11, 2021

Does anyone know of a way to retrieve the target values a user enters into the rename GUI before any of the rename events finish? We're running into a problem where we can't see what the new filename is until after the number change is already complete. We need to know if the filename is going to be changing, and if so what its new value will be, before we decide whether or not to let the number change proceed. Since separate events are being fired for name, number, and filename, it seems like it's impossible (from just these events) to tell in advace what is going to be changing. Instead of just looking at the object passed by these listeners (EPMDocument, etc.) is there some way to get all the data that was actually submitted by the user on the rename form, before any of the rename events actually finish?

Rename dialog:

Event listener order depending on what is being changed:

STEVEG · ‎Nov 15, 2021

I would think getting what someone types in a field and not completing the task by not selecting the OK button is not possible.

I have created a report that shows a past name of a file. Not sure if that would help though.

avillanueva · ‎Nov 15, 2021

I have a rename listener and am using a PRE_CHANGE_IDENTITY. Presumably, the target has already been changing but not stored yet. Why else would it be a pre-change event? I get an IdentityServiceEvent returned. I did not see any "pre" identity objects in the event so agree that they are not exposing that. What if you tried this? Using the internal ID of the object, look it up via a query and get the current identity. In this way, you have the modified object passed from the event and a separate database query of that same item to compare against.

IdentityServiceEvent idEvent=(IdentityServiceEvent)event;

Object target=idEvent.getEventTarget();
logger.debug("Listen hears PRE_CHANGE_IDENTITY: ");
logger.debug(" target:"+target.toString());
if(target instanceof EPMDocumentMaster)
{
EPMDocumentMaster master = (EPMDocumentMaster)target;
EPMDocumentMasterIdentity cadDocID=(EPMDocumentMasterIdentity)idEvent.getIdentity();
logger.debug("New name:"+cadDocID.getName()+":"+cadDocID.getName().length());
String newName=cadDocID.getName();

TomU · ‎Nov 15, 2021

@avillanueva wrote:

I have a rename listener and am using a PRE_CHANGE_IDENTITY. Presumably, the target has already been changing but not stored yet.

From the debugging I've done, that second statement is not accurate. Here's what I'm seeing:

PRE_CHANGE_IDENTITY is called before the change takes places and does not tell you what you what the new value will be.
POST_CHANGE_IDENTITY is called after the change has taken place and does not tell you what the old value previously was.

Either listener can stop the change, and in the case of a POST event, roll the change back, but neither one provides both the old value and the new value together. From what I can tell, there is no way (just using these listeners) to intelligently compare both the old and new values before letting the change proceed.

I turned on a bunch of other logging, and Windchill clearly know both of these values way before the listeners are fired, but from what I can tell these are not exposed to the listeners.

2021-11-12 16:30:17,062 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.cadx.request.AbstractUwgmRequestAdapter administrator - AbstractUwgmRequestAdapter.debugKeyValuePair :: Key: MULTIRENAMETABLE_NEWFILENAME_JSID  Value: FN02090002_50.prt
2021-11-12 16:30:17,062 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.cadx.request.AbstractUwgmRequestAdapter administrator - AbstractUwgmRequestAdapter.debugKeyValuePair :: Key: MULTIRENAMETABLE_NEWNAME_JSID  Value: null
2021-11-12 16:30:17,062 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.cadx.request.AbstractUwgmRequestAdapter administrator - AbstractUwgmRequestAdapter.debugKeyValuePair :: Key: MULTIRENAMETABLE_NEWNUMBER_JSID  Value: NUM02090002_50.PRT


2021-11-12 16:30:17,155 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.cadx.multirename.RenameL01RequestAdapter administrator - RenameL01RequestAdapter.createEpmRenameInstruction :: EPM Rename Instruction: EPMDocID: OR:wt.epm.EPMDocument:532031880 New Name: null New CadName: FN02090002_50.prt New Number: NUM02090002_50.PRT New Organization:  Autonumbered: false DerivedFromNumber: false Name Same As Number: false Same Base Number As:  Same Base Number As Related: false


2021-11-12 16:30:17,249 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.proesrv.cache.EpmIdentityInstructionCacheAdapter administrator - EpmIdentityInstructionCacheAdapter.validateEpmIdentityInstructions :: Created EpmIdentityInfo for document: h02090002_50.prt[wt.epm.EPMDocument:532031880](-.0) EpmIdentityInfo: number = NUM02090002_50.PRT name = null autoNumbered = false container = wt.pdmlink.PDMLinkProduct:423216551 organization = null source = null soft type = null IBAs = null MIBAs = null isNameSameAsNumber = null baseNumberObject = null newBaseNumber = null errorCause = null sameBaseNumberAsRelated = null cadName = FN02090002_50.prt deriveCadName = false usePreferences = false
2021-11-12 16:30:17,249 DEBUG [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.proesrv.cache.EpmIdentityInstructionCacheAdapter administrator - EpmIdentityInstructionCacheAdapter.validateEpmIdentityInstructions :: Created 1 IdentityInfos
2021-11-12 16:30:17,249 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.proesrv.cache.EpmRenameInstructionL01CacheAdapter administrator - EpmRenameInstructionL01CacheAdapter.validateInstructions :: Created 1 EpmIdentityInfos
2021-11-12 16:30:17,249 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.proesrv.cache.EpmRenameInstructionL01CacheAdapter administrator - EpmRenameInstructionL01CacheAdapter.validateInstructions :: Created EpmIdentityInfo for document from input as received from UI: h02090002_50.prt[wt.epm.EPMDocument:532031880](-.0)
IdentityInfo = EpmIdentityInfo: number = NUM02090002_50.PRT name = null autoNumbered = false container = wt.pdmlink.PDMLinkProduct:423216551 organization = null source = null soft type = null IBAs = null MIBAs = null isNameSameAsNumber = null baseNumberObject = null newBaseNumber = null errorCause = null sameBaseNumberAsRelated = null cadName = FN02090002_50.prt deriveCadName = false usePreferences = false

2021-11-12 16:30:17,655 DEBUG [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.common.identity.DefaultCADNameValidator administrator - DefaultCADNameValidator.validateCADName :: Authoring application-specific checks successful for CAD name fn02090002_50.prt
2021-11-12 16:30:17,655 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.common.identity.DefaultCADNameValidator administrator - DefaultCADNameValidator.validateCADName :: Validated new CAD name fn02090002_50.prt for master: h02090002_50.prt[wt.epm.EPMDocumentMaster:532031858]
2021-11-12 16:30:17,655 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.common.delegate.DefaultEPMOperationDelegate administrator - DefaultEPMOperationDelegate.validateCADName :: No validation error for master: h02090002_50.prt[wt.epm.EPMDocumentMaster:532031858] New CAD Name: fn02090002_50.prt AuthApp: PROE

Both the old and the new values are listed above, before the listeners are ever fired off. Sure seems like we should be able to hook into *something* here…

TomU · ‎Nov 16, 2021

@avillanueva,

You were right and I was wrong. The EPMDocumentMasterIdentity class was the difference. I was using EPMDocumentMaster and that only returns existing values but EPMDocumentMasterIdentity does return the new target value prior to the change taking place. Thank you for that.

The problem I'm still having is that EPMDocumentMasterIdentity only returns some of the new values for each listener call. When changing both number and cad name, two separate loops are executed, and as far as I can tell there is no way in the first loop to tell what (if anything) will be changing in the second loop (or if there even will be a second loop).

If a user is attempting to change more than one thing, how do I validate all of the new values that were entered before any of them are changed?

Turning on trace logging for com.ptc.windchill.uwgm.cadx.request.AbstractUwgmRequestAdapter I can see all of the new values. I'd like to have some way to retrieve this information from a supported class when the listener(s) fire off.

PRE_CHANGE_CAD_NAME

PRE_CHANGE_IDENTITY (1st loop)

- only the cad name change is visible in this first 'loop':

POST_CHANGE_IDENTITY

POST_CHANGE_CAD_NAME

PRE_CHANGE_IDENTITY (2nd loop)

- the remaining changes for name and number are shown in the second loop:

POST_CHANGE_IDENTITY

From the log information shown above, I can see no way to tell during a cad name change if number is going to also going to be changing. Any ideas?

TomU · ‎Nov 16, 2021

After scouring the PTC knowledge base, it seems the only supported method for keeping these synchronized is to use a TransactionCommitListener.

https://www.ptc.com/en/support/article/CS45397