Workflow set state

[munruh]

I have a workflow that is used on almost all of our parts.  One of the functions of this workflow is to set the states of the promoted items.  It works correctly a majority of the time.  Sometimes though, it doesn't.  The windchill logs seem to tell me that the workflow is trying to set state on items in a user's workspace which of course it can't.  I don't know why it is even looking at workspaces.

We have tried multiple things to fix this. The following code is what we use to set state of the promoted items depending on document type (wtpart, epmdocument, wtdocument).  IMPLEMENTATION is a valid state for the promoted items.

wt.lifecycle.LifeCycleHelper.service.setLifeCycleState(theLatestPart, wt.lifecycle.State.toState("IMPLEMENTATION"),false); 
wt.lifecycle.LifeCycleHelper.service.setLifeCycleState(theLatestPart, wt.lifecycle.State.toState("IMPLEMENTATION"),false); 
wt.lifecycle.LifeCycleHelper.service.setLifeCycleState(theLatestDoc, wt.lifecycle.State.toState("IMPLEMENTATION"),false); 

We have also tried the following with the same results:

wt.lifecycle.LifeCycleServerHelper.service.setState(lifeCycleManaged, wt.lifecycle.State.toState("IMPLEMENTATION")); 

Below is an example of the error that shows up in the logs.

2020-08-17 10:20:06,064 INFO [WfPropagationQueue.PoolQueueThread-22603] wt.system.err Administrator - (wt.lifecycle.lifecycleResource/143) wt.lifecycle.LifeCycleException: An object stored in a personal cabinet can not have it's state changed. Move the object to a shared location before attempting the Set State.

 We do know that if we remove the item from all workspaces the workflow will set the state successfully.  If we revise the item in commonspace it works also because the newest revision doesn't exist in any workspace.

Does anybody have any ideas why this is happening?

Thanks,

Matt

[Ajit_Kulkarni]

Hello Matt,

Looks like this is unique problem you are facing right now. So the promotion request only tries to set the state on the version.iteration in the promotion. You may see the error/exception if the user do checkout/check-in after they raised a promotion request. 

For this matter , understanding your Windchill implementation is important. 

Regards

Ajit

[munruh]

Users have the opportunity to check out the promoted items at various points in the workflow.  Before we set state we look for the latest version.

Here is the complete code for wtparts:

thePart = (wt.part.WTPart)obj;
wt.part.WTPart theLatestPart = ext.Search.searchPartByNumber(thePart.getNumber());
System.out.println("Trying to get the latest revision of Part Name = " + theLatestPart.getName() + " With Version = " + theLatestPart.getIterationDisplayIdentifier());
wt.lifecycle.LifeCycleManaged lifeCycleManaged = (wt.lifecycle.LifeCycleManaged) theLatestPart;
System.out.println("Setting State");
wt.lifecycle.LifeCycleHelper.service.setLifeCycleState(theLatestPart, wt.lifecycle.State.toState("IMPLEMENTATION"),false); 

[MikeLockwood]

Yes, this seems very non-standard.

If you are in fact promoting, then the standard robot in the promotion request workflow changes the state of all the promotion targets near the end of the process (after checking valid states, iterations, approvals, etc.).

Without understanding more it seems like this may be redundant - and an opportunity to simplify.

Note: By definition, set set cannot be done to objects in a workspace; objects in a workspace may need Tools, Synchronize to display the current state after a change.

[munruh]

I don't want to set state on items in a workspace, but for some reason that is what it is trying to do.  I don't even want it to look at workspace items.  I should also note that we set state several times throughout the workflow to make it easier to control access.

[Ajit_Kulkarni]

Hi Matt,

Actually , your scenario needs detailed investigation as it is highly unlikely to happen. 

Regards

Ajit

[joe_morton]

Hi Matt,

Have you checked to see if the file is checked out when the set state is running? A checked out file could be seen as the latest version, and then the set state would fail because you can't set state a checked out object. 

For our workflows that use set state, we usually have a validation step immediately before to either force the check in, or send a task to the appropriate user to check in the file.

[munruh]

I have checked for checked out items in the past and that hasn't been the issue.  I have a task that is sent to the administrator group if the set state fails so we can fix it through a work around.  There hasn't been a time that I can recall where the item is checked out and that is the reason for failure.

I am starting to think that it might be the search method we are using.  

wt.part.WTPart theLatestPart = ext.Search.searchPartByNumber(thePart.getNumber());

I suspect it is also looking at workspace contents and not solely items that are checked into commonspace.

[Ajit_Kulkarni]

Glad that you mentioned!! Please include simple check in your search method to check for the working copy. That will save the day for you!! 

[munruh]

I understand what you are suggesting, but I am not sure how to implement it.  Could you provide a code snippet to send me in the right direction?

[Ajit_Kulkarni]

Use

boolean checkOutStatus = false;
checkOutStatus = WorkInProgressHelper.isCheckedOut(part);

Regards

Ajit

[munruh]

I was able to investigate what you sent and that doesn't help.  We very seldom have an issue with checked out parts.  Most of the time, the search code is returning items in a workspace instead of commonspace.  It passes the location to the set state code and then it can't set the state because it returned a location in a user's workspace.  I need the search to be able to return only commonspace results.

[MikeLockwood]

Lots of interest in this. Still seems very odd that you expect users to modify the data being promoted.

The rework loop for promotion requests is there OTB.  It doesn't fully handle things but easy to supplement.

Some use processes like this to route for various Roles to fill in info on various attributes, and you may be doing this. It requires check out / edit / check in, and so the iteration being promoted keeps moving up.  Tricky to keep all this working it would seem.

In general, if something is not ready to approve as is, some other process should likely be used to get input from all, then only promote when approval is very likely w/o further changes.

[zsternal-2]

Is it possible that you're affected by this?

https://www.ptc.com/en/support/article?n=CS164020

[munruh]

I don't think this is the issue.  I followed through the notes on this article.  The information for one of the WTParts that was affected shows that it is in one of our product folders.  I checked this for all of the documents in the promotion request and they are all showing in the correct location.  I browsed to our Site folders and there isn't anything there.  We are also on Windchill PDMLink 11.1 and it looks like this only affects 10.x

[zsternal-2]

Okay, sounds good. The reason I ask is because our organization runs Windchill 11.2.1 and we still experience this issue from time to time...so often that we have the "fix" process documented in our Confluence system so that it is quite easy to follow for our system admin team.

Can you tell us how you retrieve the "latestPart" item on which you are performing the set state action? Are you using a method from the WTPartService to retrieve this? There should be an API that gets just the items being promoted like this:

wt.fc.QueryResult qr = wt.maturity.MaturityHelper.service.getPromotionTargets((wt.maturity.PromotionNotice) primaryBusinessObject);

Hopefully that will return just the commonspace items.

[munruh]

We are using the search API to find the latest version of each promoted item.  Below is the whole code for our set state expression robot.

We have tried several solutions with no luck yet.  This code still has our last attempt.  We tried to remove the items from the workspaces, but that doesn't seem to fix it either.  I don't really like that solution because somebody might have a locally modified item they are working on.  If we can find a solution, that part will be removed.

wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice) primaryBusinessObject;

if(pn!=null){
System.out.println("Promotion Name = "+ pn.getName());
ext.excel.deletePromotionTargetsFromWorkspaces.processFromPromotion(pn);
} else {
System.out.println("Invalid Promotion. Check code");
}

wt.fc.QueryResult qr = wt.maturity.MaturityHelper.service.getPromotionTargets(pn);

try {
while (qr.hasMoreElements()) {
java.lang.Object obj = qr.nextElement();
wt.part.WTPart thePart;
wt.epm.EPMDocument theEPM;
wt.doc.WTDocument theDoc;
if(obj instanceof wt.part.WTPart){
thePart = (wt.part.WTPart)obj;
wt.part.WTPart theLatestPart = ext.Search.searchPartByNumber(thePart.getNumber());
System.out.println("Trying to get the latest revision of Part Name = " + theLatestPart.getName() + " With Version = " + theLatestPart.getIterationDisplayIdentifier());
wt.lifecycle.LifeCycleManaged lifeCycleManaged = (wt.lifecycle.LifeCycleManaged) theLatestPart;
System.out.println("Setting State");
wt.lifecycle.LifeCycleHelper.service.setLifeCycleState(theLatestPart, wt.lifecycle.State.toState("IMPLEMENTATION"),false); 
} else if (obj instanceof wt.epm.EPMDocument) {
theEPM = (wt.epm.EPMDocument)obj;
wt.epm.EPMDocument theLatestPart = ext.Search.searchCADDocByNumber(theEPM.getNumber());
System.out.println("Trying to get the latest revision of CAD Part Name = " + theLatestPart.getName() + " With Version = " + theLatestPart.getIterationDisplayIdentifier());
wt.lifecycle.LifeCycleManaged lifeCycleManaged = (wt.lifecycle.LifeCycleManaged) theLatestPart;
System.out.println("Setting State");
wt.lifecycle.LifeCycleHelper.service.setLifeCycleState(theLatestPart, wt.lifecycle.State.toState("IMPLEMENTATION"),false); 
} else if(obj instanceof wt.doc.WTDocument){
theDoc = (wt.doc.WTDocument)obj;
wt.doc.WTDocument theLatestDoc = ext.Search.searchDocByNumber(theDoc.getNumber());
System.out.println("Trying to get the latest revision of Document Name = " + theLatestDoc.getName() + " With Version = " + theLatestDoc.getIterationDisplayIdentifier());
wt.lifecycle.LifeCycleManaged lifeCycleManaged = (wt.lifecycle.LifeCycleManaged) theLatestDoc;
System.out.println("Setting State");
wt.lifecycle.LifeCycleHelper.service.setLifeCycleState(theLatestDoc, wt.lifecycle.State.toState("IMPLEMENTATION"),false); 
}
}
if (bFirstArticle) {
result = "First Article";
} else if (source.toUpperCase().contains("MAKE")) {
result = "Release Make";
} else {
result = "Release Buy";
}
}
catch(Exception wte) {
sFailedState = "Implementation";
System.out.println("Failed State: "+sFailedState);
wte.printStackTrace();
System.out.println("Failed Stack Trace: "+wte.toString());
result = "Rejected";
}

[RandyJones]

Matt: You are using a custom home grown "ext.Search.xxx" to search for the "latest" items in your posted code. So without posting your ext.Search class I can't help you much. 

However PTC already has a class that will refresh all the items in a Promotion Request to the latest:

com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.refresh(pn);

This is what we use here in our promotion requests to make sure the items have been updated.

If you take a look at an ootb Promotion Request workflow you will see this. I have screenshotted an ottb Promotion Request workflow and highlighted the conditional (there might actually be more than one...) this lives in:

[munruh]

Randy - I think you are right about it being a custom search.  I didn't realize that we were using a custom one.  I was under the impression that it was setup using OOTB API calls.  Below is the searchPartByNumber that we are using.

public static WTPart searchPartByNumber(String number) throws WTException{
WTPart thepart = null;
QuerySpec qs = new QuerySpec(WTPart.class);
qs.appendWhere(new SearchCondition(WTPart.class, WTPart.NUMBER, SearchCondition.EQUAL, number),new int[] { 0 });
QueryResult qr = PersistenceHelper.manager.find((StatementSpec)qs);
while(qr.hasMoreElements()){
thepart = (WTPart)qr.nextElement();
}
return thepart;

}

I will see if we can use the OOTB PR refresh. 

[RandyJones · Accepted solution]

Matt: Your existing query will definitely get objects that you probably didn't intend to.  Definitely would need to add some more qs.appendWhere()'s to filter on more items. eg Checked In, etc.

You could also possibly use  VersionControlHelper.service.getLatestIteration​(Iterated iteration, boolean, includeMarkedForDelete) to get the latest iteration of an object.

However it looks like what you are trying to do is what the OOTB PromotionNoticeWorkflowHelper.refresh() method will do. 

edit: Corrected VersionControlHelper.service.getLatestIteration​() to VersionControlHelper.getLatestIteration​()

edit 02: put .service back in VersionControlHelper ...

[munruh]

Thanks Randy!  That pointed us in the right direction.  We implemented this on April 8th and it seems to be working.  We haven't had an issue with items that were started after that date.  

[d_graham]

Matt,

Are you checking the “StateCheckoutInfo” of the Promotables prior to the set state?

This sounds like a case where the StateCheckoutInfo is “wrk-p” (Private Working Copy).

wrk-p is not formally “checked out” but is not checked in either and it is in a user’s private location (workspace).

If you have access to the dB look at the StateCheckoutInfo column for the promotables in question.

Assuming the promotable is an EPMDocument:

select ida2a2, StateCheckoutInfo from EPMDocument where StateCheckoutInfo = ‘wrk-p’;

If the state is wrk-p, I think you’ve found the problem.

David