Best practices for configuring option classes and rules in variant management

PLM Oracle Agile PLM
, , , , , , , ,
1

I’m looking for insights on structuring option classes and configuring variant rules in Agile 9.3.4. Our product line has grown significantly, and we’re starting to see performance issues with variant configuration validation. We currently have about 45 option classes with roughly 300 variant rules managing exclusions and inclusions.

The main challenges we’re facing:

  • Rule dependency chains that are becoming difficult to maintain
  • Validation times increasing as we add more options
  • Conflicts between exclusion and inclusion rules that aren’t caught until runtime

I’m curious how others have structured their option class hierarchies for complex product families. Do you organize by functional area, physical assembly, or some other taxonomy? And what’s your approach to managing rule dependencies - do you use a formal methodology or documentation system to track which rules depend on others?

We’re also seeing cases where exclusion logic conflicts with inclusion requirements, creating invalid configurations that pass initial validation. How do you test your rule sets comprehensively before deploying to production?

system 2

Validation latency and runtime conflict escapes at your rule/option scale are classic symptoms of unindexed rule evaluation order and overlapping constraint scopes in Agile PLM’s variant engine.

Diagnostic Steps

  1. Pull the AgilePLM server log (agile.log) filtered for VariantValidation and RuleEngine tokens during a slow validation cycle — identify whether latency spikes correlate with specific option class traversals or rule chain depth.
  2. In Java Admin Console, check thread pool exhaustion under Server > Performance Monitor during validation load; sustained queue depth > 5 on the rule evaluation thread pool indicates a tuning gap.
  3. Export your full ruleset via px.jar or the SDK and run a dependency graph analysis — map every inclusion rule’s triggering conditions against exclusion rule predicates to surface bidirectional conflicts programmatically before they hit runtime.
  4. Identify circular dependency chains by tracing rules where Option A excludes B, B requires C, and C requires A — Agile 9.3.x does not always trap these at save time (verify in your version).
  5. Review option class hierarchy depth. Nesting beyond 4–5 levels compounds traversal cost non-linearly with 300+ rules.

Tuning Parameters (verify paths/values in your version)

agile.properties or Java Admin:
  variant.rule.cache.size         → increase from default 512 to 2048
  variant.validation.timeout.ms   → set explicit ceiling, e.g., 15000
  option.class.preload.enabled    → true (preloads hierarchy at session init)

JVM (appserver startup):
  -XX:MaxPermSize=512m             (if pre-JDK8 stack)
  -Xms2g -Xmx4g                   (tune to your heap headroom)
  -XX:+UseG1GC

Structural Recommendations

Organize option classes by functional domain (electrical, mechanical, software), not physical assembly — this naturally partitions rule scope and reduces cross-class dependency chains. Assign each rule an explicit priority index and document its dependency tier (T0 = standalone, T1 = depends on one class, T2+ = cross-class). Enforce a rule that inclusion rules always have higher priority than conflicting exclusion rules within the same domain to catch conflicts at authoring time.

For pre-production validation, build a combinatorial test matrix using the SDK to iterate known-valid and known-invalid configurations programmatically — manual testing at 300 rules is insufficient coverage.

Monitoring Check

After tuning, baseline validation time per configuration via a synthetic test harness hitting 10–15 representative configurations. Target < 3 seconds end-to-end; regression-test this after every ruleset deployment using a version-controlled snapshot of your rule export.

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

3

We organize option classes by assembly hierarchy first, then by feature type within each assembly. This keeps related options grouped logically. For rule dependencies, we maintain a separate documentation matrix in Excel that maps which rules reference which option classes. It’s manual but helps catch circular dependencies early.

4

One thing that helped us was limiting the depth of rule dependencies. We have a policy that rules can only reference options at the same level or one level up in the hierarchy. This prevents the deep dependency chains that cause performance problems. We also batch-test configurations using a script that generates all valid permutations based on the rules, which helps catch conflicts before they hit production.

5

For exclusion/inclusion conflicts, we use a layered approach. Exclusion rules are defined at the option class level and apply globally, while inclusion rules are specific to configuration contexts. This hierarchy prevents most conflicts. We also run a weekly validation job that tests all active rules against a baseline set of configurations to identify any new conflicts introduced by recent changes.

6

Have you looked at using option families to group related classes? We reduced our rule count by about 30% by consolidating similar options into families and applying rules at the family level rather than individual options. This also improved performance since the rule engine has fewer evaluations to perform. The key is identifying which options truly behave the same way across all configurations.

7

I’d recommend implementing a formal change control process for variant rules. We require that any new rule or modification go through a review that includes dependency analysis and conflict testing. We also version our rule sets so we can roll back if issues arise. Documentation is critical - we use a rules repository that links each rule to its business justification and affected product families.

8

Based on my experience implementing variant management across multiple industries, here’s a comprehensive approach addressing your focus areas:

Option Class Structuring: The most effective structure uses a three-tier hierarchy: Product Family → Assembly Group → Feature Options. This balances maintainability with flexibility. For your 45 option classes, I’d recommend consolidating into 8-10 product families, each containing 3-5 assembly groups. Within each assembly group, define feature options that are mutually exclusive or complementary.

Use naming conventions that reflect the hierarchy: PF_[Family]AG[Assembly]OPT[Feature]. This makes dependencies immediately visible and prevents accidental cross-family rule creation. Also leverage option class attributes to tag options by type (mechanical, electrical, software) - this enables bulk rule operations and simplifies testing.

Rule Dependency Management: Implement a dependency matrix in your configuration documentation that maps:

  • Parent-child option relationships
  • Rule precedence levels (1=global exclusions, 2=assembly-level rules, 3=feature-specific inclusions)
  • Impact scope (which product families each rule affects)

For your 300 rules, audit them to identify circular dependencies using a graph analysis tool. We found that about 20% of rules in complex systems are redundant or can be consolidated. Create a rule template library for common patterns (mutual exclusion, conditional inclusion, quantity constraints) to ensure consistency.

Establish a rule governance process: new rules require dependency analysis, conflict testing, and performance impact assessment before deployment. Use the Admin Console’s rule simulation feature to test individual rules against known valid configurations.

Exclusion/Inclusion Logic: The conflict between exclusions and inclusions typically occurs when rules operate at different hierarchy levels. Implement this precedence order:

  1. Global exclusions (safety/regulatory)
  2. Assembly-level exclusions (physical incompatibility)
  3. Feature-level inclusions (required combinations)
  4. Optional inclusions (recommended combinations)

Document each rule with its business justification and precedence level. When conflicts arise, higher precedence rules always win. Use rule attributes to tag the conflict resolution strategy.

For comprehensive testing, create a configuration test suite with these scenarios:

  • Minimum viable configuration (fewest options)
  • Maximum configuration (all compatible options)
  • Boundary cases (options at rule limits)
  • Historical problem configurations

Run this suite in a staging environment before any rule deployment. We also implemented automated weekly validation that generates random configurations and flags any that violate rules or create conflicts.

Performance Optimization: For your validation performance issues, consider:

  • Indexing option class attributes used in rule conditions
  • Caching frequently evaluated rule results
  • Implementing rule short-circuiting (stop evaluation when outcome is determined)
  • Breaking complex rules into simpler component rules that evaluate faster

Monitor rule evaluation times and set performance thresholds. Any rule taking >500ms to evaluate should be refactored or split.

This structured approach reduced our rule count by 35%, improved validation performance by 60%, and virtually eliminated runtime conflicts. The key is treating variant rules as code that requires proper architecture, testing, and change management.