Skip to main content
R
RandyJones20-Turquoise
20-Turquoise
September 9, 2022
Solved

Change Notice workflow "Release Changeables" activity terminates any workflows on Resulting Objects

  • September 9, 2022
  • 5 replies
  • 2537 views

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.

 

Best answer by RandyJones

I have done the following for new change notices going forward:

  • Created my own releaseChangeables() method in one of my helper classes using code supplied by PTC. "The following code can be used to release changeables without terminating the associated workflow:" Many thanks to the TSP who emailed me this!
  • 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);
}
  • Modified our custom Change Notice workflow Release Changeables activity to use my new releaseChangeables() method.
  • This fixes change notices created after the updated custom Change Notice workflow.

I have done the following for already in process not yet Released change notices:

  • Added a new "In process workflow(s). " check to the already existing custom "Change Task BRC" business rules checker class.
    • This new check checks each Resulting Object in the Change Task for any in process workflows and will add these as errors in the custom table shown in the custom "Change Task BRC" tab. This only does this check if the Change Notice is created on or before the date the Change Notice workflow was updated above.
    • This must pass before the user can "Complete Change Notice Task" task
    • This will stop the Change Notice workflow from progressing until the In Process workflows are taken care of.
  • Created a custom class "FindResultingObjectsWithWorkflows" that searches for all Change Notices with State Implementation or Under Review and createdOn on or before the timestamp of my fixed custom Change Notice workflow. This then finds the resulting objects of these change notices and any in process workflows with the resulting object as the PBO. I have a custom jsp page in which I can run this at any time.

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

 

5 replies

avillanueva
23-Emerald I
avillanueva23-Emerald I
23-Emerald I
September 9, 2022

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. 

R
RandyJones20-TurquoiseAuthor
20-Turquoise
September 9, 2022
@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?

avillanueva
23-Emerald I
avillanueva23-Emerald I
23-Emerald I
September 9, 2022

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.

R
RandyJones20-TurquoiseAuthor
20-Turquoise
September 9, 2022

Forgot to include Windchill version: 12.0.2.7

D
18-Opal
d_graham18-Opal
18-Opal
September 10, 2022

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

 

R
RandyJones20-TurquoiseAuthor
20-Turquoise
September 15, 2022

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

https://www.ptc.com/en/support/article/cs376605

R
RandyJones20-TurquoiseAuthorAnswer
20-Turquoise
September 23, 2022

I have done the following for new change notices going forward:

  • Created my own releaseChangeables() method in one of my helper classes using code supplied by PTC. "The following code can be used to release changeables without terminating the associated workflow:" Many thanks to the TSP who emailed me this!
  • 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);
}
  • Modified our custom Change Notice workflow Release Changeables activity to use my new releaseChangeables() method.
  • This fixes change notices created after the updated custom Change Notice workflow.

I have done the following for already in process not yet Released change notices:

  • Added a new "In process workflow(s). " check to the already existing custom "Change Task BRC" business rules checker class.
    • This new check checks each Resulting Object in the Change Task for any in process workflows and will add these as errors in the custom table shown in the custom "Change Task BRC" tab. This only does this check if the Change Notice is created on or before the date the Change Notice workflow was updated above.
    • This must pass before the user can "Complete Change Notice Task" task
    • This will stop the Change Notice workflow from progressing until the In Process workflows are taken care of.
  • Created a custom class "FindResultingObjectsWithWorkflows" that searches for all Change Notices with State Implementation or Under Review and createdOn on or before the timestamp of my fixed custom Change Notice workflow. This then finds the resulting objects of these change notices and any in process workflows with the resulting object as the PBO. I have a custom jsp page in which I can run this at any time.

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

 

    Terms & ConditionsCookie settingsAccessibility statement