JDBC Merging Configuration Corruption via Configuration Hub Backup/Restore

Hi EXPERTS,

I am experiencing an inconsistency when using Configuration Hub to back up and restore JDBC applications that have merging enabled. After restoring a deleted source from a Configuration Hub draft, the merging configuration structure changes, leading to aggregation failures.

Steps to Reproduce

  1. Perform a backup of a JDBC application (with merging enabled) using Configuration Hub.

  2. Delete the original source from the system.

  3. Restore the source using the saved Draft in Configuration Hub.

  4. Observation: Compare the merging configuration before backup and after restoration.

Configuration Comparison
Stage 1. Original State
Expected Behavior / State: Merging configuration is correctly defined as below
Group.mergeRows:false and Group.indexColumns:[F_ID_MASTER] .
Actual Result: Works as expected; aggregations succeed.
Stage 2. Backup JSON
**Expected Behavior / State :**The JSON file exported via Config Hub should match the API/XML definition.
Group.mergeRows:false and Group.indexColumns:[F_ID_MASTER]
Actual Result: The JSON reflects the correct configuration.
Stage 3. Post-Restore
Expected Behavior / State: Configuration should be identical to Stage 1. but changed as below
Group.mergeRows:true and Group.indexColumns:[F_ID_SLAVE] (THIS IS WRONG)
Actual Result: Configuration is altered (Group.mergeRows:true and Group.indexColumns:[F_ID_SLAVE]
), causing aggregation to fail.
Impact

  • Aggregation Failure: The restored source cannot process data due to the malformed merging logic.

  • Manual Overhead: Currently requires manual intervention via API to fix the configuration, which is not scalable for environments with numerous JDBC applications.

Can any one please help me on the below?

  • Is this a known limitation of Configuration Hub when handling the mergeRows or indexColumn attributes in JDBC?

  • Why does the Draft restoration process modify the JSON structure specifically for merging configurations?

cheers,

VJ

Hi @awadyafai

I wonder, have you read this policy?

https://developer.sailpoint.com/discuss/pub/ai-usage-policy

The only thing that needed to be said was “Create a case with SailPoint support”. There’s not much else we in the Dev Community can do with an SP provided tool that isn’t working as expected.

Matt

Hi @MattUribe

Point taken — I should have kept it simple and directed VJ straight to support. Thanks for the reminder about the AI usage policy, too. I’ll be more mindful going forward.

And yes, “raise a support case” was really the only actionable answer here.

Appreciate it.