Community Tip - Learn all about the Community Ranking System, a fun gamification element of the PTC Community. X
I have just discovered the "Release Changeables" activity, in the Change Notice workflow, will terminate any existing running workflow on any of its Resulting Objects. These are workflows in which its primary business object is a Resulting Object (eg a wtpart) on the Change Notice.
More specifically it is this line of code that is doing this:
com.ptc.windchill.pdmlink.change.server.impl.WorkflowProcessHelper.releaseChangeables((wt.change2.WTChangeOrder2)primaryBusinessObject);
Setting the com.ptc.windchill.pdmlink.change.server.impl.WorkflowProcessHelper.releaseChangeables logger to debug and the running the WorkflowProcessHelper.releaseChangeables(ecn) results in "Attempting to terminate workflow process..." lines in the MethodServer log. eg:
2022-09-09 11:21:45,071 DEBUG [ajp-nio-127.0.0.1-8010-exec-1] com.ptc.windchill.pdmlink.change.server.impl.WorkflowProcessHelper wcadmin - Attempting to terminate workflow process for: wt.epm.EPMDocument:2439279269
2022-09-09 11:21:45,075 DEBUG [ajp-nio-127.0.0.1-8010-exec-1] com.ptc.windchill.pdmlink.change.server.impl.WorkflowProcessHelper wcadmin - Attempting to terminate workflow process for: wt.epm.EPMDocument:2439279268
2022-09-09 11:21:45,078 DEBUG [ajp-nio-127.0.0.1-8010-exec-1] com.ptc.windchill.pdmlink.change.server.impl.WorkflowProcessHelper wcadmin - Attempting to terminate workflow process for: wt.part.WTPart:2439333087
2022-09-09 11:21:45,103 DEBUG [ajp-nio-127.0.0.1-8010-exec-1] com.ptc.windchill.pdmlink.change.server.impl.WorkflowProcessHelper wcadmin - Attempting to terminate workflow process for: wt.epm.EPMDocument:2441409194
2022-09-09 11:21:45,106 DEBUG [ajp-nio-127.0.0.1-8010-exec-1] com.ptc.windchill.pdmlink.change.server.impl.WorkflowProcessHelper wcadmin - Attempting to terminate workflow process for: wt.epm.EPMDocument:2441409193
2022-09-09 11:21:45,109 DEBUG [ajp-nio-127.0.0.1-8010-exec-1] com.ptc.windchill.pdmlink.change.server.impl.WorkflowProcessHelper wcadmin - Attempting to terminate workflow process for: wt.part.WTPart:2441421304
I have opened a call to PTC to see if there is a preference or property we can set to turn off this behavior.
Does anybody else think this is a really bad idea, for the Change Notice workflow, to terminate existing running workflows on its Resulting Objects?
Are there some scenarios where this is the desired behavior?
Does anybody have any ideas on how to prevent this from happening?
I could tweak the workflow template and comment out this line however I really don't know what the "WorkflowProcessHelper.releaseChangeables()" is really doing. This would fix new Change Notice workflows.
We have over a hundred existing Change Notice workflows running and it would be nice to have a way to prevent WorkflowProcessHelper.releaseChangeables() from this nasty behavior.
Solved! Go to Solution.
I have done the following for new change notices going forward:
public static void releaseChangeables(VersionableChangeItem object) throws WTException {
if (object instanceof ChangeOrder2) {
ChangeOrder2 changeOrder = (ChangeOrder2) object;
TransitionHandlerFactory.getInstance().transitionTargets(changeOrder, null, false);
} else if (object instanceof ChangeActivity2) {
ChangeActivity2 changeActivity = (ChangeActivity2) object;
TransitionHandlerFactory.getInstance().transitionTargets(changeActivity, null, false);
}
WorkflowProcessHelper.updateEligibleChangeOrdersChangeVersionsForReleasedChangeables(object);
}
I have done the following for already in process not yet Released change notices:
I have also checked all existing workflows for any calls to WorkflowProcessHelper.releaseChangeables, WorkflowProcessHelper.processAndTransitionChangeables, or WorkflowProcessHelper.terminateWorkflowProcesses. I did this by exporting all workflows to a zip file, unzipping and then grepping for these calls in the resultant *.xml files. I did not find any except in the Change Notice workflow. However who knows if some other method ends up terminating workflows.
I still can't believe that terminating existing running workflows is something that is "Working to spec". Certainly is not my idea of "Working to Spec".
I believe the source code of the WorkflowProcessHelper is provided so you can see what its doing, create your own version of the method and replace it. In general, having workflows running against objects like WTParts is seen as bad practice. The normal set state action has options to terminate running workflows when changing states. The change object workflows move the states along for resulting items and capture approvals against a single object which can impact multiple other objects. This is preferred over thousands of workflows running against each WTPart or CAD Document.
While early on in Windchill's development, having little workflows running during each phase transition and state was possible and still is, it became the norm to have a single workflow at the initial state which moved the object through its lifecycle. This provided an ability for a single continuous process and provide data across its states.
@avillanueva wrote:
I believe the source code of the WorkflowProcessHelper is provided so you can see what its doing, create your own version of the method and replace it. . . .
I was not aware that PTC supplied source code for Windchill classes. I have just finished looking at any jar files under Windchill and looking for WorkflowProcessHelper.java. The only thing found is WorkflowProcessHelper.class. Starting from /opt/ptc/Windchill/Windchill I ran the following:
for jar in `find . -name '*.jar' -print`; do echo doing $jar; jar tvf $jar | grep -i workflowprocesshelper; done
and found nothing related to the source code in question. Do you know where this source code is located at/in?
Perhaps I am mistaken or dating myself. I could have sworn at one time it was provided. It is documented in Java Docs. I have created my own Helper class for most of my workflow tasks.
Forgot to include Windchill version: 12.0.2.7
@RandyJones , hi
It appears the method WorkflowProcessHelper.releaseChangeables() makes a call to method processAndTransitionChangeables().
processAndTransitionChangeables makes a call to method terminateWorkflowProcesses().
terminateWorkflowProcesses makes a call to WfEngineHelper class which terminates the workflow.
Interesting. Not a day goes by.
I must admit, I've always used my own class to set state to Released (or whatever) in workflows.
Initially, I did this to ensure the target state was in the objects LifeCycle. If the target state was not in the objects LC I'd find the latest iteration of the LC's LifeCycleTemplate and check if the target state was in the latest LCT. If, yes, the code would reassign the LC using the latest LCT and then set the objects state. If no, a task is set to the appropriate people to fix the problem.
And we have a brand new article: CS376605 The Out-of-the-Box Change Notice "Release Changeables" activity terminates existing running workflows on the changeables in Windchill PDMLINK
I have done the following for new change notices going forward:
public static void releaseChangeables(VersionableChangeItem object) throws WTException {
if (object instanceof ChangeOrder2) {
ChangeOrder2 changeOrder = (ChangeOrder2) object;
TransitionHandlerFactory.getInstance().transitionTargets(changeOrder, null, false);
} else if (object instanceof ChangeActivity2) {
ChangeActivity2 changeActivity = (ChangeActivity2) object;
TransitionHandlerFactory.getInstance().transitionTargets(changeActivity, null, false);
}
WorkflowProcessHelper.updateEligibleChangeOrdersChangeVersionsForReleasedChangeables(object);
}
I have done the following for already in process not yet Released change notices:
I have also checked all existing workflows for any calls to WorkflowProcessHelper.releaseChangeables, WorkflowProcessHelper.processAndTransitionChangeables, or WorkflowProcessHelper.terminateWorkflowProcesses. I did this by exporting all workflows to a zip file, unzipping and then grepping for these calls in the resultant *.xml files. I did not find any except in the Change Notice workflow. However who knows if some other method ends up terminating workflows.
I still can't believe that terminating existing running workflows is something that is "Working to spec". Certainly is not my idea of "Working to Spec".