≡ Menu

Item Revisions vs. ItemRevisions

Share the knowledge

Here’s a story about the latest snag we’ve encountered in the process of migrating from Teamcenter Engineering to Teamcenter 8.3.

Background

In addition to upgrading from Teamcenter Engineering 2007 to Teamcenter 8.3, we’re also transmorgifying our data model at the same time, the precise reasons for which I may review in detail at another time or in another venue. Anyways, I’ve been using the BMIDE to design our new data model and others have been working to figure out how to get from the old data model to the new one. The current plan involves upgrading our TC Engineering instance in place, using some of the out of the box utilities for renaming types and changing item type — namely, item_to_part_design — and then installing the model I’ve been working on to arrive at our final, new, data model.

So anyways, a couple of weeks ago we ran through the first trial where we duplicated our production TC Engineering database and ran through the entire upgrade process until we ended up with what we thought was a TC 8.3 instance with our legacy data and our new data model. And at first glance, it seemed to have worked fine.

Trouble in Paradise

The first indication of a problem was when I went to look at the property page of one of our types. Immediately, the style sheet used to render the properties threw a slew of java NULL errors which indicated that the new properties I had added to the item type were not found where they were expected. Then, when I tried to save-as to a new item of that type, I could not, the problem being that a post-action I had set on item creation to populate the new attributes failed horribly because the attributes it was attempting to populate did not exist.

So, next we tried disabling all customizations and then creating a new item. Too our surprise, not only did that allow us to create an item, but the new item did have the new attributes. So somehow or the other, the legacy data did not have the new attributes, but new items did.

Class Problems

It took a day or two of investigation to figure out what had gone wrong. As it turned out, it was all because of a space.

In our Teamcenter Engineering instance we had this item type,

DojoItem

(the names have been changed to protect the guilty)
So, when I was designing the updated model in the BMIDE I created a business object called,

DojoItem

And that was all well and good.
Of course, if you’ve ever created a business object with the BMIDE you know that several other business objects and storage classes are created automatically. In particular, the BMIDE created a business object and class named,

DojoItemRevision

And that’s where the problem was.
You see, when we had created DojoItem in TC Engineering, TC Engineering had created a type and class called,

DojoItem Revision

You see the difference? That extra space before “Revision” was what killed us.

After the upgrade, we had a revision type called DojoItem Revision. When they deployed the template with the final data model, a new revision type was introduced, DojoItemRevision. All the legacy data had the old revision type, but any newly created items got the new one.

Next Steps

So now we’re running through a second attempt at upgrading from TC Engineering to TC 8.3. This time however, we’ll extract our legacy types out into an extracted template and then modify that template to finalize the data model. I expect I’ll be doing lots of hand editing of XML files to reconcile what’s been developed with what’s extracted.

Looking Back

I suppose you expect me to say, If I could do it again I’d do it differently. I’d start with an extracted data model first. I wouldn’t try to develop the new model from scratch in the BMIDE. Well, sorry. I’m not ready to say that. As it were, we’ve been hashing out our new data model for months. But it was only recently that the upgrade team settled on the current migration path. Had other options panned out we wouldn’t have been deploying my templates to an upgraded system anyways, and regardless (or irregardless, for those of you from Michigan) my data model development would have been set back months if I had waited for the first trial upgrades to happen.

So, moral of the story is… I dunno. I guess that it’s upgrades are hard, and changing your data model is hard, and doing both at the same time is hard squared. So expect there to be unexpected problems.

  • http://hooverm.pip.verisignlabs.com/ Teamcenter Heretic

    It has been a while since I’ve dug into this issue but I seem to remember even some of the OOTB stuff in earlier versions had this issue.
    I seem to remember some ITK I wrote that tried to get some stuff with either the ACME Revision or ACMERevision and it gave me fits.
    Seems that it was the wild wild west for developers in the past 😉

    Even better than that is whenever I run across custom stuff where the developer misspelled an attribute or property ala acme_securiy_code instead of acme_security_code

  • Patrick

    This is helpful.  Thanks.

    Also, I’m curious what path was decided upon for your upgrade from TcEng 2007.

Optimization WordPress Plugins & Solutions by W3 EDGE