Make Change Notice Act Like Promotion Process (Set State Resulting to Under Review)

[BrianSullivan]

Hello.

On Windchill 9.1 M050:

Did anyone have a Work-Around for Windchill 9.1? Either Set State Java Code for an Expression Robot in the Change Activity (Change Task) Workflow? Or a Method for Transitions to work?

Looking FOR:

Set State java Expression for a Change Activity;

I have:

A. Ability to use Transitions such as (Review and Refine) at the Change Notice Level.

B. Java Code to Set State on Resulting Objects at the Change Notice Level

C. Transitions Work in Change Activity Level in 10.0 (But we are on 9.1)

The Goal in 9.1is to mimic Promotion Process in a Change Activity Workflow; Resulting Objects would change from "Design" to "Under Review" while being reviewed by the Reviewer; If the Reviewer selected Rework Route then the Objects would be reset to "Design"

Not as good ofcourse at the Promotion Process Lock Functionality since that changes to "Under Review" and when you "unlock" sets data back to its Original State.

We except that all data in resulting list would change.

Also, After Review, we have an Approver Activity which following, we would want to change state to "Manf Review in Process"; Since they are not part of Windchill, they may ask for a change, so best to be in the Change Activity Workflow.

OOTB Windchill 9.1

Expects you to use the Change Notice Workflow, which is not practical, since the Change Activity Workflow closes when it goes back to that level; A Rework requires changes to the closed Change Task and the Workflow can not be restarted; Also if you had multiple change Activities they could be related to completely different groups of people; And One Finishes well before the Other... so Auditor not informed until all Activities are done....

Change Activity Workflow best use...

Brian Sullivan

PS
Set State Code for CN Level Below:

wt.fc.QueryResult result1 =wt.change2.ChangeHelper2.service.getChangeActivities((wt.change2.ChangeOrderIfc)primaryBusinessObject);

wt.fc.QueryResult RI_table;

while (result1.hasMoreElements()) {

wt.change2.WTChangeActivity2 ca = (wt.change2.WTChangeActivity2)result1.nextElement();

RI_table =wt.change2.ChangeHelper2.service.getChangeablesAfter(ca);

while ( RI_table.hasMoreElements()){

wt.fc.WTObject object2 =(wt.fc.WTObject) RI_table.nextElement();

if (object2 instanceof wt.part.WTPart) {

System.out.println("**************FROM WF PRINTING RESULTING OBJECT2*****"+object2);

String varState="UNDERREVIEW";

//set the lifecycle state using the following API.

wt.lifecycle.LifeCycleHelper.service.setLifeCycleState((wt.part.WTPart)object2,wt.lifecycle.State.toState(varState)); }

else if (object2 instanceof wt.doc.WTDocument) {

System.out.println("**************FROM WF PRINTING RESULTING OBJECT2*****"+object2);

String varState="UNDERREVIEW";

//set the lifecycle state using the following API.

wt.lifecycle.LifeCycleHelper.service.setLifeCycleState((wt.doc.WTDocument)object2,wt.lifecycle.State.toState(varState)); }

else if (object2 instanceof wt.epm.EPMDocument) {

System.out.println("**************FROM WF PRINTING RESULTING OBJECT2*****"+object2);

String varState="UNDERREVIEW";

//set the lifecycle state using the following API.

wt.lifecycle.LifeCycleHelper.service.setLifeCycleState((wt.epm.EPMDocument)object2,wt.lifecycle.State.toState(varState));

[MikeLockwood]

We do exactly this for two types of "change."

For all product data, we use a two phase lifecycle with state-based versioning (modified from the OTB sample from PTC). Seems that all who use this approach have a similar need.

* For the first phase (generally numbered Revisions), used for development, users need to be able to freely Revise and Iterate, but the business needs some control over the state change to a more mature state, at which prototypes can be made, quotes obtained, etc.

* For the second phase (generally letter Revisions), used for production, the business needs to control Revise and Iterate more closely, allowing these only after a change has been discussed and agreed on.

* Note: Getting from the first phase to the second phase in an elegant way requires another type of change, involving Revision, Iteration and state change. The OTB two-phase LC has a major flaw in logic in this area.

* Going to Obsolete at some point is handled various ways by different companies; we simply change the state of the last Revision to Obsolete (thru a change process), in coordination with obsoleting in ERP.

All this is much better discussed and explained with two-dimensional diagrams (a State / Revision grid). We've been working on such diagrams and explanations for 8+ years.

So,

* For the first phase and also for obsoleting, only a controlled (routed approval) state change is needed. Promotion would be the ideal for this, but Promotion is very limited in terms of collecting additional objects (even after the available changes in 10.x to update to the latest Iterations). We use a change task here with the data to be changed listed on the Resulting Objects table.

* On these subtypes of change, we use simple code to accomplish getting objects into the correct place:

o We copy all objects from the CT Affected objects table to the Resulting objects table

o We then delete all objects from the CT Affected objects table