Public Unique Identifier Valuation Business Logic (PLMPublicUIDValuation)

This Business Logic Openness allows you to define a set of attribute values for the Public Unique Identifier enabling identification of an object during Multiple PDM transfer.

This page discusses:

Role and Limitations of the PUID Valuation Business Logic Openness
Definition of PUID Valuation Business Logic Openness
Implementation Sample

Role and Limitations of the PUID Valuation Business Logic Openness

This Business Logic Openness (BLO) allows you to retrieve some attribute values contained in each element to be transferred. These values are concatenated to generate a Public Unique Identifier (PUID).

This BLO allows you to identify an element from among several PDM sources or targets. An attribute value is used for the PUID if it is valuated through the PUID Valuation Business Logic Openness. This BLO presents the same input and output objects as the PLM Attributes Mapping one, attribute valuation then occurs in the same way. Once it is created, the PUID allows you to query the target database to determine whether it contains the corresponding element. A query is launched for each target customized type. For each of these queries, the same attribute set should be modified. Otherwise, the transfer will fail. The query can be launched only if the selected clause (made up of PUID attributes) is the same for all result elements. As seen before, a PUID valuation BLO must modify the same attributes for all elements presenting the same target customized type. The values of these attributes should of course be different for each element to ensure the uniqueness of the PUID. These values should remain the same for all transactions to ensure the stability of the PUID. For each target type, a PUID valuation BLO should be provided. This avoids unintentional default behavior. Even for target types with no PUID attributes, an empty PUID Valuation Business Logic should therefore be provided. In this last case, no PUID query is launched.

Definition of PUID Valuation Business Logic Openness

This section describes the way the PUID Valuation BLO works, its parameters and the context in which it is used.

General Information


PLM Opening ID	PLMPublicUIDValuation
Customization Intent	Execution
Execution Content	Client

Input Objects

The Business Logic is invoked for each PLM component to be transferred. The implementation can safely retrieve its PLM public attributes.


Parameter Name	Type	Read/Write	Comments
OperationId	String	Read	Parameter used to identify the context of mapping. Following values are available: * "Coexistence" for any Coexistence scenario
Source	String	Read	In Coexistence scenario it corresponds to the name of the Source Provider (PLM1, VPM1 ...).
Target	String	Read	In Coexistence scenario it corresponds to the name of the Target Provider (PLM1, VPM1 ...).
SourceTypeName	String	Read	Customized type of the source PLM entity to be exchanged
SourceObject	PLM Entity	Read	This is a PLM proxy object with the same top modeler type and customized type as the source PLM entity to transfer. In the rule implementation it is therefore possible to retrieve source attributes values from this PLM entity.

Note: Depending on the context, some parameters may be unset. It is therefore necessary to check attribute validity before reading. For more details, see the recommendations below.

Output Objects

The Business Logic valuates the attributes of an output proxy, ThisObject, which has the same customized type as the target component. The output proxy attributes will allow you to query the target database.


Parameter Name	Type	Read/Write	Comments
ThisObject	PLMEntity	Write	This is the PLM proxy object with the top modeler and customized type of the target PLMEntity. It has therefore all the attributes of this type. In the rule implementation it is possible to valuate Public UID attributes in this PLM entity. Each attribute of ThisObject which is modified in the rule will take part in the Public UID.

PUID Valuation Business Logic Use

In the example below, a source object has already been transferred to the target database. The public identifier is a set of values carried by different attributes in each database: Car01/023.

Transfer of an Object with a MultiPDM Query

The source object is now transferred from Source PDM to Target PDM. The Transition Engine first computes the target customized type of the object through the Customization Type Mapping BLO.

This customized type is then used by the PUID Valuation BLO to type its target proxy. All the target attributes can therefore be valuated in this proxy. In this example, the PUID Valuation BLO allows you to valuate the two target attributes i.e. Tgt_Name and Tgt_Version with the values of the Src_Name and Src_Version source attributes respectively. The PUID of the object to be transferred is created. A query is launched to determine whether an object with the same PUID already exists in the target PDM. If so, the object is not transferred.

Interaction between Attributes Mapping Business Logic and PUID Valuation Business Logic

During the first transfer, the attribute mapping BLO valuates the target object attributes. Its rules can modify the source value. In the example below, note that the Tgt_Name attribute is suffixed by "_Break", to indicate the car type. As this attribute is part of the PUID, this modification should be taken into account by the PUID Valuation BLO in the next transfer.

In order to match the target attributes, the PUID Valuation BLO should valuate the PUID attributes in the same way as the Attributes Mapping BLO. In the example below, it is necessary to valuate Tgt_Name and Tgt_Version as was done in the previous transfer. Otherwise, its transfer would be launched and would clash with the existing object in the target PDM.

Implementation Sample

As described above, the BLO scripts allow you to retrieve attribute values from the input proxy, SourceObject, and to valuate attributes of target one, ThisObject. To execute rules during the transfer they should be declared in a CATRuleExit file and implemented in a CATRule file. These files are written in EKL (Engineering Knowledge Language). To be interpreted, they should be placed in CLIENT Runtimeview/resources/knowledge/script/. To achieve this particular BLO implementation you must associate a script (for example "MyPublicUIDValuation") with the <OpeningID, Type> pair in a CATRuleExit file:

<Scripts>
     <Script OpeningID="PLMPublicUIDValuation"
             Type="PLMProductDS"
             ScriptName="MyPublicUIDValuation" >
             <Condition Attribute="OperationId" Value="Coexistence" />
             <Condition Attribute="Source" Value="VPM1" />
             <Condition Attribute="Target" Value="PLM1" />
     </Script> 
</Scripts>

You must then create a CATRule file (for example MyPublicUIDValuation.CATRule) to define your rule:

Let SourceObject(PLMEntity)
Let TargetPLM_ExternalID=""
Let Targetmajorrevision =""

if (Parameters->HasAttribute("SourceObject") == true)
{
       set SourceObject = Parameters->GetAttributeObject("SourceObject")
       if(SourceObject <> NULL)
       {
              if (SourceObject->HasAttribute("PLM_ExternalID") == true) 
              {

                     TargetPLM_ExternalID = SourceObject->GetAttributeString("PLM_ExternalID") + "_Volvo"
                     ThisObject.PLM_ExternalID = TargetPLM_ExternalID
               }
               if (SourceObject->HasAttribute("majorrevision") == true)
               {

                      Targetmajorrevision = SourceObject->GetAttributeString("majorrevision")
                      ThisObject.majorrevision = Targetmajorrevision
                }
       }
}

Recommendations

Before using an optional input parameter, you must check its value. For instance, to check if the SourceObject parameter is valuated or not, use the following code sequence:

...
GetAttributeObject("SourceObject")
if(SourceObject <> NULL)
{
...