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

We are happy to announce the new Windchill Customization board! Learn more.

When to use Secondary Content (Attachments)?

ahamblett
5-Regular Member

When to use Secondary Content (Attachments)?

For Document management in Windchill, I am seeking input on when to use Primary vs. Secondary Content as well as Object naming, in general. First, with regards to Object Naming, some are recommending we name a Document record 123TBD.docx while others recommend simply 123TBD (w/ no file extension). Note the Primary Content in this example would be the 123TBD.doc. Also, if there is a 123TBD.xls which supports this document some are recommending we include this as Secondary content while others recommend creating a 123TBD WT Part along with a 123TDB.xls document record and associate both the .doc and .xls objects to the WT Part. Any thoughts on this subject are greatly appreciated. Thank you in advance!

1 ACCEPTED SOLUTION

Accepted Solutions

I don't have much to offer except that I agree with Stephen on the naming convention. The filetype/extension is an attribute of the ApplicationData, whether it's secondary or primary. Somebody may edit a Word 97 .doc in Word 2010 and re-upload a .docx. Then your primary business object's name is just wrong.

Managing this may be a nightmare, but if the attachment type is something that you MUST know when viewing a table of WTDocuments/etc, then you may consider adding an IBA like "Primary File Type," which, could be limited to a DiscreteSet of "None|Word|Excel|PDF|Unknown" etc. If it were even necessary, I would keep those DiscreteSet values broad, yet descriptive enough to tell you what to expect.

You could also extend the OOTB processors and use your own edit/checkin processor to do this for you. In that case, you could use a Hidden on Create/Update on your IBA, and just let your processor do the work.

Some things to consider.

1. Do you need to know this information at all?

2. What if the pbo.name/extension does not match the pbo.attachment.name/extension

3. What if the pbo.iba.type/extension does not match the pbo.attachment.type/extension

4. Is keeping this information accurate worth the extra development work and load on the server?

View solution in original post

10 REPLIES 10

Hi Adam,

Assuming it is a WTDocument or a EPMDocument you are naming then I would not consider the file extension to be part of the name. This is because the primary and secondary content will all be mixed file extensions so having the extension on the name is a misnomer as the actual object's mime type is defined on a linked object that is called the ApplicationData.

The other problem you pose relates to whether an Excel spreadsheet should be managed as a separate object or as secondary content. The decision here is whether the user will ever need to version and manage (i.e. Workflow) the excel spreadsheet as a separate entity, will this spreadsheet be a shared resource amongst many documents...

So, if it is a 1:1 relationship between the document>excel and the user does not want to version, workflow, secure, workspace the excel spreadsheet separately to the document THEN having it as attached (secondary content) would be a good idea.

Hope this helps,

-Ste

p.s. secondary content is best used to store data that represents or is derived from the object. Typically things like thumbnails (i.e. a jpg derived from the iso) would be stored here. So is the data in the excel derived from the document?

p.p.s I would not use a WTPart to store office based files. I would consider either WTDocument or EPMDocument. WTDocument is a simpler object to customise. EPMDocument is more heavy weight but has the advantage of better client (uwgm) support and Workspace managemnt for branched authoring of a document and its dependents.

ahamblett
5-Regular Member
(To:slawson)

Thank you, Stephen, for your response. It is greatly appreciated. We have multiple instances where a WTDocument has numerous, separate, files which may be combined into a single entity such as a PDF during the formal review and release process. The idea is to provide the ability for multiple staff members, who may or may not be co-located, to modify each record independently. For example, an analysis Report which has a .doc, a .xls and a .visio file. Or a sub-contract document w/ numerous chapters (in this scenario, the Primary content of each WTDoc record may be a .doc so each record's Number may have to be something like: TBD_Chapter1-5.doc).

Although, after reading your comment... "EPMDocument is more heavy weight but has the advantage of better client (uwgm) support and Workspace managemnt for branched authoring of a document and its dependents." I now intend to perform some research on this topic to determine if it may meet some of our needs. Based upon my comment above, in your opinion would an EPMDocument be the preferred solution for say a multi-chapter Sub Contract document?

Thanks again for your time.

Regards,

-Adam

If they need to be edited individually, may want to utilize Document Structure.

ahamblett
5-Regular Member
(To:MikeLockwood)

Document structure? Correct me if I'm wrong but wouldn't each file require its own WTDoc record (w/ Primary content) and be Related to a common WTPart? Please explain. Thanks. -a

Each file results in a separate WTDocument - but only the top level of the Document structure would need to be associated to a WTPart.

ahamblett
5-Regular Member
(To:MikeLockwood)

Thank you, Mike for the response. But can you please elaborate on what you mean by "...only the top level of the document structure..."??? What would you consider the "top level" of the document structure? The all encompassing/combined PDF file? If so, why not associate ALL files to the WTPart so the "Collect Related Objects" selection would function when generating a Change Notice, for example? Or am I misunderstanding the context? Thanks again! -a

Lots of tools - can use many different ways.

A sample structure

- WTPart - Module Assembly

- All related CAD Doc's...

- WTDocument1 - Procedure for Module Assembly

This WTDocument has a Word file as primary content

This WTDocument also has a Visio file as secondary conent

- WTDocument2 - supplemental info for module assembly, can be changed by itself

This WTDoc has an Excel file as primary content

- WTDocument3 - more like WTDoc2

This WTDoc has a PDF file as primary content and photos as secondary

- WTPart - Bracket

Just play with it. Create a few Documents. Put them in a structure. Take the doc at the top of the structure and associate to a WTPart. Check out / in the lower level Doc's.

ahamblett
5-Regular Member
(To:MikeLockwood)

Ah, OK. That's what we're doing now so that makes sense. However, we're naming the WTDoc Records using the applicable file extension. So, for your example, WTDoc1 would be WTDoc1.doc (w/ a .doc as Primary Content), WTDoc2 would be WTDoc2.xls (w/ a .xls as Primary Content) and WTDoc3 is WTDoc3.pdf (w/ a .pdf as Primary Content). All of which are associated to the applicable WTpart (WTDoc w/ no extension).

It is this WTDoc Record naming convention we aren't sure is the best solution or a common practice amongst Winchill users/admins. Any thoughts?

I don't have much to offer except that I agree with Stephen on the naming convention. The filetype/extension is an attribute of the ApplicationData, whether it's secondary or primary. Somebody may edit a Word 97 .doc in Word 2010 and re-upload a .docx. Then your primary business object's name is just wrong.

Managing this may be a nightmare, but if the attachment type is something that you MUST know when viewing a table of WTDocuments/etc, then you may consider adding an IBA like "Primary File Type," which, could be limited to a DiscreteSet of "None|Word|Excel|PDF|Unknown" etc. If it were even necessary, I would keep those DiscreteSet values broad, yet descriptive enough to tell you what to expect.

You could also extend the OOTB processors and use your own edit/checkin processor to do this for you. In that case, you could use a Hidden on Create/Update on your IBA, and just let your processor do the work.

Some things to consider.

1. Do you need to know this information at all?

2. What if the pbo.name/extension does not match the pbo.attachment.name/extension

3. What if the pbo.iba.type/extension does not match the pbo.attachment.type/extension

4. Is keeping this information accurate worth the extra development work and load on the server?

ahamblett
5-Regular Member
(To:slawson)

To follow up, we've evaluated document/object naming and with your help, have concluded that with the exception of CAD files, excluding file extensions [from object names] is best way fwd (for us). Thank you again for your time.

Top Tags