I’m working on automated MBOM rollup using Agile SDK scripting, and I’m encountering a NullPointerException when the script tries to update custom attributes on MBOM items. The script works fine for standard attributes but fails when processing custom fields.
The error occurs specifically during custom attribute handling in SDK when rolling up quantities from child items. I’ve verified that null value and type validation is in place, but the script still crashes.
IItem mbomItem = (IItem) session.getObject(IItem.OBJECT_TYPE, itemNumber);
Object customValue = mbomItem.getValue(Constants.ATT_CUSTOM_ROLLUP);
mbomItem.setValue(Constants.ATT_TOTAL_QTY, calculatedQty);
The exception points to the setValue operation. Has anyone dealt with custom attribute handling in automated MBOM rollup scripts? I need to ensure proper null handling while maintaining the rollup logic.
This is blocking our automated MBOM sync process across multiple product lines.
Yes, runtime checks are essential. The SDK doesn’t automatically handle missing attributes like the UI does. You also need to consider that custom attributes might be class-specific, so if your MBOM hierarchy includes items from different classes, not all will have the same custom attributes available. Use hasAttribute() or check the attribute collection before attempting setValue operations.
I had the exact same issue last year. Here’s the comprehensive solution that addresses all three key areas:
Custom Attribute Handling in SDK:
The core problem is that SDK requires explicit attribute validation that the UI handles automatically. You need to verify attribute existence before any setValue operation.
Null Value and Type Validation:
Implement defensive checks at multiple levels:
if (mbomItem.hasAttribute(Constants.ATT_CUSTOM_ROLLUP)) {
Object customValue = mbomItem.getValue(Constants.ATT_CUSTOM_ROLLUP);
if (customValue != null) {
mbomItem.setValue(Constants.ATT_TOTAL_QTY, calculatedQty);
}
}
Automated MBOM Rollup Scripting:
For robust rollup automation, wrap your processing in a validation framework:
- Pre-validate all items in the MBOM hierarchy have required custom attributes
- Build a validation map tracking which items can be processed
- Process only validated items, log skipped items for manual review
- Use batch commits (every 50 items) to prevent transaction timeouts
- Implement retry logic for transient failures
The key insight is that custom attributes in SDK behave differently than standard attributes. Standard attributes are guaranteed to exist on all instances of a class, but custom attributes might be conditionally applied based on subclass or configuration. Always use hasAttribute() before getValue() or setValue() when dealing with custom fields.
For your specific case, add attribute existence checks before the rollup calculation phase. If an item lacks the required custom attribute, either skip it with a warning or apply a default value based on your business rules. This approach has handled MBOM hierarchies with 10,000+ items across mixed classes without failures.
Also consider adding an initialization phase to your script that ensures all items in scope have the required custom attributes populated, even if just with default values. This prevents mid-process failures and makes the rollup logic cleaner.
Thanks for the suggestions. I checked the class definition and the attribute exists with correct data type (numeric). The problem seems to occur only when processing certain MBOM items. I added logging and discovered that some items have the custom attribute field completely null (not just empty value). Should I be checking attribute existence at runtime before trying to set values?
I’ve seen this before. The issue is likely that your custom attribute isn’t properly initialized in the MBOM class. Check if the attribute exists in the class definition and verify its data type matches what you’re trying to set. SDK is stricter about type validation than the UI.