Context Considerations
Windchill manages objects within logical entities called containers. Containers are used to separate objects that belong to different working contexts.
This section describes the availability of export and import for each context level, and how to control the destinations of imported objects with context mapping files.
Export Context Availability
This topic describes the context availability while exporting from products, libraries, projects, organizations, and sites.
Products, Libraries, and Projects
At the product, library, or project level, the export action is available to:
• Users with read access
• Administrators of the product, library, or project
• Administrators of the organization (the parent context)
• Site administrators
The export action is available from the following locations within a product, library, or project:
• The information page of a part, document, reference document, or end item (also known as a product). Any global attribute values and reusable attribute definitions must be exported with the object instances.
|
|
To export an EPMDocument, you must use the Export window, available from the Import/Export Management utility. You cannot export one of these objects from its information page.
|
• The Folder Contents table for a folder that contains supported objects. The export must include the definition of the modeled subclass as if it were a subtype.
To export data from products and libraries, you can also use the Export window, available from the Import/Export Management utility, to export data. Export is available to site, organization, product, and library administrators. To export an object, you must have read access to the object and all its attributes.
To open the Export window, select > . Then, click Export. The Export window opens, displaying your current context at the top of the window. In the Export window, you can search within a context for objects to export. The search results include only objects created within the context.
|
|
To export data from a project, you must use the export action on the Details page for the project. You cannot select project objects from the Export window.
|
Import Context Availability
This section describes the context availability while importing from products, libraries, projects, organizations, and sites.
Products, Libraries, and Projects
At the product, library, or project level, the import action is available to administrators of the product, library, or project and administrators of its parent context (the organization or site). The imported objects are created in the contexts as specified by the mapping rules, provided that the administrator has write access to the mapped contexts. Only business objects can be imported into this level.
When type instances are imported, the type definition is available in the import context.
To import data into a project, do not use the Import/Export Management utility. Instead, use the Import from File action available from the Details page for a project or from a folder. There is a slight difference in how this action works, depending on where you select it. If you select it from the Details page of a project, the import happens using the default behavior for the folder structure of all the objects in the target set. If you select it from a folder, all objects in folders are placed in the target folder.
Type Definition Equivalence
For import purposes, a type definition in an import file is equivalent to a local type definition if all of the following criteria are met:
• It has the same name or the name is mapped to a local name, as well as mapped to the same parent type, unless this type is a root-level type. The names of types cannot be changed.
• It has the same values for the following attributes: instantiable, userAttributeable, and deleted.
• Both types have the same number of attributes.
• Both types have the same set of global attributes. Two global attributes are considered the same if they are of the same reusable attribute definitions and have the same value.
• Both types have the same set of constraints on their attributes and the same set of constraints on the subtype itself.
If a type matching this criteria is found in the system, it must be visible to the context into which the import is being performed.
Organizations
The import action is available to organization and site administrators. Folder contents can be imported into an organization context. Type definitions can be mapped to locally defined type definitions.
|
|
Do not import product-, library-, or project-level objects to the organization or site level.
|
Sites
The import action is available to site administrators. Folder contents can be imported into a site context. Type definitions can be mapped to locally defined type definitions.
Controlling the Destinations of Imported Objects with Context Mapping Files
Normally, all objects are imported into the target context where the import process is launched. If you want to override this behavior, you can use context mapping. Due to security considerations, importing is always to a single project context.
The context mapping file allows the distribution of imports into multiple targets. The context mapping file is intended only for advanced users who cannot find another resolution. The context mapping file hardwires the context paths in your import set, so this approach requires detailed synchronization between the source and target system, which is typically only achievable via pilot to production export scenarios.
A better approach is to analyze what your transport needs really are, and then to streamline the creation of appropriate export sets. PTC does not recommend extensive use of the context mapping file functionality at your site.
The context mapping file has the following syntax:
<?xml version="1.0" encoding="UTF-8" ?>
<container-info>
<container>
<source-container>Original containerReference of the object
at the export site</source-container>
<target-container>containerReference of the context
where the object must be imported to at the import site</target-
container>
</container>
<container>
<source-container>Original containerReference of the object
at the export site</source-container>
<target-container>containerReference of the context where
the object must be imported to at the import site</target-
container>
</container>
<container>
<source-container>Original containerReference of the object
at the export site</source-container>
<target-container>containerReference of the context where
the object must be imported to at the import site</target-
container>
</container>
</container-info>
There can be more than one <container> element in the mapping file, as shown in the following example:
<?xml version="1.0" encoding="UTF-8" ?>
<container-info>
<container>
<source-
container>/wt.inf.container.DefaultOrgContainer=DefaultOrg/w
t.inf.container.ClassicContainer=Windchill PDM</source-
container>
<target-
container>/wt.inf.container.OrgContainer=Windchill_RD/wt.inf
.library.WTLibrary=Windchill PDM</target-container>
</container>
</container-info>
