How to Implement the Instance Aggregation Check Business Logic? |
Technical Article |
AbstractThis article details how you can implement the Instance Aggregation Check Business Logic based on the knowledge scripting technology.
|
The instance aggregation check business logic allows you to define rules that are taken into account everytime an instance aggregation operation is about to be performed, to actually continue or cancel this instance aggregation operation processing.
The instance aggregation operation means: a PLM instance (respectively a PLM representation instance) is created and is aggregated under a PLM reference (respectively a PLM representation reference).
The instance aggregation check business logic is launched everytime an interactive command or a programming interface (API) tiggers an instance aggregation operation. This is illustrated below:
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.
This section describes the objects defining the PLM opening: its global information, its kind of input object, its context object parameters.
PLM Opening ID | PLMInstanceAggregationCheck |
---|---|
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.
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 |
---|
PLMCoreReference |
PLMCoreRepReference |
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 |
---|---|---|---|
ReferenceToInstantiate | PLMEntity | Read | Pointer to the PLM reference to be instantiated (See [Fig.2]) |
Let's implement the following rule: the aggregation of an instance under a reference of PLM type MySampleType is allowed if and only if this instance is instantiated from a reference of PLM type MyGoodType.
The figure hereafter illustrates both conclusive situations:
To achieve this particular business logic implementation, a CATRuleExit file, known as family, declares the script to run everytime a PLM instance is about to be aggregated under a PLM reference of the PLM type MySampleType:
<Scripts> <Script OpeningID="PLMInstanceAggregationCheck" Type="MySampleType" ScriptName="CATMyFirstInstAggrCheckRule" /> </Scripts>
This family tells to run the script CATMyFirstInstAggrCheckRule whenever a PLM instance aggregation operation is launched with a PLM reference of PLM 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 PLM type MySampleType is allowed if and only if this instance is instantiated from an other 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.
None
Version: 1 [July 2007] | Document created |