Transferring Maturity Information from ENOVIAvpm to 3DEXPERIENCE

Maturity information is not transferred by default. You must explicitly activate it. To do this, edit the appropriate transition profile:

Depending on the scenario, you may or may not need to map maturity attributes. For information on how to map customized attributes and customized types to 3DEXPERIENCE, see Customized Attribute and Type Mapping.

• Scenario 1

  The maturity statuses have the same name in both the source and target repositories and the maturity sequences are the same. In this case, maturity attribute mapping is NOT required:

  
  
  Note that the attribute mapping phase can be deactivated in this particular case. The maturity attribute values are simply copied from one site to the other.
• Scenario 2

  The maturity statuses have different names in the source and target repositories but the maturity sequences are the same. In this case, maturity attribute mapping IS required:

  
  
  Note that in this case the attribute (or attribute set) containing the maturity information in the source provider has to be mapped to the corresponding attribute (or attribute set) in the target provider.
• Scenario 3

  The maturity statuses have different names in the source and target repositories and the maturity sequences are also different. In this case, maturity attribute mapping IS required:

  
  
  Note that in this case the attribute (or attribute set) containing the maturity information in the source provider has to be mapped to the corresponding attribute (or attribute set) in the target provider.

Note the following:

• Maturity mapping works in the same way as attribute mapping using Business Logic (BL). In other words, you can access the protected 3DEXPERIENCE attribute V_maturity in BL.
• Only basic checks are made when maturity information is transferred. The maturity status is presumed to be known by the target repository for the given object type.
• Maturity and ownership policies are strongly related. If you transfer maturity and ownership information, this information must be valid in respect of the policy rules of the target repository.
• For attribute mapping purposes, a sample script is provided in the runtime view in:

  {OS}\resources\samples\ TE_AttributesMapping_Sample_VPM1_V6.CATRule

• No customer-specific integrity rules are validated during the transfer process. If the maturity Business Logic is different in the source and target repositories, the migration / coexistence process will not ensure the consistency of object maturity in line with the target rules.
• Under no circumstances are you allowed to call any database request in the scripts corresponding to the Business Logic openings.