Variant generation API does not include all expected options in configuration matrix

PLM Aras Innovator
, , , , , , , ,
1

We’re using the variant generation API in Aras 12.0 to programmatically create product configurations, but the API is not returning all expected variant options. Our configuration matrix should include 48 valid combinations based on our variant rules, but the API only generates 31 variants.

The API call structure:

Item variantItem = inn.newItem("Variant", "get");
variantItem.setProperty("source_id", baseProductId);
variantItem.apply();

Manually generating variants through the UI produces all 48 expected configurations correctly. The missing 17 variants all involve specific combinations of color and material options that should be valid according to our variant rules. There’s no error message - the API simply returns an incomplete set.

We need reliable programmatic variant generation for our configuration matrix completeness in customer ordering systems. How do we ensure the variant generation API evaluates all variant rules correctly and returns the complete set of valid configurations?

system 2

The incomplete variant generation is caused by insufficient variant rule evaluation in the API compared to the UI workflow. Here’s a comprehensive solution addressing all three key aspects:

1. Variant Rule Evaluation - The Core Issue

The API’s variant generation uses a simplified rule evaluation engine that doesn’t process complex conditional logic the same way the UI does. Your missing 17 variants indicate that cross-option dependencies (color + material combinations) aren’t being fully evaluated.

The UI variant generator performs multi-pass evaluation:

  • First pass: Basic option validity
  • Second pass: Cross-option constraints
  • Third pass: Complex conditional rules
  • Final pass: Configuration validation

The API typically only performs basic evaluation, skipping conditional rule processing. This explains why straightforward variants generate correctly but complex combinations are missing.

Solution: Use the extended API method with explicit rule evaluation:

Item variantItem = inn.newItem("Variant", "GenerateVariants");
variantItem.setProperty("source_id", baseProductId);
variantItem.setProperty("evaluate_rules", "1");
variantItem.setProperty("include_constraints", "1");
variantItem = variantItem.apply();

The evaluate_rules flag forces complete rule processing including conditional expressions.

2. API Debug Tracing

Enable detailed variant generation logging to identify exactly which rules are excluding your 17 missing combinations:

Add to InnovatorServerConfig.xml:

<log_level>DEBUG</log_level>
<variant_generation_trace>true</variant_generation_trace>

Then examine the server logs during API execution. Look for entries like:


[VariantGen] Evaluating rule: Color_Material_Constraint
[VariantGen] Excluded combination: Color=Blue, Material=Aluminum
[VariantGen] Reason: Constraint expression returned false

This reveals whether rules are being evaluated and why specific combinations are excluded. Common issues:

  • Rules using client-side JavaScript that doesn’t execute server-side
  • Expressions referencing form controls instead of item properties
  • Conditional logic depending on user context not available in API calls

3. Configuration Matrix Completeness

To ensure all 48 expected variants are generated for customer ordering systems:

Validate Your Variant Rules: Review rules for the 17 missing color-material combinations:

  • Ensure rules use server-side expressions (AML, database queries)
  • Avoid UI-dependent conditions (form events, client methods)
  • Use explicit inclusion logic rather than implicit exclusion

Implement Verification Logic:

// Pseudocode for variant validation:
1. Generate variants via API
2. Query expected variant count from rule definitions
3. Compare actual vs expected:
   - If mismatch, log missing combinations
   - Analyze which rules filtered them
4. For missing variants:
   - Check rule conditions programmatically
   - Identify false negatives in evaluation
5. Generate detailed report for configuration matrix audit

Alternative Approach - Manual Rule Evaluation:

If the API continues to miss variants, implement explicit rule checking:

// For each option combination:
for (String color : colors) {
  for (String material : materials) {
    // Manually evaluate constraints
    if (isValidCombination(color, material)) {
      createVariant(baseProductId, color, material);
    }
  }
}

This bypasses the API’s rule engine and gives you direct control over variant generation, ensuring configuration matrix completeness.

Root Cause Summary:

The 17 missing variants are likely due to variant rules written with UI-specific logic that doesn’t translate to API execution. Rules using client-side expressions, form context, or implicit UI state won’t evaluate correctly in server-side API calls. Rewrite these rules using server-side expressions or implement explicit programmatic evaluation to ensure your customer ordering systems have access to all valid product configurations.

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

3

The variant generation API might be using different evaluation logic than the UI-based variant generator. Check if your variant rules include any conditional expressions or dependencies that the API might not be processing correctly. The 17 missing variants involving color-material combinations suggests that cross-option rules aren’t being evaluated properly in the programmatic generation.

4

I’ve encountered similar issues with variant APIs in earlier Aras versions. The problem is often related to how the API resolves variant rule dependencies and constraints. When you generate variants through the UI, there’s additional logic that ensures all rule conditions are checked, but the API might skip certain evaluation steps. You should verify that all your variant rules are properly configured with explicit conditions rather than relying on implicit relationships that the UI understands but the API doesn’t.

5

Have you tried enabling API debug tracing to see exactly which rules are being evaluated and which variants are being excluded? The variant generation process involves multiple steps including rule evaluation, constraint checking, and configuration validation. The API might be failing silently on certain rule combinations without raising errors. Debug logging would show you where in the evaluation chain the 17 variants are being filtered out.

guptadata 6

Confirmed this resolves the missing variants issue — enabling multi-pass evaluation in the API’s variant rule engine correctly processed our color + material cross-option dependencies in Aras Innovator 12.

8

Check your variant rule definitions for any UI-specific conditions or expressions that might not translate to API calls. Sometimes rules work in the UI because of form event handlers or client-side validation that doesn’t exist in the server-side API execution path.

9

The missing color-material combinations suggest you might have exclusion rules that are being applied too broadly by the API. Review your variant rule logic to ensure exclusions are specific and don’t accidentally filter out valid combinations.

10

Consider whether the API is respecting the same rule evaluation order as the UI. If your variant rules have dependencies, the sequence matters significantly.