Results of Single Level Version Conversion Utility

[avillanueva]

I wrapped up my questions to PTC with utility "works to specification" which is not the deep level of understanding I was hoping for, I was assured that things like purging and deletion would be unaffected but I want to test that to be sure or at least document them. @Marco_Tosin, let me know if you've seen anything odd since you said you ran this before me. 

Here is what I wanted to document. In our use case, all MFG views were created from the Design view using "New View Version". We never revised from the MFG view downward.

I am sure the conversion had to make some compromises for other use cases but the database does record the predecessor version in its tables showing it came from the Design view in each case. Post conversion, except for the first version of the MFG view, all now show as revises. 

While the predecessor version was altered, as mentioned in my previous post, the iteration that the version was created from was retained showing the Design version. The database records somewhat disagree with each other. PTC indicated that this was ok and should not impact integrity and functionality. I have to their word for now but I will close with some testing results. I just wanted to clearly document things for others though I expect I am a behind the curve on this one. 

[Marco_Tosin]

@avillanueva 

we did just this morning the migration of data from the current 12.0.2 test server to the new 13.0.2 test, with the modified single-level revision scheme.

I have talked to my consultant about what you wrote above, to see if we can give you some information of how we solved the problem you report.

As soon as possible I will post what we can share that might be helpful to other users as well.

[avillanueva]

Lost me on the first part. Is your production system passed this conversion and on 13? I am thinking my only path forward is after the conversion is complete is to run SQL updates to shift the revision letter forward which should not impact much, Its just a text field. Goal is to keep the Design View and Mfg View revisions in line. 

[Marco_Tosin]

We have just started the activity for the upgrade.

This morning we completed the migration of data between the test systems.

Into production with version 13.0.2, if all goes well, we should go in early June.

Bear with us for the more detailed response but we are working, even now, to complete the installations on the new test server of the various connectors of the systems connected to Windchill.

[Marco_Tosin]

Hi @avillanueva,
sorry for the delay but I was waiting for our consultant to have time to explain, even to me, what he had done before sharing it.

Below is the explanation of how we solved what you are experiencing as a problem.

The behavior you are observing seems to be the default of Windchill when using the single-level revision schema.

This occurs because, when directly revising the manufacturing view, the predecessor of the new revision is indeed the previous revision of the same branch of the view.

We assume this behavior is indeed what PTC intended, as in the context of a system managing the manufacturing BOM, PTC likely envisions the installation of the MPMLink module and the management of the information regarding which design view generated the manufacturing view through equivalence links.

To overcome this behavior, we implemented a custom listener that, during the revision of the view, navigates backward through the control branches of the object, determines which design revision gave rise to the manufacturing view, and sets a custom attribute called "Design Revision" with the expected value.

[avillanueva]

Perhaps I can chat them up at the conference. I am curious to know how they think we should be using the Mfg view too, even if we are not using MPMLink. Ensuring accuracy between the two is key for me which is why I'd rather see it get created from Design view each time so they do not wander apart. Worse case would be if someone updated their CAD and those changes were missed in the MBOM. Thanks. 

[avillanueva]

Just providing some updates on this topic. I completed a second conversion and ran the query I posted as solution here:

https://community.ptc.com/t5/Windchill/Single-Level-View-Version-Conversion-Deprecation-and-warning/m-p/985989#M83123

This shows me what the versions need to be to align with Design View. I was able to reduce that to just updating by branch ID to sets of these updates scripts in this form:

UPDATE WTPART SET versionida2versioninfo='B' WHERE BRANCHIDITERATIONINFO=1153919464;	
UPDATE CONTROLBRANCH SET VERSIONID='B' WHERE IDA2A2=1153919464;

12K lines later its complete with a few zone constraint violations. I needed to make sure I run them from latest version backward. Can't have two branches with same letter. Spotted some errors that I was able to manually correct but its done.  Next on to some code updates to block revising in certain conditions. 

[avillanueva · Accepted solution]

Closing out this thread with my final notes. We ended up successfully applying version letter changes to meet goal of aligning the MFG version to the Design version it was "derived" from. Found a couple of stragglers but all clear. Next we moved on to keeping things in sync. One solution was to prevent users from revising MFG view version. This can be done by a filter on the action but does not catch all cases like revising from change tasks and multi-object revisions. We could continue down the filtering avenue but we employed a listener on NEW_VERSION that catches all and throws a WTException. Action filters do provide a better, up front user experience. 

Our logic works like this: Goals is to allow a one time only action from Design to create a New View version to Mfg from any specific Design version but that must be done in order. Our series goes from -, A, B, etc. There are two conditions the listener checks on:

• What is the version of the MFG to be created? Does it equal "-" or first version? (X)
• Second case is does the MFG version being created match the version letter of its predecessor Design view version? (Y)

From here we can construct the following truth table:

X	Y	X OR Y	Resulting Action
T	T	T	Ok - Do nothing
T	F	T	Ok - Align Versions
F	T	T	Ok - Do nothing
F	F	F	Throw Exception

Check condition Y first and if true, no action needed. If X is true, align version. If X is false, throw an error since this would case Design and Manufacturing to get out of sequence. To align the versions, I will link back to this thread:

Set Revision API is failing to set same Revision for Manufacturing View Part and Design part. 

We had to use a different method, similar to updateVersionIdentifier by taking the version identifier from the Design View and applying to the Manufacturing View and PersistenceServerHelper.manager.update for both the Part and ControlBranch.

[HelesicPetr]

Hi @avillanueva 

Good work. 

Thank you for sharing your experience. It is very useful knowledge. 

PetrH

[HelesicPetr]

Hi @avillanueva 

Have you got any information, why this schema is going to be rid of ? 

I would like to hear any real reason from PTC but it is as a gramophone . They still repeat "Works to product specification" :D. 

PetrH

[avillanueva]

Which schema? Do you mean support for multi-level versioning? No, I will ask at the conference but its likely the decision was made along time ago. I suspect it had something to do with MPMLink and tools to sync between the views. Its is a simpler structure. All I know is we will see a rash of posts on this as users move to 13 since its now a requirement to upgrade.

[HelesicPetr]

@avillanueva 

Yes, the multi-level schema. 

You right 😄 it depends on how many companies use the multilevel versioning schema.

In our region, there are not so many companies that use it.

PetrH