About PLM Customization by Rules | ||||||
|
| |||||
PLM System Openness
This section provides you with more information about PLM System Openness.
The PLM system consists in a full set of building blocks that make PLM. It includes the server data modeler, the server core mechanisms, the client core meta-modeler, the PLM modelers ( Product, Config, ...), and the user interface.
The PLM system is delivered with a set of pre-defined opennesses for you to integrate its specific processes.
Easy Openness
The implementation of a PLM Opening is performed through rules. A rule is the description of the behavior alteration in the Enterprise Knowledge Language (EKL). EKL is an interpreted language that manipulates variables, constants, operators, attribute accessors, functions and keywords through a strict grammar.
Safe Openness
The PLM System triggers the rule with a customization intent. There are three types of intents:
- for validation: Used to validate the state of an object, or an action on an object. For consistency maintaining, every possible rule for the couple <object type, opening> will be executed in an undetermined order. For the validation to be correct, every possible rule must be correct.
- for computation: Used to compute a result from the state of an object. Only the best possible rule for the couple <object type, opening> is executed (best meaning closest, regarding the type).
- for execution: the object can be modified by the rule. Only the best possible rule for the couple <object type, opening> is executed (best meaning closest, regarding the type).
PLM Openness in Details
This section provides you with more information about PLM Openness in Details.
Rule Contents
A rule works on a set of typed variables with a name. Starting from those three variables, the rule will navigate through the objects thanks to the EKL language.
ThisObject
- This is the main object on which the rule is acting (the input object). The Knowledge type of this variable depends on the object passed at runtime (it may be a customized PLM type).
- This variable provides access to the attributes of the object. In "execution" mode, attributes may be modified by the rule whereas in "validation" or "computation" usage, attributes can only be read by the rule.
Parameters
- This is a standard object that provides contextual information about the opening. This is the context object. In the rule, it is called Parameters because its role is to provide access to parameters. This variable has the following type: RuleContext. This type inherits the basic Feature type and holds six attributes: UserID, Role, Project, Organization, Severity and Message.
- The first one is the user ID (a string in read only mode).
- The second, third and fourth ones are the security context selected at login (strings in read only mode).
- The Severity is an integer that can be valuated inside the rule, especially meaningful in the context of the validation opening. By default, the severity is set to 1. It can be valuated in the rule to specify a higher severity. It can be interpreted in different ways depending on the opening. The caller of the opening will use this severity to determine if the validation completely prevents the action, or if it will just raise a warning. It is recommended to set the severity to 1 to raise a warning and to 2 to indicate that the severity is higher and does not allow the operation.
- The Message is a string that can be valuated inside the rule to bring back messages to the end-user. It is meaningful especially in the context of the validation opening.
- The parameters are not available as attributes of the RuleContext. They are available as dynamic attributes through the ->GetAttribute**(parameter1) and > SetAttribute**(parameter1,value) methods of the EKL.
Validation
- If the rule is used by the opening as a validation, an additional variable Validation of Boolean type will be available within the rule. The rule writes its value to express the validation.
- The Message attribute of Parameters will be set or not inside the rule. If it is set, the standard failing message will be replaced by the one set inside the rule.
Examples
You can find examples:
Example 1
The rule below enables you to customize the alias of a PLM Component.
In this script:
- The attributes of the input object (ThisObject.V_Use) are read.
- The standard attributes of the Parameters (Parameters.UserId) are read.
- A parameter called Alias is created using the SetAttributeString function.
Rule Family
To express the fact that for a given opening, several scripts can be attached depending on the type of the input object , the administrator can deliver rules families. Rules families are files suffixed .CATRuleExit located in the runtime view.
The .CATRuleExit file has the following syntax:
It makes the relationship between an opening ID, a type of the input object, and the script that must be executed if the input object is of this given type.
Important:
All the .CATRuleExit files are concatenated tobuild a global dictionary, in order to manage the inheritance for these definitions. The script of the closest type in the hierarchy is executed. Some conditions can be specified. They apply to some values of the opening parameters (f the parameter equals something, a script is chosen, and another script is chosen if the parameter equals something else). The strategy for finding the script consists in:
|