How ENOVIA information is impacted by Reconciliator

Reconciliation solution enables you to import a set of CATIA documents in ENOVIA, defining how those data issued from file will affect data stored in ENOVIA. For this purpose you will be able to define storage mode.
  • For CATProduct document, in Structure Exposed, you will have to define the mapping of CATIA Product onto an assembly node.
    • For ENOVIA V5, it will be either a Part Version (PV) or a PRC (For the root of the assembly).
    • For ENOVIA VPM V4, it will be a Part (an object issued from PART_LIST table).
  • For other cases (CATProduct in Publication Exposed mode or other supported document types), he will have to define the mapping onto a document.
    • For ENOVIA V5, it will be Document Revision (DR).
    • For ENOVIA VPM V4, it will be document (object stored in document tables) or CATIA V4 model (object stored in CATIA_MODEL table).
  After defining for each CATIA objects (CATIA Products in Structure Exposed and Document for Publication Exposed) one counter ENOVIA object, you will select one Reconciliation rule among the authorized ones. The rules are categorized into 2 categories:
  • The First category (called Reload) where you will not update ENOVIA repository with the information received from file. This is done by using Reload from VPDM rule.
  • The second category (called Overwrite) where you will update the information in ENOVIA with data received from file. In this category, you will find all other rules: New, Overwrite, New Version, New Revision, and Overwrite by Delta.
  When you click the Apply button of the Reconciliator Window, the Reconciliator will define for each object the way, it will be exposed in ENOVIA repository:

  1. For reference objects, Document and CATIA Product on which end-user has defined an explicit mapping, the behavior will explicitly defined by the Reconciliator rules selected.

  2. For other objects, such as Instances, publications or connections, Reconciliator program will compute a mapping using either comparison techniques or a replacement mechanism (removed all older information in ENOVIA and save CATIA ones as new).

    The update logic for this set of information will be based on the rule associated to the reference object that aggregates this information:

    • For CATPart or CATProduct in Publication Exposed, the program will automatically map the Root Product on the Part with the part associated to this document (using for ENOVIA V5 the exposition information).

    • For CATIA product instance, in Structure Exposed, the mapping will done using an assembly structure comparison and the CATIA instance will update ENOVIA if its father CATIA Product is using an Overwrite rule. In case of reload rule on the CATIA father Product, the CATIA instance will be refreshed.

In case of CATProduct in Publication Exposed, CATIA product instance are not exposed in ENOVIA. However, the instances embedded in the parent document will be updated if document is using an overwrite rule, throw the update of the document content in Vault. So behavior is consistent on instances, with the 2 storage modes:
 
Instance Comparison Status Meaning
 		 Rule on Father CATIA Product
Reload Rule
(Only for ENOVIA V5)
 		 Overwrite rule

identical

 CATIA instance successfully mapped on an ENOVIA instance with the same 3D position. CATIA Instance will be refreshed. ENOVIA instance will be updated in ENOVIA (position, name, and others attributes )
To be moved CATIA instance successfully mapped on an ENOVIA instance with different 3D position.
To be deleted  One ENOVIA instance has no counterpart among CATIA instances. Nothing to do either in CATIA side or on ENOVIA instance. ENOVIA instance will be deleted, except for Overwrite by Delta or New Version by delta where nothing will be done
To be created One CATIA instance has no counterpart among ENOVIA instances. Reconciliation will fail. ENOVIA instance will be created in ENOVIA
 

In context of ENOVIA V5, you need to take into account that the assembly model is relying on a mixed assembly structure model with the instance model (PRC and Item Instance) and the reference assembly model (Part and Assembly Relation). As Reconciliator mainly operates at reference model (Assembly Relation and Item Instance directly attached to the PRC), the impact on Item Instance will be evaluated according to its mother Item Instance and its associated Assembly Relation.

  • For Publications, the mechanism will be similar to CATIA product instances:
    In case of Overwrite rule on Document, the Reconciliator program will compute a mapping based on comparison on publication name. At next save, CATIA publications will be saved in ENOVIA either in updating existing ones or create new ones for not mapped ones. Publication in ENOVIA not mapped on an existing Publication in CATIA will be removed.
    In case of Reload rule on Document, the Reconciliator program will have only to reload the CATIA document which will have as side effect to replace at Reconciliation Apply all Publications.
  • For contextual links:
    In case of Overwrite rule on Document, the Reconciliator program will remove existing links in ENOVIA associated to this contextual part; and will create new links for this contextual part according to the CATIA view. There is never some update for such entities.
    In case of Reload rule on Document, the Reconciliator program will have only to reload the CATIA document which will have as side effect to replace at Reconciliation Apply all Publications.
  • For Connections, the mechanism will be based on a replace mechanism:
    In case of Overwrite rule on the Document or Product, the Reconciliator program will compute impacted Connections in ENOVIA and will log their deletion at next save. With the same mechanism, the program will log as new all CATIA connections. Thus, at next save, CATIA connections will replace existing ENOVIA ones.
    In case of Reload rule on the Document or Product, the Reconciliator program will refresh CATIA session with connections published in ENOVIA.