Announcing the Saviynt Knowledge Exchange unifying the Saviynt forums, documentation, training,
and more in a single search tool across platforms. Read the announcement here.

Account Naming Rule - auto increment not computing

flegare
Regular Contributor III
Regular Contributor III

Set up a simple account naming rule:  concat(first letter of first name, lastname, customproperty16) # concat(first letter of first name, lastname, auto-increment from 2, customproperty16)

At run-time, however, rule does not seem to compute past the first auto-increment.  Attempting to generate another conflict results in the user having to provide the account name.

Rule1

flegare_0-1684976792676.png

Rule2

flegare_1-1684976815102.png

Logs reflect the following behavior:
com.saviynt.ssm.arsms.util.ARSUtils : Account Name Rule : concat(substring(users.firstname,1,1) , users.lastname , users.customproperty16) # concat(substring(users.firstname,1,1) , users.lastname , substring('~2',1,1) , users.customproperty16) SPCL:@.

Further on, this ~2 seem to cause some indigestion:
Error in getEntityObjectAttrVal|org.springframework.beans.NotReadablePropertyException: Invalid property ''~2'' of bean class [com.saviynt.ssm.entity.Users]: Bean property ''~2'' is not readable or has an invalid getter method: Does the return type of the getter match the parameter type of the setter?|

Any idea as to where I possibly messed up?

Thanks!

François

2 REPLIES 2

pruthvi_t
Saviynt Employee
Saviynt Employee

Hi @flegare ,

Greetings.

Can you please try to remove the rule 2 and recreate it and check if it still throwing the error.

Also please try to copy the rule from logs, enable the advanced config portion paste the rule and remove '~' and see if it works fine. Kindly let us know your findings.

Thanks,


Regards,
Pruthvi

flegare
Regular Contributor III
Regular Contributor III

hi @pruthvi_t ,

I gave the old "delete and recreate" a try and observed the same behavior from the user's perspective and log content

I tried setting the rule from the logs in the advanced config and got the same behavior from end user's but no reference in the logs this time.

However, we sort of gave up and set up an advanced rule that simply lists the conditions with 12 distinct statements so this is no longer a priority.  I highly doubt this client's user base will ever generate more than 12 conflicts in this connector.  I will keep digging when time permits though.

Thanks for your assistance, it is always appreciated.