Data Behaviors

This section describes the different data behaviors you can use with the different scenarios.

This page discusses:

Data Behavior Parameters

The following table describes the Data Behavior parameters:

Parameter Name (in XML script) Parameter Name (in Batch UI) Defines ... Values Optional
StreamsTransfer / Type Streams Management Data streams that will be transferred
  • Visualization Only: transfer navigation data only (applicable for all document types)

    <StreamsTransfer>

    <Type>VisualizationOnly</Type>

    </StreamsTransfer>

  • Upgrade: transfer and migration of V5 of CATDrawing or CATPart

    <StreamsTransfer>

    <Type>Upgrade</Type>

    </StreamsTransfer>

  • Structure Only: no transfer of applicative data (CATProduct)

    <StreamsTransfer>

    <Type>Upgrade</Type>

    <AssemblyRep>StructureOnly</AssemblyRep>

    </StreamsTransfer>

  • Full: transfer of applicative data (CATProduct)

    <StreamsTransfer>

    <Type>Upgrade</Type>

    <AssemblyRep>Full</AssemblyRep>

    </StreamsTransfer>

MaturityProcess Maturity informationMaturity information will be transferred
  • Off
  • On
  • x
PeopleAndOrganizationProcess People and Organization information People and Organization information will be transferred
  • Off
  • On
  • x

Stream Management

The following describes stream management in Coexistence and Migration scenarios.

Stream Management for Import Scenarios

In order to choose the most appropriate import mode for your documents, you can define the stream management with four parameters divided into two categories:

  • Assembly defines the CATProducts migration:
    • Structure Only import: only the structure of the product is imported. Applicative data is lost.
    • Full import: the product assembly and the applicative data are imported.
  • V5 Geometry defines the V5 data migration:
    • Authoring import: migrates V5 data to 3DEXPERIENCE

The Import mode differs depending on the type of the document you want to import.

Document TypesAbout the Import Mode
CATPart, CATDrawing, model, CGRThe import mode depends on the migration of applicative data.

Choosing Structure Only or Full mode does not have any effects.

CATProductThe import mode depends on the migration of V5 data.

Choosing Authoring import does not have any effects.

Non-CATIA documentsThe selected import modes for V5 geometry and assembly data do not have any effects.
CATProcess, CATAnalysisThe selected import modes for V5 geometry and assembly data do not have any effects. Full authoring migration will be performed.

Stream Management for Export Scenarios

In export scenarios, you can choose between two conversion modes for representations, depending on the features and geometry you want to export:

  • As Result: Exports the geometry.
  • As Specifications: Exports the geometry and the specifications.

For more information, see About Conversion Modes.

Versioning When Transferring Metadata

The following section describes how versioning is handled when transferring metadata.

Warning: The version label will be determined by the target provider.

Version information is always transferred in Coexistence and Migration scenarios. However, depending on the source and the target PDM customization, the version label can be different. For example, when transferring data from a PDM where the version label pattern is 1, 2, 3, 4 to a PDM where the version label pattern is ---, --A, --B, the version label will be automatically computed from the target patterns.

Example 1

Source PDM version pattern equal to target version pattern equal to ---, --A, --B, --C, --D,....

TransferSource VersionExpected 3DEXPERIENCE Version

(order respected)

1st transfer --- (1st order)--- (1st order)
2nd transfer --A (2nd order)--A (2nd order)

Example 2

Source PDM version pattern equal to a, b, c, d, e, f, ...

Target version pattern equal to ---, --A, --B, --C, --D,....

TransferSource VersionExpected 3DEXPERIENCE Version

(order respected)

1st transfer a (1st order)--- (1st order)
2nd transfer d (4th order)--C (4th order)

Example 3

Source PDM version pattern equal to 1, 2, 3, 4, ...

Target version pattern equal to ---, --A, --B, --C, --D,....

TransferSource VersionExpected 3DEXPERIENCE Version

(order respected)

1st transfer1 (1st order) --- (1st order)
2nd transfer4 (4th order)--C (4th order)
Note: The data transferred using a coexistence scenario still belongs to the source PDM and can evolve and be versioned by the source PDM. That is why a lock prevents versioning such data in CATIA 3DEXPERIENCE. To do so, you must transfer Mastership from the source PDM to the target PDM by means of the CoexistenceAdministration batch.

The data transferred using a migration scenario belongs to the target PDM and can be versioned directly in CATIA 3DEXPERIENCE.

Versioning When Converting Representations

Instances resulting from different CATProduct versions keep the same logical ID. 3DEXPERIENCE data pointing to such instances can use versioning-related rerouting capabilities.

When data with versioning information is imported into 3DEXPERIENCE, FBDI/DBDI migrates it and creates new instances that each have a logical ID. This ID will enable you to reroute the links on the versioned structures.



Note: Only the first level of instances is supported.
  • Instances of internal components are not supported.
  • Publications are not supported either. In other words, links to the CATPart geometry cannot be rerouted because Publications have no logical ID between the two versions.

Customized Attributes and Type Mapping

The following table describes customized attributes and type mapping.

Note: If CustomizedAttributesProtection is activated, then CustomizeAttributeMapping has no effect.

Customized attributes are transferred using the dedicated Business Logics PLMAttributesMapping and PLMCustoTypeMapping. For more information, see Installation and Setup: Customize: Behavior: Data Setup: List of Resource Set IDs: Infrastructure Business Logic: Coexistence: Attribute Mapping Business Logic and Custo Type Mapping Business Logic (PLMCustoTypeMapping).

ScenarioTargeted scenario NameDescription
Scenario 1ISO

Prerequisites:

  • Source and target PDMs have the same customization (types and attributes).
  • No implementation of PLMOpening IDs, PLMCustoTypeMapping or PLMAttributesMapping.

Coexistence infrastructure behavior:

  • Objects and their attributes will be transferred as is.
  • No attempt is made to map either types or attributes.

Remarks:

  • This scenario will result in a warning message (No rules available for...).
  • If source and target PDMs do not have the same customization, errors result.

Scenario #2Map on my own target type

Prerequisites:

  • Implementation of the PLMOpening ID: PLMCustoTypeMapping.

Coexistence infrastructure behavior:

  • The Coexistence infrastructure will use a dedicated PLMOpening ID to change, "on the fly", the type of object to be saved.
  • If a PLMOpening ID exists but has no output custom type for a dedicated type, the source custom type will be used.
  • Mapping mistakes result in errors in the Coexistence process.
  • Regarding attribute mapping, only core attributes and common customized attributes (same name, same type) will be transferred.

Remark:

  • This scenario will result in a warning message (No rules available for...) because the PLMOpening ID PLMAttributesMapping is not implemented.

Scenario #3Map Type and Attributes

Prerequisites:

  • Implementation of PLMOpening ID: PLMCustoTypeMapping

of PLMOpening ID PLMAttributesMapping

Coexistence infrastructure behavior:

  • The Coexistence infrastructure will use dedicated PLMOpening IDs to change "on the fly" the type of object to be saved.
  • If a rule exists but has no output custom type for a dedicated type, the source custom type will be used.
  • Mistakes in type mapping result in errors in the Coexistence process.
  • The Coexistence infrastructure uses dedicated PLMOpening IDs to map attributes from the source object to the target object.
  • If not mapped in the PLMOpening ID, core and common customized attributes (same name, same type) will be transferred as is.
  • Mistakes in attribute mapping may result in errors in the Coexistence process (depending on the attributes).

Remarks:

  • PLMOpening IDs (types or attributes) can be mapped on a subscope of data i.e rules do not have to be written for all types.
  • For objects without a PLMOpening ID, a warning is issued (No rule available for ...).

Object Maturity Management

The table below describes how to manage object maturity.

Object maturity is transferred by means of the dedicated Business Logic PLMAttributesMapping. For more information, see Installation and Setup: Customize: Behavior: Data Setup: List of Resource Set IDs: Infrastructure Business Logic: Coexistence: Attribute Mapping Business Logic and Custo Type Mapping Business Logic (PLMCustoTypeMapping).

Warning: Transferring objects that have maturity FROZEN is not supported.

ScenarioTargeted Scenario Name
Scenario 1 Autonomous management

Description:

  • Source and target PDMs are autonomous for maturity management. Both sites manage their own policy.

Prerequisites:

  • The Maturity parameter value must be set to Off.

Coexistence Infrastructure behavior:

  • Maturity information will be ignored. The target PDM will set it with default information i.e the user who launches the coexistence process.
Scenario 2Synchronized management - ISO

Description:

  • Source and target PDMs are synchronized from a maturity management point of view.

  • Each change of maturity status in the source PDM means an update on the target PDM.
  • Only Master PDMs can update object maturity.

Prerequisites:

  • Source and target PDMs have exactly the same maturity.
  • The maturity parameter value must always be set to On.
  • Implementation of the PLMOpening ID PLMAttributesMapping must not be set.
  • Maturity policy must be consistent between both PDMs.

Coexistence Infrastructure behavior:

  • Object maturity will be transferred as is.

Note: If source and target PDMs do not have the same maturity, policy errors may appear.
Warning: Before transferring Mastership using the CoexistenceAdministration batch, make sure all your objects are synchronized on both your source and target PDMs.
Scenario 3 Synchronized management - Mapping. Non-ISO.

Description:

  • Source and target PDMs are synchronized from a maturity management point of view.
  • Any change of maturity status in the source PDM means updating the target PDM.
  • Only Master PDMs can update object maturity.
  • The maturity of source and target PDMs is not the same but is consistent. Mapping can be done.

Prerequisites:

  • The maturity parameter value must always be set to On.
  • Implementation of the PLMOpening ID PLMAttributesMapping must have been set.
  • Maturity policy must be consistent between both PDMs.

Coexistence Infrastructure behavior:

  • The Coexistence infrastructure will use dedicated PLMOpening IDs to change object maturity to be saved "on the fly".

Note: The mapping of maturity attributes must be written in accordance with customer business process integrity.
Warning: Before transferring Mastership data using the CoexistenceAdministration batch, make sure all your objects are synchronized on both your source and target PDMs.
Note: Regarding the scenarios Synchronized management - ISO and Synchronized management - Mapping, it is important to keep data synchronized. If, for any reason, maturity is updated i.e. a promote directly on a non-Master site, a demote must be done before running any further transfer on the non-Master site. For more information, see Data Editability Best Practices.

Management of Object Ownership (User, Project and Organization)

The table below describes object P&O management.

Object P&O is transferred by means of the dedicated Business Logic PLMAttributesMapping. For more information, see Installation and Setup: Customize: Behavior: Data Setup: List of Resource Set IDs: Infrastructure Business Logic: Coexistence: Attribute Mapping Business Logic and Custo Type Mapping Business Logic (PLMCustoTypeMapping).

Warning: Only users with all the required rights on the given objects can perform a transfer with P&O information.

ScenarioTargeted Scenario Name
Scenario #1 Autonomous managementDescription:
  • Source and Target PDMs are autonomous from a P&O management point of view. Both sites manage their own specific policy.
Prerequisites:
  • The PeopleAndOrganization parameter value must be set to Off.

Coexistence Infrastructure behavior:

  • User/Project/Organization information will be ignored. The target PDM will set it with default information i.e. the user who launches the Coexistence process.

Scenario #2Synchronized management - ISODescription:
  • Source and target PDMs are synchronized from a P&O management point of view.
  • Any P&O change in the source PDM means an update in the target PDM.
  • Only Master PDMs can update object P&O.

Prerequisites:

  • Source and target PDMs have exactly the same P&O.
  • The PeopleAndOrganization parameter value must always be set to On.
  • Implementation of the PLMOpening ID PLMAttributesMapping must not be set.
  • P&O policy must be consistent between both PDMs.
  • Users of source PDMs must exist in the target.
  • Projects of source PDM must exist in the target.
  • Organizations of source PDMs must exist in the target.
  • Users must belong to the same organization both in source and target PDMs.
  • Projects must belong to the same organization both in source and target PDMs.

Coexistence Infrastructure behavior:

  • Object P&O will be transferred as is.

Note: If source and target PDMs do not have the same maturity, policy errors may appear.
Warning: Before transferring Mastership using the CoexistenceAdministration batch, make sure all your objects are synchronized on both your source and target PDMs.
Scenario 3Synchronized management - Mapping. Non ISO.Description:
  • Source and target PDMs are synchronized from a P&O management point of view.
  • Any P&O change in the source PDM means an update in the target PDM.
  • Only Master PDMs can update object P&O.
  • The P&O of source and target PDMs is not the same but is consistent. Mapping can be performed.

Prerequisites:

  • The maturity P&O parameter value option must always be set to On.
  • The implementation of the PLMOpening ID PLMAttributesMapping has been set.
  • Maturity policy must be coherent between both PDMs.
Coexistence infrastructure behavior:
  • The Coexistence infrastructure will use the dedicated PLMOpening ID to change, "on the fly", the object's user, project and organization to be saved.
  • Mistakes in any of the mapping values result in errors in the Coexistence process.
Note: Mapping of People and Organization attributes must be written in accordance with customer business process integrity.
Note: None or all three attributes must be mapped. If none are built, P&O of the current user will be used only if the option is not selected for P&O mapping. Selecting the option without any attributes being mapped will result in an error. If all are built, the information must be in accordance with the target PDM P&O customization. In the event of mapping errors, data may not be available to users.
Warning: Before transferring Mastership data using the CoexistenceAdministration batch, make sure all your objects are synchronized on both your source and target PDMs.

Note: Regarding the scenarios Synchronized management - ISO and Synchronized management - Mapping, it is important to keep data synchronized. If, for any reason, People and Organization information is updated directly on a non-Master PDM, a demote must be done manually before running any further transfer to a non-Master PDM. For more information, see Data Editability Best Practices.