cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can change your system assigned username to something more personal in your community settings. X

PDMLink Version Series

avengerlegal
1-Visitor

PDMLink Version Series

Does anyone know of a way to set the versioning series of a Part to do the following.

Start a ProE part in Prototype at 1.1 then when that part gets released it goes to A.1 without using the revise function.

12 REPLIES 12

Its documented. State based versioning.


This is the single most important set of configurations there is in PDMLink.

Need to envision Next Revision / State change as X and Y axes on a graph. States are the X axis; Revisions are the Y axis. The Lifecycle Diagrams from PTC do not lend themselves to clear thinking / planning / training on these concepts.

Changing the state of a given Revision is a horizontal (X axis) change; the content does not change when only the state changes. No new data is created.

Changing the Revision is not really that - instead it is a Save-As operation, leaving the previous Rev alone, and adding a new thing to work on at the new Revision, generally also that "working state" for that Revision. At the end of executing New Revision, you have the original item plus another identical copy at the New Rev and at the working state.

When the Revision series needs to follow Numbers, then Letters, there are two choices - simple file-based or state-based. Much more to this - we can chat off-line if you like.

This is the single most important set of configurations there is in PDMLink.

I actually just opened a call similar to this where if you reassign from a lifecycle using numeric to one of alpha and you do a revise it doesn't pick up the change. My OIR uses hardvardseries.statebased.

But yeah it would be nice to have more flexibility here ootb without a file based xml load file. My issue is not having a known sequence between numeric and alpha hence the two LC solution.




Sent from my Verizon Wireless BlackBerry

Unfortunately StateBased versioning doesn't do this OOTB to the best of my knowledge. When you promote to Released, the Rev will not change from 1 to A...its only the NEXT time it's rev'd that it does the switch from 1 to A. There is a way to do this but it requires a modification to which ever workflow you are using to get up to released. Usually that is the "Promote" workflow. I don't have the information on hand on how exactly it's done at the moment.

Do you have to have the Rev changed when moving to Released? The software is designed to indicate, on the drawing, if something is released by mapping the "Lifecycle" state to the drawing and conveying the info in that method instead of the Rev.


Steve Vinyard
Application Engineer

[cid:image001.gif@01CB144B.3AB87160]

Need to also configure each LC state to use Numeric or MILSTD - have you done this?


Sure did!

We loaded in series resource bundle an additional one called alpha. I switched all states in one LC template to alpha and in the other all numeric.






Sent from my Verizon Wireless BlackBerry

Hi Dave, you might try reassigning the lifecycle again and then watch the MethodServer output...or review the log for it. At times there can be some issues behind the scenes that aren't apparent from the what the UI would tell you.

Steve Vinyard
Application Engineer

[cid:image001.gif@01CB145F.06132E00]

The whole point is that in a single Lifecycle template, some of the states are NUMERIC and others are MILSTD.

When you Revise from a state that is NUMERIC, it Revises to the next number Revision
When you Revise from a state that is MILSTD, it Revises to the first / next alpha Revision


From: - [

There is utility I don't have it handy to make objects change the versioning series called out by the oir

Let me know if you want me to dig it up

Sent from my iPhone

On Jun 25, 2010, at 3:07 PM, "Lockwood,Mike,IRVINE,R&D" <mike.lockwood@alconlabs.com> wrote:

> The whole point is that in a single Lifecycle template, some of the states are NUMERIC and others are MILSTD.
>
>
>
> When you Revise from a state that is NUMERIC, it Revises to the next number Revision
>
> When you Revise from a state that is MILSTD, it Revises to the first / next alpha Revision
>
>
>
>
>
> From: - [
>

I posted to this because I don't want states in the same LC to have different versioning series.

I understand how it is designed to work though.

Ideally, by having a reassign lifecycle it should behave the same way, but I'm going to customize to create new rev automatically and set it to a different LC template.

What this allows is for me to avoid calling the state of the object "production inwork" vs. "Inwork" . With one LC you would have to name your states with some kind of prefix to distinguish production vs prototype. I'm trying to avoid that.

So not to confuse anyone. I just thought I'd mention using two lifecycles to switch from versioning in prototype to production needs a little customization logic it appears.




Sent from my Verizon Wireless BlackBerry


So what I did at a previous customer was to use the State Based lifecycle, but we put in a state before Released, call it Release to Production or something like that. In this example we used a Promotion process to get it to this Release to Production state, whose versioning series was different Mil Std. I then had an expression robot that had the following code that was provided to me by a person from PTC, non-supported of course. The transition in the lifecycle was such that when you revised from the RTP state it went to their Released or Production state. This was all automated through the Promotion workflow.

I'm sure this could be done through an ECN process as well, the code below would need to be slightly changed to grab the ECN's affected objects instead of the Promotion Notices objects. Then you would probably need to add the newly revised objects to the Resulting data of the ECN.

Steve D.

wt.vc.Versioned versionedObj = null;
wt.fc.WTObject obj = null;
wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice) primaryBusinessObject;
wt.util.WTProperties props;

try
{
props = wt.util.WTProperties.getLocalProperties();
VERBOSE = props.getProperty("wt.maturity.verbose", VERBOSE);
}
catch (java.io.IOException e1)
{
e1.printStackTrace();
}
try
{

wt.fc.QueryResult queryresult = wt.maturity.MaturityHelper.service.getPromotionTargets(pn);

wt.fc.collections.WTCollection mycollection = new wt.fc.collections.WTArrayList();

mycollection.addAll(queryresult);

//Multi-revise all objects
wt.fc.collections.WTValuedMap versionMap = wt.vc.VersionControlHelper.service.newVersions(mycollection);

/*NOT COMPLETE: Set user of the new objects
Example:Iterated part = VersionControlHelper.assignIterationCreator( thePart, theNewCreator );
*/

wt.fc.collections.WTCollection versionscollection = versionMap.wtValues();

//NOT COMPLETE: Set folder, by checking the value of the folder for the original object
/*if(versioned instanceof Foldered)
{
Folder folder = ......
FolderHelper.assignLocation((FolderEntry)versioned1, folder);

}

*/

//Save new versions
wt.fc.PersistenceHelper.manager.store(versionscollection);
}
catch (Exception me)
{
if(VERBOSE)
me.printStackTrace();
}


In Reply to Charlie Jones:

Does anyone know of a way to set the versioning series of a Part to do the following.

Start a ProE part in Prototype at 1.1 then when that part gets released it goes to A.1 without using the revise function.

Charlie,
we are using a two phased life cycle which changes from NUMERIC to MILSTD
when going from In Work to Released. Windchill can not OOTB handle
changing both life cycle state and revision so we modified the Promote
workflow and added this expression method to automatically change to
MILSTD upon promotion from a NUMERIC to Released.

public void invoke(String targetstate, wt.fc.WTObject obj) throws
Exception
{ // Get the type identifier for the object taken into account
that it can be a subtype
String type =
wt.type.TypedUtilityServiceHelper.service.getExternalTypeIdentifier(obj);
// Cast the object to a Versioned
wt.vc.Versioned verobj = (wt.vc.Versioned) obj;
// Get the current version as a string value
String ver =
wt.vc.VersionControlHelper.getVersionIdentifier(verobj).getValue();
//Test if this promotion needs special
(version Numeric and targetstate RELEASED)
if(java.util.regex.Pattern.matches("\d*", ver)
&& ((targetstate.equals("RELEASED") &&
(type
.equals("WCTYPE|wt.epm.EPMDocument|com.company.DefaultEPMDocument") ||
type
.equals("WCTYPE|wt.doc.WTDocument|com.company.EngineeringDocument")))))
{ // Get the next available version
wt.vc.VersionIdentifier versionidentifier =
wt.vc.VersionControlHelper.nextVersionId(verobj);
// Set the version to the next available version
for all iterations and commit to the database
wt.vc.VersionControlHelper.service.changeRevision(verobj,
versionidentifier.getValue(),true);
}
}

Regards,
Bjarne



Charlie Jones <->
25-06-2010 18:09
Please respond to
Charlie Jones <->


To
-
cc

Subject
[solutions] - PDMLink Version Series






Does anyone know of a way to set the versioning series of a Part to do the
following.

Start a ProE part in Prototype at 1.1 then when that part gets released it
goes to A.1 without using the revise function.

Site Links: View post online View mailing list online Send new post
via email Unsubscribe from this mailling list Manage your subscription
Use of this email content is governed by the terms of service at:
Announcements


Top Tags