Here's an outline example of what I was thinking of. Note, I haven't actually tested this, so you may need to modify
It assumes all Policies are of type "UI" and fire on "submission", e.g. for requests from the bulk load client.
P1 - Set variables
Data:
First_Name (user attribute)
Last_Name (user attribute)
Counter (constant = 0)
Action rule
Set variable: Insert_Success_var=false
Set variable: First_Name_var={First_Name}
Set variable: Last_Name_var={Last_Name}
Set variable: Counter_var={Counter}
P2 - Check if UID candidate is unique
Data:
First_Name (variable = First_Name_var)
Last_Name (variable = Last_Name_var)
Counter (variable = Counter_var)
Counter_Plus_One (math - increment Counter by 1)
Uid_Candidate (constant = {First_Name}{Last_Name}{Counter})
Is_Uid_Candidate_Unique (attribute - uniqueness checker)
Is_Uid_Candidate_In_Runtime_DB (SQL query)
Action Rule
Condition: Uid candididate is unique and not in runtime DB
Action: SQL - run procedure to insert into DB
Set Variable: Insert_Success_var=true (this must come after the SQL query)
Set Variable Uid_var = {Uid_Candidate}
Condition: Uid candidate not unique and/or in runtime DB
Action: Set variable: Counter_var={Counter_Plus_One}
Redo policy
P3 - handle SQL Insert failures
Data
Counter (variable = Counter_var)
Counter_Plus_One (math - increment Counter by 1)
Insert_Success (variable = Insert_Success_var)
Entry Rule
Insert_Success = false
Action Rule
Action: Set variable: Counter_var={Counter_Plus_One}
Goto previous policy
P4 - Set user attributes
Data
Uid (variable = Uid_var)
Action rule
Set User Attribute - %USER_ID% = {Uid}
Now the trick is in Policy 2 to make sure that the entire task doesn't fail if you fail to write the UID Candidate into your runtime DB. To do this, in Policy 2, go to the "advanced" tab. Change the "validation" and "environment" errors to "fail policy" (I think the default is "fail task"). This means that the policy will fail but the task does not, so you will proceed to the next policy
So if the UID Candidate you choose in P2 is unique, you then write it to the the DB. If this succeeds, the next action is to update the "Insert_Success_var" variable to "true". If it fails (e.g. because another request has just written the same value to the DB), then the policy fails before it gets the chance to update the "Insert_Success_var" - i.e. it is still set to "false" from P1
So when P3 runs, it checks the "Insert_Success_var" value. If it is "true", P3 does nothing (entry rule condition not met). If it is false, P3 increments the counter and returns to previous policy to try again with a new UID Candidate.
Make sure to write the log for each action in each policy to troubleshoot.
Pearse