How to Implement the Functional/Logical Connection Creation Check Business Logic? |
Technical Article |
AbstractThis article details how you can implement the Functional/Logical Connection Creation Check Business Logic based on the knowledge scripting technology. |
The functional/logical connection creation check business logic allows you to define rules that are taken into account everytime a connection is about to be established between two ports (in context of their instance or reference), to actually continue or cancel this operation.
This business logic is launched everytime an interactive command or a programming interface (API) triggers an operation of functional/logical connection creation.
The functional/logical connection creation operation means:
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 relatively to the functional or logical connection:
The business logic behavior is illustrated below (with the logical domain on the parent/child case):
This section describes the objects defining the PLM opening: its global information, its kind of input object, its context object parameters.
PLM Opening ID | FLConnectionCreationCheck |
---|---|
Customization Intent | Validation |
Execution Context | Client |
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.
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:
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 since the implied objects description is not compliant." }
None
[1] |
Version: 1 [Decemeber 2008] | Document created |