Replacing Deprecated methods for upgrading IIQ to 8.4 Version

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Which IIQ version are you inquiring about?

8.4

Share all details about your problem, including any error messages you may have received.

We are in process of upgrading our current IIQ version 8.2 to IIQ version 8.4. During this process we are replacing the deprecated methods with provided alternatives. For below class and method Sailpoint did not provided any alternative but only mentioned that as deprecated.

Package Name : sailpoint.connector
Class : JDBCConnector
Method name : buildMapFromResultSet​(java.sql.ResultSet result, Schema schema)

Below code line needs to be modified in code base to correct alternative :

Map map = JDBCConnector.buildMapFromResultSet(result,schema);

This screenshot of javadoc for JDBCConnector class and highlighted is the method with no alternate.

image
image1920Ă—974 152 KB

If you came across this problem. Please provide the inputs on this.

Appreciate your input. Thanks

2

sometime the deprecated funcion still working, but in every case, why dont use the funcion above? the buildMapFromResultSet(result)

Also, if you see the details you can find out which function replaces the deprecated one.

1 Like
4

Hi @vivekpotdaraexp,

You’re definitely not alone in facing this during the 8.4 upgrade—we encountered the same while upgrading from 8.1 to 8.4.

As a side note (and while I can’t say with 100% certainty, I’m fairly confident): usually when SailPoint deprecates a method without a documented replacement, it’s often a sign that it was originally intended for internal use only, not for external or custom rule logic.

The buildMapFromResultSet(ResultSet) that’s still available doesn’t handle schema normalization, which is critical in many connector use cases “especially if your DB field names differ from what’s defined in the application schema”.

We ended up manually replicating the behaviour with something like this:

Map<String, Object> resultMap = new HashMap<>();
ResultSetMetaData meta = result.getMetaData();
int colCount = meta.getColumnCount();

for (int i = 1; i <= colCount; i++) {
    String colName = meta.getColumnName(i);
    Object val = result.getObject(i);

    if (schema != null && schema.getField(colName) != null) {
        colName = schema.getField(colName).getName();
    }
    resultMap.put(colName, val);
}

We wrapped this in our custom rule library and used it across connector workflows. It’s a clean workaround that avoids relying on deprecated or internal-only APIs, and it’s working well post-upgrade.

Hope this helps others running into the same issue during version jumps.
Feel free to adapt the logic based on how tightly your schema names match your DB columns.

1 Like
5

Fun fact -

IIQ actually has a built-in feature for this! I’ve never actually seen it documented anywhere. You can specify an internalName on a Schema field, and IIQ will translate back and forth. It’s implemented in the ConnectorProxy class that wraps all connectors at runtime.

3 Likes
6

Thanks a lot, @drosenbauer!, honestly, I didn’t know about the internalName feature - that’s a really helpful insight, Appreciate you pointing it out!

It’s always great to learn these kinds of details from people who’ve dug deep into the platform. I’ll definitely explore how we can leverage that in our connector configurations going forward.

If you’ve seen any good examples or spots where this worked well in your projects, I’d love to hear more.

Have a nice and great one!

Regards,
Mustafa

7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.