About the Customization by Business Rules and Resource Sets

The system is based on an architecture merging a core model with native authoring apps covering the design, engineering, simulation and manufacturing domains. This architecture needs to be customizable on site by administrators to better match the critical behaviors of the system with the specificity of the customer business processes.

This page discusses:

See Also
About the Administrator's Process
About the Customization on the End-User Environment

Opening IDs

This section provides you with information about opening IDs.

The system is delivered with a set of pre-defined openings so that you integrate your specific processes. The implementation of an 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.

Customization Intent

The system triggers the business rule with a customization intent. There are three types of intents:

  • 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> is executed in an undetermined order. For the validation to be correct, every rule must be correct.
  • 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.
  • Execution: The object can be modified by the rule. Only the best possible rule for the couple <object type, opening> is executed.

Business Rule Creation Process

Each opening has an opening ID and must be contained in a dedicated resource table.

The steps required for an administrator to modify the default behavior of the system using business rules are the following:

  1. The administrator (or the business rule architect) creates one or several business rules for the selected opening ID. The rule body must be compliant with the EKL syntax. It manipulates the input object and the context object as variables. This rule will be a dedicated object stored in database.
    Note: For the same opening ID, several business rules can be created, according to the different possible fact types and P&O projects to which the resource sets will be bound.
  2. The administrator creates or edits an existing resource table containing the selected opening ID and assigns the created business rules to the different couples <Opening ID> | <Fact Type>.
  3. When satisfied with the customization, the administrator deploys his customization on the production server.

Business Rule Arguments

A business rule works on a set of three typed variables.

ThisObject

ThisObject is a variable that represents the object on which the rule is acting. The type of this variable is determined when creating the business rule. In execution mode, attributes may be modified by the rule whereas in validation or computation mode, attributes can only be read by the rule.

Parameters

This is a variable of RuleContext type that represents the object that provides contextual information about the opening.

Important:
  • The contextual information is not available as attributes of the RuleContext. It is available as dynamic attributes through the->GetAttribute**(parameter1) and  > SetAttribute**(parameter1,value) methods of the EKL.
  • The Message attribute of Parameters is set or not inside the rule. If it is set, the standard failing message is replaced by the one defined in the rule.

Validation (optional)

If the rule is used by the opening as a validation, an additional Validation variable of Boolean type is available in the rule. The rule writes its value to express the validation.

Examples

Example 1

The rule below enables you to customize the name of a component.

ThisObject.PLM_ExternalID =  Parameters.UserID /*Possible direct attribute notation*/
+ "_" + Parameters.GetAttributeString("IdString") /*Dynamic attribute notation mandatory*/

Example 2

The rule below checks the maturity modification.

Validation=(ToUpper (Parameters.UserID)==ToUpper(ThisObject.owner))
if (Validation==false) {
  Parameters.Message="Impossible to change the maturity state of an object that does not belong to you"
  Parameters.Severity=1
}

In the above script:

  • The Validation Boolean is valuated to determine if the change maturity operation is allowed.
  • The message is valuated to explain the origin of the problem. If you want to provide NLS messages, use the BuildMessageNLS function.