Symantec IGA

#Policy xpress

On a custom create form, i need user id to be genrated incrementally and With uniquness check .

I know how to do the unique check but i am mixing thingsup and not able to create the incremental unique number.

I used a Math data element With increment by 1 and checked its uniqueness and restart the policy but the NeXT run the data element will be the same as before.

For example: Generate_User_id is map increment With intial value 01 and incremental 1, next run its going to be the same. How to hold the value in this data element or what am i MISSSING!!

You will need to keep a counter somewhere. Perhaps you can create a DB table to keep a counter (would need to ensure the DB was locking as to avoid concurrent requests from getting the same value) or perhaps you could insert a record into the DB and have the DB generate a unique counter and then select the record you just inserted to get back the incremented counter.

I agree one can do this way but we should not use the DB or LDAP is there any other way using just policy press data elements or variables 

You need to be able to persist and increment the piece of data. If you don't store the value in a DB or LDAP store then you wouldn't be able to increment after each execution.

How about writing a BLTH handleValidation(BlthContext, errorMessage) and generate the user id and I can even check it against exsiting users using BlthContext.getUserProvider().findUsers(...

I don't see how that would be efficient if you are starting at counter=0 each time and then performing a loop to keep searching with an increment of counter+1 for each loop iteration. As time goes on the number of loops required will increase. Also you would need to consider concurrent tasks being executed where both tasks may believe they have found the next available number to use as both searches would return the same results.

I think the most robust solution is to perform an insert into a DB where the DB is responsible for an incremented count and then you can perform a select against the DB to find the entry you inserted and retrieve that DB generated counter.

In any case that is the only suggestion I have to provide.

Hi Kenny

Can you provide some example of policy that insert a number into DB and is incremented and then the number is retrieved. Screenshots of policy would be helpful....thanks in advance.

Thats true from efficiency purpose and the fact that concurrent task i not handled in this manner. Actually the customer wont like to make any changes to the DB and as a result I am forced to see alternatives.

I have recently had a support case along these same lines:

I think the problem that we are running into is documented here:
https://communities.ca.com/docs/DOC-98228136

Bulk Load Limitations
Generate Unique User ID - Generates a unique identifier in both the corporate directory and the provisioning server userstore and endpoints.
Uniqueness and Policy Xpress
If the unique identifier uses a non-random business logic, the likelihood of generating a similar identifier is high during the onboarding process. One method is to generate the user identifier with sequential numbers appended to the end of the string, while considering the allowed maximum length of the string; then check uniqueness against the corporate directory.
Operation in memory may run in parallel and collide
During the bulk onboarding process, multiple accounts (1000) have unique identifiers generated. If there is no similarity between sequential IDs and the business logic used to generated the unique identifier, Policy Xpress generates a unique identifier as expected. If there is the possibility of a similar ID and/or a workflow process is to be introduced into the onboarding process, then a temporary database table is required to retain the generated unique identifier until the unique identifier has been committed to the corporate directory; otherwise the single uniqueness check against the corporate directory will not be sufficient. A secondary uniqueness checker is required against the temporary database table to ensure that no two IDs are used prior to being written to the corporate directory.

The resolution to that support case was to read a table that held the unique number, and 1 to it, then write to that table then continue with user creation.

Hi ,

can you please share me the doc in how to do,because i to got struck in this use case please help in this.

thanks in advance