cancel
Showing results for 
Search instead for 
Did you mean: 
Security Alert Log4j Security Vulnerability. Click here to know more.
cancel
Showing results for 
Search instead for 
Did you mean: 

Windchill Listener Events - Get Rename Values

TomU
23-Emerald II

Windchill Listener Events - Get Rename Values

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:

TomU_1-1636672142378.png

 

Event listener order depending on what is being changed:

TomU_0-1636672011173.png

 

5 REPLIES 5
STEVEG
20-Turquoise
(To:TomU)

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
17-Peridot
(To:TomU)

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
23-Emerald II
(To:avillanueva)


@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
23-Emerald II
(To:avillanueva)

@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?

 

TomU_0-1637081207481.png

 

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.

 

TomU_2-1637081422701.png

 

PRE_CHANGE_CAD_NAME

PRE_CHANGE_IDENTITY (1st loop)

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

TomU_3-1637081502231.png

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:

TomU_4-1637081680640.png

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
23-Emerald II
(To:TomU)

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

Announcements