SBOM versioning fails to track revision history after bulk import via PX scripts

We’re encountering a critical issue with SBOM revision tracking after executing bulk imports through PX scripts in Agile 9.3.4. Our compliance team runs quarterly SBOM audits and discovered that revision history is completely missing for approximately 1,200 components imported last month.

The PX script successfully creates the SBOM records and establishes BOM relationships, but the revision sequencing breaks down. Here’s the relevant portion:

IItem sbomItem = (IItem)session.createObject("SBOM");
sbomItem.setValue(ItemConstants.ATT_TITLE_BLOCK_NUMBER, sbomNumber);
sbomItem.setValue(ItemConstants.ATT_TITLE_BLOCK_DESCRIPTION, description);
session.save(sbomItem);

When we check the revision history through the Agile client, these imported SBOMs show as Rev A with no predecessor links or audit trail. Manual SBOM creation works fine with proper revisioning. The Agile SDK documentation mentions revisioning parameters, but I’m unclear on the correct API calls for PX script context. Has anyone successfully implemented revision tracking in bulk SBOM imports? This is blocking our compliance audit process.

Here’s the complete solution addressing all three focus areas - PX script logic, SDK API usage, and compliance audit requirements.

PX Script Revision Logic Fix:

Your current code creates the SBOM but doesn’t initialize it as a revisioned object. You need to use the IRevisionControlled interface after object creation:

IItem sbomItem = (IItem)session.createObject("SBOM");
sbomItem.setValue(ItemConstants.ATT_TITLE_BLOCK_NUMBER, sbomNumber);
sbomItem.setValue(ItemConstants.ATT_TITLE_BLOCK_DESCRIPTION, description);

// Initialize as first revision
IRevisionControlled revControl = (IRevisionControlled)sbomItem;
revControl.setRevision("A");

Agile SDK API Usage:

The critical step is properly casting to IRevisionControlled and setting the initial revision before save(). In Agile 9.3.4, the SDK requires explicit revision initialization for programmatically created items. Additionally, ensure your session has appropriate privileges - use session.setUserContext() if needed to match the privilege level of manual SBOM creation.

For bulk operations, wrap your import logic in proper transaction handling:

  • Use session.beginTransaction() before the loop
  • Call setRevision() for each SBOM immediately after setValue() calls
  • Commit in batches of 50-100 items to maintain performance
  • Implement rollback logic for failed items

SBOM Compliance Audit Resolution:

For the 1,200 existing SBOMs without revision history:

  1. Immediate Fix: Create a remediation script that iterates through affected SBOMs and properly initializes their revision records. You’ll need to use the Agile SDK to update the REVTABLE entries directly or use the revision API to “re-establish” them as Rev A with proper audit trail timestamps.

  2. Validation Layer: Implement post-import verification that queries each SBOM’s revision history immediately after creation:

IRevision[] revisions = sbomItem.getRevisions();
if (revisions == null || revisions.length == 0) {
    // Log error and rollback
}
  1. Audit Trail Reconstruction: For compliance purposes, you may need to work with Oracle Support to properly backdate the revision creation timestamps to match the original import dates. Document this remediation in your audit trail as a corrective action.

  2. Future Prevention: Add revision validation to your PX script framework as a mandatory check. Consider implementing a custom workflow that automatically verifies revision initialization for all SBOM imports.

The key takeaway is that PX scripts bypass normal Agile business logic, so revision management must be explicitly coded. Always test bulk import scripts on a small dataset first and verify database table entries (NODETABLE, REVTABLE, HISTORYTABLE) before running production imports. For compliance-critical objects like SBOMs, consider adding automated validation that checks revision history completeness as part of your import process.

If you need to remediate the existing 1,200 SBOMs, I recommend engaging Oracle Support to ensure the revision history reconstruction maintains audit trail integrity for regulatory compliance.


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.

I’ve seen this exact behavior before. The issue is that your PX script is creating new objects directly without initializing the revision sequence properly. When you use createObject() without setting up the revision context, Agile bypasses the standard revisioning workflow that normally happens through the UI or proper SDK calls.

Check your PX script execution privileges first. In 9.3.4, there were some permission changes around revision management that could affect bulk operations. Your script might be running with elevated privileges that skip revision initialization. Also verify that your SBOM class has the proper revision scheme configured in JavaClient admin settings. Sometimes custom subclasses inherit incorrect revision behavior. Run a test with a single SBOM creation through the same PX script and examine the database tables directly - look at the NODETABLE and REVTABLE entries to see if revision records are being created at all.

The root cause is missing revision initialization in your code snippet. You need to explicitly invoke the revision creation methods from the Agile SDK API. After creating the item object, you must call the appropriate methods to establish it as the initial revision in a sequence. The SDK provides specific interfaces for this - look into IRevisionControlled interface methods. Also, your PX script should be using the VersionControlService or equivalent to properly register the item in the revision chain before saving.

“Confirmed this resolves the SBOM revision history gap — casting to IRevisionControlled after createObject ensures Agile PLM properly initializes revision tracking during PX bulk imports.”

Thanks for the insights. I checked the database tables as suggested and confirmed that REVTABLE entries are completely absent for our bulk-imported SBOMs. The NODETABLE has the records but without proper revision linkage. Our SBOM class does have a revision scheme configured (A-Z sequence), and manual creation works perfectly. This definitely points to the PX script logic needing revision API calls. Could someone share an example of proper revision initialization using the SDK? I’m particularly concerned about how this affects our compliance audit trail since we need full history tracking.

Your compliance concern is valid - missing revision history can fail regulatory audits. Beyond fixing the PX script, you should also implement validation checks post-import. We built a verification routine that queries imported items and confirms revision table entries exist before marking the import as successful. For SBOM compliance specifically, you might need to regenerate the audit trail for those 1,200 components by creating proper revision records retroactively, though this requires careful database manipulation and Agile support involvement.

I ran into similar issues during a large-scale SBOM migration project. The key is understanding that PX scripts operate at a lower level than the standard Agile API, so you need to explicitly handle revision management. Consider switching to the full Java API instead of PX if possible, as it provides better revision control abstractions. For your immediate situation with 9.3.4, you’ll need to add revision handling before the save operation.