Working with Objects Imported Using a Received Delivery
Received deliveries provide collaboration opportunities with people that work outside of the Windchill installation. There are many variations to these collaboration scenarios, but there are two main categories of collaboration: between two installations within a given company and between two separate companies. These two collaboration scenarios result in the following:
• The objects shared between systems represent the same information
• The sending system is considered the authority on the shared objects
• The recipient system can view and reference the shared objects while maintaining administrative capabilities on their own system
The receiving system follows essentially the same steps regardless of the collaboration scenario, but there are slight differences introduced from the sending system. The differences center around the degree to which the imported objects match their counterparts on the source system.
Objects imported using a received delivery represent the same object in the receiving system as they do in the sending system. As a result, the objects maintain the same business information such as name, number, and life cycle state. When replicating between internal systems, there are generally not the same security or business relationship restrictions about sharing more detailed information as there are when collaborating with external partners. Objects replicated between two internal systems often include
user information (such as the user who created an object), effectivity, or life cycle and workflow history.
The collaboration objective influences the differences between the data imported into a receiving system.
• Collaboration with external partners is commonly centered on a significant event, such as a contract milestone with a scheduled delivery date or the release of a new configuration. As a result, the receiving system only needs to contain periodic snapshots of information relative to that milestone. For example, the received delivery could only contain versions used in a specific released configuration.
• Collaboration for internal replication is commonly focused on creating precise data replication on a second system. Internal replication is typically handled on a schedule and recognizes that the two systems may not be identical. For example, there may be different context or folder structures. Different business processes between the two systems may also be in place. For example, a workflow running on the sending system should not be started on the receiving system.
The differences between the collaboration objectives when creating the package delivery on the sending system also means that internal replication may need additional details. Changes to existing objects as well as information about objects that have been deleted from the source system are communicated using incremental deliveries.
Regardless of the collaboration scenario, objects imported using a received delivery automatically have a lock applied, which restricts the actions users can perform on the objects by allowing users to view and use objects, but not to modify their attributes or content. For more information, see
About Lock on Imported Objects.
Certain objects, such as a change notice, have additional restrictions to prevent users from modifying them as they would modify objects that are owned by your Windchill system. For example, in the target system, when a change notice or changeable object is replicating then:
• The creation of an unincorporated change on any replicating changeable object is not allowed.
• The incorporation of an unincorporated change using the replicating change notice is not allowed if a replicating changeable object has an unresolved unincorporated change.