Issue in genrating UserID through BLTH in Create User process

[Shashank Agarwal]

Hi All,

 

We create users in the system through bulk feed. We have a BLTH script implemented at Create User process which calculates the userId of the user based on combination of last name and first name.

 

In that script we make sure that only unique combinations are generated by comparing the combination value wit the IAM user store.

 

But if we pass two(or more) entries in the same feed with same last name and full name, the process executes for one entry and fails for other with error " ERROR MESSAGE: [LDAP: error code 20 - Duplicate attribute value/s detected:"

 

It seems main issue is due to multi-threading feature of IDM. IDM opens separate thread for each entry due to which the logic fails for generating the unique userId. Please find below logs for more reference:-

 

 

2015-03-30 04:11:21,651 INFO  [STDOUT] (pool-66-thread-1) GenerateUniqueFullName_CreateEmployee BLTH Version 1.2 usrFltr=com.netegrity.llsdk6.imsapi.policy.rule.constraints.UserFilter@34f58b4

2015-03-30 04:11:21,661 INFO  [STDOUT] (pool-66-thread-1) 21.0

2015-03-30 04:11:21,677 INFO  [STDOUT] (pool-66-thread-2) GenerateUniqueFullName_CreateEmployee BLTH Version 1.2 usrFltr=com.netegrity.llsdk6.imsapi.policy.rule.constraints.UserFilter@8fb9650

2015-03-30 04:11:21,688 INFO  [STDOUT] (pool-66-thread-2) 21.0

 

As per our analysis, userId is calculated via BLTH scripts and then it is passed onto IDM. So when the userId was generated for second user , first user was still not pushed into IDM which resulted in same userId for both the users.

 

Can anyone guide us how to proceed on this?

 

Thanks.

 

Regards,

Shashank

[phone]

[Sagi Gabay]

This is a design question really. There is no problem with the product. It actually functions correctly and your description suggests you well understand it.

You are correct, if you check against the user store then you will not find what is not there and so if too much time elapses between your check and your commitment then your calculated value may be taken and you won't be able to commit it anymore. You are correct that this is due to the multi thread and asynchronous nature of the product execution.

 

I say that this is a 'design' question since you will need to 'design' your solution taking into account the product's behavior and this exact possibility.

 

The way I see it , you have a few alternatives:

1. Perhaps the easiest would be: leave it as is. Mostly it won't happen. Chances of you processing users with similar enough first and last names almost at same time are probably minimal. This means you won't run into this often enough. What you can do is still monitor for this error, perhaps for this specific error maybe email the administrator with the failed ID, along with an explanation of this situation and ask they resubmit again. When they resubmit later this should be fine.  You can also just gather all these failures and resubmit them automatically and only if failing the second time then you may want to alert your administrator.

 

2. You may change your code so that by the time it reserves a certain User ID then it will immediately create the user, then from there onward basically modify it (adding more attributes, roles, memberships, whatever).

 

3. You can also have your BLTH code manage its own 'registry' where the User IDs that passed the BLTH check will be written in some local file or some place where you will also check against that on top of the normal check which basically will ensure you're taking into account the User IDs that are 'under process' and 'being submitted' which are not yet known to your user store.

 

 

Honestly, I think solution #1 is probably the cleanest since you will allow your function to work in a clean way and simply resubmit your failures giving them another try as a second batch run , perhaps even a third. If all that fail then you may want to result to emails and manual intervention.

 

 

Hoping you found this helpful.

 

 

Regards,

Sagi

[Shashank Agarwal]

Hi Sagi,

 

Thanks for the response.

 

 

1.       We already gave the first solution you proposed to the client first time they reported the issue. They wanted us to explore if there was any possibility for this race condition to be handled by our system.

 

2.       If we are going to make any changes in our code so as to introduce any kind of delay etc., this would apply to all the threads that will be opened by the IDM for each entry. Hence the delay will be checked for each subsequent entry into IDM and ultimately this will also fail. We tried this also in our test lab ☹

 

3.       We thought of making some changes in the input file processing like splitting the input file into parts in case of similar entries and then submitting them one after other. We have multiple tenants using the same feed code for processing entries into the system , any kind of change may result in issues for other tenants as well. Hence we did not implement this as well.

 

The frequency of such scenarios occurring will be less and as you said we have also decided not to make any changes in the current system implementation.

 

I will come back to you in case my client wants us to handle this scenario anyhow.

 

Thanks.

 

Regards,

Shashank

[phone]

[Arij Qamar]

Hi Shashank,

 

 

I think if you execute the following query on task persistence table dbo.event12_5, you can solve this duplicate id issue:

 

select state from TPDB.dbo.event12_5 where state not in (32,128,512) and name = 'CreateUserEvent' and description like'%newUserID%

 

If the result set is empty, then "newUserID" is definitely unique. There is no pending request for user creation with the id "newUserID".

 

Hope that helps.

 

Regards,

 

Arij