PX script fails to create new item in configuration management

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

We’re running into a critical issue with our PX script that’s supposed to automate item creation in configuration management. The script worked fine in our test environment but started throwing NullPointerException in production after upgrading to 9.3.4.

The error occurs specifically when trying to create items with custom attributes. Here’s the relevant code section:

IItem newItem = (IItem)session.createObject(itemSubtype, itemNumber);
newItem.setValue(attributeId, attributeValue);
session.save(newItem);

The exception happens at the setValue() line. We’ve verified the attribute mapping configuration and the item subtype setup looks correct in the admin console. The PX error handling doesn’t provide much detail beyond the stack trace. This is blocking our automated item creation workflow that processes hundreds of configuration items daily. Has anyone encountered similar attribute mapping issues with PX scripts after version upgrades?

system 2

I think I know what’s happening here. We had the exact same issue after upgrading to 9.3.4. The problem is a combination of PX script error handling gaps and how the API validates attribute types now.

First, let’s address the PX script error handling. You need to add proper null checks and validation before attempting attribute assignment:

if (attributeValue != null && attributeId != null) {
    IAttribute attr = newItem.getAttributes().get(attributeId);
    if (attr != null && attr.isModifiable()) {
        newItem.setValue(attributeId, attributeValue);
    }
}

Second, the attribute mapping validation changed in 9.3.4. The API now validates that the attribute data type matches exactly. If you’re passing a String when the attribute expects an Integer or Date, you’ll get NPE instead of a type conversion error. Check your attribute definitions in the admin console under Data Settings > Attributes and verify the data type.

Third, item subtype configuration matters more now. Oracle added a validation layer that checks if attributes are properly initialized for the subtype before allowing setValue(). If your subtype has a complex inheritance chain or uses attribute groups, you need to ensure the parent classes are properly configured.

Here’s a more robust approach:

// Pseudocode - Key implementation steps:
1. Create item object with proper subtype initialization
2. Validate attribute exists and is modifiable for this subtype
3. Check attribute data type matches value being set
4. Wrap setValue() in try-catch with specific exception handling
5. Add logging to capture attribute state before assignment
6. Verify all required attributes are set before save()
// See Agile PLM SDK Guide Section 6.3 for attribute validation

The difference between test and production is likely due to different privilege sets or attribute configurations. Export your test environment’s class configuration and compare it with production. Look for differences in attribute properties like ‘Required’, ‘Enabled’, or ‘Visible’ settings.

Also enable debug logging in your PX script to capture the actual attribute values and types at runtime. Add this before your setValue() call:

logger.debug("Setting attribute: " + attributeId +
             " with value: " + attributeValue +
             " of type: " + attributeValue.getClass().getName());

This will help you identify if the issue is with the value itself or the attribute configuration. In 9.3.4, Oracle also changed how custom attributes handle null values - they’re more strict now. If your workflow allows null values in test but production has stricter validation rules, that would explain the difference.

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

I’ve seen this before. The NullPointerException usually means the attributeId isn’t resolving correctly. Did you check if the attribute API name changed during the upgrade? Sometimes custom attributes get renamed in the schema.

4

Adding to Sara’s point - also verify that the item subtype actually has the attribute you’re trying to set. In 9.3.4, Oracle tightened the validation rules for attribute assignments. You need to ensure the attribute is explicitly mapped to that subtype in the class configuration. Check the subtype’s attribute list in the Java Client admin console under Data Settings > Classes. If the attribute isn’t there, you’ll get a null reference when trying to access it through the API.

deepamaster 5

Tested this on Agile PLM 9.3.4 with a PX script creating Parts items, and adding the attr.isModifiable() check before setValue() eliminated the null pointer exceptions entirely.

6

Thanks for the suggestions. I verified the attribute API name and it matches what we’re using. The attribute is definitely mapped to the subtype - I can see it in the admin console and can set it manually through the UI. The strange part is this works in test but fails in production, both running 9.3.4.

7

Check your PX script’s error handling for the attribute value itself. If attributeValue is null or the wrong data type, setValue() can throw NPE in 9.3.4. Also, verify that the session object has proper privileges. I’ve seen cases where the PX execution context doesn’t have the required permissions to set certain attributes, especially custom ones with restricted access. Try wrapping your code with explicit null checks and type validation before the setValue() call.

8

One more thing to check - the item subtype configuration might have validation rules that weren’t there before. In 9.3.4, Oracle added stricter validation for item creation. If your subtype has required attributes that must be set before others, you’ll get NPE. The order of attribute setting matters now. Try setting all required attributes first, then the optional ones.

migueladmin 10

I verified the attribute API name and it matches what we’re using.