Migrating data into Teamcenter, Part 2: Taking Inventory

September 14, 2011 • By • Comments 0

Last time I discussed the problems with native NX CAD files while migrating data into Teamcenter that I’ve seen. This week we’ll begin looking at how to proceed with the migration — or at least what I’ve done. What I did may not work for your situation, but at least it should give you something to think about.

This Doesn’t Just Apply to Teamcenter and NX (Yet)

As some people commented about the previous installment, a lot of this information is not specific to either Teamcenter or NX. However, they are what I worked with so I will be referring to them, and as the series progresses and I get deeper into more technical matters the information will get more specific to those applications.

And with that bit of throat-clearing out of the way, let us proceed.

Zeroth Step: Inventory what you Have

I’m calling this step zero because it’s something you should do before you even start deciding what to migrate and how: make an inventory of every CAD file. Go find one of the grey bearded system admin guys[1] and have them write a script to crawl your directories and report every *.prt file they can find. At this stage I would advise against filtering out any of the raw data.

Report Format

A simple comma separated value (CSV) text file is fine. If you have a fancier option, that’s good too — as long as you’ll be able to access and manipulate the data later.

The nice thing about CSVs is that you can load the data into Excel, which pretty much everyone is comfortable with, is portable across operating systems, can be programmatically parsed pretty easily, and you can load it into a database, etc.

What to Report

Capture as much information as you can about the files: full file names and directory paths, owning users and groups, file sizes, creation dates, last modified dates, etc. etc. Obviously the specific information you can capture depends on the operating system on which the files are stored.

This information will come in handy later for a variety of uses, such as resolving duplicate file name questions. For example, if you find the same file name in two different directories with the exact same file size and modification time you can make a pretty safe bet that they are exact duplicates and you just chose one to ignore arbitrarily.

You’ll also want to include anything that you do to files to mark a file’s maturity, i.e. what do you do to files that have been released. Do you assign ownership to a particular user (root?) or group or set specific privileges? You may choose to use this information later when selecting which files to migrate and it may may also translate into statuses in Teamcenter later.

Resolve Symbolic Links Now

You will avoid needless complexity and confusion later if you only report “real” file paths and not any symbolic link paths. Otherwise you’re going to have a report that has duplicate entries for files; once under the “real” path name and again for each symbolic link.

Keep Up to Date

If users are still working in the directories from which you’ll be migrating, you’ll need to re-run the report periodically.

Related Posts

[1] Yes, I’m stereotyping, but you know exactly who I mean.