Skip to main content
A
ahamblett1-Visitor
1-Visitor
March 8, 2013
Solved

When to use Secondary Content (Attachments)?

  • March 8, 2013
  • 1 reply
  • 6091 views

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!

Best answer by MatthewKnight

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?

1 reply

S
slawson1-Visitor
1-Visitor
March 14, 2013

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.

A
ahamblett1-VisitorAuthor
1-Visitor
March 26, 2013

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

M
MikeLockwood22-Sapphire I
22-Sapphire I
March 26, 2013

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

Terms & ConditionsAccessibility statement