Export WTPart structure with associated documents to Excel

[ckg]

We have recently migrated from Intralink 3.4 to PDMLink 9.1 and I am looking for a wayof identifying ProE Models with associated ProE drawings. So far I have found a way to display this information within PDMLink by searching for the top level assy WTPart and showing the structure, then expanding and using 'Show documents'. What I cannot do is export a snapshot of this structure with all the associated ProE documentsincluded (see attached screen shot). Does anyone know if this is possible, and if so how is it achieved? Possibly it requires a script? Any advice gratefully received. Chris Glenister, Thermo Fisher Scientific, UK.

[bwilson-2]

The easiest way to accomplish this is to write a report in the report manager using the Query Builder. You should be able to get all the info you need in a report.

[MikeLockwood]

Don't know of any way to export as you say - hopefully others will answer.

Seeing the screen capture though, I'm curious why you have the same information in both Number and Name. Ideally the Name would be words that are helpful (e.g. bracket, module 23F, etc.).

[ddemay]

You could add the toolbar to that table that gives you the actions/menu for
export to excel. Never tried it. Best guess also is if you run the report,
might be a way to export.

[patrick.chin1]

Iforwarded the presentation of the download WTPart/EPM Structure which is what Najanaja.comprovidedfufilling my architecture design. With every download of WTPart, you'll get a tsv report at the level requested. You can do the view report first then export to TSV (tab dilimited in case of commas in the name) which will not get any associated documents, or you can just download the entire package based on various baselines. More advanced baselines are in the ECN reports during review. See attached.

the default configurations were:

• as stored
• latest iteration
• latest revision
• latest released

For the download, we went to expand the solution to include:

• EPM document effectivity based on ECN
• WTDocument effectivity based on ECN

We also did BOM Compare which is really cool. I believe Najanaja.com really done wonders with this. My requirements went further with comparing the following configurations of WTPart:

• as stored
• latest iteration
• latest revision
• latest released
• effectivity

http://www.najanaja.com/?q=node/5

All done by just using the links. No new models.

Having fun as usual,

Patrick

[patrick.chin1]

If you plan to use Windchill beyond managing just ProE files, I suggest following this presentation I sent to PTC. A lot of companies are now moving towards this uniqueness architecture which separates ProE File Management and its part management which is WTPart. PTC Project Managers have called me up and have already implemented this. This way you can import anything if it was from Pro/I or even file based on a drive. It follows all CAD management tools if did not even have Windchill like the good old days on a local hard drive. This way people can filter the file name column if they wanted to. The synchronizing WTPart Number and Name will be 100% easiermatching and autoassociating withEPM Number and Name (respectively in ProE File Name (no extension) and PTC_COMMON_NAME).

PTC always had all the attributes to do this in their datamodel, but they justcouldn't see it. With this method, you can perform most Pro/I migrations without datacleasing duplicate docnames. If it works in Pro/I and you local hard drive, it should also work in Windchill. My motto. You can also migrate muliple Pro/Is into one Windchill. Yes there is only onerecord in ORGCONTAINER Windchill Database, but you can add and remove. You just have to modify the migrator to point to appropriate site record. Each Pro/I system will point to it's own ORGID and ORG context.

[avillanueva]

Pat, my head hurts. I read this and feel like there is so much more to
learn. Would it be possible to illustrate the issues in not having this
customization? What issue would we (or do we) run into? Contrast that
with life with this customization. Without notes on slides, its hard to
decipher them.

[patrick.chin1]

Sorry,

If I got you guys confused with too much information with my presentations. It was to answer 2 streams of this email with exports andthe use of Windchill Number and Name. The namehistory configurationis greatwith the uniqueness configuration.

History on Name for Psion Teklogix was accomplished using OOTB data utility functionality which calls an IBA instead. Just like Tristar said you "can use the query builder", but like most developers, it's best to create your own queries. I don't consider queries as customizations.

I made sure that the Windchill Architecture ismaintained with the UIs and OOTB APIs. As for download, Here are my instructions as part of my requirements:

1. In the type manager or backend, you need add additional attributes first to various objects like:
   • Configurable Describe Link
   • Configurable Reference Link
   • EPM Document Reference Link
   • EPM Document Uses Link
   • Part Usage
2. These are the following attributes to add:
   • Effectivity Lot
   • Effectivty Date
   • Other Effectivity Attributes.
   • Serial Number
   • As Stored for Part Usage
3. This way it is the parent that has the effectivity and the values of effectivity. Sometimes both Documents and Parts have no effectivity on themselves but the assembly or ECN that uses them has effectivity to "use" at an appropriate time, lot, etc. In most cases for Engineering, Manufacturing and supply chain, 2 revisions of the same assembly BOM, documents, etc can be released at the same time but have different effectivities. This is either because the requirement to support past products with long lifecycles or the previous rev can still be sold. If a specific part has to be applied effectivity, then the OOTB effectivity is applied naturally. The effectivity of the ECN is applied to the links.
4. Now with the attributes in place, you can either use the OOTB collector with added configurations based on the attributes or use your own queries down those OOTB links to produce a report and then perform and export.
5. Now the only customization which is developer dependent is how to package the export:
   • My requirement of folders and CAD folders is based on my understanding of how most
     • CAD/ECAD and Arbortext manipulates files on a local drive. Most cases it's on one folder so that you don't have to apply search paths or the default paths like ECAD.
     • As for WTDocument since there is no uniquenss of file name, you have to rename the primary files based on WTDocument number, rev and OBJECTID.
       • And sometimes zip them up in a sub packages because of secondary content and name it WTDocument Number_rev_secondary.zip

I know that PTC is way behind on this. I demonstrated this to the PTC user conference back in 2006 with the PTC Product-line Manager and they were blown away. Like I said, most of this is using OOTB Architecture, UIs and APIs so it would look seamless in terms of both integration and usage. But, PTC always changes their APIs and hardly ever their data model. I explained to PTC that it is very difficult to manually collect everything. Which is why we did this is standard requirement and very little custom reports for packaging the information. It's just how you present the info. Hopefully, you guys who are developers can work with this to "customize" your own way how to deliver the export package. If you guys can do this that's great, I'm just pointing you to someone who helped us achieve our goal back in 2006.

I don't do much code, but I try to make sure the Windchill Architectureiskept to achieve thePLMand ERPenterprise solution vision following best industry business practices.

Like I said, having fun with what we have. I consider Windchill like most PLM tools have the the basics. It's almost there. but you just need to add a little configuration to achieve so much more.

Patrick

[patrick.chin1]

To answer Tony's question regarding the uniqueness refer to this documentation. OOTB ProE can manage files with the same docname on a local drive. But it uses the extension to add uniqueness. This has been like this and still is.

In the old Pro/I 3.4 and earlier, the only unique attribute was NAME which was actually filename. Most cases as a ProE user, you would either number your files appropriately with the part number, number_description, etc. That's the old way of placing every possible attribute in a file to uniquely identify your files which do have number of character limits and it's hard to search every possible metadata value in a file name.

Problems in the past:

• workaround for Pro/I into Windchill to rename you legacy docnames with conflicts if you plan not to include extension
• Just push it into Windchill with docname with extension because "nobody cares at that point in time".
  • This leads to major confusion with other users when you try to just search for number or drawing number once you start implementing WTPart.

So, what to do, we have the old way with Pro/I and local drive and now Windchill. In most cases, CAD files are only 10% of the users in Windchill once you expand to WTDocument, WTPart, Suma, MPMLink and Change Management. They are not interested in file names and the simplification and filters of data is very important which is dependent on the functional user.

I've been working with CAD integration into Windchill since version 5. The solution has always been there and keeps the vision of PLM with no change in UI or APIs.

[patrick.chin1]

This is why I could import and export from any ProI and single local file sytems. See attached. The uniquenss sets me up for the export.