Functional/Logical Connection Creation Check Business Logic (FLConnectionCreationCheck)

General Information

This opening ID is invoked everytime an interactive command or a programming interface (API) triggers an operation of functional/logical connection creation.

The functional/logical connection creation operation means that a connection is established between two ports; each port being in context of its reference or of an instance coming from its reference.

There are two different possible patterns relating to the functional or logical connection:

Sibling: the connection links two ports of two instances located under the same reference.
Parent/Child: the connection links two ports of a reference and of an instance (located under the previous reference).

The business logic behavior is illustrated below (with the logical domain on the parent/child case):

The table below provides you with information related to the definition of the Opening ID.


PLM Opening ID	`FLConnectionCreationCheck`
Customization intent	Validation
Execution context	Client

Input Objects

The Business Logic can be invoked for at least the listed PLM Component Type. It means that your implementation can safely use the PLM attributes of the default PLM Component.


PLM Component Class Types
RFLPLMFunctionalConnector
RFLVPMLogicalPort

Since the Knowledge scripting technology supports inheritance, the actual component type may be any type that derives from theses two PLM Core types. Hence additional attributes defined by the inheriting types may be accessed depending on the context of the operation.

Context Object parameters


Parameter Names	Types	Read/Write	Comments
AssociatedConnectable	PLMEntity	Read	The instance or reference aggregating 'this' port.
TargetPort	PLMEntity	Read	The Port that is going to be connected to 'this' port.
TargetConnectable	PLMEntity	Read	The instance or reference aggregating the target port.
Connection	PLMEntity	Read	The connection being established.

The figure below illustrates the different parameters for the two different possible patterns:

Parent/Child case:
Sibling case:

Sample

Let's implement the following rule (on the logical domain): The logical connection can be created only if the implied entities shares the same value for 'V_description' attribute.

To achieve this particular business logic implementation, a CATRuleExit file, known as family, declares the script to run everytime a logical connection is about to be established between two logical ports:

<Scripts>
     <Script OpeningID="FLConnectionCreationCheck"
             Type="RFLVPLMLogicalCustomizedPort"
             ScriptName="CATMyFirstConnectionCreationCheckRule" />
</Scripts>

This family tells to run the script CATMyFirstConnectionCreationCheckRule whenever a connection creation operation
is launched with a logical port of PLM type RFLVPMLogicalCustomizedPort. This script is a CATRule file that contains
the following business logic implementation:

let AssociatedConnectable(PLMEntity)
let TargetConnectable(PLMEntity)
let TargetPort(PLMEntity)
let Connection(PLMEntity)

set AssociatedConnectable = Parameters->GetAttributeObject("AssociatedConnectable")
set TargetConnectable = Parameters->GetAttributeObject("TargetConnectable")
set TargetPort = Parameters->GetAttributeObject("TargetPort")
set Connection = Parameters->GetAttributeObject("Connection")

if ((TargetPort.V_description == ThisObject.V_description) and (AssociatedConnectable.V_description ==
 TargetConnectable.V_description) and (TargetPort.V_description==Connection.V_description))
{
     validation = true
}
else
{
     validation = false
}
if (Validation == false)
{
    Parameters.Message = "The logical connection cannot be created for the implied objects description is not compliant."  
}

Since this is a check purpose business logic, the Validation variable must be valuated during the script execution to return the check result. The reader can refer to the PLM Customization by Rules documentation [1] to get more insights regarding the writing and the delivery of these files.