Flow/Type Association Check CATRule (FLTypeAssociationCheck)

General Information

This opening ID is invoked to define rules that are taken into account every time a flow/type is about to be associated to a port, to actually continue or cancel this operation. The flow/type association operation means:

In functional domain, a flow reference is instantiated under a functional reference aggregating a functional port; this port pointing the flow instance (coming from the flow reference).
In logical domain, a type reference is instantiated under a logical reference aggregating a logical port; this port pointing the type instance (coming from the type reference).

Let's illustrate this pattern with the following figure (in the logical domain):

This business logic is launched every time an interactive command or a programming interface (API) triggers an operation of flow/type association to a port. The business logic behavior is illustrated below (with the logical domain):

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


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

The validation nature of this business logic implies that the operation is actually performed if and only if every associated rule that is a candidate for execution within the context of this operation grants permission to do so.

Input Objects

Input objects must be of the following 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
TypeToAssociate	PLMEntity	Read	Flow/type reference to associate to the port.
AggregatingReference	PLMEntity	Read	Functional/logical reference aggregating the port.

The figure below illustrates the different parameters:

Sample

Let's implement the following rule (on the logical domain): the logical type can be associated to a logical port only if both objects share the same value of a custom attribute named 'Segregation' (defined on the PLM type RFLVPMLogicalCustomizedPort).

To achieve this particular business logic implementation, a CATRuleExit file, known as family, declares the script to run every time a logical type is about to be associated to a logical port:

<Scripts>
     <Script OpeningID="FLTypeAssociationCheck"
             Type="RFLVPLMLogicalCustomizedPort"
             ScriptName="CATMyFirstTypeAssociationCheckRule" />
</Scripts>

This family tells to run the script CATMyFirstTypeAssociationCheckRule whenever a flow/type association to a port 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 TypeToAssociate(PLMEntity)
let AggregatingReference(PLMEntity)

set TypeToAssociate = Parameters->GetAttributeObject("TypeToAssociate")
set AggregatingReference = Parameters->GetAttributeObject("AggregatingReference")

if (TypeToAssociate.GetAttributeString("Segregation") == ThisObject.GetAttributeString("Segregation"))
{
     validation = true
}
else
{
     validation = false
}
if (Validation == false)
{
    Parameters.Message = "The logical type '" + TypeToAssociate.Name + "' failed to  
    be associated to a logical port of '" + AggregatingReference.Name + "' reference
    because the defined segregations are different." 
}

Since this is a check purpose business logic, the Validation variable must be valuated during the script execution to return the check result. For more about the writing and delivery of these files, see the PLM Customization by Rules User's Guide.