ACCEPTED SOLUTION
Accepted Solutions
Madhu,
A container is a context within Windchill that represents a storage location for a set of related information. For example, site, organizations, products, libraries, programs, and projects are all containers, and there is a specific container hierarchy within Windchill and the lower containers inherit from the higher containers. See image below.
A container is where you store/use your Windchill business objects (e.g., Documents, Parts, CAD Documents, Change objects, baselines, etc.) Within the container you may have one or more folders to store the objects.
Every container has cabinet objects that store data and system objects for that context, and every cabinet within the context has an associated domain. As a result, each container can have multiple domains associated with it, such as a default domain (for data objects, such as CAD Docs, Documents, Parts, Change objects) and a system domain (for system objects, such as queue objects, workflow objects, lifecycle objects, etc.). A domain stores policies that are applied to the associated cabinet and the objects within the cabinet. The policies include access permissions, notification policies, and indexing rules.
There is also a domain hierarchy and the lower domains inherit from the higher domains. See the following example:
This is a very simplified explanation of how these object types work, but hopefully, it gives you some idea of the differences between the two.
Madhu,
A container is a context within Windchill that represents a storage location for a set of related information. For example, site, organizations, products, libraries, programs, and projects are all containers, and there is a specific container hierarchy within Windchill and the lower containers inherit from the higher containers. See image below.
A container is where you store/use your Windchill business objects (e.g., Documents, Parts, CAD Documents, Change objects, baselines, etc.) Within the container you may have one or more folders to store the objects.
Every container has cabinet objects that store data and system objects for that context, and every cabinet within the context has an associated domain. As a result, each container can have multiple domains associated with it, such as a default domain (for data objects, such as CAD Docs, Documents, Parts, Change objects) and a system domain (for system objects, such as queue objects, workflow objects, lifecycle objects, etc.). A domain stores policies that are applied to the associated cabinet and the objects within the cabinet. The policies include access permissions, notification policies, and indexing rules.
There is also a domain hierarchy and the lower domains inherit from the higher domains. See the following example:
This is a very simplified explanation of how these object types work, but hopefully, it gives you some idea of the differences between the two.
