Migrating V4 Multi-Model Links (MML) in ENOVIA V5 VPM

This task will show you how you can retrieve model links from CATIA V4, after a data migration into ENOVIA V5 VPM. Two processes are described:

The customer who want to migrate its CDM or VPM database to the new LCA one, can use the strategic DS tools:

  • psnmigex.sh for the CDM extraction (File saving).

  • IEnovIn.sh for the LCA insert (from File).

These tools insure the well migration for the CDM/VPM BOM and CATIA V4 models as simple representation. Unfortunately, there is no model introspection during the migration from a process to another. That means the links inside a model keep unchanged. After the complete migration process, a migrated model keeps on pointing the original model (VPM links).

The customer wants to be able to retrieve easily the corresponding pointed model in its LCA database to go on working with it.

The customer will need to have a CATIA V4 process in order to retrieve the corresponding pointed model in the LCA database. For this, interoperability between LCA and CATIA V4 is necessary. The goal after the migration is to be able to:

  • send to CATIA V4 from LCA the migrated models,

  • dereference into CATIA V4 the links inside the model,

  • retrieve from these old information (one CDM/VPM model ID) the corresponding migrated model (one LCA model ID),

  • rebuild the new link from this new information (CATIA V4 is the only process authorized to modify the links),

  • load the new pointed LCA models through the CATIA V4 application,

This CATIA V4 process will be called hereafter the rerouting mechanism.

For this, we need to have a mapping between the old information (CDM/VPM ID) and the new one (LCA ID). This will be possible with a dedicated mapping during the migration process:
  • the express mapping will keep the CDM/VPM ID in a dedicated attribute of the LCA express model.
  • knowing this attribute it will be easy to have a correspondence between these two pieces of information.
 

Migration of the CDM or VPM database

This functionality includes several steps:

  • the export from CDM/VPM into a step file,

  • the mapping from CDM/VPM to LCA,

  • the import into LCA from a step file.
 

We will describe explicitly the different steps, in order to make understandable the complete process.

  1. Export:

This first step, with the psnmigex.sh command, does not need any recommendation.
The customer can run it as of today.

  1. Mapping:

This step is very important because it is a customer action and the mapping will condition the future behaviour of the highlight.
We will briefly explain the different entities and attributes to take into account, the purpose will not be to have training on express language and STEP mapping.

  1. The highlight needs simple information: the CDM/VPM ID.
    This ID is certainly a simple concatenation of COID, COMPID and CAENV (for the environment). The CATAB (table information: CATIA_MODEL) is useless.
    The entry point in the LCA model is the ENOVExVPMTPDocumentMaster object. This object could have several ENOVExVPMTPDocumentRevision. In order to transfer the CDM/VPM data without ambiguity, the current mapping will create one ENOVExVPMTPDocumentMaster and one ENOVExVPMTPDocumentRevision for each representation to migrate.
    You will find any information in the express files:
    - cdma.express for the CDM/VPM model.
    - ENOV_DATAX.express for the LCA model.

    These created objects have to be unique.
    The uniqueness is insured through the V_ID attribute of the ENOVExVPMTPDocumentMaster object, and for reconciliation purpose, this attribute has to be a VPM unique identifier. In order to transfer and keep the CDM/VPM ID into LCA, the more simple solution is to use the V_ID attribute. But any string typed attribute of the ENOVExVPMTPDocumentMaster object could be used provided that the length attribute is enough, for example: V_name.
    Anyway, at this step the customer has to know what is its migration policy considering the attributes uniqueness, the CDM/VPM objects to migrate and the new LCA model. Moreover, by default, the model is identified in the LCA client by its V_ID attribute. That means, this attribute should be the clearer as possible.
    Our recommendation is to use either:
    - the V_ID attribute
    - or the V_name attribute.
    in order to keep the concatenation of COID, COMPID and CAENV attributes. This last operation could be done through the user-function: B_GetDocID (const SdaiPrimitiveH& iDoc), with the variable ENOVExVPMtoLCA_DocIdentificationMode set to "2".

    In other words, the piece of the mapping for the ENOVExVPMTPDocumentMaster and the ENOVExVPMTPDocumentRevision attributes should look like this:
    VIEW DOCMCM_VPMENV FOR dcmnt : enovia::ENOVExVPMTPDocumentMaster;
    FROM (model : cdma::VPMENV_CATIA_MODEL)
    WHEN TRUE;
    BEGIN_VIEW
          dcmnt.V_ID                       := B_GetDocID(model);
          dcmnt.V_name                  := model.C_NICKNAME;
          …
    END_VIEW;
    -------------------------------------------------------------------------------
    VIEW DOCVCM_VPMENV FOR dctv : enovia::ENOVExVPMDocumentRevision;
    FROM (model : cdma::VPMENV_CATIA_MODEL)
    WHEN TRUE;
    BEGIN_VIEW
          dctv.V_version          := model.C_REVISION;
          dctv.V_status            := 'nls_WIP';              
          dctv.V_master           := {DOCMCM_VPMENV} model;
    END_VIEW;

    But if the customer has its own uniqueness rule for the V_ID attribute (through the user function: User_fnct1() – see below), the first view also looks like:
    VIEW DOCMCM_VPMENV FOR dcmnt : enovia::ENOVExVPMTPDocumentMaster;
    FROM (model : cdma::VPMENV_CATIA_MODEL)
    WHEN TRUE;
    BEGIN_VIEW
          dcmnt.V_ID                     := User_fnct1(model);
          dcmnt.V_name                := B_GetDocID(model);
          …
    END_VIEW;

    Obviously, in any case, as it is showed above, the V_ID must be unique.
    And for the next steps, the customer has to know exactly what is the attribute dedicated to the CDM/VPM ID.

  2. The normal behavior for the import is not to manage the timestamps for the object, but, for an interoperability purpose, some attributes must be valuated, including the timestamp attributes:
    - C_created
    - C_modified
    So, in order to avoid some inconsistencies with the CATIA V4 functionalities, you are strongly advised to set the timestamps attributes in the mapping, at least for the following LCA objects:
    - ENOVExVPMTPDocumentMaster
    - ENOVExVPMDocumentRevision
    - ENOVExVPMDocumentIteration
    - ENOVExVPMTPRepresentation

    This is possible through the user-function:
    C_SetTime (const SdaiPrimitiveH& iObject,
                          const SdaiPrimitiveH& iSetMode)
    where iObject is the model object to import, where iSetMode is the attribute set mode:
    - "1" for creation mode, i.e. C_CREATE (VPM attribute) will be read,
    - "2" for modification mode, i.e. C_LASTMOD (VPM attribute) will be read.

    Here is an example:
    VIEW DOCMCM_VPMENV FOR dcmnt : enovia::ENOVExVPMTPDocumentMaster;
    FROM (model : cdma::VPMENV_CATIA_MODEL)
    WHEN TRUE;
    BEGIN_VIEW
          dcmnt.V_ID                       := B_GetDocID(model);
          dcmnt.V_name                  := model.C_NICKNAME;

…
      dcmnt.C_created                 := C_SetTime(model,1);
      dcmnt.C_modified               := C_SetTime(model,2);
END_VIEW;

  1. Import:

This step, with the IEnovIn.sh command, does not need any recommendation.
The customer can run it as of today.

  1. Environment:
    The UNIX common environment necessary to perform the following tests is:

  1. One VPM database with:
    - MML V4 links exposed.
    - the navigation library (libLV0XCDMA.*) and the corresponding cdma.express correctly generated.

  2. One CATIA V4 installation with at least the LCA database connection.
    The VPM database connection is not necessary if all MML V4 structure has been already built.

  3. One LCA installation with:
    - the express library from the VPM cdma.express file correctly generated.
    - the mapping from cdma.express to ENOV_DATAX.express and the corresponding library correctly generated.
 

Multi Model Links rerouting in CATIA V4

The link synchronization will be possible after migration. The customer will be able to view the different components of its drawing, SolidE or Numerical command (NC) data. The rerouting mechanism will no longer be manual, and there will be a major impact on all CDM / VPM V4 users. It will make the CDM or VPM to LCA migration deployment easier and, the LCA deployment and processes scalable.
 

Before this functionality: With this functionality:
There was not any automatic way to reconnect and synchronize the VPM links inside a LCA model.
The only way was a manual one: for each link, the customer had to know the application owner of the link, and reconnect manually the link with the dedicated tool with the right application.		 A new command (/reroute) is added to the CATIA V4 product.
This command automatically scans the current model, and for each VPM link (exclusively Drafting, SolidE and Numerical Control links type) inside the model, retrieves the corresponding LCA model, and reroutes the link within this model. Then, the AUXVIEW2 application, SolidE and MFGPROG can be run on the current model.

This functionality includes several steps:

  • the interoperability between LCA and CATIA V4 (send to CATIA V4 from LCA);

  • the /reroute command in CATIA V4 or rerouting mechanism.
 

  1. ENOVIA V5 VPM / CATIA V4 Interoperability:

As of today, the behavior of the interoperability between LCA client and CATIA V4 does not need any special recommendation.
However, at this step, the UNIX and customization variables should be set for the LCA client side, LCA server side and CATIA V4 side.

  1. For LCA client: no specific customization is needed.

  2. For LCA server: the attribute used to store the CDM/VPM ID must be known by the server.
    For that, the UNIX variable ENOVExVPMId must be set with the right value name.
    For example, if V_name was used, the customer has to set the variable as following:
    export ENOVExVPMId=’V_name’
    in the customisation environment file:
    $HOME/CustomEnv for the testing user, or the installation customization file (see further details in the installation guide).
    By default, if this variable is not set, the V_ID attribute will be considered as the right one.

  3. For CATIA V4 side: the command /reroute must be correctly defined in the declarative file for functions and commands as following:

    CATCMD.COMMAND.LOAD3D.REROUTE = ‘LD0RELNK’;
    CATCMD.COMMAND.LOAD2D.REROUTE = ‘LD0RELNK’;
    CATCMD.COMMAND.LOADDR.REROUTE = ‘LD0RELNK’;
    CATCMD.COMMAND.NAME.REROUTE = ‘LD0RELNK’;
    CATCMD.COMMAND.DETSPACE.REROUTE = TRUE;
    CATCMD.COMMAND.DETDRAW.REROUTE = TRUE;
    CATCMD.COMMAND.MODSPACE.REROUTE = TRUE;

  1. Rerouting mechanism in CATIA V4 (/reroute command):

As usual, CATIA V4 has to be connected to the LCA client by any mean:

  1. Manually through the CATIA V4 command: /enovia.

  2. Automatically, by launching the CATIA V4 process from the LCA client.

From Content Management and Document Editor on the LCA client, retrieve the model with VPM Links and apply the Send To / CATIA V4 menu on it (to have it as the active one).

After the load of the model, i.e. the drafting model, or the model containing the SolidE import, or the geometric model for machining operations, the command /reroute can be run.

The only user interface available is the CATIA V4 command: /reroute. This command is a GII one.
In case of error, the help is available (/help command). Otherwise, the command ends with an informative short message. Here is the list of the messages visible in CATIA V4, with the "error" number:

Information messages:
When there is no more links to a VPM model to reroute:
1896
MODEL COMPLETELY PROCESSED
ALL LINKS WITHIN THE CURRENT MODEL HAVE BEEN REROUTED

Error messages:
When you activate the link window in CATIA V4 (/link window for AUXVIEW2 function and Part Editor checklinks or checklink menu for SolidE) and, when there are VPM links with models in ENOVIA V5 VPM:
1890
LCA MODEL WITH VPM LINKS
ALL LINKS ARE POINTING 'DBMS' MODELS:
YOU SHOULD USE /REROUTE COMMAND TO CHANGE OLD LINKS

When the current model is not loaded from ENOVIA V5 VPM (ex: model loaded from Open > File), no link rerouting is available:
1891
MODEL NOT SUPPORTED FOR /REROUTE
ONLY LCA MODELS ARE SUPPORTED

When there is a problem with a link within the model:
1892
MODEL LINKS EXTRACTION ERROR
PROBLEM DETECTED WITH MODEL LINKS

When mapping information is missing (can happen when the model has not been migrated from VPM into LCA):
1893
MODEL MAPPING ERROR
PROBLEM DETECTED WITH LCA/VPM MAPPING

When there is a link that can not be rerouted:
1894
LINK REROUTE ERROR
PROBLEM DETECTED WITH MODEL LINKS REROUTING

There no link (or no link anymore) to VPM models, the rerouting command cannot operate:
1895
NO LINKS TO REROUTE
NO SUPPORTED LINKS TO REROUTE

There are still links to be rerouted (ex: pointed models from VPM which have not been migrated, or non-VPM links that have not been modified):
- 1897
   MODEL PARTIALLY PROCESSED
   LINKS WITHIN THE CURRENT MODEL HAVE BEEN REROUTED
   BUT AT LEAST ONE OLD LINK REMAINS IN THE MODEL.
- 1898
   HYBRID LCA MODEL WITH VPM LINKS
   SOME LINKS ARE STILL POINTING 'DBMS' MODELS:
   THESE LINKS HAVEN'T BEEN CORRECTLY REROUTED (MAPPING ERROR OR MODELS HAVEN'T BEEN MIGRATED).
   TRY TO USE /REROUTE COMMAND TO CHANGE THESE LINKS.

In short, this command:
- scans the model and lists all the CDM/VPM Drafting and SolidE and NC links, with the VPM ID,
- calls the LCA server with these information,
- the LCA server retrieves thanks to the internal mapping the new LCA ID,
- the LCA server returns these new information,
- the links are modified by CATIA V4 and point to the corresponding VPM model migrated in LCA.

Then, the AUXVIEW2 and SolidE and MFGPROG functions are able to analyze, scan, browse the new links, and the information related to the pointed models in LCA could be exposed.

Miscellaneous and limitations
 

Miscellaneous

SolidE and Drafting NC links can be managed through CATIA V4 windows (/link window for AUXVIEW2 function and Part Editor checklinks or checklink menu for SolidE). You can see the new pointed models after rerouting and they can be automatically loaded (with Load Passive commands). The pointed models can be managed transparently as before, in VPM. For AUXVIEW2 links, the load as passive of the pointed models and an update could be required to synchronize Views.

Limitations

After migration, this highlight will allow the customer retrieve the correct information on the link. This link could be rerouted, resynchronised and the model could be saved or not with the new information.
Due to the uncertain LCA support of all CATIA V4 application, the functionality focuses on:

  • AUXVIEW2 links, i.e. MML_Drafting links, through the /link command.

  • SolidE links, i.e. MML_SolidE and MML_Solskin links (solid pointing to skin), through the functionalities in the Part Editor:

    • Check Link… on the Import primitive,
    • Check Links… on the SolidE.
  • MFGPROG links, i.e. MML_NC links, through the interactive function MFGPROG.

No customization is possible at installation, through settings and so on. But the mapping can be customized in order to choose the attribute which holds the CDM/VPM ID (see External behavior) and connect it to LCA ID. This implies to set an UNIX variable for the /reroute command.

The rerouting mechanism does not need to load the pointed models in order to reroute the links.
Nevertheless, due to the CATIA V4 infrastructure, the rerouting mechanism cannot be automated through a batch process. That means CATIA V4 always needs to connect manually to a LCA client process, which is a prerequisite of any interoperability mechanism.

Only Drafting, SolidE and NC links are taken into account in the rerouting mechanism. Any other applicative links cannot be rerouted.
In the VPM database, those links can be analyzed and visualized with the MML graph functionality. Their applicative types are MML_NC, MML_Drafting, MML_SolidE and MML_Solskin. Therefore, the pointing model can mix supported links after the rerouting mechanism:

  • LCA links (Drafting and SolidE and NC) onto LCA models,

  • CDM/VPM links which have not been rerouted and still stay in the model.

This situation is not recommended, the customer should avoid to have mixed links.