I’m attempting to learn more about beanshell’s functionalities and there doesn’t seem to be any examples that I can find for delimited file manipulation specifically calling out for the removal of the domain name in one of the columns.
Hoping you guys can help me with figuring this out.
Am I correct in assuming your using essentially the msDS-principalName format in your CSV file and that the record value would always be in format DOMAIN\crimson3708 or would it in fact be DOMAIN\crimson3708
Hmm I believe it to be a complete buildmap - I’ve done small similar ones like this in the past. This is a little bit outside what I’m used to since I’ve never replaced/gotten rid of a portion of a cell via buildmap.
The extra \ there was actually so VS Code would show the correct parsing of java as it would shout at me about non escaped backslash haha.
This is the escaped code - the domain is actually a placeholder sanitized to not show the actual domain.
The main goal with this was to get rid of the DOMAIN\ that shows in the user listing because we can’t correlate off that. (We also only have like 10 or so extension attributes to go off of for searchable fields)
Good day @Crimson3708 I did also try the same for us and also tried a few different approaches too, it seems like there is an issue with the escaping of the forward slash in beanshell rule import causing the rule to go awry. This may be a bug in escaping the forward slash causing this simple rule to go awry, hope to feed back soon.
I attempted to modify it - it errored on saving the change via the IDN Visual Studio Code Extension - it looks like its blocking cause it things its not escaped properly.
Failed to save ‘CRM App BuildMap Modifier’: Unable to write file ‘idn://domain-sb.identitynow.com/beta/connector-rules/Unique ID/CRM App BuildMap Modifier’ (Error: The request could not be parsed.)
Worth noting that the quoting tools on this site seems to be getting rid of backslashes depending on what quote style I use.
The username is actually formatted DOMAIN\ un-escaped, and DOMAIN\\\ escaped.
This is the script which I think should preserve the escapes I have in there.
The reason I am asking is because in java replace and replaceAll methods handle the searchFor string differently. While replace method treats it as a character squence, replaceAll treats it as regex. This is an age old issue with Java and while using replaceAll method you will have to use \\\\ to escape a single \ as internally these are compiled by Java and then by regex. If you use replace then it is just compiled by Java and \\ will be treated a \