Missing IN or OUT parameter at index 2 - Oracle Stored Procedure JDBC Connector Issue

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Hi Community,

We have a JDBC application in SailPoint IIQ 8.x
connected to an Oracle database.

Target system provides a stored procedure
FETCH_EMPLOYEE_DATA to fetch user accounts.

The procedure runs successfully in SQL Developer
returning user data via REF CURSOR.

However when SailPoint tries to Discover Schema
or run Aggregation, we get:

“Missing IN or OUT parameter at index:: 2”

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Working Script in SQL Developer:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

VARIABLE v_cursor REFCURSOR
VARIABLE v_status VARCHAR2(100)
VARIABLE v_message VARCHAR2(200)

BEGIN
FETCH_EMPLOYEE_DATA(
p_cursor => :v_cursor,
p_errcode => :v_status,
p_errmsg => :v_message
);
END;
/
PRINT v_status
PRINT v_message
PRINT v_cursor

Output:
v_status → 000000
v_message → SUCCESS
v_cursor → (returns employee data successfully)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SailPoint XML Configuration:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━




true

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Our Setup:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  • SailPoint Version : IIQ 8.x
  • Connector : JDBCConnector
  • Database : Oracle
  • Driver : oracle.jdbc.driver.OracleDriver
  • useStoredProcedureSqlStmt : true
  • Test Connection : SUCCESS
  • Discover Schema : FAIL

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Procedure Signature:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Position 1 → p_cursor (OUT SYS_REFCURSOR)
Position 2 → p_errcode (OUT VARCHAR2)
Position 3 → p_errmsg (OUT VARCHAR2)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Constraints:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  • REF CURSOR is at Position 1 in procedure
  • Procedure cannot be modified
  • No DB write access, cannot create wrapper

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
What We Tried:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  1. Named parameters:
    BEGIN FETCH_EMPLOYEE_DATA(
    p_cursor => ?,
    p_errcode => ?,
    p_errmsg => ?
    ); END;

  2. Positional parameters:
    BEGIN FETCH_EMPLOYEE_DATA(?,?,?); END;

Both give same error:
“Missing IN or OUT parameter at index:: 2”

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Has anyone successfully configured Oracle Stored
Procedure with REF CURSOR at first position in
SailPoint JDBC Connector?

Any help is appreciated!

Thanks

2

HI @Shubhangani_Kharayat

This is a known limitation of the SailPoint JDBC connector with Oracle stored procedures.

The JDBC connector does not properly support Oracle procedures where a SYS_REFCURSOR is the first OUT parameter. During schema discovery and aggregation, IIQ internally prepares the callable statement expecting IN parameters first, which causes the error:

“Missing IN or OUT parameter at index:: 2”

That’s why:

  • The procedure works fine in SQL Developer

  • But fails in Discover Schema / Aggregation from IIQ, even with positional or named parameters

Unfortunately:

  • Named parameters are not truly supported by the JDBC connector

  • REF CURSOR must typically be the last parameter

  • This behavior is connector‑side and not configurable

What usually works

:white_check_mark: A wrapper procedure/function where:

  • IN params come first

  • SYS_REFCURSOR is last

In your case (given constraints)

  • The procedure cannot be modified

  • You cannot create a wrapper

Your realistic options are:

  • Use a custom JDBC rule (bypassing schema discovery)

  • Switch to Direct SQL (SELECT) instead of stored procedure (if permitted)

  • Or handle aggregation via flat file / staging table exposed by DB team

No misconfiguration on your side: this is a JDBC connector limitation with Oracle REF CURSOR positioning. Without a wrapper or rule‑based workaround, IIQ won’t be able to consume this procedure.

Hope this helps set expectations.

3

Hi,

Thank you for the detailed explanation.

I wanted to confirm one thing regarding the
“custom JDBC rule” option you mentioned.

Could you please clarify what type of rule
should be used here?

I tried using a JDBCBuildMap rule but it
seems that rule only triggers during
Aggregation, not during Schema Discovery.

Also since the REF CURSOR is at Position 1,
the connector fails before the rule even
gets triggered.

So my questions are:

  1. What exact rule type should be used for
    this custom JDBC rule approach?

  2. Will this rule bypass the Schema
    Discovery error as well, or only fix
    Aggregation?

  3. Can you share a sample rule structure
    for this scenario?

Looking forward to your guidance!

Thanks

4

@Shubhangani_Kharayat I think for stored procedure to work, you need to append “call” at the beginning like {call FETCH_EMPLOYEE_DATA(?, ?, ?)}. Could you please give it a try with this?

Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(:heart:,:+1:, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.

5

hi @Shubhangani_Kharayat Short answer: there is no rule that can bypass Schema Discovery in this case.

  • JDBCBuildMap (or any JDBC rule) runs only during Aggregation, not during Schema Discovery.

  • Since the stored procedure fails at discovery time (REF CURSOR as first OUT param), the connector errors before any rule is invoked.

So:

  • :cross_mark: No rule type can fix or bypass the Schema Discovery error

  • :white_check_mark: Rules can help only if you avoid stored‑procedure‑based discovery (e.g., manual/static schema)

I would go below options:

  • Define the account schema manually and use JDBCBuildMap for aggregation

  • Use direct SELECT SQL instead of the procedure (if allowed)

  • Use a staging table/view/file feed

This is a connector limitation, not a misconfiguration.