Identity Refresh in Joiner Workflow throws a Identity Lock error

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Which IIQ version are you inquiring about?

8.4p1

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

I am running an Identity Refresh in a Joiner workflow and I’m getting this error:

ERROR Thread-72 sailpoint.object.LockInfo:448 - class sailpoint.object.Identity reached end of Refresh without lock: [Identity123]

I’m not sure if this error really matters, as the rest of the workflow seems to run just fine. Can anyone tell me how I can get past this error? I’m not sure I understand what it is saying and we don’t see this error on other Identity Refreshes we have running in other workflows.

Thanks!

2

check if foregroundProvisioning= true in workflow.

3

I don’t have foregroundProvisioning set as an argument on the Identity Refresh step.

4

Hi @vic_rinkenberger

I would guess without seeing the workflow a previous step has created a lock.

You could make a step before the refresh step to check and/or release the lock with sailpoint.tools.Util class there are methods in the javadoc

5

That’s a good thought. The previous steps in the workflow are minimal, but they do create an Identity object (although it is never modified) like this:

Identity identity = context.getObjectByName(Identity.class, identityName);

Here is the Identity Refresh step:

  <Step action="refreshIdentity" icon="Task" monitored="true" name="Refresh Identity to set Manager on Identity" posX="647" posY="10">
    <Arg name="refreshLinks" value="false"/>
    <Arg name="identityName" value="ref:identityName"/>
    <Arg name="promoteManagedAttributes" value="true"/>
    <Arg name="provision" value="true"/>
    <Arg name="promoteAttributes" value="true"/>
    <Arg name="correlateEntitlements" value="true"/>
    <Arg name="refreshManagerStatus" value="true"/>
    <Arg name="checkHistory" value="true"/>
    <Arg name="includeWindowModified" value="true"/>
    <Transition to="Create Accounts"/>
  </Step>

How would an Identity get locked if you are not modifying it?

1 Like
6

Hi @vic_rinkenberger

When you have finished processing this Identity object try using:

context.decache(identity);

7

Just to be clear, you are saying to create a step right after the Identity Refresh and run that code? Or run that code before the refresh?

8

Lock might happen if you try to modify identity during refresh. I saw eg. Lifecycle trigger with workflow where someone just did identity.setAttribute and commit transaction. Same might happen in source mapping rules - all identity modifications might throw lock exception.

9

The refresh is meant to update the identity with the manager value from the HR source of authority. It does set the manager value, but it also throws that error.

10

Hi @vic_rinkenberger

I am saying that within the step that is using context.getObjectByName at the end of this try the statement provided before the refresh step.

11

I tried context.decache(identity) on the step before the refresh, but I got the same error. At the beginning of my workflow, I have a bunch of variables being assigned like this:

  <Variable name="identityEmail">
    <Script>
      <Source>
        Identity identity = context.getObjectByName(Identity.class, identityName);
        String identityDepartmentCode = identity.getAttribute("department");
        return identityDepartmentCode;
      </Source>
    </Script>
  </Variable>

Surely I wouldn’t need to run a decache on all of those Variables… I just can’t understand how this doesn’t happen on other workflows that I have.

1 Like
12

Hi @vic_rinkenberger

What about the IdentityTrigger? Anything there that is locking the object.

Compare the differences between a working workflow and this one.

13

The trigger looks like it shouldn’t cause a problem:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE IdentityTrigger PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<IdentityTrigger handler="sailpoint.api.WorkflowTriggerHandler" name="JoinerIT" type="Create">
  <HandlerParameters>
    <Attributes>
      <Map>
        <entry key="businessProcess"/>
        <entry key="identityProcessingThreshold" value="20"/>
        <entry key="identityProcessingThresholdType" value="percentage"/>
        <entry key="workflow" value="IdentityLifecycleJoinerWF"/>
      </Map>
    </Attributes>
  </HandlerParameters>
  <Selector>
    <IdentitySelector>
      <PopulationRef>
        <Reference class="sailpoint.object.GroupDefinition" name="HR Users"/>
      </PopulationRef>
    </IdentitySelector>
  </Selector>
</IdentityTrigger>

I compared against a working workflow that is called from a form and nothing stood out as being different. I unfortunately don’t have a workflow with an identity refresh that is being called by an IdentityTrigger.

14

This seems to be new behavior in 8.4, we were consistently seeing it during aggregations with refresh options and where we were setting multi-valued attributes on an identity. We set externalHandlerSeparateThread and it resolved the issue.

1 Like
15

I set this argument to both true and false on the Identity Refresh step, but I get the error either way:

<Arg name="externalHandlerSeparateThread" value="true"/>

Am I supposed to be setting that argument somewhere else or in some other way?

16

If you are creating an AD account, how about trying to remove the “password” attribute in an after provisioning rule from the plan. Or in any application that you are setting a password in, there is a bug where it tries to update password history and commits the wrong identity object.

17

Hmm, I’m just running an identity refresh that doesn’t do anything other than promote the manager value onto the identity.

18

Hi Vic,
Have you managed to figure out what happened at the end? It looks like I have the same issue, on version 8.3p3 - the joiner workflow finished even though the AD account is not created and a form is left to fill…

19

I didn’t actually have any real issues attached to the error. That’s the strange thing. Everything worked as expected, but I just got the error. I still have not figured it out.

20

Hi,
I am also facing the same issue even while running the LCE workflow even for Prehire where we are not refreshing the identity itself.

Also as per the suggestion provided above i verified i don’t have foreground provisioning, all the use cases i can see above.