Implementing the Policy Chooser Mechanism

As you now know, business objects are governed by policies.

Several policies may govern the same kind of business object, but only one can govern a given object. The choice of a business object's policy (and consequently its lifecycle and security aspects) may be based on creation criteria such as project or organization, for instance.

In ENOVIA V6, several default policies and one store are created by default.

Furthermore, there is no possibility to interactively choose which policy governs a given object when that object is created. Even if this were possible:


  • there would be no means of preventing a user from creating an object and associate it with the wrong policy, which would lead to corporate business process inconsistencies
  • in most cases, the choice of policy is driven by the business process, not by the user.

Furthermore, any checked-in file associated to a Business Object (for example, a VPLM representation) is stored in a store. The choice of the store may vary according to:


  • the current login context (project, organization)
  • the PLM entity type of the associated Business Object.

Consequently, because these choices are driven by the business process and not the user, they need to be automated. This is implemented via the Policy Chooser.

It allows you to specify:


  • which policy applies to a business object, according to creation criteria
  • which store must be used to store a file associated to a given Business Object.

The policy chooser capability therefore allows the ENOVIA V6 system administrator to automate the choice of policy governing an object and file stores based on your business process requirements. There is no end-user intervention in the process. As a consequence, no error resulting from the wrong choice of policy may occur.

The term policy, as used in the context of the policy chooser, has a wider meaning than the strict ENOVIA V6 policy. It must be understood as dynamic rules governing the overall system. This includes policies, of course, as well as stores.

Configuring the Policy Chooser

The policy chooser is configured via an XML file: PLMPolicyChooser.xml. This file contains two logical sections: the policy choice section and the store choice section.

The policy choice section comprises:


  • Several optional <entity> blocks, each one defining the policy choice cases for a given VPLM type.
  • A policy choice case may be conditioned by an expression (standard case: <case>) or not (<default> case).
  • A final <anyOtherEntity> block defines all cases for types that were not explicitly listed in <entity> blocs.

    The Policy Chooser manages VPLM type inheritance for policy choice.

The store choice section comprises an unnamed <stores> block, similar to an <entity> block, containing conditioned cases (<case>) and potentially a <default> case.

The PLMPolicyChooser.xml file must be deployed in the ENOVIA V6 server runtime view.

Policies referenced by the PLMPolicyChooser.xml file must be declared in the ENOVIA V6 database (using Business or MQL utilities) before any business object is created, otherwise an exception may be raised, leading to object creation failure.

Note: policy administration (using ENOVIA V6 utilities) is distinct from policy chooser administration.

When Is the Policy Chooser Invoked?

Policy choice is invoked each time a business object is created, for example in the following cases (the list is not an exhaustive:)


  • object creation (New)
  • object duplication (Duplicate)
  • inter-enterprise Import (Import As Ref).

But it is NOT invoked when versioning a business object (New Version). In this case, the object's attributes are copied, and the version number is just incremented.

Store choice is invoked each time a file associated to a business object (for example, a representation, a port or a connection) has to be saved in a vault.

File Structure

When the ENOVIA VPM Multi-Discipline Collaboration Platform is installed, the default PLMPolicyChooser.xml file is deployed in your web application path:

<application_server>/webapps/my_web_appli/WEB-INF/classes/vplm/policychoice

where my_web_appli is the name of your web application, for example ematrix or enovia.

It has a <policyChoice> root node. It may contain several <entity> blocks and one <anyOtherEntity> block for the policy section, and one <stores> block for the stores section.

<entity name="type">

This block defines all policy choice cases for a given PLM type. It may contain several standard cases (<case>) and one default case (<default>).

<case>

A case defines:


  • the policy to apply (<policy name="a_policy_name">)
  • and the condition (<condition>expression</condition>) that must be satisfied to apply the policy.

Refer to “Case Condition Syntax” for details on condition syntax.

<default>

This block is similar to the <case> block, except that there is no <condition>.

If present, this block applies if no previous case is applied.

<anyOtherEntity>

This block has the same structure as <entity>, except that there is no name. It covers all types not already covered by an <entity> block, as well as all cases where no <case> was previously matched.

<stores>

This block has the same structure as <entity>, except that there is no name. The store choice is entirely based on that block.

The condition expression of the <case> block is based on the same case condition syntax with some extensions, as the choice of a store may be also based on the characteristics of the business object associated to that file.

Case Condition Syntax

Several expression types can be mixed to define a condition expression.

Simple expression

A simple expression has the form: 

<variable> <operator> <value>
<variable>

$project if the condition is about the current security context's project

$org if the condition is about the current security context's organization

Extension for conditions of <stores> block only:

<variable> is extended to associated object's attributes, including its type using the $type variable.
<operator>

= the equal operator.

The variable MUST MATCH the string value.

!= the not equal operator.

The variable MUST NOT MATCH the string value.

in the IN operator.

The variable MUST MATCH at least one element of the following string list:

<value>

String A string enclosed in " " (double-quotes). It may contain the following characters: [A-Z], [a-z], [0-9], _(underscore), - (dash) or any space; e.g. "Car_XYZ-123 Project"

String list list of strings containing at least one element, in{} (braces) e.g.

{"Project 1", "Project Z"}

Negated expression

It has the form:

not <expression>

Logical expression

A logical expression is a combination of two or more expressions with a logical operator:

and, or

Example:

$project in {"Project ABC","Very Secret Project"} and $org = "Design"

Expressions can be enclosed in parenthesis, to limit errors due to left-to-right precedence plus combination of and & or operators.

Example:

$project = "A" or $project = "B" and $org = "C"

is equivalent to:

($project = "A" or $project = "B") and $org = "C"

Inheritance

PLM type inheritance is managed in the policy chooser (only for policy choice).

If no <entity> block was defined for a given type (or no <case> condition was matched), another <entity> block is searched in the type's hierarchy.

If no <case> condition was matched at all, the <anyOtherEntity> block is used.

In the following example, policy P1 is associated to the PLMProductDS entity, while P0 is associated to its super-type, VPMReference. The PLMPolicyChooser file would look like this:

<entity name="VPMReference">
	<default>
	<policy name="P0"/>
	</default>
</entity>
<entity name="PLMProductDS">
	<default>
	<policy name="P1"/>
	</default>
</entity>

If a PLMProductDS object is created, its policy will be P1. If a subclass of VPMReference (other than PLMProductDS) is created, its policy will be P0.

PLM type inheritance is not managed for choosing stores, but the administrator may specify conditions based on an associated object's type, explicitly using the $type variable.

Order of Appearance

The appearance order between <entity> or <anyOtherEntity> blocks does not matter. Only the inheritance tree is considered (e.g. PLMProductDS, then VPMReference, etc. up to the PLMReference, and finally, the <anyOtherEntity> block).

But, in a given block - <entity>, <anyOtherEntity> or even <store> - the case (including default) blocks are considered in their order of appearance.

As the <default> block is considered as an always TRUE condition, any <case> appearing AFTER will be purely and simply ignored.

Policy Chooser Algorithms

The following diagram explains how policy and store choice algorithms work:

If no case is matched through all <entity> or <anyOtherEntity> blocks, an exception will be raised on the ENOVIA V6 Server. This means that no policy could be associated to the object that had to be created. As no object can be created without a policy, the object creation will then fail.

This remark is also valid for files storing, when store choice fails.

As a consequence, great attention must be paid when configuring the policy chooser file.

Example

Suppose you plan to associate the VPLM_SMB_SecretProject policy to any part object (a VPMReference type, if we consider the top modeller) created in the “Secret project” project.

The entity block would be like this:

<entity name="VPMReference">
<case>
<policy name="VPLM_SMB_SecretProject"/>
<condition>$project = “Secret project” </condition>
</case>
<default>
<policy name="VPLM_SMB"/>
</default>
</entity>

Suppose now you want to store files associated to PLMRepresentationDS with:


  • SecretProjectStoreForRep store, if the current project is “Secret project”
  • StoreForRep store for the other projects.

The stores block would be like this:

<stores>
<case>
<condition>$project = “Secret project” and $type = “PLMRepresentationDS” </condition> 
<store name="SecretProjectStoreForRep"/> 
</case>
<case>
<condition>$type = “PLMRepresentationDS” and V_RepKind = “ABC”</condition> 
<store name="StoreForABCRep"/> 
</case>
<default>
<store name="plmx"/> 
</default>
</stores>

The following table shows where files associated to PLMRepresentationDS objects will be stored, depending on their characteristics:

Current project RepKind Chosen store will be:
Secret project ABC SecretProjectStoreForRep
Secret project SomethingElse SecretProjectStoreForRep
Standard ABC StoreForABCRep
Standard SomethingElse plmx