Custom variant rule not evaluated during configuration generation

PLM ENOVIA
, , , , , , , ,
1

We’ve implemented custom variant selection rules using Java extensions to handle complex product configurations. The rules work when tested in isolation, but during actual configuration generation for customer orders, they’re not being evaluated at all.

Our rule registration code:


VariantRule customRule = new CustomVariantRule();
ruleEngine.registerRule("CUSTOM_MATERIAL_RULE", customRule);

The configuration engine seems to skip our custom rules entirely and falls back to standard variant logic. This results in invalid BOMs being generated because the material compatibility checks we implemented aren’t running. The rules should filter out incompatible component variants based on material properties and environmental requirements. Is there a specific registration pattern required for custom variant rules to participate in the configuration generation workflow?

system 2

You’re dealing with three interconnected issues: rule registration mechanics, configuration context association, and Java extension deployment. Let me provide a comprehensive solution addressing all three areas.

First, proper rule registration requires more than runtime code. Your CustomVariantRule class must extend ENOVIA’s VariantRule base class and override the evaluate() method with the correct signature:

public class CustomVariantRule extends VariantRule {
  public boolean evaluate(ConfigurationContext ctx) {
    // Material compatibility logic
  }
}

The registration you showed happens at runtime but doesn’t persist. Instead, register your rule through ENOVIA’s service framework by creating a rule descriptor XML file in your extension’s config directory:

<VariantRuleDefinition name="CUSTOM_MATERIAL_RULE">
  <Implementation class="com.custom.CustomVariantRule"/>
  <EvaluationPhase>PRE_SELECTION</EvaluationPhase>
</VariantRuleDefinition>

This XML-based registration ensures your rule is discovered by the configuration engine during system initialization.

Second, configure the configuration context association. Custom variant rules must be explicitly linked to configuration contexts where they should apply. This is done through the configuration management admin interface, but for automated deployment, create a context binding file:

<ConfigurationContext name="PRODUCT_ORDER_CONFIG">
  <ActiveRules>
    <Rule name="CUSTOM_MATERIAL_RULE" priority="100"/>
  </ActiveRules>
</ConfigurationContext>

The priority value determines evaluation order relative to other rules. Higher priority rules evaluate first. For material compatibility checks that should filter options before standard variant logic, use a high priority value (90-100 range).

Third, ensure complete Java extension deployment. Your extension must be packaged as an ENOVIA service module with proper manifest entries. Create a service.xml in your extension’s META-INF directory:

<Service name="CustomVariantRuleService">
  <Implementation class="com.custom.VariantRuleServiceImpl"/>
  <Dependency service="VariantManagementService"/>
</Service>

This registers your rule service with ENOVIA’s dependency injection framework, making it available to the configuration engine across all execution contexts.

The complete deployment process:

  1. Package your CustomVariantRule class with the rule descriptor XML and service.xml manifest into a JAR file
  2. Deploy the JAR to ENOVIA’s extension directory: `/Windchill/codebase/ext/custom/
  3. Register the extension through the admin console: Site > Utilities > Extension Manager
  4. Restart the application server to load the extension
  5. In Configuration Management admin, associate CUSTOM_MATERIAL_RULE with your product configuration contexts
  6. Set the evaluation phase to PRE_SELECTION so material checks happen before variant selection

After deployment, verify the rule is active by checking the configuration engine logs during BOM generation. You should see entries like:


Evaluating rule: CUSTOM_MATERIAL_RULE
Context: PRODUCT_ORDER_CONFIG
Result: 15 variants filtered by material compatibility

If the rule still doesn’t evaluate, check these common issues:

  • Rule class constructor must be public and no-arg
  • The evaluate() method signature must exactly match the base class
  • Configuration context name in the binding file must match the context used by order processing
  • Extension JAR must be in the classpath before server startup

For your specific case with material compatibility and environmental requirements, structure your evaluate() method to access the configuration context’s product structure and variant options. The context provides methods to query component materials and filter variants based on your compatibility matrix. Make sure to log evaluation results for debugging, as rule evaluation happens deep in the configuration engine’s workflow and can be hard to trace without explicit logging.

The key insight is that ENOVIA’s variant rule framework requires explicit registration through XML descriptors and service deployment, not just runtime code registration. The configuration engine discovers rules through the service registry at startup, and only rules properly registered and associated with configuration contexts participate in BOM generation workflows.

This draft is based on general ENOVIA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Variant rule registration in ENOVIA requires more than just calling registerRule. You need to ensure your custom rule class properly extends the VariantRule base class and implements all required methods. The configuration engine only evaluates rules that are properly registered in the variant rule registry and have the correct evaluation context set.

4

Check your configuration context setup. Custom variant rules need to be associated with specific configuration contexts to be evaluated during BOM generation. If your rule isn’t linked to the context used by the order configuration process, it won’t fire. Navigate to the configuration management admin panel and verify that CUSTOM_MATERIAL_RULE appears in the active rules list for your product configuration context.

5

I suspect your Java extension deployment might be the issue. Custom variant rules need to be deployed as ENOVIA extensions with proper service registration. Simply instantiating and registering the rule in code won’t persist across server restarts or be available to the configuration engine running in different execution contexts. You need to package your CustomVariantRule as an OSGi bundle or ENOVIA service module with the appropriate service descriptors. Check if your extension is listed in the deployed services registry in the admin console. If it’s not there, the configuration engine won’t be able to discover and invoke your rule during BOM generation workflows.

plm_ck 6

Tested this on ENOVIA V6R2019x and confirming that extending VariantRule with the correct evaluate() signature finally triggered our custom material compatibility logic during configuration generation.

7

Also verify the rule evaluation order. ENOVIA processes variant rules in a specific sequence, and if your custom rule has dependencies on other rules or requires certain context data, it might be evaluated too early or too late in the workflow.

8

I checked the deployed services and my extension is listed there, so deployment seems okay. But I’m not seeing CUSTOM_MATERIAL_RULE in the configuration context’s active rules list. How do I properly associate a custom rule with a configuration context? Is there an XML configuration file I need to update?