Data integrity errors in SBOM Management after migrating legacy BOMs with custom fields

We migrated 2,400 legacy BOMs with custom compliance fields into SBOM Management module and now facing data integrity issues. The BOM hierarchy validation is failing for approximately 15% of migrated items, showing orphaned child components. Our custom field mapping included fields like ‘RoHS_Status’, ‘REACH_Compliance’, and ‘Conflict_Minerals’, but many values are appearing as NULL despite being populated in source data. I’ve attempted basic PX scripting to fix the data but getting constraint violations. The compliance disruption is severe as we can’t generate accurate compliance reports.

Sample error from PX script:


Constraint violation: SBOM_ITEM_FK
Parent SBOM_ID not found: SBOM-2024-1573

I’ll provide a complete solution for your data integrity issues:

1. Custom Field Mapping - Standardization Strategy:

First, create a mapping table for compliance field transformations:

CREATE TABLE compliance_mapping (
  legacy_value VARCHAR2(100),
  target_value VARCHAR2(50),
  field_name VARCHAR2(50)
);

Populate with your variations:

  • ‘RoHS Compliant’ → ‘Compliant’
  • ‘RoHS-OK’ → ‘Compliant’
  • ‘Non-compliant’ → ‘Non-Compliant’
  • etc.

2. BOM Hierarchy Validation - Rebuilding Relationships:

Create a PX process extension to fix orphaned items. Here’s the pseudocode approach:


// Pseudocode - Hierarchy Fix Process:
1. Query all SBOM items where parent_id references non-existent SBOM_ID
2. Cross-reference with migration_log table to find legacy parent IDs
3. Look up new SBOM_ID for each legacy parent in id_mapping table
4. Update orphaned items with correct parent SBOM_ID
5. Validate hierarchy depth doesn't exceed max_levels (typically 10)
// Commit in batches of 50 to avoid lock timeouts

Key validation before updates:

  • Verify parent SBOM exists in target system
  • Check that update doesn’t create circular references
  • Ensure parent-child relationship maintains proper BOM structure levels

3. PX Scripting for Data Fix - Complete Implementation:

Script 1: Compliance Field Standardization

Implement in PX using IAgileSession:


// Pseudocode - Field Value Standardization:
1. Get all SBOM items with custom compliance fields
2. For each field (RoHS_Status, REACH_Compliance, etc.):
   a. Read current value
   b. Look up standardized value in compliance_mapping
   c. If mapping exists, update field with target_value
   d. Log transformation for audit
3. Handle NULL values: set default based on legacy system rules
4. Validate against list field constraints before commit
// Process in batches, transaction per 25 items

Script 2: Hierarchy Reconstruction

This is more complex - you need to process in correct order:

// Top-level pseudo-logic
List<IItem> orphanedItems = findOrphanedSBOMs();
for (IItem item : orphanedItems) {
  String legacyParentId = getLegacyParent(item);
  IItem newParent = findMigratedParent(legacyParentId);
  item.setValue(SBOM_PARENT_FIELD, newParent);
}

4. Execution Plan:

Phase 1: Pre-Fix Validation

  • Run integrity check queries to document current state
  • Export affected SBOM records to CSV for rollback capability
  • Verify all legacy parent IDs have corresponding migrated SBOMs

Phase 2: Field Value Fixes (Run First)

  • Execute compliance field standardization PX
  • Validate 100% of custom fields have valid list values
  • Generate compliance report to verify data accuracy

Phase 3: Hierarchy Fixes (Run Second)

  • Execute hierarchy reconstruction PX
  • Validate no orphaned items remain
  • Run BOM explosion report on sample items to verify structure

Phase 4: Post-Fix Validation

  • Re-run all integrity checks
  • Compare record counts: should have zero orphans
  • Test compliance report generation end-to-end

5. Handling Edge Cases:

Missing Parents: If legacy parent wasn’t migrated (obsolete item), either:

  • Create placeholder parent SBOM with minimal data
  • Reassign to a ‘Legacy_Unmapped’ parent for later cleanup
  • Document for manual review

Circular References: Your PX script MUST check for these:

  • Before assigning parent, verify item isn’t already an ancestor
  • Use recursive query to check full hierarchy path
  • Reject and log any circular relationship attempts

Data Type Mismatches: For fields beyond simple lists:

  • Date fields: parse legacy format and convert
  • Numeric fields: handle decimal precision differences
  • Multi-select lists: split comma-separated legacy values

6. Monitoring and Rollback:

Create monitoring queries:

-- Check orphaned items
SELECT COUNT(*) FROM sbom_items
WHERE parent_id NOT IN (SELECT sbom_id FROM sbom_master);

-- Check NULL compliance fields
SELECT COUNT(*) FROM sbom_custom_fields
WHERE field_name IN ('RoHS_Status','REACH_Compliance')
AND field_value IS NULL;

Run these before and after each fix phase.

If you need to rollback, restore from your pre-fix CSV exports using Data Loader in update mode.

Expected Outcome: After completing all phases, you should have:

  • Zero orphaned SBOM components
  • 100% populated compliance custom fields with valid list values
  • Accurate compliance reports that match legacy system baseline
  • Full audit trail of all data transformations

The 15% failure rate you’re seeing should drop to 0% after hierarchy fixes. The NULL custom fields should be completely resolved by the field standardization script.


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.

The orphaned components issue suggests your migration script didn’t properly handle the parent-child relationship order. You need to migrate parent SBOMs first, get their new IDs, then migrate children with correct references. The NULL custom fields are likely a data type mismatch between source and target schemas.

For the custom field mapping issues, check if your target SBOM custom fields have the same data types and constraints as your source. RoHS_Status might be a list field in SBOM module but was a text field in legacy. You need transformation logic during migration, not just direct mapping. Also verify that your custom fields are actually enabled on the SBOM subclass you’re importing to.

Good points. I checked and RoHS_Status is indeed a list field in SBOM (values: Compliant/Non-Compliant/Exempt) but was free text in legacy system with variations like ‘RoHS Compliant’, ‘Compliant’, etc. How do I handle the 300+ BOMs that already have the wrong mappings? Can I use PX to fix them post-migration?

“Tested this on Agile PLM 9.3.6 and the compliance_mapping table approach successfully standardized our RoHS field variations before bulk BOM import via the SDK.”

Yes, PX is the right approach for post-migration cleanup. You’ll need two scripts: one to fix the parent-child relationships by rebuilding the hierarchy, and another to standardize the compliance field values. For the hierarchy fix, query all orphaned items, find their intended parents in the legacy mapping table, and update the SBOM_ITEM_FK references. For compliance fields, create a mapping table that translates legacy values to valid list entries.

Before running any PX scripts, back up your SBOM tables. Also create a validation query to identify all affected records. Something like: SELECT COUNT(*) FROM sbom_items WHERE parent_id IS NOT NULL AND parent_id NOT IN (SELECT sbom_id FROM sbom_master). This gives you the exact count of orphaned records. Run your fix script on a test subset first.