Revising Using Workflow

[Toby.Pettit]

Hi,

I have a need to automate a revise using workflow and was wondering if anyone could tell me the expression I need.

There are two occasions when I need it, once in a promotion workflow and once in the change notice workflow.

Regards,

Toby

[MatthewKnight]

VersionControlHelper.service.newVersion. I'm not sure if the new version is persisted.

Don't put this directly in the expression. Put it in your own class and method and call that method from the expression. Later, if you decide you don't want to auto-revise, you can simply comment out the .newVersion stuff inside your method.

[Toby.Pettit]

That will suit me fine as a back up however my company is fairly limited in what we are allowed to do outside of the Windchill GUI due to imposed restrictions from our parent. The reason being that it makes it harder to upgrade and they want to keep maintenance to a minimum.

If anyone knows of a way I can do it in an expression that would be great? Otherwise thanks Matthew and I'll try and make the business case.

Regards,

Toby

[MatthewKnight]

In an expression, you have access to at least two things.

1. ObjectReference self

2. WTObject primaryBusinessObject

Try something like:

primaryBusinessObject = (wt.fc.WTObject)wt.vc.VersionControlHelper.service.newVersion((wt.vc.Versioned)primaryBusinessObject);

primaryBusinessObject = (wt.fc.WTObject)PersistenceHelper.manager.save(primaryBusinessObject);

You should probably do this inside a try catch and even inside a Transaction. One possible reason this would error is because somebody has not checked in the business object before the expresison fires.

[Toby.Pettit]

Checking the syntax it comes up with one error:

Checking Syntax...

/apps/ptc/Windchill_9.1/Windchill/tmp/WfExpression8831407.java:29: package PersistenceHelper does not exist

primaryBusinessObject = (wt.fc.WTObject)PersistenceHelper.manager.save(primaryBusinessObject);

^

1 error

Syntax check complete.

Toby

[MatthewKnight]

"package PersistenceHelper does not exist"

wt.fc.PersistenceHelper

[AmolVairagkar]

Here is the modifed expression.Should work!

wt.vc.Versioned newObject = wt.vc.VersionControlHelper.service.newVersion((wt.vc.Versioned) primaryBusinessObject);

wt.fc.PersistenceHelper.manager.store(newObject);

-Amol

[Toby.Pettit]

Both suggestions do not produce errors. I will test tomorrow morning to check I get the behaviour I want. Thanks guys!

[Toby.Pettit]

Well I tried it and it occurred to me I may not have worded the question properly. I want the promotion request to revise the objects in the promotion. I need this because I need to to promote to a state (implementation) and then revise to the Production state (going from a numeric to a mil std revision). The ERP connector is then triggered but the change in revision scheme is a requirement to put it into the Production life cycle state in our ERP system.

So, and I think I know the answer, can I revise the content of the promotion request within a workflow without customisation?

Toby

[MikeLockwood]

This is available OTB with 10.0 M020

[Toby.Pettit]

So it can be done when we upgrade, however we are currently only running 9.1... So can it be done?

Toby

[NickD]

Mike,

I've looked in the Workflow Template Administrator in v10.0 M020, and (apart from it taking ages to load compared with the previous versions...) I could not see any new additions to the UI to do a Revise action automatically in the Method Robot or Expression Robot. Can you be more explicit about where the new functionality in v10.0 is made available OOTB ?

ta'

Nick

[Nitin]

This has been an interesting discussion. I just tried to find out how to accomplish this in Windchill 10.0.

In Windchill 10.0, promote and revise simultaneously is acheived by combination of a preference and some customization -

Preference is 'Automatic Revision Mode'

A workkflow expression is required to be added with a new API -

com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.revisePromotables(..)

This is also documented in Windchill 10.0 Customization Guide: Procedure - Adding Automatice Revisioning.

[NickD]

Thank you for the pointer to relevant section in the v10.0 manuals. Some more bedtime reading !

Like others have posted, we also need to find a way to achieve the same result (or effectively the same result...) in v9.1 M060/062, ie. to achieve a simultaneous revise and promote, or perhaps an automatically linked sequence of revise and promote, for a list of CAD files on one promotion request. We would also like to edit a couple of file based Parameters (mapped to Attributes) at the same time, so that they appear on the published viewable copy of the drawing along with the new issue number and Lifecycle state.

We plan to use 9.1 as a stepping stone between Intralink v3.4 and PDMLink v10.0, to avoid having to upgrade Pro/E from Wildfire3 to Wildfire4 at the same time, as that would be far too disruptive. Hence we need a relatively short term solution that works with Promotion Requests &/or Notices (we could omit using Change Requests & Notices until sometime after we get to v10.0 - as we don't have them now in Intralink v3.4 !).

Intralink v3.4 has a Check-In option to 'Promote Configuration' - so it makes an RTP form directly off a Check-In form, starting with the same list of objects. It also allows the user to set a new (target) Revision number on any checked-out/modified file before it is checked in. In PDMLink there appears to be no easy way to pass a list of selected objects directly from a Check-in form to a Promotion Notice, and the Revise action can only take place on checked-in files. Hence it appears much more difficult to setup the combination of : editing parameters, setting revison number(s) and promoting files that is required to embody our company procedures.

Any further help gratefully received.

Nick

[ShawnPete]

I'd like to do this too. Currently I have a task that requires the initiator to do this manually. It would be really nice if the workflow would revise the object without interaction from the initiator.

I have the same issue, Toby. We have one revision scheme for New and R&D states in the lifecycle, but another for Released objects. I promote an object to a temporary state (Pre-released) then revise the object to Released with the new revision scheme. I am using Windchill 9.1 M060 and may go to Windchill 10, but not for some time.

[Toby.Pettit]

Are you wanting to revise just a single object, the objects attached to a promotion request or changeables attached to a change request?

I managed to get it to revise all the objects attached to a change request - the code is quite easily changed to revise baselines of a promotion request. If you are revising a single object Amol's answer is just fine.

I do not have access to the code right now for the others but I will tomorrow morning (GMT).

Toby

[ShawnPete]

All the objects attached to the promotion request.

Shawn

[Toby.Pettit · Accepted solution]

I have not tested it (like I said I had it working properly with changeables) but something like this should work:

try

{

wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice)primaryBusinessObject;

wt.fc.QueryResult qr = wt.maturity.MaturityHelper.service.getBaselineItems(pn);

while (qr.hasMoreElements()) {

wt.vc.Versioned obj = (wt.vc.Versioned) qr.nextElement();

wt.vc.Versioned newObject = wt.vc.VersionControlHelper.service.newVersion(obj);

wt.fc.PersistenceHelper.manager.store(newObject);

}

}

catch (wt.util.WTException ex)

{

}

Toby

[ShawnPete]

Using the code you mention how would I get the promotion notice to approve those revisions. I would still like the new revisions to be tracked and linked to the promotion.

[Toby.Pettit]

Hi Shawn,

I do not know off the top of my head how to attach the newly revised objects to the promotion notice. Unattaching them is simple enough if you do not want the old revisions on the promo request as well.

We have a different solution to the problem.

We do not revise the object to give it an Alpha (Production) revision scheme, we relabel it during the promotion process. The benefit is that an intermediate state is no longer needed. We promote straight from our Design state to Production state directly (with a rev scheme change along the way)

By "relabelling" I mean if we approve a part at revision 1.3 for Production, we replace the revision with A.1. 1.3 and A.1 are identical, in fact they are the exact same Windchill object. If you look at the objects revision history it will read something like: 1.1, 1.2, A.1.

There is no need to attach it to the promotion request, it is already there.

Toby

[NickD]

Hi Toby,

Could you please expand a bit on what you have mentioned as "relabelling" ?

Could you bump up the revision number within the same revision sequence, ie. from 1.3 to 2.1 ?

Is this achieved in a Workflow with a Robot ?

thanks,

Nick

[Toby.Pettit]

Hi Nick,

If you want to just bump it up like that then all you need to do is revise it.

However, as a requirement from our ERP system I do not want to create a new version of something to switch from numeric to alpha, I just want to relabel it. Numeric was pre-production (unreleased), alpha for production items.

Both of the above can and I have done in workflow expressions. Revising an object in a workflow does have issues if the old revision was attached to another obejct (e.g. Change Notice or Promotion Request).

Regards,

Toby

[NickD]

Hi Toby,

As well as bumping up the Revision number for each of the CAD files on the Promotion Request, we also want to change the value of 2 or 3 of the file-based parameters and promote the files to a new state (as I have explained a bit more in my other posting on this thread, above).

I think we could live with a process that included a user activity task to enter the attributes manually (at the expense of another check-out and check-in ?), but then we'd want to get those CAD docs & files Revised and Promoted immediately. For example, at the expense of an extra stored iteration we could :

- have the designer select the files from 'commonspace' and start a promotion request

- if the request is approved then have the approver enter the parameter values (eg. external change note no.) along with their name and date of approval - and set these 3 attribute values in the CAD files followed by an immediate check-in, revise & promote in automatic succession

- if the request is rejected then nothing happens to the files, and the designer has to start again

This may be a bit crude and simple, but I expect it would suffice until we can get up to v10.0

Can you suggest how we might achieve this ?

Many thanks,

Nick

[Toby.Pettit]

Hi Nick,

To revise every object on the promotion request, put this in an expression robot (or better yet a Conditional with 'result = "FAIL"' in the catch leading to an Admin task) after your approval task.

try {

wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice)primaryBusinessObject;

wt.fc.QueryResult qr = wt.maturity.MaturityHelper.service.getBaselineItems(pn);

while (qr.hasMoreElements()) {

wt.vc.Versioned obj = (wt.vc.Versioned) qr.nextElement();

wt.vc.Versioned newObject = wt.vc.VersionControlHelper.service.newVersion(obj);

wt.fc.PersistenceHelper.manager.store(newObject);

}

} catch (wt.util.WTException ex) {

}

The downside with this though is the new revision will not be attached to the promotion request (I think).

These attributes you speak of, are they on one promotable or all of them? If on all of them, are the values unique? If every object, or one object that is identifyable (by type, name etc) all have the same attribute values, I can show you how to have the user enter the values in a task rather than manually check the objects out. The objects would still be checked out, but by the system.

Regards,

Toby

[mmontgomery]

Greetings All,

I've been trying to set up a promotion process to revise an object so that we'd have a formalized, documented reason for the revision. This has been working however I noticed that when the promotion objects are revised, the old versions no longer maintain they're original state (released - no modify rights) but take on the new state (rework required - can be modified) that the new version moves to. This has become an issue because users have been able to inadvertently check out a previous revision as it is left in the modifiable state after completion of the promotion request. This is not what I want. As a note, we do have the 'allow checkout of non-latest iterations' set to 'Do not allow...' Not sure why that is not stopping the checkout of previous iterations.

In contrast, if we simply do a right-click>revise from admin - the old state (released) is maintained on the old version and the new version is in the new state (rework required). This is what I want.

Any help would be greatly appreciated.

Marc

Here is the default code for revisioning in the OOTB 10.2:

wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice)primaryBusinessObject;

try

{

java.util.Locale locale = wt.session.SessionHelper.getLocale();

com.ptc.core.ui.validation.UIValidationResultSet set= com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.revisePromotables(pn, pn.getCreator(), locale);

reviseValidationMsg= com.ptc.windchill.enterprise.maturity.validators.PromotionTargetsReviseValidator.getReviseResultSetMessage(set, locale);

if (!reviseValidationMsg.isEmpty() )

result="Partial";

else

result="Full";

}

catch( Exception wte )

{

wte.printStackTrace();

}

*Update*

It looks like this code won't run without the code that promotes the objects ahead of it. This is clearly a problem as I think the solution to my problem is to do the revision before the promotion. Anybody know how to do a revision before a promotions?

[mmontgomery]

Does anybody out there know why the above conditional routing expression, that revises the object, won't work unless it is preceded by the following conditional routing expression that promotes the object? I'd like to revise the object before it's promoted so as to preserve the state of the original promotion object.

wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice)primaryBusinessObject;

try

{

wt.util.WTProperties props = wt.util.WTProperties.getLocalProperties();

VERBOSE = props.getProperty("wt.maturity.verbose",VERBOSE);

}

catch( Throwable t )

{

}

try{

wt.maturity.MaturityServerHelper.service.promoteTargets (pn);

/* If any of the promotion targets are Advanced Configurable Generics the

* baseline used during collection needs to be set on the generic as the

* default baseline to properly support Options and Variants. If none of

* the promotion targets are Advanced Configurable Generics, this method will

* simply return.

*/

wt.maturity.MaturityServerHelper.setDefaultBaselineForGenerics(pn);

result="Approved";

} catch (wt.maturity.MaturityException me){

if ( VERBOSE )

me.printStackTrace();

errorMsg=me.getMessage();

result="Rejected";

}

[GKelly]

Is there an option to do essentially this same thing through a Change Notice workflow?  We are testing using an Alpha and Numeric versioning schema and without an automated revise when moving from Prototype to Full Production (Released) we need to follow a manual process to move from the Alpha to Numeric revision.