Instance Aggregation Check (PLMInstanceAggregationCheck)

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

Note: The policy name of the object is a parameter of the opening meaning that depending on the policy, you can assign different values to the attributes and you can also assign the same attributes to different deployment extensions.

This page discusses:

Business Logic Intent
PLM Opening Definition
Implementation Sample

Business Logic Intent

The instance aggregation check business logic allows you to define rules that are taken into account each time an instance aggregation operation is about to be performed, to actually continue or cancel this instance aggregation operation processing.

The instance aggregation operation means: an instance (respectively a representation instance) is created and is aggregated under a reference (respectively a representation reference).

The instance aggregation check business logic is launched each time an interactive command or a programming interface (API) triggers an instance aggregation operation. This is illustrated below:

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

PLM Opening Definition

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

General Information


Opening ID	`PLMInstanceAggregationCheck`
Customization Intent	`Validation`
Execution Content	On the cloud: Client On premises: Client/Server

Note: 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 attributes of the default PLM Component.

Since the Knowledge scripting technology supports inheritance, the current component type may be any type that derives from these 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
ReferenceToInstantiate	PLMEntity	Read	Pointer to the PLM reference to be instantiated. (see graphic below.)
`Policy`	`String`	Read	Policy name.

Implementation Sample

Let's implement the following rule: the aggregation of a port under a reference of type MySampleType is allowed if and only if it is created under a reference of type MyGoodType.. The graphic hereafter illustrates both conclusive situations:

To achieve this particular business logic implementation, a CATRuleExit file, known as family, declares the script to run each time an instance is about to be aggregated under a reference of the type MySampleType:

<Scripts>
      <Script OpeningID="PLMInstanceAggregationCheck"
              Type="MySampletype"
              ScriptName="CATMyFirstInstAggrCheckRule" />
</Scripts>

This family tells to run the script CATMyFirstInstAggrCheckRule whenever an instance aggregation operation is launched with a reference of type MySampleType. This script is a CATRule file that contains the following business logic implementation:

Let Reference(PLMEntity)
set Reference = Parameters->GetAttributeObject("ReferenceToInstantiate")

if (Reference.IsSupporting("MyGoodType") == true) {
    Validation = true
}
else
{
    Validation = false
}
if (Validation == false) {
    Parameters.Message = "the aggregation of an instance under a reference of type MySampleType is allowed
    if and only if this instance is instantiated from another reference of type MyGoodType." 

}

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