Mobile SDK part creation fails with duplicate number error despite unique input in part management module

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

We’re experiencing a critical issue with our mobile application that creates parts using the Agile SDK. When users attempt to create new parts through the mobile interface, they randomly receive duplicate part number errors even though the numbers are freshly generated and should be unique.

The mobile SDK session appears to be properly initialized, and the same part creation logic works flawlessly from our desktop application. The error specifically states the part number already exists, but when we check the database, no such part exists. This is blocking our mobile part creation workflow completely.

IAgileSession session = AgileSessionFactory.createAgileSession(params);
IItem newPart = (IItem) session.createObject(ItemConstants.CLASS_PART, partNumber);
newPart.setValue(ItemConstants.ATT_TITLE_BLOCK.DESCRIPTION, description);
newPart.save();
// Fails with: Part number P-2024-0156 already exists

We’ve verified the part numbers are unique before creation. Could this be related to server-side validation caching or perhaps event listeners interfering with the mobile SDK session? Any insights would be greatly appreciated.

2

Let me provide a comprehensive solution addressing all three aspects: mobile SDK session management, server-side uniqueness validation, and PX/event listener side effects.

Root Cause Analysis: Your issue combines session reuse problems with event listener state management. When mobile SDK sessions persist across multiple operations, the server-side validation cache isn’t cleared, and your custom ERP validation listener maintains state that causes false duplicate detections.

Solution - Mobile SDK Session Management: Implement a session refresh pattern for mobile part creation operations:

public IItem createPartMobile(IAgileSession session, String partNumber, String desc) {
    session.refresh(); // Clear validation cache
    IItem newPart = (IItem) session.createObject(ItemConstants.CLASS_PART, partNumber);
    newPart.setValue(ItemConstants.ATT_TITLE_BLOCK.DESCRIPTION, desc);
    return newPart;
}

Server-Side Uniqueness Validation: The duplicate check happens at multiple levels. Agile’s internal validation runs first, then your event listener. The session refresh clears Agile’s validation cache. For optimal performance with long-lived mobile sessions, call refresh() only before part creation operations, not on every API call.

PX/Event Listener Side Effects: Your ERP validation listener needs modification to be stateless:

  1. Remove any class-level caching or static variables
  2. Ensure each validation request to ERP is independent
  3. Add proper exception handling that doesn’t mask validation errors
  4. Consider implementing a request-scoped cache key using session ID + part number

Here’s the corrected listener pattern:

// Pseudocode - Event listener validation:
1. Extract session context (session.getSessionID())
2. Build cache key: sessionID + partNumber + timestamp
3. Query ERP with timeout (max 2 seconds)
4. Return validation result without caching
5. Log validation outcome for audit
// Avoid: static Map<String,Boolean> cache - causes cross-session pollution

Additional Recommendations:

  • Implement connection pooling for ERP validation calls to avoid timeouts
  • Add logging around session.refresh() calls to verify execution
  • Monitor server-side validation cache metrics (if available in 9.3.4)
  • Consider upgrading to 9.3.6+ where mobile SDK session handling was improved
  • Set session timeout parameters explicitly in mobile app configuration

Testing Approach:

  1. Test with session.refresh() before each createObject call
  2. Verify listener doesn’t hold state between invocations
  3. Load test with concurrent mobile users creating parts
  4. Monitor server logs for validation cache hits/misses

This solution addresses the immediate blocking issue while maintaining mobile app performance. The session refresh overhead is minimal (under 50ms typically) compared to the full session recreation cost.

3

Thanks for the suggestions. We are reusing sessions across multiple part creation requests to improve performance - each mobile user maintains a session for their entire login period. I didn’t realize this could cause validation caching issues.

Regarding PX extensions, we do have a custom event listener on part creation that validates against our ERP system. Could that be caching part numbers somehow? The listener runs on the server side and checks external systems before allowing part creation.

4

Building on previous responses, I’d add that mobile SDK sessions in 9.3.4 have a known behavior where validation state isn’t properly cleared when reusing sessions. Oracle addressed similar issues in later patches, but for your version, you need to work around it programmatically. Consider implementing a session refresh pattern specifically for mobile clients.

5

I’ve seen similar behavior with mobile SDK implementations. The issue often stems from how the mobile session handles uniqueness validation differently than desktop sessions. When you create the session, are you explicitly setting the session context parameters? Mobile sessions sometimes inherit cached validation states from pooled connections.

Also check if you have any custom PX (Process Extensions) or event listeners that might be triggering on part creation. These can sometimes cache part numbers during validation phases and cause false duplicate errors.

6

Your ERP validation listener is likely the culprit. If it’s caching validation results or maintaining state between invocations, it could report false duplicates. Event listeners in Agile run in the server’s transaction context, and if your listener holds any static references or caches, those will persist across multiple mobile SDK calls using the same session.

Check your listener implementation for any class-level variables or caching mechanisms. Also verify the listener properly handles exceptions - if it throws an error that gets swallowed, Agile might interpret it as a duplicate validation failure.

7

This looks like a session lifecycle issue. Mobile SDK sessions need explicit cleanup between operations. Are you properly closing and recreating sessions for each part creation request, or reusing a single session across multiple operations?

The error message suggests the server thinks the part exists in the current transaction context. Try adding session.refresh() before the createObject call, or better yet, ensure each mobile request gets a fresh session instance. Session pooling in mobile contexts can lead to stale validation caches.

8

I’d recommend adding explicit transaction boundaries in your mobile SDK code. Between part creation attempts, commit the transaction and start fresh. Also, implement proper session cleanup:

try {
    session.refresh();
    IItem newPart = (IItem) session.createObject(...);
} finally {
    session.commit();
}

This ensures the server-side validation cache gets cleared between operations.