Question regarding pruning of NativeChange Events

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Which IIQ version are you inquiring about?

Version 8.3

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

Hello,
We just recently upgraded from IIQ 8.0p1 to 8.3p3, which went pretty well overall. When we did the upgrade we noticed the new NativeChange Events that where triggering, and added the “nativeIdentityChangeMaxAge” value to the system config and set it to “7” so these events wouldn’t accumulate. We are seeing a number records in the Request objects table beyond the 7 days that we assumed we had set the pruning to. The requests are of the “NativeIdentityChangePropagation” type, and are all failures that we see due to identity locks during our Rehire lifecycle events. We do run the “Reset Failed NativeIdentityChange Events” a number of times a day in an attempt to ensure these all process successfully. (after a refresh, and once a day in the evening) As far as I can tell they are just failed events that eventually process successfully, but I’m not sure how we are supposed to get these cleared out of the “Request” table? I’m used to that table being mostly empty unless something is running, or something is being “retried” as is the case with some email events. Did I misunderstand what the nativeIdentityChangeMaxAge setting and “Prune Native Identity Change Events” task is supposed to be doing, or is there some issue in 8.3p3 that isn’t cleaning these things up? I’m sure I could write a rule to clean these out if needed, but I thought that was what the prune task was for.

Thanks!
Mike Frank

2

These are stuck NativeChange detections. the request table should not have “anything” at the end of the day if everything is processed. SOmething is getting stuck in there.

3

Thanks Ivan, definitely agree these are stuck for some reason, the part I don’t understand is that the processing does complete successfully, and there are no “failed” native change events to reset when that “Reset” task is ran. So maybe these are just some artifact of the original failure that isn’t being cleaned up properly by the SailPoint code? I can manually delete them from the Request table in debug, and I’m assuming I can write a rule to do the same.

Here is a partial chunk of these requests, I copied up until I hit person specific info. This only occurs on our Rehire events, for those identities that the AD account still exists, but is in a “disabled” OU. During the Rehire, the account is moved back to the Users OU, which is probably what is triggering the Native Change event. Everything about the rehire processes successfully.

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Request PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Request completed="1710672698882" completionStatus="Error" created="1710672628095" host="BJCIIQBT01" id="0a333e2e8e3d1a11818e4c08c97f220d" modified="1710672698882" name="Native Identity Change Propagation Request for Account" type="NativeIdentityChangePropagation">
  <Attributes>
    <Map>
      <entry key="NativeIdentityChangeEventIdList">
        <value>
          <List>
            <String>0a333e2e8e3d1a11818e4c08c941220b</String>
          </List>
        </value>
      </entry>
      <entry key="NativeIdentityChangeEventType">
        <value>
          <ObjectType>Account</ObjectType>
        </value>
      </entry>
      <entry key="partitionResult">
        <value>
          <TaskResult completed="1710672698867" completionStatus="Error" host="BJCIIQBT01" launched="1710672629251" name="Native Identity Change Propagation Request for Account">
            <Messages>
              <Message key="msg_plain_text" type="Error">
                <Parameters>
                  <String>Timeout waiting for lock on object: sailpoint.object.Identity:0a333f4a71991ce881719a1cf74d45ae from SP LCE Rehire Trigger:
4

We did a recent upgrade as well and do see these native change events, but nothing is stuck so far.

5

Hi Abhishek,

By saying “nothing is stuck” are you saying you aren’t seeing these requests remaining in the Request object table? Have you had any of the NativeChange requests error or fail during processing? We don’t see the successful events in the Request table, only the errored ones.

Thanks!
Mike

6

If they are in the Request table they are stuck/not executed. You need to understand why though and try to solve it . Normally putting wait checking for locks in LCM events solves this issues.

Environment with requests stucks are not healthy