How to Implement the Port Creation Check Business Logic?

Technical Article

Abstract

This article details how you can implement the Port Creation Check Business Logic based on the knowledge scripting technology.

Business Logic Intent

The port creation check business logic allows you to define rules that are taken into account everytime a port creation operation is about to be performed, to actually continue or cancel this port creation operation processing.

The port creation operation means: a PLM port is created and is aggregated under a PLM reference.

The port creation check business logic is launched everytime an interactive command or a programming interface (API) tiggers a port creation operation. This is illustrated hereafter:

Fig.1 intent illustration

In the 4b situation, the port creation check business logic doesn't grant permission to run the operation, which means that the PLM port is not created nor aggregated.

PLM Opening Definition

This section describes the objects defining the PLM opening: its global information, its kind of input object, its context object parameters.

General Information

PLM Opening ID PLMPortAggregationCheck
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

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
PLMPort

Since the Knowledge scripting technology supports inheritance, the actual component type may be any type that derives from this PLM Core type. 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
AggregatingReference PLMCoreReference Read Pointer to the PLM reference that will aggregate the port (See [Fig.2])

Implementation Sample

Let's implement the following rule: the aggregation of a port under a reference of PLM type MySampleType is allowed if and only if it is created under a reference of PLM type MyGoodType.

The figure hereafter illustrates both conclusive situations:

Fig.2 sample situations

To achieve this particular business logic implementation, a CATRuleExit file, known as family, declares the script to run everytime a PLM port of the PLM type MySampleTypeis about to be created under a PLM reference:

<Scripts>
    <Script OpeningID="PLMPortAggregationCheck"
            Type="MySampleType"
            ScriptName="CATMyFirstPortAggrCheckRule" />
</Scripts>

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

Let Reference(PLMCoreReference)
set Reference = Parameters->GetAttributeObject("
        AggregatingReference")

if (Reference.IsSupporting("MyGoodType") == true) {
    Validation = true
}
else {
    Validation = false
}

if (Validation == false) {
    Parameters.Message = "The creation of a port of PLM type MySampleType under a reference
    is allowed if and only if the reference is a reference of PLM type MyGoodType."
}

Since this is a check purpose business logic, the Validation variable must be valuated during the script execution to return the check result.

Recommendations

None

References

History

Version: 1 [Feb 2009] Document created