Handling Local Data During Context Replication
This topic explains how systems manage the replication of business objects and their relationships from a source system to a target system, especially when some of those objects already exist locally in the target system. The goal is to avoid conflicts and ensure data consistency.
Local Object Behavior
In certain replication scenarios, local objects in the target system may act as placeholders for objects that exist in the source system. These placeholders continue to change and evolve independently within the target system and are referred to as agents.
Placeholder Configuration
To enable the placeholder feature, set the property wt.ixb.import.businessIdentityBasedSearchForLinks.placeholderObjectsOnly=true in the wt.properties file on both the source and target environments.
* 
In the source system, these objects are referred to as Placeholders, whereas in the target system, they are known as Agents, representing their actual implementation.
Replication Conflict Handling
Previous behavior — If context replication detected that some of the business objects being replicated already existed locally in a closed environment (target) and were not marked for replication, it raised a conflict. This conflict was resolved by skipping the import of those objects.
Current behavior — If context replication detects any relationships being replicated that reference such local objects, the system ignores those relationships during import to prevent conflicts.
Package Export and Import
The source system exports a package containing all supported objects and their business identities during replication. This package is then imported by the target system or a local system.
Relationship Handling Logic
During this import operation:
The system first attempts to locate the weak-side object on the target system using its UFID.
If UFID doesn’t match, the system checks whether the business identity of the weak-side object in the source system matches a local object on the target system.
If a match is found, the link is replicated.
Local Object Replication Rules
When a business object is discovered on the target system based on its business identity, the replication process follows these rules:
Conditional Link Replication: A link (relationship) is replicated only if the strong-side object is being replicated, and the weak-side object already exists locally on the target system and is marked as a placeholder. This replication occurs only if the business identity of the local weak-side object matches the identity provided by the source or included in the received delivery package.
Link Replication Based on Lock Status: The system determines whether a business object is eligible for link replication based on the object’s lock status. If the object is marked with Lock for Replication or Locked by Product Design Package, the object is excluded from the link replication process. However, if the object is marked with In-transit lock or identified as a Local Object, the object is allowed to participate in link replication.
Replication of Strong-side Only: If the object is identified as the weak side of a relationship, the system replicates only the strong-side object and establishes a link to the latest iteration of the weak-side object. The weak-side object itself remains local, is not replicated, and is marked as a placeholder.
No Link Replication for Fully Local Objects: If both the strong-side and weak-side objects are already present and local on the target system, the link between them is not replicated.
Replication Restrictions Due to Lock or Pending Replication: The link is not imported if the strong-side object is either:
Not replicated due to an administrative lock, or
Tagged for replication but has not yet been replicated
Partial or Missing Business Identity: If the business identity is partially available or missing at the source during export, the link is still replicated on the target system.
Access Control Considerations: If the weak-side object exists locally on the target but cannot be discovered due to access restrictions or permissions, the system ignores the replication of such links.
Context Considerations: Local objects may reside in any context (for example, product or library) on the target system.
Including Placeholders in Replication Package: In the source system, when users select a few objects (weak-side objects in the relationship) as placeholders, the system includes the business identity of only those selected objects in the export replication package. These identities are transferred through their associated links.
Example
Consider the following example in which the strong-side object PartP1 A.2 is replicated in the target system because the business identity of the weak-side object Child C1 A.1 in source is the same as Child C1 A.1 in target and both are marked as a placeholder.
Source System
Target System (Before Replication)
Target System (After Replication)
PartP1 A.2
ChildC1 A.1 (local)
PartP1 A.2 (replicated)
ChildC1 A.1
ChildC1 A.1(remains local)
If the business identity of the target and weak-side objects do not match, PartP1 A.2 is replicated in the target system, but the link is not replicated. For more information on business identity, see Business Identity for Objects.
Special Case
In some cases, the weak-side object may exist in a different context than the strong-side object on the target. When the strong-side object is replicated, the system also replicates the associated link, provided the business identity of the weak-side object in the target system matches the identity information from the source and the weak-side object is marked as a placeholder in both the source and target systems.
While this topic focuses on general business object replication, similar identity-matching principles apply to Change Management objects as well. For more details, see Business Identity for Change Management.
To understand how local data is handled during the replication of CAD documents, see CAD Document Limitations.
Isto foi útil?