Windchill Product Container Best Practices

3 replies
3270 views
Translate All

I am hoping to get a pulse on how other companies view product container management.

We have received contradictory statements form PTC consultants stating that some companies have 10's of thousands of containers and find this hard to believe they are able to replicate or manage access permissions on that magnitude.

We have also been told that containers should contain less than 20K objects to avoid possible issues and have now been informed by the consultants that there are companies with containers containing 10's of thousands, if not millions of objects per container without issue.

So... Were is the balance?

1. How many container (don't need a "hard" number) does your company have?

2. How many objects per container do you have on average (good guess)?

3. Do you replicate?

4. Have you encountered any issues with your strategy (lessons learned)?

Any information would help tremendously in our decision making processes moving forward.

Thanks in Advance,

Lee

Other

M

MikeLockwood

22-Sapphire I

- As soon as the number of objects is over a few hundred, browsing becomes unrealistic (use search 100% of the time instead). Because of the assumption that people need to browse within a folder tree, there are lots of unrealistic guidelines on numbers of objects per; these can be ignored in favor of using search.

- Vaulted content files are not related to Product / Library / Project containers unless you implement vaulting rules specific to these containers - which are generally not needed. The number of files is per operating system folder, not Product / Library / Project containers. Management of this can be done at the Site level unrelated to Product / Library / Project containers.

- For reference, we have:

o ~ 2.6 TB of vaulted files

o ~ 2.4 million CAD documents

o 25 Products / 22 Libraries / 35 active Projects

- Note: OTB, each Product / Library / Project has a very large number of ACL's, created via the OTB templates. Any changes that needs to be done across a large number of containers is very, very painful. For this reason, it's been very good strategy for us to put as many common ACL's at Org level as possible and remove them from the Product / Library / Project level (and remove them from the templates).

Translate

D

ddemay

1-Visitor

Hi Lee,

Some of what you are hearing from consultants has more to do with how the
code and queries are written as well as how the database is structured. No
matter what design, you will always face limitations on performance.
Performance is in the eye of the beholder and usability studies over the
past decade on how humans interact with content presented in a web browser
is key here. You might be able to efficiently query for thousands of
objects; it is the perception that it is slower that no amount of ingenuity
can beat.

Consultants who had to deal with the 7.0 and 8.0 folders and contents table
views will raise concern about limiting number of objects in folders and
contexts as a whole. 9.x will of course shift that perspective and concern
and X20 will shift it further.

It is a question of politics, if you customer doesn't tolerate the listing
of thousands of objects well, training to search by number helps. However,
you customer may ultimately go Hey, let's use Agile or TeamCenter instead
thinking there is some tangible benefit in these systems when that is not
true. It has to do with hardware, implementation, and tuning. These can be
tweaked. Only training can really deal with human element. The struggles
you hear from the aches and pains of consultants has to do with any hearsay.

That said, there have been discussions on here about the proper use of
contexts (containers are the technical name). I have been provided PTC
documentation in the past that suggest the balance comes between management
and process, access controls, and data. While those are valid
considerations, I also recommend looking at how you can leverage things even
further using 90% out of the box configuration to add a 4th dimension of
sorts. Organization of data also based on how the database retrieves it.
This takes a DBA and someone who knows Windchill fairly well like a solution
architect.

In our large production systems, we will have to deal with legacy cultural
and interoperable issues and nomenclature. Our system is also phased.
Proper use of folder names for example, might gain you a sort of performance
leverage. i.e. you need to classify data by some attribute. Instead of
placing the attribute on each object, having a folder's name represent that
attribute and value can organize data more efficiently and still provide the
backwards search capability. I'm definitely not a fan of using nested
subfolders. That taxes the system.

In order to leverage this solution, we have a product and library 100-150 of
each type just for this purpose. No CAD data is stored here, only WTParts
and related BOM data, variants, alternate parts, etc. The data here is
managed by separate users and associated back to the CAD data end assembly
items or individual parts as needed.

Under separate organizations, we will have other context (containers) for
actual CAD work. Our solution will not use ProjectLink.

Contexts and containers for CAD design should follow product design, not
project teams and not project or org charts. This creates over complicated
solutions.

Permissions managed at the organization context/container level (and under
the PDM sub domain if Project link is installed) is key.

Replication has changed in 9.1 quite a lot. There is a technical brief
available on the PTC site explaining the changes. Replication should not
drive how you create your products, libraries, and projects on new systems.
This is old school.

It is wise to never store anything in the default folder of a context (which
is actually the public cabinet of the context.) It is best to store all data
in appropriate subfolders no more than 1 or at most two folders deep.

Lastly, Windchill 10, improves greatly on how users operate on new and
existing data in a folder/context that contains a lot of data. You will no
longer have to wait for all data to load to start working.

Good luck.

David DeMay

Translate

H

HugoHermans

12-Amethyst

Hi David,

This is very little to be added to the statement of Lee and Mike.
Container definition should be driven by the business. Users who rely
on Windchill for their day-by-day job should recognize products and
libraries as a natural and intuitive reflection on how the business
functions. When one feels that there is doubt about which container is
the right one for this document, problem report, etc. then the container
definition is not OK.

We are an organisation with 100+ Windchill users, content is mostly
CAD-driven (historically), with ~800GB in our vaults. We have 14
products (CAD-driven), 32 libraries (mix of CAD-driven and non-CAD), 584
running projects (managed by one person!). We have remote sites with
replication, but fairly limited number of users until now. The number
of products and libraries is fairly stable, and will only grow when the
applications will grow.

Met vriendelijke groeten,
Kindest regards,

Hugo Hermans

-

NV Michel Van de Wiele
Michel Vandewielestraat 7
B-8510 Kortrijk (Marke) - Belgium
Tel : +32 56 243 211
Fax: +32 56 243 540
BTW BE 0405 450 595
RPR Kortrijk

Translate

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.