Relationship definition behavior rules - SmartPlant Foundation - IM Update 46 - Help - Hexagon

SmartPlant Foundation Help

Language
English
Product
SmartPlant Foundation
Search by Category
Help
SmartPlant Foundation / SDx Version
10
SmartPlant Markup Plus Version
10.0 (2019)
Smart Review Version
2020 (15.0)

The following sections define how relationships definitions behave in a concurrent engineering environment.

Relationship ownership

The owner of a relationship may not exist in a higher configuration than the related item. This is because if you look in the higher configuration, you do not see its related objects. For example:

  • When using transmittals and transmittal sections, the transmittal owns the relationship to the section, as the transmittal is comprised of its sections. If the section exists at a configuration lower than the transmittal, finding the transmittal in its higher configuration hides the section.

As an extension of this, it is necessary to force items and relationships into Configuration Top when the owner of the relationship is not configuration controlled, for example, an administration document with an attached file.

  • The administration document is not configuration controlled, therefore the file also exists at the configuration of the document. For example, the document owns the relationship, so the file and relationship are forced to the Configuration Top.

Set the Force Null Configuration property on the Relationship Definition to govern the behavior when instantiated.

Relationship behavior

There are configuration considerations that govern the behavior of relationships.

Relationships can be created if you first compare the basic configurations of the objects:

  • The query configuration of both objects match the active create configuration

  • Or, the items are in the active create configuration

  • Or, the items are higher up the same branch of the tree and have not been claimed to the create configuration

  • Or, the items are configuration independent items, so they are visible from the current create configuration and not in a parallel project

Relationships can be created if you look at the ownership of the relationship:

  • An object is considered a claim owner of a relationship if the relationship definition identifies it through claim12 and claim21 flags. Therefore, the owner of a relationship is manipulated, such that the owner object and its relationships must always be at the same configuration.

  • It is important during drag-and-drop operations to be able to match the two objects to the correct ends of the relationship definition in order to read the correct owner flag. This also has to be done for the condition evaluation.

Relationships can be created if an object owns a relationship to create the relationship:

  • The owning object must be claimed or created at this configuration

  • The other object must be:

    • Either in the current create configuration

    • Or at a higher configuration in the same branch of the tree

    • Which makes it visible from the current create configuration, but not in a parallel configuration or lower

If any of these conditions are not met during the relationship creation, an error message appears.

Relationships can only be modified or terminated if they have been previously claimed. Modification or termination of a relationship in a higher configuration requires the claim of the owner of the relationship.

A configuration-independent item cannot be the claim owner of a relationship.

A relationship can be modified or deleted if:

  • The two objects and the relationship are configuration independent or:

    • The query configuration for the relationship is the same as the current create configuration

    • And the current configuration of the relationship is the same as the current create configuration

Relationship behavior on merge

When a merge occurs, if a relationship to the merging object is not being merged, it is terminated. A cardinality check is also done to make sure that removing the merging object from the configuration does not break cardinality. If it is going to break cardinality, the related item is also terminated.

For example, merging an object on a workflow results in the workflow being terminated, as the workflow must be related to a workflow item.

Relationship behavior on merge by grouping object

When a merge by grouping object occurs, an additional validation check is done. If any unresolved conflicts or errors are found, the merge is stopped, and the items in conflict are displayed in the Merge Structure Exception report. Any conflicts and errors are listed in the report for resolution. The administrator can choose to merge data from other structures when objects or relationships from the starting group object are required to be merged successfully. For more information on the exception report, see Reviewing merge by grouping object errors.