RADE

Why Migrating ENOVIA Masks Customization?

Some customers have decided to apply changes on Dassault Systemes masks, in ENOVIA, so that ENOVIA behavior and appearance agree with their application. But with ENOVIA migration, new Dassault Systemes masks will be set in place, and will replace the old customized masks. To prevent users from losing any information, RADE provides them with a merger that will help them to quickly create new customized masks. These new masks will take into account the changes between ENOVIA release N and ENOVIA release N+1 and the old customized masks.

[Top]

Migrating ENOVIA Masks

The mask migration process is shown below.

• Files Required to Migrate the Mask

To run the masks merger, three files are required:

• Mask DEF N (Default mask Release N)
• Mask DEF N+1(Default mask Release N+1)
• Mask CUST N (Customized mask Release N)

1. Mask release N

   The default N mask can be retrieved using the VPMPeopleUpdate -savemask <dir>. Your mask is exported to a file in the <dir> folder.
   The customized N mask can be retrieved using the VPMPeopleImport -savemask <dir>. Your customized mask is saved in a file in the folder <dir>.
    

2. Mask release N+1

   Once you have migrated your ENOVIA LCA database, use the command VPMPeopleUpdate -savemask <dir> to export the default N+1 mask.

   For further details on VPMPeopleImport and VPMPeopleUpdate, refer to ENOVIA V5 LifeCycle Applications Documentation: Administration Tasks: People, Organization and Security Tools                       

• Launching the Merge Application

One you have retrieved all needed files for the migration, launch the CATVBTMaskMerger command as follows:

• After Merging your Files

Now, your mask is ready to be used in the database, you must import it. To do so, import the new custo files, using the command VPMPeopleImport in your ENOVIA installation files. For further details on VPMPeopleImport, refer to ENOVIA V5 LifeCycle Applications Documentation: Administration Tasks: People, Organization and Security Tools.

Principles of the Merger Application

The algorithm of the merger runs on sorted trees, so each *.custo file is sorted, and transformed into a tree. Then, comparisons are made between nodes of these trees, and according to the result of these comparisons, an action is deduced. When a doubt exists in the treatment of one case, an alternative action becomes necessary. At this moment, the user will choose which action to execute, to solve the problem. To choose this action, the user will write a rules file, to explain actions to do on one or several nodes.
(Rules are explained further in this documentation).

The result tree is based on the customized masks - version Rn

Details

• Tree and Sorting

This sort has no impact on nodes of the mask, except for nodes whose type is VALUE.
Indeed, customers who decide to customize VALUE nodes want to keep nodes content but also the nodes order. The sort will disturb the order defined in the mask. So to prevent any unwanted effects, a weight is affected to each node (this weight is in fact the line number at which the VALUE node has been found), and the sort is done.  Thus, after merging the three trees, it will be possible to retrieve the expected order, by reordering the VALUE nodes according to their weight.

 

• Action to Execute

 Once the 3 trees are sorted, compare them node by node. All cases have been summed up in the following table:

Actions
	Add node	the node and its sub tree are cloned and added in the result tree
	Keep node	the node is kept and comparisons and actions are launched in the node sub tree, that's why deep-first = yes for keep action
	Ignore node	the node and its sub tree are ignored (they do not appear is the result)
Node
	New	DEF(N+1) tree
	Cus	Custo(N) tree
	Ref	DEF(N) tree

         For example:

• Alternative Cases

In some cases, the merger engine cannot decide what to do, or cannot determine whether the chosen action matches the user intents. To let you set up the merger behavior, alternative actions  were added. So, you can choose one of the actions shown in the matrix.  By default, the merger engine uses Recommendations, but if a valid rule is found in the rules file, this latter is applied.

Thus, in an alternative case:

1. You first try to find the first rule which agrees with:

   The current node

   The possible choice given in the matrix

2. If no rule was met, recommendations are used.

• Rules File Syntax

Rules define the choice strategy to adopt when an alternative solution occurs.

Syntax:  {keep|ignore} {new|custo} <Xpath>

        keep = conservation  / ignore = exclusion  (only actions available in alternative cases)
        new = the reference (DS mask) / custo = the customization. 
       <Xpath> defines all concerned nodes

Each node  has a format : <node_type>::<node_id>.
Nodes are separated by '/'.

Types of these nodes can be :

E                   ->    Entity
+--_              ->    Property
+--F              ->    Filter (of entities)
+--A             ->    Attribute
     +--X        ->    Access
     +--_         ->    Property
     +--V         ->   Value

<node_id> are :
    -either a full valid identifier
    -either '*', in this case the engine will deal with every nodes

Particular case : //<type>::<id> describe all the nodes <type>::<id>, independently from their path

A few examples :

//_::alias                              ----------------> all aliases properties (entities +attributes)
E::* /_::alias                        ----------------> aliases property of all entities
E::E1/A::*                          ----------------> all attributes of entity E1
E::E1/A::A1                       ----------------> attribute A1 of entity E1
E::E2/_::alias                      ----------------> alias property of entity E2
E::E9/A::*/_::*                   ----------------> all properties of all attributes of entity E9
E::E9/A::*/X::*                  ----------------> all accesses of all attributes of entity E9
E::E9/A::*/_::values/V::*    ----------------> all values in values property in all attributes of  E9
E::*/F::F1                          ----------------> F1 filter of all entities
 

 

At this step, we only consider differences between Dassault Systemes nodes and customized nodes. That's why the rules only deal with "new" and "custo".

Thus, if we found such a situation:

[Top]

References

History

Copyright © 2006, Dassault Systèmes. All rights reserved.