Status change events do not seem to fire when status is updated via PX
We are still currently on Agile 9.3.2.
I’ve written a Groovy script PX which runs multiple validations on a Change order. Once it determines that validations pass, it advances the CO to the next status. In that next status, there are multiple Java PXs that are configured to run on a “Change Status for Workflow” event. These events, handlers, and subscribers are all setup correctly and have never had an issue running when the user manually advances the workflow status. It is the fact that a PX is changing the status that seems to prevent the “Change Status for Workflow” from being triggered. Is there a way to “force” that event to be triggered from the Groovy PX? Is this a bug within Agile 9.3.2, or is this by design for some reason?
Thanks,
Steve
Steve,
Events are only triggered by users in the web or Java clients, unfortunately. PXs, WSXs, Import, etc., do not trigger events. In this case you might consider the Groovy script to be a pre event script upon changing the status, then prevent the change if there are issues.
Keith, Thanks for the prompt feedback. As it turns out, some of our developers have already encountered this issue. The workaround for us will more likely be to create a state-based triggered PX configuration.
Steve
Hi again Keith.
I’ve given your pre-event suggestion some thought and feel like this is worth looking into. It seems like one of our developers tried pre-events before but found some issue with using them. At this point, I can’t recall what that issue was, so I’d like to know more about it. I’m assuming that the event object must have a method to tell it there is an error and prevent it from going forward. Either that, or I’m guessing you must force a particular exception to occur. Do you know what syntax I might use to cause the pre-event to not trigger the event?
Many thanks,
Steve
When setting up the event subscriber, have the “Error Handling Rule” set to “Stop”. This means that the status change will not happen if an exception occurs during the pre-(Status Change)-event. Have your Groovy/validation code throw an exception to stop the workflow from advancing to the next status…Any exception should work and you can display the exception to the user using
“throw new AgileDSLException(“Validation failed…….“);“
Hi Steve,
In the script you just need to throw an exception and then configure the event subscriber to not continue upon error. That will prevent the workflow from continuing.
Thank you both Keith and “D”. I’ve tried your suggestions, but here’s what I’m running into if I use PRE… When going from a Pending state to either Submitted or Review, Agile’s default behavior is to pop-up the “Change Status” dialog box to request users to select approvers, etc. No PX will begin until the Finish button is clicked. During the time that the PX runs, the dialog remains open while things process. One of the critical functions of my PX is to populate both a page 3 attribute and the history with information. Once this happens, an “Object has been modified” error is shown within the dialog. I believe this happens whether the PX passes of fails. The question now is… is there any known workaround? Can the dialog be suppressed? I don’t think it can be done by the PX because, like I said, the dialog come up prior to the PX being triggered.
Thanks again,
Steve
D, I was so excited about the idea that I could simply add a refresh. Unfortunately, it does not seem to work for me 🙁
It doesn’t seem to matter where or in how many places I add it. My guess is that as long as the dialog has focus, the primary client screen cannot actually be refreshed. It is not until I close the dialog that I see the attributes get updated. It is possible that throwing the error itself may attempt to update the history, which is considered a modification of the object. If I attempt to place the change.refresh() within the Catch area, it acts as if the object is no longer defined. I get some sort of Groovy error about an invalid method. The objects are defined within the Try area. I suppose I could take a chance to define them prior to the Try to see if they remain defined.
Hello Steve,
I do not remember correctly, but it occurs to me that you have posted something similar a couple of days ago, may be am wrong.
Unfortunately I don’t quite get a clear picture of what you’re trying to achieve and what has been implemented in your system. And it seems to me you’ve used the words PX both for an Custom Action Process Extension as well as an Event, which is why it’s a little ambiguous to me.
Nevertheless, to answer your last question about getting Object Has Been Modified message when you click on Finish button of the Change Status pop up: you said you’ve configured a Pre Event for some validation on this change status event of the CO, right? In that case, it’s Agile’s default behavior that if you use Pre subscriber to check or validate something, you won’t be able to set any attribute’s value or perform any ‘write’ operation on any data object like changing status of an ECO, in the same thread. If you try to do, you’ll get the Object Has Been Modified error message.
Let me know if it helps and if you need any more suggestions.
Swagoto,
Thanks so much for your feedback. While I do not recall posting a similar question outside of this thread, I apologize if I’ve duplicated any info here. I do also apologize if I’ve misused or confused any of the terminology. Regardless, between the information that you and others have provided, you have confirmed that the way I wanted to achieved this special process is simply outside the scope of Agile’s standard functionality. My original questioned stemmed from wanting to run a PX in a Post-triggered event, but ALSO wanted to run OTHER PXs in the next status, which were also Post-triggered events in that next status. The problem was that I wanted to “auto-promote” to this next status via the PX running in the previous status. As it turns out, when a PX changes status, no event is triggered.
At that point, I followed Keith’s advice to try a Pre-triggered event, which raised a whole new set of issues. The Pre-event idea, had it worked, would have actually reduced the number of status values required to accomplish our goals. Since it did not work, I have resolved to do this a bit differently, and with just a little less automation for the end-user. In the end, we still believe that out Validation PX will deliver value to the business.
Thank you all for your valuable feedback. I am learning quite a bit from MyAgilePLM.
Kind regards,
Steve
Swagoto,
As I think I stated previously, we run numerous PXs on a Change Order, typically run on the Post event when the ECO goes to the Submit status. Some of these processes can take some time to run, but the ECO can actually appear to reach the Submitted status prior to completion. One such PX emails the user upon completion with either a success of fail message. If it fails, the user is to push the change back to pending, make corrections and try again. But you know how users are… they get impatient, ignore the rules, and release the ECO that may have error’d. That leads to a released ECO with issues… It can then clog up the PIP integration queue, the process that pushes data to Oracle.
What we are attempting to do is to create a Validation PX. Through some clever configuration, it is flexible enough to run the same PX multiple times on the same ECO, when it reaches different status values. One run of this PX is a pre-validation (running prior to all the other PXs). The idea in this case is to validate that all of the things that can cause the those other PXs to fail in the first place are set correctly. For example, we require that our revision values for affected items be numeric AND two digits (01, 02, etc. rather than 1, 2), so revisions get validated. Another common mistake a user makes is to redline a BOM by removing an item and then redline adding that same item back onto the BOM, possibly with a different find number. This can definitely error in the PIP process.
Once the pre-validation passes in the Submit status, the user will move the ECO to new status called PX Processing. Moving it to this status is something we wanted to automate, but due to issues that cause me to post my question to begin with, I think the user will be okay with doing it themselves. In this PX Processing status, our “standard PXs” will run. The very last one to run will be a post-validation PX. It’s purpose is to review the history entries on the ECO to see that all of the other PXs have passed. If not, the ECO is sent back to an Error status and the user is provided with enough information to direct them toward correcting the problems.
So, that’s it… in a rather large nut shell 🙂
Thanks again to all who have offered valuable insight.
Steve
PS: If I had to suggest a “feasible solution”, I would suggest creating a change.updateStatusWithEvent() method 🙂
What I do in these situations is to store data in the user map then add a post event to perform the updates.