PX script fails to trigger conditional approval workflow for quality management

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

We’re experiencing workflow failures with a custom PX script in our quality management module. The PX is designed to trigger conditional approval workflows based on custom attribute values, but it’s throwing NullPointerException errors intermittently.

The error occurs when the PX tries to access custom attributes to determine routing logic:

String severity = (String) change.getValue("Page Three.Severity Level");
if (severity.equals("Critical")) {
    triggerWorkflow("QM_Critical_Approval");
}

This is causing significant workflow delays as quality changes get stuck in limbo. The error handling in our PX doesn’t seem to catch these cases properly, and we’re struggling to understand why the custom attribute access fails randomly. Has anyone dealt with similar PX script issues when implementing conditional workflow routing?

system 2

Here’s a comprehensive solution addressing all three focus areas:

PX Script Error Handling: First, implement robust null checking and exception handling in your PX:

try {
    ICell cell = change.getCell("Page Three.Severity Level");
    String severity = (cell != null && cell.getValue() != null) ?
                      cell.getValue().toString() : "Standard";
    // Proceed with workflow logic
} catch (Exception e) {
    logger.error("Attribute access failed: " + e.getMessage());
    triggerWorkflow("QM_Default_Approval"); // Fallback
}

Custom Attribute Access: The root cause is using getValue() on Page Three attributes during PRE events. Page Three attributes require special handling:

  • Use getCell() method instead of getValue()
  • Verify cell existence before accessing value
  • Switch to POST_UPDATE or APPROVE event handlers where attributes are guaranteed to be committed
  • For Page Two/Three attributes, always check if the cell is null and has a value

Workflow Routing Logic: Redesign your conditional routing to handle edge cases:

  1. Define a default workflow path for null/missing severity values
  2. Implement a workflow decision table in your PX configuration that maps severity levels to workflow names
  3. Add audit logging for every routing decision to track which path was taken and why
  4. Consider using Agile’s built-in workflow criteria instead of PX for simple conditional routing - it’s more reliable for attribute-based decisions

For critical quality workflows, I recommend creating a hybrid approach: use workflow criteria for basic routing (severity-based) and reserve PX scripts for complex multi-attribute logic that criteria can’t handle. This reduces the dependency on custom code for standard routing scenarios.

If you must use PX for all routing, implement a status check mechanism:

if (!isAttributeReady(change, "Page Three.Severity Level")) {
    scheduleDelayedEvaluation(change, 5000); // Retry after 5 sec
    return;
}

This ensures attributes are committed before evaluation, preventing the NullPointerException while maintaining your conditional workflow requirements.

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 pattern before. The NullPointerException suggests the custom attribute isn’t always populated when your PX executes. Check the workflow event timing - if the PX fires before attribute validation completes, you’ll get nulls. Add null checks before the equals() call to prevent the exception.

priya_func 4

“Confirmed this resolves the null pointer exceptions we were hitting when accessing Page Three custom attributes in our PX-triggered conditional approval workflow on Agile PLM 9.3.6.”

5

Mike, are you using the correct API method to retrieve custom attributes? For Page Three attributes, you should use getCell() method instead of getValue(). Also, the attribute access might fail if the user executing the change doesn’t have read permissions on that specific custom attribute. I’d recommend adding detailed logging in your PX to capture the actual state of the change object when the error occurs. Log the change number, status, and whether the attribute exists before attempting to access it. This will help you identify if it’s a timing issue or a permissions problem.

6

The intermittent nature suggests a race condition in your workflow routing logic. When multiple changes are processed simultaneously, the PX might be accessing attributes before they’re committed to the database. Consider implementing a queue-based approach where the PX validates attribute availability before proceeding with workflow triggers.

8

I worked on a similar implementation last year. The key issue was that custom attributes on Page Three aren’t always immediately accessible in PX context depending on the event type. For quality management workflows, you need to ensure the PX is triggered at the right lifecycle phase. We switched from using PRE_UPDATE to POST_UPDATE events and added a 2-second delay using a scheduled task for critical workflow routing decisions. This gave the system time to commit attribute changes before evaluation. Also, implement proper exception handling with fallback workflows - if severity can’t be determined, route to a default approval path rather than failing completely.

9

Thanks for all the suggestions. I added logging and confirmed it’s definitely a timing issue with attribute access. The PX fires before the attributes are fully committed. I’m going to try the POST_UPDATE approach Lisa mentioned.

priya_arch 10

I worked on a similar implementation last year.