ISC JDBC Connector: Built-in Provisioning Query Settings | How to access plan arguments?

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Hi everyone,

I’m looking for some info if you’ve configured the JDBC Connector to use the provisioning settings directly on the UI, which now lets us skip writing simplistic JDBC Provision Rules.

I am trying to configure the Create Account SQL query, and had a question. I see from the documentation that we can access the plan attributes, but can we also in a similar fashion access plan’s arguments?

For instance, if I have a ProvisioningPlan object which has some Plan Arguments, can I do something like this to access a specific key’s value? $plan.arguments.myKey$

Would love to get your insights if you’ve attempted something similar.

Sushant.

2

@sushantkulkarni -

Short answer: for the new “low-code” JDBC provisioning queries in SailPoint ISC, the documented placeholders are:

  • $plan.<fieldName>[.<type>]$ – values taken from the provisioning plan (i.e., the account request’s attributes), and

  • $response.<fieldName>[.<type>]$ – values captured from a prior query in the same query set,

not $plan.arguments.*. The docs don’t list plan.arguments as available in JDBC SQL templates, only the two forms above. (documentation.sailpoint.com)

So if you currently stash data in plan arguments, you have two reliable patterns:

Pattern A — Promote the value in a Before Provisioning Rule

Copy your plan argument into a real account attribute (or add a transient attribute request) so the SQL can reference it as $plan.myPromotedField$.

Rule (excerpt):

// Cloud Before Provisioning Rule (runs for all connectors)

ProvisioningPlan plan = (ProvisioningPlan) request.getPlan();
Map args = plan.getArguments();
if (args != null && args.containsKey("myKey")) {
    String val = String.valueOf(args.get("myKey"));
    for (AccountRequest ar : (List<AccountRequest>) plan.getAccountRequests()) {
        if ("yourJdbcSourceName".equals(ar.getApplication())) {
            // Create/replace an attribute request so it appears as $plan.myPromotedField$
            ar.add(new AttributeRequest("myPromotedField", ProvisioningPlan.Operation.Set, val));
        }
    }
}
return plan;

SQL template (Create Account):

INSERT INTO users(login, display_name, extra_col)
VALUES ($plan.login.string$, $plan.displayName.string$, $plan.myPromotedField.string$);

This keeps the value inside the plan but places it where the JDBC template engine actually looks. (documentation.sailpoint.com)

Pattern B — Use a prior query and pass along $response.*

If your “argument” can be looked up, run a first query to fetch it, then reference it from later queries via $response:

-- Query 1: look up BU id you “would have” passed via arguments
SELECT id AS buId FROM business_units WHERE code = $plan.buCode.string$;

-- Query 2: create user using value from Query 1
INSERT INTO users(login, bu_id)
VALUES ($plan.login.string$, $response.buId.int$);

JDBC query sets explicitly support reusing response fields like this. (documentation.sailpoint.com)

Why $plan.arguments.* works elsewhere but not here

You’ll see $plan.arguments.<key> in ITSM/SDIM connectors (Velocity templates) and forum examples; that path is documented for ticketing payloads, not for JDBC SQL variables. JDBC’s low-code feature documents only $plan.<field> and $response.<field>. If SailPoint adds plan.arguments to JDBC templates in the future, they’ll update that page; as of today, it’s not listed. (community.sailpoint.com)

TL;DR / Recommendation

  • No: $plan.arguments.myKey$ is not a documented placeholder in JDBC SQL templates. Use $plan.<field> or $response.<field> instead. (documentation.sailpoint.com)

  • Do: move your value from arguments into an attribute request in a Before Provisioning Rule (Pattern A), or fetch it in a prior query and reference $response (Pattern B). (developer.sailpoint.com)

Cheers!!!

3

If we’re moving to a rule, there is no question, it will work. We can access the plan completely and use it as needed without needing anything else. The question I had was with the OOTB provisioning query settings. Checking if there is a way or if rule is the only way forward.