JDBC Connector - nativeIdentity is set to "?"

Hello,

I’m having an issue for the JDBC Connector on the Modify Operation only, where the nativeIdentity is set to ??? in the provisioning plan, instead of the actual nativeId. On Create Operation, the correct nativeId is sent and set.

Rule snippet:

// Check if plan is null
if ( plan != null ) {
    // Get all account requests from plan
    List accounts = plan.getAccountRequests();
    // If the plan contains one or more account requests, we'll iterate through them
    if ((accounts != null) && (accounts.size() > 0)) {
      for (AccountRequest account : accounts) {
        **String nativeId = (String) account.getNativeIdentity();**
        log.error(\"native identity: \" + nativeId);
        log.error(\"application: \" + account.getApplicationName());
        log.error(\"operation: \" + account.getOperation());
        List attributeRequests = account.getAttributeRequests();
        if (attributeRequests != null) {
          log.error(\"Num of AttributeRequests: \" + attributeRequests.size());
          // iterate through each attribute request
          for (AttributeRequest attributeRequest : attributeRequests) {
            String attributeName = attributeRequest.getName();
            Object attributeValue = attributeRequest.getValue();
            attributeMap.put(attributeName,attributeValue);
          }
        log.error(\"map: \" + attributeMap.toString());
        }

in the debug I see:

{…“level”:“INFO”,“IdentityIQ”:“8.3p4 Build 4cd878af669-20241202-173620”,“message”
:“Provisioning [Modify] for account [FAKEID0001] starting.”,“pipeline”:“1.12.2”,“@timestamp”:“2025-02-05T00:03:54.933Z”,“thread_name”:“pool-6-thread-79”,“atlas-util”:“2.7.1”,“metrics”:“1.10.5”,“region”:“us-east-1”,“AppType”:“JDBC”…}

{…“level”:“ERROR”,“IdentityIQ”:“8.3p4 Build 4cd878af669-20241202-173620”,“mess
age”:“Enter UserID Provisioning”,“pipeline”:“1.12.2”,“@timestamp”:“2025-02-05T00:03:54.946Z”,“NativeIdentity”:“???”,“thread_name”:“pool-6-thread-79”,“atlas-util”:“2.7.1”,“metrics”:“1.10.5”,“region”:“us-east-1”,“AppType”:“JDBC”…}

The remaining debug continues to reference ??? as the NativeIdentity. Ultimately, it fails, as it is supposed to reference this nativeIdentity on the record it is updating.

Happy to provide the full provisioning rule and sproc if needed.

Hey Tim!
It looks like the NativeIdentity is getting lost in the shuffle as the rule steps through the code…
I noticed in the first part of your debug there was this message:

"Provisioning [Modify] for account [FAKEID0001]...

This leads me to believe the NativeIdentity is at least found when the Modify operation is triggered…
However, in the next message:

"Enter UserID Provisioning"....

This is where we see the NativeIdentity is now suddenly ???

I probably need more context to make a better guess on this, but based off what I can see here, I would suggest throwing another one of your log.error(\"native identity: \" + nativeId);
error logging messages, immediately after the "Enter UserID Provisioning".... message to begin to trace where the NativeIdentity gets lost in the process. :slight_smile:

@moss_snake_01 you can try to get the native identity using the below code
String username= request.getNativeIdentity();

Thanks for replying! Yes, I do have a log.error later in the code that reports the same:

“message”:“account attr-EEID: ???”

I have it set via:

          pStatement.setString(7, nativeId);
          log.error(\"account attr-EEID: \" + nativeId);

This parameter is set from the above rule snippet.

@schattopadhy – I’ll give request a try instead. Right now, it is using account. Is there documentation on these by chance, if you know?

Sadly, I can’t reproduce the ??? in my sandbox tenant, but I did update the rule to reference request. How do these two classes (?) differ in what is sent?

Should I be considering that this ran fine within Sandbox, and only occurs in Production?

There are no before provisioning cloud rules set.

If you are having those issues getting nativeIdentity via account.getNativeIdentity(), you can directly pass value of nativeIdentity via plan and fetch that value from plan as you are fetching other variables.

Apologies for my lack of knowledge around the plan, but does the plan always pass the nativeIdentity? I noticed in the map output from the rule snippet above on a recent modify operation, it only had the attributeName and attributeValue of the attributeRequest that was being modified.

How does referencing plan differ from account? Is this equivalent to Shantanu’s recomendation to use request?

You can see what value plan has passed in “Account Activity” of that particular user. If you go to search and search for the id that you are running those tests, then the “Account Activity” section will show you all the values passed in the plan. You can see “ACCOUNT REQUEST” and “ATTRIBUTE REQUESTS” section. The native identity, if sent, is seen in “ACCOUNT REQUEST” section and other information such as entitlement info or any attributes info is seen in “ATTRIBUTE REQUESTS” section.

1 Like

Is this in the ISC console Search? For account activity I only see attributes passed:

It said this activity passed too, but failed under the hood.

No. Go to Search in the search bar. Search target user and you will see “Account Activity” and all plan variables.

Ah, thanks for the redirect.

I don’t see the connector in the account activity when it was reactivated (rehired) initially; only when I went to manually fix the source database record and manually re-process the identity. I was expecting to see the connector in these initial activity events.

The manual fix involves updating one of the database fields directly for the record in the source database, such as a change on status to active (A). I then go to remove the account from the list of accounts this Identity has through Roles/Access Profiles. Once I re-process the identity, it then re-correlates and updates the existing record as a create account action (as highlighted by associated Account Activity). Any further modify actions work as expected.

What confuses me, is that I would expect this behavior on all existing records that are modified, but its only happening to some existing identities. Any net new identities are generated without issue, and further modify operations work as expected.

A bit more context that may help…

This connector was refactored into a new database a bit ago, and all existing records were migrated over. The correlated attribute values were configured the same in the prior iteration and the new connector.

I’m going to push this to our production tenant next week (changing the class from account to request) – I saw no issues in our Sandbox, but then I haven’t been able to reproduce this in Sandbox either. Worth a shot.

Sadly, this didn’t resolve it. The same issue is occurring.

I noticed on another connector I am updating that uses a similar block of code to set the nativeId, as well as build out a hash map for the attributes, that the NativeIdentity associated with the ccg log event is SearchSam instead of an Employee Number.

The account correlation is set up the Account Name = SeachSam and also correlating Account ID = Employee Number.

I’m not sure how it’s identifying that it needs a Modify operation rather than create, as the single account query lookup is based on Employee Number.

Might have figured out a solution – I moved the getNativeIdentity() call outside the for loop. It is set now immediately after the plan.getAccountRequests() call.

May not be tied, but in that other JDBC connector, this seemed to resolve it. Hoping for the same here. I’ll report back!