More about the Process for the Administrator

This page provides you with more information about performing the customization, as the administrator.

Related Topics
About the Business Rule Editor
About PLM Customization by Rules

Methodology

An on-site administrator writes rules and plugs them to the PLM openings thus altering the behavior of the PLM system. This will be achieved as follows:


  1. Each opening is documented to explain its intent, what are the kinds of input objects that it manipulates, and what are the context parameters accessible from the rules. It also indicates if the opening is done on the Server or on the Client. Each opening has a PLM Opening ID.
  2. The administrator writes a rule compliant with the EKL syntax, manipulating the input object and the context object as variables, and he saves it in an intel_a/resources/knowledge/scripts/PLMOpeningID.CATRule file (in the server runtime view or in the client runtime view depending on the opening).
  3. The administrator tests the behavior of his PLM system that takes the rule customization into account. If the rule syntax is incorrect, a message is displayed explaining the problem. The administrator modifies the rule and tests it again.
  4. When satisfied with the customization, the administrator deploys the customization on the server or on the clients by deploying the runtime view.
  5. Finally, it is possible to describe a higher flexibility in the choice of the script for a given opening, thanks to the definition of a family.

On the User Side

The administrator activates environment variables before running PLM:

CKE_CUSTO_TRACES=1: Variable used to have traces generated by the PLM customization engine, explaining the problems encountered: scripts not found, scripts not valid syntactically, scripts failing at runtime for example.

Note: If the Trace function or the Message function is used in the script, the string passed to those functions will be traced too.

CKE_CUSTO_TRACES_RESTRICTION: Variable used to specify the PLM Opening ID to be traced and possibly the Type of the objects to be traced. It is also possible to provide a list of couples (OpeningID/Type of fact). To set the environment variables, separate the strings using a ';'.

CKE_CUSTO_DYNAMIC=1: variable used to get a "live" behavior of the PLM customization engine: You can modify both scripts and families at runtime, without exiting the PLM application. The new rules will be taken into account. By default, and for the final user, this is not a desired behavior to ensure disk access optimizations. No access to the database, CATRule{Exit} files only.

The list of traces raised by the customization engine when the traces are activated is the following:

Business Rules execution: <OpeningID>: Indicates at the beginning of the execution which opening is triggered.

Business Rules validation: <OpeningID>: Indicates at the beginning of a validation exit which opening is triggered.

Operation validated. Additional message added within the script: <Message>.

Operation not validated. Additional message added within the script: <Message>.

Operation validated. Additional message added within the script: <Message>.

Operation not validated. Additional message added within the script: <Message>.

Business Rules computation: <OpeningID>: Indicates at the beginning of a computation exit which opening is triggered.

Business Rules execution re-directed to script <ScriptName>>: indicates that the family has redirected the execution to a given script

Business Rules execution re-directed to script <ScriptName>: Indicates that the family has redirected the execution to a given script.

Business Rules execution failed because script <ScriptName> was not found in the runtime environment: Indicates at the end of the script execution that no script was associated to the OpeningID.

Business Rules execution failed because the syntax of the script <ScriptName> is invalid: <SyntaxErrorMessage>: Indicates that the syntax of the script is invalid and shows the syntax error message.

Business Rules execution failed because script <ScriptName> execution produced an evaluation error: <EvaluationErrorMessage>:: Indicates that the evaluation of the script raised an error and shows the evaluation error message.

The context of the business rules is (name=<Name>, user=<UserID>, security=<SecurityContext>.: Provides information about the parameters of the opening.

Business Rules testing opening: <OpeningID> succeeded: Traces the testing of the opening.

Business Rules testing opening: <OpeningID> failed: Traces the testing of the opening.

Trace raised: <Traces>: traces the message passed to the Trace function.

Message raised: <Message>: traces the message passed to the Message function.

Trace raised: <Traces>: Traces the message passed to the Trace function.

Message raised: <Message>: Traces the message passed to the Message function.

Redirection file read : <Name of the .CATRuleExit file>.

Script file read : <ScriptName>.

Script file not found or readable : <ScriptName>.

Misplaced condition in redirection file <Name of the .CATRuleExit file>.

Invalid tag <an XML tag> in redirection file <Name of the .CATRuleExit file>.

Invalid attribute(s) for tag <an XML tag> in redirection file <Name of the .CATRuleExit file>.

Opening <OpeningID> for type <Type> to script <Name of the .CATRule file> with condition <a condition> is eligible.

Opening <OpeningID> for type <Type> to script <ScriptName> with condition <a condition> has been rejected.

Opening <OpeningID> with condition <a condition> has been selected because of greater accuracy (= level of accuracy).