On my test system, I am experimenting with Lifecycles, OIRs, ACLs, Roles, Types for WTDocuments and EPMDocuments. I evidently didn't do something right, and now when I try to run a Promotion Request Review to the Released State for an EPMDOC, the process doesn't complete and sometimes I get a “Error: Stalled (Failed queue entry)” error.
Any suggestions on what I should do to fix? I am afraid I made enough changes that I am having trouble narrowing it down.
Solved! Go to Solution.
To follow up, we got to the bottom of this issue. We had installed some third party utilities on the Test Server to perform some unrelated tasks. They weren't completely configured, and there was a missing queue that one of the utilities needed. That is what was causing the error.
We disabled the utility and the promotion request works.
If there's a failed queue entry, it is likely in the WfUserWorkQueue or WfPropagationQueue. If you go there, there should be a link to open up the workflow process for the Promotion Request that is in error. From there, you should be able to see a particular task with an error (background that is not green) or a task that has occurred but following tasks did not when it should have. If you click on the last run task or the errored task, you should be able to see an error stack for it.
You can also check methodserver logs if you can nail down the time that the queue entry was run.
Out of curiosity, can you go into a bit of detail on what you are attempting to implement in your modification to Promotion Request?
I am not changing the Promotion Request, at all. I am mainly trying to implement a new lifecycle for EPMDocs. To do so, I defined a CAD Author role, document type, some OIRs and ACLs in addition to the lifecycle.
When I had that all in place, I started testing and ran into this issue with the promo request.
Likely a dumb question, but have you set the "Promote" transitions in your life cycle template appropriately?
Regardless, can you still identify the bot/task that the failed queue entry corresponds to? It will help with troubleshooting.
A "Failed queue entry" error is always caused by a code error. You told the system to do something to an object that it is incapable of doing; the most common source of this error that I've found (i.e. me screwing something up and it blowing up in my face with that error ) is trying to use a state-setting command on an object that the object's Lifecycle Template doesn't have defined. This can happen in two different ways:
There may be other causes of a Failed Queue Entry error, but 100% of the instances I've been hit with it have been caused by one of the two situations above. So very carefully look at all of the parts of your workflows that can change the State of something and at the Lifecycle Templates of all of the objects they can affect, and make sure that everything has the required definitions for those signals to work.
Our story so far....
So I took Bob's advice and started looking at the logs more closely, and noticed this:
wt.pom.PersistenceException: A nested transaction cannot be started when a rollback in in progress.
I did some searching on the knowledge base, and found that this might because of a missing lock transition. (PTC TS article: CS1437) Which is along the lines of what Daryl was mentioning.
So hopefully making progress, but not out of the woods just yet.
A missing Lock transition? That's an interesting one; for our WTParts which are the only objects we use Promotions on we don't have any Lock transitions defined anywhere, but the promotions still work. Looking at the online help, the Lock transition "Works in conjunction with the Promote state transition when a different set of access policies are desired, when promotion requests are under review and seek approval. This transition is only valid for promotion requests and is only used as an interim state for the duration of the Promotion process".
Anyone happen to know what that actually means, since our Promotion Requests work just fine without any Lock transitions defined?
Yeah, I experimented with adding and removing lock transistions in the lifecycle and it didn't seem to make a difference in my case...
We do use WTParts, mainly to gather related documentation, whether it is CAD or WTDocs.
We use Promo Requests for moving CAD files from Released to Production Change when there is a non-FFF (Form, Fit, or Function) change that needs to be made. For example, when a layer needs to be turned on or off, or a datum added for placement in a new assembly.
We also use Promo Requests for other cases, and objects. We have used it with the approval option to set a WTDocument to Released, etc...
There might be better ways, but that is how we grew up using it...