About Working in a Product Context

You can share data in a product context without opening a 3D shape representation in a stand-alone editor. However, to do so you first have to activate the representation containing the features to be sent or in which the features are merged.

You can select features you want to share either from the geometry area or from the tree. Note: Only the features of representations can be shared.

The following paragraphs provide information on the various features that adhere to the Collaborative Design protocol and can be shared:

This page discusses:

Generative Shape Design Features
Part Design Features
Knowledgeware Features
Features Linked to External References
Define In Work Object
Content Overwrite for Functional and Geometrical Sets

Generative Shape Design Features

Features are shared by a briefcase mechanism.

In addition to your explicit selection, the briefcase also contains other features that are required to reconstruct the model in a different document. These additional features are typically the parents of the selected features, and information concerning the body or set to which the features belong. Sending this information ensures that features are properly positioned in the destination part when the merge is done.

You can share Generative Design Features. Collaborative Design is performed at feature level. This means that each feature can be shared without its aggregating set.

Two designers can divide the initial geometric set in two parts (blue and yellow curves).

Each designer can create their own features (blue and yellow surfaces).

And finally, the created specifications can be merged into the initial set (green surface).

Collaboration and Geometrical Sets

When merging features in a different type of set, the behavior is identical to that when creating features. The result is similar to a manual creation of the features.

When merging a feature that does not already exist in the part, the following rules are applied:

If the destination part does not already contain the geometric set to which the feature belongs, the set is created before inserting the feature.
If the geometric set already exists, the feature is added to it.

Collaboration and Ordered Geometrical Sets

In an ordered geometric set, if user A has defined the feature and shares it as in In Work Object, then this information is also sent by the briefcase. This means that, after the merge, user B may see a different In WorkObject than expected.

Part Design Features

You can share Part Design features.

Collaborative Design is performed at hybrid body level because Part Design features are history-dependent.

Only sketches can be shared and merged explicitly without aggregating the hybrid body if it does not depend on other Part Design features.

Boolean operations

The body(ies) involved in the Boolean operation can be shared explicitly by the user.

Example:

Sketch.1 can be shared explicitly because it is based on a reference plane.
Sketch.2 cAot be shared explicitly because it is built on Pad.1. To share Pad.1, Assemble.1, Sketch.2, or EdgeFillet.1, the user must select PartBody.

Notes:

When a hybrid body is shared, it is merged with the PartBody of the destination part only if the part bodies are the same features. If the part bodies are not the same features, a new body (Body.1) containing the shared features is created in the destination part. This new body is renamed PartBody and the original PartBody renamed Body.1.
The dependencies (aggregated features) of a shared hybrid body are only shared if they adhere to the Collaborative Design protocol.
If a sketch can be explicitly shared by the user (that is, if it is not built on another Part Design feature), the only dependency embedded in the message is the support plane (reference plane or Generative Shape Design plane).
An entire representation cAot be shared.

Functional Plastic Parts Features

You can share functional design features (created in the Functional Plastic Parts app). Collaborative Design is performed at functional specification level. This means that you can share functional specifications without any functional body or functional solid. If a sketch built on the result of a functional specification is shared, the functional specification and recursively any dependencies is embedded into the briefcase.

Functional body

If a feature is shared, the dependencies are the aggregated features (and recursively their dependencies) and the functional solid.

Functional specification

The parent is embedded in the briefcase (without the other features aggregated below the parent).

Part body aggregating a functional solid

The functional solid and the functional body are embedded in the briefcase.

Pattern Features

Only simple patterns can be shared.

Simple Patterns

You can proceed to a standard sending data to have your simple pattern shared.

Knowledgeware Features

You can share Knowledgeware features.

Parameters and Formulas

You can share parameters and formulas.

If you share formulas, the geometry on which these formulas are based is also embedded in the briefcase. Note that if geometry exists in the destination part, it is not overwritten.

Other Knowledgeware features such as reactions, macros with arguments, and optimizations cAot be shared.

Notes:

You can only select datum features in the tree.
A datum feature cAot recreate the geometry. Therefore, also select the associated geometry when sharing a datum feature.
You cAot share geometry only that is, without its associated proxy feature. When a datum is merged, its specification is updated and the geometry is replaced.
Collaboration share action never converts (on the fly) specifications into datum while streaming collaborative messages.
Copy with link and Copy as result with link are not supported.

Embedded Design Tables

When creating certain types of features, embedded design tables are used as a support for their creations. These embedded design tables can be shared.

That kind of data is implicitly used when a threaded hole is created for example.

Warning: The share is blocked for nonembedded design tables.

Warning: If sharing a parameter controlled by a design table, there could be a parameter update conflict in the destination representation if you update the parameter only and share it again. The merge of the sent design table is successful in the destination representation but, if you change the parameter value and send it alone, the parameter value of your collaborator's representation remains the same as the one in the design table. Therefore, instead of sharing the parameter only, you have to share again the whole design table so that you are sure all the values are right.

Features Linked to External References

If you share features containing links to external references, such as contextual links, copy with links and copy as result with link, the result of the link is inserted in the briefcase but the external reference is ignored.

On the merge side, a datum is created. This method for sharing external references is referred to as deprecated share.

To protect the information about external references in a bidirectional exchange of briefcases, the following rules apply during the merge:

A feature resulting from a deprecated share cAot overwrite its source.
A feature "shared deprecated" (the source) always overwrites the version of the datum existing in the destination part.

To better understand these rules, consider the following example:

A - User A wants to share feature F1 with user B who does not have the feature F1. F1 is linked to an external reference.

The external reference is ignored during A's share operation.
When B merges the briefcase on their side, a datum is created with the resulting geometry.

B now wants to share with both with user A. F2 is pointing to the datum F1 generated during step 1.

Datum feature F1 is embedded in the briefcase as a dependency of F2.
On the merge side, F2 is retrieved in the User A model but doesn't merged because a feature resulting from a deprecated share cAot overwrite its source. This way A does not loose the original external reference.

C- Finally A updates the external reference pointed by F1 and shares F1 again.

The external reference is ignored again.
When B merges, the datum F1 is overwritten by the newer version coming from A because a feature "shared deprecated" (the source) always overwrites the version of the datum existing in the destination part.

Define In Work Object

If you share features and one of the features is defined as the In Work object, the Define In Work Object information is kept when features are merged in the destination part.

If no shared feature is defined as the In Work object, you may not see the result that you expect because another feature in the destination part was defined as the current object.

Content Overwrite for Functional and Geometrical Sets

Normally when a briefcase containing a geometrical set or a functional set is merged with a part that already contains a copy of the set, the list of features of the two versions are combined.

For instance, if the briefcase contains a Geometrical Set named My Sketches that contain three sketches Sketch.1, Sketch.2 and Sketch.3 and the destination part contains the same set with two sketches Sketch.2 and Sketch.4. After the merge, the destination part contains Sketch.1, Sketch.2, Sketch.3, and Sketch.4. More precisely, Sketch.1 is added to the destination part, Sketch.2 and Sketch.3 are replaced with the version from the briefcase, and Sketch.4 is left untouched.