Promotion Request Review Process hangs...

[mdebower]

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.

-marc

[bsindelar]

Marc,

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?

[mdebower]

Hey Bob,

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.

-marc

[bsindelar]

Understood.

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.

[doehr]

Hi there,

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:

1. You used a Set State robot/code script in a Workflow to try and set an object like a part to a State that its Lifecycle Template doesn't have, for example, if your Promotion Request Lifecycle Template has only the states New, In Work, Released and you tried to use a Set State robot to move it to Obsolete.
2. You tried to use one of the state Transition signals (Change, Lock, Obsolescence, Production Released, Promote, Refine, Review, Revise or Set State) on an object likely within a workflow, and that transition has not been defined for the State that the object was in when it saw the signal. For example, the Change transition is the one found at the end of the OOTB Change Notice workflow and is supposed to release all Resulting Objects in the change tasks to their released state. If you have a Resulting Object at the In Work state, such as an EPMDoc, it receives that Change signal but you have not defined any Change transition (checkmark) in the In Work state of the EPMDoc's Lifecycle Template, it won't know where to go when it gets that transition signal.

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.

Daryl

[doehr]

Actually going to expand on my previous post. It turns out there's another key source of "Failed queue entry": a hidden syntax failure on any transition within a task. I literally got hit by one of these 10 minutes ago. From what I can tell, on every user task the system does a quick syntax check on EVERY Transition code segment, even ones that you don't have defined to fire. If there's a problem with any of them, bam. Done. It freezes and you get Failed Queue Entry. For my particular very recent example there was some random old variable I never defined in the ass-end of nowhere on a Transition we never use which had no initial setup declaration, likely from a very old previous iteration on the code on a rarely-used process routing.

So Marc, if you haven't found the source of those Failed Queue Entry problems, take one of the Promotion Requests that did hang with Failed Queue Entry and look for the user task that was supposed to start but didn't (whatever task is immediately after the last Executed step, if the last executed step goes to multiple simultaneous tasks check ALL of them), go into the workflow and Syntax Check every single Transition (or code script for a non-user task that was supposed to start).

[mdebower]

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.

[doehr]

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?

[mdebower]

Yeah,  I experimented with adding and removing lock transistions in the lifecycle and it didn't seem to make a difference in my case...  

[doehr]

I do need to ask, why are you using Promotion Requests on CAD files? Do you not use the WTParts (gear icon)?

[mdebower]

Daryl,

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

[doehr]

I see...that is very, very different from our own setup. For Parts we treat the WTPart as the central "bucket" to hold all of the relevant data, including the CAD files/drawings, and they are the only things that need a "design stability" that gets moved along with Promotion Requests. All of the lower level files like CAD documents are designed to unlock to an In Work state from the Revise function and re-lock with the Change transition found at the end of a Change Notice, and therefore never need a Promotion Request. As for WTDocuments we defined a custom document release workflow on the document object lifecycle template itself that has all of the relevant state-changing functions on it via the Revise function or Set State robots.

So it sounds like you're using Promotion Requests significantly more (i.e. by at least a factor of 100) than we are...am I correct in saying that you use Promotion Requests to move any object of any type to any state?

[mdebower]

We have used promo requests for changing the states of WTParts, CAD Documents, and WTDocuments.  We don't have any custom workflows to speak of, and so have made more extensive use of the OOTB Promotion Request.

We are starting to look at some light customization with lifecycles, types, roles, OIRs, and ACLs; which got me into this mess in the first place!   Thank goodness, we have a test server for me to **** up.

-marc

[bsindelar]

Marc,

I've personally done a lot of different things and have come up with some pretty unique solutions, a lot of which needing minimal or NO custom code to solve.  If you'd like, I'd be more than happy to discuss your goals for what you are looking to do.  While this forum is a great way to reach out, feel free to send me a direct e-mail at robert.sindelar@eccellent.com, and I'd be happy to set up a call just to chat and really dive deeper into your needs, provide a few tips, etc.

[doehr]

PDM is so adaptable that honestly before you consider any customization you should go to the fundamental root of the issue. Does your company have a policy on how they want engineering changes and promotions to work? How do you want to get a part to move from the initial bare-bones prototype phase to full out production on a line? Our company is automotive and we based our policies (and therefore PDM processes) off of ISO TS16949 and the APQP PPAP policies and Stage-Gate product development, with a couple of custom additions. Having a baseline policy like that really, really helps, trust me, and pretty much no matter what you put on the policy you can customize the tool around it.

[mdebower]

We are really in the configuration / adapting stage.   I have heard other people refer to it as light customization, but it really is just configuration.

We deal with APQP and ISO as well, but we are non-automotive vehicles.  (Trucks, Utility Vehicles, Construction Equipment, Ag, Special Vehicles.)  We are in the process  of updating and revamping our internal policies to follow ISO and APQP more closely.  I will have to read the policies we have again to make sure Windchill supports them.

Our existing policies do have stage gates (we call them Phase Gates) and some other direction to follow.   How closely does your Windchill lifecycle follow your stage gates?

How do you store all the PPAP paperwork?  In Windchill?   If so, what document types do you associate with the WTPart?

[doehr]

For our custom parts they very, very closely follow the stage-gate process. We centralized all of our part definition on the WTPart, including the design stability (stage) of its development, and everything else directly linked to it such as the CAD file and drawing gets basic lifecycles like New, In Work, Under Review, Released, etc...there's no need to repeat the stage stabilities on everything when they're always linked to one central collection object that already has that stability.

I'm changing the specific state names here for proprietary sake, but effectively all new parts first start with the WTPart which starts at a Prototype In Work phase and is also the source of the part number. When it gets released via a Change Notice (linked to a Change Task) its Change transition sends it to a Prototype Released state. If a new Revision is started on the part (with the Revise transition in the Lifecycle Template) it goes back to the Prototype In Work state, and again when that new revision gets released via a CN it goes back to Prototype Released.

So at that prototype phase is when the design engineers can revise it six ways to Sunday, getting low volumes of parts, building them, testing them, revising again, etc...our Operations group is heavily trained not to do any large volume ordering on Prototype parts so we keep the inventory levels, and therefore costs, low for the changes. Only once Design has finished their fiddling and they present proper evidence that the design is ready do we use a Promotion Request to upgrade it to the next main Stability (i.e. stage), which is Design Stable; all of that relevant work, which includes PPAP documents like DFMEAs etc, get stored in Windchill and a lot of it goes through a lighter custom-made Documentation workflow set directly onto the Document object type. From that point on it's the main job of our Operations group to develop or source the production line/supplier for the parts, which could include a lower number of further design revisions if the suppliers or in-house production line are having real trouble physically building something because something wasn't well designed for manufacturability. We also hold the part at the same stability in the end through the changes, so we do have a Design Stable In Work phase which the part switches to during a change and it gets released back into the Design Stable released state afterwards. Again, all PPAP documentation (Process Flow Chart, PFMEA, Control Plan, Work Instructions etc) are stored in Windchill under the Documentation workflows; they can go through a faster review and don't need the slower CR/CN/CT process to be released. When Operations has all their evidence ready as well as evidence of a successful full-rate trial production run and validated product made from it, they use another Promotion Request to upgrade the part(s) to Limited Production Stable.

At this point it's mainly final signoff from the customer and large-scale orders, since we have a validated design produced at the desired rate from a validated production line, Once all the final T's are crossed and I's are dotted, a final Promotion Request puts it to Production, which, in other words, means "Crank them out in the thousands if you can get the orders". Like the first two main stages, we do have In Work variants of Limited Production and Production to again hold the part at the same stability through a change. We also have Obsolete and Non-Product states which Promotion Requests can get the part to when appropriate.

For the document types associated with the WTPart, the main Described By document is the final PDF drawing, stamped and signed at the end of the CN that releases it, that would get sent to a supplier to build it. Reference Documents can be any number of things; one in particular for custom purchased Parts is what we call a Compatibility Sheet that is the core design verification for the part to move from the Prototype to Design Stable states, so it gets linked as a Reference Document to the WT part. And of course there's the CAD files.

For the promotion evidence on the Promotion Requests those files don't necessarily need to be directly linked to the relevant parts since the WTPart has history links to every Promotion Request that has ever affected any of its revisions, so you can link the evidence to the Promotion Request itself and just keep the main files in one of the data folders of the host Context of the part itself.

[mdebower]

Thanks for the great info.   Some things you said are similar to what we are trying to do, and others are good food for thought.

[mdebower · Accepted 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.