Skip to main content
1-Visitor
March 17, 2021
Solved

Workflow set state

  • March 17, 2021
  • 6 replies
  • 11191 views

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

 

 

Best answer by RandyJones

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 ...

6 replies

16-Pearl
March 17, 2021

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

munruh1-VisitorAuthor
1-Visitor
March 17, 2021

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);
22-Sapphire I
March 17, 2021

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.

munruh1-VisitorAuthor
1-Visitor
March 17, 2021

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.

16-Pearl
March 17, 2021

Hi Matt,

 

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

 

Regards

Ajit

joe_morton
18-Opal
18-Opal
March 18, 2021

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.

munruh1-VisitorAuthor
1-Visitor
March 18, 2021

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.

16-Pearl
March 18, 2021

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!! 

22-Sapphire I
March 18, 2021

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.

1-Visitor
March 24, 2021

Is it possible that you're affected by this?

 

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

 

munruh1-VisitorAuthor
1-Visitor
March 24, 2021

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

1-Visitor
March 24, 2021

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.

18-Opal
April 16, 2021

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