I’ve debugged this exact issue multiple times. Here’s the comprehensive solution covering all three configuration aspects:
1. Validation Rule Event Triggers:
The core issue is that check-in and revise are distinct lifecycle events with different trigger points:
Navigate to your validation rule configuration:
- Go to Validation Management > Rules > [Your Rule Name]
- Edit the rule properties
- In the ‘Event Triggers’ section, you need to add multiple events:
Check In - for initial check-in of new partsRevise - for creating new revisionsUpdate - for in-place updates to checked-in objectsPromote - if you want validation at state transitions
The key insight: ‘Check In’ only fires when an object transitions from checked-out to checked-in state. When you revise an object, you’re creating a new iteration, which triggers the ‘Revise’ event instead.
For comprehensive coverage, configure your rule to trigger on all relevant events:
Trigger Events: [Check In, Revise, Update, Promote]
Execution Timing: Before (to block invalid operations)
2. Check-in vs. Revise Events:
Understanding the event lifecycle is critical:
Check-In Event:
- Fires when: User checks in a checked-out object
- Object state: Transitions from checked-out to checked-in
- Typical scenario: Completing edits on an existing revision
- Event context: Has working copy context
Revise Event:
- Fires when: User creates a new revision (new iteration)
- Object state: New iteration created, typically in IN_WORK state
- Typical scenario: Creating B revision from A revision
- Event context: Has both previous and new iteration context
Your validation rule must handle both contexts. Update your rule’s event handler code if you have custom validation logic:
For Java-based validation:
public class CADValidationRule implements ValidationRule {
@Override
public ValidationResult validate(Validatable target, ValidationEvent event) {
// Handle both check-in and revise events
if (event.getType() == ValidationEvent.CHECKIN ||
event.getType() == ValidationEvent.REVISE) {
return performValidation(target);
}
}
}
For expression-based validation rules, ensure your applicability expression doesn’t inadvertently filter out revisions:
- Avoid:
iteration.version.identifier = 'A' (only matches first revision)
- Use:
iteration != null (matches all revisions)
- Avoid:
state = 'IN_WORK' (revisions might start in different state)
- Use:
state != 'CANCELLED' (more flexible state checking)
3. Rule Configuration:
Complete rule configuration checklist:
Applicability Settings:
- Object Type: Include all CAD document types (WTPart, CADDocument, etc.)
- Context: Ensure rule applies to all relevant product contexts
- Lifecycle State: Don’t restrict to specific states unless necessary
- Iteration: Remove iteration-specific conditions
Validation Logic:
Structure your validation to work regardless of how the object was created:
- Check required attributes on the current iteration (not working copy)
- Validate naming conventions against the object’s current name
- Don’t assume specific iteration patterns (A.1, B.1, etc.)
Execution Settings:
- Priority: Set to HIGH (e.g., 100) to execute before modification rules
- Blocking: Enable ‘Block operation on failure’ to prevent invalid check-ins/revisions
- Error Handling: Configure clear error messages that specify what failed
Advanced Configuration for Revisions:
If you need different validation logic for revisions vs. new parts:
Rule 1: CAD Validation - New Parts
Trigger: Check In
Condition: iteration.version.identifier = 'A'
Validation: [Strict validation for new parts]
Rule 2: CAD Validation - Revisions
Trigger: Revise
Condition: iteration.version.identifier != 'A'
Validation: [Validation for changes, may be less strict]
Testing the Configuration:
-
Test new part check-in:
- Create new part, check out, make changes, check in
- Verify validation rule executes and blocks if validation fails
-
Test revision creation:
- Select existing part, create new revision
- Verify validation rule executes during revision creation
- Try to save revision with invalid data, confirm it’s blocked
-
Test revision check-in:
- Check out the new revision, make changes, check in
- Verify validation executes on this check-in as well
Common Issues and Solutions:
- Rule not firing at all: Check that rule is Active and not Suspended
- Rule fires but doesn’t block: Verify ‘Block operation’ is enabled
- Rule fires on new parts but not revisions: Add Revise event trigger
- Rule execution errors: Check method server logs for validation exceptions
- Performance issues: If validation is slow, consider async validation for non-critical checks
Monitoring:
Enable validation rule logging to diagnose issues:
- Add to log4j.properties: `log4j.logger.wt.validation=DEBUG
- Monitor validation execution: Check MethodServer logs for rule execution traces
- Review validation results: Check Validation Management > Audit Trail
After implementing these changes, test thoroughly with both new parts and revisions to ensure validation consistently triggers across all scenarios. The key is understanding that different operations trigger different events, and your validation rules must be configured to handle all relevant event types.