Skip to main content
S
slapha15-Moonstone
15-Moonstone
November 28, 2016
Question

Preventing multiple promotion requests on the same objects

  • November 28, 2016
  • 3 replies
  • 7844 views

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?

    3 replies

    M
    22-Sapphire I
    MikeLockwood22-Sapphire I
    22-Sapphire I
    November 28, 2016

    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.

    S
    slapha15-MoonstoneAuthor
    15-Moonstone
    November 28, 2016

    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
    OliverDroop15-Moonstone
    15-Moonstone
    December 19, 2016

    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‌

    A
    amar_karthi13-Aquamarine
    13-Aquamarine
    May 8, 2019

    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

    M
    mchen-71-Visitor
    1-Visitor
    June 4, 2020

    @amar_karthi 

    Could share the same code for reference , thanks

    D
    18-Opal
    d_graham18-Opal
    18-Opal
    June 5, 2020

    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

     

     

      M
      mchen-71-Visitor
      1-Visitor
      June 8, 2020

      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
      18-Opal
      d_graham18-Opal
      18-Opal
      June 8, 2020

      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

      Terms & ConditionsCookie settingsAccessibility statement