cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

Preventing multiple promotion requests on the same objects

slapha
15-Moonstone

Preventing multiple promotion requests on the same objects

We implemented the Rework option in our promotion requests similar to the out of the box template in 10.2.

The rework options works great, as long as they don't need to change the collection.

A secondary problem we've found is that often the promoter will forget they have a promotion in rework, and will create a new promotion request.

So we end up with a brand new promotion and one that has rework data recorded.

This leads to queue failures when it's trying to lock an object that's already locked in Under Review.

My first instinct is to check for the objects being in Under Review. Though when the second promotion is started it's at an In Work state. You could only catch the failure on the original promotion with all the data.

We perform a check of objects checked out already. We also have a terminate path as part of the Rework task if they find a duplicate promotion or need to change the collection and just can't move forward with it. Though, right now I have to play watchdog over the WfPropagationQueue watching for any failures until I implement some sort of fix/prevention because the promoter gets no notification of a failure, and even if they did they might not know what the failure message means or what they need to do about it.

A second idea might be to look for any open Promotions against a Revision. Though that would require a bit more processing.

Ideally we would want to eliminate the duplicate promotion before it even gets started, terminate it after creation, or trigger some sort of flag to the promoter that there is an open promotion.

Do these make sense, anyone have any other ideas I'm missing?

12 REPLIES 12
MikeLockwood
22-Sapphire I
(To:slapha)

The New Prom Req wizard will not let users past the object collection screen if any object on it does not have a promotion transition from the current state in it's  current cycle template.

Maybe check the lifecycle and see if there are unwanted Promote transitions.  If you use the optional (but very helpful and highly recommended) "lock" transition to a temporary state at which there is no Promote transition, this seems like it would prevent the situation described.

Note: It's unbelievable, but the new Lifecycle UI add the Promote checkmark from every state to every other state on the first save (there is some algorithm in there created 15+ years ago and no one at PTC ever went back and removed it).  There are literally thousands of Windchill systems around the world that have lifecycle templates littered with extra Promotion transitions.  Also, if you do change the lifecycle template, you have to take relatively extreme measures to apply the latest iteration of the lifecycle template to all objects that use it.

slapha
15-Moonstone
(To:MikeLockwood)

The problem is while the Promotion is in Rework, the objects go back to In Work, which is the original promotable state and unlocked. They are set that way so they can be fixed and the promotion can be re-triggered from Rework back to Under Review and the objects are set back to Under Review awaiting approvals.

A Rework state on the objects might prevent this issue, but that would mean adding the lifecycle state to all objects. I think we considered this in the past for validating when objects were truly being reworked during promotion or change process. We try to limit lifecycle states on docs/parts/models for ease of understanding, also updating lifecycles on all the objects may be a bit more than we want to undertake at the moment.

OliverDroop
12-Amethyst
(To:slapha)

I fully agree that it should be prevented to add the same object revision as resulting to multiple Change or Promotion Notices.

It will just cause issues and from the business point of view it does not make sense.

Each object revision should be reviewed, approved and released by a dedicated task and published to downstream systems by the notice.

You could use an pre-store event listener to prevent this as long this is not available OOTB and controlled by a preference.

Jeffrey Zemsky

Oliver Droop its not that straight forward.

Promotion Request is not a revision level tool - it is made for State management at the iteration level and supports the ability to set states back and forth.  Preventing it at the Revision level would prevent use cases such as Promote from Prototype in Work to Prototype Completed and the for the same revision promote from WIP to Review.  or Promote (demote) back from Prototype Complete to Prototype in Work.

For Change there are again two use cases that are supported for using the same revision on a Change Notice in Resulting objects.  The first is updating or adding Effectivity to a revision - eg additional Effectivity statements in multiple contexts (CN1 Effective in Assembly 1 on January 1, 2017-, CN2 adds Effectivity for Assembly 2 on January 17, 2017 - February 11, 2017).  The second use case is that CN3 is used to Obsolete the part, whereas CN1 was used to release it.

I could see two things in the future - a) a preference for sites that do not have these use cases or b) a business rule that checks if its on another Promotion Request or Change Notice and gives you feedback such that one could use it to  either block or optionally allow

l4urence
4-Participant
(To:JeffZemsky)

@JeffZemsky , apologies for posting on an old topic, but I wonder whether there's been anything recent in PDMLink in the way of a business rule or preference to prevent raising a promotion request on object currently in the rework loop (and therefore in the WIP or DRAFT state)?. We are facing the same issue and I'm reluctant to going down a customisation route.

@l4urence  There is nothing that would prevent it today.  However best practice would be for the rework loop to be something different than the normal WIP state -eg .REWORK.  In this case it becomes clearer that the object is part of a Promotion.

 

Additionally it would be pretty easy to add a workflow check to see if the object is on another promotion and route the Promotion back to the user to edit before proceeding.

l4urence
4-Participant
(To:JeffZemsky)

Thanks Jeff - that's pretty much what I've done but the users are effectively reworking the document at draft and then setting up a new promotion request rather than use the existing one. I think I need to review using draft for the change but use rework instead.

amar_karthi
12-Amethyst
(To:slapha)

I had been into the same situation where users keep creating Promotion request on objects that are actually made available for Re-Work and is in "In Work" state.

 

And we actually solved it by writing a customized validator class which was hooked to our promotion request workflow which would check if the object has an existing promotion request and thereby blocks the action for a new Promotion request.

 

Amar Karthi ARASAN

mchen-7
4-Participant
(To:amar_karthi)

@amar_karthi 

Could share the same code for reference , thanks

d_graham
17-Peridot
(To:slapha)

To prevent multiple promotion requests with the same promotable objects I always include an expression robot in the workflow (after the Start robot) that gets the objects on the promotion request and looks to see if an open (Not Approved or Rejected for example) request already exists. If a promotion request already exists do (whatever the require is). Maybe send email stating the situation, delete the new request and terminate the process, or send a Task to the creator explaining the situation. Really, whatever you want.

 

Another, and I think better, solution is to create a listener that listens for the addition of an object to a promotion request. The advantage of using a listener is you stop the action in its tracks and the user gets instantaneous feedback.

When the listener runs it checks if the object is already on an open request. If it is, throw an exception which opens a window to the user explaining the situation. Something like: “EPMDocument <number rev.iteration> is already on open Promotion Request <number name> and cannot be added to your Promotion Request.

 

The event I listen for is the PersistenceManagerEvent.POST_STORE of the "link" that links the object to the Promotion Request, not the Promotion Request itself. The advantage of using the post store event is that the object is in the dB but it has not yet been "committed" to the dB. Therefore, if something wrong, like the object is already on an open Promotion Request and an exception is thrown the commit to dB never happens

 

Here's a screenshot of the listener in action.

It prevents a user from creating a Promotion Request with an object that is already on an open Promotion Request. And it prevents a user from adding an object to an existing Promotion Request if the object is already on an open Promotion Request. The listener is really the way to go.

It provides instantaneous feedback to the user.

Works when creating a new Promotion Request

Works when adding to existing Promotion Request

It's bombproof!

 

d_graham_0-1591381675600.png

 

 

mchen-7
4-Participant
(To:d_graham)

listen PersistenceManagerEvent.POST_STORE of the "link" .

Does it mean that only one drawing error can be thrown at a time? Not all drawings errors at a time ,right?

d_graham
17-Peridot
(To:mchen-7)

Correct. One link at a time.

The reason I did it this way rather than keying off the Promotion Request is because if I key off the link my code works under all circumstances (making a new Promotion Request or adding to an existing Promotion Request).

 

It might be possible to key off the Promotion Request but I think you'd need to use a different event. Maybe the PersistenceManagerEvent.UPDATE event.

 

In the example I showed a drawing that was already on 5 Promotion Requests. I put the drawing an several Promotion Requests for testing purposes.

 

Listeners are great for checking stuff before it's committed to the dB.  I actually wrote a script that lists all of the Windchill PDMLink listeners.  As of 11.2 there are 458 events listened for.  This is up quite a bit from four years ago.

 

One example of how I've used them in the past is to force the user to enter a valid attribute value.  For example, you have two attributes that are related.  Attribute A has a value constraint of 1,2,3,4 or 5 attribute B has a value constraint of X, Y or Z. However, if A is 1 or 2, B must be X or Y only.

With a listener I can check the values and make sure they are compatible before they are committed to the dB.

If they are not  compatible an exception is thrown telling the user if A=1 or 2 then B must = X or Y only.

 

Doing stuff like this helps to automatically educate the users, ensures that data complies with standards and takes some load off the administrators.  Seems to work out well for all concerned.

 

And thanks for the kudo!

 

David

Top Tags